Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: bakedjake
From the Securing Windows [webmasterworld.com] list, you should do the following:
Additional things I do on UNIX servers:
Lock down user accounts - Even though this is in the Securing Windows list, I gave it special mention here. In the old days, most UNIX software was designed to be used from or in conjunction with a shell account. That mentality has held over to today's software in its default state. If you run an FTP or mail service, and that user only needs to access FTP or mail, there's no reason to give them shell access. Keep that in mind when performing your lockdown - no shell access unless necessary!
Kill X - You don't need a GUI on a server. It's wasteful. Get rid of it.
Compile services yourself - I generally compile all services myself (such as apache, qmail, djbdns). The benefit here is twofold: one, you completely customize the software to your preferences; and two, since you set the software up to your specifications, you'll have a much easier time indentifying and combatting problems. No packages, no binaries, only source. Note: I consider skeleton source port systems (such as those that Gentoo or the BSDs use) to be okay.
Install chrootkit [chkrootkit.org] - Run it regularly, and send the output to someone that will read and act upon the reports.
Get a package update notification service - This is critical. With so many open source software apps, things change daily. I know that RedHat has a service, Mandrake has a service, and there's a bunch of others. I'm biased, and mainly use FreeBSD, so I use FreshPorts [freshports.org].
Install nmap [insecure.org] - Run it against your entire network on a regular basis and send the output to someone that will read and act upon the reports. It will tell you immediately if any backdoor is currently running on a server.
Personal/Political Rant (flamesuit on):
Don't use BIND, sendmail, or a GUI (web-based or otherwise) control panel - These are the top offenders of UNIX security and good practices.
If you're running a service, know what it does, make sure it's configured the way you need it, and keep on top of updates.
After years of compiling Apache from scratch every time there is an update, I've gone back to the RPM method. I've saved time, and the updated RPM is available within hours of the patch being released. Anything that I do track the source of, I make into an RPM anyway. Far more efficient to roll out across a dozen servers that way, not to mention ensuring consistency across builds.
The number one thing about security is that locking down your server is only half the equation. If you don't know when you've been hacked, you may as well not bother spending the time on the patching.
Nice firewall apf:
and Brute force protection scrittie:
They have some others. For monitoring I suggest nagios, they have som eplugins that you can use to alert you if someone logs in to your server and such.
Brute Force Detection [hostinglife.com]
Advanced Policy Firewall [hostinglife.com]
There are lots more, but those were some mentioned here.. the site is great for all Server Help [hostinglife.com]
also if shell access in general is required always use SSH not telnet.
make sure to have a software firewall.
Close as many ports as you can. I have a Linux server with ONLY the following ports open:
22 - SSH for shell and sftp access
25 - SMTP for email
80 - HTTP
443 - HTTPS
995 - SPOP3
if possible make sure to have a proper SSL certificate on your server and check your email securely.
use SFTP through the SSH port 22. there is no need for regular FTP because it sends your password in clear text.
I respectfully disagree on the BIND and Sendmail parts...
Just curious to know why that is? I use to use sendmail/bind but about a year ago switched to qmail/djbdns on *all* my servers.
I decided this one day after I was faced with another upgrade to sendmail or bind (can't remember which) due to security flaws.
You know what I'd never go back. They are much leaner. Do everything I need and more and most of all the configuration files are *very* programmer friendly. Ie it's very very easy for me to write a script to add a DNS entry to change my rcpthosts file.
Just my 2 cents from a convert :)