Home Page
Linux Basics Debian Linux Installation Using Debian Packages Linux Modem Setup Setting Up A Network Setting Up DNS Servers Linux Internet Servers Linux LAN Servers Linux Database Server Linux Syslog Server Linux Fax Server Linux Web Cam Servers Linux Proxy/NAT Servers Linux Firewall Servers Linux Security Compiling Linux Programs Home Automation What Now?


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:


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 Top of page

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:


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:

Maximum Linux Security
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:


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. 


<IfModule security2_module>

# *** 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 "@validateByteRange 0 255"
  # Block Santy.A worm
  SecRule ARGS:highlight %27
  # Block drop table SQL injection attack
  SecRule REQUEST_URI "drop[[:space:]]table"
  # Only accept request encodings we know how to handle
  # we exclude GET requests from this because some (automated)
  # clients supply "text/html" as Content-Type
  SecRule REQUEST_METHOD "!^(GET|HEAD)$" chain
  SecRule REQUEST_HEADERS:Content-Type \
  "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
  # Do not accept GET or HEAD requests with bodies
  SecRule REQUEST_METHOD "^(GET|HEAD)$" chain
  SecRule REQUEST_HEADERS:Content-Length "!^$"
  # Require browser headers from all user agents
  SecRule "REQUEST_HEADERS:USER_AGENT|HTTP_HOST" "^$"
  # Require Content-Length to be provided with every POST request
  SecRule REQUEST_METHOD "^POST$" chain
  SecRule REQUEST_HEADERS:Content-Length "^$"
  # Don't accept transfer encodings we know we don't handle
  SecRule REQUEST_HEADERS:Transfer-Encoding "!^$"

</IfModule>
Once you get the file FTPed up to your server copy it into the /etc/apache2/conf.d directory so that Apache reads it when it starts. Don't forget to restart Apache after getting this file in place with the command:

/etc/init.d/apache restart

You can test it out to make sure it's working by entering a URL which contains the text of one of the "SecRule REQUEST_URI" entries. For example, if your server's IP address is 192.168.1.80 enter the following in a browser's address bar:

http://192.168.1.80/bin/uname

You should get the Apache "Forbidden" error page.

You can write a lot of your own rules, including only allowing certain types of traffic from certain addresses. If you want to allow for special access and get granular with your access control, check out the documentation at modsecurity.org.

Perimeter Security

The most common means of protecting a network is using a firewall (or two in the case of a DMZ which was illustrated back on the Firewall page). The biggest problem with firewalls is that people think they're more than they actually are. A firewall's major strength is protecting against traffic-based attacks (DoS, etc). If you let people into your network from the outside, the firewall has no way of differentiating between a legitimate user and a hacker. A firewall is not a substitute for strong OS and application security.

If you're going to use a firewall package on a Debian system, keep in mind that the firewall is the application. As such, a system-based firewall won't offer much security if the underlying OS isn't hardened. (This is why the NetMax commercial firewall product includes the OS piece. It allows them to ensure the OS is properly configured.)

If you want to have Internet servers or provide remote access using a VPN server, be sure to use a DMZ configuration with two firewalls. In cases where critical or confidential business information is at risk, use stateful firewalls and IDS (Intrusion Detection System) software.

An IDS has been referred to as the burglar alarm of the network. See our Snort page on how to set one up.

Physical Security

Unauthorized access to your servers can occur just as easily from the inside as the outside. Perhaps even more so since the internal organization is seen as less of a threat. While that may be (somewhat) true from a user perspective, the unauthorized use of the organization's facilities and hardware is a very real threat.

To most people, physical security means locking up the server hardware and hubs/switches. However, it goes far beyond that. It involves the entire physical plant, the systems that connect to it, and the office space those systems are located in. It even extends to the notebooks carried by your company's road warriors. Notebooks and PDAs get stolen all the time. And there's no telling who has access to the computers of those who dial-in from home where users have a tendency to check the "Remember password" box on their dial-up connections.

I have seen countless instances of organizations that spend all kinds of money on fancy security systems surrounding the rooms that house servers and other IT equipment and at the same time have network jacks in locations that anyone can get to without breaking a sweat. Someone could hook up a pocket-sized packet sniffer and in less than a minute have all the IP address information and maybe even some IDs and passwords they need. With all of the foot traffic in large companies at quitting time, it wouldn't take much for someone with a notebook to slip into a secluded office or cubicle and spend hours on your network with no one but the cleaning people to bother them.

Networks, by their very nature, mean you don't need to be phsically at a server to administrate that server. While IT operations typically don't have a lot of clout with a facility's security people, there are some infrastructure-related steps you can take to try and lock things down. Unplugging unused or publically-accessible network jacks at the cross-connects is one measure. Restricting users to logging in only on certain systems, whether they be identified by MAC address or a hostname, and only during certain hours is a start. Security-minded organziations are also setting up VPNs on internal networks and requiring that all Intranet Web traffic be SSL to guard against unauthorized sniffing.

And how many users do you know have their passwords written down on Post-It Notes stuck to their monitor or on a piece of paper inside a desk drawer? Biometric devices have dropped dramatically in price in the last two years. You can buy a hardware device that reads a fingerprint in order to authenticate users for a little over $100 now (U.are.U Pro from Digital Persona). Setting up certificate servers helps ensure that only authorized systems have access to network resources. They're not just for remote systems anymore.

That's not to say physical security of the servers and wiring closets isn't important. Just don't overlook the obvious. One organization was so proud of their fire-proof file room for all of their personnel records until I pointed out the room had a wooden door. A chain is only as strong as its weakest link. Do the doors to your server room or wiring closets open out? If so, it's probably just a matter of popping the hinge pins out and a door comes right off. Crawling over the top of a wall by popping out the panels in a suspended ceiling isn't all that tough either.

There are many steps you can take to secure the physical environment. Some are electronic, some are mechanical, and others are procedural. But nothing substitutes for common sense.


Be Proactive Top of page

Security is not a "set it and forget it" proposition. Because there are no absolutes, constant monitoring is essential. New attacks are being developed every day and if you're simply going to respond once an attack is discovered it's likely too late. Hackers will use DoS attacks, log alterations (provided they can gain access), and other means to disguise other, more intrusive, exploits. In many cases simply waiting for obvious evidence that you've been hacked means you'll never know you've been hacked. The hackers will sneak in, grab what they want, and sneak back out again covering their tracks as they go.

In short, any security plan that is reactive rather than proactive is pretty lame. In addition to the security measures mentioned above, there are several things you can do to be more proactive in ensuring security:


Where to learn more - The best of our bookshelves:

Hacking Linux Exposed
More info... 		    My first reaction to Hacking Linux Exposed was "Oh great, now there'll be a million more hackers trying to get into our systems". It's a veritable tutorial, including step-by-step commands, on how to use a gazillion different exploits to hack into systems. However, after further consideration we realized this book is a great resource. It not only tells you how to do things (so you can see if you can when going against your systems), but gives specific countermeasures to mitigate the risks. It also gives each exploit individual ratings for simplicity, popularity, and impact and then combines them into an overall "risk rating". Comprehensive is the one word that best describes this book. For instance, it doesn't just cover Web servers but gets into CGI and SSI threats as well. Information on how to obtain a lot of the hacking tools that are available is also given.


While it's unfortunate that society has produced the types of losers that make such measures necessary, there are steps you can take to protect yourself and your data. It's just that security has become an ever-growing aspect of network administration and this growth shows no signs of abating. Vigilance is as important a quality as technical expertise. Exercise it like your professional life depends on it, because it may.




Did you find this page helpful ?
If so, please help keep this site operating
by using our DVD or book pages.


Site, content, documents, original images   Copyright © 2003-2011   Keith Parkansky   All rights reserved
Duplication of any portion of this site or the material contained herein without
the express written consent of Keith Parkansky, USA is strictly prohibited.

This site is in no way affiliated with the Debian Project, the debian.org Web site, or
Software In The Public Interest, Inc. No endorsement of this site by the Debian Project
or Software In the Public Interest is expressed or implied. Debian and the Debian logo
are registered trademarks of Software In The Public Interest, Inc. Linux is a registered
trademark of Linus Torvalds. The Tux penguin graphic is the creation of Larry Ewing.

LIABILITY

IN NO EVENT WILL KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY OR BLUEHOST INCORPORATED OR ANY OF ITS' SUBSIDIARIES SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE, COMMONLY REFERRED TO AS THE "ABOUT DEBIAN" WEBSITE, OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. ALL INFORMATION, METHODS, HTML OR COMPUTER CODE IS PROVIDED STRICTLY "AS IS" WITH NO GUARANTY OF ACCURACY AND/OR COMPLETENESS. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.