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.
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 net.
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.)
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:
ALL: 127.
And of course /etc/hosts.deny would contain:
ALL: ALL
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.
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
requests.
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.
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.
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. While it's mostly
for posterity purposes now, it's a good idea to be familiar with SATAN
as a means to scan your machine or network, and fix the problems it
finds. Developed by Wietse
Venema, most notably the author of the Postfix mail server and
TCP Wrappers, it is still worth learning from how it works and how to
think like a security-minded administrator. Note that SATAN has not been
updated in quite a while, and some of the other tools below might do a
better job.
Issue 57 of Linux Gazette
has a nice summary of the available security scanners for Linux.
Nmap
("Network Mapper") is a free open source utility for network exploration
or security auditing. It was designed to rapidly scan large networks,
although it works fine against single hosts. Nmap uses raw IP packets in
novel ways to determine what hosts are available on the network, what
services (application name and version) those hosts are offering, what
operating systems (and OS versions) they are running, what type of
packet filters/firewalls are in use, and dozens of other
characteristics. Nmap runs on most types of computers and both console
and graphical versions are available.
EnGarde Secure
Linux includes NetDiff,
developed by Guardian Digital to detect changes in network status over a
period of time. This is vital to ensuring that DNS server changes, among
others, have not been made without authorization.
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
http://www.nessus.org
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 system.
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, the free intrusion detection
system (IDS), and can detect attacks on a network. EnGarde Secure Linux
includes the Internet
Defense and Detection System (IDDS) which can graphically
represent network intrusion attempts over time as well as in real
time.
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 http://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 http://www.postfix.org
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 upgrade now!
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.
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
firewall.
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
Packetstorm Security
using their search engine.
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 security.
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 dangers.
There is a much more secure replacement for NIS, called NIS+.
Check out the NIS HOWTO
for more information on NIS security.
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 Firewalls
HOWTO for more information on firewalls and Linux.
For current projects involving firewalling and Linux, visit the
Netfilter home page.
The National
Institute of Standards and Technology have put together an
excellent collection of documents on computer security, and are entirely
free. While not specifically geared towards Linux (or even open source),
they are authoritative and invaluable.
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.
iptables 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 protocols.
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:
