GoFuckYourself.com - Adult Webmaster Forum - View Single Post - Newbie's Guide to Dedicated Server Security

minusonebit · 12-25-2007, 01:39 AM

In light of the TMM/NATS mess that has recently unfolded, I think something like this is needed. So I am gonna start it and people can add on below with their knowledge. Trolls, please, I'm gonna ask nicely. Go to another thread and troll there. Use my name and start some shit, but do it in a new thread. Thanks in advance.

Disclaimer: This is general information and it is being provided for free. Consult an experienced professional before you undertake any of this on your own if you do not know what you are doing. I will not be held responsible in any way for damages that result to your server as a result of your reliance on these instructions. You should not run commands unless you know what they are going to do anyway.

OK, all of this assumes you are running on a LAMP (Linux, Apache, MySQL, PHP) server. If you are running Microsoft Windows IIS box, thats a MAJOR security hole in and of itself and you need to move your stuff to another box.

1. Disable and Remove Telnet and FTP.

Both of these services are outdated, exceptionally old and prone to attack. Additionally, they are no longer useful because of the exploits and they are big targets for hackers who will try and gain access to your server. FTP has been replaced by SFTP and Telnet replaced by SSH - both are MUCH more secure.

1a. Disable and Remove Unused Packages and Programs.

If there is software running or sitting on your box that you do not use - get rid of it - now! Software that you are not using is a huge security risk. Because you are not using it, you are likely not paying attention to it, either. That means you are not updating it and THAT means that any exploits discovered will not be patched. If you don't run any scripts that require PHP, remove it. Removing unused software reduces the possible places an exploit could be.

1b. Microsoft Front Page Extensions.

If you do not use Microsoft Frontpage, your server does not need Frontpage extensions - remove them. They are a terrible security risk whether you need them or not. If you use Frontpage, consider removing the extensions anyway and publishing manually.

1c. Remove "Pine"

Pine is a command line mail program that is poorly written that has had exploits in it and very few people use it. If you do not use it, uninstall it.

2. Make Absolutely Certain that PHP, phpMyAdmin, MySQL and Apache are Updated.

These are where most attempts to hack your box come from. Especially PHP. Software like phpBB, phpNuke and phpMyAdmin that rely on PHP/MySQL are notorious for containing zero day exploits that are taken advantage of to gain elevated privileges on a server. They are also huge targets. If you are running this software, you need to be very aware of your server's security status and you need to patch your box and the software itself religiously. WordPress also has had some security issues crop up from time to time, so you need to make sure you stay up to date with your updates there as well.

2a. Consider Removing Apache and Going to lighthttpd.

Lighthttpd uses less resources than Apache and is more scalable and also to a degree, more secure. Wikipedia runs lighthttpd. However, some of the scripts you have on your box may REQUIRE Apache, so you need to think about this carefully. If you have done tons of hacks through .htaccess or rely on Apache re-write rules extensively a switch to lighthttpd may be a huge pain in the ass. If you are a novice, do not make this decision on your own. Consult someone who knows what they are doing and save yourself alot of hassles.

3. Disable Plaintext Logins for Root.

If you SSH with the userid of "root" and then type a password to become root, this is bad. Even if you use IPsec rules and such, your box can be compromised. The root user is always a target for password cracking by brute force. Instead, set it up so that you have to use an SSH key (4096 bits recommend, 2048 bits minimum) to access this user account. Using a key makes it almost impossible to brute force the password. A general guide on how to do this can be found here.

4. Services DO NOT Get to Run as Root

SSH into your server. Type "top" at the command prompt and strike enter. See the image below. This is from one of my servers at OC3 Networks.

Look at the columns in the red boxes. Note that the results of top (and other commands, for that matter) may look a little different based on the type of Linux you are running. The example is from FreeBSD. This tells you what is running on your server and the resources being used by each item. The left column in a red box is the username running the item and the right most red box is the actual program that is running. On a properly secured box, services (apache, exim, courior, php, mysql, ruby on rails, etc) do not run as root.

If you notice on my box, lighthttpd, php and some other items run as the user "www". Courier - my mail transfer agent - runs as "courier". MySQL runs as "mysql". My IRC bot runs as "eggdrop". Ruby on Rails runs as "ruby". The list goes on and on.

The reason for this is a user account cannot do alot of things on the server that root can do. Root can do anything, root is god. It cant delete the hard drive, it cant run most utilities and it cant delete other user's files or directories. It cannot even change or view (most of) them. If one of these services got hacked, the hackers would not have administrative privileges on the server and while they might be able to make a mess of that software, their ability to damage things is confined to a single user.

Some things have to run as root, so you may still see root in the left box. But you should not see things running as root like the services I mentioned above. Apache does not run as root on a properly configured box. If you do see a bunch of stuff running as root, your box is very vulnerable - its a time bomb waiting to go off. Get professional help right away.

Most webhosts when they deploy a box set everything up to run as root. This is very, very bad. It means that if anyone gets into your box by pretty much any means, your ass belongs to them. I cannot recall how OC3 had the default install of this box setup when I got it from them.

Note: you can type "ps -aux" and hit enter to get most of the same info formatted in a different manner, that may be more helpful to you. Try it and see which way you prefer to get the info.

5. You Should Sign into Every Server you Own at Least Once a Week and Watch Things.

You should go on every box you have every week and spend at least a half an hour each one doing nothing but checking disk space, network usage and so on.

Run "last" to see who was on the box last and where they came from. Look for people you do not know.
Run netstat and watch your traffic live for a few minutes. See what is being accessed and make sure they are files you recognize and that should be there. Look for excessive usage and files that you do not recognize.
Check disk usage by any users and look at what they are storing on your server. You are responsible for your server and what is on it and you have every right to dig through their home directories. I do it all the time and yes, one time I did find a hosting customer storing CP. Needless to say, that customer does not have a relationship with me any longer and I spent quite a bit of time dealing with the authorities. Do note that you need to disclose the fact that you may monitor activity on your network to the users, putting a notice on /etc/motd is a good place to do this.
Excessive disk usage may indicate improper activity. Find out what is being stored.
Run "top" and "ps -aux" and see what is running. You should recognize the services running. Look into stuff that you do not recognize.
Tail the logs of your main sites and see whats going on. Use grep to filter stuff. In the case below, I was watching my traffic from digg.com in real time. See below for an example of usage.

tail -f /usr/local/www/domains/path/to/domain/files/domain.com/logs/lighttpd.access.log | grep digg

6. Uninstall and Remove Zend Optimizer if Possible

Zend itself is not per say a security risk in and of itself - sort of. Zend allows PHP scripts to run in an encrypted manner where you cannot see exactly what the script is doing. And this is a security risk. If someone gets control of your PHP installation, they can run their bad scripts encrypted as well, and you will not be able to see what the scripts are doing. Personally, I refuse to use, buy or install software that requires Zend Optimizer for this reason. Zend claims that is speeds up PHP, I have seen no convincing evidence of this - ever. Script authors claim they use Zend to keep their work from being stolen. I tend to poo on this explanation and believe instead the authors of scripts don't want me to know what they are doing on my box. After all, lawsuits are for re coving damages from stolen work and breach of contract.

7. Know Your Box.

Know where things live on your box. Know how much bandwidth, memory and CPU your box normally uses. Know when major cron jobs run (i.e. awstats) and know what constitutes ordinary usage and extraordinary usage. Investigate extraordinary usage until you find out why its going on. Did you get listed in Wikipedia? Someone blog you? You in the news? Campaign going well on AdWords? Or did someone move in without being invited? Proper investigation and follow up will let you know which and will likely help you refine your techniques to make them even better.

(cont'd below)

12-25-2007, 01:39 AM
minusonebit So Fucking Banned Join Date: Feb 2006 Location: [email protected] Posts: 7,391	Newbie's Guide to Dedicated Server Security In light of the TMM/NATS mess that has recently unfolded, I think something like this is needed. So I am gonna start it and people can add on below with their knowledge. Trolls, please, I'm gonna ask nicely. Go to another thread and troll there. Use my name and start some shit, but do it in a new thread. Thanks in advance. Disclaimer: This is general information and it is being provided for free. Consult an experienced professional before you undertake any of this on your own if you do not know what you are doing. I will not be held responsible in any way for damages that result to your server as a result of your reliance on these instructions. You should not run commands unless you know what they are going to do anyway. OK, all of this assumes you are running on a LAMP (Linux, Apache, MySQL, PHP) server. If you are running Microsoft Windows IIS box, thats a MAJOR security hole in and of itself and you need to move your stuff to another box. 1. Disable and Remove Telnet and FTP. Both of these services are outdated, exceptionally old and prone to attack. Additionally, they are no longer useful because of the exploits and they are big targets for hackers who will try and gain access to your server. FTP has been replaced by SFTP and Telnet replaced by SSH - both are MUCH more secure. 1a. Disable and Remove Unused Packages and Programs. If there is software running or sitting on your box that you do not use - get rid of it - now! Software that you are not using is a huge security risk. Because you are not using it, you are likely not paying attention to it, either. That means you are not updating it and THAT means that any exploits discovered will not be patched. If you don't run any scripts that require PHP, remove it. Removing unused software reduces the possible places an exploit could be. 1b. Microsoft Front Page Extensions. If you do not use Microsoft Frontpage, your server does not need Frontpage extensions - remove them. They are a terrible security risk whether you need them or not. If you use Frontpage, consider removing the extensions anyway and publishing manually. 1c. Remove "Pine" Pine is a command line mail program that is poorly written that has had exploits in it and very few people use it. If you do not use it, uninstall it. 2. Make Absolutely Certain that PHP, phpMyAdmin, MySQL and Apache are Updated. These are where most attempts to hack your box come from. Especially PHP. Software like phpBB, phpNuke and phpMyAdmin that rely on PHP/MySQL are notorious for containing zero day exploits that are taken advantage of to gain elevated privileges on a server. They are also huge targets. If you are running this software, you need to be very aware of your server's security status and you need to patch your box and the software itself religiously. WordPress also has had some security issues crop up from time to time, so you need to make sure you stay up to date with your updates there as well. 2a. Consider Removing Apache and Going to lighthttpd. Lighthttpd uses less resources than Apache and is more scalable and also to a degree, more secure. Wikipedia runs lighthttpd. However, some of the scripts you have on your box may REQUIRE Apache, so you need to think about this carefully. If you have done tons of hacks through .htaccess or rely on Apache re-write rules extensively a switch to lighthttpd may be a huge pain in the ass. If you are a novice, do not make this decision on your own. Consult someone who knows what they are doing and save yourself alot of hassles. 3. Disable Plaintext Logins for Root. If you SSH with the userid of "root" and then type a password to become root, this is bad. Even if you use IPsec rules and such, your box can be compromised. The root user is always a target for password cracking by brute force. Instead, set it up so that you have to use an SSH key (4096 bits recommend, 2048 bits minimum) to access this user account. Using a key makes it almost impossible to brute force the password. A general guide on how to do this can be found here. 4. Services DO NOT Get to Run as Root SSH into your server. Type "top" at the command prompt and strike enter. See the image below. This is from one of my servers at OC3 Networks. Look at the columns in the red boxes. Note that the results of top (and other commands, for that matter) may look a little different based on the type of Linux you are running. The example is from FreeBSD. This tells you what is running on your server and the resources being used by each item. The left column in a red box is the username running the item and the right most red box is the actual program that is running. On a properly secured box, services (apache, exim, courior, php, mysql, ruby on rails, etc) do not run as root. If you notice on my box, lighthttpd, php and some other items run as the user "www". Courier - my mail transfer agent - runs as "courier". MySQL runs as "mysql". My IRC bot runs as "eggdrop". Ruby on Rails runs as "ruby". The list goes on and on. The reason for this is a user account cannot do alot of things on the server that root can do. Root can do anything, root is god. It cant delete the hard drive, it cant run most utilities and it cant delete other user's files or directories. It cannot even change or view (most of) them. If one of these services got hacked, the hackers would not have administrative privileges on the server and while they might be able to make a mess of that software, their ability to damage things is confined to a single user. Some things have to run as root, so you may still see root in the left box. But you should not see things running as root like the services I mentioned above. Apache does not run as root on a properly configured box. If you do see a bunch of stuff running as root, your box is very vulnerable - its a time bomb waiting to go off. Get professional help right away. Most webhosts when they deploy a box set everything up to run as root. This is very, very bad. It means that if anyone gets into your box by pretty much any means, your ass belongs to them. I cannot recall how OC3 had the default install of this box setup when I got it from them. Note: you can type "ps -aux" and hit enter to get most of the same info formatted in a different manner, that may be more helpful to you. Try it and see which way you prefer to get the info. 5. You Should Sign into Every Server you Own at Least Once a Week and Watch Things. You should go on every box you have every week and spend at least a half an hour each one doing nothing but checking disk space, network usage and so on. Run "last" to see who was on the box last and where they came from. Look for people you do not know. Run netstat and watch your traffic live for a few minutes. See what is being accessed and make sure they are files you recognize and that should be there. Look for excessive usage and files that you do not recognize. Check disk usage by any users and look at what they are storing on your server. You are responsible for your server and what is on it and you have every right to dig through their home directories. I do it all the time and yes, one time I did find a hosting customer storing CP. Needless to say, that customer does not have a relationship with me any longer and I spent quite a bit of time dealing with the authorities. Do note that you need to disclose the fact that you may monitor activity on your network to the users, putting a notice on /etc/motd is a good place to do this. Excessive disk usage may indicate improper activity. Find out what is being stored. Run "top" and "ps -aux" and see what is running. You should recognize the services running. Look into stuff that you do not recognize. Tail the logs of your main sites and see whats going on. Use grep to filter stuff. In the case below, I was watching my traffic from digg.com in real time. See below for an example of usage. tail -f /usr/local/www/domains/path/to/domain/files/domain.com/logs/lighttpd.access.log \| grep digg 6. Uninstall and Remove Zend Optimizer if Possible Zend itself is not per say a security risk in and of itself - sort of. Zend allows PHP scripts to run in an encrypted manner where you cannot see exactly what the script is doing. And this is a security risk. If someone gets control of your PHP installation, they can run their bad scripts encrypted as well, and you will not be able to see what the scripts are doing. Personally, I refuse to use, buy or install software that requires Zend Optimizer for this reason. Zend claims that is speeds up PHP, I have seen no convincing evidence of this - ever. Script authors claim they use Zend to keep their work from being stolen. I tend to poo on this explanation and believe instead the authors of scripts don't want me to know what they are doing on my box. After all, lawsuits are for re coving damages from stolen work and breach of contract. 7. Know Your Box. Know where things live on your box. Know how much bandwidth, memory and CPU your box normally uses. Know when major cron jobs run (i.e. awstats) and know what constitutes ordinary usage and extraordinary usage. Investigate extraordinary usage until you find out why its going on. Did you get listed in Wikipedia? Someone blog you? You in the news? Campaign going well on AdWords? Or did someone move in without being invited? Proper investigation and follow up will let you know which and will likely help you refine your techniques to make them even better. (cont'd below)