How do you secure your DirectAdmin server(s)?

questions

Verified User
Joined
Oct 24, 2009
Messages
137
I thought it would be useful to start a discussion about the ways that people have had success with securing their DirectAdmin servers.

Responses should be a itemized list of your operating system and what was done beyond a default DirectAdmin installation to increase security, and finally an account of how long the server has been live and how many times it has been successfully hacked with any kind of /tmp script or other hack.

I've read about securing the /tmp folder to not allow execution of files from it but would like to get a better idea of what really works long term. Please be as exact and complete as possible so that this information can actually be directly replicated and used by even a novice DirectAdmin system administrator.
 
Your server should be made secured and protected, despite directadmin is installed. So you need to use your OS community recommendations to make your server secured. This subject has been already discussed here. You might want to search these forums to find related threads on the subject. I've posted some links somewhere here for CentOS (where is good official CentOS wiki site). There is also on these forums recommendations so called "what to do on the server with newly installed directadmin". For the future references you might want to post here any links, you'll definitely find.

So please Google and good luck.
 
I thought it would be useful to start a discussion about the ways that people have had success with securing their DirectAdmin servers.

Responses should be a itemized list of your operating system and what was done beyond a default DirectAdmin installation to increase security, and finally an account of how long the server has been live and how many times it has been successfully hacked with any kind of /tmp script or other hack.

I've read about securing the /tmp folder to not allow execution of files from it but would like to get a better idea of what really works long term. Please be as exact and complete as possible so that this information can actually be directly replicated and used by even a novice DirectAdmin system administrator.

Your server should be made secured and protected, despite directadmin is installed. So you need to use your OS community recommendations to make your server secured. This subject has been already discussed here. You might want to search these forums to find related threads on the subject. I've posted some links somewhere here for CentOS (where is good official CentOS wiki site). There is also on these forums recommendations so called "what to do on the server with newly installed directadmin". For the future references you might want to post here any links, you'll definitely find.

So please Google and good luck.

I'm aware of how to search this site and the URL for Google. The goal of this post is to create a single post with the information organized in an itemized fashion so that even the novice DirectAdmin system admin can use it. Users who just have links and references to Google should keep to themselves.
 
I've read about securing the /tmp folder to not allow execution of files from it but would like to get a better idea of what really works long term. Please be as exact and complete as possible so that this information can actually be directly replicated and used by even a novice DirectAdmin system administrator.
Security is an ongoing process and not a one-time procedure. For examples, systems passing PCI security checks today may very well not pass them tomorrow.

I have checklists I use myself when setting up servers; they change continuously. And I'm not distributing them simply because someone may rely on them, and then blame me when they have a problem.

Note I wrote when and not if.

We offer server administration services, and our clients tend to stay quite secure, but they still have problems from time to time.

We also offer PCI security configuration, but we're not specifically security specialists.

Of course even companies with many security specialists on board have security problems; a good (fascinating, actually) example can be found here (infoworld.com). Especially fascinating because Comodo is a Certification Authority and a security company with many security products (comodo.com).

Jeff
 
CSF/LFD is a good way to start, in addition to that I would suggest configuring it to suit your needs though, out of the box there are three levels and these don't suit all servers well. You will need to adjust for your specific needs.

I would also suggest changing up some of the ports such as ssh etc.

Once you get CSF configured properly, your DA server can be very secure and protected.

PCI compliance is a joke to be honest, it's just another way for the scanning companies to make money.... while it's a necessary evil, we still have to deal with it, but as Jeff mentioned it's changing everyday and solely dependent on the scanning service you use as well. Some may not like 1a or 1c, while others will simply ignore it or not like 3c or 5f.
 
Thanks for the responses, but I disagree that you can't make a useful list that can help people. Half of the responses are from people who make money from this so they don't want to provide it for free on here, but they do want to advertise themselves.

It would be nice to have an operating system independent itemized list of the best known (within reason) way to secure a single box DirectAdmin server used for providing shared web hosting to others, but its not going to happen if only the people who want to make a buck reply. This would help out a lot of people.
 
I do not want to create a list, but one thing is we have just started using CSF/LFD http://www.configserver.com/cp/csf.html and I must say it is really working great. It also integrates into DirectAdmin.

This doesn't work on FreeBSD which is the OS that I use. It only supports the various Linux distributions.

Also a Firewall is really not going to protect a server that has hundreds or thousands of users that are running Wordpress and Joomla where the end user is most likely going to install insecure and dangerous scripts.
 
Thanks for the responses, but I disagree that you can't make a useful list that can help people. Half of the responses are from people who make money from this so they don't want to provide it for free on here, but they do want to advertise themselves.

It would be nice to have an operating system independent itemized list of the best known (within reason) way to secure a single box DirectAdmin server used for providing shared web hosting to others, but its not going to happen if only the people who want to make a buck reply. This would help out a lot of people.


This is true..... but what I told you was what I do and it works well. Start with csf/lfd, then manually configure the settings to suit your needs.

Then change your major ports or turn off the ones your not using. One I would change for sure is ssh, it's standard on port 22... go for something like 3149 or something off the top of your head in the four digit range.

Those are the basics, along with making sure you are running the latest stable versions of software on the server and OS. Keep up to date on patches and new versions.
 
This is true..... but what I told you was what I do and it works well. Start with csf/lfd, then manually configure the settings to suit your needs.

Then change your major ports or turn off the ones your not using. One I would change for sure is ssh, it's standard on port 22... go for something like 3149 or something off the top of your head in the four digit range.

Those are the basics, along with making sure you are running the latest stable versions of software on the server and OS. Keep up to date on patches and new versions.

Most exploits I've seen over the past 10 years of using DirectAdmin come from insecure scripts installed by the end user, which you can not control, and then were exploited by bots or real live people. I've never had anyone break into SSH or do anything that a firewall would have prevented. I've run DirectAdmin with a firewall and without, and there were no difference in actual security breaches. I did have people install php scripts through holes in other popular php programs like Wordpress or Joomla that gave SSH-like capability. So a firewall is good but I haven't seen it be useful in over 10 years of providing web hosting.
 
Last edited:
Actually, questions, you've answered your own questions as far as I can see, and you've made my point. To the suggestion that you use a firewall you responded that you didn't believe one to be useful. At least I think that's what you wrote.

I think firewalls (even static firewalls) can be very helpful, because even good OS distributions often install daemons you don't want, listening on ports you don't want open, and then when you use package managers to try to remove them you find there are dependencies that keep you from doing so.

And also, because attackers use zero-day exploits to listen on ports or send outgoing traffic to ports, which you'd rather they not use.

So why should I spend hours creating a list (it takes me over two hours to do an initial secure setup of a box) just so you can in a few words tell me why you don't want to do what I do.

Sure it's easy enough for you to say that the only reason I won't create a list is because I want to make money off you. That's just not true, and I won't stop trying to help you on these forums as my time and rsources permit. But as I wrote in post #6 to this thread, Security is an ongoing process and not a one-time procedure.. So a list would be fairly useless. In fact every time I secure a box I make minor changes to my own internal lists. And I've already explained why I won't publish my list.

It's okay that you disagree with me. I've been running and securing webservers since before the Internet was first commercialized in 1995 (when NSFNET was decommissioned, thus removing the last restrictions on the use of the Internet to carry commercial traffic). I've posted well over 22,000 posts on these forums, probably 90% or more of which have been at least tries at being helpful. But I'm still not perfect, and I learn every day. Hopefully I can learn a lot from you.

Thanks.

Jeff
 
Actually, questions, you've answered your own questions as far as I can see, and you've made my point. To the suggestion that you use a firewall you responded that you didn't believe one to be useful. At least I think that's what you wrote.

I think firewalls (even static firewalls) can be very helpful, because even good OS distributions often install daemons you don't want, listening on ports you don't want open, and then when you use package managers to try to remove them you find there are dependencies that keep you from doing so.

And also, because attackers use zero-day exploits to listen on ports or send outgoing traffic to ports, which you'd rather they not use.

So why should I spend hours creating a list (it takes me over two hours to do an initial secure setup of a box) just so you can in a few words tell me why you don't want to do what I do.

Sure it's easy enough for you to say that the only reason I won't create a list is because I want to make money off you. That's just not true, and I won't stop trying to help you on these forums as my time and rsources permit. But as I wrote in post #6 to this thread, Security is an ongoing process and not a one-time procedure.. So a list would be fairly useless. In fact every time I secure a box I make minor changes to my own internal lists. And I've already explained why I won't publish my list.

It's okay that you disagree with me. I've been running and securing webservers since before the Internet was first commercialized in 1995 (when NSFNET was decommissioned, thus removing the last restrictions on the use of the Internet to carry commercial traffic). I've posted well over 22,000 posts on these forums, probably 90% or more of which have been at least tries at being helpful. But I'm still not perfect, and I learn every day. Hopefully I can learn a lot from you.

Thanks.

Jeff

I'm not saying you aren't a great guy, but I don't think that security is really that ongoing except that there are big weaknesses in servers doing web hosting for end users. (because no one wants to be systematic and make a list, hence all the ongoing manual labor involved) I'd like to discuss ways that people secure DirectAdmin, and what breaches they've encountered, and the weaknesses they see in DA) because there are a finite list of things that are done, and hence they can be listed, categorized, and valued according to effectiveness. Then we can make progress instead of going around in circles.
 
As I've told you above, you should start with Handbooks and How-Tos for your specific OS. I always do some certain things just before to install Directadmin (these things have been already mentioned in this thread, and they are discussed on these forums):


1. Change SSH port, and add AllowUsers directive.
2. Setting up firewall.
3. File System Partitioning (extra options for temp directories in /etc/fstab).
4. Chmoding some binaries and directories.
5. Configuring some pre-installed software
6. Password Policies
7. Sysctl Security
etc.

All these things are basic. You can learn with reading your OS handbook, How-Tos.

For FreeBSD it's http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html
For CentOS it's http://wiki.centos.org/HowTos/OS_Protection

In my experience, I've never seen a compromised directadmin. All those bad things happen mostly with SSH/FTP/HTTP and MAIL.

SSH: bad/stolen passwords => malicious software uploaded => spam or other attacks
FTP: stolen passwords => malicious software uploaded => spam
HTTP: different sorts of injections and exploits => malicious software uploaded => spam

Thus, you should make your server secure despite directadmin is installed. Of course Directadmin add some basic protection (access group, chmod/chown). But you never should rely only on directadmin, as it is designed to make hosting more easier, but it never replace a real system administrator.

I agree with Jeff, security is an ongoing process. The best secure and protected server is that one, which is switched off from Internet or even supply power. Thus you should always re-view your secure methods, as hackers are always searching new holes.
 
As I've told you above, you should start with Handbooks and How-Tos for your specific OS. I always do some certain things just before to install Directadmin (these things have been already mentioned in this thread, and they are discussed on these forums):


1. Change SSH port, and add AllowUsers directive.
2. Setting up firewall.
3. File System Partitioning (extra options for temp directories in /etc/fstab).
4. Chmoding some binaries and directories.
5. Configuring some pre-installed software
6. Password Policies
7. Sysctl Security
etc.

All these things are basic. You can learn with reading your OS handbook, How-Tos.

For FreeBSD it's http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html
For CentOS it's http://wiki.centos.org/HowTos/OS_Protection

In my experience, I've never seen a compromised directadmin. All those bad things happen mostly with SSH/FTP/HTTP and MAIL.

SSH: bad/stolen passwords => malicious software uploaded => spam or other attacks
FTP: stolen passwords => malicious software uploaded => spam
HTTP: different sorts of injections and exploits => malicious software uploaded => spam

Thus, you should make your server secure despite directadmin is installed. Of course Directadmin add some basic protection (access group, chmod/chown). But you never should rely only on directadmin, as it is designed to make hosting more easier, but it never replace a real system administrator.

I agree with Jeff, security is an ongoing process. The best secure and protected server is that one, which is switched off from Internet or even supply power. Thus you should always re-view your secure methods, as hackers are always searching new holes.


When I say DirectAdmin I mean a server that is setup using it. Not that I think DirectAdmin is really ever hacked.

I think most of you are barely mentioning the biggest ways that web hosting servers are hacked: through end users installing software that has openings.

So if you have 1,000 end-users installing semi-malicious code in the form on insecure Wordpress and Joomla and similar scripts, how do you deal with this?
 
If you search these forums, you'll definitely find the answers:

— mod_security
http://www.directadmin.com/features.php?id=961
— disable_function in php.ini

Everything was already discussed. What is in public — google and you'll find it — nobody will share his/her own "secret" methods here. I don't want to let hackers to know what exactly I do to make my servers secure. With this I'm leaving the discussion.
 
I´m going right now through all possible security-tweaks, which are almost on all serveradministration companysites. I`m not sure when i will be ready. Maybe I´ll post them later (not as big tutorial, more as linklist with short description). But its all inside, from Linux/OS-tweaks starting with ssh, iptables, through "hardening" filesystem, binaries, php till firewalls and antispam and a lot more.
I have no idea when it will be ready, but maybe it could be a good list with all important pros and cons inside.
I dont promise this yet, but as I am going myself first time a little bit deeper through linux and hostingsecurity, i`ll write them down also for myself. No reason not to share it after.. however .. need time ... dont expect earlier as in 2-3 weeks..
greets..
 
If you search these forums, you'll definitely find the answers:

— mod_security
http://www.directadmin.com/features.php?id=961
— disable_function in php.ini

Everything was already discussed. What is in public — google and you'll find it — nobody will share his/her own "secret" methods here. I don't want to let hackers to know what exactly I do to make my servers secure. With this I'm leaving the discussion.

so I can search and find the answers, but hackers can't... lol.
 
Are there going to be any additional helpful posts on this thread? Or is it time to close it?

Jeff
 
I don't see any reason to close it... if you do then you will see another one soon lol

this is a topic people need to learn about, the more the better!
 
Back
Top