Next Previous Contents

3. Network Security

Network security is becoming more and more important as people spend more and more time connected. Compromising network security is often much easier than physical or local, and is much more common.

There are a number of good tools to assist with network security, and more and more of them are shipping with Linux distributions.

3.1 Windows Networking

Most likely your network will also include Microsoft clients, presumably using either NetBIOS or other inheriently insecure networking protocols.

Among other things, NetBIOS is the protocol Microsoft uses to publicize share names, user names, and host names within the network.

Disabling NetBIOS on any Windows workstations is a prudent idea, as is blocking TCP and UDP ports 137 through 139 on your border routers or firewalls.

A detailed discussion on the actual reasons for this insecurity is available in a paper written by Hobbit, and can be found at his site here http://avian.org:4687/web1/hak/cifs.txt

Unfortunately, disabling NetBIOS also will disable any Remote Access Service it may be offering, as well as browsing (Network Neighborhood). If you must retain your NT server on your network, you may consider two NICs in the machine, one outbound via TCP/IP and one internal only. Disable NetBIOS binding to the TCP/IP side. This keeps enterprising folks from poking into the network via TCP/IP, then using various NET commands to gather network information.

The hacker group called l0pht have written a utility similar to how Crack works on UNIX, called l0phtcrack and is available at their site http://www.l0pht.com as is other generally useful information.

The file security_level.txt, distributed with SAMBA, discusses the various security levels that can be set using SAMBA, including encrypted passwords, server security, share-level security, and user security. It does a good job of explaining the general security concerns you must deal with.

The security research group called Rhino9, have also put together in depth information on the NetBIOS protocol and interface. You can find it at http://207.98.195.250/texts/netbios.doc

Internet Security Systems also produces a document on Windows file sharing security, and is available here http://www.iss.net/vd/fileshare.html This document, titled File Sharing: Unknown Dangers on Your Network, helps to describe some of the security issues you should be aware of, and just how insecure Windows 95 really is. It is a good overview, whereas Hobbit's document is more of a low-level description at the protocol level.

3.2 Identify Gateway Machines

Special attention should be paid to gateway or firewall systems, as they usually control access to the services running on the entire network. Such gateways should be identified, its function within the network shouild be assessed and owners or administrators should be identified. These hosts, often referred to as ``bastion hosts'' are a prime target for an intruder. They should be some of the most fortified machines on the network.

Be sure to regularly review the current access policies and security of the system itself.

These ``systems'' should absolutely only be running the services necessary to perform it's operation. Your firewall should not be your mail server, web server, contain user accounts, etc. Some of the things you should check for, and absolutely fortify on these hosts include:

3.3 Network Monitoring

It is important to keep aware of the status of your network, so you can not only detect when there is an intrusion, but when there is abnormal system activity, such as system load, increased disk usage, slower network, etc. There are many tools available for network monitoring, most of which were developed on other platforms first, then ported to Linux.

See the COAST archives, available at http://www.cs.purdue.edu/coast/hotlist/ for network monitoring tools.

Matthew Franz [email protected] has put together a Linux distribution that runs on two or three floppies, and includes many of the tools necessary to probe a network and the services it has available. This sounds like a great method in which to test your current security policy, as well as find otherwise unknown vulnerabilities. You can find the latest version, as well as more information, at http://www.txdirect.net/users/mdfranz/trinux.html

3.4 Network Configuration Files

Improperly configured network services and configuration files can lead to a system lacking full control over its services. You can configure your systems to be secure, yet still offer the services necessary. As a general rule:

The best method of configuration here is to only enable the services in which the box is intended to serve. Network-based exploits are equally as common as other forms of exploits, and they are performed by finding weaknesses in services, or poorly configured services.

3.5 Check for Poor Topology Configuration

Poor network configurations can also lead to a very difficult intrusion to track. Protecting the ``front door'' with a very well configured firewall will not prevent someone from entering through the ``back door'' via the modem bank with poor authorization.

3.6 Disable Unnecessary and Unauthorized Services

Before you put your Linux system on ANY network the first thing to look at is what services you need to offer. Services that you do not need to offer should be disabled so that you have one less thing to worry about and attackers have one less place to look for a hole.

You should check your /etc/rc.d/rcN.d, where N is your systems run level and see if any of the servers started in that directory are not needed. The files in /etc/rc.d/rcN.d are actually symbolic links to the directory /etc/rc.d/init.d. Renaming the files in the init.d directory has the effect of disabling all the symbolic links in /etc/rc.d/rcN.d. If you only wish to disable a service for a particular runlevel, rename the appropriate file with a lower-case ``s'', instead of the upper-case ``S'', such as in S45dhcpd.

If you have BSD style rc files, you will want to check /etc/rc* for programs you don't need. The Red Hat distribution includes tksysv, a graphical program to change what runlevel a particular server runs in. The newer distributions also include linuxconf, which can also do this.

Additionally, machines on your network running unauthorized services can create an opportunity for a cracker to gain access to the system. Regular port scanning of your machines, as well as running network security scanning tools, can help to find these potential exploits before an intruder does.

3.7 Monitoring Network Services with TCP Wrappers

Most Linux distributions ship with tcp_wrappers ``wrapping'' all your TCP services. A tcp_wrapper (known as /usr/sbin/tcpd) is invoked from /sbin/inetd instead of the real service, such as telnet or ftp. tcpd then checks the host that is requesting the service and either executes the real server or denies access from that host. tcpd allows you to restrict access to your tcp services. You should make a /etc/hosts.allow and add in only those hosts that need to have access to your machines services.

By making simple changes to the inetd configuration file, /etc/inetd.conf you can monitor and control incoming requests to network services. Such a modification might look like the following:

Typical 

        telnet  stream   tcp   nowait root /usr/sbin/in.telnetd
TCP Wrappers 
        telnet  stream   tcp   nowait root /usr/sbin/tcp /usr/etc/in.telnetd

In default mode the wrappers report the name of the client host and of the requested service. Be sure you have syslogd configure properly to ensure correct logging.

As no information is exchanged between the wrappers and the client or server applications there is no overhead on the actual conversation between the client and server applications occurs.

Additionally, you can configure:

3.8 Running Services in a chroot Environment

Several network services can now be configured to run in a restricted environment, called a ``chroot jail''. This is an isolated environment seperated from the ``real'' operating system. Services such as Apache or bind can be operated in this environment. A special root directory is created, with a complete installation of all programs and libraries necessary to execute the service. The intention is to prevent someone from obtaining root privilege on the ``real'' operating system, due to a bug in the service that is operating in the chroot jail.

This should not be treated as a panacea, however. It may help to restrict a process' filesystem access, but it doesn't affect its ability to make privileged system calls (e.g. init_module, modify_ldt, bind to a priviliged port, etc.) So ultimately a root process can break out of a chroot environment; it just makes the necessary shellcode more involved than just ``exec("/bin/sh")''. You can find more information on it's advantages and disadvantages at http://www.ssc.com/lg/issue30/tag_chroot.html This isn't explicitly a chroot discussion, but is helpful, nevertheless.

3.9 Domain Name Service (DNS) Security

Keeping up-to-date DNS information about all hosts on your network can help to increase security. In the event of an unauthorized host becomes connected to your network, you can recognize it by its lack of a DNS entry. Many services can be configured to not accept connections from hosts that do not have valid DNS entries.

Descriptive hostnames are just as useful to attackers as they are to internal users. Host names such as ``firewall.mydomain.com'' is obvious to an attacker, as is ``ns.mydomain.com''. These are likely to be prime targets to an attacker. A machine named ``fred.mydomain.com'' likely indicates a normal user's PC, which is also least likely to have an updated security mechanism installed, making it also a prime target.

Keep conscious of possible DNS spoofing. You can find more information on this in the Exploits section of this document.

Further information on securing DNS can be obtained from http://www.psionic.com/papers/dns-linux.html

Cricket Liu and Paul Albitz, the authors of the famed DNS and BIND O'Reilly book, contributed an article on Sun World with hints on how to secure DNS. You can find it, as well as some other excellent general security information at http://www.sunworld.com/swol-11-1997/swol-11-bind.html which discusses information on how to prevent being DNS spoofed.

Additonally, BIND can now successfully be run in a chroot() environment. John A. Martin <[email protected]> has put together a set of Red Hat packages that can be used to install BIND in a chroot jail. You can find more information on this available at ftp://ftp.tux.org/pub/tux/jam/

Be sure to configure a separate user for BIND. This not only restricts the amount of damage an intruder can do after exploiting a security hole in BIND, but also allows administration of the zone files without having to be root. This is generally a good practice, and more packages are configured for doing this more easily than before possible.

3.10 Network File System (NFS) Security

NFS is a very widely used file sharing protocol. It allows servers running nfsd(8) and mountd(8) to ``export'' entire filesystems to other machines with nfs filesystem support built-in to their kernels (or some other client support if they are non Linux machines). mountd(8) keeps track of mounted filesystems in /etc/mtab, and can display them with showmount(8).

Many sites use NFS to serve home directories to users, so that no matter what machine in the cluster they login to, they will have all their home files.

There is some small amount of ``security'' allowed in exporting filesystems. You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files. This is only a small hindrance to an attacker that has access to mount your remote filesystems.

If you must use NFS, make sure you export to only those machines that you really need to export only. Never export your entire root directory, export only directories you need to export and export read-only wherever possible.

Filter TCP port 111, UDP port 111 (portmapper), TCP port 2049, and UDP port 2049 (nfsd) on your firewall or gateway to prevent external access.

The NFS HOWTO also discusses some of the security issues with NFS, and it is available at http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html for more information on NFS.

3.11 Network Information Service (NIS)

Network Information service (formerly YP) is a means of distributing information to a group of machines. The NIS master holds the information tables and converts them into NIS map files. These maps are then served over the network, allowing NIS client machines to get login, password, home directory and shell information (all the information in a standard /etc/passwd file), among other information.

NIS is not at all secure. It was never meant to be. It was meant to be handy and useful. Not only was it not intended to be secure, it also has characteristics which inherently make it insecure. Among these are:

Anyone that can guess the name of your NIS domain (anywhere on the net) can get a copy of your passwd file, and use Crack against your users passwords.

If you must use NIS, make sure you are aware of the dangers.

Control the use of /etc/netgroup file for NIS systems. Explicitly define which hosts and which users can connect from a known list of machines.

There is a much more secure replacement for NIS, called NIS+. Check out the NIS HOWTO for more information, available at http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html

3.12 File Transport Protocol (FTP)

The Washington University FTP server is the default server on Linux distributions. It has the ability to run in a chroot environment, thus (theoretically) protecting the real root environment, limiting the damage an exploit can do.

FTP sites are easily misconfigured, and doing so can lead to a false sense of security, as well as easily exploitable holes. Attackers can use a misconfigured site to transfer pirate software, gain remote access, corrupt downloadable files, cause a denial of service, among other misuses.

Be sure to disable FTP entirely if you don't have any reason to leave it enabled (such as replacing it with ssh) and definately enable quotas on the FTP filesystem. Additionally, disable anonymous FTP access if it is not necessary.

3.13 Simple Mail Transport Protocol (SMTP)

One of the most important services you can provide is a mail server. Unfortunately, it is also one of the most vulnerable to attack, simply due to the number of tasks it must perform and the privileges it typically needs.

If you are using sendmail, it is very important to keep up on current versions. Sendmail has a long long history of security exploits. Always make sure you are running the most recent version. http://www.sendmail.org

An alternative to sendmail is qmail, which alledges to be more secure, and easier to configure. qmail was designed with security in mind from the ground up. It's reported that it's fast, stable and secure. You can find it at http://www.qmail.org

Wietse Venema <[email protected]> is writing a mail server that is still in testing stages, but also promotes improved security. You can find out more about vmail at http://www.vmailer.org

Significant improvements in preventing unsolicited bulk email (spam) have been made with recent versions of the available SMTP servers. Starting with sendmail-8.9, anti-relaying is enabled by default, which prevents a remote host from using your network and mail servers for forwarding mail to other hosts. Additional filters are also available for preventing spam.


Next Previous Contents