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.
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.
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://188.8.131.52/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.
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:
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@example.com 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
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:
/etc/hosts.equivfile. A properly configured system, using TCP Wrappers, offers much better control over which hosts and users are allowed access to the other machines on your network.
$HOME/.rhostsfiles. By properly configuring PAM, you can eliminate the risk of a user subverting system security by allowing unauthorized access from a remote system via a
.rhostsfile. This should be replaced by the functionally equivilent SSH file called
.shosts. If this is not possible, Wietse Venema wrote a more secure rsh and rlogin daemon replacement, available in the logdaemon package. You can find this at ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.tar.gz
/etc/exportsconfiguration. Be sure if you are exporting filesystems using NFS, be sure to configure
/etc/exportswith the most restrictive access possible. This means not using wildcards, not allowing root access, and exporting read-only wherever possible. Verify who can mount these filesystems using /usr/sbin/showmount -e localhost.
/etc/securettyfile for the list of tty's that root is permitted to login from. This should only include the local tty's, and never including pseudo-ttys (from a remote location). The absense of this file indicates root is permitted to login from anywhere. Use /bin/su or sudo, available at ftp://ftp.cs.colorado.edu/pub/sudo/
/etc/inetd.confand see what services are being offered by your inetd. Disable any that you do not need by commenting them out (# at the beginning of the line), and then sending your inetd process a SIGHUP. All services running from inetd should be wrapped using TCP Wrappers.
/etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past.
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.
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
actually symbolic links to the directory
/etc/rc.d/init.d. Renaming the files in the
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.
Most Linux distributions ship with tcp_wrappers ``wrapping'' all your
TCP services. A tcp_wrapper (known as
/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
telnet stream tcp nowait root /usr/sbin/in.telnetdTCP 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
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:
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
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.
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 <firstname.lastname@example.org> 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.
NFS is a very widely used file sharing protocol. It allows servers
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
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.
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
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
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.
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@example.com> 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.