Slashdot Mirror
Ask Slashdot: Securing Web Servers Against Cracking
Bryan Andersen asks: "I'm looking for information
on securing web servers against hacking. In particular,
I'm interested in securing
Apache on Debian Linux
and OpenBSD,
but discussion on other server/OS combinations are welcome.
Links to sites with good information would be greatly
appreciated."
Use a modern os that uses packages (Redhat/Debian)
Be on switched ethernet
Unplug from network
Install OS but with only needed packages.
Turn off all services.
Use MD5 shadowed passwords.
Get stackguard.
Compile all CGI's & SSH & Apache w/ stackguard.
Get a recent kernel and Solar Designers no-stack patch.
Configure no root logon (even in ssh).
Configure SSH to deny by default
Config SSH to only accept connected from good places.
Start SSH and Apache services
ipchain default deny all incoming
ipchain allow ICMP
ipchain allow incoming on port 80
ipchain allow incoming on ssh
ipchain deny outgoing w/ low source if possible (check proc for the lowest auto port (dont have linux handy))
Remove all system utils you are sure you dont need, use find to scan for SUID files and remove all SUID you do not HAVE to have (even things like ping and such).
Go through the system and remove write permission from most files (anything you can).
Set the ext2 immutible flag on system and other static files.
Setup remote syslogging to a box with nothing more then console access (little 386 or sumpting).
Install tripwire (with cron to check and all, set to email and page)
Backup frequently.
Pray to approiate 'force'.
Plug into network.
Subscribe to cert/bugtrack/etc.
Install security updates for everything you have installed, when they come out.
Use SCP to upload content.
If comprimised nuke it, get content (no scripts or bins!) from backup. Goto step 1 and try harder..
I have cracked/hacked many a web server. Most if not all allowed us to exploit poorly configured mahines or applications. A good admin will beat us everytime.. but most places wont pay for a good admin. The hardest computers to crack are the ones limited to the least ammount of accesss they allow. So.. if you dont use it..dont run it. IE if your not using a ftp server why allow ftp access? why not turn off the deamon.. then sshd to move files. Its secure.. and will close all the hundreds of ftpd exploits. Now some would say that a good firewall rule will solve this.. but as I have beaten many a fire wall why not just shut down the stuff your not going to need. This applies to just about every deamon you can think of.. if you dont need it, kill it. Now after that some good firewall rules wont hurt. If this is only going to be a web server then I would only allow your web server port.. firewall with a seperate machine.. then only run your webdeamon. If you need other access allow other machines to do that for you.. your web sever is the big juicy target. Owning a ftp server is all nice and good but If i dont need the space / bandwidth then I really wont bother. Warez kiddies wont even bother to own a system so many ftp server allow anon access that its just funny.. why waste the time on something you can get for free. Really the kernel or OS that you use doesnt really matter.. its how well you configure it.. Its no harder to root/crack a Misconfigured OpenBSD/debian/Irix/winNT/or any other OS. You will see attempts.. but with good backups you should be off line for only a few hours. If you do get hacked make sure that you follow the code of ethics.. most hackers/crackers wont destroy more than they need to get their message up.. So for not killing your file system you should give copies of all the hacked files to 2600.com so that they can mirror it. They will get it anyways but its like saying " you got me.. but wait for next round"
Use shadow passwords. That way, a malicious web writer can't grab the encrypted passwords and try to break them. It's easy: "pwconv" is the (only) command to run if your system is relatively modern (this may be somewhat specific to the Linux implementation of the shadow password system?).
If you need to protect the users from each other, you might consider:
Some general purpose Linux/unix related security links:
Finally: Keep your system up-to-date with the latest official patches. Consider joining the BugTraq mailing list.
If you don't want a site hacked, *period*, I suggest you consider a CD-R based server. Let all development occur on, well, development machines, burn a copy of the static site, and have the dynamic material imported in from a backend database.
Lets see how easy it is to hack a server where not even *root* can modify the configuration files.
I'm still waiting for an entire Linux distribution I can boot off a CD-ROM using either a floppy drive or a web site to cache settings. It'll be significantly easier to deal with these CD Lockboxes once the various kernel configs for a semi slow medium serving mechanism are developed.
There will be a few issues with switchovers under a CD-ROM system, incidentally. Updates are no longer a matter of FTPing; it's more along the lines of using Fake(beautiful app) to have two identical servers doing failover for eachother.
Fairness dictates I remind the reader that, no, this isn't 100% effective--a remote root compromiser might still be able to link into the running(but binary non-modifiable) process and somehow redirect some pointer mechanisms to manipulate what files are distributed on the website, but that's orders of magnitude more difficult than echo "THIS SITE SUX" > index.html .
Keep in mind, if you have a backend writable database it's going to be the next target. Intrusion detection on high, keptain.
Email me or visit my site if you want to discuss all this stuff further. If you have experience with ARP/ICMP spoofing attacks, I need you to read something I'm in the process of putting together. Ahhhhh yes, I'm geeking out on security as of late. (Can you tell?)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://doxpara.netpedia.net
Once you pull the pin, Mr. Grenade is no longer your friend.
Here's a quick(??) checklist:
/etc/login.defs. It allows passwords longer than 8 characters (standard shadow limit), and to the best of my knowledge there are no password crackers which will crack MD5 hashed *NIX passwords. There's also lots of other fun stuff to mess with in login.defs, btw.
/etc/hosts.deny - this will drop all connections from systems where the connecting ip and dns do not resolve properly; e.g. if a connect from 10.1.1.1 comes in, and reverse-resolves to proxy.somenet.com, but proxy.somenet.com resolves to 192.168.1.1, the connection is dropped. This prevents DNS spoofing attacks.
/bin /sbin /usr/bin /usr/sbin - etc.
* Disable all the unused services. ftp, talk, biff, finger - the usual suspects. Make sure the inetd internal services (echo, chargen, discard, daytime, time) are disabled; there are some inetds that have overflow problems with these services, which will crash inetd.
* Shadow passwords.
* MD5 crypted passwords. Don't know if this is supported on RH, but Debian 2.0 or better does. This is a wonderful feature, it's settable in
* Strict firewall rules; allow only addresses that should be coming into your system (or network) in on only the interfaces configured for them. Reject anything else, and log it. Reject ports you don't use. When setting up firewall rules, use numeric IP addreses to prevent DNS spoofing attacks.
* Make sure the line `ALL: PARANOID' is in
* Think about a chroot()'d webspace. Make sure the chroot() jail is writable only by a privledged user.
* Never log in as root. Have a user account and use su or sudo.
* Strong passwords.
* Never ever perform a privledged operation (like su) over an insecure transport like telnet or rsh. ssh is your friend here.
* Think about mounting your root partition read-only to prevent trojans. Maybe also set the ext2 immutable flag (chattr +i files) on areas which should not be modified;
* Run a logwatcher which will filter your logs and mail suspicious entries to you. Abacus logwatcher is good. (http://www.psionic.com/abacus/) Set it up to page your alphapager if something funny happens. (All serious *NIX admins have alphapagers, right? right??)
* Write an init script to alphapage you when the system changes runlevels.
* Workstations make bad servers, and vice-versa. Don't use a server as your desktop machine.
* Once you have a stable configuration, leave it unless you must change something. (bug etc)
* BUGTRAQ
* Common sense.
I'll address the Linux part first, because I know the most about that.
/etc/inetd.conf and your rc scripts. Shadowed passwords, not allowing root login remotely (use su) and only having ssh for remote access spring to mind.
First off, do the obvious things like removing EVERYTHING you don't absolutely need from
Now, if thats still not enough, look into the firewall support. deny ICMP, and access to ssh from anything but your machine. The only port that anyone can connect to should be 80.
Finally, if you're getting hammered by the kiddies, you might want to look into things like Solar Designer's non-executable stack patch(its called secure-linux, and I think its at: www.false.com). Its not perfect, but its a great extra layer to stop the formulaic attacks. Also, things like StackGuard (a hacked GCC that generates code to try to avoid buffer overruns) may be helpful. If all this isn't enough, its time to break out the heavy iron.
Which brings us to OpenBSD. Most of the stuff I said above applys, except for instead of secure-linux, you just use StackGuard. And firewalling uses ipfilter.
No matter what you use, you want tripwire, and be sure to keep the database and the statically linked executable, and a safe kernel, on write-protected floppies.
CGI security i'll leave to someone more qualified than I, especially since there are many great resources on secure CGI programming techniques, and a few on secure apache CGI configuration.
Nothing will make a box 100% secure, but every little thing you do could prevent another attack, and eventually, the cost of attacking your server exceeds whatever gain the attacker would get.