This document is copyrighted (c) 1998 - 2000 Kevin Fenzi and Dave Wreski.

Modifications from v2.0, 11 June 2002, (C)opyright 2000-2004 Mandriva

and distributed under the following terms:

This chapter covers some of the main issues which affect GNU/Linux security. General philosophy and net-born resources are also discussed.

A number of other HOWTO documents overlap with security issues, and those documents have been pointed to wherever appropriate.

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.

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.

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.

A generally-accepted security policy starts with the phrase:

“That which is not permitted is prohibited.”

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.

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 two main points to understand when reading this chapter are:

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.

	Note
	If you have a server computer, and you set 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.

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.

OpenBoot is much more advanced than a PC BIOS when it comes to security (consult the “Installation Guide” on how to access and use OpenBoot).

	Note
	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.

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.

If you are using security in conjunction with a bootloader, you might as well disable booting from a floppy in your computer's BIOS, and password-protect the BIOS.

If you are using security in conjunction with a bootloader, you might as well password-protect the PROM.

	Note
	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!

password very_secret /boot/grub/menu2.lst

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.

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 discrepancies.

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.

Some things to check for in your logs:

We will discuss system log data in Section 4.9.5, “Keep Track of your System Accounting Data”.

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.

Several good rules of thumb when allowing other people legitimate access to your GNU/Linux computer:

Many local user accounts which are utilized in security compromises have not been used in months or years. Since no one is using them, they provide the ideal attack vehicle.

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 the 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 be.

Several tricks to avoid messing up your own box as root:

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 root. This 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.

Although 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 offers a 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 could allow root to be exploited. Consider sudo as a means for accountability, and don't expect it to replace the root user and still be secure.

The 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 022, 027, and 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 mask of 111. For example, you may have a line that looks like this:

# Set the user's default umask
umask 033

Be sure to make root's umask 077, which will disable read, write, and execute permission for other users, unless explicitly changed using chmod. In this case, newly-created directories would have 744 permissions, obtained by subtracting 033 from 777. Newly-created files using the 033 umask would have permissions of 644.

	Note
	In Mandriva Linux, it is only necessary to use 002 for a umask. This is due to the fact that the default configuration is one user per group.

It is important to ensure that your system files are not open for casual editing by users and groups who should not be doing such system maintenance.

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.

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 a file. Permissions for directories may have a different meaning to the same set of permissions on a file.

Read:

Write:

Execute:

You – The owner of the file.

Group – The group you belong to.

Everyone – Anyone on the system that is not the owner or a member of the group.

File Example:

-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)

Directory Example:

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 in the /etc directory) are usually mode 640 (-rw-r-----), and owned by 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 /etc should 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.

You can even add a crontab entry to run the checker from your floppy every night and mail you the results in the morning. Something like:

# 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 source, 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 a program from its 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.

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.

There are advantages to both public key and private key cryptography, and you can read about those differences in the RSA Cryptography FAQ, listed at the end of this section.

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.

US export controls are now managed by EAR (Export Administration Regulations). They are no longer governed by ITAR.

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.

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.

As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.

ssh and stelnet are suites of programs that allow you to login to remote systems and to have a encrypted connection.

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 Data Fellows can be found at the ssh home page available on the Datafellows web site.

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 DataFellows on the Datafellows web site.

SSLeay (outdated, see OpenSSL below) is a free implementation of Netscape'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 “Blowfish”.

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 Netscape. You can find Secure telnet and Secure FTP by starting with the SSLeay and SSLapps FAQ.

Note

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.

SRP is another secure telnet/ftp implementation. From their web page:

“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.

Just a few of the things you can do with PAM:

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 /etc/pam.d/rlogin:

#
# 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 encrypts the data at the network level. Packets traveling between hosts on the network are encrypted. The encryption engine is placed near the driver which sends and receives packets.

This is unlike SSH, which encrypts the data by connection, at the socket level. A logical connection between programs running on different hosts is encrypted.

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.

Summarized from the CIPE documentation:

“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.

As with other forms of cryptography, it is not distributed with the kernel by default due to export restrictions.

Kerberos is an authentication system developed by the Athena Project 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.

You can find more information about Kerberos by looking at the Kerberos FAQ, and the code can be found on the Kerberos web site.

[From: Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos: An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]

Kerberos should not be your first step to improve the security of your host. It is quite evolved, and not as widely used as, say, SSH.

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 in the /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.

If for some reason your passwd program is not enforcing hard-to-guess 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, 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 your /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 also need not be used on entire file systems. It works on directory trees as well.

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 /usr/src/linux/Documentation/Configure.help, which is the same document that is referenced while using the Help facility during the make config 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.

There are a few block and character devices available on GNU/Linux which can also help you with security.

The two devices /dev/random and /dev/urandom are provided by the kernel to provide random data at any time.

Both /dev/random and /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 /dev/random 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”.

/dev/random is high quality entropy, generated from measuring the inter-interrupt times etc. It blocks until enough bits of random data are available.

/dev/urandom is similar, but when the store of entropy is running low, it will return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications.

You might read from the devices using something like:

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 the metamail package.

See /usr/src/linux/drivers/char/random.c for a description of the algorithm.

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 things like passwd and login and su in the packet stream and then logs the traffic after that. This way, attackers gain passwords for systems they are not even attempting to break into. Clear-text passwords are very vulnerable to this attack.

Example: Host A has been compromised. Attacker installs a sniffer. Sniffer picks up admin logging into Host B from Host C. It gets the admins personal password as they login to B. Then, the admin does a su to fix a problem. They now have the root password for Host B. Later the admin lets someone telnet from his account to Host Z on another site. Now the attacker has a password/login on Host Z.

In this day and age, the attacker doesn't even need to compromise a system to do this: they could also bring a computer (portable or not) into a building and tap into your net.

Using ssh or other encrypted password methods thwarts this attack. Things like APOP for POP accounts also prevents this attack. Normal POP logins are very vulnerable to this, as is anything that sends clear-text passwords over the network.

Before you put your 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.

Some of the services you might want to leave enabled are:

If you know you are not going to use some particular package, you can also delete it entirely. rpm -e packagename or urpme packagename will erase an entire package.

Additionally, you really want to disable the rsh/rlogin/rcp utilities, including login (used by rlogin), shell (used by rcp), and exec (used by rsh) from being started in /etc/inetd.conf. These protocols are extremely insecure and have been the cause of exploits in the past.

You should check 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 directory /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 S with a K, like this:

root#  cd /etc/rc6.d
root#  mv S45dhcpd K45dhcpd

	Note
	You may also use a command line utility to do that: chkconfig or the graphical interface under KDE: ksysv.

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 /etc/hosts.allow:

ALL: 127.

And of course /etc/hosts.deny would contain:

ALL: ALL

which will prevent external connections to your computer, yet still allow you from the inside to connect to servers on the Internet.

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.

identd is a small program that typically runs out of your inetd server. It keeps track of which user is running which TCP services, and can then report this to whoever requests this information.

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.

The identd that ships with most distributions is more configurable than many people think. You can disable it for specific users (they can make a .noident file), you can log all identd requests (Which we recommend), you can even have identd return a UID instead of a user name or even NO-USER.

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.

ISS (Internet Security Scanner) is another port-based scanner. It is faster than Satan, and thus may be better for large networks. However, SATAN tends to provide more information.

SAINT^TM 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.

A “Denial of Service” (DoS) attack is one where the attacker tries to make some resource too busy to answer legitimate requests, or to deny legitimate users access to a computer or network.

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.

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 O'Reilly and Associates 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.

There are several GNU/Linux VPN solutions available:

Also see the section on IPSEC for more pointers and information.

Discussion of backup methods and storage is beyond the scope of this chapter, but here are a few words relating to backups and security:

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.

The files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm probably will not fit on a single floppy. But if compressed, each should fit on a separate floppy.

Now, when your system is compromised, you can use the command:

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.

This means that every time a new RPM is added to the system, the RPM database will need to be re-archived. You will have to decide the advantages versus drawbacks.

It is very important that the information that comes from syslog has not been compromised. Making the files in /var/log readable and writable by only a limited number of users is a good start.

Be sure to keep an eye on what gets written there, especially under the auth facility. Multiple login failures, for example, can indicate an attempted break-in.

You will want to look in /var/log and check messages, mail.log, and others.

You may also want to configure your log-rotating script to keep logs around longer so you have time to examine them. Take a look at logrotate(8).

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.

You should also be sure to separate the auth facility from other log data, including attempts to switch users using su, login attempts, and other user accounting information.

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 @ option.

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.

Another 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 tampering.

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.

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, 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, 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 computers), the next best step is to use something like tcp_wrappers or ipfwadm to deny access from the intruder's site.

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 .rhosts files, FTP access, and a host of possible back doors.

After you have done one of the above (disconnected the 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 to get back in. Perhaps using a different account, and/or from a different network address.

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?

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.

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.

Mandriva Linux security lists. You can be informed for each security fix by subscribing to our security 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: “subscribe ciac-bulletin”

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.

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.

4.13.1.1. Setting your Security Level

	Note
	This tool is only displayed in expert mode. Choose Options → Expert mode from the menu and then access the Security section of Mandriva Linux Control Center.

Figure 5.9. Choosing the Security Level of your System

Simply choose the security level you want from the Security Level pull-down list: it will be effective as soon as you click on OK. Please read the help text regarding security levels very carefully so that you know what setting a specific security level implies.

	Tip
	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 Help 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 4.13.1.2, “Customizing a Security Level”, for details.

Put a check mark on the Security Alerts box to send by mail possible security issues found by msec to the local user name or to the e-mail address defined in the Security Administrator field.

	Warning
	We highly recommend you activate the security alerts option so that the administrator is immediately informed of possible security issues. Otherwise, the administrator will have to regularly check the relevant system log files.

4.13.1.2. Customizing a Security Level

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.

Figure 5.10. Modifying Standard Options

For each tab, there are two columns:

1. Options List. All available options are listed.

2. Value. For each option^[1] 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 the Help button for more information.

Clicking on OK accepts the current security level with custom options, applies it to the system and exits the application.

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.

	Note
	This tool is accessible only in expert mode. Choose Options → Expert mode from the menu and then access the Security section of Mandriva Linux Control Center.

Figure 5.11. Configuring File-Permission Checks

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”.

	Note
	You cannot edit system rules, as stated by the “Do not enter” sign on the left. However you can override them by adding custom rules.

If you wish to add your own rules for specific files or modify the default behavior, display the Custom settings list and click on the Add a rule button.

Figure 5.12. Adding a File-Permissions Rule

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 /home/queen/ directory.

	Warning
	msec only changes file permissions that are more permissive than the one required by a certain security level. That means that for the change above, the permissions must be changed by hand. You can do this in Konqueror by modifying the permission properties of your home directory, and checking the Apply changes to all sub-folders and their contents option.

If you create more rules, you can change their priorities by moving them up and down the rules list: use the Up and Down buttons on your custom rules to have more control over your system's permissions.