directadmin security?

With the recent cpanel exploit mess I want to ask the creators of DA what security measures do you have in place to make sure your code is secure? It would be great if DA and us as hosting companies can avoid the cpanel problems with security.

Since all of it is complied and closed source we are totally relying on you to keep the code secure. Do you have another firm or person audit your code to ensure it is secure? Is it possible to discuss have select hosting companies audit your code?

Hi Larry,

There are several coding techniques I use to ensure the code is secure.

1) non-trusting functions. All functions don't trust anything they're given, even if they're internal function calls. This means, that even if invalid strings make it past the intial filters, internally, they'll get stopped.

2) Don't run as root. DirectAdmin runs as the "nobody" user for 98% of the time. Only when it needs root access does it ever get it. If it only needs "diradmin" access, then it will only have that access permission to open the writing of a file... once open, the permissions are dropped back down, even before the writing has commenced.

3) Variable length memory/strings. All data in DA is worked with using variable length buffers, so overruns can't happen. If you give too much info, then the filters will either say, "hey, you gave too much", or else DA will just make a buffer big enough for the data.

4) No local memory buffers. Undestanding how program stacks work in memory, local buffers are bad if they're overrun because they'll be overwriting the programs code in memory, allowing unwanted code execution. We use memory that is not local and is all requested from the systems "heap".. meaning "not where code lives". Any overruns would be done in "storage" which never gets executed.

5) no backdoors. The only way into DA is through the front door (port 2222). We have no special access to your machines and cannot help you if (for example) you lose your passwords.

6) security over functionality. As you may have seen with some aspects, DA can be restrictive. For example, you may want to use certain characters for filenames, passwords, etc. We always start out with the most strict ruleset first, and then very slowly add flexibiliy as needed.

All put together.. should any single point fail, there are others to catch it. Many layers of security is the best strategy.

John

Regarding Larry's questions about security auditing:

We do not believe releasing source code to third parties is in the best interests of our business or customers. Aside from thoughtful programming, protecting the code itself is a security measure we take very seriously. The DirectAdmin source code has never left our physical possession or been stored anywhere online.

Please reply back if you need further clarification on our decisions -- we have considered this issue in-depth during the formation of the company with the assistance of legal and technical professionals.

Mark

While I think all of the coding measures you have in place are great, I still think it would help if you had a third party, like a security firm, audit your code.

DirectAdmin Support said:

2) Don't run as root. DirectAdmin runs as the "nobody" user for 98% of the time. Only when it needs root access does it ever get it. If it only needs "diradmin" access, then it will only have that access permission to open the writing of a file... once open, the permissions are dropped back down, even before the writing has commenced.

Click to expand...

IMHO this is the area that has the greatest risk of an exploit.

From what we have seen and tested we do think your application is secure (and was one of the reasons why we chose it) but we have no way of knowing and trusting DA should there be a problem like Cpanel has had that you will also be quick to fix it.

You guys might know me from webhostgear and I'm a major cpanel user but I'd like to give DA a shot on my personal boxes. Cpanel is currently on their 3rd patch to fix the problem and since broken more things than you can believe.

empowering said:

While I think all of the coding measures you have in place are great, I still think it would help if you had a third party, like a security firm, audit your code.



IMHO this is the area that has the greatest risk of an exploit.

From what we have seen and tested we do think your application is secure (and was one of the reasons why we chose it) but we have no way of knowing and trusting DA should there be a problem like Cpanel has had that you will also be quick to fix it.

Click to expand...

Simply do a search for DA exploits vs CPanel. That says enough for me.

And I agree with not releasing source to any third party, even an Audit firm.

I have found this Advisory

http://packetstormsecurity.org/0605-advisories/sa19885.txt

altho I don't know if the problem has been fixed and if not, please do

Hello,

I've commented on that report many times. There is zero security risk with that. All it means is that a User has the ability to break his own web forms meaning he can't submit any valid data to DA. All that happens is a User shoots himself in his own foot. He can't hurt anyone else, he can't break into the system. It accomplishes nothing but his inability to use the form after he messes with the variable. The skins are designed that way, to allow forms to be created with variables passed around. You might as well just write your own broken html with notepad at home and view it in your browser locally. It's does about the same level of damage (ie: none). Messing with the tokens just breaks the forms making them useless. I barely consider it a security issue. All data passed to DA to execute actual tasks is extremely strictly parsed, which is much different that the skin variable passing. Moving from page to page doesn't do anything important. As for "fixing" it, yes, I've "fixed" it, but there wasn't much point in doing so (was only done to make people happy).

John

Well John you know that I appreciate all of the stuff that you guys do to keep us all secure

one of my clients got hacked via DA i.e. the attacker was able to login with his user and pass after checking the logs I've found that theres no sign of brute force or anything but going back 3-4 months I found signs of brute force attack on his account for almost 10 days straight isn't there something to be done to protect from this kind of brute force (BFD don't monitor DA logs)

I would probably guess that he had an insecure password like... "password"...lol.

BFD should monitor at the server level anyway...and one should always be watching your logs on a regular basis to catch those kinds of activity.

Hello,

Yes, there is a Brute Force Detection (BFD) and block:

Admin Level -> Admin Settings -> Blacklist IPs for excessive login attempts: [x] after [ 30 ] attempts.

Make sure that's turned on.

John

Thanks John it wasn't enabled