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."
the LASG is available here, a free 150+ page document on securing Linux.
-Kurt Seifried
Many SCSI hard drives have a write protect jumper. This will have the same effect as a CD, but be a lot less obvious to the potential cracker, especially to one who isn't top notch in the clue department.
'course, who knows what sort of undocumented SCSI mode changes can be done to your average modern drive. There might be a back door to re-enable writes.
At the end of the day, of course, everything you do is just one more hurdle and makes it that much less likely you get broken into; you cannot make a system perfectly secure without pulling all the plugs (and maybe that won't even be enough).
Also put the Deception Tool Kit on an old machine, preferably in a DMZ, and let the script kiddies think you're running a single machine and that it behaves differently than it really does. They have time to waste, so let them waste more time.
I will personally come to your house and cut your damn head off if you DENY all ICMP or ever tell anyone else to do the same!
Denying all ICMP breaks path MTU discovery and will cause weird random TCP behavior across the internet. Read the FAQs.
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"
Start with the basics: remove any modules you are NOT using. Be careful with your CGI useage. Make sure they don't get executed anywhere any user can write to.
:-)
Use ipchains to deny incoming packets that come in from outside interfaces with local network IPs. That includes denying traffic from your IP when it comes in from eth0. Block all the "private" ips (10.0.0.0/8, 192.168.0.0/16, etc.) which are coming in on outside IPs. That will stop most spoofs which rely on your system trusting itself dead in their tracks.
I run my little knowledgebase at mixdown.org and while the knowledgebase itself is not secure (anyone can read, write and edit articles), I feel the underlying system is quite secure. When I get the database stuff more functional, I'll tighten up access.
I'd appreciate anyone who finds holes to mail me. Also, if you want to screw around with the database a little, go ahead.
Andrew
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.
StackGuardk Guard
StackGuard is a compiler approach for defending programs and systems against "stack smashing" attacks. Stack smashing attacks are the most common form of security vulnerability. Programs that have been compiled with StackGuard are largely immune to stack smashing attack. Protection requires no source code changes at all. When a vulnerability is exploited, StackGuard detects the attack in progress, raises an intrusion alert, and halts the victim program.
http://www.cse.ogi.edu/DISC/projects/immunix/Stac
San Disk + IDE
An interface board has been developed which allows a CompactFlashTM card to be used as a boot device on a PC. It takes advantage of a feature of the CompactFlashTM Card that allows it to emulate an IDE hard disk drive.
http://www.tapr.org/tapr/html/Fcfa.html
Virtual-Services-HOWTO
Every network connection is made up of two IP address/port pairs. The API (Applications Program Interface) for network programming is called the Sockets API. The socket acts like an open file and by reading/writing to it you can send data over a network connection. There is a function call getsockname that will return the IP address of the local socket. Virtuald uses getsockname to determine which IP on the local machine is being accessed. Virtuald reads a config file to retrieve the directory associated with that IP. It will chroot to that directory and hand the connection off to the service. Chroot resets / or the root directory to a new point so everything higher in the directory tree is cut off from the running program. Therefore, each IP address gets their own virtual filesystem. To the network program this is transparent and the program will behave like nothing happened. Virtuald in conjunction with a program like inetd can then be used to virtualize any service.
Personal note: using virtual services allows to separate users from *real* system accounts that maybe they will never use, so you don't have to care about dictionary attacks against root or another attacks that willcompromise all the system.
And...
If you use ssh, firewall support, external logs (using the serial port and an old computer), keep all important data (electronic commerce transactions, a user database, etc.) on a different computer using SSL and if you use the last, stable and secure version of your favorite applications, you will have a very robust and secure system.
Regardless, one would be best off using FreeBSD; it has far fewer exploits than the slashdot-preferred Linux.
Multiple layers of security is best for any machine; redundancy is the absolute key for security. You don't just have one level of restrictions which could be possibly exploited or tricked. For example, for ssh, restrict hosts in the sshd_config file, and compile in libwrap support, and use ipfw. By those actions alone, ssh is amazingly more secure.
In terms of web-specific stuff, make sure to closely look over your httpd.conf to see what is available to your users. You should also make an educated decision about if you want to allow CGIs.
Overall: Stay up to date with software versions.
--
Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net
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.
They had a contest a few years back about trying to hack into a MacOS appleshareIP web server. The contest offered 10.000$ cash to whomever could crack the system, prove it and explain the process. Anything affecting only that one machine was allowed. Downing the server was not considered a crack, content had to change. There were no winner to the first run of the contest. However, and this led to a crack on the second contest, the server was only running the web server. Nothing more. I'm not even sure CGIs were allowed... The admins would update the server through a local appletalk network. Although in the end, if I remember properly, in the second contest, about one year after the initial one, someone cracked one of the new plugins added for additional functionalities; the real http server was never cracked. I'm not trying to argue that appleshareIP is a better product, nor even a good product, this was back at the beginning of ASIP 5. The product has evolved since then and its security features may have fallen a bit. However this does show that if there's no point of entry, except the strict minimum, on your server, then there is nothing to hack... But if you're trying to run all the latest web gizmos then you shouldn't be looking at security, just good backups. Hope this helps.
check /etc/inetd.conf and comment off the usual open services e.g. telnet, ftp, popxx, shell, login. install ssh and shadow the password file (redhat 5.x never used to do that -- run pwconv and grpconv). Check your system logs daily..install an updater to check for new bugfixes automatically (you get the rpm for it). Be really paranoid -- all good sysadmins are. Ensure no login account exists except for your account and root. never login as root - always su yourself and login via ssh from a trusted machine or your own webservers console.