8. 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
compromising physical or local security, 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.
8.1. Packet Sniffers
One of the most common ways intruders gain access to more systems on your
network is by employing a packet sniffer on a already compromised host. This
"sniffer" just listens on the Ethernet port for things like passwd and login and su in the packet stream and then logs the traffic after that.
This way, attackers gain passwords for systems they are not even attempting to
break into. Clear-text passwords are very vulnerable to this attack.
Example: Host A has been compromised. Attacker installs a sniffer. Sniffer
picks up admin logging into Host B from Host C. It gets the admins personal
password as they login to B. Then, the admin does a su to
fix a problem. They now have the root password for Host B. Later the admin lets
someone telnet from his account to Host Z on another
site. Now the attacker has a password/login on Host Z.
In this day and age, the attacker doesn't even need to compromise a system to
do this: they could also bring a laptop or pc into a building and tap into your
Using ssh or other encrypted password methods thwarts
this attack. Things like APOP for POP accounts also prevents this attack.
(Normal POP logins are very vulnerable to this, as is anything that sends
clear-text passwords over the network.)
8.2. System services and tcp_wrappers
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.
There are a number of ways to disable services under Linux. You can look at
your /etc/inetd.conf file and 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.
You can also remove (or comment out) services in your /etc/services file. This will mean that local clients will
also be unable to find the service (i.e., if you remove ftp, and try and ftp to a remote site from that machine it
will fail with an "unknown service" message). It's usually not worth the trouble
to remove services from /etc/services, since it provides
no additional security. If a local person wanted to use ftp even though you had commented it out, they would make
their own client that used the common FTP port and would still work fine.
Some of the services you might want to leave enabled are:
If you know you are not going to use some particular package, you can also
delete it entirely. rpm -e packagename under the Red Hat
distribution will erase an entire package. Under Debian dpkg
--remove does the same thing.
Additionally, you really want to disable the rsh/rlogin/rcp utilities,
including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from
being started in /etc/inetd.conf. These protocols are
extremely insecure and have been the cause of exploits in the past.
You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on Debian), and see if any of the servers
started in those directories are not needed. The files in those directories are
actually symbolic links to files in the directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian). Renaming the files in the init.d directory disables all the symbolic links that point
to that file. If you only wish to disable a service for a particular run level,
rename the appropriate symbolic link by replacing the upper-case S with a lower-case s, like this:
root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd
If you have BSD-style rc files, you will want to check
/etc/rc* for programs you don't need.
Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP
services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real server. 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 machine's services.
If you are a home dial up user, we suggest you deny ALL. tcpd also logs failed attempts to access services, so this
can alert you if you are under attack. If you add new services, you should be
sure to configure them to use tcp_wrappers if they are TCP-based. For example, a
normal dial-up user can prevent outsiders from connecting to his machine, yet
still have the ability to retrieve mail, and make network connections to the
Internet. To do this, you might add the following to your /etc/hosts.allow:
And of course /etc/hosts.deny would contain:
which will prevent external connections to your machine, yet still allow you
from the inside to connect to servers on the Internet.
Keep in mind that tcp_wrappers only protects services executed from inetd, and a select few others. There very well may be other
services running on your machine. You can use netstat -ta
to find a list of all the services your machine is offering.
8.3. Verify Your DNS Information
Keeping up-to-date DNS information about all hosts on your network can help
to increase security. If 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.
identd is a small program that typically runs out of
your inetd server. It keeps track of what user is running
what TCP service, and then reports this to whoever requests it.
Many people misunderstand the usefulness of identd,
and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way
of knowing if the data you get from the remote identd is
correct or not. There is no authentication in identd
Why would you want to run it then? Because it helps you out, and is
another data-point in tracking. If your identd is un
compromised, then you know it's telling remote sites the user-name or uid of
people using TCP services. If the admin at a remote site comes back to you and
tells you user so-and-so was trying to hack into their site, you can easily take
action against that user. If you are not running identd,
you will have to look at lots and lots of logs, figure out who was on at the
time, and in general take a lot more time to track down the user.
The identd that ships with most distributions is more
configurable than many people think. You can disable it for specific users (they
can make a .noident file), you can log all identd requests (We recommend it), you can even have identd
return a uid instead of a user name or even NO-USER.
8.5. Configuring and Securing the Postfix
The Postfix mail server was written by Wietse Venema, author of Postfix and
several other staple Internet security products, as an "attempt to provide an
alternative to the widely-used Sendmail program. Postfix attempts to be fast,
easy to administer, and hopefully secure, while at the same time being sendmail
compatible enough to not upset your users."
Further information on postfix can be found at the Postfix home and in the Configuring and Securing Postfix.
8.6. SATAN, ISS, and Other Network
There are a number of different software packages out there that do port and
service-based scanning of machines or networks. SATAN, ISS, SAINT, and Nessus
are some of the more well-known ones. This software connects to the target
machine (or all the target machines on a network) on all the ports they can, and
try to determine what service is running there. Based on this information, you
can tell if the machine is vulnerable to a specific exploit on that server.
SATAN (Security Administrator's Tool for Analyzing Networks) is a port
scanner with a web interface. It can be configured to do light, medium, or
strong checks on a machine or a network of machines. It's a good idea to get
SATAN and scan your machine or network, and fix the problems it finds. Make sure
you get the copy of SATAN from metalab or a reputable FTP or web site. There was a Trojan copy
of SATAN that was distributed out on the net. https://www.trouble.org/~zen/satan/satan.html. Note that SATAN
has not been updated in quite a while, and some of the other tools below might
do a better job.
ISS (Internet Security Scanner) is another port-based scanner. It is faster
than Satan, and thus might be better for large networks. However, SATAN tends to
provide more information.
Abacus is a suite of tools to provide host-based security and intrusion
detection. Look at it's home page on the web for more information. https://www.psionic.com/abacus
SAINT is a updated version of SATAN. It is web-based and has many more
up-to-date tests than SATAN. You can find out more about it at: https://www.wwdsi.com/saint
Nessus is a free security scanner. It has a GTK graphical interface for ease
of use. It is also designed with a very nice plug in setup for new port-scanning
tests. For more information, take a look at: https://www.nessus.org/
8.6.1. Detecting Port Scans
There are some tools designed to alert you to probes by SATAN and ISS and
other scanning software. However, if you liberally use tcp_wrappers, and look
over your log files regularly, you should be able to notice such probes. Even on
the lowest setting, SATAN still leaves traces in the logs on a stock Red Hat
There are also "stealth" port scanners. A packet with the TCP ACK bit set (as
is done with established connections) will likely get through a packet-filtering
firewall. The returned RST packet from a port that _had no established
session_ can be taken as proof of life on that port. I don't think TCP
wrappers will detect this.
You might also look at SNORT, which is a free IDS (Intrusion Detection
System), which can detect other network intrusions. https://www.snort.org/
8.7. sendmail, qmail and MTA's
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
Keep in mind that sendmail does not have to be running in order for you to
send mail. If you are a home user, you can disable sendmail entirely, and simply
use your mail client to send mail. You might also choose to remove the "-bd"
flag from the sendmail startup file, thereby disabling incoming requests for
mail. In other words, you can execute sendmail from your startup script using
the following instead:
# /usr/lib/sendmail -q15m
This will cause sendmail to flush the
mail queue every fifteen minutes for any messages that could not be successfully
delivered on the first attempt.
Many administrators choose not to use sendmail, and instead choose one of the
other mail transport agents. You might consider switching over to qmail. qmail was designed with
security in mind from the ground up. It's fast, stable, and secure. Qmail can be
found at https://www.qmail.org/
In direct competition to qmail is "postfix", written by Wietse Venema, the
author of tcp_wrappers and other security tools. Formerly called vmailer, and
sponsored by IBM, this is also a mail transport agent written from the ground up
with security in mind. You can find more information about postfix at https://www.tldp.org/www.postfix.org
8.8. Denial of Service Attacks
A "Denial of Service" (DoS) attack is one where the attacker tries to make
some resource too busy to answer legitimate requests, or to deny legitimate
users access to your machine.
Denial of service attacks have increased greatly in recent years. Some of the
more popular and recent ones are listed below. Note that new ones show up all
the time, so this is just a few examples. Read the Linux security lists and the
bugtraq list and archives for more current information.
SYN Flooding - SYN flooding is a network denial of service attack.
It takes advantage of a "loophole" in the way TCP connections are created. The
newer Linux kernels (2.0.30 and up) have several configurable options to
prevent SYN flood attacks from denying people access to your machine or
services. See Section
7 for proper kernel protection options.
Pentium "F00F" Bug - It was recently discovered that a series of
assembly codes sent to a genuine Intel Pentium processor would reboot the
machine. This affects every machine with a Pentium processor (not clones, not
Pentium Pro or PII), no matter what operating system it's running. Linux
kernels 2.0.32 and up contain a work around for this bug, preventing it from
locking your machine. Kernel 2.0.33 has an improved version of the kernel fix,
and is suggested over 2.0.32. If you are running on a Pentium, you should
Ping Flooding - Ping flooding is a simple brute-force denial of
service attack. The attacker sends a "flood" of ICMP packets to your machine.
If they are doing this from a host with better bandwidth than yours, your
machine will be unable to send anything on the network. A variation on this
attack, called "smurfing", sends ICMP packets to a host with your
machine's return IP, allowing them to flood you less detectably. You can find
more information about the "smurf" attack at https://www.quadrunner.com/~chuegen/smurf.txt
If you are ever under a ping flood attack, use a tool like tcpdump to determine where the packets are coming from (or
appear to be coming from), then contact your provider with this information.
Ping floods can most easily be stopped at the router level or by using a
Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST
packets that are too large to fit in the kernel data structures intended to
store them. Because sending a single, large (65,510 bytes) "ping" packet to
many systems will cause them to hang or even crash, this problem was quickly
dubbed the "Ping o' Death." This one has long been fixed, and is no longer
anything to worry about.
Teardrop / New Tear - One of the most recent exploits involves a
bug present in the IP fragmentation code on Linux and Windows platforms. It is
fixed in kernel version 2.0.33, and does not require selecting any kernel
compile-time options to utilize the fix. Linux is apparently not vulnerable to
the "newtear" exploit.
You can find code for most exploits, and a
more in-depth description of how they work, at https://www.rootshell.com/
their search engine.
8.9. NFS (Network File System)
NFS is a very widely-used file sharing protocol. It allows servers running
nfsd and mountd to "export" entire
file systems to other machines using NFS filesystem support built in to their
kernels (or some other client support if they are not Linux machines). mountd keeps track of mounted file systems in /etc/mtab, and can display them with showmount.
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 file systems. 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 root user 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 file systems.
If you must use NFS, make sure you export to only those machines that you
really need to. Never export your entire root directory; export only directories
you need to export.
See the NFS HOWTO for more information on NFS, available at https://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html
8.10. NIS (Network Information Service)
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). This allows users to change their password
once and have it take effect on all the machines in the NIS domain.
NIS is not at all secure. It was never meant to be. It was meant to be handy
and useful. 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" and "John the Ripper"
against your users' passwords. Also, it is possible to spoof NIS and do all
sorts of nasty tricks. If you must use NIS, make sure you are aware of the
There is a much more secure replacement for NIS, called NIS+. Check out the
NIS HOWTO for more information: https://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html
Firewalls are a means of controlling what information is allowed into and out
of your local network. Typically the firewall host is connected to the Internet
and your local LAN, and the only access from your LAN to the Internet is through
the firewall. This way the firewall can control what passes back and forth from
the Internet and your LAN.
There are a number of types of firewalls and methods of setting them up.
Linux machines make pretty good firewalls. Firewall code can be built right into
2.0 and higher kernels. The user-space tools ipfwadm for
2.0 kernels and ipchains for 2.2 kernels, allows you to
change, on the fly, the types of network traffic you allow. You can also log
particular types of network traffic.
Firewalls are a very useful and important technique in securing your network.
However, never think that because you have a firewall, you don't need to secure
the machines behind it. This is a fatal mistake. Check out the very good Firewall-HOWTO at your latest metalab archive for more
information on firewalls and Linux. https://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
More information can also be found in the IP-Masquerade mini-howto: https://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html
More information on ipfwadm (the tool that lets you
change settings on your firewall, can be found at it's home page: https://www.xos.nl/linux/ipfwadm/
If you have no experience with firewalls, and plan to set up one for more
than just a simple security policy, the Firewalls book by O'Reilly and
Associates or other online firewall document is mandatory reading. Check out https://www.ora.com/ for more
information. The National Institute of Standards and Technology have put
together an excellent document on firewalls. Although dated 1995, it is still
quite good. You can find it at https://csrc.nist.gov/nistpubs/800-10/main.html. Also of
8.12. IP Chains - Linux Kernel 2.2.x
Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling code
for the 2.2 kernel. It has many more features than previous implementations,
More flexible packet manipulations
More complex accounting
Simple policy changes possible atomically
Fragments can be explicitly blocked, denied, etc.
Logs suspicious packets.
Can handle protocols other than ICMP/TCP/UDP.
If you are currently using ipfwadm on your 2.0 kernel,
there are scripts available to convert the ipfwadm
command format to the format ipchains uses.
Be sure to read the IP Chains HOWTO for further information. It is available
8.13. Netfilter - Linux Kernel 2.4.x
In yet another set of advancements to the kernel IP packet filtering code,
netfilter allows users to set up, maintain, and inspect the packet filtering
rules in the new 2.4 kernel.
The netfilter subsystem is a complete rewrite of previous packet filtering
implementations including ipchains and ipfwadm. Netfilter provides a large
number of improvements, and it has now become an even more mature and robust
solution for protecting corporate networks.
is the command-line interface used to
manipulate the firewall tables within the kernel.
Netfilter provides a raw framework for manipulating packets as they traverse
through various parts of the kernel. Part of this framework includes support for
masquerading, standard packet filtering, and now more complete network address
translation. It even includes improved support for load balancing requests for a
particular service among a group of servers behind the firewall.
The stateful inspection features are especially powerful. Stateful inspection
provides the ability to track and control the flow of communication passing
through the filter. The ability to keep track of state and context information
about a session makes rules simpler and tries to interpret higher-level
Additionally, small modules can be developed to perform additional specific
functions, such as passing packets to programs in userspace for processing then
reinjecting back into the normal packet flow. The ability to develop these
programs in userspace reduces the level of complexity that was previously
associated with having to make changes directly at the kernel level.
Other IP Tables references include:
8.14. VPNs - Virtual Private Networks
VPN's are a way to establish a "virtual" network on top of some
already-existing network. This virtual network often is encrypted and passes
traffic only to and from some known entities that have joined the network. VPNs
are often used to connect someone working at home over the public Internet to an
internal company network.
If you are running a Linux masquerading firewall and need to pass MS PPTP
(Microsoft's VPN point-to-point product) packets, there is a Linux kernel patch
out to do just that. See: ip-masq-vpn.
There are several Linux VPN solutions available:
See also the section on IPSEC for pointers and more information.