Securing a Linux Web Server

The following are notes that I've taken while learning how to secure a Linux web server. As you read through security guides you begin to see that the only fool-proof way to secure a computer is to lock it in a safe and never turn it on. As long as you are running a server on the Internet you have to accept the fact that you are running some risks. A little bit of work and knowledege can help reduce those risks, but there is no such thing as a crack-proof system.

• Use strong passwords on all accounts
  Your password is your most important security tool. Passwords should be long (at least 8 characters), contain UpperAndLowercase letters, have both ch@r@cters and num8ers thrown in for good measure, and absolutely not be in any dictionary. I also prefer to use passwords that if seen in clear text are still not memorable. All users need to have strong passwords, but especially the root account.
• Use different passwords on different accounts
  If you are responsible for more than one system, server, or account, use a different password for each account. This may mean remembering a lot of passwords, but if one system is cracked you don't want all of the systems to be cracked.
• Test your passwords
  On an existing system start by running a password cracking utility to audit the passwords currently in use. Good utilities include John the Ripper and Crack. Run these "auditing" tools to see if anyone currently has a weak password. If they do, have them fix it.

  To ensure that new passwords are strong, configure Linux to run cracking tests on new passwords and allow only strong passwords to be use. This is done by adding the following lines to /etc/pam.d/passwd:
  

  • password     required     pam_cracklib.so retry=3 minlength=10
    pam_cracklib.so is a file. You may need to give the full address of the file, such as /lib/security/pam_cracklib.so (the location on Mandrake 9.0). The "retry=3" means the user is allowed three attemtpts to create a qualified password. "minlength=10" sets the minimum length of the password to 10 charactes. You can adjust the retries and minlength as needed.
  • password     required     pam_unix.so use_authtok md5
    This directs the system to use MD5 password hashes instead of the default DES hashes. Again, you may need to provided the full address to the file, such as /lib/security/pam_unix.so on Mandrake 9.0.
• Prohibit root logins
  Do not use the root account as a regular login account. Instead, use "su root" to accomplish tasks that require root permissions. To enforce the "do not log in as root" rule, edit /etc/securetty so that the only line in the file is "tty1". The securetty file lists what TTYs the root account is allowed to log in from.
• Set Up File Permissions
  Set the most restrictive file permissions that your services will allow. Make sure that the directory has restrictive permissions as well as the file. On a web server with multiple webmasters, create a webmaster group and make each user who needs write access to the web directories part of that group. Then, set the permissions so that only root and the webmaster group have write access to the web directories.
• Take Pictures
  If you don't know what "normal" looks like, it is hard to figure out when something is wrong. Before unleashing your server on the world, take a few pictures by running basic commands and piping the results into a text file. Keep copies of these files off the server, so a cracker can't edit them for you. The following are helpful tests to run:
  • netstat -l > filename
    Ports that currently have services listening
  • df > filename
    Amount of free disk space
  • ps -A> filename
    Processes currently running.
• Find out what ports are open
  Use a port scanning tool like nmap to run a port scan on your server, preferably from a different server. Make sure that the only ports you have open are those you want open. If you aren't sure what a port is for, check Kurt Seifried's port catalog. Note that port 113 is used to identify your computer to a requesting host. The "ident" service is bound to this port, and even if you are not using this service, the port should be responding, not completely closed. Closing the port can completely can make it difficult for other hosts to communicate with your computer.
• Turn off unneeded services
  By default Linux runs a number of services that you may not need. Turn off any services that you do not need and set them to stay off by default when the system is rebooted. For example, if your server is not working as a DNS server, turn off the "named" service.
• Close all unnecessary ports
  Use a firewall, or your iptables, to close off all the ports that are unnecessary. Mandrake Linux comes with a program called Shoreline Firewall, or Shorewall that configures iptables to close down the ports, which is easier than learning to configure iptables.

  If you are running both an FTP server and a firewall, you will run into issues. FTP is a bit goofy. It requires port 21 for connecting to the FTP server, but then it chooses another port for setting up data transfer, so it needs more than one port open to work correctly. In default setups, FTP randomly chooses what port it wants to use as the data transfer port, which makes firewalling essentially impossible. However, FTP can be configured to choose a port within a certain range of ports that you will leave open through the firewall. This is really the only way to use FTP with a firewall. You'll need to look into your FTP configuration for how to do this.

• Beware of telnet and FTP
  Both telnet and FTP transfer your login information via clear text over the Internet, making it a lot easier for folks sniffing your sessions to get a valuable login name and password. SSH is a secure replacement for telnet since it encrypts your information. Never use telnet; always use SSH instead. As for FTP, there really isn't a way to use FTP securely. You can create a secure FTP session through some SSH tricks, but it is more cumbersome than what many folks are willing to do. Be aware that FTP is insecure and NEVER connect as root, or any other privileged user, over FTP.
• Don't give unncessary information
  The more a cracker knows about your system, the easier it is for him to break in, so be very careful about how much information is available about your system and your network. For example, the default welcome web page (index.html) on most systems is full of information about what version of Linux and Apache you are running, as well as what modules you have installed. Be sure to delete this file as soon as possible. Information about your system is also commonly given as part of the login banners for telnet (which you shouldn't be running) and FTP. Edit these login banners so they don't tell the world what software you are running. For a ProFTP server, edit the file /etc/proftpd.conf by changing the "ServerName" information. Check any other services that you have running on your system and see if they give out unnecessary information. If so, edit their configurations so they don't tell the world where you are vulnerable.
• Run security scans before potential crackers do
  Scan from both outside the network and from within the system itself to find any other vulnerabilities that need to be addressed. A good scanner for network insecurities is Nessus. Some good scanners for local system security include the Linux Security Auditing Tool (LSAT), Tara, and NABOU.
• Delete unneeded CGI applications
  Some Linux distributions come with a number of CGI applications installed in the cgi-bin directory. Either delete these files or move them out of the cgi-bin directory. The only programs you should have in CGI are the ones you choose to put in there. You should never have an executable file available for anyone in the world to run on your server unless you know exactly what that file does and you fully trust that the file has been built securely.
• Configure running services securely
  For each service you run (web server, email server, DNS server, etc.) find out how to configure it securely. For some services one software tool may be more secure than another, so choose the more secure software. For example, Qmail is considered to have superior security to Sendmail, so consider using Qmail as your mail server.

  With any service you run, be sure to read more detailed information on how that service works, what weaknesses it exposes, and how to configure it to be secure. The more you understand these services, and the better configured they are, the more you can rest assured that your system will run smoothly.

Further Resources: