LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/text/Security-HOWTO

3257 lines
152 KiB
Plaintext
Raw Permalink Blame History

Linux Security HOWTO
Kevin Fenzi
tummy.com, ltd.
<kevin-securityhowto@tummy.com>
Dave Wreski
linuxsecurity.com
<dave@linuxsecurity.com>
v2.3, 22 January 2004
This document is a general overview of security issues that face the
administrator of Linux systems. It covers general security philosophy and a
number of specific examples of how to better secure your Linux system from
intruders. Also included are pointers to security-related material and
programs. Improvements, constructive criticism, additions and corrections are
gratefully accepted. Please mail your feedback to both authors, with
"Security HOWTO" in the subject.
-----------------------------------------------------------------------------
Table of Contents
1. Introduction
1.1. New Versions of this Document
1.2. Feedback
1.3. Disclaimer
1.4. Copyright Information
2. Overview
2.1. Why Do We Need Security?
2.2. How Secure Is Secure?
2.3. What Are You Trying to Protect?
2.4. Developing A Security Policy
2.5. Means of Securing Your Site
2.6. Organization of This Document
3. Physical Security
3.1. Computer locks
3.2. BIOS Security
3.3. Boot Loader Security
3.4. xlock and vlock
3.5. Security of local devices
3.6. Detecting Physical Security Compromises
4. Local Security
4.1. Creating New Accounts
4.2. Root Security
5. Files and File system Security
5.1. Umask Settings
5.2. File Permissions
5.3. Integrity Checking
5.4. Trojan Horses
6. Password Security and Encryption
6.1. PGP and Public-Key Cryptography
6.2. SSL, S-HTTP and S/MIME
6.3. Linux IPSEC Implementations
6.4. ssh (Secure Shell) and stelnet
6.5. PAM - Pluggable Authentication Modules
6.6. Cryptographic IP Encapsulation (CIPE)
6.7. Kerberos
6.8. Shadow Passwords.
6.9. "Crack" and "John the Ripper"
6.10. CFS - Cryptographic File System and TCFS - Transparent
Cryptographic File System
6.11. X11, SVGA and display security
7. Kernel Security
7.1. 2.0 Kernel Compile Options
7.2. 2.2 Kernel Compile Options
7.3. Kernel Devices
8. Network Security
8.1. Packet Sniffers
8.2. System services and tcp_wrappers
8.3. Verify Your DNS Information
8.4. identd
8.5. Configuring and Securing the Postfix MTA
8.6. SATAN, ISS, and Other Network Scanners
8.7. sendmail, qmail and MTA's
8.8. Denial of Service Attacks
8.9. NFS (Network File System) Security.
8.10. NIS (Network Information Service) (formerly YP).
8.11. Firewalls
8.12. IP Chains - Linux Kernel 2.2.x Firewalling
8.13. Netfilter - Linux Kernel 2.4.x Firewalling
8.14. VPNs - Virtual Private Networks
9. Security Preparation (before you go on-line)
9.1. Make a Full Backup of Your Machine
9.2. Choosing a Good Backup Schedule
9.3. Testing your backups
9.4. Backup Your RPM or Debian File Database
9.5. Keep Track of Your System Accounting Data
9.6. Apply All New System Updates.
10. What To Do During and After a Breakin
10.1. Security Compromise Underway.
10.2. Security Compromise has already happened
11. Security Sources
11.1. LinuxSecurity.com References
11.2. FTP Sites
11.3. Web Sites
11.4. Mailing Lists
11.5. Books - Printed Reading Material
12. Glossary
13. Frequently Asked Questions
14. Conclusion
15. Acknowledgments
1. Introduction
This document covers some of the main issues that affect Linux security.
General philosophy and net-born resources are discussed.
A number of other HOWTO documents overlap with security issues, and those
documents have been pointed to wherever appropriate.
This document is not meant to be a up-to-date exploits document. Large
numbers of new exploits happen all the time. This document will tell you
where to look for such up-to-date information, and will give some general
methods to prevent such exploits from taking place.
-----------------------------------------------------------------------------
1.1. New Versions of this Document
New versions of this document will be periodically posted to
comp.os.linux.answers. They will also be added to the various sites that
archive such information, including:
[http://www.linuxdoc.org/] http://www.linuxdoc.org/
The very latest version of this document should also be available in various
formats from:
<EFBFBD><EFBFBD>*<2A> [http://scrye.com/~kevin/lsh/] http://scrye.com/~kevin/lsh/
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/docs/Security-HOWTO] http://
www.linuxsecurity.com/docs/Security-HOWTO
<EFBFBD><EFBFBD>*<2A> [http://www.tummy.com/security-howto] http://www.tummy.com/
security-howto
-----------------------------------------------------------------------------
1.2. Feedback
All comments, error reports, additional information and criticism of all
sorts should be directed to:
[mailto:kevin-securityhowto@tummy.com] kevin-securityhowto@tummy.com
and
[mailto:dave@linuxsecurity.com] dave@linuxsecurity.com
Note: Please send your feedback to both authors. Also, be sure and include
"Linux" "security", or "HOWTO" in your subject to avoid Kevin's spam filter.
-----------------------------------------------------------------------------
1.3. Disclaimer
No liability for the contents of this document can be accepted. Use the
concepts, examples and other content at your own risk. Additionally, this is
an early version, possibly with many inaccuracies or errors.
A number of the examples and descriptions use the RedHat(tm) package layout
and system setup. Your mileage may vary.
As far as we know, only programs that, under certain terms may be used or
evaluated for personal purposes will be described. Most of the programs will
be available, complete with source, under [http://www.gnu.org/copyleft/
gpl.html] GNU terms.
-----------------------------------------------------------------------------
1.4. Copyright Information
This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski, and
distributed under the following terms:
<EFBFBD><EFBFBD>*<2A> 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.
<EFBFBD><EFBFBD>*<2A> 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.
<EFBFBD><EFBFBD>*<2A> If you have questions, please contact Tim Bynum, the Linux HOWTO
coordinator, at
[mailto:tjbynum@metalab.unc.edu] tjbynum@metalab.unc.edu
-----------------------------------------------------------------------------
2. Overview
This document will attempt to explain some procedures and commonly-used
software to help your 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.
-----------------------------------------------------------------------------
2.1. Why Do We Need Security?
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, and
even alter, it. 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 then use
advanced knowledge to impersonate you, steal information from you, or even
deny you access to your own resources. If you're wondering what the
difference is between a "Hacker" and a "Cracker", see Eric Raymond's
document, "How to Become A Hacker", available at [http://www.catb.org/~esr/
faqs/hacker-howto.html] http://www.catb.org/~esr/faqs/hacker-howto.html.
-----------------------------------------------------------------------------
2.2. How Secure Is Secure?
First, keep 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 Linux user, not much is required to keep
the casual cracker at bay. However, for high-profile 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
login. You could also setup your Linux system with no network or connection
to the Internet, but this limits its usefulness.
If you are a medium to large-sized site, you should establish a security
policy stating how much security is required by your site and what auditing
is in place to check it. You can find a well-known security policy example at
[http://www.faqs.org/rfcs/rfc2196.html] http://www.faqs.org/rfcs/
rfc2196.html. It has been recently updated, and contains a great framework
for establishing a security policy for your company.
-----------------------------------------------------------------------------
2.3. What Are You Trying to Protect?
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.
<EFBFBD><EFBFBD>*<2A> 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
login 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 account.
<EFBFBD><EFBFBD>*<2A> Threat is typically from someone with motivation to gain unauthorized
access to your network or computer. You must decide whom you trust to
have access to your system, and what threat they could pose.
There are several types of intruders, and it is useful to keep their
different characteristics in mind as you are securing your systems.
<20><>+<2B> The Curious - This type of intruder is basically interested in
finding out what type of system and data you have.
<20><>+<2B> The Malicious - This type of intruder is out to either bring down
your systems, or deface your web page, or otherwise force you to
spend time and money recovering from the damage he has caused.
<20><>+<2B> The High-Profile Intruder - This type of intruder is trying to use
your system to gain popularity and infamy. He might use your
high-profile system to advertise his abilities.
<20><>+<2B> The Competition - This type of intruder is interested in what data
you have on your system. It might be someone who thinks you have
something that could benefit him, financially or otherwise.
<20><>+<2B> The Borrowers - This type of intruder is interested in setting up
shop on your system and using its resources for their own purposes.
He typically will run chat or irc servers, porn archive sites, or
even DNS servers.
<20><>+<2B> The Leapfrogger - This type of intruder is only interested in your
system to use it to get into 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.
<EFBFBD><EFBFBD>*<2A> Vulnerability describes how well-protected your computer is from another
network, and the potential for someone to gain unauthorized access.
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?
-----------------------------------------------------------------------------
2.4. Developing A Security Policy
Create a simple, generic policy for your system that your users can readily
understand and follow. It should protect the data you're 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's 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
shouldn't be using that service until you do grant access. Make sure the
policies work on your regular user account. Saying, "Ah, I can't figure out
this permissions problem, I'll just do it as root" can lead to security holes
that are very obvious, and even ones that haven't been exploited yet.
[ftp://www.faqs.org/rfcs/rfc1244.html] rfc1244 is a document that describes
how to create your own network security policy.
[ftp://www.faqs.org/rfcs/rfc1281.html] rfc1281 is a document that shows an
example security policy with detailed descriptions of each step.
Finally, you might want to look at the COAST policy archive at [ftp://
coast.cs.purdue.edu/pub/doc/policy] ftp://coast.cs.purdue.edu/pub/doc/policy
to see what some real-life security policies look like.
-----------------------------------------------------------------------------
2.5. Means of Securing Your Site
This document will discuss various means with which you can secure the
assets you have worked hard for: your local machine, 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 next quarter? If you are
planning a network installation, there are many factors you must take into
account before adding a single machine to your network.
Even if you have a single dial up PPP account, or just a small site, this
does not mean intruders won't 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're connected to.
Intruders have a lot of time on their hands, and can avoid guessing how
you've 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.
-----------------------------------------------------------------------------
2.5.1. Host Security
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 doing.
Although this is absolutely necessary, it can become a daunting task once
your network becomes larger than a few machines.
-----------------------------------------------------------------------------
2.5.2. Local Network Security
Network security is as necessary as local host security. With hundreds,
thousands, or more computers on the same network, you can't rely on each one
of those systems being secure. Ensuring that only authorized users can use
your network, building firewalls, using strong encryption, and ensuring there
are no "rogue" (that is, unsecured) machines on your network are all part of
the network security administrator's duties.
This document will discuss some of the techniques used to secure your site,
and hopefully show you some of the ways to prevent an intruder from gaining
access to what you are trying to protect.
-----------------------------------------------------------------------------
2.5.3. Security Through Obscurity
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 hopes that attackers won't notice
it's there and thus won't exploit it. Rest assured that they can determine
that it's there and will exploit it. Security through obscurity is no
security at all. Simply because you may have a small site, or a relatively
low profile, does not mean an intruder won't be interested in what you have.
We'll discuss what you're protecting in the next sections.
-----------------------------------------------------------------------------
2.6. Organization of This Document
This document has been divided into a number of sections. They cover several
broad security issues. The first, Section 3, covers how you need to protect
your physical machine from tampering. The second, Section 4, describes how to
protect your system from tampering by local users. The third, Section 5,
shows you how to setup your file systems and permissions on your files. The
next, Section 6, discusses how to use encryption to better secure your
machine and network. Section 7 discusses what kernel options you should set
or be aware of for a more secure system. Section 8, describes how to better
secure your Linux system from network attacks. Section 9, discusses how to
prepare your machine(s) before bringing them on-line. Next, Section 10,
discusses what to do when you detect a system compromise in progress or
detect one that has recently happened. In Section 11, some primary security
resources are enumerated. The Q and A section Section 13, answers some
frequently-asked questions, and finally a conclusion in Section 14
The two main points to realize when reading this document are:
<EFBFBD><EFBFBD>*<2A> Be aware of your system. Check system logs such as /var/log/messages and
keep an eye on your system, and
<EFBFBD><EFBFBD>*<2A> Keep your system up-to-date by making sure you have installed the
current versions of software and have upgraded per security alerts. Just
doing this will help make your system markedly more secure.
-----------------------------------------------------------------------------
3. Physical Security
The first layer of security you need to take into account is the physical
security of your computer systems. Who has direct physical access to your
machine? Should they? Can you protect your machine from their tampering?
Should you?
How much physical security you need on your system is very dependent on your
situation, and/or budget.
If you are a home user, you probably don't need a lot (although you might
need to protect your machine from tampering by children or annoying
relatives). If you are in a lab, you need considerably more, but users will
still need to be able to get work done on the machines. Many of the following
sections will help out. If you are in an office, you may or may not need to
secure your machine off-hours or while you are away. At some companies,
leaving your console unsecured is a termination offense.
Obvious physical security methods such as locks on doors, cables, locked
cabinets, and video surveillance are all good ideas, but beyond the scope of
this document. :)
-----------------------------------------------------------------------------
3.1. Computer locks
Many modern PC cases include a "locking" feature. Usually this will be a
socket on the front of the case that allows you to turn an included key to a
locked or unlocked position. Case locks can help prevent someone from
stealing your PC, or opening up the case and directly manipulating/stealing
your hardware. They can also sometimes prevent someone from rebooting your
computer 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 PC's 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.
Some machines (most notably SPARC's and macs) have a dongle on the back
that, if you put a cable through, attackers would have to cut the cable or
break the case to get into it. Just putting a padlock or combo lock through
these can be a good deterrent to someone stealing your machine.
-----------------------------------------------------------------------------
3.2. BIOS Security
The BIOS is the lowest level of software that configures or manipulates your
x86-based hardware. LILO and other Linux boot methods access the BIOS to
determine how to boot up your Linux machine. Other hardware that Linux runs
on has similar software (Open Firmware on Macs and new Suns, Sun boot PROM,
etc...). You can use your BIOS to prevent attackers from rebooting your
machine and manipulating your Linux system.
Many PC BIOSs let you set a boot password. This doesn't provide all that
much security (the BIOS can be reset, or removed if someone can get into the
case), but might be a good deterrent (i.e. it will take time and leave traces
of tampering). Similarly, on S/Linux (Linux for SPARC(tm) processor
machines), your EEPROM can be set to require a boot-up password. This might
slow attackers down.
Another risk of trusting BIOS passwords to secure your system is the default
password problem. Most BIOS makers don't expect people to open up their
computer and disconnect batteries if they forget their password and have
equipped their BIOSes with default passwords that 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' websites and [http://astalavista.box.sk] http:/
/astalavista.box.sk and as such a BIOS password cannot be considered adequate
protection from a knowledgeable attacker.
Many x86 BIOSs 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 BIOSs disallow booting from floppy drives and some require
passwords to access some BIOS features.
Note: If you have a server machine, and you set up a boot password, your
machine will not boot up unattended. Keep in mind that you will need to come
in and supply the password in the event of a power failure. ;(
-----------------------------------------------------------------------------
3.3. Boot Loader Security
The various Linux boot loaders also can have a boot password set. LILO, for
example, has password and restricted settings; password requires password at
boot time, whereas restricted requires a boot-time password only if you
specify options (such as single) at the LILO prompt.
>From the lilo.conf man page:
password=password
The per-image option `password=...' (see below) applies to all images.
restricted
The per-image option `restricted' (see below) applies to all images.
password=password
Protect the image by a password.
restricted
A password is only required to boot the image if
parameters are specified on the command line
(e.g. single).
Keep in mind when setting all these passwords that you need to remember
them. :) Also remember that these passwords will merely slow the determined
attacker. They won't prevent someone from booting from a floppy, and mounting
your root partition. If you are using security in conjunction with a boot
loader, you might as well disable booting from a floppy in your computer's
BIOS, and password-protect the BIOS.
Also keep in mind that the /etc/lilo.conf will need to be mode "600"
(readable and writing for root only), or others will be able to read your
passwords!
>From the GRUB info page: GRUB provides "password" feature, so that only
administrators can start the interactive operations (i.e. editing menu
entries and entering the command-line interface). To use this feature, you
need to run the command `password' in your configuration file (*note
password::), like this:
password --md5 PASSWORD
If this is specified, GRUB disallows any interactive control, until you
press the key <p> and enter a correct password. The option `--md5' tells GRUB
that `PASSWORD' is in MD5 format. If it is omitted, GRUB assumes the
`PASSWORD' is in clear text.
You can encrypt your password with the command `md5crypt' (*note
md5crypt::). For example, run the grub shell (*note Invoking the grub
shell::), and enter your password:
grub> md5crypt Password: ********** Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.
Then, cut and paste the encrypted password to your configuration file.
Grub also has a 'lock' command that will allow you to lock a partition if
you don't provide the correct password. Simply add 'lock' and the partition
will not be accessable until the user supplies a password.
If anyone has security-related information from a different boot loader, we
would love to hear it. (grub, silo, milo, linload, etc).
Note: If you have a server machine, and you set up a boot password, your
machine will not boot up unattended. Keep in mind that you will need to come
in and supply the password in the event of a power failure. ;(
-----------------------------------------------------------------------------
3.4. xlock and vlock
If you wander away from your machine from time to time, it is nice to be
able to "lock" your console so that no one can tamper with, or look at, your
work. Two programs that do this are: xlock and vlock.
xlock is a X display locker. It should be included in any Linux
distributions that support X. Check out the man page for it for more options,
but in general you can run xlock from any xterm on your console and it will
lock the display and require your password to unlock.
vlock is a simple little program that allows you to lock some or all of the
virtual consoles on your Linux box. You can lock just the one you are working
in or all of them. If you just lock one, others can come in and use the
console; they will just not be able to use your virtual console until you
unlock it. vlock ships with RedHat Linux, but your mileage may vary.
Of course locking your console will prevent someone from tampering with your
work, but won't prevent them from rebooting your machine or otherwise
disrupting your work. It also does not prevent them from accessing your
machine from another machine 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 xdm.
-----------------------------------------------------------------------------
3.5. Security of local devices
If you have a webcam or a microphone attached to your system, you should
consider if there is some danger of a 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 with
provides access to such devices.
-----------------------------------------------------------------------------
3.6. Detecting Physical Security Compromises
The first thing to always note is when your machine was rebooted. Since
Linux is a robust and stable OS, the only times your machine should reboot is
when you take it down for OS upgrades, hardware swapping, or the like. If
your machine has rebooted without you doing it, that may be a sign that an
intruder has compromised it. Many of the ways that your machine can be
compromised require the intruder to reboot or power off your machine.
Check for signs of tampering on the case and computer area. Although many
intruders clean traces of their presence out of logs, it's a good idea to
check through them all and note any discrepancy.
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 machine 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 unencrypted, allowing an
intruder to view data as it is being transferred. This may reveal information
about your network that is not intended to be public. There are syslog
daemons available that 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:
<EFBFBD><EFBFBD>*<2A> Short or incomplete logs.
<EFBFBD><EFBFBD>*<2A> Logs containing strange timestamps.
<EFBFBD><EFBFBD>*<2A> Logs with incorrect permissions or ownership.
<EFBFBD><EFBFBD>*<2A> Records of reboots or restarting of services.
<EFBFBD><EFBFBD>*<2A> missing logs.
<EFBFBD><EFBFBD>*<2A> su entries or logins from strange places.
We will discuss system log data Section 9.5 in the HOWTO.
-----------------------------------------------------------------------------
4. Local Security
The next thing to take a look at is the security in your system against
attacks from local users. Did we just say local users? Yes!
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 access to
root access using a variety of bugs and poorly setup local services. If you
make sure your local security is tight, then the intruder will have another
hurdle to jump.
Local users can also cause a lot of havoc with your system even (especially)
if they really are who they say they are. Providing accounts to people you
don't know or for whom you have no contact information is a very bad idea.
-----------------------------------------------------------------------------
4.1. Creating New Accounts
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 Linux machine:
<EFBFBD><EFBFBD>*<2A> Give them the minimal amount of privileges they need.
<EFBFBD><EFBFBD>*<2A> Be aware when/where they login from, or should be logging in from.
<EFBFBD><EFBFBD>*<2A> Make sure you remove inactive accounts, which you can determine by using
the 'last' command and/or checking log files for any activity by the
user.
<EFBFBD><EFBFBD>*<2A> The use of the same userid on all computers and networks is advisable to
ease account maintenance, and permits easier analysis of log data.
<EFBFBD><EFBFBD>*<2A> The creation of group user-id's should be absolutely prohibited. User
accounts also provide accountability, and this is not possible with group
accounts.
Many local user accounts that are used in security compromises have not been
used in months or years. Since no one is using them they, provide the ideal
attack vehicle.
-----------------------------------------------------------------------------
4.2. Root Security
The most sought-after account on your machine is the root (superuser)
account. This account has authority over the entire machine, which may also
include authority over other machines 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:
<EFBFBD><EFBFBD>*<2A> When doing some complex command, try running it first in a
non-destructive way...especially commands that use globing: e.g., if you
want to do rm foo*.bak, first do ls foo*.bak and make sure you are going
to delete the files you think you are. Using echo in place of destructive
commands also sometimes works.
<EFBFBD><EFBFBD>*<2A> Provide your users with a default alias to the rm command to ask for
confirmation for deletion of files.
<EFBFBD><EFBFBD>*<2A> Only become root to do single specific tasks. If you find yourself
trying to figure out how to do something, go back to a normal user shell
until you are sure what needs to be done by root.
<EFBFBD><EFBFBD>*<2A> The command path for the root user is very important. The command path
(that is, the 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 PATH. Additionally, 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.
<EFBFBD><EFBFBD>*<2A> Never use the rlogin/rsh/rexec suite of tools (called the r-utilities)
as root. They are subject to many sorts of attacks, and are downright
dangerous when run as root. Never create a .rhosts file for root.
<EFBFBD><EFBFBD>*<2A> The /etc/securetty file contains a list of terminals that root can login
from. By default (on Red Hat Linux) this is set to only the local virtual
consoles(vtys). Be very wary of adding anything else to this file. You
should be able to login remotely as your regular user account and then su
if you need to (hopefully over Section 6.4 or other encrypted channel),
so there is no need to be able to login directly as root.
<EFBFBD><EFBFBD>*<2A> Always be slow and deliberate running as root. Your actions could affect
a lot of things. Think before you type!
If you absolutely positively need to allow someone (hopefully very trusted)
to have root access to your machine, there are a few tools that can help.
sudo allows users to use their password to access a limited set of commands
as root. This would allow you to, for instance, let a user be able to eject
and mount removable media on your Linux box, but have no other root
privileges. sudo also keeps a log of all 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 keep track of changes made.
Although sudo can be used to give specific users specific privileges for
specific tasks, it does have several shortcomings. It should be used only for
a limited set of tasks, like 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.
-----------------------------------------------------------------------------
5. Files and File system Security
A few minutes of preparation and planning ahead before putting your systems
on-line can help to protect them and the data stored on them.
<EFBFBD><EFBFBD>*<2A> There should never be a reason for users' home directories to allow SUID
/SGID programs to be run from there. Use the nosuid option in /etc/fstab
for partitions that are writable by others than root. You may also wish
to use nodev and noexec on users' home partitions, as well as /var, thus
prohibiting execution of programs, and creation of character or block
devices, which should never be necessary anyway.
<EFBFBD><EFBFBD>*<2A> If you are exporting file-systems using NFS, be sure to configure /etc/
exports with the most restrictive access possible. This means not using
wild cards, not allowing root write access, and exporting read-only
wherever possible.
<EFBFBD><EFBFBD>*<2A> Configure your users' file-creation umask to be as restrictive as
possible. See Section 5.1.
<EFBFBD><EFBFBD>*<2A> If you are mounting file systems using a network file system such as
NFS, be sure to configure /etc/exports with suitable restrictions.
Typically, using `nodev', `nosuid', and perhaps `noexec', are desirable.
<EFBFBD><EFBFBD>*<2A> Set file system limits instead of allowing unlimited as is the default.
You can control the per-user limits using the resource-limits PAM module
and /etc/pam.d/limits.conf. For example, limits for group users might
look like this:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
This says to prohibit the creation of core files, restrict the number of
processes to 50, and restrict memory usage per user to 5M.
You can also use the /etc/login.defs configuration file to set the same
limits.
<EFBFBD><EFBFBD>*<2A> The /var/log/wtmp and /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 644
permissions, without affecting normal system operation.
<EFBFBD><EFBFBD>*<2A> The immutable bit can be used to prevent accidentally deleting or
overwriting a file that must be protected. It also prevents someone from
creating a hard link to the file. See the chattr(1) man page for
information on the immutable bit.
<EFBFBD><EFBFBD>*<2A> 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 SUID-root programs, then leave a SUID program as a back door
to get in the next time, even if the original hole is plugged.
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 \)
The Debian distribution runs a job each night to determine what SUID
files exist. It then compares this to the previous night's run. You can
look in /var/log/setuid* for this log.
You can remove the SUID or SGID permissions on a suspicious program with
chmod, then restore them back if you absolutely feel it is necessary.
<EFBFBD><EFBFBD>*<2A> 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.
<EFBFBD><EFBFBD>*<2A>
Unowned files may also be an indication an intruder has accessed your
system. You can locate files on your system that have no owner, or belong
to no group with the command:
root# find / \( -nouser -o -nogroup \) -print
<EFBFBD><EFBFBD>*<2A> Finding .rhosts files should be a part of your regular system
administration duties, as these files 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
.rhosts files on your system with the following command:
root# find /home -name .rhosts -print
<EFBFBD><EFBFBD>*<2A>
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.
-----------------------------------------------------------------------------
5.1. Umask Settings
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 permissions settings, the user could
inadvertently give read or write permission to someone that should not have
this permission. 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 resulting permission is calculated as
follows: The default permission of user/group/others (7 for directories, 6
for files) is combined with the inverted mask (NOT) using AND on a
per-bit-basis.
Example 1:
file, default 6, binary: 110 mask, eg. 2: 010, NOT: 101
resulting permission, AND: 100 (equals 4, r__)
Example 2:
file, default 6, binary: 110 mask, eg. 6: 110, NOT: 001
resulting permission, AND: 000 (equals 0, ___)
Example 3:
directory, default 7, binary: 111 mask, eg. 2: 010, NOT: 101
resulting permission, AND: 101 (equals 5, r_x)
Example 4:
directory, default 7, binary: 111 mask, eg. 6: 110, NOT: 001
resulting permission, AND: 001 (equals 1, __x)
# 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.
If you are using Red Hat, and adhere to their user and group ID creation
scheme (User Private Groups), 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.
-----------------------------------------------------------------------------
5.2. File Permissions
It's important to ensure that your system files are not open for casual
editing by users and groups who shouldn't 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 it. Permissions for directories may have a different meaning than
the same set of permissions on files.
Read:
<EFBFBD><EFBFBD>*<2A> To be able to view contents of a file
<EFBFBD><EFBFBD>*<2A> To be able to read a directory
Write:
<EFBFBD><EFBFBD>*<2A> To be able to add to or change a file
<EFBFBD><EFBFBD>*<2A> To be able to delete or move files in a directory
Execute:
<EFBFBD><EFBFBD>*<2A> To be able to run a binary program or shell script
<EFBFBD><EFBFBD>*<2A> To be able to search in a directory, combined with read permission
Save Text Attribute: (For directories)
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 the he owns or for
which he has explicit write permission granted, even when he has write
access to the directory. This is designed for directories like /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.
SUID Attribute: (For Files)
This describes set-user-id permissions on the file. When the set user ID
access mode is set in the owner permissions, and the file is executable,
processes which run it are granted access to system resources based on
user who owns the file, as opposed to the user who created the process.
This is the cause of many "buffer overflow" exploits.
SGID Attribute: (For Files)
If set in the group permissions, this bit controls the "set group id"
status of a file. This behaves the same way as SUID, except the group is
affected instead. The file must be executable for this to have any
effect.
SGID Attribute: (For directories)
If you set the SGID bit on a directory (with chmod g+s directory), files
created in that directory will have their group set to the directory's
group.
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 kevin users 114 Aug 28 1997 .zlogin
1st bit - directory? (no)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (no)
5th bit - read by group? (yes, by users)
6th bit - write by group? (no)
7th bit - execute by group? (no)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (no)
The following lines are examples of the minimum sets of permissions that are
required to perform the access described. You may want to give more
permission than what's 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 kevin users 512 Sep 19 13:47 .public_html/
1st bit - directory? (yes, it contains many files)
2nd bit - read by owner? (yes, by kevin)
3rd bit - write by owner? (yes, by kevin)
4th bit - execute by owner? (yes, by kevin)
5th bit - read by group? (yes, by users
6th bit - write by group? (no)
7th bit - execute by group? (yes, by users)
8th bit - read by everyone? (yes, by everyone)
9th bit - write by everyone? (no)
10th bit - execute by everyone? (yes, by everyone)
The following lines are examples of the minimum sets of permissions that are
required to perform the access described. You may want to give more
permission than what's 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 /etc) are usually mode 640
(-rw-r-----), and owned by root. Depending on your site's security
requirements, you might adjust this. Never leave any system files writable by
a group or everyone. Some configuration files, including /etc/shadow, should
only be readable by root, and directories in /etc should at least not be
accessible by others.
SUID Shell Scripts
SUID shell scripts are a serious security risk, and for this reason the
kernel will not honor them. Regardless of how secure you think the shell
script is, it can be exploited to give the cracker a root shell.
-----------------------------------------------------------------------------
5.3. Integrity Checking
Another very good way to detect local (and also network) attacks on your
system is to run an integrity checker like Tripwire, Aide or Osiris. These
integrety checkers run a number of checksums on all your important binaries
and config 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's a good idea to install these sorts of programs onto a floppy, and then
physically set the write protect on the floppy. This way intruders can't
tamper with the integrety checker itself or change the database. Once you
have something like this setup, it's 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=kevin
# 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 what is cracker activity and what is your own doing.
You can find the freely available unsusported version of Tripwire at [http:/
/www.tripwire.org] http://www.tripwire.org, free of charge. Manuals and
support can be purchased.
Aide can be found at [http://www.cs.tut.fi/~rammer/aide.html] http://
www.cs.tut.fi/~rammer/aide.html.
Osiris can be found at [http://www.shmoo.com/osiris/] http://www.shmoo.com/
osiris/.
-----------------------------------------------------------------------------
5.4. Trojan Horses
"Trojan Horses" are named after the fabled ploy in Virgil's "Aenid". 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 system while they are not paying attention. While they
think the binary they just pulled down does one thing (and it might very
well), it also compromises their security.
You should take care of what programs you install on your machine. RedHat
provides MD5 checksums and PGP signatures on its RPM files so you can verify
you are installing the real thing. Other distributions have similar methods.
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.
-----------------------------------------------------------------------------
6. Password Security and Encryption
One of the most important security features used today are passwords. It is
important for both you and all your users to have secure, unguessable
passwords. Most of the more recent Linux distributions include passwd
programs that do not allow you to set a easily guessable password. Make sure
your passwd program is up to date and has these features.
In-depth discussion of encryption is beyond the scope of this document, but
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 Unicies (and 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 (typically) /etc/passwd (or less
commonly) /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 contents of /etc/passwd (or /etc/shadow).
Brute force attacks, such as "Crack" or "John the Ripper" (see section
Section 6.9) 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.
You can go to [http://consult.cern.ch/writeup/security/security_3.html]
http://consult.cern.ch/writeup/security/security_3.html for information on
how to choose a good password.
-----------------------------------------------------------------------------
6.1. PGP and Public-Key Cryptography
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 [http://www.rsa.com/rsalabs/faq/] the
RSA Cryptography FAQ, listed at the end of this section.
PGP (Pretty Good Privacy) is well-supported on 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 PGP FAQ: [http://www.pgp.com/service/export/faq/55faq.cgi] http:/
/www.pgp.com/service/export/faq/55faq.cgi
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 Linux available at
[http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/
article7.html] http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/
November1997/article7.html. 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 Linux; the patch is available at
[ftp://metalab.unc.edu/pub/Linux/apps/crypto] ftp://metalab.unc.edu/pub/Linux
/apps/crypto.
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 [http://www.faqs.org/rfcs/rfc2440.html] OpenPGP. See the GNU
Privacy Guard web page for more information: [http://www.gnupg.org] http://
www.gnupg.org/.
More information on cryptography can be found in the RSA cryptography FAQ,
available at [http://www.rsa.com/rsalabs/newfaq/] http://www.rsa.com/rsalabs/
newfaq/. Here you will find information on such terms as "Diffie-Hellman",
"public-key cryptography", "digital certificates", etc.
-----------------------------------------------------------------------------
6.2. SSL, S-HTTP and S/MIME
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.
<EFBFBD><EFBFBD>*<2A> SSL: - SSL, or Secure Sockets Layer, is an encryption method developed
by Netscape 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 online document with Communicator, and serves as the basis for
secure communications with Communicator, as well as many other Netscape
Communications data encryption. More information can be found at [http://
www.consensus.com/security/ssl-talk-faq.html] http://www.consensus.com/
security/ssl-talk-faq.html. Information on Netscape's other security
implementations, and a good starting point for these protocols is
available at [http://home.netscape.com/info/security-doc.html] http://
home.netscape.com/info/security-doc.html. It's also worth noting that the
SSL protocol can be used to pass many other common protocols, "wrapping"
them for security. See [http://www.quiltaholic.com/rickk/sslwrap/] http:/
/www.quiltaholic.com/rickk/sslwrap/
<EFBFBD><EFBFBD>*<2A> S-HTTP: - S-HTTP is another protocol that 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]
<EFBFBD><EFBFBD>*<2A> 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, so it
is likely we will see it on Linux one day soon. More information on S/
MIME can be found at [http://home.netscape.com/assist/security/smime/
overview.html] http://home.netscape.com/assist/security/smime/
overview.html.
-----------------------------------------------------------------------------
6.3. Linux IPSEC Implementations
Along with CIPE, and other forms of data encryption, there are also several
other implementations of IPSEC for 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 [http://www.ietf.org/
html.charters/ipsec-charter.html] http://www.ietf.org/html.charters/
ipsec-charter.html. You can also find links to other protocols involving key
management, and an IPSEC mailing list and archives.
The x-kernel Linux implementation, which is being developed at the
University of Arizona, uses an object-based framework for implementing
network protocols called x-kernel, and can be found at [http://
www.cs.arizona.edu/xkernel/hpcc-blue/linux.html] http://www.cs.arizona.edu/
xkernel/hpcc-blue/linux.html. Most simply, the x-kernel is a method of
passing messages at the kernel level, which makes for an easier
implementation.
Another freely-available IPSEC implementation is the 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 machine 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 machines at several
different sites connected by the insecure Internet.""
It's available for download from [http://www.xs4all.nl/~freeswan/] http://
www.xs4all.nl/~freeswan/, and has just reached 1.0 at the time of this
writing.
As with other forms of cryptography, it is not distributed with the kernel
by default due to export restrictions.
-----------------------------------------------------------------------------
6.4. ssh (Secure Shell) and stelnet
ssh and stelnet are suites of programs that allow you to login to remote
systems and 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 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 implementiations now. The original commercial
implementation by Data Fellows can be found at The ssh home page can be found
at [http://www.datafellows.com] http://www.datafellows.com.
The excellent Openssh implementation is based on a early version of the
datafellows ssh and has been totally reworked to not include any patented or
proprietary pieces. It is free and under a BSD license. It can be found at:
[http://www.openssh.com] http://www.openssh.com.
There is also a open source project to re-implement ssh from the ground up
called "psst...". For more information see: [http://www.net.lut.ac.uk/psst/]
http://www.net.lut.ac.uk/psst/
You can also use ssh from your Windows workstation to your Linux ssh server.
There are several freely available Windows client implementations, including
the one at [http://guardian.htu.tuwien.ac.at/therapy/ssh/] http://
guardian.htu.tuwien.ac.at/therapy/ssh/ as well as a commercial implementation
from DataFellows, at [http://www.datafellows.com] http://www.datafellows.com.
SSLeay is a free implementation of Netscape's Secure Sockets Layer protocol,
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 that 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 FAQ, available at [http://
www.psy.uq.oz.au/~ftp/Crypto/] http://www.psy.uq.oz.au/~ftp/Crypto/.
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, go to [http://www-cs-students.stanford.edu/~tjw/srp/]
http://www-cs-students.stanford.edu/~tjw/srp/
-----------------------------------------------------------------------------
6.5. PAM - Pluggable Authentication Modules
Newer versions of the Red Hat Linux and Debian Linux distributions ship 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 document, but be sure to
take a look at the PAM web site for more information. [http://www.kernel.org/
pub/linux/libs/pam/index.html] http://www.kernel.org/pub/linux/libs/pam/
index.html.
Just a few of the things you can do with PAM:
<EFBFBD><EFBFBD>*<2A> Use encryption other than DES for your passwords. (Making them harder to
brute-force decode)
<EFBFBD><EFBFBD>*<2A> Set resource limits on all your users so they can't perform
denial-of-service attacks (number of processes, amount of memory, etc)
<EFBFBD><EFBFBD>*<2A> Enable shadow passwords (see below) on the fly
<EFBFBD><EFBFBD>*<2A> allow specific users to login only at specific times from specific
places
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
-----------------------------------------------------------------------------
6.6. Cryptographic IP Encapsulation (CIPE)
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 tunnelling, 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 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, easy to
debug...) implementation."
Further information can be found at [http://www.inka.de/~bigred/devel/
cipe.html] http://www.inka.de/~bigred/devel/cipe.html
As with other forms of cryptography, it is not distributed with the kernel
by default due to export restrictions.
-----------------------------------------------------------------------------
6.7. Kerberos
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 her 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 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 [http://
www.cis.ohio-state.edu/hypertext/faq/usenet/kerberos-faq/general/faq.html]
the kerberos FAQ, and the code can be found at [http://nii.isi.edu/info/
kerberos/] http://nii.isi.edu/info/kerberos/.
[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 in improving security of your host.
It is quite involved, and not as widely used as, say, SSH.
-----------------------------------------------------------------------------
6.8. Shadow Passwords.
Shadow passwords are a means of keeping your encrypted password information
secret from normal users. Recent versions of both Red Hat and Debian Linux
use shadow passwords by default, but on other systems, encrypted passwords
are stored in /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 /etc/shadow, which only
privileged users can read. In order to use shadow passwords, you need to make
sure all your utilities that need access to password information are
recompiled to support them. PAM (above) also allows you to just plug in a
shadow module; it doesn't require re-compilation of executables. You can
refer to the Shadow-Password HOWTO for further information if necessary. It
is available at [http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html]
http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html It is rather
dated now, and will not be required for distributions supporting PAM.
-----------------------------------------------------------------------------
6.9. "Crack" and "John the Ripper"
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" ([http://www.openwall.com/john/] http://
www.openwall.com/john/) . 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/passwd
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 machines on your network, you should
check out L0phtCrack, a Crack implementation for Windows. It's available from
[http://www.l0pht.com] http://www.l0pht.com
-----------------------------------------------------------------------------
6.10. CFS - Cryptographic File System and TCFS - Transparent Cryptographic
File System
CFS is a way of encrypting entire directory trees and allowing users to
store encrypted files on them. It uses an NFS server running on the local
machine. RPMS are available at [http://www.zedz.net/redhat/] http://
www.zedz.net/redhat/, and more information on how it all works is at [ftp://
ftp.research.att.com/dist/mab/] ftp://ftp.research.att.com/dist/mab/.
TCFS improves on CFS by adding more integration with the file system, so
that it's transparent to users that the file system that is encrypted. More
information at: [http://www.tcfs.it/] http://www.tcfs.it/.
It also need not be used on entire file systems. It works on directory trees
as well.
-----------------------------------------------------------------------------
6.11. X11, SVGA and display security
6.11.1. X11
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 also can be fraught with
peril, allowing sniffers to see all your interaction with the remote system.
X has a number of access-control mechanisms. The simplest of them is
host-based: you 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 machine, they can xhost + their machine and get in easily. Also, if
you have to allow access from an untrusted machine, anyone there can
compromise your display.
When using xdm (X Display Manager) to 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 machine 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 [http://metalab.unc.edu/LDP/HOWTO/mini
/Remote-X-Apps.html] http://metalab.unc.edu/LDP/HOWTO/mini/
Remote-X-Apps.html.
You can also use ssh (see Section 6.4, above) 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.
You can also disable any remote connections to your X server by using the
'-nolisten tcp' options to your X server. This will prevent any network
connections to your server over tcp sockets.
Take a look at the Xsecurity man page for more information on X security.
The safe bet is to use xdm to login to your console and then use ssh to go to
remote sites on which you wish to run X programs.
-----------------------------------------------------------------------------
6.11.2. SVGA
SVGAlib programs are typically SUID-root in order to access all your Linux
machine's video hardware. This makes them very dangerous. If they crash, you
typically need to reboot your machine to get a usable console back. Make sure
any SVGA programs you are running are authentic, and can at least be somewhat
trusted. Even better, don't run them at all.
-----------------------------------------------------------------------------
6.11.3. GGI (Generic Graphics Interface project)
The Linux GGI project is trying to solve several of the problems with video
interfaces on Linux. GGI will move a small piece of the video code into the
Linux kernel, and then control access to the video system. This means GGI
will be able to restore your console at any time to a known good state. They
will also allow a secure attention key, so you can be sure that there is no
Trojan horse login program running on your console. [http://
synergy.caltech.edu/~ggi/] http://synergy.caltech.edu/~ggi/
-----------------------------------------------------------------------------
7. Kernel Security
This is a description of the kernel configuration options that relate to
security, and an explanation of what they do, and how to use them.
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 [ftp://ftp.kernel.org] ?? or from your distribution
vendor.
There is also a international group providing a single unified crypto patch
to the mainstream Linux kernel. This patch provides support for a number of
cryptographic subsystems and things that cannot be included in the mainstream
kernel due to export restrictions. For more information, visit their web page
at: [http://www.kerneli.org] http://www.kerneli.org
-----------------------------------------------------------------------------
7.1. 2.0 Kernel Compile Options
For 2.0.x kernels, the following options apply. You should see these options
during the kernel configuration process. Many of the comments here are from .
/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.
<EFBFBD><EFBFBD>*<2A> Network Firewalls (CONFIG_FIREWALL)
This option should be on if you intend to run any firewalling or
masquerading on your Linux machine. If it's just going to be a regular
client machine, it's safe to say no.
<EFBFBD><EFBFBD>*<2A> IP: forwarding/gatewaying (CONFIG_IP_FORWARD)
If you enable IP forwarding, your Linux box essentially becomes a
router. If your machine 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 machines will want this enabled, and
used in conjunction with firewall software.
You can enable IP forwarding dynamically using the following command:
root# echo 1 > /proc/sys/net/ipv4/ip_forward
and disable it with the command:
root# echo 0 > /proc/sys/net/ipv4/ip_forward
Keep in mind the files in /proc are "virtual" files and the shown size of
the file might not reflect the data output from it.
<EFBFBD><EFBFBD>*<2A> IP: syn cookies (CONFIG_SYN_COOKIES)
a "SYN Attack" is a denial of service (DoS) attack that consumes all the
resources on your machine, forcing you to reboot. We can't think of a
reason you wouldn't normally enable this. In the 2.2.x 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>
<EFBFBD><EFBFBD>*<2A> IP: Firewalling (CONFIG_IP_FIREWALL)
This option is necessary if you are going to configure your machine as a
firewall, do masquerading, or wish to protect your dial-up workstation
from someone entering via your PPP dial-up interface.
<EFBFBD><EFBFBD>*<2A> IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE)
This option gives you information about packets your firewall received,
like sender, recipient, port, etc.
<EFBFBD><EFBFBD>*<2A> IP: Drop source routed frames (CONFIG_IP_NOSR)
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 that may be a
potential exploit.
<EFBFBD><EFBFBD>*<2A> IP: masquerading (CONFIG_IP_MASQUERADE) If one of the computers on your
local network for which your Linux box acts as a firewall wants to send
something to the outside, your box can "masquerade" as that host, i.e.,
it forewords the traffic to the intended destination, but makes it look
like it came from the firewall box itself. See [http://www.indyramp.com/
masq] http://www.indyramp.com/masq for more information.
<EFBFBD><EFBFBD>*<2A> IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) This option adds ICMP
masquerading to the previous option of only masquerading TCP or UDP
traffic.
<EFBFBD><EFBFBD>*<2A> IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) This enables
your 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-Masquerading HOWTO and
[http://www.indyramp.com/masq] http://www.indyramp.com/masq for more
information.
<EFBFBD><EFBFBD>*<2A> IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)
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 that
isn't supposed to be there. It could also prevent a teardrop attack
against an internal host that is not yet itself patched against it.
<EFBFBD><EFBFBD>*<2A> Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING)
This is an option that is available in the 2.2.x kernel series that will
sign NCP packets for stronger security. Normally you can leave it off,
but it is there if you do need it.
<EFBFBD><EFBFBD>*<2A> IP: Firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK)
This is a really neat option that 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.
-----------------------------------------------------------------------------
7.2. 2.2 Kernel Compile Options
For 2.2.x kernels, many of the options are the same, but a few new ones have
been developed. Many of the comments here are from ./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. Only the
newly- added options are listed below. Consult the 2.0 description for a list
of other necessary options. The most significant change in the 2.2 kernel
series is the IP firewalling code. The ipchains program is now used to
install IP firewalling, instead of the ipfwadm program used in the 2.0
kernel.
<EFBFBD><EFBFBD>*<2A> Socket Filtering (CONFIG_FILTER)
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.
<EFBFBD><EFBFBD>*<2A> Port Forwarding
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 machine 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 http://
www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to browse the WWW,
you need to have access to a machine on the Internet that has a program
like lynx or Netscape). For general info, please see ftp://
ftp.compsoc.net/users/steve/ipportfw/linux21/
<EFBFBD><EFBFBD>*<2A> Socket Filtering (CONFIG_FILTER)
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. Linux socket filtering works on
all socket types except TCP for now. See the text file ./linux/
Documentation/networking/filter.txt for more information.
<EFBFBD><EFBFBD>*<2A> IP: Masquerading
The 2.2 kernel masquerading has been improved. It provides additional
support for masquerading special protocols, etc. Be sure to read the IP
Chains HOWTO for more information.
-----------------------------------------------------------------------------
7.3. Kernel Devices
There are a few block and character devices available on Linux that will
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 runs out of
random bytes and it 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'll
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.
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for
helping me (Dave) with this.
-----------------------------------------------------------------------------
8. Network Security
Network security is becoming more and more important as people spend more
and more time connected. Compromising network security is often much easier
than compromising physical or local security, and is much more common.
There are a number of good tools to assist with network security, and more
and more of them are shipping with Linux distributions.
-----------------------------------------------------------------------------
8.1. Packet Sniffers
One of the most common ways intruders gain access to more systems on your
network is by employing a packet sniffer on a already compromised host. This
"sniffer" just listens on the Ethernet port for things like passwd and login
and su in the packet stream and then logs the traffic after that. This way,
attackers gain passwords for systems they are not even attempting to break
into. Clear-text passwords are very vulnerable to this attack.
Example: Host A has been compromised. Attacker installs a sniffer. Sniffer
picks up admin logging into Host B from Host C. It gets the admins personal
password as they login to B. Then, the admin does a su to fix a problem. They
now have the root password for Host B. Later the admin lets someone telnet
from his account to Host Z on another site. Now the attacker has a password/
login on Host Z.
In this day and age, the attacker doesn't even need to compromise a system
to do this: they could also bring a laptop or pc into a building and tap into
your net.
Using ssh or other encrypted password methods thwarts this attack. Things
like APOP for POP accounts also prevents this attack. (Normal POP logins are
very vulnerable to this, as is anything that sends clear-text passwords over
the network.)
-----------------------------------------------------------------------------
8.2. System services and tcp_wrappers
Before you put your Linux system on ANY network the first thing to look at
is what services you need to offer. Services that you do not need to offer
should be disabled so that you have one less thing to worry about and
attackers have one less place to look for a hole.
There are a number of ways to disable services under Linux. You can look at
your /etc/inetd.conf file and see what services are being offered by your
inetd. Disable any that you do not need by commenting them out (# at the
beginning of the line), and then sending your inetd process a SIGHUP.
You can also remove (or comment out) services in your /etc/services file.
This will mean that local clients will also be unable to find the service
(i.e., if you remove ftp, and try and ftp to a remote site from that machine
it will fail with an "unknown service" message). It's usually not worth the
trouble to remove services from /etc/services, since it provides no
additional security. If a local person wanted to use ftp even though you had
commented it out, they would make their own client that used the common FTP
port and would still work fine.
Some of the services you might want to leave enabled are:
<EFBFBD><EFBFBD>*<2A> ftp
<EFBFBD><EFBFBD>*<2A> telnet (or ssh)
<EFBFBD><EFBFBD>*<2A> mail, such as pop-3 or imap
<EFBFBD><EFBFBD>*<2A> identd
If you know you are not going to use some particular package, you can also
delete it entirely. rpm -e packagename under the Red Hat distribution will
erase an entire package. Under Debian dpkg --remove does the same thing.
Additionally, you really want to disable the rsh/rlogin/rcp utilities,
including login (used by rlogin), shell (used by rcp), and exec (used by rsh)
from being started in /etc/inetd.conf. These protocols are extremely insecure
and have been the cause of exploits in the past.
You should check /etc/rc.d/rc[0-9].d (on Red Hat; /etc/rc[0-9].d on Debian),
and see if any of the servers started in those directories are not needed.
The files in those directories are actually symbolic links to files in the
directory /etc/rc.d/init.d (on Red Hat; /etc/init.d on Debian). Renaming the
files in the init.d directory disables all the symbolic links that point to
that file. If you only wish to disable a service for a particular run level,
rename the appropriate symbolic link by replacing the upper-case S with a
lower-case s, like this:
root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd
If you have BSD-style rc files, you will want to check /etc/rc* for programs
you don't need.
Most Linux distributions ship with tcp_wrappers "wrapping" all your TCP
services. A tcp_wrapper (tcpd) is invoked from inetd instead of the real
server. tcpd then checks the host that is requesting the service, and either
executes the real server, or denies access from that host. tcpd allows you to
restrict access to your TCP services. You should make a /etc/hosts.allow and
add in only those hosts that need to have access to your machine's services.
If you are a home dial up user, we suggest you deny ALL. tcpd also logs
failed attempts to access services, so this can alert you if you are under
attack. If you add new services, you should be sure to configure them to use
tcp_wrappers if they are TCP-based. For example, a normal dial-up user can
prevent outsiders from connecting to his machine, yet still have the ability
to retrieve mail, and make network connections to the Internet. To do this,
you might add the following to your /etc/hosts.allow:
ALL: 127.
And of course /etc/hosts.deny would contain:
ALL: ALL
which will prevent external connections to your machine, yet still allow you
from the inside to connect to servers on the Internet.
Keep in mind that tcp_wrappers only protects services executed from inetd,
and a select few others. There very well may be other services running on
your machine. You can use netstat -ta to find a list of all the services your
machine is offering.
-----------------------------------------------------------------------------
8.3. Verify Your DNS Information
Keeping up-to-date DNS information about all hosts on your network can help
to increase security. If an unauthorized host becomes connected to your
network, you can recognize it by its lack of a DNS entry. Many services can
be configured to not accept connections from hosts that do not have valid DNS
entries.
-----------------------------------------------------------------------------
8.4. identd
identd is a small program that typically runs out of your inetd server. It
keeps track of what user is running what TCP service, and then reports this
to whoever requests it.
Many people misunderstand the usefulness of identd, and so disable it or
block all off site requests for it. identd is not there to help out remote
sites. There is no way of knowing if the data you get from the remote identd
is correct or not. There is no authentication in identd requests.
Why would you want to run it then? Because it helps you out, and is another
data-point in tracking. If your identd is un compromised, then you know it's
telling remote sites the user-name or uid of people using TCP services. If
the admin at a remote site comes back to you and tells you user so-and-so was
trying to hack into their site, you can easily take action against that user.
If you are not running identd, you will have to look at lots and lots of
logs, figure out who was on at the time, and in general take a lot more time
to track down the user.
The identd that ships with most distributions is more configurable than many
people think. You can disable it for specific users (they can make a .noident
file), you can log all identd requests (We recommend it), you can even have
identd return a uid instead of a user name or even NO-USER.
-----------------------------------------------------------------------------
8.5. Configuring and Securing the Postfix MTA
The Postfix mail server was written by Wietse Venema, author of Postfix and
several other staple Internet security products, as an "attempt to provide an
alternative to the widely-used Sendmail program. Postfix attempts to be fast,
easy to administer, and hopefully secure, while at the same time being
sendmail compatible enough to not upset your users."
Further information on postfix can be found at the [http://www.postfix.org]
Postfix home and in the [http://www.linuxsecurity.com/feature_stories/
feature_story-91.html] Configuring and Securing Postfix.
-----------------------------------------------------------------------------
8.6. SATAN, ISS, and Other Network Scanners
There are a number of different software packages out there that do port and
service-based scanning of machines or networks. SATAN, ISS, SAINT, and Nessus
are some of the more well-known ones. This software connects to the target
machine (or all the target machines on a network) on all the ports they can,
and try to determine what service is running there. Based on this
information, you can tell if the machine is vulnerable to a specific exploit
on that server.
SATAN (Security Administrator's Tool for Analyzing Networks) is a port
scanner with a web interface. It can be configured to do light, medium, or
strong checks on a machine or a network of machines. It's a good idea to get
SATAN and scan your machine or network, and fix the problems it finds. Make
sure you get the copy of SATAN from [http://metalab.unc.edu/pub/packages/
security/Satan-for-Linux/] metalab or a reputable FTP or web site. There was
a Trojan copy of SATAN that was distributed out on the net. [http://
www.trouble.org/~zen/satan/satan.html] http://www.trouble.org/~zen/satan/
satan.html. Note that SATAN has not been updated in quite a while, and some
of the other tools below might do a better job.
ISS (Internet Security Scanner) is another port-based scanner. It is faster
than Satan, and thus might be better for large networks. However, SATAN tends
to provide more information.
Abacus is a suite of tools to provide host-based security and intrusion
detection. Look at it's home page on the web for more information. [http://
www.psionic.com/abacus] http://www.psionic.com/abacus/
SAINT is a updated version of SATAN. It is web-based and has many more
up-to-date tests than SATAN. You can find out more about it at: [http://
www.wwdsi.com/saint] http://www.wwdsi.com/~saint
Nessus is a free security scanner. It has a GTK graphical interface for ease
of use. It is also designed with a very nice plug in setup for new
port-scanning tests. For more information, take a look at: [http://
www.nessus.org/] http://www.nessus.org
-----------------------------------------------------------------------------
8.6.1. Detecting Port Scans
There are some tools designed to alert you to probes by SATAN and ISS and
other scanning software. However, if you liberally use tcp_wrappers, and look
over your log files regularly, you should be able to notice such probes. Even
on the lowest setting, SATAN still leaves traces in the logs on a stock Red
Hat system.
There are also "stealth" port scanners. A packet with the TCP ACK bit set
(as is done with established connections) will likely get through a
packet-filtering firewall. The returned RST packet from a port that _had no
established session_ can be taken as proof of life on that port. I don't
think TCP wrappers will detect this.
You might also look at SNORT, which is a free IDS (Intrusion Detection
System), which can detect other network intrusions. [http://www.snort.org]
http://www.snort.org
-----------------------------------------------------------------------------
8.7. sendmail, qmail and MTA's
One of the most important services you can provide is a mail server.
Unfortunately, it is also one of the most vulnerable to attack, simply due to
the number of tasks it must perform and the privileges it typically needs.
If you are using sendmail it is very important to keep up on current
versions. sendmail has a long long history of security exploits. Always make
sure you are running the most recent version from [http://www.sendmail.org/]
http://www.sendmail.org.
Keep in mind that sendmail does not have to be running in order for you to
send mail. If you are a home user, you can disable sendmail entirely, and
simply use your mail client to send mail. You might also choose to remove the
"-bd" flag from the sendmail startup file, thereby disabling incoming
requests for mail. In other words, you can execute sendmail from your startup
script using the following instead:
# /usr/lib/sendmail -q15m
This will cause sendmail to flush the mail queue every fifteen minutes for
any messages that could not be successfully delivered on the first attempt.
Many administrators choose not to use sendmail, and instead choose one of
the other mail transport agents. You might consider switching over to qmail.
qmail was designed with security in mind from the ground up. It's fast,
stable, and secure. Qmail can be found at [http://www.qmail.org] http://
www.qmail.org
In direct competition to qmail is "postfix", written by Wietse Venema, the
author of tcp_wrappers and other security tools. Formerly called vmailer, and
sponsored by IBM, this is also a mail transport agent written from the ground
up with security in mind. You can find more information about postfix at
[http:/www.postfix.org] http://www.postfix.org
-----------------------------------------------------------------------------
8.8. Denial of Service Attacks
A "Denial of Service" (DoS) attack is one where the attacker tries to make
some resource too busy to answer legitimate requests, or to deny legitimate
users access to your machine.
Denial of service attacks have increased greatly in recent years. Some of
the more popular and recent ones are listed below. Note that new ones show up
all the time, so this is just a few examples. Read the Linux security lists
and the bugtraq list and archives for more current information.
<EFBFBD><EFBFBD>*<2A> SYN Flooding - SYN flooding is a network denial of service attack. It
takes advantage of a "loophole" in the way TCP connections are created.
The newer Linux kernels (2.0.30 and up) have several configurable options
to prevent SYN flood attacks from denying people access to your machine
or services. See Section 7 for proper kernel protection options.
<EFBFBD><EFBFBD>*<2A> Pentium "F00F" Bug - It was recently discovered that a series of
assembly codes sent to a genuine Intel Pentium processor would reboot the
machine. This affects every machine with a Pentium processor (not clones,
not Pentium Pro or PII), no matter what operating system it's running.
Linux kernels 2.0.32 and up contain a work around for this bug,
preventing it from locking your machine. Kernel 2.0.33 has an improved
version of the kernel fix, and is suggested over 2.0.32. If you are
running on a Pentium, you should upgrade now!
<EFBFBD><EFBFBD>*<2A> Ping Flooding - Ping flooding is a simple brute-force denial of service
attack. The attacker sends a "flood" of ICMP packets to your machine. If
they are doing this from a host with better bandwidth than yours, your
machine will be unable to send anything on the network. A variation on
this attack, called "smurfing", sends ICMP packets to a host with your
machine's return IP, allowing them to flood you less detectably. You can
find more information about the "smurf" attack at [http://
www.quadrunner.com/~chuegen/smurf.txt] http://www.quadrunner.com/~chuegen
/smurf.txt
If you are ever under a ping flood attack, use a tool like tcpdump to
determine where the packets are coming from (or appear to be coming
from), then contact your provider with this information. Ping floods can
most easily be stopped at the router level or by using a firewall.
<EFBFBD><EFBFBD>*<2A> Ping o' Death - The Ping o' Death attack sends ICMP ECHO REQUEST packets
that are too large to fit in the kernel data structures intended to store
them. Because sending a single, large (65,510 bytes) "ping" packet to
many systems will cause them to hang or even crash, this problem was
quickly dubbed the "Ping o' Death." This one has long been fixed, and is
no longer anything to worry about.
<EFBFBD><EFBFBD>*<2A> Teardrop / New Tear - One of the most recent exploits involves a bug
present in the IP fragmentation code on Linux and Windows platforms. It
is fixed in kernel version 2.0.33, and does not require selecting any
kernel compile-time options to utilize the fix. Linux is apparently not
vulnerable to the "newtear" exploit.
You can find code for most exploits, and a more in-depth description of how
they work, at [http://www.rootshell.com] http://www.rootshell.com using their
search engine.
-----------------------------------------------------------------------------
8.9. NFS (Network File System) Security.
NFS is a very widely-used file sharing protocol. It allows servers running
nfsd and mountd to "export" entire file systems to other machines using NFS
filesystem support built in to their kernels (or some other client support if
they are not Linux machines). mountd keeps track of mounted file systems in /
etc/mtab, and can display them with showmount.
Many sites use NFS to serve home directories to users, so that no matter
what machine in the cluster they login to, they will have all their home
files.
There is some small amount of security allowed in exporting file systems.
You can make your nfsd map the remote root user (uid=0) to the nobody user,
denying them total access to the files exported. However, since individual
users have access to their own (or at least the same uid) files, the remote
root user can login or su to their account and have total access to their
files. This is only a small hindrance to an attacker that has access to mount
your remote file systems.
If you must use NFS, make sure you export to only those machines that you
really need to. Never export your entire root directory; export only
directories you need to export.
See the NFS HOWTO for more information on NFS, available at [http://
metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/
NFS-HOWTO.html
-----------------------------------------------------------------------------
8.10. NIS (Network Information Service) (formerly YP).
Network Information service (formerly YP) is a means of distributing
information to a group of machines. The NIS master holds the information
tables and converts them into NIS map files. These maps are then served over
the network, allowing NIS client machines to get login, password, home
directory and shell information (all the information in a standard /etc/
passwd file). This allows users to change their password once and have it
take effect on all the machines in the NIS domain.
NIS is not at all secure. It was never meant to be. It was meant to be handy
and useful. Anyone that can guess the name of your NIS domain (anywhere on
the net) can get a copy of your passwd file, and use "crack" and "John the
Ripper" against your users' passwords. Also, it is possible to spoof NIS and
do all sorts of nasty tricks. If you must use NIS, make sure you are aware of
the dangers.
There is a much more secure replacement for NIS, called NIS+. Check out the
NIS HOWTO for more information: [http://metalab.unc.edu/mdw/HOWTO/
NIS-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html
-----------------------------------------------------------------------------
8.11. Firewalls
Firewalls are a means of controlling what information is allowed into and
out of your local network. Typically the firewall host is connected to the
Internet and your local LAN, and the only access from your LAN to the
Internet is through the firewall. This way the firewall can control what
passes back and forth from the Internet and your LAN.
There are a number of types of firewalls and methods of setting them up.
Linux machines make pretty good firewalls. Firewall code can be built right
into 2.0 and higher kernels. The user-space tools ipfwadm for 2.0 kernels and
ipchains for 2.2 kernels, allows you to change, on the fly, the types of
network traffic you allow. You can also log particular types of network
traffic.
Firewalls are a very useful and important technique in securing your
network. However, never think that because you have a firewall, you don't
need to secure the machines behind it. This is a fatal mistake. Check out the
very good Firewall-HOWTO at your latest metalab archive for more information
on firewalls and Linux. [http://metalab.unc.edu/mdw/HOWTO/
Firewall-HOWTO.html] http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html
More information can also be found in the IP-Masquerade mini-howto: [http://
metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html] http://metalab.unc.edu/mdw
/HOWTO/mini/IP-Masquerade.html
More information on ipfwadm (the tool that lets you change settings on your
firewall, can be found at it's home page: [http://www.xos.nl/linux/ipfwadm/]
http://www.xos.nl/linux/ipfwadm/
If you have no experience with firewalls, and plan to set up one for more
than just a simple security policy, the Firewalls book by O'Reilly and
Associates or other online firewall document is mandatory reading. Check out
[http://www.ora.com] http://www.ora.com for more information. The National
Institute of Standards and Technology have put together an excellent document
on firewalls. Although dated 1995, it is still quite good. You can find it at
[http://csrc.nist.gov/nistpubs/800-10/main.html] http://csrc.nist.gov/
nistpubs/800-10/main.html. Also of interest:
<EFBFBD><EFBFBD>*<2A> The Freefire Project -- a list of freely-available firewall tools,
available at [http://sites.inka.de/sites/lina/freefire-l/index_en.html]
http://sites.inka.de/sites/lina/freefire-l/index_en.html
<EFBFBD><EFBFBD>*<2A> SunWorld Firewall Design -- written by the authors of the O'Reilly
book, this provides a rough introduction to the different firewall types.
It's available at [http://www.sunworld.com/swol-01-1996/
swol-01-firewall.html] http://www.sunworld.com/swol-01-1996/
swol-01-firewall.html
<EFBFBD><EFBFBD>*<2A> Mason - the automated firewall builder for Linux. This is a firewall
script that learns as you do the things you need to do on your network!
More info at: [http://www.pobox.com/~wstearns/mason/] http://
www.pobox.com/~wstearns/mason/
-----------------------------------------------------------------------------
8.12. IP Chains - Linux Kernel 2.2.x Firewalling
Linux IP Firewalling Chains is an update to the 2.0 Linux firewalling code
for the 2.2 kernel. It has many more features than previous implementations,
including:
<EFBFBD><EFBFBD>*<2A> More flexible packet manipulations
<EFBFBD><EFBFBD>*<2A> More complex accounting
<EFBFBD><EFBFBD>*<2A> Simple policy changes possible atomically
<EFBFBD><EFBFBD>*<2A> Fragments can be explicitly blocked, denied, etc.
<EFBFBD><EFBFBD>*<2A> Logs suspicious packets.
<EFBFBD><EFBFBD>*<2A> Can handle protocols other than ICMP/TCP/UDP.
If you are currently using ipfwadm on your 2.0 kernel, there are scripts
available to convert the ipfwadm command format to the format ipchains uses.
Be sure to read the IP Chains HOWTO for further information. It is available
at [http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html] http://
www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html
-----------------------------------------------------------------------------
8.13. Netfilter - Linux Kernel 2.4.x Firewalling
In yet another set of advancements to the kernel IP packet filtering code,
netfilter allows users to set up, maintain, and inspect the packet filtering
rules in the new 2.4 kernel.
The netfilter subsystem is a complete rewrite of previous packet filtering
implementations including ipchains and ipfwadm. Netfilter provides a large
number of improvements, and it has now become an even more mature and robust
solution for protecting corporate networks.
iptables
is the command-line interface used to manipulate the firewall tables within
the kernel.
Netfilter provides a raw framework for manipulating packets as they traverse
through various parts of the kernel. Part of this framework includes support
for masquerading, standard packet filtering, and now more complete network
address translation. It even includes improved support for load balancing
requests for a particular service among a group of servers behind the
firewall.
The stateful inspection features are especially powerful. Stateful
inspection provides the ability to track and control the flow of
communication passing through the filter. The ability to keep track of state
and context information about a session makes rules simpler and tries to
interpret higher-level protocols.
Additionally, small modules can be developed to perform additional specific
functions, such as passing packets to programs in userspace for processing
then reinjecting back into the normal packet flow. The ability to develop
these programs in userspace reduces the level of complexity that was
previously associated with having to make changes directly at the kernel
level.
Other IP Tables references include:
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/feature_stories/feature_story-94.html]
Oskar Andreasson IP Tables Tutorial -- Oskar Andreasson speaks with
LinuxSecurity.com about his comprehensive IP Tables tutorial and how this
document can be used to build a robust firewall for your organization.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/feature_stories/feature_story-93.html] Hal
Burgiss Introduces Linux Security Quick-Start Guides -- Hal Burgiss has
written two authoritative guides on securing Linux, including managing
firewalling.
<EFBFBD><EFBFBD>*<2A> [http://netfilter.samba.org] Netfilter Homepage -- The netfilter/
iptables homepage.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html]
Linux Kernel 2.4 Firewalling Matures: netfilter -- This LinuxSecurity.com
article describes the basics of packet filtering, how to get started
using iptables, and a list of the new features available in the latest
generation of firewalling for Linux.
-----------------------------------------------------------------------------
8.14. VPNs - Virtual Private Networks
VPN's are a way to establish a "virtual" network on top of some
already-existing network. This virtual network often is encrypted and passes
traffic only to and from some known entities that have joined the network.
VPNs are often used to connect someone working at home over the public
Internet to an internal company network.
If you are running a Linux masquerading firewall and need to pass MS PPTP
(Microsoft's VPN point-to-point product) packets, there is a Linux kernel
patch out to do just that. See: [ftp://ftp.rubyriver.com/pub/jhardin/
masquerade/ip_masq_vpn.html] ip-masq-vpn.
There are several Linux VPN solutions available:
<EFBFBD><EFBFBD>*<2A> vpnd. See the [http://sunsite.dk/vpnd/] http://sunsite.dk/vpnd/.
<EFBFBD><EFBFBD>*<2A> Free S/Wan, available at [http://www.xs4all.nl/~freeswan/] http://
www.xs4all.nl/~freeswan/
<EFBFBD><EFBFBD>*<2A> ssh can be used to construct a VPN. See the VPN mini-howto for more
information.
<EFBFBD><EFBFBD>*<2A> vps (virtual private server) at [http://www.strongcrypto.com] http://
www.strongcrypto.com.
<EFBFBD><EFBFBD>*<2A> yawipin at [mailto:http://yavipin.sourceforge.net] http://
yavipin.sourceforge.net
See also the section on IPSEC for pointers and more information.
-----------------------------------------------------------------------------
9. Security Preparation (before you go on-line)
Ok, so you have checked over your system, and determined it's as secure as
feasible, and you're ready to put it online. 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.
-----------------------------------------------------------------------------
9.1. Make a Full Backup of Your Machine
Discussion of backup methods and storage is beyond the scope of this
document, 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.
-----------------------------------------------------------------------------
9.2. Choosing a Good Backup Schedule
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.
-----------------------------------------------------------------------------
9.3. Testing your backups
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.
-----------------------------------------------------------------------------
9.4. Backup Your RPM or Debian File Database
In the event of an intrusion, you can use your RPM database like you would
use tripwire, but only if you can be sure it too hasn't been modified. You
should copy the RPM database to a floppy, and keep this copy off-line at all
times. The Debian distribution likely has something similar.
The files /var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most
likely won't fit on a single floppy. But if compressed, each should fit on a
seperate 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 that can be included to make it less verbose. Keep in mind 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 rearchived. You will have to decide the advantages
versus drawbacks.
-----------------------------------------------------------------------------
9.5. Keep Track of Your System Accounting Data
It is very important that the information that comes from syslog not be
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.
Where to look for your log file will depend on your distribution. In a Linux
system that conforms to the "Linux Filesystem Standard", such as Red Hat, you
will want to look in /var/log and check messages, mail.log, and others.
You can find out where your distribution is logging to by looking at your /
etc/syslog.conf file. This is the file that tells syslogd (the system logging
daemon) where to log various messages.
You might also want to configure your log-rotating script or daemon to keep
logs around longer so you have time to examine them. Take a look at the
logrotate package on recent Red Hat distributions. Other distributions likely
have a similar process.
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 that 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
[http://www.core-sdi.com/ssyslog/] http://www.core-sdi.com/ssyslog/ 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 [http://www.balabit.hu/en/downloads/
syslog-ng/] syslog-ng. It allows you a lot more flexibility in your logging
and also can has 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.
-----------------------------------------------------------------------------
9.6. Apply All New System Updates.
Most Linux users install from a CD-ROM. Due to the fast-paced nature of
security fixes, new (fixed) programs are always being released. Before you
connect your machine to the network, it's a good idea to check with your
distribution's ftp site 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.
-----------------------------------------------------------------------------
10. What To Do During and After a Breakin
So you have followed some of the advice here (or elsewhere) and have
detected a break-in? The first thing to do is to remain calm. Hasty actions
can cause more harm than the attacker would have.
-----------------------------------------------------------------------------
10.1. Security Compromise Underway.
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 machine. Depending on your authority and
procedures, you might ask them to stop, or contact your local security
people.
If you have detected a local user trying to compromise your security, the
first thing to do is confirm they are in fact who you think they are. Check
the site they are logging in from. Is it the site they 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 machines), 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 the
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 backdoors.
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.
-----------------------------------------------------------------------------
10.2. Security Compromise has already happened
So you have either detected a compromise that has already happened or you
have detected it and locked (hopefully) the offending attacker out of your
system. Now what?
-----------------------------------------------------------------------------
10.2.1. Closing the Hole
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 and 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
Caldera security fixes at [http://www.caldera.com/tech-ref/security/] http://
www.caldera.com/tech-ref/security/. Red Hat has not yet separated their
security fixes from bug fixes, but their distribution errata is available at
[http://www.redhat.com/errata] http://www.redhat.com/errata
Debian now has a security mailing list and web page. See: [http://
www.debian.org/security/] http://www.debian.org/security/ for more
information.
It is very likely that if one vendor has released a security update, that
most other Linux vendors will as well.
There is now a Linux security auditing project. They are methodically going
through all the user-space utilities and looking for possible security
exploits and overflows. From their announcement:
""We are attempting a systematic audit of 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:
security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to:
security-audit-subscribe@ferret.lmh.ox.ac.uk""
If you don't lock the attacker out, they will likely be back. Not just back
on your machine, but back somewhere on your network. If they were running a
packet sniffer, odds are good they have access to other local machines.
-----------------------------------------------------------------------------
10.2.2. Assessing the Damage
The first thing is to assess the damage. What has been compromised? If you
are running an integrity checker like Tripwire, you can use it to perform an
integrity check; it should help to tell you what has been compromised. If
not, you will have to look around at all your important data.
Since Linux systems are getting easier and easier to install, you might
consider saving 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 restore 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.
Re-installation should be considered mandatory upon an intruder obtaining
root access. Additionally, you'd like to keep any evidence there is, so
having a spare disk in the safe may make sense.
Then you have to worry about how long ago the compromise happened, and
whether the backups hold any damaged work. More on backups later.
-----------------------------------------------------------------------------
10.2.3. Backups, Backups, Backups!
Having regular backups is a godsend for security matters. If your system is
compromised, you can restore the data you need from backups. Of course, some
data is valuable to the attacker 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.)
-----------------------------------------------------------------------------
10.2.4. Tracking Down the Intruder.
Ok, you have locked the intruder out, and recovered your system, but you're
not quite done yet. While it is unlikely that most intruders will ever be
caught, you should report the attack.
You should report the attack to the admin contact at the site from which the
attacker attacked your system. You can look up this contact with whois or the
Internic database. You might send them an email with all applicable log
entries and dates and times. If you spotted anything else distinctive about
your intruder, you might mention that too. After sending the email, you
should (if you are so inclined) follow up with a phone call. If that admin in
turn spots your attacker, they might be able to talk to the admin of the site
where they are coming from and so on.
Good 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 ([http:/
/www.cert.org/] CERT or similar), as well as your Linux system vendor.
-----------------------------------------------------------------------------
11. Security Sources
There are a LOT of good sites out there for Unix security in general and
Linux security specifically. It's very important to subscribe to one (or
more) of the security mailing lists and keep current on security fixes. Most
of these lists are very low volume, and very informative.
-----------------------------------------------------------------------------
11.1. LinuxSecurity.com References
The LinuxSecurity.com web site has numerous Linux and open source security
references written by the LinuxSecurity staff and people collectively around
the world.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/vuln-newsletter.html] 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.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/newsletter.html] Linux Security Week --
The purpose of this document is to provide our readers with a quick
summary of each week's most relevant Linux security headlines.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/general/mailinglists.html] Linux Security
Discussion List -- This mailing list is for general security-related
questions and comments.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/general/mailinglists.html] Linux Security
Newsletters -- Subscription information for all newsletters.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/docs/colsfaq.html] comp.os.linux.security
FAQ -- Frequently Asked Questions with answers for the
comp.os.linux.security newsgroup.
<EFBFBD><EFBFBD>*<2A> [http://www.linuxsecurity.com/docs/] Linux Security Documentation -- A
great starting point for information pertaining to Linux and Open Source
security.
-----------------------------------------------------------------------------
11.2. FTP Sites
CERT is the Computer Emergency Response Team. They often send out alerts of
current attacks and fixes. See [ftp://ftp.cert.org] ftp://ftp.cert.org for
more information.
ZEDZ (formerly Replay) ([http://www.zedz.net] http://www.zedz.net) has
archives of many security programs. Since they are outside the US, they don't
need to obey US crypto restrictions.
Matt Blaze is the author of CFS and a great security advocate. Matt's
archive is available at [ftp://ftp.research.att.com/pub/mab] ftp://
ftp.research.att.com/pub/mab
tue.nl is a great security FTP site in the Netherlands. [ftp://
ftp.win.tue.nl/pub/security/] ftp.win.tue.nl
-----------------------------------------------------------------------------
11.3. Web Sites
<EFBFBD><EFBFBD>*<2A> The Hacker FAQ is a FAQ about hackers: [http://www.solon.com/~seebs/faqs
/hacker.html] The Hacker FAQ
<EFBFBD><EFBFBD>*<2A> The COAST archive has a large number of Unix security programs and
information: [http://www.cs.purdue.edu/coast/] COAST
<EFBFBD><EFBFBD>*<2A> SuSe Security Page: [http://www.suse.de/security/] http://www.suse.de/
security/
<EFBFBD><EFBFBD>*<2A> Rootshell.com is a great site for seeing what exploits are currently
being used by crackers: [http://www.rootshell.com/] http://
www.rootshell.com/
<EFBFBD><EFBFBD>*<2A> BUGTRAQ puts out advisories on security issues: [http://www.netspace.org
/lsv-archive/bugtraq.html] BUGTRAQ archives
<EFBFBD><EFBFBD>*<2A> CERT, the Computer Emergency Response Team, puts out advisories on
common attacks on Unix platforms: [http://www.cert.org/] CERT home
<EFBFBD><EFBFBD>*<2A> 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: [http://www.trouble.org] http://www.trouble.org
<EFBFBD><EFBFBD>*<2A> The Linux security WWW is a good site for Linux security information:
[http://www.aoy.com/Linux/Security/] Linux Security WWW
<EFBFBD><EFBFBD>*<2A> Infilsec has a vulnerability engine that can tell you what
vulnerabilities affect a specific platform: [http://www.infilsec.com/
vulnerabilities/] http://www.infilsec.com/vulnerabilities/
<EFBFBD><EFBFBD>*<2A> CIAC sends out periodic security bulletins on common exploits: [http://
ciac.llnl.gov/cgi-bin/index/bulletins] http://ciac.llnl.gov/cgi-bin/index
/bulletins
<EFBFBD><EFBFBD>*<2A> A good starting point for Linux Pluggable Authentication modules can be
found at [http://www.kernel.org/pub/linux/libs/pam/] http://
www.kernel.org/pub/linux/libs/pam/.
<EFBFBD><EFBFBD>*<2A> The Debian project has a web page for their security fixes and
information. It is at [http://www.debian.com/security/] http://
www.debian.com/security/.
<EFBFBD><EFBFBD>*<2A> WWW Security FAQ, written by Lincoln Stein, is a great web security
reference. Find it at [http://www.w3.org/Security/Faq/
www-security-faq.html] http://www.w3.org/Security/Faq/
www-security-faq.html
-----------------------------------------------------------------------------
11.4. Mailing Lists
Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
containing the message body subscribe bugtraq. (see links above for
archives).
CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not subject) of
the message put (either or both): subscribe ciac-bulletin
Red Hat has a number of mailing lists, the most important of which is the
redhat-announce list. You can read about security (and other) fixes as soon
as they come out. Send email to redhat-announce-list-request@redhat.com with
the Subject Subscribe See [https://listman.redhat.com/mailman/listinfo/]
https://listman.redhat.com/mailman/listinfo/ for more info and archives.
The Debian project has a security mailing list that covers their security
fixes. See [http://www.debian.com/security/] http://www.debian.com/security/
for more information.
-----------------------------------------------------------------------------
11.5. Books - Printed Reading Material
There are a number of good security books out there. This section lists a
few of them. In addition to the security specific books, security is covered
in a number of other books on system administration.
<EFBFBD><EFBFBD>*<2A> Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky,
1st Edition September 1995, ISBN: 1-56592-124-0
<EFBFBD><EFBFBD>*<2A> Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
Gene Spafford, 2nd Edition April 1996, ISBN: 1-56592-148-8
<EFBFBD><EFBFBD>*<2A> Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr., 1st
Edition July 1991, ISBN: 0-937175-71-4
<EFBFBD><EFBFBD>*<2A> Linux Network Administrator's Guide By Olaf Kirch, 1st Edition January
1995, ISBN: 1-56592-087-2
<EFBFBD><EFBFBD>*<2A> PGP: Pretty Good Privacy By Simson Garfinkel, 1st Edition December 1994,
ISBN: 1-56592-098-8
<EFBFBD><EFBFBD>*<2A> Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
William VonStorch (Consulting Editor Eugene H. Spafford), 1st Edition
August 1995, ISBN: 1-56592-086-4
<EFBFBD><EFBFBD>*<2A> Linux Security By John S. Flowers, New Riders; ISBN: 0735700354, March
1999
<EFBFBD><EFBFBD>*<2A> Maximum Linux Security : A Hacker's Guide to Protecting Your Linux
Server and Network, Anonymous, Paperback - 829 pages, Sams; ISBN:
0672313413, July 1999
<EFBFBD><EFBFBD>*<2A> Intrusion Detection By Terry Escamilla, Paperback - 416 pages (September
1998), John Wiley and Sons; ISBN: 0471290009
<EFBFBD><EFBFBD>*<2A> Fighting Computer Crime, Donn Parker, Paperback - 526 pages (September
1998), John Wiley and Sons; ISBN: 0471163783
-----------------------------------------------------------------------------
12. Glossary
Included below are several of the most frequently used terms in computer
security. A comprehensive dictionary of computer security terms is available
in the [http://www.linuxsecurity.com/dictionary/] LinuxSecurity.com
Dictionary
<EFBFBD><EFBFBD>*<2A> authentication: The process of knowing that the data received is the
same as the data that was sent, and that the claimed sender is in fact
the actual sender.
<EFBFBD><EFBFBD>*<2A> bastion Host: 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 hot oil for discouraging attackers.
<EFBFBD><EFBFBD>*<2A> buffer overflow: 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.
<EFBFBD><EFBFBD>*<2A> denial of service: An attack that consumes the resources on your
computer for things it was not intended to be doing, thus preventing
normal use of your network resources for legitimate purposes.
<EFBFBD><EFBFBD>*<2A> dual-homed Host: A general-purpose computer system that has at least two
network interfaces.
<EFBFBD><EFBFBD>*<2A> firewall: A component or set of components that restricts access between
a protected network and the Internet, or between other sets of networks.
<EFBFBD><EFBFBD>*<2A> host: A computer system attached to a network.
<EFBFBD><EFBFBD>*<2A> IP spoofing: IP Spoofing is a complex technical attack that is made up
of several components. It is a security exploit that works by tricking
computers in a trust relationship into thinking that you are someone that
you really aren't. There is an extensive paper written by daemon9, route,
and infinity in the Volume Seven, Issue Forty-Eight issue of Phrack
Magazine.
<EFBFBD><EFBFBD>*<2A> non-repudiation: The property of a receiver being able to prove that the
sender of some data did in fact send the data even though the sender
might later deny ever having sent it.
<EFBFBD><EFBFBD>*<2A> packet: The fundamental unit of communication on the Internet.
<EFBFBD><EFBFBD>*<2A> packet filtering: 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 that 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.
<EFBFBD><EFBFBD>*<2A> perimeter network: A network added between a protected network and an
external network, in order to provide an additional layer of security. A
perimeter network is sometimes called a DMZ.
<EFBFBD><EFBFBD>*<2A> proxy server: A program that 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.
<EFBFBD><EFBFBD>*<2A> superuser: An informal name for root.
-----------------------------------------------------------------------------
13. Frequently Asked Questions
1. Is it more secure to compile driver support directly into the kernel,
instead of making it a module?
Answer: Some people think it is better to disable the ability to load
device drivers using modules, because an intruder could load a Trojan
module or a module that could affect system security.
However, in order to load modules, you must be root. The module object
files are also only writable by root. This means the intruder would need
root access to insert a module. If the intruder gains root access, there
are more serious things to worry about than whether he will load a
module.
Modules are for dynamically loading support for a particular device that
may be infrequently used. On server machines, 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
a server. Modules are also slower than support compiled directly in the
kernel.
2. Why does logging in as root from a remote machine always fail?
Answer: See Section 4.2. This is done intentionally to prevent remote
users from attempting to connect via telnet to your machine as root,
which is a serious security vulnerability, because then the root password
would be transmitted, in clear text, across the network. Don't forget:
potential intruders have time on their side, and can run automated
programs to find your password. Additionally, this is done to keep a
clear record of who logged in, not just root.
3. How do I enable shadow passwords on my Linux box?
Answer:
To enable shadow passwords, run pwconv as root, and /etc/shadow should
now exist, and be used by applications. If you are using RH 4.2 or above,
the PAM modules will automatically adapt to the change from using normal
/etc/passwd to shadow passwords without any other change.
Some background: shadow passwords is a mechanism for storing your
password in a file other than the normal /etc/passwd file. This has
several advantages. The first one is that the shadow file, /etc/shadow,
is only readable by root, unlike /etc/passwd, which must remain readable
by everyone. The other advantage is that as the administrator, you can
enable or disable accounts without everyone knowing the status of other
users' accounts.
The /etc/passwd file is then used to store user and group names, used by
programs like /bin/ls to map the user ID to the proper user name in a
directory listing.
The /etc/shadow file then only contains the user name and his/her
password, and perhaps accounting information, like when the account
expires, etc.
To enable shadow passwords, run pwconv as root, and /etc/shadow should
now exist, and be used by applications. Since you are using RH 4.2 or
above, the PAM modules will automatically adapt to the change from using
normal /etc/passwd to shadow passwords without any other change.
Since you're interested in securing your passwords, perhaps you would
also be interested in generating good passwords to begin with. For this
you can use the pam_cracklib module, which is part of PAM. It runs your
password against the Crack libraries to help you decide if it is
too-easily guessable by password-cracking programs.
4. How can I enable the Apache SSL extensions?
Answer:
a. Get SSLeay 0.8.0 or later from [ftp://ftp.psy.uq.oz.au/pub/Crypto/
SSL] ??
b. Build and test and install it!
c. Get Apache source
d. Get Apache SSLeay extensions from [ftp://ftp.ox.ac.uk/pub/crypto/SSL
/] here
e. Unpack it in the apache source directory and patch Apache as per the
README.
f. Configure and build it.
You might also try [http://www.zedz.net] ZEDZ net which has many
pre-built packages, and is located outside of the United States.
5. How can I manipulate user accounts, and still retain security?
Answer: most distributions contain a great number of tools to change the
properties of user accounts.
<20><>+<2B> The pwconv and unpwconv programs can be used to convert between
shadow and non-shadowed passwords.
<20><>+<2B> The pwck and grpck programs can be used to verify proper
organization of the passwd and group files.
<20><>+<2B> The useradd, usermod, and userdel programs can be used to add,
delete and modify user accounts. The groupadd, groupmod, and groupdel
programs will do the same for groups.
<20><>+<2B> Group passwords can be created using gpasswd.
All these programs are "shadow-aware" -- that is, if you enable shadow
they will use /etc/shadow for password information, otherwise they won't.
See the respective man pages for further information.
6. How can I password-protect specific HTML documents using Apache?
I bet you didn't know about [http://www.apacheweek.com] http://
www.apacheweek.org, did you?
You can find information on user authentication at [http://
www.apacheweek.com/features/userauth] http://www.apacheweek.com/features/
userauth as well as other web server security tips from [http://
www.apache.org/docs/misc/security_tips.html] http://www.apache.org/docs/
misc/security_tips.html
-----------------------------------------------------------------------------
14. Conclusion
By subscribing to the security alert mailing lists, and keeping current, you
can do a lot towards securing your machine. If you pay attention to your log
files and run something like tripwire regularly, you can do even more.
A reasonable level of computer security is not difficult to maintain on a
home machine. More effort is required on business machines, but Linux can
indeed be a secure platform. Due to the nature of Linux development, security
fixes often come out much faster than they do on commercial operating
systems, making Linux an ideal platform when security is a requirement.
-----------------------------------------------------------------------------
15. Acknowledgments
Information here is collected from many sources. Thanks to the following who
either indirectly or directly have contributed:
Rob Riggs
[mailto:rob@DevilsThumb.com] rob@DevilsThumb.com
S. Coffin [mailto:scoffin@netcom.com] scoffin@netcom.com
Viktor Przebinda [mailto:viktor@CRYSTAL.MATH.ou.edu]
viktor@CRYSTAL.MATH.ou.edu
Roelof Osinga [mailto:roelof@eboa.com] roelof@eboa.com
Kyle Hasselbacher [mailto:kyle@carefree.quux.soltec.net]
kyle@carefree.quux.soltc.net
David S. Jackson [mailto:dsj@dsj.net] dsj@dsj.net
Todd G. Ruskell [mailto:ruskell@boulder.nist.gov] ruskell@boulder.nist.gov
Rogier Wolff [mailto:R.E.Wolff@BitWizard.nl] R.E.Wolff@BitWizard.nl
Antonomasia [mailto:ant@notatla.demon.co.uk] ant@notatla.demon.co.uk
Nic Bellamy [mailto:sky@wibble.net] sky@wibble.net
Eric Hanchrow [mailto:offby1@blarg.net] offby1@blarg.net
Robert J. Berger[mailto:rberger@ibd.com] rberger@ibd.com
Ulrich Alpers [mailto:lurchi@cdrom.uni-stuttgart.de]
lurchi@cdrom.uni-stuttgart.de
David Noha [mailto:dave@c-c-s.com] dave@c-c-s.com
Pavel Epifanov. [mailto:epv@ibm.net] epv@ibm.net
Joe Germuska. [mailto:joe@germuska.com] joe@germuska.com
Franklin S. Werren [mailto:fswerren@bagpipes.net] fswerren@bagpipes.net
Paul Rusty Russell [mailto:Paul.Russell@rustcorp.com.au] <
Paul.Russell@rustcorp.com.au>
Christine Gaunt [mailto:cgaunt@umich.edu] <cgaunt@umich.edu>
lin [mailto:bhewitt@refmntutl01.afsc.noaa.gov]
bhewitt@refmntutl01.afsc.noaa.gov
A. Steinmetz [mailto:astmail@yahoo.com] astmail@yahoo.com
Jun Morimoto [mailto:morimoto@xantia.citroen.org]
morimoto@xantia.citroen.org
Xiaotian Sun [mailto:sunx@newton.me.berkeley.edu]
sunx@newton.me.berkeley.edu
Eric Hanchrow [mailto:offby1@blarg.net] offby1@blarg.net
Camille Begnis [mailto:camille@mandrakesoft.com] camille@mandrakesoft.com
Neil D [mailto:neild@sympatico.ca] neild@sympatico.ca
Michael Tandy [mailto:Michael.Tandy@BTInternet.com]
Michael.Tandy@BTInternet.com
Tony Foiani [mailto:tkil@scrye.com] tkil@scrye.com
Matt Johnston [mailto:mattj@flashmail.com] mattj@flashmail.com
Geoff Billin [mailto:gbillin@turbonet.com] gbillin@turbonet.com
Hal Burgiss [mailto:hburgiss@bellsouth.net] hburgiss@bellsouth.net
Ian Macdonald [mailto:ian@linuxcare.com] ian@linuxcare.com
M.Kiesel [mailto:m.kiesel@iname.com] m.kiesel@iname.com
Mario Kratzer [mailto:kratzer@mathematik.uni-marburg.de]
kratzer@mathematik.uni-marburg.de
Othmar Pasteka [mailto:pasteka@kabsi.at] pasteka@kabsi.at
Robert M [mailto:rom@romab.com] rom@romab.com
Cinnamon Lowe [mailto:clowe@cinci.rr.com] clowe@cinci.rr.com
Rob McMeekin [mailto:blind_mordecai@yahoo.com] blind_mordecai@yahoo.com
Gunnar Ritter [mailto:g-r@bigfoot.de] g-r@bigfoot.de
Frank Lichtenheld[mailto:frank@lichtenheld.de] frank@lichtenheld.de
Björn Lotz[mailto:blotz@suse.de] blotz@suse.de
Othon Marcelo Nunes Batista[mailto:othonb@superig.com.br]
othonb@superig.com.br
The following have translated this HOWTO into various other languages!
A special thank you to all of them for help spreading the Linux word...
Polish: Ziemek Borowski [mailto:ziembor@FAQ-bot.ZiemBor.Waw.PL]
ziembor@FAQ-bot.ZiemBor.Waw.PL
Japanese: FUJIWARA Teruyoshi [mailto:fjwr@mtj.biglobe.ne.jp]
fjwr@mtj.biglobe.ne.jp
Indonesian: Tedi Heriyanto [mailto:22941219@students.ukdw.ac.id]
22941219@students.ukdw.ac.id
Korean: Bume Chang [mailto:Boxcar0001@aol.com] Boxcar0001@aol.com
Spanish: Juan Carlos Fernandez [mailto:piwiman@visionnetware.com]
piwiman@visionnetware.com
Dutch: "Nine Matthijssen" [mailto:nine@matthijssen.nl] nine@matthijssen.nl
Norwegian: ketil@vestby.com [mailto:ketil@vestby.com] ketil@vestby.com
Turkish: tufan karadere [mailto:tufank@metu.edu.tr] tufank@metu.edu.tr
Reference in New Issue View Git Blame Copy Permalink