poto

I seen a pretty good post by minusonebit about securing your dedicated box... thought I'd repost it here...

---

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.

8. If Your Box is Compromised.

If your box is compromised, your only immediate concern should be protecting the data and the evidence it may contain as to who is responsible. You should not be on GFY or anywhere else freaking out, you should be taking actions to stop the breach from going further and then looking what happened, who did it and how. You should notify your customers of your issue because it is the right thing to do and because the laws of almost 40 states require you to do so.

Turn the box OFF by issuing shutdown commands and contact your host immediately to make arrangements to get the server shipped, the hard drive shipped or whatever else needs to happen. Do not leave a compromised box online or reachable for any reason - ever. Do your investigation locally without the server online. Leaving a hacked box online may subject the data to further or additional compromise and your box could be used as a launching pad for attacks on other boxes in your data center or outside of it.

__________________
My Ratios :: My Blacklist

pussyluver

wow, that's a challenging list. If you're going to own a dedicated server then you should really be able to manage it correctly. That's a tall order for a webmaster given all the other responsibilities and tasks to cover. That's why hosting companies offer managed services. They keep up with all the details regarding updates, security, hacks and configuration. Obviously some do better than others. Really covering 100% of the technical tasks by a hosting provider would make the cost prohibitive I suspect.

Good points made by the piece though.

Add disabling directory listing (if they mentiooned that and I missed it)

pussyluver

1. Disable and Remove Telnet and FTP.

It would be an old box with Telnet enabled. Good point on SFTP. A lot of apps rely on ftp for updates and collaborative work. Contribute and Dreamweaver come to mind. I will be checking that out on my own usage.

1a. Disable and Remove Unused Packages and Programs.
Wish I were smart enough to know each and every server process and app I might use or need sometime. Is there a better alternative etc. The major ones are obvious. Can all describe every process in your PID list or all the processes on your PC for that matter.

1b. Microsoft Front Page Extensions.
Is a virus and should never be turned on.

1c. Remove "Pine"
ok - it was off to begin with

2. Make Absolutely Certain that PHP, phpMyAdmin, MySQL and Apache are Updated.This I expect from my manged hosting provider, but do check from time to time generally. Do I know if they have every single patch and adjustment made - no.

Brings up another point. It is prolly smart to move to a new server or do a total rebuild every year to make sure you keep up with the latest versions and patches. The idea being that the larger and smart host will have an upto-date image to apply!

2a. Consider Removing Apache and Going to lighthttpd.
NO - Still learning Apache - lol Plus not sure my manged hosting supports it. Am using FreeBSD which some say is better for security.

pussyluver

3. Disable Plaintext Logins for Root.
Obvious

4. Services DO NOT Get to Run as Root
Not gonna list a screen cap of my PIDs - Think my host read the article or knew the issues before they did the setup of the box. The right provider is key unless you're a guru yourself.

5. You Should Sign into Every Server you Own at Least Once a Week and Watch Things.
agree. Even if you don't understand everything, anything that does raise a flag can be researched or you can ask your provider. Fuck, a manual comes on the machine... Then there is google or as a last resort GFY.

Seriously, your best source if things are serious are your peeps. Those you know you can trust, even with your passwords.

6. Uninstall and Remove Zend Optimizer if Possible
Does CT need Zend Optimizer? We could use a discussion about CT sometime. Sixzeros has always gone the extra mile. Still it is software and all software is a risk...

7. Know Your Box.
Fo sure. Look often, see something you don't like find out. Fail to do this at your own risk. Speaking from experience of course. Look daily. Monitoring software makes sense. A seperate thread on that should be up if not already.

8. If Your Box is Compromised.
Unless you physically own the box, the host is not gonna ship it to ya. Plus they may beable to interrupt what went on better than you can if you're not a guru. Still looking at logs provides a wealth of information.

Reporting a hack to authorites may be more involved and take more time than it is worth, something to consider. If you haven't been through it, talk to someone that has.

So unless it involves stollen cc number or equally valuable info, prolly best to learn from the event and figure out a fix or protection. Then get your shit up on another box ASAP.

Taking a box down hurts seo, trades, income. Dreamhost is so cheap it's not funny, so you could get a site back online fairly quick if you grabbed an account from them and changed DNS info. BTW, they do mirroring. That could be an answer depending on what the exact issues were. If you're in trouble, your host provider can prolly get a second box up too and move the data fast.

Parting thought on the list that would apply to most of us here I think. Who you host with is paramont. If you can't stand the downtime, then you need tech support+++++ and the ability to contact the individual to get to the companies best brains to resolve an issue. That's even if it is on Christmas day at 3:00 am.

poto

I've heard these peeps will do a one time 'hardening' for your box...
Vintage Host - Web Hosting, Web Sites, Web Site Design, Dedicated Servers

they also do monitoring for a monthly fee type deal...
Vintage Host - Web Hosting, Web Sites, Web Site Design, Dedicated Servers

I've not used them myself, but I have heard good things...

__________________
My Ratios :: My Blacklist

poto

yes, comus uses zend :/

although, it's probably the only script that I trust to use it... there have been a few security issues in the past... if I remember right one of two of my comus sites got hit with an exploit a while back that put a nasty little iframe that tried to do an auto-install, I caught it quickly and removed it so not much damage was done... and I'm pretty sure they patched that in the current version, so I'm not gonna stress about it...

__________________
My Ratios :: My Blacklist

pussyluver

know CT uses zend. is zend and zend optimizer one in the same - may be my first dumb Q of the day?

poto

yea, you need zend optimizer to run zend encoded scripts...

of course there are ways to de-zend scripts... if you really wanna run it without the zend encoding and peek at the source

__________________
My Ratios :: My Blacklist

pussyluver

Thanks for the references. Looking at some software monitoring products too. Plus wanna talk to my host. Think my rep will be back this week. Need to tighten up my ship a bit. Been keeping an eye on the server, several times a day.

Got a list to address with the host. I think they will provide a ton of support. Just there may be a charge for some of it beyond what I am paying now.

pussyluver

Ya know, I'm not really qualified to totally manage a server. Then again a lot of those in tech support know less than I do. Can't tell ya how sad that is.

If I let someone in to harden my server, which I truly think needs to be done, I'd loose support from my host provider.

poto

yea, it's sad... half the time I know more than the tech support guys... and I'm no expert myself :/

damn, that sux... why will they cut off support? is it a TOS violation or something... one would think they would want you to have a more secure box...

__________________
My Ratios :: My Blacklist

pussyluver

TOS = if you get root access (which you would need) then they will not support the server. You get shell access, but it is limited. For example, you can NOT view raw access logs. Have to do that through a stats program in the control panel.

poto

hrm, well that kinda bites

__________________
My Ratios :: My Blacklist

stma

I recently added bruteforce protection on a couple of my servers. It's amazing how many 'events' happen daily with folks trying to break into your box.

Stats for yesterday show that I've blocked 7 IP's with a combined 1500ish attempts.

I've got pretty good support folks, but not all of them are as bright as the others. If your getting bad support from "ramesh (or tony)", or whoever that doesn't seem to understand what your asking for - ask for a supervisor to look into things. Lot's of support is outsourced to India and communication is a problem. They probably have a supervisor that can help them understand what YOU are saying a little better.

__________________
Ed Charkow
Black Hat - White Hat Black Hat Digest - 30 Day Plan