This document is a general overview of the security issues that the administrators of GNU/Linux systems face. It covers general security philosophy and a number of specific examples of how to better secure your GNU/Linux system against intruders. Also included are pointers to security-related material and programs. Finally, you will also find how to use Mandriva security tools.
This chapter is based on a
HOWTO by and .
The Linux Documentation
Project hosts the original document.
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 authors 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 the Linux HOWTO coordinator Tim Bynum.
This chapter is not meant to be an up-to-date exploits document. Large numbers of new exploits happen all the time. This chapter will tell you where to look for such up-to-date information, and will give you some general methods to prevent such exploits from taking place.
This chapter will attempt to explain some procedures and commonly-used software to help your GNU/Linux system be more secure. It is important to discuss some of the basic concepts first, and create a security foundation, before we get started.
In the ever-changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becoming more and more of an issue. Security is now a basic requirement because global computing is inherently insecure. As your data goes from point A to point B on the Internet, for example, it may pass through several other points along the way, giving other users the opportunity to intercept, or worst, make alterations. Even other users on your system may maliciously transform your data into something you did not intend. Unauthorized access to your system may be obtained by intruders, also known as “crackers”, who could then use advanced knowledge to impersonate you, steal information from you, or even deny you access to your own resources. See Eric Raymond's How to Become a Hacker if you're wondering what the difference between a “hacker” and a “cracker” is.
First, bear in mind that no computer system can ever be completely secure. All you can do is make it increasingly difficult for someone to compromise your system. For the average home GNU/Linux user, not much is required to keep the casual cracker at bay. However, for high profile GNU/Linux users (banks, telecommunications companies, etc.), much more work is required.
Another factor to take into account is that the more secure your system is, the more intrusive your security becomes. You need to decide where in this balancing act your system will still be 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 log in. You could also set up your GNU/Linux system with no network, nor connection to the Internet, but this limits its usefulness.
If you are a medium-to-large-size 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. You can find a well-known security policy example at faqs.org. It contains a great framework for establishing a security policy for your company.
Before you attempt to secure your system, you should determine what level of threat you have to protect against, what risks you should or should not take, and how vulnerable your system is as a result. You should analyze your system to know what you're protecting, why you're protecting it, what value it has, and who has responsibility for your data and other assets.
Risk is the possibility that an intruder may be successful in attempting to access your computer. Can an intruder read or write files, or execute programs that could cause damage? Can they delete critical data? Can they prevent you or your company from getting important work done? Don't forget: someone gaining access to your account, or your system, can also impersonate you.
Additionally, having one insecure
account on your system can result in your entire network being
compromised. If you allow a single user to log in using a
.rhosts file, or to use an insecure
service, such as tftp, you risk an intruder
getting “his foot in the door”. Once the intruder
has a user account on your system, or someone else's system, it
can be used to gain access to another system, or another
Threat is typically from someone with motivation to gain unauthorized access to your network or computer. You must decide who you trust to have access to your system, and what level of threat they might pose.
The Borrowers – This type of intruder is interested in setting up shop on your system and using its resources for their own purpose. He typically will run chat or IRC servers, porn archive sites, or even DNS servers.
The Leapfrogger – This type of intruder is only interested in using your system to get access to other systems. If your system is well connected or a gateway to a number of internal hosts, you may well see this type trying to compromise your system.
What's at stake if someone breaks into your system? Of course the concerns of a dynamic PPP home user will be different from those of a company connecting their machine to the Internet, or another large network.
How much time would it take to retrieve/recreate any data that was lost? An initial time investment now can save ten times more time later if you have to recreate data that was lost. Have you checked your backup strategy and verified your data lately?
Create a simple, generic policy for your system that your users can readily understand and follow. It should protect the data you are safeguarding as well as the privacy of the users. Some things to consider adding are: who has access to the system (Can my friend use my account?), who is allowed to install software on the system, who owns what data, disaster recovery, and appropriate use of the system.
This means that unless you grant access to a service for a user, that user should not be using that service until you do grant access. Make sure the policies work on your regular user account. Saying, “Ah, I cannot figure out this permissions problem, I'll just do it as root”, can lead to security holes that are very obvious, and even ones which haven not been exploited yet.
rfc1244 is a document that describes how to create your own network security policy.
rfc1281 is a document that shows a security policy example with detailed descriptions of each step.
To see what some real-life security policies look like, you can take a look at the COAST policy archive.
This section discusses various means by which you can secure the assets you have worked hard for: your local computer, your data, your users, your network, even your reputation. What would happen to your reputation if an intruder deleted some of your users' data? Or defaced your web site? Or published your company's corporate project plan for the next quarter? If you are planning a network installation, there are many factors you must take into account before adding a single computer to your network.
Even if you have a single dial up PPP account, or just a small site, this does not mean intruders will not be interested in your systems. Large, high-profile sites are not the only targets – many intruders simply want to exploit as many sites as possible, regardless of their size. Additionally, they may use a security hole in your site to gain access to other sites you are connected to.
Intruders often have a lot of time on their hands, and can guess how you have obscured your system just by trying all the possibilities. There are also a number of reasons an intruder may be interested in your systems, which we will discuss later.
Perhaps the area of security on which administrators concentrate most is host-based security. This typically involves making sure your own system is secure, and hoping everyone else on your network does the same. Choosing good passwords, securing your host's local network services, keeping good accounting records, and upgrading programs with known security exploits are among the things the local security administrator is responsible for. Although this is absolutely necessary, it can become a daunting task once your network becomes larger than a few computers.
Network security is as necessary as local host security. With hundreds, thousands, or more computers on the same network, you cannot rely on each one of those systems being secure. Ensuring that only authorized users can use your network, by building firewalls, by using strong encryption, and by ensuring there are no “rogue” (that is, unsecured) computers on your network are all part of the network security administrator's duties.
This document discusses some of the techniques which can be used to secure your site, and hopefully shows you some of the ways to prevent intruders from gaining access to that which you are trying to protect.
One type of security that must be discussed is “security through obscurity”. This means, for example, moving a service that has known security vulnerabilities to a non-standard port in the hope that an attacker won't notice it's there and thus won't exploit it. Rest assured that they can determine that it is there and will exploit it. Security through obscurity is no security at all. Simply because you have a small site, or a relatively low profile, does not mean an intruder will not be interested in what you have. We will discuss what you are protecting in the next sections.
This chapter has been divided into a number of sections. They cover several broad security issues. The first, Section 4.3, “Physical Security”, covers how to protect your physical machine from tampering. The second, Section 4.4, “Local Security”, describes how to protect your system from tampering by local users. The third, Section 4.5, “Files and File-System Security”, shows you how to set up your file systems and permissions on your files. The next, Section 4.6, “Password Security and Encryption”, discusses how to use encryption to better secure your machine and network. Section 4.7, “Kernel Security” discusses what kernel options you should set or be aware of for a more secure system. Section 4.8, “Network Security”, describes how to better secure your GNU/Linux system from network attacks. Section 4.9, “Security Preparation (Before You Go On-Line)”, discusses how to prepare your machine(s) before bringing them on-line. Next, Section 4.10, “What to Do During and After a Break-in”, discusses what to do when you detect a system compromise in progress or detect one that has recently happened. In Section 4.11, “Security Sources”, some primary security resources are enumerated. The Q & A section Section 4.12, “Frequently Asked Questions”, answers some frequently-asked questions, and finally, a conclusion in Section 4.14, “Conclusion”.
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 computer? Should they? Can you protect your computer from their tampering? Should you?
If you are a home user, you probably don't need a lot (although you might need to protect your computer from tampering by children or annoying relatives). If you are in a lab, you need considerably more, but users will still need to be able to get work done on the computers. Many of the following sections will help out. If you are in an office, you may or may not need to secure your computer after-hours or while you are away. In some companies, leaving your console unsecured is a termination offense.
Many modern computer 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 computer, or opening up the case and directly manipulating or stealing your hardware. Some locks can even prevent someone from rebooting your computer from 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 computers, they make it so you have to break the case to get the case open. On some others, they will not let you plug in new keyboards or 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 skills.
Some computers (most notably SPARCs and Macs) have a dongle on the back: 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 computer.
The BIOS is the lowest level of software to configure or manipulate your x86-based hardware. LILO and other GNU/Linux boot methods access the BIOS to determine how to boot your GNU/Linux computer. Other hardware that GNU/Linux runs on has similar software (Open Firmware on Macs and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent attackers from rebooting your computer and manipulating your GNU/Linux system.
Many PC BIOSes let you set a boot password. This does not provide much security (the BIOS can be reset, or removed if someone can get into the case), but may be a good deterrent (i.e. it will take time and leave traces of tampering). Similarly, on S/Linux (GNU/Linux for SPARC(tm) processor computers), your EEPROM can be set to require a boot-up password. This may slow attackers down.
Another risk of trusting BIOS passwords to secure your system is the default password problem. Most BIOS makers do not expect people to open up their computer and disconnect batteries if they forget their password and have equipped their BIOSes with default passwords which work regardless of your chosen password. Some of the more common passwords include:
j262 AWARD_SW AWARD_PW lkwpeter Biostar AMI Award bios BIOS setup cmos AMI!SW1 AMI?SW1 password hewittrand shift + s y x z
I tested an Award BIOS and AWARD_PW worked. These passwords are quite easily available from manufacturers' web sites and astalavista and as such a BIOS password cannot be considered adequate protection from a knowledgeable attacker.
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. For example, some BIOSes disallow booting from floppy drives and some require passwords to access some BIOS features.
The PROM is the lowest level of software to configure or manipulate your SPARC-based hardware. SILO and other GNU/Linux boot methods access the PROM to determine how to boot your GNU/Linux computer. Other hardware which GNU/Linux runs on has similar software (OpenFirmware on Macs and new Suns, x86 BIOS, etc.). You can use your PROM to prevent attackers from rebooting your computer and manipulating your GNU/Linux system.
It is important to set your password before setting the security mode, as you would be unable to change it later. Moreover, claims you need to contact your vendor's customer support service to make your computer bootable again.
> password > New password (only first 8 chars are used): > Retype new password: >
> setenv security-mode full >
Bear in mind when setting these passwords that you need to remember them. Also remember that these passwords will only slow the determined attacker. They will not prevent someone from booting from a floppy and mounting your root partition.
Once again, if you have a server computer, and you set up a boot password, your computer will not boot up unattended. Bear in mind that you will need to come in and supply the password in the event of a power failure!
LILO can have a password set.
password requires a password at boot time,
restricted requires a boot-time
password only if you specify options (such as
single) at the LILO prompt.
GRUB is quite
flexible when it comes to password setting: your default
contain a line allowing the loading of a new configuration file
with different options (this new file may contain a new password
to access another third configuration file and so on).
password very_secret /boot/grub/menu2.lst
and of course generate a new
/boot/grub/menu2.lst configuration file
where you move insecure entries previously removed from
If you wander away from your computer from time to time, it is nice to be able to “lock” your console so that no one can tamper with or look at your work. Two programs that do this are: xlock and vlock.
xlock is a X display locker. You can run xlock from any xterm on your console and it will lock the display and require your password to unlock. Most desktop environments also provide this feature in their respective menus.
vlock is a simple little program which allows you to lock some or all of the virtual consoles on your GNU/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 virtual console until you unlock it.
Of course, locking your console will prevent someone from tampering with your work, but won't prevent them from rebooting your computer or otherwise disrupting your work. It also does not prevent them from accessing your computer from another computer on the network and causing problems.
More importantly, it does not prevent someone from switching out of the X Window System entirely, and going to a normal virtual console login prompt, or to the VC that X11 was started from, and suspending it, thus obtaining your privileges. For this reason, you might consider only using it while under control of KDM (or other login manager).
If you have a webcam or a microphone attached to your system, you should consider if there is some danger of an attacker gaining access to those devices. When not in use, unplugging or removing such devices might be an option. Otherwise you should carefully read and look at any software which provides access to such devices.
The first thing to always note is when your computer was rebooted. Since GNU/Linux is a robust and stable OS, the only time your computer should reboot is when you take it down for OS upgrades, hardware swapping, or the like. If your computer has rebooted without you doing it, that may be a sign that an intruder has compromised it. Many of the ways that your computer can be compromised require the intruder to reboot or power off your computer.
It is also a good idea to store log data at a secure location, such as a dedicated log server within your well-protected network. Once a computer has been compromised, log data becomes of little use as it most likely has also been modified by the intruder.
The syslog daemon can be configured to automatically send log data to a central syslog server, but this is typically sent in unencrypted form, allowing an intruder to view data as it is being transferred. This may reveal information about your network which is not intended to be public. There are syslog daemons available which encrypt the data as it is being sent.
Also be aware that faking syslog messages is easy – with an exploit program having been published. syslog even accepts net log entries claiming to come from the local host without indicating their true origin.
We will discuss system log data in Section 4.9.5, “Keep Track of your System Accounting Data”.
Getting access to a local user account
is one of the first things that system intruders attempt while on
their way to exploiting the
root account. With lax local
security, they can then “upgrade” their normal user
root access using a variety of bugs and poorly
set up 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 do not know or for whom you have no contact information is a very bad idea.
You should make sure you provide user accounts with only the minimal requirements for the task they need to do. If you provide your son (age 10) with an account, you might want him to only have access to a word processor or drawing program, but be unable to delete data that is not his.
The most sought-after account on your
computer is the
root (superuser) account. It has authority
over the entire computer, which may also include authority over
other computers on the network. Remember that you should only use
root account for very short, specific tasks, and
should mostly run as a normal user. Even small mistakes made while
logged in as the
root user can cause problems. The less
time you are on with
root privileges, the safer you will
When doing some complex command, try running it first in a non-destructive way... especially commands that use globbing: e.g., if you want to do rm -f foo*.bak, first do ls foo*.bak and make sure you are going to delete the files you think you are deleting. Using echo in place of destructive commands sometimes works too.
The command path for
root user is very important. The command path (that
PATH environment variable) specifies the
directories in which the
shell searches for programs.
Try to limit the command path for the
root user as much
as possible, and never include
. (which means “the current
directory”) in your
never have writable directories in your search path, as this
can allow attackers to modify or place new binaries in your
search path, allowing them to run as
root the next time
you run that command.
Never use the
rlogin/rsh/rexec suite of tools (called the
root. They are subject
to many kinds of attacks, and are downright dangerous when run
root. Never create a
/etc/securetty file contains a list of
root can login from. By default, this is
set to only the local virtual consoles (ttys). Be very wary of
adding anything else to this file. You should be able to log in
remotely as your regular user account and then
su if you need to (hopefully over ssh
or other encrypted channel), so there is no need to be able to
login directly as
If you absolutely,
positively need to allow someone (hopefully very trusted) to have
root access to your computer, there are a few tools which
can help. sudo allows users to use their own
password to access a limited set of commands as
could allow you to, for instance, let a user be able to eject and
mount removable media on your GNU/Linux box, but have no other
root privileges. sudo also keeps a log
of all successful and unsuccessful sudo attempts, 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, because it helps you to keep
track of changes made.
sudo can be used to give specific users special
privileges for particular tasks, it does have several
shortcomings. It should be used only for a limited set of tasks,
such as restarting a server, or adding new users. Any program that
shell escape will give
root access to a
user invoking it via sudo. This includes most
editors, for example. Also, a program as innocuous as
/bin/cat can be used to overwrite files, which
root to be exploited. Consider
sudo as a means for accountability, and don't
expect it to replace the
root user and still be
There should never be
a reason for users' home directories to allow
SUID/SGID programs to be run from them. Use
nosuid option in
/etc/fstab for partitions which are
writable by users other than
root. You may also wish to
users' home partitions, as well as
thus prohibiting execution of programs, and creation of
character or block devices, which should never be necessary
If you are exporting file systems
using NFS, be sure to configure the
/etc/exports file with the most restrictive
access possible. This means not using wildcards, not allowing
root write access, and exporting read-only wherever
Configure your users' file-creation
umask to be as restrictive as possible. See
Section 4.5.1, “umask Settings”.
If you are mounting file systems
using a network file system such as NFS, be sure to configure
/etc/fstab with suitable restrictions.
nosuid, and perhaps
Set file system limits instead of allowing
unlimited as default. You can control the per-user
limits using the resource-limits PAM module and
/etc/pam.d/limits.conf. For example, limits for
users might look like this:
@users hard core 0 @users hard nproc 50 @users hard rss 5000
/var/run/utmp files contain the login
records for all users on your system. Their integrity must be
maintained because they can be used to determine when and from
where a user (or potential intruder) has entered your system.
These files should also have
without affecting normal system operation.
The immutable bit can be used to prevent accidentally deleting or overwriting a file which must be protected. It also prevents someone from creating a hard link to the file. See chattr(1) for information on the immutable bit.
SUID and SGID
files on your system are a potential security risk, and should
be monitored closely. Because these programs grant special
privileges to the user who is executing them, it is necessary to
ensure that insecure programs are not installed. A favorite
trick of crackers is to exploit
programs, then leave a SUID program as a back
door to get in the next time, even if the original hole is
Find all SUID/SGID programs on your system, and keep track of what they are, so you are aware of any changes which could indicate a potential intruder. Use the following command to find all SUID/SGID programs on your system:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
World-writable files, particularly system files, can be a security hole if a cracker gains access to your system and modifies them. Additionally, world-writable directories are dangerous, since they allow a cracker to add or delete files as he wishes. To locate all world-writable files on your system, use the following command:
root# find / -perm -2 ! -type l -ls
and be sure you know why those files are writable. In the normal
course of operation, several files will be world-writable,
including some from
/dev, and symbolic
links, thus the
! -type l which excludes
these from the previous find command.
root# find / \( -nouser -o -nogroup \) -print
.rhosts files should be a part of your
regular system administration duties, as they should not be
permitted on your system. Remember, a cracker only needs one
insecure account to potentially gain access to your entire
network. You can locate all
on your system with the following command:
root# find /home -name .rhosts -print
Finally, 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.
umask command can be used to determine the
default file-creation mode on your system. It is the octal
complement of the desired file mode. If files are created without
any regard to their permission settings, the user could
inadvertently give read or write permission to someone who should
not have it. Typical umask settings include
077 (which is the most restrictive). Normally,
the umask is set in
/etc/profile, so it
applies to all users on the system. The file creation mask can be
calculated by subtracting the desired value from
777. In other words, a umask of
777 would cause newly-created files to contain
no read, write or execute permission for anyone. A mask of
666 would cause newly-created files to have a
111. For example, you may have a line
that looks like this:
# Set the user's default umask umask 033
Be sure to make
will disable read, write, and execute permission for other users,
unless explicitly changed using chmod. In this
case, newly-created directories would have
permissions, obtained by subtracting
777. Newly-created files using the
033 umask would have permissions of
UNIX® separates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else.
The “sticky bit”
also has a different meaning when applied to directories than
when applied to files. If the sticky bit is set on a
directory, then a user may only delete files that he owns or
for which he has had explicit write permission granted, even when
he has write access to the directory. This is designed for
directories such as
/tmp, which are
world-writable, but where it may not be desirable to allow any
user to delete files at will. The sticky bit is seen as a
t in a long directory listing.
This describes set-user-id
permissions on the file. When the set user
mode is set in the owner permissions, and the file is
executable, processes which run it are granted access to
system resources based on the user who owns the file, as opposed
to the user who created the process. This is the cause of many
“buffer overflow” exploits.
-rw-r--r-- 1 queen users 114 Aug 28 1997 .zlogin 1st bit - directory? (no) 2nd bit - read by owner? (yes, by queen) 3rd bit - write by owner? (yes, by queen) 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)
The following lines are examples of the minimum sets of permissions required to perform the access described. You may want to give more permission than those listed here, but this should describe what these minimum permissions on files do:
-r-------- Allow read access to the file by owner --w------- Allows the owner to modify or delete the file (Note that anyone with write permission to the directory the file is in can overwrite it and thus delete it) ---x------ The owner can execute this program, but not shell scripts, which still need read permission ---s------ Will execute with effective User ID = to owner ------s--- Will execute with effective Group ID = to group -rw------T No update of "last modified time". Usually used for swap files ---------t No effect. (formerly sticky bit)
drwxr-xr-x 3 queen users 512 Sep 19 13:47 .public_html/ 1st bit - directory? (yes, it contains many files) 2nd bit - read by owner? (yes, by queen) 3rd bit - write by owner? (yes, by queen) 4th bit - execute by owner? (yes, by queen) 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)
The following lines are examples of the minimum sets of permissions required to perform the access described. You may want to give more permission than those listed, but this should describe what these minimum permissions on directories do:
dr-------- The contents can be listed, but file attributes can't be read d--x------ The directory can be entered, and used in full execution paths dr-x------ File attributes can be read by owner d-wx------ Files can be created/deleted, even if the directory isn't the current one d-----x--t Prevents files from deletion by others with write access. Used on /tmp d--s--s--- No effect
System configuration files (usually
/etc directory) are usually mode
-rw-r-----), and owned
root. Depending on your site's security requirements,
you might want to adjust this. Never leave any system files writable by a
group or everyone. Some configuration files, including the
/etc/shadow one, should only be readable by
root, and directories in
at least not be accessible by others.
Another very good way to detect local (and also network) attacks on your system is to run an integrity checker such as Tripwire, Aide or Osiris. These integrity checkers run a number of checksums on all your important binaries and configuration files and compares them against a database of former, known-good values as a reference. Thus, any changes in the files will be flagged.
It is a good idea to install these types of program onto a floppy, and then physically set the write protect on the floppy. This way intruders cannot tamper with the integrity checker itself or change the database. Once you have something like this setup, it is a good idea to run it as part of your normal security administration duties to see if anything has changed.
# set mailto MAILTO=queen # run Tripwire 15 05 * * * root /usr/local/adm/tcheck/tripwire
will mail you a report each morning at 5:15am.
Integrity checkers 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 to determine which is cracker activity and which is your own doing.
You can find the freely available unsupported version of Tripwire on the TripWire web site free of charge. Manuals and support can be purchased.
Aide can be found on Sourceforge.
OSIRIS can be found on the OSIRIS web site.
“Trojan Horses” are
named after the fabled ploy in Homer's "Iliad". The idea
is that a cracker distributes a program or binary that sounds
great, and encourages other people to download it and run it as
root. Then the program can compromise their systems while
they are not paying attention. While they think the binary they
just pulled down does one thing (and it might very well do so), it also
compromises their security.
You should take care of what programs
you install on your computer. Mandriva provides MD5
checksums and PGP signatures on its RPM files
so you can verify you are installing the real thing. You should
never run any unfamiliar binary, for which you don't have the
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 a program from its real
distribution site. If the program is going to run as
make sure either you or someone you trust has looked over the
source and verified it.
One of the most important security features used today are passwords. It is important for both you and all of your users to have secure, unguessable passwords. Your Mandriva Linux distributions include a passwd program that does not allow you to set an easy to guess password. Make sure your passwd program is up to date.
In-depth discussion of encryption is beyond the scope of this chapter, but an introduction is in order. Encryption is very useful, possibly even necessary in this day and age. There are all sorts of methods of encrypting data, each with its own set of characteristics.
Most UNIX® systems (and GNU/Linux
is no exception) primarily use a one-way encryption algorithm,
called DES (Data Encryption Standard) to encrypt
your passwords. This encrypted password is then stored in
/etc/shadow. When you attempt to login, the
password you type in is encrypted again and compared with the entry
in the file that stores your passwords. If they match, it must be
the same password, and you are allowed access. Although
DES is a two-way encryption algorithm (you can
code and then decode a message, given the right keys), the variant
that most Unixes use is one-way. This means that it should not be
possible to reverse the encryption to get the password from the
Brute force attacks, such as “Crack” or “John the Ripper” (see Section 4.6.9, ““Crack” and “John the Ripper””) can often guess passwords unless your password is sufficiently random. PAM modules (see below) allow you to use a different encryption routine with your passwords (MD5 or the like). You can use Crack to your advantage, as well. Consider periodically running Crack against your own password database, to find insecure passwords. Then contact the offending user, and instruct him to change his password.
To obtain information on how to choose a good password, check the CERN web site.
Public-key cryptography, such as that used for PGP, uses one key for encryption, and one key for decryption. Traditional cryptography, however, uses the same key for encryption and decryption; this key must be known to both parties, and thus somehow transferred from one to the other securely.
To alleviate the need to securely transmit the encryption key, public-key encryption uses two separate keys: a public key and a private key. Each person's public key is available by anyone to do the encryption, while at the same time each person keeps his or her private key to decrypt messages encrypted with the correct public key.
PGP (Pretty Good Privacy) is well-supported on GNU/Linux. Versions 2.6.2 and 5.0 are known to work well. For a good primer on PGP and how to use it, take a look at the different PGP FAQs available on the Internet FAQ Archives.
Be sure to use the version that is applicable to your country. Due to export restrictions by the US Government, strong-encryption is prohibited from being transferred in electronic form outside the country.
There is also a step-by-step guide for configuring PGP on GNU/Linux available at LinuxFocus. It was written for the international version of PGP, but is easily adaptable to the United States version. You may also need a patch for some of the latest versions of GNU/Linux; the patch is available at metalab.
There is a project maintaining a free re-implementation of PGP with open source. GnuPG is a complete and free replacement for PGP. Because it does not use IDEA or RSA it can be used without any restrictions. GnuPG is in compliance with OpenPGP. See the GNU Privacy Guard web page for more information.
More information on cryptography can be found in the RSA cryptography FAQ. Here you will find information on such terms as “Diffie-Hellman”, “public-key cryptography”, “digital certificates”, etc.
Often users ask about the differences between the various security and encryption protocols, and how to use them. While this isn't an encryption document, it is a good idea to explain briefly what each protocol is, and where to find more information.
SSL: - SSL, or Secure Sockets Layer, is an encryption method developed by to provide security over the Internet. It supports several different encryption protocols, and provides client and server authentication. SSL operates at the transport layer, creates a secure encrypted channel of data, and thus can seamlessly encrypt data of many types. This is most commonly seen when going to a secure site to view a secure on-line document with a web browser, and serves as the basis for secure communications with the browser, as well as many other Communications data encryption. More information can be found on the OpenSSL web site. It's also worth noting that the SSL protocol can be used to pass many other common protocols, “wrapping” them for security. See the sslwrap web page.
S-HTTP: - S-HTTP is another protocol which provides security services across the Internet. It was designed to provide confidentiality, authentication, integrity, and non-repudiability [cannot be mistaken for someone else] while supporting multiple key-management mechanisms and cryptographic algorithms via option negotiation between the parties involved in each transaction. S-HTTP is limited to the specific software that is implementing it, and encrypts each message individually. [ From RSA Cryptography FAQ, page 138]
S/MIME: - S/MIME, or Secure Multipurpose Internet Mail Extension, is an encryption standard used to encrypt electronic mail and other types of messages on the Internet. It is an open standard developed by RSA. More information on S/MIME can be found at rfc2311.
Along with CIPE, and other forms of data encryption, there are also several other implementations of IPSEC for GNU/Linux. IPSEC is an effort by the IETF to create cryptographically-secure communications at the IP network level, and to provide authentication, integrity, access control, and confidentiality. Information on IPSEC and Internet draft can be found at the ipsec Charter. You can also find links to other protocols involving key management, and an IPSEC mailing list and archives.
The x-kernel GNU/Linux implementation, which was being developed at the University of Arizona, uses an object-based framework for implementing network protocols called x-kernel. Most simply, the x-kernel is a method of passing messages at the kernel level, which makes for an easier implementation. This project is now closed, but contact information can be found on The x-Kernel Project web site.
Another freely-available IPSEC implementation is the GNU/Linux FreeS/WAN IPSEC. Their web page states, “These services allow you to build secure tunnels through untrusted networks. Everything passing through the untrusted net is encrypted by the IPSEC gateway computer and decrypted by the gateway at the other end. The result is Virtual Private Network or VPN. This is a network which is effectively private even though it includes computers at several different sites connected by the insecure Internet.”
It's available for download from the Linux FreeS/WAN web site.
openssh is a suite of programs used as a secure replacement for rlogin, rsh and rcp. It uses public-key cryptography to encrypt communications between two hosts, as well as to authenticate users. It can be used to securely login to a remote host or to copy data between hosts, while preventing man-in-the-middle attacks (session hijacking) and DNS spoofing. It will perform data compression on your connections, and secure X11 communications between hosts.
There are several
ssh implementations now. The original
commercial implementation by can be
found at the
ssh home page available on the
The excellent OpenSSH implementation is based on a early version of the DataFellows ssh and has been totally reworked so as not to include any patented or proprietary parts. It is free and released under a BSD license. It can be found on the OpenSSH web site.
There is also a open source project to re-implement ssh from the ground up called “lsh”. For more information see the LSH web site.
You can also use ssh from your Windows® workstation to your GNU/Linux ssh server. There are several freely available Windows® clients, including PuTTY and a commercial implementation from on the Datafellows web site.
(outdated, see OpenSSL below) is a free implementation of 's
Secure Sockets Layer, developed by Eric Young.
It includes several applications, such as “Secure
telnet”, a module for Apache,
several databases, as well as several algorithms including
DES, IDEA and
Using this library, a secure telnet replacement has been created which does encryption over a telnet connection. Unlike SSH, stelnet uses SSL, the Secure Sockets Layer protocol developed by . You can find Secure telnet and Secure FTP by starting with the SSLeay and SSLapps FAQ.
The OpenSSL Project is based on SSLeay and is intended to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. For more information about this project, consult the OpenSSL home page. There is a large list of applications based on OpenSSL at OpenSSL-related applications.
“The SRP project is developing secure Internet software for free worldwide use. Starting with a fully-secure Telnet and FTP distribution, we hope to supplant weak networked authentication systems with strong replacements that do not sacrifice user-friendliness for security. Security should be the default, not an option!”
For more information, visit the Stanford University web site.
Your version of the Mandriva Linux distribution ships with a unified authentication scheme called PAM. PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries. Configuration of PAM is beyond the scope of this chapter, but be sure to take a look at the PAM web site for more information.
Within a few hours of installing and
configuring your system, you can prevent many attacks before they
even occur. For example, use PAM to disable the
system-wide usage of
.rhosts files in user's
home directories by adding these lines to
# # Disable rsh/rlogin/rexec for users # login auth required pam_rhosts_auth.so no_rhosts
The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet.
CIPE can be used in tunneling, in order to create a Virtual Private Network. Low-level encryption has the advantage that it can be made to work transparently between the two networks connected in the VPN, without any change to application software.
“The IPSEC standards define a set of protocols which can be used (among other things) to build encrypted VPNs. However, IPSEC is a rather heavyweight and complicated protocol set with a lot of options, implementations of the full protocol set are still rarely used and some issues (such as key management) are still not fully resolved. CIPE uses a simpler approach, in which many of the things which can be parameterized (such as the choice of the actual encryption algorithm used) are an install-time fixed choice. This limits flexibility, but allows for a simple (and therefore efficient, and easy to debug...) implementation.”
At the CIPE project web site more information can be found.
Kerberos is an authentication system developed by the at MIT. When a user logs in, Kerberos authenticates that user (using a password), and provides the user with a way to prove their identity to other servers and hosts scattered around the network.
This authentication is then used by
programs such as rlogin to allow the user to
login to other hosts without a password (in place of the
.rhosts file). This authentication method can
also be used by the mail system in order to guarantee that mail is
delivered to the correct person, as well as to guarantee that the
sender is who he claims to be.
Kerberos and the other programs that come with it, prevent users from “spoofing” the system into believing they are someone else. Unfortunately, installing Kerberos is very intrusive, requiring the modification or replacement of numerous standard programs.
Shadow passwords are a means of
keeping your encrypted password information secret from normal
users. Your Mandriva Corporate Server 4 system uses shadow passwords by default, but on
other systems, encrypted passwords are stored in the
/etc/passwd file for all to read. Anyone can
then run password-guesser programs on them and attempt to
determine what they are. Shadow passwords, by contrast, are saved
/etc/shadow file, which only
privileged users can read. You can refer to the Shadow-Password
HOWTO for further information if necessary. It is rather
dated now, and will not be required for distributions supporting
PAM, like your Mandriva Corporate Server 4 system.
Password cracking programs work on a simple idea: they try every word in the dictionary, and then variations on those words, encrypting each one and checking it against your encrypted password. If they get a match they know what your password is.
There are a number of programs out
there...the two most notable of which are
Crack and John the
Ripper (See OpenWall). 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 read
/etc/shadow file, but such holes are
more common than you might think.
Because security is only as strong as the most insecure host, it is worth mentioning that if you have any Windows® computers on your network, you should check out L0phtCrack, a Crack implementation for Windows®. Check out the @stake LC 4 web site.
CFS is a way of encrypting an entire directory tree and allowing users to store encrypted files on them. It uses an NFS server running on the local computer. More information and source code is available on the AT&T web site.
TCFS improves on CFS by adding more integration with the file system, so that it's transparent to users when the file system is encrypted. More information is available on the TCFS web site.
It's important for you to secure
your graphical display to prevent attackers from grabbing your
passwords as you type them, reading documents or information you
are reading on your screen, or even using a hole to gain
root access. Running remote X applications over a
network can also 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 use xhost to specify the hosts that are allowed access to your display. This is not very secure at all, because if someone has access to your computer, they can xhost + their computer and get in easily. Also, if you have to allow access from an untrusted computer, anyone there can compromise your display.
xdm (X Display Manager), or its
KDE counterpart: KDM, to log
in, you get a much better access method: MIT-MAGIC-COOKIE-1. A
128-bit “cookie” is generated and stored in your
.Xauthority file. If you need to allow a
remote computer access to your display, you can use the
xauth command and the information in your
.Xauthority file to provide access to only
that connection. See the Remote-X-Apps mini-howto, available at
Linux Documentation Project web site.
You can also use ssh (see Section 4.6.4, “ssh (Secure SHell) and stelnet”) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no unencrypted data flows across the network.
root in order to access all
your GNU/Linux computer's video hardware. This makes them very
dangerous. If they crash, you typically need to reboot your
computer 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.
The GNU/Linux GGI project is trying to solve several of the problems with video interfaces on GNU/Linux. GGI will move a small piece of the video code into the GNU/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. More information available at the GGI Project web site.
As the kernel controls your computer's networking, it is important that it be very secure, and not be compromised. To prevent some of the latest networking attacks, you should try to keep your kernel version current. You can find new kernels at kernel dot org or from packages updates available through MandrivaUpdate.
There is also an international group providing a single unified cryptographic patch to the mainstream GNU/Linux kernel. This patch provides support for a number of cryptographic subsystems and things which cannot be included in the mainstream kernel due to export restrictions. For more information, visit the GNU/Linux Crypto API web site.
When this document was written, kernel 2.2 was state-of-the-art. Still today, most firewalls still run 2.2. However, with kernel 2.4, a lot of things have changed. Most of the compile options in this chapter are still valid, but the Masquerading and port forwarding have been replaced by iptables. You can find more information on iptables on the Linux Guruz web site.
For 2.2.x kernels, the following
options apply. You should see these options during the kernel
configuration process. Many of the comments here are from
which is the same document that is referenced while using the Help
facility during the
stage of compiling the kernel. Please consult the chapter
Compiling and Installing New Kernels of the Reference Manual for a full
description of the compilation of a brand new kernel.
If you enable IP forwarding, your GNU/Linux box essentially becomes a router. If your computer is on a network, you could be forwarding data from one network to another, and perhaps subverting a firewall that was put there to prevent this from happening. Normal dial-up users will want to disable this, and other users should concentrate on the security implications of doing this. Firewall computers will want this enabled, and used in conjunction with firewall software.
root# echo 1 > /proc/sys/net/ipv4/ip_forward
and disable it with the command:
root# echo 0 > /proc/sys/net/ipv4/ip_forward
A “SYN Attack” is a denial of service (DoS) attack which consumes all the resources on your computer, forcing you to reboot. We can't think of a reason you wouldn't normally enable this. In the 2.1 kernel series this config option merely allows syn cookies, but does not enable them. To enable them, you have to do:
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>
This option should be enabled. Source routed frames contain the entire path to their destination inside of the packet. This means that routers through which the packet goes do not need to inspect it, and just forward it on. This could lead to data entering your system which may be potential exploits.
If one of the computers on your local network for which your GNU/Linux box acts as a firewall wants to send something to the outside, your box can “masquerade” as that host, i.e., it forwards the traffic to the intended destination, but makes it look like it came from the firewall box itself. See the Indyramp web site for more information.
This enables your GNU/Linux firewall to transparently redirect any network traffic originating from the local network and destined for a remote host to a local server, called a “transparent proxy server”. This makes the local computers think they are talking to the remote end, while in fact they are connected to the local proxy. See the IP Masquerade HOWTO for more information.
Generally this option is disabled, but if you are building a firewall or a masquerading host, you will want to enable it. When data is sent from one host to another, it does not always get sent as a single packet of data, but rather it is fragmented into several pieces. The problem with this is that the port numbers are only stored in the first fragment. This means that someone can insert information into the remaining packets which isn't supposed to be there. It could also prevent a teardrop attack against an internal host which is not itself patched against it.
This is a really neat option which allows you to analyze the first 128 bytes of the packets in a user-space program, to determine if you would like to accept or deny the packet, based on its validity.
For most people, it's safe to say no to this option. This option allows you to connect a user-space filter to any socket and determine if packets should be allowed or denied. Unless you have a very specific need and are capable of programming such a filter, you should say no. Also note that as of this writing, all protocols were supported except TCP.
Port Forwarding is an addition to IP Masquerading which allows some forwarding of packets from outside to inside a firewall on given ports. This could be useful if, for example, you want to run a web server behind the firewall or masquerading host and that web server should be accessible from the outside world. An external client sends a request to port 80 of the firewall, the firewall forwards this request to the web server, the web server handles the request and the results are sent through the firewall to the original client. The client thinks that the firewall computer itself is running the web server. This can also be used for load balancing if you have a farm of identical web servers behind the firewall. Information about this feature is available from monmouth.
Using this option, user-space
programs can attach a filter to any socket and thereby tell the
kernel that it should allow or disallow certain types of data
to get through the socket. GNU/Linux socket filtering works on
all socket types except TCP for now. See the
for more information.
/dev/urandom should be secure enough to
use in generating PGP keys,
ssh challenges, and other applications where
secure random numbers are required. Attackers should be unable to
predict the next number given any initial sequence of numbers from
these sources. There has been a lot of effort put in to ensuring
that the numbers you get from these sources are random in every
sense of the word.
The only difference
between the two devices, is that
can run out of random bytes and makes you wait for more to be
accumulated Note that on some systems, it can block for a long
time waiting for new user-generated entropy to be entered into the
system. So you have to use care before using
/dev/random. Perhaps the best thing to do is
to use it when you're generating sensitive keying information, and
you tell the user to pound on the keyboard repeatedly until you
print out “OK, enough”.
root# head -c 6 /dev/urandom | mimencode
This will print six random characters on the console, suitable for
password generation. You can find mimencode in
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 shipped with your Mandriva Linux distribution, either in the main CD-ROM, contribs, or through the FTP crypto server (see above).
One of the most common
ways intruders gain access to systems on your network is by
employing a packet sniffer on a already compromised host. This
"sniffer" just listens on the
Ethernet port for
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
login on Host Z.
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 GNU/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 GNU/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
restart your inetd service.
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 computer 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 use the common
FTP port and would still work fine.
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
protocols are extremely insecure and have been the cause of
exploits in the past.
You should check your
/etc/rc.d/rc[0-9].d, and see if any of the
servers started in that directory are not needed. The files in
that directory are actually symbolic links to files in the
/etc/rc.d/init.d. Renaming the
files in the
init.d directory disables all
the symbolic links which 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
K, like this:
root# cd /etc/rc6.d root# mv S45dhcpd K45dhcpd
Your Mandriva Linux
distribution ships with a tcp_wrapper
“wrapping” all your TCP
services. The tcp_wrapper (tcpd) is
invoked from inetd instead of the real
server. tcpd then checks the host 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 edit
/etc/hosts.allow and add in only those hosts
which need to have access to your computer'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 computer, 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
Bear 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 computer. You can use netstat -ta to find a list of all the services your computer is offering.
Keeping up-to-date DNS information about all of the 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 reject connections from hosts that do not have valid DNS entries.
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 not 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.
identd that ships with most distributions is
more configurable than many people think. You can disable it for
specific users (they can make a
file), you can log all identd requests (Which
we recommend), you can even have identd return a UID instead of
a user name or even
There are a number of software packages out there that do port and service-based scanning of computers or networks. SATAN, ISS, SAINT, and Nessus are some of the more well-known ones. This software connects to the target computer (or all the target computers on a network) on as many of the ports as they can, and try to determine what services are running. Based on this information, you can tell if the computer is vulnerable to specific exploits 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 computer or a network of computers. It's a good idea to get SATAN and scan your computer or network, and fix any 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 on the net (see the Trouble web site). Note that SATAN has not been updated in quite a while, and some of the other tools below may do a better job.
SAINTTM is an 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 the SAINT home page.
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 the Nessus web site.
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, 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.
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 which _has 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 SNORTTM, which is a free IDS (Intrusion Detection System), which can detect other network intrusions.
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 GNU/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 GNU/Linux kernels (2.0.30 and up) have several configurable options to prevent SYN flood attacks from denying people access to your computer or services. See Section 4.7, “Kernel Security” for proper kernel protection options.
Ping Flooding - Ping flooding is a simple brute-force denial of service attack. The attacker sends a “flood” of ICMP packets to your computer. If they are doing this from a host with better bandwidth than yours, your computer will be unable to send anything on the network. A variation on this attack, called “smurfing”, sends ICMP packets to a host with your computer's return IP, allowing them to flood you less detectably. You can find more information about the “smurf” attack on the Linux Security web site.
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.
Death - The Ping o' Death attack sends
ICMP ECHO REQUEST packets that are too
large for 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.
You can find code for most exploits, and a more in-depth descriptions of how they work, on the Insecure web site using their search engine.
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. GNU/Linux computers make pretty good firewalls. Firewall code can be built right into 2.0 and higher kernels. The user-space tools ipchains for 2.2 kernels, and iptables for 2.4 kernels, allow 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 computers behind it. This is a fatal mistake. Check out the very good Firewall HOWTO for more information on firewalls and GNU/Linux.
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 or other on-line firewall documents are mandatory reading. Check out the O'Reilly site 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 on the Computer Security Resource Center (CSRC) web site. Also of interest are:
VPNs are a way to establish a “virtual” network on top of some already existing network. This virtual network is often encrypted and passes traffic only to and from some known entities that have joined the network. VPN's are often used to connect someone working at home over the public Internet to a internal company network.
Ok, so you have checked over your system, and determined that it is as secure as feasible, and you're ready to put it on-line. There are a few things you should now do in order to prepare for an intrusion, so you can quickly disable the intruder, and get back up and running.
If you have less than 650MB of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time), you will of course need at least 650MB of space to make the image. Tapes and other re-writable media should be write-protected as soon as your backup is complete, and then verified to prevent tampering. Make sure you store your backups in a secure off-line area. A good backup will ensure that you have a known good point to restore your system from.
A six-tape cycle is easy to maintain. This includes four tapes for during the week, one tape for even Fridays, and one tape for odd Fridays. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particularly important changes or add some important data to your system, a full backup might well be in order.
You should do periodic tests of your backups to make sure they are working as you might expect them to. Restores of files and checking against the real data, sizes and listings of backups, and reading old backups should be done on a regular basis.
In the event of an intrusion, you can use your RPM database like you would use tripwire, but only if you can be sure that it has not been modified. You should copy the RPM database to a floppy, and keep this copy off-line at all times.
root# rpm -Va
to verify each file on the system. See the rpm man page, as there are a few other options which can be included to make it less verbose. Bear in mind that you must also be sure your RPM binary has not been compromised.
If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things appeared to be tampered with. Are there large periods of time which cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea.
Intruders typically modify log files
in order to cover their tracks, but they should still be checked
for strange happenings. You may notice the intruder attempting to
gain entrance, or exploit a program in order to obtain the
root account. You might see log entries before the
intruder has time to modify them.
If possible, configure
syslog to send a copy of the most important
data to a secure system. This will prevent an intruder from
covering his tracks by deleting his
login/su/ftp, etc attempts. See the
syslog.conf man page, and refer to the
There are several more advanced syslogd programs out there. Take a look at the SDSC Syslog Home Page for Secure Syslog. Secure Syslog allows you to encrypt your syslog entries and make sure no one has tampered with them.
syslogd with more features is syslog-ng.
It allows you a lot more flexibility in your logging and can also
encrypt your remote
syslog streams to prevent
Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files, and get a feeling for what they look like on a normal day. Knowing this can help make unusual things stand out.
Most users install their systems from CD-ROM. Due to the fast-paced nature of security fixes, new (fixed) programs are always being released. Before you connect your computer to the network, it's a good idea to run MandrivaUpdate (on another computer connected to the Internet) and get all the updated packages since you received your distribution CD-ROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.
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, you might have spotted someone trying to open a case or reboot a computer. Depending on your own level of 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 normally log 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 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 computers), the next best step is to use something
ipfwadm to deny access from the intruder's
If you can't deny all
people from the same site as the intruder, locking that user's
account will have to do. Note that locking an account is not an
easy thing. You have to keep in mind
files, FTP access, and a host of possible back doors.
If you are able to determine what means the attacker used to get into your system, you should try to close that hole. For instance, perhaps you see several FTP entries just before the user logged in. Disable the FTP service and check to see if there is an updated version, or if 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. You can find your Mandriva Linux security fixes by running the MandrakeUpdate regularly.
“We are attempting a
systematic audit of GNU/Linux sources with a view to being as
secure as OpenBSD. We have already
uncovered (and fixed) some problems, but more help is welcome.
The list is unmoderated and also a useful resource for general
security discussions. The list address is:
subscribe, send a mail to:
If you don't lock the attacker out, they will likely be back. Not just back on your computer, but back somewhere on your network. If they were running a packet sniffer, odds are good they have access to other local computers.
The first thing is to assess the damage. What has been compromised? If you are running an Integrity Checker like Tripwire, you can use it to perform a file integrity check; this should help to show you what has been compromised. If not, you will have to look around at all your important data.
Since GNU/Linux systems are getting easier and easier to install, you might consider saving your config files, wiping your disk(s), reinstalling, then restoring your user files and your config files from backups. This will ensure that you have a new, clean system. If you have to backup files from the compromised system, be especially cautious of any binaries that you restore, as they may be Trojan horses placed there by the intruder.
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 too, 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.
You should report the attack to the admin contact at the site from which the attacker attacked your system. You can look up this contact with whois or the 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 crackers 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).
There are a lot of good sites out there for UNIX® security in general and GNU/Linux security specifically. It is 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.
The Linux Security web site has numerous Linux and open source security references written by the Linux Security staff and people collectively around the world.
Linux Advisory Watch — A comprehensive newsletter that outlines the security vulnerabilities that have been announced throughout the week. It includes pointers to updated packages and descriptions of each vulnerability.
Linux Security Week — The purpose of this document is to provide readers with a quick summary of each week's most relevant Linux security headlines.
Linux Security Discussion List — This mailing list is for general security-related questions and comments.
Linux Security Newsletters — Subscription information for all newsletters.
comp.os.linux.security FAQ — Frequently Asked
Questions with answers for the
Linux Security Documentation — A great starting point for information pertaining to Linux and Open Source security.
CERT is the Computer Emergency Response Team. They often send out alerts of current attacks and fixes. See the CERT web site for more information.
ZEDZ (formerly Replay) has archives of many security programs. Since they are outside the US, they do not need to obey US crypto restrictions.
Matt Blaze is the author of CFS and a great security advocate. Matt's archive is available on the AT&T web site.
The Hacker FAQ is a FAQ about hackers available on the Plethora web site.
The COAST archive has a large number of UNIX® security programs and information. It is available at CERIAS.
Security Page available at SuSE.
BUGTRAQ puts out advisories on
security issues, available on Security
CERT, the Computer Emergency Response Team, puts out advisories on common attacks on UNIX® platforms available at CERT.
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 available on the Trouble web site.
CIAC sends out periodic security bulletins on common exploits. See CIAC for more information.
A good starting point for GNU/Linux Pluggable Authentication modules can be found on The Linux Kernel Archives.
WWW Security FAQ, written by Lincoln Stein, is a great web security reference. Find it on the W3C web site.
Mandriva Security Advisories is Mandriva Linux official security page, notably holding new advisories, End of life product support policy, etc.
Mandriva Linux security lists. You can be informed for each security fix by subscribing to our security mailing-lists.
There are a number of good security books out there. This section lists a few of them. In addition to the security specific books, security is covered in a number of other books on system administration.
Maximum Linux Security: A Hacker's Guide to Protecting Your Linux Server And Network. July 1999. ISBN 0672313413.
However, in order to load modules,
you must be
Modules are for dynamically loading support for a particular device that may be infrequently used. On server computers, or firewalls for instance, this is very unlikely to happen. For this reason, it would make more sense to compile support directly into the kernel for machines acting as servers. Modules are also slower than support compiled directly in the kernel.
See Section 4.4.2, “Root Security”. This is done intentionally to prevent
remote users from attempting to connect via
telnet to your computer as
Simply install the package
You might also try ZEDZ net which has many pre-built packages, and is located outside of the United States.
I bet you did not know about Apache Week, did you?
draksec is a graphical interface to msec (which stands for Mandriva Linux Security Tool). It allows you to change your system's security level and to configure every option of msec's security features.
msec has two aspects: system behavior configuration and periodic checks of system state. Each security level modifies the system configuration, making it more and more secure, and verifying more and more security related aspects.
Simply choose the security level you want from the Security Level pull-down list: it will be effective as soon as you click on . Please read the help text regarding security levels very carefully so that you know what setting a specific security level implies.
If you wish to check which options are activated for each security level, review the other tabs: Network Options, System Options and Periodic Checks. Click on the button to display information about the options and their default values. If some of the default options don't suit your needs, simply redefine them. See Section 18.104.22.168, “Customizing a Security Level”, for details.
Clicking on each of the Options tabs (and the Periodic Checks one) lead you to msec's list of security options. This allows you to define your own security level based on the security level previously chosen.
Options List. All available options are listed.
Value. For each option you can choose from the corresponding pull-down menu:
Yes. Activate this option no matter what the default value is.
No. Deactivate this option no matter what the default value is.
Default. Keep the default security level behavior.
Ignore. Use this option if you don't wish this test to be performed.
ALL, LOCAL, NONE. The meaning of these are option-dependent. Please see the Help text available through thebutton for more information.
drakperm allows you to customize the permissions which should be associated with each file and directory in your system: configuration files, personal files, applications, etc. If the owners and permissions listed here don't match the actual permissions of the system's files, then msec (which stands for Mandriva Linux Security Tool) will change them during its hourly checks. These modifications can help prevent possible security holes or intrusions.
The list of files and directories which appears depends on the current system's security level as set by msec, along with their expected permissions for that security level. For each entry (Path) exists a corresponding owner (User), owner group (Group) and Permissions. In the drop-down menu, you can choose to display only msec rules (System settings), your own user-defined rules (Custom settings) or both as in the example shown in Figure 5.11, “Configuring File-Permission Checks”.
Let's imagine your current
security level is set to
3 (high). This means
that only the owners of the home directories can browse them. If you
wish to share the content of Queen's home directory with
other users, you need to modify the permissions of the
By subscribing to the security alert mailing lists, and keeping current, you can do a lot towards securing your computer. 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 computer. More effort is required on business computers, but GNU/Linux can indeed be a secure platform. Due to the nature of GNU/Linux development, security fixes often come out much faster than they do on commercial operating systems, making GNU/Linux an ideal platform when security is a requirement.
Included below are several of the most frequently used terms in computer security. A comprehensive dictionary of computer security terms is available in the Linux Security Dictionary
A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projects on the outer walls of medieval castles. Bastions overlook critical areas of defense, usually having strong walls, room for extra troops, and the occasional useful tub of boiling oil for discouraging attackers. Some reasonable definition here.
Common coding style is to never allocate large enough buffers, and to not check for overflows. When such buffers overflow, the executing program (daemon or set-uid program) can be tricked in doing some other things. Generally this works by overwriting a function's return address on the stack to point to another location.
IP Spoofing is a complex technical attack which is made up of several components. It is a security exploit that works by tricking computers in a trust relationship into thinking that you really are someone you are not. There is an extensive paper written by daemon9, route, and infinity in the Volume Seven, Issue Forty-Eight of Phrack Magazine.
The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice-versa). To accomplish packet filtering, you set up rules which specify what types of packets (those to or from a particular IP address or port) are to be allowed and what types are to be blocked.
A program which deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests to real servers, and relay answers back to clients.
 The default security level setting is shown in the window.