Linux Security HOWTO
Kevin Fenzi, kevin@scrye.com
v0.9.5, 1 March 1998
This document is a general overview of security issues that face the
administrator of linux systems. It covers general security philosophy
and a number of specific examples of how to better secure your linux
system from intruders. Also included are pointers to security related
material and programs. NOTE: This is a beta version of this document.
Improvements, constructive criticism, additions and corrections are
gratefully excepted. Due to my despam filter, you will need to mail
me to get a despam key to mail me. Sorry for the trouble. To avoid
this make sure you have "linux", "security" or "HOWTO" in the subject
line of your mail.
1. Introduction
This document covers some of the main security issues that affect
linux security. General philosophy and net born resources are
discussed.
A number of other HOWTO documents overlap with security issues, and
those have been pointed to wherever appropriate.
This document is NOT meant to be a up to date exploits document. Large
numbers of new exploits happen all the time. This document will tell
you where to look for such up to date information, and some general
methods to prevent such exploits from taking place.
1.1. New versions of this document
New versions of this document will be periodically posted to
comp.os.linux.answers. They will also be added to the various
anonymous FTP sites who archive such information, including:
ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
In addition, you should generally be able to find this document on the
Linux Worldwide Web home page via:
http://sunsite.unc.edu/mdw/linux.html
Finally, the very latest version of this document should also be
available in various formats from:
http://scrye.com/~kevin/lsh/
1.2. Feedback
All comments, error reports, additional information and criticism of
all sorts should be directed to:
kevin@scrye.com
NOTE: I use the despam filter to filter all my mail. This means that
if you are not known to me, your mail will bounce with a notice to re-
send with a provided "key" in the subject. I regret the trouble this
causes, but since I get 20-30 spam mails a day, I have to do
something. Please re-send your message with the "key" in the subject
and I will read your mail. You can also avoid this step by making sure
you put "linux" "security" or "HOWTO" in the subject of your mail.
http://scrye.com/~kevin/
1.3. Disclaimer
No liability for the contents of this documents can be accepted. Use
the concepts, examples and other content at your own risk.
Additionally, this is an early version, with many possibilities for
inaccuracies and errors.
A number of the examples and descriptions use the RedHat(tm) package
layout and system setup. Your mileage may vary.
As far as I know, only programs that under certain terms may be used
or evaluated for personal purposes will be described. Most of the
programs will be available complete with source under GNU-like terms.
1.4. Copyright information
This document is copyrighted (c)1998 Kevin Fenzi and distributed under
the following terms:
� Linux HOWTO documents may be reproduced and distributed in whole or
in part, in any medium physical or electronic, as long as this
copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions.
� All translations, derivative works, or aggregate works
incorporating any Linux HOWTO documents must be covered under this
copyright notice. That is, you may not produce a derivative work
from a HOWTO and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the Linux HOWTO coordinator at
the address given below.
� If you have questions, please contact Greg Hankins, the Linux HOWTO
coordinator, at
gregh@sunsite.unc.edu Finger for phone number and snail mail address.
2. Overview
This document will attempt to explain some procedures and commonly
used software to help your linux system be more secure.
The first thing to keep in mind is that there is never any such thing
as a "completely" secure computer system. All you can do is make it
increasingly difficult for someone to compromise your system. For the
average home linux user, not much is required to keep the causal
cracker at bay. For high profile linux users (banks,
telecommunications companies, etc) much more work is required.
Another factor to take into account is that the more you increase your
system security, the more intrusive your security becomes. You need to
decide where in this balancing act your system is still usable and yet
secure for your purposes. For instance, you could require everyone
dialing into your system to use a call back modem to call them back at
their home number. This is more secure, but if someone is not at home,
it makes it difficult for them to login. You could also setup your
linux system with no network or connection to the Internet, but this
makes it harder to surf the web. If you are a large to medium sized
site, you should establish a "Security Policy" stating how much
security is required by your site and what auditing is in place to
check it.
This document has been segregated into several sections. They cover
several broad kinds of security issues. The first, physical security,
covers how you need to protect your physical machine from tampering.
The second describes how to protect your system from tampering by
local users. The third, network security, describes how to better
secure your linux system from network attacks. The next discusses what
to do when you detect a system compromise in progress or detect one
that has recently happened. Then links to other security resources are
enumerated, and finally a few closing words.
The two main points to realize when reading this document are:
� Be aware of your system. Check system logs such as
/var/log/messages and keep an eye on your system, and
� Two, keep your system up to date by making sure you have installed
the current versions of software and have upgraded per security
alerts. Just doing this will help make your system markedly more
secure.
3. Physical Security
The first "layer" of security you need to take into account is the
physical security of your computer systems. Who has direct physical
access to your machine? Should they? Can you protect your machine from
their tampering? Should you?
How much physical security you need on your system is very dependent
on your situation, and/or budget.
If you are a home user, you probably don't need a lot (although you
might need to protect your machine from tampering by children or
annoying relatives). If you are in a Lab environment, you need
considerably more, but users will still need to be able to get work
done on the machines. Many of the following sections will help out. If
you are in a Office, you may or may not need to secure your machine
off hours or while you are away. At some companies, leaving your
console unsecured is a termination offense.
Obvious physical security methods such as locks on doors, cables,
locked cabinets, and video survailance are all a good idea, but beyond
the scope of this document. :)
3.1. Computer locks
Many more modern pc cases include a "locking" feature. Usually this
will be a socket on the front of the case that allows you to turn an
included key to a locked or unlocked position. Case locks can help
prevent someone from stealing your pc, or opening up the case and
directly manipulating/stealing your hardware. They can also sometimes
prevent someone from rebooting your computer on their own floppy or
other hardware.
These case locks do different things according to the support in the
motherboard and how the case is constructed. On many pc's they make it
so you have to break the case to get the case open. On some others
they make it so that it will not let you plug in new keyboards and
mice. Check your motherboard or case instructions for more
information. This can sometimes be a very useful feature, even though
the locks are usually very low quality and can easily be defeated by
attackers with locksmithing.
Some cases (most notably sparcs and macs) have a dongle on the back
that if you put a cable through attackers would have to cut the cable
or break the case to get into it. Just putting a padlock or combo lock
through these can be a good deterrent to someone stealing your
machine.
3.2. BIOS Security
The BIOS is the lowest level of software that configures or
manipulates your x86 based hardware. LILO and other linux boot methods
access the BIOS to determine how to boot up your linux machine. Other
hardware that linux runs on has similar software (OpenFirmware on macs
and new suns, sun boot prom, etc...). You can use your BIOS to prevent
attackers from rebooting your machine and manipulating your linux
system.
Under linux/x86 many pc bioses let you set a boot password. This
doesn't provide all that much security (bios can be reset, or removed
if someone can get into the case), but might be a good deterant (ie it
will take time and leave traces of tampering).
Many x86 bioses also allow you to specify various other good security
settings. Check your bios manual or look at it the next time you boot
up. Some examples are: disallow booting from floppy drives and
passwords to access some bios features.
On Linux/Sparc, your SPARC eeprom can be set to require a boot-up
password. This might slow attackers down.
NOTE: If you have a server machine, and you setup a boot password,
your machine will not boot up unattended. Keep in mind that you will
need to come in and supply the password in the even of a power
failure. ;(
3.3. Boot loader Security
The various linux boot loaders also can have a boot password set.
Using lilo take a look at the "restricted" and "password" settings.
"password" allows you to set a bootup password. "restricted" will let
the machine boot _unless_ someone specifies options at the lilo:
prompt (like 'single').
Keep in mind when setting all these passwords that you need to
remember them. :) Also remember that these passwords will mearly slow
the determined attacker.
If anyone has security related information from a different boot
loader, I would love to hear it. (grub, silo, milo, linload, etc).
NOTE: If you have a server machine, and you setup a boot password,
your machine will not boot up unattended. Keep in mind that you will
need to come in and supply the password in the even of a power
failure. ;(
3.4. xlock and vlock
If you wander away from your machine from time to time, it is nice to
be able to "lock" your console so that no one tampers with or looks at
your work. Two programs that do this are: xlock and vlock.
Xlock is a X display locker. It should be included in any linux
distributions that support X. Check out the man page for it for more
options, but in general you can run xlock from any xterm on your
console and it will lock the display and require your password to
unlock.
vlock is a simple little program that allows you to lock some or all
of the virtual consoles on your linux box. You can lock just the one
you are working in or all of them. If you just lock one, others can
come in and use the console, they will just not be able to use your
vty until you unlock it. vlock ships with redhat linux, but your
mileage may vary.
Of course locking your console will prevent someone from tampering
with your work, but does not prevent them from rebooting your machine
or otherwise disrupting your work.
3.5. Detecting Physical Security compromises.
The first thing to always note is when your machine was rebooted.
Since linux is a robust and stable OS, the only times your machine
should reboot is when YOU take it down for OS upgrades, hardware
swapping, or the like. If your machine has rebooted without you doing
it, a trouble light should go on. Many of the ways that your machine
can be compromised require the intruder to reboot or power off your
machine.
Check for signs of tampering on the case and computer area. Although
many intruders clean traces of their presence out of logs, it's a good
idea to check through them all and note any discrepancy.
Some things to check for in your logs:
� Short or incomplete logs.
� Logs containing strange timestamps.
� Logs with incorrect permissions or ownership.
� Records of reboots or restarting of services.
� missing logs.
� su entries or logins from strange places.
Where to look for your log file will depend on your distribution. In
the standard redhat setup, you will want to look in /var/log/ and
check messages, mail.log, and others.
You might also want to configure your log-rotating script or daemon to
keep logs around longer so you have time to examine them. Take a look
at the 'logrotate' package un recent redhat distributions. Other
distributions likely have a similar process.
4. Local Security
The next thing to take a look at is the security in your system
against attacks from local users. Did I just say _local_ users? yes.
Getting access to a local user is one of the first things that system
intruders attempt. With lax local security, they can then "upgrade"
their normal user access to root access using a variety of bugs and
poorly setup local services. If you make sure your local security is
tight, then the intruder will have another hurdle to jump.
Local users can also cause a lot of havoc with your system even
(especially) if they really are who they say they are. Providing
accounts to people you don't know or have no contact information for
is a very bad idea.
Before changing permissions on any system files, make sure you
understand what you are doing. Never change permissions on a file
because it seems like the easy way to get things working. Always
determine why the file has that permission before changing it.
4.1. Creating new accounts
You should make sure and provide user accounts with only the minimal
requirements for the task. If you provide your son (age 10) with an
account, you might want them to only have access to a word processor
or drawing program, but be unable to rm everything.
Several good rules of thumb when allowing other people legitimate
access to your linux machine:
� Give them the minimal amount of privileges they need.
� Be aware when/where they login from, or should be logging in from.
� Make sure and remove their account when they no longer need the
access.
Many local user accounts that are used in security compromises are
ones that have not been used in months or years. Since no one is using
them they provide the ideal attack vehicle.
4.2. File Permissions
It's important to insure that your system files are not open for
casual editing by users and groups who shouldn't be doing such system
maintance.
A quick explanation of unix permissions:
Ownership - Which user(s) and group(s) retain(s) control of the
permission settings of the node and parent of the node
Permissions - Bits capable of being set or reset to allow certain
types of access to it.
Read:
� To be able to view contents of a file
� To be able to read a directory
Write:
� To be able to add to or change a file
� To be able to delete or move files in a directory
Execute:
� To be able to run a binary program
� To be able to search in a directory
You - The owner of the file
Group - The group you belong to
Everyone - Anyone on the system
Examples:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1st bit - directory? (no)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (no)
5th bit - read by group? (yes, by users)
6th bit - write by group? (no)
7th bit - execute by group? (no)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (no)
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1st bit - directory? (yes, it contains many files)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (yes, by kevin)
5th bit - read by group? (yes, by users
6th bit - write by group? (no)
7th bit - execute by group? (yes, by users)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (yes, by everyone)
System configuration files (usually in /etc) are usually mode 644
(-rw-r--r--), and owned by root. Depending on your sites security
requirements, you might adjust this. Never leave any system files
writable by a group or everyone.
4.3. Root security
Another common local user attacker is the admin of your linux box.
yes, you! ;) Remember that you should only use the root account for
very short specific tasks and should mostly run as a normal user.
Running as root all the time is a very very very bad idea. Just use
su or sudo to do those tasks you need to do.
Several tricks to avoid messing up your own box as root:
� When doing some complex command, try running it first in a non
destructive way...especially commands that use globbing: ie, you
are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak"
and make sure you are going to delete the files you think you are.
Using echo in place of destructive commands also sometimes works.
� Some people find it helpfull to do a "touch /-i" on their systems.
This will make commands like: "rm -rf *" ask you if you really want
to delete all the files. (It does this by your shell resolving the
"-i" file first, and treating it as the -i option to rm.) This will
not help with rm statements with no * in them. ;(
� Only become root to do single specific tasks. If you find yourself
trying to figure out how to do something, go back to a normal user
shell until you are sure what needs to be done by root.
� Always be slow and deliberate running as root. Your actions could
affect a lot of things. Think before you type!
If you absolutely positively need to allow someone (hopefully very
trusted) to have superuser access to your machine, there are a few
tools that can help. Sudo allows users to use their password to access
a limited set of commands as root. This would allow you to, for
instance, let a user be able to eject and mount removable media on
your linux box, but have no other root privileges. sudo also keeps a
log of all sudo attempts and successes, allowing you to track down who
used what command to do what. For this reason sudo works well even in
places where a number of people have root access, but use sudo so you
can keep track of changes made.
4.4. Trojan Horses
A Trojan Horse is named after the fabled ploy in Homers great literary
work. The idea is that you put up a program or binary that sounds
great, and get other people to download it and run it as root. Then,
you can compromise their system while they are not paying attention.
While they think the binary they just pulled down does one thing (and
it might very well), it also compromises their security.
You should take care of what programs you install on your machine.
redhat provides md5 checksums and pgp signed rpm files so you can
verify you are installing the real thing. Other distributions have
similar methods. You should never run any binary you don't have the
source for or a well known binary as root! Few attackers are willing
to release source code to public scrutiny.
Although it can be complex, make sure you are getting the source for
some program from it's real distribution site. If the program is going
to run as root make sure either you or someone you trust has looked
over the source and verified it.
4.5. Password Security & Encryption
One of the most important security features used today are passwords.
It is important for both you and all your users to have secure,
unguessable passwords. Most of the more recent linux distributions
include 'passwd' programs that not allow you to set a easily guessable
password. Make sure your passwd program is up to date and has these
features.
In depth discussion of encryption is beyond the scope of this document
, but a introduction is in order. Encryption is very usefull, possibly
even nessessary in this day and age. There are all sorts of methods of
encrypting data, each with their own flaws and drabacks. Some of the
more common ones you should be aware of:
unix password encryption: Most unicies (and linux is no exception) use
the DES (Data Encryption Standard) to encrypt your passwords. This
encrypted password is then stored in (typically) /etc/passwd (or less
commonly) /etc/shadow. When you attempt to login, whatever you type in
is encrypted again and compaired with the entry in the passwd file. If
they match, it must be the same password and you are allowed access.
DES is a one-way encryption. DES is know to be pretty weak in these
days of fast computers. Brute force attacks, such as crack or John the
ripper (see below) can often guess passwords unless your password is
sufficently random. PAM modules (see below) allow you to use a
diffrent encryption routine with your passwords (MD5 or the like).
4.5.1. PAM - Pluggable Authentication Modules
Newer versions of the RedHat linux distribution ship with a thing
called "PAM". PAM allows you to change on the fly your authentication
methods and requirements. Without re-compiling any of your binaries.
Configuration of PAM is beyond the scope of this document, take a look
at the PAM web site for more information.
http://www.kernel.org/pub/linux/libs/pam/index.html
Just a few of the things you can do with PAM:
� Use a non DES encryption for your passwords. (Making them harder to
brute force decode.
� Set resource limits on all your users so they can't perform denial
of service attacks (number of processes, amount of memory, etc).
� Enable shadow passwords (see below) on the fly.
� allow specific users to login only at specific times from specific
places.
4.5.2. Shadow Passwords.
Shadow passwords are a means of keeping your encrypted password
information secret from normal users. Normally this encrypted password
is stored in your /etc/passwd file for all to read. They can then run
password guesser programs on it and attempt to determine what it is.
Shadow passwords save this information to a /etc/shadow file that only
privileged users can read. In order to run shadow passwords you need
to make sure all your utilities that need access to password
information are recompiled to support it. PAM (above) also allows you
to just plug in a shadow module and doesn't require re-compilation of
executables.
4.5.3. Crack and John the Ripper
If for some reason your passwd program is not enforcing non easily
guessable passwords, you might want to run a password cracking program
and make sure your users passwords are secure.
Password cracking programs work on a simple idea. They try every word
in the dictionary, and then variations on those words. They encrypt
each one and check it against your encrypted password. If they get a
match they are in.
There are a number of programs out there...the two most notable of
which are "Crack" and "John the Ripper"
http://www.false.com/security/john/index.html . They will take up a
lot of your cpu time, but you should be able to tell if an attacker
could get in using them by running them first yourself and notifying
users with weak passwords. Note that an attacker would have to use
some other hole first in order to get your passwd (unix /etc/passwd)
file, but these are more common than you might think.
4.6. Integrity Checking with Tripwire
Another very good way to detect local (and also network) attacks on
your system is to run an integrity checker like Tripwire. Tripwire
runs a number of checksums on all your important binaries and config
files and compares them against a database of former values. Thus, any
changes in the files will be flagged.
It's a good idea to install tripwire onto a floppy, and then
physically set the write protect on the floppy. This way intruders
can't tamper with tripwire itself or change the database. Once you
have tripwire setup, it's a good idea to run it once a day or so and
check to see if anything has changed.
You can even add a crontab entry to run tripwire from your floppy
every night and mail you the results in the morning. Something like:
# set mailto
MAILTO=kevin
# run tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
will mail you a report each morning at 5:15am.
Tripwire can be a godsend to detecting intruders before you would
otherwise notice them. Since a lot of files change on the average
system, you have to be careful what is cracker activity and what is
your own doing.
4.7. CFS - Cryptographic File System and TCFS - transparent crypto�
graphic File System.
CFS is a way of encrypting an entire file system and allow users to
store encrypted files on them. It uses a NFS server running on the
local machine. rpms are avail at http://www.replay.com/redhat/ and
more information on how it all works is at:
ftp://ftp.research.att.com/dist/mab/
TCFS improves on CFS, adding more integration with the file system, so
that it's transparent to any users using the file system that it's
encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/
4.8. X11, SVGA and display security.
4.8.1. X11
It's important for you to secure your graphical display to prevent
attackers from doing things like: grabbing your passwords as you type
them without you knowing it, reading documents or information you are
reading on your screen, or even using a hole to gain superuser access.
Running remote X applications over a network also can be fraught with
peril, allowing sniffers to see all your interaction with the remote
system.
X has a number of access control mechanisms. The simplest of them is
host based. You can use xhost to specify what hosts are allowed access
to your display. This is not very secure at all. If someone has access
to your machine they can xhost + their machine and get in easily.
Also, if you have to allow access from an untrusted machine, anyone
there can compromise your display.
When using xdm (x display manager) to login, you get a much better
access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and
stored in your .Xauthorty file. If you need to allow a remote machine
access to your display, you can use the xauth command and the
information in your .Xauthority file to provide only that connection
access.
You can also use ssh (see ssh, above) to allow secure X connections.
This has the advantage of also being transparent to the end user, and
means that no un-encrypted data flows across the network.
Take a look at the Xsecurity man page for more information on X
security. The safe bet is to use xdm to login to your console and then
use ssh to go to remote sites you wish to run X programs off of.
4.8.2. SVGA
SVGAlib programs are typically suid root in order to access all your
linux machines video hardware. This makes them very dangerous. If they
crash, you typically need to reboot your machine to get a usable
console back. Make sure any SVGA programs you are running are
authentic, and can at least be somewhat trusted. Even better, don't
run them at all.
4.8.3. GGI (Generic Graphics Interface project)
The linux GGI project is trying to solve several of the problems with
video interfaces on linux. GGI will move a small piece of the video
code into the linux kernel, and then control access to the video
system. This means GGI will be able to restore your console at any
time to a known good state. They will also allow a secure attention
key, so you can be sure that there is no Trojan horse login program
running on your console. http://synergy.caltech.edu/~ggi/
4.9. identd
identd is a small program that typically runs out of your inetd. 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 identd for specific users
(they can make a .noident file), you can log all identd requests (I
recommend it), you can even have identd return a uid instead of a user
name or even NO-USER.
5. 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.
5.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
"Password" 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 wire.)
5.2. System services and tcp_wrappers
As soon as 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 (ie, 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, since it provides no
additional security. If a local person wanted to use ftp even tho you
had commented it out, they would make their own client that use the
common ftp port and would still work fine.
If you know you are not going to use some particular package, you can
also delete it entirely. rpm -e under the redhat distribution will
erase an entire package. Under debian dpkg likely does the same thing.
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. Simply remove the unneeded script(s) and they will not be
started on your next reboot. 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 launches the program 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. If you are a home dialup
user, I would suggest you deny ALL. tcpd also logs failed attempts to
access services, so this can give you an idea that you are under
attack. If you add new services, you should always tcp wrapper them if
they are tcp based.
5.3. SATAN , ISS, and other network scanners
There are a number of different software packages out there that do
port and service based scanning of machines or networks. SATAN and ISS
are two 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 it can, and tries to determine what service is running there.
Based on this information, you could find out the machine is
vulnerable to a specific exploit on that server.
SATAN (Security Administrators 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 sun-site
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
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.
Detecting Port scans.
There are some tools designed to alert you to probes by Satan and ISS
and other scanning software, However liberal use of tcp_wrappers and
making sure to 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 Redhat system.
5.4. pgp and public key cryptography
pgp (pretty good privacy) is well supported on linux. versions 2.62
and 5.0 are known to work well. For a good primer on pgp and how to
use it, take a look a the pgp FAQ.
http://www.pgp.com/service/export/faq/55faq.cgi
5.5. ssh and stelnet
ssh (secure shell) and stelnet are programs that allow you to login to
remote systems and have a encrypted connection.
Ssh will prevent host spoofing attacks (It expects a specific key back
from a host it's connected to before), it does compression and X11
forwarding in addition to encrypting all your communications with the
remote machines. This is very good to defeat packet sniffer attacks
(The packet sniffer gets a bunch of encrypted packets). ssh is free
for personal use, so I would recommend you install it and use it if
you are at a personal site. http://www.cs.hut.fi/ssh/
Stelnet is a secure telnet replacement that does encryption over a
telnet connection.
5.6. 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.
http://www.sendmail.org
If you are tired of upgrading your version of sendmail every week, you
might consider switching over to qmail. qmail was designed with
security in mind from the ground up. It's fast and stable and secure.
http://www.qmail.org
5.7. Denial of service attacks.
A Denial of service 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 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. CONFIG_SYN_COOKIES and
CONFIG_RST_COOKIES. Rebuild your kernel with these options to reduce
your susceptibility to SYN flood attacks.
Pentium "F00F" bug. It was recently discovered that a series of
assembly codes send to a genuine Intel Pentium processor would lock
the machine up totally. This affects every machine with a Pentium
processor (not clones, not Pentium Pro or PII), no matter what
operating system it's running. Linux kernel 2.0.32 and up contain a
work around for this bug, preventing it from locking your machine. If
you are running on a pentium, you should upgrade now!
Ping flooding. Ping flooding is a simple brute force denial of service
attack. Your attacker send 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 "smurfing" sends ICMP packets to a host with
_your_ machines return IP, allowing them to flood you less detectably.
If you are 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.
5.8. NFS (Network File System) security.
NFS is a very widely used file sharing protocol. It allows servers
running nfsd and mountd to "export" entire filesystems to other
machines with nfs filesystem support builtin to their kernels (or some
other client support if they are non 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 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.
See the NFS HOWTO for more information on NFS: NFS HOWTO
5.9. NIS (Network Information service) (formerly YP).
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 affect 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 usefull. 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://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html
5.10. Firewalls
Firewalls are a means of restricting 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 and methods of setting up firewalls. Linux
machines make pretty good low cost firewalls. firewall code can be
built right into 2.0 and higher kernels. The ipfwadm user space tool
allows you to change what types of network traffic you allow on the
fly. You can also log particular types of network traffic.
Firewalls are a very usefull and important technique in securing your
network. It is important to realize that you should 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 sun-site archive for more information on
firewalls and linux. http://sunsite.unc.edu/mdw/HOWTO/Firewall-
HOWTO.html
6. What to do during and after a breakin
So you have followed some of the advice here (or elsewhere) and have
detected a breakin? The first thing to do is to remain calm. Hasty
actions can cause more harm than the attacker would have.
6.1. Security Compromise under way.
Spotting a security compromise under way can be a tense undertaking.
How you react can have large consequences.
If the compromise you are seeing is a physical one, odds are you have
spotted someone who has broken into your home, office or lab. You
should notify your local authorities. In a lab setting you might have
spotted someone trying to open a case or reboot a machine. Depending
on your authority and procedures, you might ask them to stop, or
contact your local security people.
If you have detected a local user trying to compromise your security,
the first thing to do is confirm they are in fact who you think they
are. Check the site they are logging in from. Is it the site they are
normally in from? no? Then use a non electronic means of getting in
touch. For instance call them on the phone or walk over to their
office/house and talk to them. If they agree that they are on, you can
ask them to explain what they were doing or tell them to cease doing
it. If they are not on, and have no idea what you are talking about,
odds are this incident requires further investigation. Look into such
incidents , and have lots of information before making any
accusations.
If you have detected a network compromise, the first thing to do (if
you are able) is to disconnect your network. If they are connected via
modem, unplug the modem cable, if they are connected via ethernet,
unplug the ethernet cable. This will prevent them from doing any
further damage, and they will probably see it as a network problem
rather than detection.
If you are unable to disconnect the network (if you have a busy site,
or you do not have physical control of your machines), the next best
step is to use something like tcp_wrappers or ipfwadm to deny access
from the intruders site.
If you can't deny all people from the same site as the intruder,
locking the users account will have to do. Note that locking an
account is not an easy thing. You have to keep in mind .rhosts files,
FTP access, and a host of backdoors).
After you have done one of the above (disconnected network, denied
access from their site, and/or disabled their account), you need to
kill all their user processes and log them off.
You should monitor your site well for the next few minutes, as the
attacker will try and get back in. Perhaps using a different account,
and/or from a different network address.
6.2. Security Compromise has already happened.
So you have either detected a compromise that has already happened or
you have detected it and locked (hopefully) the offending attacker out
of your system. Now what?
6.2.1. Closing the Hole
If you are able to determine what means the attacker used to get into
your system, you should try and close that hole. For instance, perhaps
you see several FTP entries just before the user logged in. Disable
the FTP service and check and see if there is an updated version or
any of the lists know of a fix.
Check all your log files, and make a visit to your security lists and
pages and see if there are any new common exploits you can fix.
If you don't lock the attacker out, they will likely be back. Not just
back on your machine, but back somewhere on your lan. If they were
running a packet sniffer, odds are good they have access to other
local machines.
6.2.2. Assessing the Damage
The first thing is to assess the damage. What has been compromised?
If you are running an Integrity Checker like Tripwire you can make a
tripwire run and it should tell you. If not, you will have to look
around at all your important data.
Since linux systems are getting easier and easier to install, you
might consider saving off your config files and then wiping your
disk(s) and reinstalling, then restoring your user files from backups
and your config files. This will insure that you have a new clean
system.
6.2.3. Backups, Backups, Backups!
Having regular backups is a godsend for security matters. If your
system is compromised, you can restore the data you need from backups.
Of course some data is valuable to the attacker to, and they will not
only destroy it, they will steal it and have their own copies, but at
least you will still have the data.
You should check several backups back into the past before restoring a
file that has been tampered with. The intruder could have compromised
your files long ago, and you could have made many successful backups
of the compromised file!!!
Of course, there are also a raft of security concerns with backups.
Make sure you are storing them in a secure place. Know who has access
to them. (If an attacker can get your backups, they can have access to
all your data without you ever knowing it.)
6.2.4. Tracking down the intruder.
Ok, you have locked the intruder out, and recovered your system, but
you're not quite done yet. While it is unlikely that most intruders
will ever be caught, you should report the attack.
You should report the attack to the admin contact at the site where
the attacker attacked your system. You can look up this contact with
"whois" or the internic database. You might send them an email with
all applicable log entries and dates and times. If you spotted
anything else distinctive about your intruder, you might mention that
too. After sending the email, you should (if you are so inclined)
follow up with a phone call. If that admin in turn spots your
attacker, they might be able to talk to the admin of the site where
they are coming from and so on.
Good hackers often use many intermediate systems. Some (or many) of
which may not even know they have been compromised. Trying to track a
cracker back to their home system can be difficult. Being polite to
the admins you talk to can go a long way to getting help from them.
You should also notify any security organizations you are a part of
(cert or similar).
7. Security sources
There are a LOT of good sites out there for unix security in general
and linux security specifically. It's very important to subscribe to
one (or more) of the security mailing lists and keep current on
security fixes. Most of these lists are very low volume, and very
informative.
7.1. FTP sites
CERT is the Computer Emergency Response Team. They often send out
alerts of current attacks and fixes. cert.org
Replay has archives of many security programs. Since they are outside
the US, they don't need to obey any silly US crypto restrictions.
replay.com
Matt Blaze is the author of CFS and a great security advocate. Matt
Blaze's stuff
Sorosis is the home of the linux PAM site. They have lots of modules
and information on PAM. Linux PAM ftp site
tue.nl is a great security ftp site in the Netherlands.
ftp.win.tue.nl
7.2. The Hacker FAQ is a FAQ about hackers: The Hacker FAQ web sites
The COAST archive has a large number of unix security programs and
information: COAST
Rootshell.com is a great site for seeing what exploits are currently
being used by crackers: rootshell.com exploits
BUGTRAQ puts out advisories on security issues: BUGTRAQ archives
CERT, the Computer Emergency Response Team, puts out advisories on
common attacks on unix platforms: CERT home
Dan Farmer is the author of SATAN and many other security tools, his
home site has some interesting security survey information as well as
security tools: Dan Farmers trouble.org
The linux security WWW is a good site for linux security information:
Linux Security WWW
Reptile has lots of good linux security information on his site:
Reptiles Linux Security Page
Infilsec has a vulnerability engine that can tell you what
vunerabilities affect a specific platform: Infilsec vunerability
engine
CIAC sends out periodic security bulitins on common exploits: CIAC
bulitins
7.3. mailing lists
Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
containing the message body subscribe bugtraq. (see links above for
archives).
CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not
subject) of the message put (either or both): subscribe ciac-bulletin
7.4. Books - printed reading material.
There are a number of good security books out there. This section
lists a few of them. In addition to the security specify books,
security is covered in a number of other books on system
administration.
Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky
1st Edition September 1995
ISBN: 1-56592-124-0
Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
Gene Spafford
2nd Edition April 1996
ISBN: 1-56592-148-8
Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr.
1st Edition July 1991
ISBN: 0-937175-71-4
Linux Network Administrator's Guide By Olaf Kirch
1st Edition January 1995
ISBN: 1-56592-087-2
PGP: Pretty Good Privacy By Simson Garfinkel
1st Edition December 1994
ISBN: 1-56592-098-8
Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
William VonStorch (Consulting Editor Eugene H. Spafford)
1st Edition August 1995
ISBN: 1-56592-086-4
8. Conclusion
By subscribing to the security alert mailing lists, and keeping
current, you can do a lot towards securing your machine. If you pay
attention to your log files and run something like tripwire regularly,
you can do even more.
A reasonable level of computer security is not difficult to maintain
on a home machine. More effort is required on business machines, but
linux can indeed be a secure platform. Due to the nature of linux
development, security fixes often come out much faster than they do on
commercial operating systems, making linux an ideal platform when
security is a requirement.
9. Thanks to
Information here is collected from many sources. Thanks to the
following that either indirectly or directly have contributed:
Rob Riggs <rob@DevilsThumb.com>
S. Coffin <scoffin@netcom.com>
Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu>
Roelof Osinga <roelof@eboa.com>
Kyle Hasselbacher <kyle@carefree.quux.soltec.net>
"David S. Jackson" <dsj@dsj.net>