Next
Previous
Contents
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 admin's 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:
ftptelnet (or ssh)- mail, such as
pop-3 or imap
identd
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 dialup 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.
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.
http://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.
http://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:
http://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 plugin setup for
new port-scanning tests. For more information, take a look at:
http://www.nessus.org
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 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.
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 from
http://www.sendmail.org.
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
Kernel Security 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. You can find more information about the
"smurf" attack at
http://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 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
http://www.rootshell.com using their search engine.
NFS is a very widely-used file sharing protocol. It allows servers
running nfsd and mountd to "export" entire filesystems
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 filesystems 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
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 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
filesystems.
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
http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html
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:
http://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.
http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html More information can also be found in the IP-Masquerade
mini-howto:
http://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:
http://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
http://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
http://csrc.nist.gov/nistpubs/800-10/main.html. Also of interest:
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, including:
- 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 at
http://www.rustcorp.com/linux/ipchains/HOWTO.html
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.
Next
Previous
Contents
|
