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 existence 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, there’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.

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.