Linux Server and Network Security

The most dangerous threat to internal networks are Internet gateways. Gateways are systems (or other hardware devices) with a minimum of two network interfaces where one interface is connected to the Internet (via an ISP connection) and at least one interface is connected to an internal LAN segment. Just as a gateway allows traffic to go out from your LAN onto the Internet, it also allows traffic from the Internet onto your LAN. The trick is to only let the traffic you want onto your LAN, and it's no easy feat.

You could be legally liable if someone hacks their way into your LAN and steals confidential data (social security numbers, credit card numbers, etc) that you maintain on your clients or customers. Worms or trojans could be planted that send passwords or other sensitive information out onto the Internet to a waiting sniffer. The risks are many and the consequences could threaten the very existance of your company. It's not uncommon for large institutions like banks and insurance firms to decline pressing charges against a hacker simply because they don't want the negative press and loss of confidence they would suffer as the result of a public prosecution by a district attorney.

"Multi-homed" (multi-connection) systems such as gateways are not the only security risk. A server that is only connected to the Internet, such as a Web server, is also at risk of being hacked. You may not care if some hacker cracks his way in and defaces your Web pages. You just reload the pages. But there are other, more hideous, attacks that are not uncommon:

• Your server can be used as a base from which attacks on other systems can be launched.
• Your e-mail server could be used as a relay for spammers.
• Your system can be surreptitiously used as an IRC (chat) server or for some other band-width intensive application that steals performance from both your server and your Internet connection.
• Your could be the target of DoS (Denial of Service) attacks which renders your servers (e-mail or Web), and your Internet connection, useless.
• Internet servers that use SSL to collect sensitive information such as credit card numbers or account numbers and passwords can be targets of hackers in order to try and gain access to the devices where this data is stored. (SSL only protects in-transit HTTP traffic. It does nothing for operating system or server security.)

Addressing security issues is one of those cases where "an ounce of prevention is worth a pound of cure". A hacker could do untold damage if they get into your system or network. And because hackers learn their trade in underground electronic communities, if one finds a way into your system you can bet that they'll let everyone else know about it.

If your company has public address space with an available IP you may want to try a little test just for grins. Do a full-boat install of Debian (including all Internet-related apps you can think of) and put the system on the Internet. It doesn't need a domain name with a DNS record, just a static public IP address. Set it up with the Apache, Sendmail, wu_ftpd, telnet, and any other services running and just leave it sit there. Check the /var/log/messages file every week or so and see how long it takes for the hackers to find it and start playing around with it. When I tried this they took all of two weeks. Since there's no way of telling what they did during their visits, you'd be wise to totally wack the partitions on the hard-drive and do an install from scratch when you do want to re-use the system as a production server.

Setting up a system like this is actually a new security tool that's emerging. It's called setting up a "honey-pot". The hackers are drawn to the the honey-pot because it's the most responsive, and are drawn away from your production servers. Before you deploy your honey-pot you may want to hang a tape drive on the system and do a full backup so you can go back to square one once it gets compromised. Again, thre's no way to really know everything that a hacker may have done to your system once they get in so the only safe thing to do is start over. Monitoring your honey-pot on a regular basis will let you know when things are happening so you can keep an even closer eye on your production servers.

Don't always assume that the "untrusted" network you're trying to protect yourself from is the Internet. If you have VPNs or other types of network connectivity established with business partners or even other divisions within the same company, you must be watchful for unauthorized access attempts from these networks as well. "Trust no one" is a good rule to follow when it comes to system and network security.

Do Your Homework

Along with the benefits of having your own Internet servers comes the responsibility of being knowledgable on how to secure those servers. Covering this subject beyond anything other than a superficial manner is beyond the scope of any single Web page. Here we only present an overview of some of the common tools used to help secure an Internet-connected server. It is by no means comprehensive and should only serve as an introduction to the topic.

Security measures can be categorized into the following four broad classifications:

1. OS configuration - "hardening" the operating system
2. Application configuration - making sure the server applications you do make available do only what they're supposed to do
3. Perimeter security - configuring your network infrastructure with firewalls and DMZs
4. Physical security - only authorized users and systems should have access to the network infrastructure

Different publications may categorize things differently but that's of little consequence. The important thing is that doing so allows you to take a "divide and conquer" approach to addressing all of the various aspects involved in securing a network, its servers, and the information contained on them.

OS Configuration

Hardening the operating system involves many things are are not only operating system-specific, but may often vary from one "flavor" of an operating system to another. Typical steps include:

• Disabling all default accounts and groups that are not needed. When an operating system is installed it sets up quite a few user accounts and groups by default. (Try logging into your Debian system using the username news and see how far you can navigate around your system's file system and what files you can cat to the screen.) There's a line in the /etc/passwd file for each user. Each line contains different pieces of info separated by colons (:) with the last item being the user's default shell (typically the Bash shell). To disable user accounts, just change the default shell to /bin/false so they can't log in.
  
  
• Change your startup configuration so that only necessary services are running. Many services open TCP/IP "ports" which hackers find when running port scans against systems. (Many applications are responsible for starting services also.) Closing all unnecessary ports is a common practice. You can run a port scanner from another system against your server to see which ports are open.
  
  
• Configure file system security (using the chmod and chown commands) so that only the bare minimum of access to files and directories is allowed.
  
  
• Utilize strong (mixed case, alpha-numberic, long) passwords on accounts that are necessary.
  
  
• Don't use common names for groups that are given high levels access (ex: "admins").
  
  
• Use TCP wrappers (tcpd) to run Internet-related daemons and properly configure the hosts.allow and hosts.deny files to restrict access.
  
  
• Don't run a GUI if you don't need one and never leave a GUI running while the server isn't being used for an interactive console session.
  
  
• Log off of server consoles when they're not being used. This is especially important for Internet-connected systems.

There is a HOWTO on securing the OS on the Debian Web site at:
www.debian.org/doc/manuals/securing-debian-howto/
The installation routines for many Linux distributions set things wide open by default to reduce the number of technical support calls and e-mails they get. (The more wide open a system is the less likely it is that someone - or an application - will run into problems trying to perform a specific task or function.) As a result, most Linux systems are inherently insecure. Once you do make security-related changes, check to make sure that all functions of your applications still run the way they should.

Where to learn more - The best of our bookshelves:
More info...		Maximum Linux Security is the best security book I've found for those who do not have a lot of Linux experience. The first four chapters cover some of the basics of Linux from a security perspective, including the fundamentals of server administration. If you are going to set up an Internet server, get this book. The book not only covers what to do, but covers the theory behind why you are doing it. It also shows you how hackers work and provides links to the tools they use to break in. You would think that a book on server security would be pretty dry, but this book is an easy read.

Application Configuration

Some applications are insecure due to the defaults used during their installations and some are just inherently insecure. Telnet and ftp are two inherently insecure applications because passwords are transmitted over the wire as clear text.

The biggest threat to many applications is their vulnerability to "buffer overflow" attacks which usually results in the hacker having access to the system with the rights of whatever user account the application was running under.

The following are some general guidelines related to applications:

• Use more secure equivalents for insecure applications (ex: ssh instead of telnet, sudo in place of su, etc).
  
  
• Keep your applications up-to-date with the latest versions. Many releases are specifically developed to address security issues.
  
  
• Determine which ports an application opens up and see if they are absolutely necessary. If they aren't, shut them down.
  
  
• Check the application vendor's Web site for information on how to make the application more secure and for any news items and or patches that address newly-discovered security vulnerabilities.
  
  
• If you have a Web server, learn proper programming techniques to ensure that CGI scripts are secure and make sure the scripts you use utilize these techniques. Also acquaint yourself with the security issues related to Server Side Includes and any Web site interpreters you may be running (such as PHP or ASP).
  
  
• In the case of a Web server, if Web page updates are fairly infrequent, you could just edit the pages on the server using a text editor or use a floppy disk to "sneaker-net" the updated HTML files by mounting the floppy disk, copying the files into the DocumentRoot directory, and then unmounting the floppy. Either of these would eliminate the need to run an ftp server service and enabling an account for the person who maintains the pages.
  
  
• If you have an Apache Web server (or have a Web site that is hosted on a shared Apache Web server) and the US government's Titan Rain investigation has you considering blocking visitors from China (which we are now doing), you can configure Apache to deny access to your site from Chinese IP addresses (see my China blocking page for more information).
  
  
• Searching Google for the name of the application along with the word 'harden' will usually yield some helpful configuration information. For instance, Googling 'harden apache' will list some Web pages which tell you what modules you can rem out (in the /etc/apache/modules.conf file) to make your Apache installation more secure.

If all you want to do is set up a simple Web server (running Apache) then there are quite a few "applications" (OS utilities actually) that run by default that are not needed. They open ports and since each open port is a possible entry point into your server by a hacker, you don't want them open. I disable them by renaming their 'S' (startup) symlinks in the appropriate runlevel directory. Since Debian boots into runlevel 2 by default, we want to go into the runlevel 2 startup directory with the command:
cd /etc/rc2.d
There we'll find the symlink S20ssh which opens the port for secure remote console sessions. If you'll be physically at the console (keyboard and monitor), there is no need for remote access. To stop the SSH server service from needlessly opening a port we disable it by just renaming its symlink with the command:
mv S20ssh _S20ssh
You can do the same for S20exim4, S20lpd, and S21nfs-common. Now if you reboot your system and run the netstat -a command you'll see fewer open ports. One port that does remain open though is 'sunrpc'. That's the RPC portmap service and it is notorious for being the target of exploits. If you run the netstat -ap command you'll see that '/sbin/portmap' is the application that has the sunrpc port (port 111) open. NFS and some other applications need the RPC service. Apache does not. So for our simple Web server we can disable portmap. However, this service is called from two places so we need to rename both symlinks with the commands:
mv /etc/rc2.d/S18portmap /etc/rc2.d/_S18portmap
mv /etc/rcS.d/S43portmap /etc/rcS.d/_S43portmap
Note that disabling RPC will cause the 'nfs-common' service to fail at boot-up but that's OK. You shouldn't be mounting any network drives on a Web server anyway.

Now if you again reboot your system and run the netstat -a command you'll see only port 80 open (and possibly port 25 listening on 127.0.0.1 which is internal only).

Other daemons and services don't open ports but they're not needed either and they just use up memory. Two examples in the default installation that you can also rename are S89atd and, if your system isn't connected directly to a cable or DSL modem that uses PPPoE, S14ppp.

Because applications interact with the operating system, start processes, and accept input they can affect operating system security. Likewise, operating system security can affect an application's ability to function properly. Achieving maximum OS security while still retaining full application functionality is a balancing act.

This balancing act is evident when using "jails" or chroot jails. You can put any program or daemon in it's own jail. A chroot jail is a way of configuring the operating system so that the directory the application is running from appears to be the root of the entire file system. As such, the only directories the application can "see" or has access to are the ones it needs to run. That way, if an application does have a security flaw, the hacker exploiting that flaw won't have access to the entire file system.

For example, if you want to set up a DNS server be advised that BIND runs as root. As such, if a hacker exploited a security flaw in BIND they would have root access to the entire file system. By running BIND in a jail, the hacker would only have access to the BIND application directory.

The problem with jails is that they can be a pain to set up. ALL files that an application needs (library files, config files, etc.) or generates (data files, log files) have to reside within the jail. So if you were going to set up a jail for BIND in /var/lib/named you'd have to create /var/lib/named/etc (for config files) and /var/lib/named/var (for log files) directories under that directory. You also then need to create a user for the application and change ownership of the directories to that user. It may be a pain but it does isolate your file system considerably.

Securing Apache
This discussion of mod_security refers to mod_security 2.x on Apache 2.x.
mod_security 2.x only works with Apache 2.x. It is not backward compatible with Apache 1.x.
Back on our Internet Servers page we showed you how to change a couple security settings to reduce the amount of information about your server that is given out to potential hackers. However, this doesn't do anything for HTTP-targeted attacks.

If your firewall is properly configured to only allow port 80 traffic to your Web server there are still dangers that can come in on port 80, the most common being malformed URLs. There's an Apache IDS (Intrusion Detection System) module that can keep an eye out for suspicious and malformed requests and block them. The mod_security module is no longer included with Debian due to a licensing snit so you have to get it from the package maintainer. Add the following line to your /etc/apt/sources.list file:
http://etc.inittab.org/~agi/debian/libapache-mod-security2/ ./
After adding this line you'll need to run the commands:

gpg --keyserver pgpkeys.mit.edu --recv-keys C514AF8E4BA401C3 gpg --export -a C514AF8E4BA401C3 | apt-key add -

to pull down the maintainer's public key because the packages are digitally signed. Then run the update command:
apt-get update
to make apt aware of the packages available at this site. To see the name of the package that got added to the available inventory run the command:
apt-cache search mod-security
To install and enable the module simply enter the command:
apt-get install libapache-mod-security
This will not only add the module files to the /etc/apache2/mods-available directory but also adds the sym link to it in the /etc/apache2/mods-enabled directory and restarts Apache. Unfortunately that doesn't do us much good because there is no configuration file yet.

Below is a sample mod-security configuration file which you can use as is. The first part of the file configures the module's operation while the second part of the file adds the filtering rules it should use. You can copy/paste the following into a file with a name like "mod-security.conf" and then FTP that file (using ASCII mode) to your server.
Note that there are drastic differences between mod_security 1.x
configuration statements and mod_security 2.x configuration statements.
Most configuration examples available on the Web are for version 1.x.
The example below is for 2.x because that's the version available on
the package maintainer's site. If you want to customize your
configuration be sure to use the 2.x statements.

  # *** MODULE CONFIG   # Turn the filtering engine On   SecRuleEngine On   # Only log suspicious requests   SecAuditEngine RelevantOnly   # The name of the audit log file   SecAuditLog /var/log/apache2/modsec_audit.log   # Debug level set to a minimum (0) - 9 is max   SecDebugLogLevel 0   SecDebugLog /var/log/apache2/modsec_debug.log   # Should mod_security inspect POST payloads   SecRequestBodyAccess On   # By default log and deny suspicious requests   # with HTTP status 403   SecDefaultAction deny,log,status:403,phase:2      # *** FILTER RULES   SecRule REQUEST_URI /etc/passwd   SecRule REQUEST_URI /bin/ls   SecRule REQUEST_URI /bin/uname   SecRule REQUEST_URI /usr/bin/whoami   SecRule REQUEST_URI cd\x20/tmp   SecRule REQUEST_URI wget\x20   # Make sure that URL encoding is valid   SecRule ARGS "@validateUrlEncoding"   # Unicode encoding check   SecRule ARGS "@validateUtf8Encoding"   # Only allow bytes from this range   SecRule ARGS:text 

Posted in: