A Romp Through System Security
by Lumikant with help from Zarium
So you have your web server, you've got millions of hits on your web site every day, but you feel that ever-present nagging feeling inside that there's something missing. You're right, something is always missing - it's called security. "So, how do I secure this beast of mine here?" you may ask.
In this article, you'll see some ways of going about it. However, this is in no way a complete guide to security, but rather a cornerstone, or a foundation, in learning the basics on UNIX and UNIX variant security. Topics covered will include basic software security, hardware security, and general common sense techniques to prevent your system from getting owned. Well, that's enough yackin, let's get to hackin!
It's assumed you have general knowledge of a UNIX-based system. All the methods herein have been tested on a Slackware 7.1 system, as well as a Red Hat 6.2 system. These are two common distributions of Linux that are often used for web servers. We're also assuming that the computer the server is on is an up to date computer (at least 300 MHz, 128 MB of RAM) that can easily be used for a web server.
Hopefully you are running at least kernel 2.2.16, or a development version written around that kernel. Some of the methods in this article will be of no avail or may not work if the kernel is a lower version than that. A side note here - always get the latest stable kernel running on your system. With every new release comes new bug fixes, new updates, and support. Security isn't a one-time fix-all, but rather a careful ever-watching vigilance over your system/network.
This article is also written specifically for securing a web server that hosts a web site. If you intend to use the system for more than just that, be careful how you follow what is described in this text, because the methods may cripple other vital services that you'd need in other situations. It does however allow for optional POP3 e-mail usage through a local SMTP server. However, unless you need it, we recommend you drop that service. Being as just about anything is exploitable, it's only a matter of time until someone uses that service against you. (Yes, paranoia is a good thing here, guys.)
Finally, we are assuming you have local access to the server itself. If you can only admin the box remotely you will have to allow certain exploitable services that I would suggest disallowing and/or killing. Services such as ftpd and telnetd. After all, if you can dig into it remotely, that means somebody else most certainly can.
The basics of securing a web server are often the most neglected. Admins seem to be sloppy when it comes to this, the most important part of securing a server. What good are all the patches in the world, all the firewalls and other various software, if your kernel is exploitable or if other users have a great deal of access? Not very is the correct answer (give yourself a pat on the back if you got that one, by not too hard, you may pull a muscle.)
The Kernel
The kernel is the core of a *NIX system.
In fact, it is almost the entire system itself. The kernel is notated for its version. For example, the latest stable kernel at the time of this writing is 2.2.18. The version of a kernel has two parts, the kernel version (first and second fields) and the patch level (third field). Kernel 2.2.18, for example, means that 2.2 is the kernel version and 18 is the patch level of this specific kernel. If the kernel version itself is an odd number (i.e., 2.3), then it's a development kernel. This is not a stable release and should not be used unless you're a programmer or UNIX Guru. In that case, use it by all means, improve it, re-code it, work on it, and then tell everyone out there so they can help improve it too. Development versions oftentimes have many bugs that are easily exploitable. Unless you are a UNIX Guru, you should not run a development version of a kernel. The latest kernel can normally be found at in the Freshmeat archives (for Linux): www.freshmeat.net
Root Account
Another security issue admins often overlook is the usage of the root account.
For most work you do, the root account isn't needed. This is an important point to make. When you mess with the root account, you are playing with fire. You don't get pretty little error messages with UNIX like you do with Windows if you say "Delete this," It does it - no recycle bin.
It's an unnecessary risk, especially if you are running an Xterm. Not only can you make mistakes as root that can compromise system security, it also makes it more difficult to see when others have been accessing the root account, which is an important step in finding out who owned you.
The easiest way to avoid problems with root is to make another user account - using the adduser command - and give that account admin permissions. This will allow most actions, but will keep you from causing wanton damage to the system and make it easier to notice unwanted activity as root. It also makes for a safer Xterm environment, disallowing someone from crashing your entire system remotely through an Xterm buffer overflow.
Shell Accounts
Sometimes other people, friends, associates, and otherwise will want an account on your system, be it for their own web page, use of the services, etc. This is okay! It's one of the beauties of running a UNIX system - allowing multiple users to log in.
However, just like the Force, this has a dark side. If one of your friend's accounts is cracked, that person loses whatever privacy they had with their files and gives the intruder a launching place to root you. Give shell accounts out to only the most trusted of people. Another great aspect of Linux is the ability to use different group ID's. But all users into a group such as games so they have little to no access to exploitable system services.
A practice that is becoming more and more popular nowadays is to simply block out port 23, the Telnet login port, disallowing shell accounts. While this is a clever way of keeping you from being rooted, it also crimps the beauty and ability of UNIX systems.
Services
Now let's move on to many of the services and daemons that keep a UNIX system running well.
If the kernel is the base, the skeleton, of a UNIX system, then the services and daemons are the blood, muscles, and skin. They are what complete tasks, allow external users, post your web page, etc. They're also what allow the easiest entry into your system, so do be careful. Several services are very important to you if you're running a web server. The most important of these is the Hyper-Text Transfer Protocol Daemon, or httpd. This is the daemon that actually opens port 80 for HTTP traffic, thus allowing your site to be viewed. This service is not standard on a UNIX system. It comes with whatever web server you choose. This daemon in and itself is very secure.
Another daemon that is almost as necessary as the httpd is the crond.
This daemon watches all the programs on your cron tab (a list of programs that should always be running), and if one of them is down, inactive, absent, or frozen, it begins the program anew to make sure the program is running. If the initialization program for the web server is on the cron tab, whenever it crashes it will be started again, thus keeping the page up.
Many services and daemons however are unnecessary and are very insecure. These services should be killed and whenever possible disallowed from starting in the first place. These services are what allow most defacements and intrusions.
fingerd
The most unnecessary and dangerous service is the fingerd.
The finger daemon, running on port 79, is also useless. The sole purpose of it is to give out information about your users. As if that's not dangerous enough, it is also a very easy service to crash, most often through a buffer overflow, to give one a root access shell. Here is a finger response from a Windows NT webserver running Worldgroup:
This is an example of finger information from a UNIX based system:
As may be apparent to you, this offers quite a bit of information that could be used by someone wishing to infiltrate a system. It gives the shell type used (bash), home directory, real name (in some cases), last login, and last time the mail was read. Sometimes the plan can show even more important information. All of that coupled with the buffer overflow possibility makes this service very dangerous. It should be removed from your initialization files (usually /etc/inetd.conf - just comment out the lines that start this service. Other places you could look are the /etc/rc.d/ where several files may exist that manage your start-up services. This is going to be different with every flavor of UNIX out there.)
ftpd
Another service that is easily exploitable is the ftpd (File Transfer Protocol Daemon). This daemon allows people to access files on your system, as well as send files of their own. The danger in this is pretty self-explanatory. Although this protocol is often used and is reasonably secure, it is still a risk.
Depending on the version of ftpd you run, it may be possible to download password files and other sensitive materials through FTP, so make sure that you have users set and restricted enough to where they're not even allowed read access to the /etc directory in particular, or if you're paranoid enough, any directory other than their own and anything in the FTP directory.
One version of ftpd, WU-FTP, is the absolute worst ftpd one can run. It has so many exploitable bugs, it makes for a playground for any intruder who wishes to cause your server harm. People have been known to scan entire IP blocks (i.e., 209.23.*.*) for servers running this daemon, just for a little easy fun. Pretty sick, isn't it?
If you have other users or wish to update your server or web page remotely you will need the ftpd. Just make sure you have the newest version with any necessary patches. This will save you from a lot of trouble in the long run. If you're not going to be updating remotely then kill the ftpd. It's recommended you do all your updates right there on the server if possible.
telnetd
Another service that you won't need unless you plan on having extra users is the telnetd. This daemon, which runs on port 23, allows users to access a remote console on your system. This, while being a secure service itself, allows for many problems.
Basically, the only way to break in through the telnetd is with a simple brute-force attack. This throws as many passwords as it can to your computer, hoping one is right. If you have a strong password this attack is almost useless but there's still a chance that someone could gain access. If you are only offering web space to the people who have accounts on your system, then giving them access to Telnet is also unnecessary because this allows them to try all sorts of local exploits on your system. Local exploits often are more effective due to the easier access to the system. All in all, telnetd is unnecessary to be running unless you have users who want to use the shell services of your server. If you.don't have any of those users, the smartest thing to do would be kill the telnetd.
smtpd
Another service that is nice to have if you are offering e-mail services is the smtpd. This is the service that allows your server to send and receive mail. This service is secure in the way that it doesn't allow ready access to your system. However it's insecure in the way that it's easy to monitor traffic in and out of it. It also allows people to send e-mail without their true identity showing up.
These problems can be remedied by simply using the newest and patched version of SMTP, or Enhanced Simple Mail Transfer Protocol (ESMTP). Also, make sure any important e-mail you send is encrypted, preferably with PGP, so snoopers won't get any sensitive information.
Keep Watching Your System
Another very important part of keeping your system secure is keeping up with all the current bugs and exploits and, more importantly, their patches and fixes.
Something as simple as an outdated and buggy service can allow someone access to your system. Not only do these bugs, or exploits as they are most often called, sometimes provide access to your system, they can also allow malicious users to view sensitive data or crash your system. This, for the most part, can be easily avoided with simple measures such as always using the newest release of a service or piece of software.
Take Perl, for example. This service allows you and other users to make web-based (and other) scripts, including CGI, which can allow someone to gain root on your system if they have a shell. However, in the newest version of Perl, the SUID exploit, as it is called, has been patched.
Perl
Perl scripts, if not written carefully, can also allow users to view data. Because they run on a shell and interact with your system, they can often be "tricked" into displaying information. Also, if the files it refers to don't have stringent permissions, then someone could view files dealing directly with the script.
Logs
No, we're not talking about those things that you burn in the stove.
Logs are very, mucho, uber important to your system. With these handy things, you can see who broke in, from what IP address they were hailing, and at what time (among other things). You've got to log every connection, and for you paranoid people out there, every single packet that comes into your system. A firewall can accomplish this rather easily, but your system will also log failed Telnet logins.
If you notice that a certain IP attempted to login as a user several times and failed, then you might consider restricting that account and banning that IP address, being as someone is very likely to be trying to brute force their password. Your system also logs odd happenings. Pay attention to your logs.
If you get owned, you'd better be able to prove how when you go whining to the authorities. System logs are usually appended in a, file located in: /var/log/message
Passwords
One thing your users need to have is a strong password. This basically means that if their password is their first name (i.e., jerry), then you've got a problem. Let's say Jerry has a friend at school who wants to thrash a UNIX box somewhere. He knows Jerry's username on example.org is dude. So he goes in and brute-forces the password. Since he knows Jerry, he's going to guess things that are close, near, and dear to him, such as his girlfriend's name, his dog's name, his mother's name, his car, his favorite movie, etc.
Finally, the intruder enters jerry as the password and he's allowed in. From there he downloads local exploits and roots your sorry rear. Tsk tsk, if you would have been a good little sysadmin, this could have been avoided. You should have Jerry change his password every three months (i.e., every business quarter or whenever you feel it would be a good time, as long as it's somewhat often). Make sure Jerry's password isn't something like "laura" (maybe his wife's name?).
That's just dumb, because anyone who knows Jerry and is trying to guess his password is going to know Laura more than likely and try guessing that as his password. Make him use something off the wall and totally random, like 77x883492xxsofyBB25.8. The longer the password, the better, as it takes a dictionary creator and/or password cracker much longer to reach a password of this length than it does "laura". Also, even though it may be hard to remember, it's still feasible to create a password within a password.
For example, let's say your dog's name was Missy (like my mom's little dachshund, God rest her soul), and let's say you have a work ID number of 12345.
Try this for a password: 1m2i3s4s5y
This spells "missy" with 12345 strewn through it. Although this method is commonly used, it is a bit more difficult to crack.
Firewalls
Firewalls are super handy.
Make sure you're running one on the gateway in your network, otherwise you're asking for trouble. Firewalls block whatever you tell them to pretty much, including ICMP attacks, which are the most common when you're getting packeted. This can greatly reduce the risk of being packeted to death, but it doesn't mean that it won't happen. Nothing can fully defend against a Smurf attack, but you can sure slow one down by having a proper firewall installed. There are several firewall types you can get, ranging from software firewalls such as ConSeal PC FIREWALL, Freedom, or Linux IP Firewalling Chains (IPChains).
There are also hardware based firewalls and routers, the most prestigious of which are Cisco routers. Depending on how much money you wish to spend you can get varying degrees of protection. From packet routing, IP banning and looping to port protection, logging, and warnings. I have used several different firewalls, mostly software based and most are useless. For the most part they just log connection attempts. Although it is helpful to log, protection is still better.
For your UNIX-based system I would recommend IPChains and PortSentry. Collectively they offer a great deal of protection. IPChains routes harmful packets while PortSentry logs connections and warns you of possible attacks. PortSentry also negates most scans, stealth and otherwise.
Final Words
The last line of defense here are the services you're running.
If you're running SMTP, HTTP, Telnet, finger, etc., you're in deep crap, dude! You'd better get rid of every single one of those services, because they're all exploitable. Every service under the sun is exploitable, but these in particular because they're used so much more often and are far more likely to screw you rather than some of the other things.
Let's start with SMTP. Simple Mail Transfer Protocol isn't necessary unless you're running an e-mail service on your box, so get rid of it if at all possible. Another risk (in addition to getting rooted through it somehow) is that of spoofed e-mail. It's possible to Telnet to port 25 on a target and manipulate SMTP to send a fake e-mail to anyone in the world. Your best bet to prevent this is to block the service, or run ESMTP instead.
HTTP is probably going to be a necessity if you're running a web server - just make sure that you have all the patches and security info available that you possibly can get because no web server, no matter how rare or how well-coded it is, is totally secure. I recommend using Apache, since it's free and fairly stable. Just be sure to get all the patches and bug fixes for it. Telnet is a whole monster in and of itself. The service itself is secure, but not what it allows people to do. Having Telnet open is basically an invitation to get your butt kicked, so close it off and don't allow shell accounts.
Finally, as mentioned earlier, finger is a no-no. Anybody, even newbie wannabe hackers, can play with finger. It's basically there for one reason alone - to get you owned. Any buffer overflow will cause finger to give a user root access - it's the simplest type of attack. So make sure to block it out. If you want to get rid of these services, try editing /etc/inetd.conf and there are also some files in /etc/rc.d/ that you may want to have a look at too.
Hopefully after reading this you have at least a basic idea of how to secure your server. Although it-does not go incredibly in depth, it is more than enough to keep most "kiddie" hackers out of your system.