LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/linuxdoc/Security-HOWTO.sgml

3172 lines
143 KiB
Plaintext
Raw Blame History

<!DOCTYPE LINUXDOC SYSTEM>
<ARTICLE>
<TITLE>Linux Security HOWTO
<AUTHOR>Kevin Fenzi, <tt>kevin@tummy.com</tt> &ero Dave Wreski, <tt>dave@linuxsecurity.com</tt>
<DATE>v1.1.1, 17 March 2000
<ABSTRACT>
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.
</ABSTRACT>
<TOC>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Introduction
<P>
This document covers some of the main issues that affect
Linux security. General philosophy and net-born resources are
discussed.
<P>
A number of other HOWTO documents overlap with security issues, and
those documents have been pointed to wherever appropriate.
<P>
This document is <em>not</em> 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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> New Versions of this Document
<P>
New versions of this document will be periodically posted to
<it>comp.os.linux.answers</it>. They will also be added to the
various sites that archive such information, including:
<P>
<tt>
<htmlurl url="http://www.linuxdoc.org/"
name="http://www.linuxdoc.org/">
</tt>
<P>
In addition, you should generally be able to find this document
on the Linux World Wide Web home page via:
<P>
<tt>
<htmlurl url="http://metalab.unc.edu/mdw/linux.html"
name="http://metalab.unc.edu/mdw/linux.html">
</tt>
<P>
Finally, the very latest version of this document should also be
available in various formats from:
<P>
<tt>
<htmlurl url="http://scrye.com/~kevin/lsh/"
name="http://scrye.com/~kevin/lsh/">
</tt>
<P>
or
<P>
<htmlurl url="http://www.linuxsecurity.com/docs/Security-HOWTO"
name="http://www.linuxsecurity.com/Security-HOWTO">
<P>
or
<P>
<htmlurl url="http://www.tummy.com/security-howto"
name="http://www.tummy.com/security-howto">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Feedback
<P>
All comments, error reports, additional information and criticism
of all sorts should be directed to:
<P>
<tt>
<htmlurl url="mailto:kevin@tummy.com"
name="kevin@tummy.com">
</tt>
<P>
and
<P>
<tt>
<htmlurl url="mailto:dave@linuxsecurity.com"
name="dave@linuxsecurity.com">
</tt>
<P>
<em>Note</em>: Please send your feedback to <em>both</em> authors. Also, be sure and
include "Linux" "security", or "HOWTO" in your subject to avoid Kevin's
spam filter.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Disclaimer
<P>
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.
<P>
A number of the examples and descriptions use the RedHat(tm) package
layout and system setup. Your mileage may vary.
<P>
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
<url url="http://www.gnu.org/copyleft/gpl.html" name="GNU"> terms.
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Copyright Information
<P>
This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski,
and distributed under the following terms:
<P> <ITEMIZE>
<ITEM> 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.
<ITEM> 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.
<ITEM> If you have questions, please contact Tim Bynum, the
Linux HOWTO coordinator, at
</ITEMIZE>
<P>
<tt>
<htmlurl url="mailto:tjbynum@metalab.unc.edu"
name="tjbynum@metalab.unc.edu">
</tt>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Overview
<P>
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.
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Why Do We Need Security?
<P>
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 <htmlurl
url="http://www.netaxs.com/~esr/faqs/hacker-howto.html"
name="http://www.netaxs.com/~esr/faqs/hacker-howto.html">.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> How Secure Is Secure?
<P>
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.
<P>
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 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.
<P>
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 <htmlurl
url="http://www.faqs.org/rfcs/rfc2196.html"
name="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.
<P>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> What Are You Trying to Protect?
<P>
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.
<P><ITEMIZE><ITEM>
<em>Risk</em> 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.
<P>
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 <tt>.rhosts</tt> file, or to use an insecure
service such as <tt>tftp</tt>, 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.
<P><ITEM>
<em>Threat</em> 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.
<P>
There are several types of intruders, and it is useful to keep their
different characteristics in mind as you are securing your systems.
<P>
<ITEMIZE>
<ITEM><bf>The Curious</bf> - This type of intruder is basically
interested in finding out what type of system and data you have.
</item>
<ITEM><bf>The Malicious</bf> - 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.
</item>
<ITEM><bf>The High-Profile Intruder</bf> - 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.
</item>
<ITEM><bf>The Competition</bf> - 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.
</item>
<ITEM><bf>The Borrowers</bf> - 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.
</item>
<ITEM><bf>The Leapfrogger</bf> - 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.
</item>
</ITEMIZE><P><ITEM>
Vulnerability describes how well-protected your computer is from
another network, and the potential for someone to gain unauthorized
access.
<P>
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.
<P>
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?
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Developing A Security Policy
<P>
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.
<P>
A generally-accepted security policy starts with the phrase
<P>
<quote><bf> That which is not permitted is prohibited</bf>
</quote>
<P>
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.
<P>
<htmlurl url="ftp://www.faqs.org/rfcs/rfc1244.html" name="rfc1244">
is a document that describes how to create your own network security
policy.
<P>
<htmlurl url="ftp://www.faqs.org/rfcs/rfc1281.html" name="rfc1281">
is a document that shows an example security policy with detailed
descriptions of each step.
<P>
Finally, you might want to look at the COAST policy archive at <htmlurl
url="ftp://coast.cs.purdue.edu/pub/doc/policy"
name="ftp://coast.cs.purdue.edu/pub/doc/policy"> to see what some
real-life security policies look like.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Means of Securing Your Site
<P>
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.
<P>
Even if you have a single dialup 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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Host Security
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Local Network Security
<P>
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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Security Through Obscurity
<P>
One type of security that must be discussed is "security through
obscurity". This means, for example, moving a service that has known
security vunerabilities 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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Organization of This Document
<P>
This document has been divided into a number of sections. They cover
several broad security issues. The first,
<ref id="physical-security"name="Physical Security">,
covers how you need to protect your physical machine from
tampering. The second,
<ref id="local-security" name="Local Security">, describes how to
protect your system from tampering by local users. The third,
<ref id="file-security" name="Files and Filesystem Security">,
shows you how to setup your filesystems and permissions on your
files. The next, <ref id="password-security" name="Password Security
and Encryption">, discusses how to use encryption to better secure
your machine and network.
<ref id="kernel-security" name="Kernel Security"> discusses what kernel
options you should set or be aware of for a more secure system.
<ref id="network-security" name="Network Security">, describes how to
better secure your Linux system from network attacks.
<ref id="secure-prep" name="Security Preparation">, discusses how to
prepare your machine(s) before bringing them on-line. Next,
<ref id="after-breakin" name="What To Do During and After a Break-in">,
discusses what to do when you detect a system compromise in progress
or detect one that has recently happened. In <ref id="sources"
name="Security Resources">, some primary security resources are enumerated.
The Q and A section <ref id="q-and-a" name="Frequently Asked Questions">,
answers some frequently-asked questions, and finally a conclusion in
<ref id="conclusion" name="Conclusion">.
<P>
The two main points to realize when reading this document are:
<P>
<ITEMIZE>
<ITEM>
Be aware of your system. Check system logs such as
<tt>/var/log/messages</tt> and keep an eye on your system, and
<ITEM>
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.
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Physical Security<label id="physical-security">
<P>
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?
<P>
How much physical security you need on your system is very dependent
on your situation, and/or budget.
<P>
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.
<P>
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. :)
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Computer locks
<P>
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.
<P>
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.
<P>
Some machines (most notably SPARCs and macs) have a dongle on the back
that, if you put a cable through, attackers would have to cut the cable
or break the case to get into it. Just putting a padlock or combo lock
through these can be a good deterrent to someone stealing your
machine.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> BIOS Security
<P>
The BIOS is the lowest level of software that configures or
manipulates your x86-based hardware. LILO and other Linux boot methods
access the BIOS to determine how to boot up your Linux machine. Other
hardware that Linux runs on has similar software (OpenFirmware on Macs
and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent
attackers from rebooting your machine and manipulating your Linux
system.
<P>
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.
<P>
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.
<p>
<em>Note</em>: 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. ;(
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Boot Loader Security
<P>
The various Linux boot loaders also can have a boot password set.
LILO, for example, has <tt>password</tt> and <tt>restricted</tt>
settings; <tt>password</tt> requires password at boot time,
whereas <tt>restricted</tt> requires a boot-time password only if you
specify options (such as <tt>single</tt>) at the <tt>LILO </tt> prompt.
<P>
From the lilo.conf man page:
<tscreen><verb>
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).
</verb></tscreen>
<P>
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.
<P>
If anyone has security-related information from a different boot
loader, we would love to hear it. (<tt>grub</tt>, <tt>silo</tt>, <tt>milo</tt>, <tt>linload</tt>, etc).
<P>
<em>Note</em>: If you have a server machine, and you set up a boot password,
your machine will <em>not</em> boot up unattended. Keep in mind that you will
need to come in and supply the password in the event of a power
failure. ;(
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> xlock and vlock
<P>
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: <tt>xlock</tt> and <tt>vlock</tt>.
<P>
<tt>xlock</tt> 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 <tt>xlock</tt> from any xterm on your
console and it will lock the display and require your password to
unlock.
<P>
<tt>vlock</tt> 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. <tt>vlock</tt> ships with redhat
Linux, but your mileage may vary.
<P>
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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Detecting Physical Security Compromises
<P>
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 <em>you</em> 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.
<P>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
Some things to check for in your logs:
<ITEMIZE>
<ITEM>Short or incomplete logs.
<ITEM>Logs containing strange timestamps.
<ITEM>Logs with incorrect permissions or ownership.
<ITEM>Records of reboots or restarting of services.
<ITEM>missing logs.
<ITEM><tt>su</tt> entries or logins from strange places.
</ITEMIZE>
<P>
We will discuss system log data <ref id="logs" name="later"> in the HOWTO.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Local Security<label id="local-security">
<P>
The next thing to take a look at is the security in your system
against attacks from local users. Did we just say <em>local</em> users? Yes!
<P>
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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Creating New Accounts
<P>
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.
<P>
Several good rules of thumb when allowing other people legitimate
access to your Linux machine:
<P>
<ITEMIZE>
<ITEM>
Give them the minimal amount of privileges they need.
<ITEM>
Be aware when/where they login from, or should be logging in from.
<ITEM>
Make sure you remove inactive accounts
<ITEM>
The use of the same userid on all computers and networks is advisable
to ease account maintence, and permits easier analysis of log
data.
<ITEM>
The creation of group userid's should be absolutely prohibited. User
accounts also provide accountability, and this is not possible with
group accounts.
</ITEMIZE>
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Root Security<label id="root-security">
<P>
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.
<P>
Several tricks to avoid messing up your own box as root:
<ITEMIZE>
<ITEM>
When doing some complex command, try running it first in a
non-destructive way...especially commands that use globbing: e.g., if
you want to do <tt>rm foo*.bak</tt>, first do <tt>ls foo*.bak</tt> and make
sure you are going to delete the files you think you are. Using <tt>echo</tt>
in place of destructive commands also sometimes works.
<ITEM>
Provide your users with a default alias to the <tt>rm</tt> command to ask for
confirmation for deletion of files.
<ITEM>
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 <em>sure</em> what needs to be done by root.
<ITEM>
The command path for the root user is very important. The command
path (that is, the <tt>PATH</tt> 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 <em>never</em>
include <tt>.</tt> (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.
<ITEM>
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 <tt>.rhosts</tt> file for root.
<ITEM>
The <tt>/etc/securetty</tt> 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 <tt>su</tt> if you need to (hopefully over <tt><ref
id="ssh" name="ssh"></tt> or other encrypted channel), so there is no
need to be able to login directly as root.
<ITEM>
Always be slow and deliberate running as root. Your actions could
affect a lot of things. Think before you type!
</ITEMIZE>
<P>
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. <tt>sudo</tt> 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. <tt>sudo</tt> 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 <tt>sudo</tt>
works well even in places where a number of people have root access,
because it helps you keep track of changes made.
<P>
Although <tt>sudo</tt> 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 <tt>sudo</tt>. This includes
most editors, for example. Also, a program as innocuous as
<tt>/bin/cat</tt> can be used to overwrite files, which could allow
root to be exploited. Consider <tt>sudo</tt> as a means for
accountability, and don't expect it to replace the root user and still
be secure.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Files and Filesystem Security<label id="file-security">
<P>
A few minutes of preparation and planning ahead before putting your
systems online can help to protect them and the data
stored on them.
<ITEMIZE>
<ITEM>
There should never be a reason for users' home directories to allow
SUID/SGID programs to be run from there. Use the <tt>nosuid</tt> option in
<tt>/etc/fstab</tt> for partitions that are writable by others than root. You
may also wish to use <tt>nodev</tt> and <tt>noexec</tt> on users' home partitions,
as well as <tt>/var</tt>, thus prohibiting execution of programs, and
creation of character or block devices, which should never be
necessary anyway.
<ITEM>
If you are exporting filesystems using NFS, be sure to configure
<tt>/etc/exports</tt> with the most restrictive access possible. This means
not using wildcards, not allowing root write access, and exporting
read-only wherever possible.
<ITEM>
Configure your users' file-creation <tt>umask</tt> to be as restrictive as
possible. See <ref id="umask" name="umask settings">.
<ITEM>
If you are mounting filesystems using a network filesystem such as
NFS, be sure to configure /etc/exports with suitable restrictions.
Typically, using `nodev', `nosuid', and perhaps `noexec', are
desirable.
<ITEM>
Set filesystem limits instead of allowing <tt>unlimited</tt> as is the
default. You can control the per-user limits using the
resource-limits PAM module and <tt>/etc/pam.d/limits.conf</tt>. For example,
limits for group <tt>users</tt> might look like this:
<P>
<tscreen><verb>
@users hard core 0
@users hard nproc 50
@users hard rss 5000</verb></tscreen>
<P>
This says to prohibit the creation of core files, restrict the
number of processes to 50, and restrict memory usage per user to
5M.
<P>
<ITEM>
The <tt>/var/log/wtmp</tt> and <tt>/var/run/utmp</tt> 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 <tt>644</tt> permissions, without affecting normal system
operation.
<P><ITEM>
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 symbolic link to the file (such symbolic links have been the
source of attacks involving deleting <tt>/etc/passwd</tt> or <tt>/etc/shadow</tt>).
See the <tt>chattr</tt>(1) man page for information on the immutable bit.
<P><ITEM>
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 backdoor to get in the next time, even if the original
hole is plugged.
<P>
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:
<P><tscreen><verb>
root# find / -type f \( -perm -04000 -o -perm -02000 \)
</verb></tscreen>
<P>
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 <tt>/var/log/setuid*</tt> for this log.
<P>
You can remove the SUID or SGID permissions on a
suspicious program with <tt>chmod</tt>, then restore them back if you
absolutely feel it is necessary.
<P>
<ITEM>
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:<P>
<tscreen><verb>
root# find / -perm -2 ! -type l -ls
</verb></tscreen>
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 <tt>/dev</tt>, and symbolic links, thus the <tt>! -type l</tt>
which excludes these from the previous <tt>find</tt> command.
<ITEM>
<P>
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:<P>
<tscreen><verb>
root# find / -nouser -o -nogroup -print
</verb></tscreen>
<P>
<ITEM>
Finding <tt>.rhosts</tt> 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
<tt>.rhosts</tt> files on your system with the following command:
<tscreen><verb>
root# find /home -name .rhosts -print
</verb></tscreen>
<ITEM>
<P>
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.
<P>
</ITEMIZE>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1>Umask Settings<label id="umask">
<P>
The <tt>umask</tt> 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 <tt>umask</tt>
settings include <tt>022</tt>, <tt>027</tt>, and <tt>077</tt> (which is the most
restrictive). Normally the umask is set in <tt>/etc/profile</tt>, so it applies
to all users on the system. The file creation mask can be calculated
by subtracting the desired value from 777. In other words, a umask of
777 would cause newly-created files to contain no read, write or execute
permission for anyone. A mask of 666 would cause newly-created files
to have a mask of 111. For example, you may have a line that
looks like this:
<P>
<tscreen><verb>
# Set the user's default umask
umask 033
</verb></tscreen>
Be sure to make root's umask <tt>077</tt>, which will disable read, write, and
execute permission for other users, unless explicitly changed using
<tt>chmod</tt>. 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.
<P>
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 <tt>002</tt>
for a <tt>umask</tt>. This is due to the fact that the default configuration
is one user per group.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> File Permissions
<P>
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.
<P>
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.
<P>
A quick explanation of Unix permissions:
<P>
Ownership - Which user(s) and group(s) retain(s) control of the
permission settings of the node and parent of the node
<P>
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.
<P>
<bf>Read:</bf>
<ITEMIZE>
<ITEM>To be able to view contents of a file
<ITEM>To be able to read a directory
</ITEMIZE>
<P>
<bf>Write:</bf>
<ITEMIZE>
<ITEM>To be able to add to or change a file
<ITEM>To be able to delete or move files in a directory
</ITEMIZE>
<P>
<bf>Execute:</bf>
<ITEMIZE>
<ITEM>To be able to run a binary program or shell script
<ITEM>To be able to search in a directory, combined with read permission
</ITEMIZE>
<P>
<descrip>
<tag/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 <tt>/tmp</tt>, 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 <tt>t</tt> in a long
directory listing.
</descrip>
<P>
<descrip>
<tag/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.
</descrip>
<descrip>
<tag/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.
</descrip>
<P>
<descrip>
<tag/SGID Attribute: (For directories)/
If you set the SGID bit on a directory (with <tt>chmod g+s <it>directory</it></tt>),
files created in that directory will have their group set to the
directory's group.
</descrip>
<P>
You - The owner of the file<P>
Group - The group you belong to<P>
Everyone - Anyone on the system that is not the owner or a member
of the group<P>
<P>
<bf>File Example:</bf>
<P>
<tscreen><verb>
-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)
</verb></tscreen>
<P>
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:<P>
<tscreen><verb>
-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)
</verb></tscreen>
<bf>Directory Example:</bf>
<tscreen><verb>
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)
</verb></tscreen>
<P>
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:<P>
<tscreen><verb>
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
</verb></tscreen>
<P>
System configuration files (usually in <tt>/etc</tt>) are usually mode <tt>640</tt>
(<tt>-rw-r-----</tt>), 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
<tt>/etc/shadow</tt>, should only be readable by root, and directories in <tt>/etc</tt>
should at least not be accessible by others.
<P>
<descrip>
<tag /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.
</descrip>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Integrity Checking
<P>
Another very good way to detect local (and also network) attacks on
your system is to run an integrity checker like <tt>Tripwire</tt>,
<tt>Aide</tt> or <tt>Osiris</tt>.
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.
<P>
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.
<P>
You can even add a <tt>crontab</tt> entry to run the checker from your floppy
every night and mail you the results in the morning. Something like:
<tscreen><verb>
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
</verb></tscreen>
will mail you a report each morning at 5:15am.
<P>
Integrety 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.
<P>
You can find the open sourced version of <tt>Tripwire</tt> at <htmlurl
url="http://www.tripwire.org" name="http://www.tripwire.org">,
free of charge. Manuals and support can be purchased.
<P>
<tt>Aide</tt> can be found at <htmlurl
url="http://www.cs.tut.fi/~rammer/aide.html"
name="http://www.cs.tut.fi/~rammer/aide.html">.
<P>
<tt>Osiris</tt> can be found at <htmlurl
url="http://www.shmoo.com/osiris/" name="http://www.shmoo.com/osiris/">.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Trojan Horses
<P>
"Trojan Horses" are named after the fabled ploy in Homer's "Iliad".
The idea is that a cracker distributes a program or binary that sounds
great, and encourages other people to download it and run it as root. Then
the program can compromise their 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.
<P>
You should take care of what programs you install on your
machine. Redhat provides MD5 checksums and PGP signatures on it's 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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Password Security and Encryption <label id="password-security">
<P>
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 <tt>passwd</tt> programs that do not allow you to set a
easily guessable password. Make sure your <tt>passwd</tt> program is up to date
and has these features.
<P>
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.
<P>
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)
<tt>/etc/passwd</tt> (or less commonly) <tt>/etc/shadow</tt>. 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 unices use is one-way. This
means that it should not be possible to reverse the encryption to get
the password from the contents of <tt>/etc/passwd</tt> (or <tt>/etc/shadow</tt>).
<P>
Brute force attacks, such as "Crack" or "John the Ripper" (see Section <ref id="crack">) 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.
<P>
You can go to <htmlurl
url="http://consult.cern.ch/writeup/security/security_3.html"
name="http://consult.cern.ch/writeup/security/security_3.html"> for
information on how to choose a good password.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> PGP and Public-Key Cryptography
<P>
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.
<P>
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.
<P>
There are advantages to both public key and private key cryptography,
and you can read about those differences in <url url="http://www.rsa.com/rsalabs/newfaq/" name="the RSA Cryptography FAQ">,
listed at the end of this section.
<P>
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: <htmlurl
url="http://www.pgp.com/service/export/faq/55faq.cgi"
name="http://www.pgp.com/service/export/faq/55faq.cgi">
<P>
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.
<P>
US export controls are now managed by EAR (Export Administration
Regulations). They are no longer governed by ITAR.
<P>
There is also a step-by-step guide for configuring PGP on Linux
available at <htmlurl
url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"
name="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 <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/apps/crypto"
name="ftp://metalab.unc.edu/pub/Linux/apps/crypto">.
<P>
There is a project working on 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 nearly in compliance with <htmlurl
url="http://www.faqs.org/rfcs/rfc2440.html" name="OpenPGP">.
See the GNU Privacy Guard web page for more information:
<htmlurl url="http://www.gnupg.org"
name="http://www.gnupg.org/">.
<P>
More information on cryptography can be found in the RSA cryptography
FAQ, available at <htmlurl url="http://www.rsa.com/rsalabs/newfaq/"
name="http://www.rsa.com/rsalabs/newfaq/">. Here you will find
information on such terms as "Diffie-Hellman", "public-key
cryptography", "digital certificates", etc.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> SSL, S-HTTP, HTTPS and S/MIME
<P>
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.
<ITEMIZE>
<ITEM><bf>SSL:</bf> - 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 <htmlurl
url="http://www.consensus.com/security/ssl-talk-faq.html"
name="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 <htmlurl
url="http://home.netscape.com/info/security-doc.html"
name="http://home.netscape.com/info/security-doc.html">.
<P>
<ITEM><bf>S-HTTP:</bf> - S-HTTP is another protocol that provides
security services across the Internet. It was designed to provide
confidentiality, authentication, integrity, and non-repudiability &lsqb
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. &lsqb From RSA Cryptography FAQ,
page 138]
<P>
<ITEM><bf>S/MIME:</bf> - 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 <htmlurl
url="http://home.netscape.com/assist/security/smime/overview.html"
name="http://home.netscape.com/assist/security/smime/overview.html">.
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Linux IPSEC Implementations
<P>
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 <htmlurl
url="http://www.ietf.org/html.charters/ipsec-charter.html"
name="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.
<P>
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 <htmlurl
url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html"
name="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.
<P>
Another freely-available IPSEC implementation is the Linux FreeS/WAN
IPSEC. Their web page states,
<quote>"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."
</quote>
<P>It's available for download from <htmlurl
url="http://www.xs4all.nl/~freeswan/"
name="http://www.xs4all.nl/~freeswan/">, and has just reached 1.0 at the
time of this writing.
<P>
As with other forms of cryptography, it is not distributed with the
kernel by default due to export restrictions.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> <tt>ssh</tt> (Secure Shell) and <tt>stelnet</tt><label id="ssh">
<P>
<tt>ssh</tt> and <tt>stelnet</tt> are suite's of programs that
allow you to login to remote systems and have a encrypted connection.
<P>
<tt>openssh</tt> is a suite of programs used as a secure replacement
for <tt>rlogin</tt>, <tt>rsh</tt> and <tt>rcp</tt>. 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.
<P>
There are several ssh implementiations now. The original commercial
implementation by Data Fellows can be found at
The <tt>ssh</tt> home page can be found at <htmlurl
url="http://www.datafellows.com"
name="http://www.datafellows.com">.
<P>
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 propriatary peices. It is free and under a BSD
liscence. It can be found at: <htmlurl url="http://www.openssh.com"
name="http://www.openssh.com">.
<P>
There is also a open source
project to re-implement ssh from the ground up called "psst...". For
more information see: <htmlurl url="http://www.net.lut.ac.uk/psst/"
name="http://www.net.lut.ac.uk/psst/">
<P>
You can also use <tt>ssh</tt> from your Windows workstation to your
Linux <tt>ssh</tt>
server. There are several freely available Windows client
implementations, including the one at <htmlurl
url="http://guardian.htu.tuwien.ac.at/therapy/ssh/"
name="http://guardian.htu.tuwien.ac.at/therapy/ssh/"> as well as a
commercial implementation from DataFellows, at <htmlurl
url="http://www.datafellows.com"
name="http://www.datafellows.com">.
<P>
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.
<P>
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 <htmlurl url="http://www.psy.uq.oz.au/~ftp/Crypto/"
name="http://www.psy.uq.oz.au/~ftp/Crypto/">.
<P>
SRP is another secure telnet/ftp implementation. From their web page:
<P>
<quote>"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!" </quote>
<P>
For more information, go to <htmlurl url="http://srp.stanford.edu/srp"
name="http://srp.stanford.edu/srp">.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> PAM - Pluggable Authentication Modules
<P>
Newer versions of the Red Hat Linux distribution 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. <htmlurl
url="http://www.kernel.org/pub/linux/libs/pam/index.html"
name="http://www.kernel.org/pub/linux/libs/pam/index.html">.
<P>
Just a few of the things you can do with PAM:
<P>
<ITEMIZE>
<ITEM>
Use encryption other than DES for your passwords. (Making them harder to
brute-force decode)
<ITEM>
Set resource limits on all your users so they can't perform
denial-of-service attacks (number of processes, amount of memory, etc)
<ITEM>
Enable shadow passwords (see below) on the fly
<ITEM>
allow specific users to login only at specific times from specific
places
</ITEMIZE>
<P>
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 <tt>.rhosts</tt> files in user's home
directories by adding these lines to <tt>/etc/pam.d/rlogin</tt>:
<tscreen><verb>
#
# Disable rsh/rlogin/rexec for users
#
login auth required pam_rhosts_auth.so no_rhosts
</verb></tscreen>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1>Cryptographic IP Encapsulation (CIPE)
<P>
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.
<P>
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.
<P>
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.
<P>
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.
<P>
Summarized from the CIPE documentation:
<P>
<quote>
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.
</quote>
<P>
Further information can be found at
<htmlurl url="http://www.inka.de/~bigred/devel/cipe.html"
name="http://www.inka.de/~bigred/devel/cipe.html">
<P>
As with other forms of cryptography, it is not distributed with the
kernel by default due to export restrictions.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Kerberos
<P>
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.
<P>
This authentication is then used by programs such as <tt>rlogin</tt> to allow
the user to login to other hosts without a password (in place of the
<tt>.rhosts</tt> 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.
<P>
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.
<P>
You can find more information about kerberos by looking at <htmlurl
url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/kerberos-faq/general/faq.html"
name="the kerberos FAQ">, and the code can be found at <htmlurl
url="http://nii.isi.edu/info/kerberos/"
name="http://nii.isi.edu/info/kerberos/">.
<P>
[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.]
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Shadow Passwords.
<P>
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 <tt>/etc/passwd</tt> 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 <tt>/etc/shadow</tt>, 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 <htmlurl
url="http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"
name="http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html">
It is rather dated now, and will not be required for distributions
supporting PAM.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> "Crack" and "John the Ripper"<label id="crack">
<P>
If for some reason your <tt>passwd</tt> 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.
<P>
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.
<P>
There are a number of programs out there...the two most notable of
which are "Crack" and "John the Ripper"
(<htmlurl url="http://www.false.com/security/john/index.html"
name="http://www.false.com/security/john/index.html">) . They will take
up a lot of your cpu time, but you should be able to tell if an
attacker could get in using them by running them first yourself and
notifying users with weak passwords. Note that an attacker would have
to use some other hole first in order to read your
<tt>/etc/passwd</tt> file, but such holes are more common than you might think.
<P>
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 <htmlurl url="http://www.l0pht.com" name="http://www.l0pht.com">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System
<P>
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 <htmlurl
url="http://www.zedz.net/redhat/"
name="http://www.zedz.net/redhat/">, and more information on how it
all works is at <htmlurl url="ftp://ftp.research.att.com/dist/mab/"
name="ftp://ftp.research.att.com/dist/mab/">.
<P>
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: <htmlurl
url="http://edu-gw.dia.unisa.it/tcfs/"
name="http://edu-gw.dia.unisa.it/tcfs/" >.
<P>
It also need not be used on entire filesystems. It works on
directory trees as well.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> X11, SVGA and display security
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> X11
<P>
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.
<P>
X has a number of access-control mechanisms. The simplest of them is
host-based: you use <tt>xhost</tt> 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 <tt>xhost + <it>their machine</it></tt> and get in
easily. Also, if you have to allow access from an untrusted machine,
anyone there can compromise your display.
<p>
When using <tt>xdm</tt> (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 <tt>.Xauthority</tt> file. If you need to allow a remote machine
access to your display, you can use the <tt>xauth</tt> command and the
information in your <tt>.Xauthority</tt> file to provide access to only that connection.
See the Remote-X-Apps mini-howto, available at <htmlurl
url="http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html"
name="http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html">.
<P>
You can also use <tt>ssh</tt> (see <ref id="ssh">, 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.
<P>
Take a look at the <tt>Xsecurity</tt> man page for more information on X
security. The safe bet is to use <tt>xdm</tt> to login to your console and then
use <tt>ssh</tt> to go to remote sites on which you wish to run X programs.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> SVGA
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> GGI (Generic Graphics Interface project)
<P>
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 <tt>login</tt> program
running on your console. <htmlurl
url="http://synergy.caltech.edu/~ggi/"
name="http://synergy.caltech.edu/~ggi/">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Kernel Security<label id="kernel-security">
<P>
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.
<P>
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 <url url="ftp://ftp.kernel.org"> or from your distribution
vendor.
<P>
There is also a international group providing a single unified crypto
patch to the mainstream Lnux kernel. This patch provides support for
a number of cyrptographic subsystems and things that cannot be
included in the mainstream kernel due to export restrictions. For more
information, visit their web page at: <htmlurl
url="http://www.kerneli.org" name="http://www.kerneli.org">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> 2.0 Kernel Compile Options
<P>
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 <tt>./linux/Documentation/Configure.help</tt>, which is
the same document that is referenced while using the Help facility during
the <tt>make config</tt> stage of compiling the kernel.
<P>
<ITEMIZE>
<ITEM>Network Firewalls
(CONFIG_FIREWALL)
<P>
This option should be on if you intend to run any firewalling or
masquerading on your Lnux machine. If it's just going to be a regular
client machine, it's safe to say no.
<P>
<ITEM>IP: forwarding/gatewaying
(CONFIG_IP_FORWARD)
<P>
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.
<P>
You can enable IP forwarding dynamically using the following command:
<P><tscreen><verb>
root# echo 1 > /proc/sys/net/ipv4/ip_forward
</verb></tscreen>
and disable it with the command:
<tscreen><verb>
root# echo 0 > /proc/sys/net/ipv4/ip_forward
</verb></tscreen>
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.
<P>
<ITEM>IP: syn cookies
(CONFIG_SYN_COOKIES)
<P>
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:
<P>
<tscreen><verb>
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>
</verb></tscreen>
<P>
<ITEM>IP: Firewalling
(CONFIG_IP_FIREWALL)
<P>
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.
<P>
<P>
<ITEM>IP: firewall packet logging
(CONFIG_IP_FIREWALL_VERBOSE)
<P>
This option gives you information about packets your firewall
received, like sender, recipient, port, etc.
<ITEM>IP: Drop source routed frames
(CONFIG_IP_NOSR)
<P>
This option should be enabled. Source routed frames contain the
entire path to their destination inside of the packet. This means
that routers through which the packet goes do not need to inspect it,
and just forward it on. This could lead to data entering your system
that may be a potential exploit.
<P>
<ITEM>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 forwards the traffic
to the intended destination, but makes it look like it came from the
firewall box itself. See <htmlurl url="http://www.indyramp.com/masq"
name="http://www.indyramp.com/masq"> for more information.
<P>
<ITEM>IP: ICMP masquerading
(CONFIG_IP_MASQUERADE_ICMP)
This option adds ICMP masquerading to the previous option of only
masquerading TCP or UDP traffic.
<P>
<ITEM>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 <htmlurl url="http://www.indyramp.com/masq"
name="http://www.indyramp.com/masq"> for more information.
<P>
<ITEM>IP: always defragment
(CONFIG_IP_ALWAYS_DEFRAG)
<P>
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.
<P>
<ITEM>Packet Signatures
(CONFIG_NCPFS_PACKET_SIGNING)
<P>
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.
<P>
<ITEM>IP: Firewall packet netlink device
(CONFIG_IP_FIREWALL_NETLINK)
<P>
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.
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> 2.2 Kernel Compile Options
<P>
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
<tt>./linux/Documentation/Configure.help</tt>, which is the same
document that is referenced while using the Help facility during
the <tt>make config</tt> 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 <tt>ipchains</tt>
program is now used to install IP firewalling, instead of the
<tt>ipfwadm</tt> program used in the 2.0 kernel.
<P>
<ITEMIZE>
<ITEM>Socket Filtering
(CONFIG_FILTER)
<P>
For most people, it's safe to say no to this option. This option
allows you to connect a userspace 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.
<P>
<ITEM>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/
<P>
<ITEM>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 <tt>./linux/Documentation/networking/filter.txt</tt> for
more information.
<P>
<ITEM>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.
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Kernel Devices
<P>
There are a few block and character devices available on Linux that
will also help you with security.
<P>
The two devices <tt>/dev/random</tt> and <tt>/dev/urandom</tt> are provided by the
kernel to provide random data at any time.
<P>
Both <tt>/dev/random</tt> and <tt>/dev/urandom</tt> should be secure enough to use in
generating PGP keys, <tt>ssh</tt> 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.
<P>
The only difference between the two devices, is that <tt>/dev/random</tt> 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 <tt>/dev/random</tt>. (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".)
<P>
<tt>/dev/random</tt> is high quality entropy, generated from measuring the
inter-interrupt times etc. It blocks until enough bits of random data
are available.
<P>
<tt>/dev/urandom</tt> 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.
<P>
You might read from the devices using something like:
<P><tscreen><verb>
root# head -c 6 /dev/urandom | mimencode
</verb></tscreen>
This will print eight random characters on the console, suitable for
password generation. You can find <tt>mimencode</tt> in the <tt>metamail</tt>
package.
<P>
See <tt>/usr/src/linux/drivers/char/random.c</tt> for a description of the
algorithm.
<P>
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel
for helping me (Dave) with this.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Network Security<label id="network-security">
<P>
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.
<P>
There are a number of good tools to assist with network security, and
more and more of them are shipping with Linux distributions.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Packet Sniffers
<P>
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
<tt>passwd</tt> and <tt>login</tt> and <tt>su</tt> 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.
<P>
Example: Host A has been compromised. Attacker installs a
sniffer. Sniffer picks up admin logging into Host B from Host C. It
gets the admin's personal password as they login to B. Then, the admin
does a <tt>su</tt> to fix a problem. They now have the root password for Host
B. Later the admin lets someone <tt>telnet</tt> from his account to Host Z on
another site. Now the attacker has a password/login on Host Z.
<P>
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.
<P>
Using <tt>ssh</tt> 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.)
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> System services and tcp_wrappers
<P>
Before you put your Linux system on <em>ANY</em> 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.
<P>
There are a number of ways to disable services under Linux. You can
look at your <tt>/etc/inetd.conf</tt> file and see what services are being
offered by your <tt>inetd</tt>. Disable any that you do not need by commenting
them out (<tt>&num;</tt> at the beginning of the line), and then sending
your inetd process a SIGHUP.
<P>
You can also remove (or comment out) services in your <tt>/etc/services</tt>
file. This will mean that local clients will also be unable to find
the service (i.e., if you remove <tt>ftp</tt>, 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 <tt>/etc/services</tt>, since it provides no
additional security. If a local person wanted to use <tt>ftp</tt> even though
you had commented it out, they would make their own client that used
the common FTP port and would still work fine.
<P>
Some of the services you might want to leave enabled are:<P>
<itemize><item><tt>ftp</tt>
<item><tt>telnet</tt> (or <tt>ssh</tt>)
<item>mail, such as <tt>pop-3</tt> or <tt>imap</tt>
<item><tt>identd</tt>
</itemize>
<P>
If you know you are not going to use some particular package, you can
also delete it entirely. <tt>rpm -e <it>packagename</it></tt> under
the Red Hat distribution will erase an entire package. Under debian
<tt>dpkg --remove</tt> does the same thing.
<P>
Additionally, you really want to disable the rsh/rlogin/rcp utilities,
including login (used by <tt>rlogin</tt>), shell (used by <tt>rcp</tt>),
and exec (used
by <tt>rsh</tt>) from being started in <tt>/etc/inetd.conf</tt>.
These protocols are extremely insecure and have been the cause of exploits
in the past.
<P>
You should check <tt>/etc/rc.d/rc[0-9].d</tt> (on Red Hat;
<tt>/etc/rc[0-9].d</tt> 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
<tt>/etc/rc.d/init.d</tt> (on Red Hat; <tt>/etc/init.d</tt> on Debian).
Renaming the files in the <tt>init.d</tt> 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 <tt>S</tt> with a lower-case
<tt>s</tt>, like this:
<P><tscreen><verb>
root# cd /etc/rc6.d
root# mv S45dhcpd s45dhcpd
</verb></tscreen>
<P>
If you have BSD-style <tt>rc</tt> files, you will want to check
<tt>/etc/rc*</tt> for programs you don't need.
<P>
Most Linux distributions ship with tcp_wrappers "wrapping" all your
TCP services. A tcp_wrapper (<tt>tcpd</tt>) is invoked from <tt>inetd</tt> instead of
the real server. <tt>tcpd</tt> then checks the host that is requesting the
service, and either executes the real server, or denies access from that
host. <tt>tcpd</tt> allows you to restrict access to your TCP services. You
should make a <tt>/etc/hosts.allow</tt> and add in only those hosts that need
to have access to your machine's services.
<P>
If you are a home dialup user, we suggest you deny ALL. <tt>tcpd</tt> 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 <tt>/etc/hosts.allow</tt>:
<P>
ALL: 127.
<P>
And of course /etc/hosts.deny would contain:
<P>
ALL: ALL
<P>
which will prevent external connections to your machine, yet still
allow you from the inside to connect to servers on the Internet.
<P>
Keep in mind that tcp_wrappers only protects services executed from
<tt>inetd</tt>, and a select few others. There very well may be other
services running on your machine. You can use <tt>netstat -ta</tt> to
find a list of all the services your machine is offering.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Verify Your DNS Information
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> <tt>identd</tt>
<P>
<tt>identd</tt> is a small program that typically runs out of your
<tt>inetd</tt> server. It keeps track of what user is running what TCP
service, and then reports this to whoever requests it.
<P>
Many people misunderstand the usefulness of <tt>identd</tt>, and so disable it
or block all off site requests for it. <tt>identd</tt> is not there to help out
remote sites. There is no way of knowing if the data you get from the
remote <tt>identd</tt> is correct or not. There is no authentication in <tt>identd</tt>
requests.
<P>
Why would you want to run it then? Because it helps <em>you</em> out, and is
another data-point in tracking. If your <tt>identd</tt> 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 <tt>identd</tt>,
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.
<P>
The <tt>identd</tt> that ships with most distributions is more configurable
than many people think. You can disable it for specific users
(they can make a <tt>.noident</tt> file), you can log all
<tt>identd</tt> requests (We recommend it), you can even have identd
return a uid instead of a user name or even NO-USER.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> SATAN, ISS, and Other Network Scanners
<P>
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.
<P>
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 <url
url="http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/"
name="metalab"> or a reputable FTP or web site. There was a Trojan
copy of SATAN that was distributed out on the net. <htmlurl
url="http://www.trouble.org/~zen/satan/satan.html"
name="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.
<P>
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.
<P>
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. <htmlurl url="http://www.psionic.com/abacus"
name="http://www.psionic.com/abacus/">
<P>
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:
<htmlurl url="http://www.wwdsi.com/saint" name="http://www.wwdsi.com/~saint">
<P>
Nessus is a free security scanner. It has a GTK graphical interface
for ease of use. It is also designed with a very nice plugin setup for
new port-scanning tests. For more information, take a look at: <htmlurl
url="http://www.nessus.org/" name="http://www.nessus.org">
<P>
<sect2>Detecting Port Scans
<P>
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.
<P>
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
<em>_had no established session_</em> can be taken as proof of life on
that port. I don't think TCP wrappers will detect this.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> <tt>sendmail</tt>, <tt>qmail</tt> and MTA's
<P>
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.
<P>
If you are using <tt>sendmail</tt> it is very important to keep up on current
versions. <tt>sendmail</tt> has a long long history of security
exploits. Always make sure you are running the most recent version from
<htmlurl url="http://www.sendmail.org/" name="http://www.sendmail.org">.
<P>
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:
<tscreen><verb>
# /usr/lib/sendmail -q15m
</verb></tscreen>
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.
<P>
Many administrators choose not to use sendmail, and instead choose one
of the other mail transport agents. You might consider switching over
to <tt>qmail</tt>. <tt>qmail</tt> was designed with security in mind
from the ground up. It's fast, stable, and secure. Qmail can be found at
<htmlurl url="http://www.qmail.org" name="http://www.qmail.org">
<P>
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 <htmlurl url="http:/www.postfix.org"
name="http://www.postfix.org">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Denial of Service Attacks
<P>
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.
<P>
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.
<P>
<ITEMIZE><ITEM>
<bf>SYN Flooding</bf> - 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 <ref
id="kernel-security" name="Kernel Security"> for proper kernel
protection options.
<P>
<item><bf>Pentium "F00F" Bug</bf> - 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!
<P>
<ITEM>
<bf>Ping Flooding</bf> - 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 <em>your</em> machine's return IP, allowing them to
flood you less detectably. You can find more information about the
"smurf" attack at <htmlurl
url="http://www.quadrunner.com/~chuegen/smurf.txt" name="
http://www.quadrunner.com/~chuegen/smurf.txt">
<P>
If you are ever under a ping flood attack, use a tool like <tt>tcpdump</tt> 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.
<P>
<ITEM>
<bf>Ping o' Death</bf> - 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.
<P>
<ITEM>
<bf>Teardrop / New Tear</bf> - 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.
<P>
</ITEMIZE>
You can find code for most exploits, and a more in-depth description of how
they work, at <htmlurl url="http://www.rootshell.com"
name="http://www.rootshell.com"> using their search engine.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> NFS (Network File System) Security.
<P>
NFS is a very widely-used file sharing protocol. It allows servers
running <tt>nfsd</tt> and <tt>mountd</tt> to "export" entire filesystems
to other machines using NFS filesystem support built in to their kernels
(or some other client support if they are not Linux machines).
<tt>mountd</tt> keeps track of mounted filesystems in <tt>/etc/mtab</tt>,
and can display them with <tt>showmount</tt>.
<P>
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.
<P>
There is some small amount of security allowed in exporting
filesystems. You can make your <tt>nfsd</tt> map the remote root user (uid=0)
to the <tt>nobody</tt> 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 <tt>su</tt> to
their account and have total access to their files. This is only a
small hindrance to an attacker that has access to mount your remote
filesystems.
<P>
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.
<P>
See the NFS HOWTO for more information on NFS, available at <htmlurl
url="http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html"
name="http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> NIS (Network Information Service) (formerly YP).
<P>
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 <tt>/etc/passwd</tt> file). This allows users to
change their password once and have it take effect on all the machines
in the NIS domain.
<P>
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.
<P>
There is a much more secure replacement for NIS, called NIS+.
Check out the NIS HOWTO for more information: <htmlurl
url="http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html"
name="http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Firewalls
<P>
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.
<P>
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 <tt>ipfwadm</tt> for 2.0
kernels and <tt>ipchains</tt> 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.
<P>
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 <tt>Firewall-HOWTO</tt> at your latest metalab archive for
more information on firewalls and Linux. <htmlurl
url="http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"
name="http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html">
<P>
More information can also be found in the IP-Masquerade
mini-howto: <htmlurl
url="http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"
name="http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html">
<P>
More information on <tt>ipfwadm</tt> (the tool that lets you change settings on
your firewall, can be found at it's home page: <htmlurl
url="http://www.xos.nl/linux/ipfwadm/"
name="http://www.xos.nl/linux/ipfwadm/">
<P>
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 <htmlurl url="http://www.ora.com" name="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
<htmlurl url="http://csrc.nist.gov/nistpubs/800-10/main.html"
name="http://csrc.nist.gov/nistpubs/800-10/main.html">. Also of interest:
<P>
<ITEMIZE>
<ITEM> The Freefire Project -- a list of freely-available firewall tools,
available at <htmlurl
url="http://sites.inka.de/sites/lina/freefire-l/index_en.html"
name="http://sites.inka.de/sites/lina/freefire-l/index_en.html">
<ITEM> 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 <htmlurl
url="http://www.sunworld.com/swol-01-1996/swol-01-firewall.html"
name="http://www.sunworld.com/swol-01-1996/swol-01-firewall.html">
<ITEM>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: <htmlurl
url="http://www.pobox.com/~wstearns/mason/"
name="http://www.pobox.com/~wstearns/mason/">
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> IP Chains - Linux Kernel 2.2.x Firewalling
<P>
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:
<itemize>
<item> More flexible packet manipulations
<item> More complex accounting
<item> Simple policy changes possible atomically
<item> Fragments can be explicitly blocked, denied, etc.
<item> Logs suspicious packets.
<item> Can handle protocols other than ICMP/TCP/UDP.
</itemize>
<P>
If you are currently using <tt>ipfwadm</tt> on your 2.0 kernel, there are scripts
available to convert the <tt>ipfwadm</tt> command format to the format <tt>ipchains</tt> uses.
<P>
Be sure to read the IP Chains HOWTO for further information. It is
available at <htmlurl url="http://www.rustcorp.com/linux/ipchains/HOWTO.html"
name="http://www.rustcorp.com/linux/ipchains/HOWTO.html">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> VPNs - Virtual Private Networks
<P>
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.
<P>
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: <htmlurl
url="ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html"
name="ip-masq-vpn">.
<P>
There are several Linux VPN solutions available:
<ITEMIZE>
<ITEM> vpnd. See the <htmlurl
url="http://sunsite.auc.dk/vpnd/" name="http://sunsite.auc.dk/vpnd/">.
<ITEM> Free S/Wan, available at <htmlurl url="http://www.xs4all.nl/~freeswan/"
name="http://www.xs4all.nl/~freeswan/">
<ITEM> ssh can be used to construct a VPN. See the VPN mini-howto
for more information.
<ITEM> vps (virtual private server) at <htmlurl
url="http://www.strongcrypto.com" name="http://www.strongcrypto.com">.
</ITEMIZE>
<P>
See also the section on IPSEC for pointers and more information.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Security Preparation (before you go on-line)<label id="secure-prep">
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Make a Full Backup of Your Machine
<P>
Discussion of backup methods and storage is beyond the scope of this
document, but here are a few words relating to backups and security:
<P>
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). 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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Choosing a Good Backup Schedule
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Backup Your RPM or Debian File Database
<P>
In the event of an intrusion, you can use your RPM database like you
would use <tt>tripwire</tt>, 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.
<P>
The files <tt>/var/lib/rpm/fileindex.rpm</tt> and
<tt>/var/lib/rpm/packages.rpm</tt> most likely won't fit on a single floppy.
But if compressed, each should fit on a seperate floppy.
<P>
Now, when your system is compromised, you can use the command:
<P><tscreen><verb>
root# rpm -Va
</verb></tscreen>
to verify each file on the system. See the <tt>rpm</tt> 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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1>Keep Track of Your System Accounting Data<label id="logs">
<P>
It is very important that the information that comes from <tt>syslog</tt>
not be compromised. Making the files in <tt>/var/log</tt> readable and
writable by only a limited number of users is a good start.
<P>
Be sure to keep an eye on what gets written there, especially under
the <tt>auth</tt> facility. Multiple login failures, for example, can
indicate an attempted break-in.
<P>
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 <tt>/var/log</tt> and check <tt>messages</tt>,
<tt>mail.log</tt>, and others.
<P>
You can find out where your distribution is logging to by looking at
your <tt>/etc/syslog.conf</tt> file. This is the file that tells
<tt>syslogd</tt> (the system logging daemon) where to log various messages.
<P>
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 <tt>logrotate</tt> package on recent Red Hat distributions. Other
distributions likely have a similar process.
<P>
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.
<P>
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.
<P>
You should also be sure to separate the <tt>auth</tt> facility from other log
data, including attempts to switch users using <tt>su</tt>, login attempts,
and other user accounting information.
<P>
If possible, configure <tt>syslog</tt> 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
<tt>syslog.conf</tt> man page, and refer to the <tt>@</tt> option.
<P>
There are several more advanced <tt>syslogd</tt> programs out
there. Take a look at <htmlurl url="http://www.core-sdi.com/ssyslog/"
name="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.
<P>
Another <tt>syslogd</tt> with more features is <htmlurl
url="http://www.balabit.hu/products/syslog-ng.html"
name="syslog-ng">. It allows you a lot more flexibility in your
logging and also can has your remote syslog streams to prevent
tampering.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Apply All New System Updates.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> What To Do During and After a Breakin<label id="after-breakin">
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Security Compromise Underway.
<P>
Spotting a security compromise under way can be a tense
undertaking. How you react can have large consequences.
<P>
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.
<P>
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.
<P>
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.
<P>
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 <tt>tcp_wrappers</tt> or <tt>ipfwadm</tt>
to deny access from the intruder's site.
<P>
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 <tt>.rhosts</tt> files,
FTP access, and a host of possible backdoors.
<P>
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.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Security Compromise has already happened
<P>
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?
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Closing the Hole
<P>
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.
<P>
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 <htmlurl
url="http://www.caldera.com/tech-ref/security/"
name="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 <htmlurl
url="http://www.redhat.com/errata"
name="http://www.redhat.com/errata">
<P>
Debian now has a security mailing list and web page. See: <htmlurl
url="http://www.debian.org/security/"
name="http://www.debian.org/security/"> for more information.
<P>
It is very likely that if one vendor has released a security update,
that most other Linux vendors will as well.
<P>
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:
<P>
<quote>
"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"
</quote>
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Assessing the Damage
<P>
The first thing is to assess the damage. What has been compromised?
If you are running an integrity checker like <tt>Tripwire</tt>, 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.
<P>
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.
<P>
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.
<P>
Then you have to worry about how long ago the compromise happened, and
whether the backups hold any damaged work. More on backups later.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Backups, Backups, Backups!
<P>
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.
<P>
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!
<P>
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.)
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT2> Tracking Down the Intruder.
<P>
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.
<P>
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 <tt>whois</tt> 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.
<P>
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.
<P>
You should also notify any security organizations you are a part of
(<url url="http://www.cert.org/" name="CERT"> or similar), as well as your Linux system vendor.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Security Sources<label id="sources">
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1> FTP Sites<label id="ftpsites">
<P>
CERT is the Computer Emergency Response Team. They often send out
alerts of current attacks and fixes. See <htmlurl url="ftp://ftp.cert.org"
name="ftp://ftp.cert.org"> for more information.
<P>
ZEDZ (formerly Replay) (<htmlurl url="http://www.zedz.net" name="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.
<P>
Matt Blaze is the author of CFS and a great security advocate. Matt's
archive is available at <url url="ftp://ftp.research.att.com/pub/mab"
name="ftp://ftp.research.att.com/pub/mab">
<P>
<tt>tue.nl</tt> is a great security FTP site in the Netherlands.
<htmlurl url="ftp://ftp.win.tue.nl/pub/security/"
name="ftp.win.tue.nl">
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Web Sites<label id="websites">
<P>
<ITEMIZE>
<ITEM>
The Hacker FAQ is a FAQ about hackers: <htmlurl
url="http://www.solon.com/~seebs/faqs/hacker.html" name="The Hacker
FAQ">
<ITEM>
The COAST archive has a large number of Unix security programs and
information: <htmlurl url="http://www.cs.purdue.edu/coast/"
name="COAST">
<ITEM> SuSe Security Page: <htmlurl url="http://www.suse.de/security/"
name="http://www.suse.de/security/">
<ITEM>
Rootshell.com is a great site for seeing what exploits are currently
being used by crackers: <htmlurl url="http://www.rootshell.com/"
name="http://www.rootshell.com/">
<ITEM>
BUGTRAQ puts out advisories on security issues: <htmlurl
url="http://www.netspace.org/lsv-archive/bugtraq.html" name="BUGTRAQ
archives">
<ITEM>
CERT, the Computer Emergency Response Team, puts out advisories on
common attacks on Unix platforms: <htmlurl url="http://www.cert.org/"
name="CERT home">
<ITEM>
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: <htmlurl url="http://www.trouble.org"
name="http://www.trouble.org">
<ITEM>
The Linux security WWW is a good site for Linux security information:
<htmlurl url="http://www.aoy.com/Linux/Security/" name="Linux Security
WWW">
<ITEM>
Infilsec has a vulnerability engine that can tell you what
vulnerabilities affect a specific platform: <htmlurl
url="http://www.infilsec.com/vulnerabilities/" name="http://www.infilsec.com/vulnerabilities/">
<ITEM>
CIAC sends out periodic security bulletins on common exploits: <htmlurl
url="http://ciac.llnl.gov/cgi-bin/index/bulletins" name="http://ciac.llnl.gov/cgi-bin/index/bulletins">
<ITEM>
A good starting point for Linux Pluggable Authentication modules can
be found at <htmlurl url="http://www.kernel.org/pub/linux/libs/pam/"
name="http://www.kernel.org/pub/linux/libs/pam/">.
<ITEM>
The Debian project has a web page for their security fixes and
information. It is at <htmlurl url="http://www.debian.com/security/"
name="http://www.debian.com/security/">.
<ITEM> WWW Security FAQ, written by Lincoln Stein, is a great web
security reference. Find it at <htmlurl
url="http://www.w3.org/Security/Faq/www-security-faq.html"
name="http://www.w3.org/Security/Faq/www-security-faq.html">
</ITEMIZE>
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Mailing Lists
<P>
Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
containing the message body subscribe bugtraq. (see links above for
archives).
<P>
CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not
subject) of the message put (either or both): <verb>subscribe ciac-bulletin</verb>
<P>
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 <verb>Subscribe</verb>
See <htmlurl
url="http://www.redhat.com/mailing-lists/redhat-announce-list/"
name="http://www.redhat.com/mailing-lists/redhat-announce-list/"> for
more info and archives.
<P>
The Debian project has a security mailing list that covers their
security fixes. See <htmlurl url="http://www.debian.com/security/"
name="http://www.debian.com/security/"> for more information.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT1> Books - Printed Reading Material
<P>
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.
<P>
Building Internet Firewalls By D. Brent Chapman &amp; Elizabeth D. Zwicky
<P> 1st Edition September 1995
<P> ISBN: 1-56592-124-0
<P>
Practical UNIX &amp; Internet Security, 2nd Edition By Simson Garfinkel &amp; Gene Spafford
<P> 2nd Edition April 1996
<P> ISBN: 1-56592-148-8
<P>
Computer Security Basics By Deborah Russell &amp; G.T. Gangemi, Sr.
<P> 1st Edition July 1991
<P> ISBN: 0-937175-71-4
<P>
Linux Network Administrator's Guide By Olaf Kirch
<P> 1st Edition January 1995
<P> ISBN: 1-56592-087-2
<P>
PGP: Pretty Good Privacy By Simson Garfinkel
<P> 1st Edition December 1994
<P> ISBN: 1-56592-098-8
<P>
Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &amp;
William VonStorch (Consulting Editor Eugene H. Spafford)
<P> 1st Edition August 1995
<P> ISBN: 1-56592-086-4
<P>
<P>
Linux Security By John S. Flowers
<P> New Riders;
<P> ISBN: 0735700354
<P> March 1999
<P>
<P>
Maximum Linux Security : A Hacker's Guide to Protecting Your Linux
Server and Network
<P> Anonymous
<P> Paperback - 829 pages
<P> Sams;
<P> ISBN: 0672313413
<P> July 1999
<P>
<P>
Intrusion Detection By Terry Escamilla
<P> Paperback - 416 pages (September 1998)
<P> John Wiley and Sons;
<P> ISBN: 0471290009
<P>
<P>
Fighting Computer Crime
<P> Donn Parker
<P> Paperback - 526 pages (September 1998)
<P> John Wiley and Sons;
<P> ISBN: 0471163783
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Glossary
<P>
<ITEMIZE>
<ITEM><bf>authentication:</bf> 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.
<P>
<ITEM><bf>bastion Host:</bf> 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.
<P>
<ITEM><bf>buffer overflow:</bf> 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.
<P>
<ITEM><bf>denial of service:</bf> 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 legitmate purposes.
<P>
<ITEM><bf>dual-homed Host:</bf> A general-purpose computer system that
has at least two network interfaces.
<P>
<ITEM><bf>firewall:</bf> A component or set of components that restricts
access between a protected network and the Internet, or between other
sets of networks.
<P>
<ITEM><bf>host:</bf> A computer system attached to a network.
<P>
<ITEM><bf>IP spoofing:</bf> 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.
<P>
<ITEM><bf>non-repudiation:</bf> 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.
<P>
<ITEM><bf>packet:</bf> The fundamental unit of communication on the
Internet.
<P>
<ITEM><bf>packet filtering:</bf> 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.
<P>
<ITEM><bf>perimeter network:</bf> 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.
<P>
<ITEM><bf>proxy server:</bf> 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.
<P>
<ITEM><bf>superuser:</bf> An informal name for <tt>root</tt>.
<P>
</ITEMIZE>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Frequently Asked Questions<label id="q-and-a">
<P>
<enum>
<ITEM> Is it more secure to compile driver support directly into the
kernel, instead of making it a module?
<P>
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.
<P>
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.
<P>
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.
<P>
<ITEM> Why does logging in as root from a remote machine always fail?
<P>
Answer: See <ref id="root-security" name="Root Security">. This is done
intentionally to prevent remote users from attempting to connect via
<tt>telnet</tt> to your machine as <tt>root</tt>, which is a serious
security
vulnerability, because then the root password would be transmitted, in
cleartext, across the network. Don't forget: potential intruders have time on their
side, and can run automated programs to find your password.
<P>
<ITEM> How do I enable shadow passwords on my Red Hat 4.2 or 5.x Linux
box?
<P>
Answer:
<P>
To enable shadow passwords, run <tt>pwconv</tt> as root, and
<tt>/etc/shadow</tt> 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 <tt>/etc/passwd</tt> to shadow
passwords without any other change.
<P>
Some background: shadow passwords is a mechanism for storing your
password in a file other than the normal <tt>/etc/passwd</tt> file. This has
several advantages. The first one is that the shadow file,
<tt>/etc/shadow</tt>, is only readable by root, unlike <tt>/etc/passwd</tt>,
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.
<P>
The <tt>/etc/passwd</tt> file is then used to store user and group names, used
by programs like <tt>/bin/ls</tt> to map the user ID to the proper username
in a directory listing.
<P>
The <tt>/etc/shadow</tt> file then only contains the username and his/her
password, and perhaps accounting information, like when the account
expires, etc.
<P>
To enable shadow passwords, run <tt>pwconv</tt> as root, and
<tt>/etc/shadow</tt> 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 <tt>/etc/passwd</tt> to shadow
passwords without any other change.
<P>
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 <tt>pam_cracklib</tt> 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.
<P>
<ITEM> How can I enable the Apache SSL extensions?
<P>
Answer:
<P>
<enum>
<item>Get SSLeay 0.8.0 or later from <url
url="ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL"><P>
<item>Build and test and install it!<P>
<item>Get Apache 1.2.5 source<P>
<item>Get Apache SSLeay extensions from
<url
url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/apache_1.2.5+ssl_1.13.tar.gz"
name="here"><P>
<item>Unpack it in the apache-1.2.5 source directory and patch Apache as
per the README.<P>
<item>Configure and build it.<P>
</enum>
<P>
You might also try <htmlurl url="http://www.zedz.net" name="ZEDZ net">
which has many pre-built packages, and is located outside of the United States.
<P>
<ITEM> How can I manipulate user accounts, and still retain security?
<P>
Answer: The Red Hat distribution, especially RH5.0, contains a great
number of tools to change the properties of user accounts.
<P>
<ITEMIZE>
<ITEM>The <tt>pwconv</tt> and <tt>unpwconv</tt> programs can be used to convert
between shadow and non-shadowed passwords.
<ITEM>The <tt>pwck</tt> and <tt>grpck</tt> programs can be used to verify proper
organization of the <tt>passwd</tt> and <tt>group</tt> files.
<ITEM>The <tt>useradd</tt>, <tt>usermod</tt>, and <tt>userdel</tt> programs can be used to
add, delete and modify user accounts. The <tt>groupadd</tt>,
<tt>groupmod</tt>, and <tt>groupdel</tt> programs will do the same for groups.
<ITEM>Group passwords can be created using <tt>gpasswd</tt>.
</ITEMIZE>
All these programs are "shadow-aware" -- that is, if you enable shadow
they will use <tt>/etc/shadow</tt> for password information, otherwise they won't.
<P>
See the respective man pages for further information.
<P>
<ITEM> How can I password-protect specific HTML documents using
Apache?
<P>
I bet you didn't know about <htmlurl url="http://www.apacheweek.com"
name="http://www.apacheweek.org">, did you?
<P>
You can find information on user authentication at <htmlurl
url="http://www.apacheweek.com/features/userauth"
name="http://www.apacheweek.com/features/userauth"> as well as other
web server security tips from <htmlurl
url="http://www.apache.org/docs/misc/security_tips.html"
name="http://www.apache.org/docs/misc/security_tips.html">
</enum>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Conclusion<label id="conclusion">
<P>
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 <tt>tripwire</tt> regularly,
you can do even more.
<P>
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.
<P>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<SECT> Acknowledgements
<P>
Information here is collected from many sources. Thanks to the
following that either indirectly or directly have contributed:
following who either indirectly or directly have contributed:
<tscreen>
Rob Riggs
<htmlurl url="mailto:rob@DevilsThumb.com" name="rob@DevilsThumb.com">
<P>
S. Coffin
<htmlurl url="mailto:scoffin@netcom.com" name="scoffin@netcom.com">
<P>
Viktor Przebinda
<htmlurl url="mailto:viktor@CRYSTAL.MATH.ou.edu"
name="viktor@CRYSTAL.MATH.ou.edu">
<P>
Roelof Osinga
<htmlurl url="mailto:roelof@eboa.com" name="roelof@eboa.com">
<P>
Kyle Hasselbacher
<htmlurl url="mailto:kyle@carefree.quux.soltec.net"
name="kyle@carefree.quux.soltc.net">
<P>
David S. Jackson
<htmlurl url="mailto:dsj@dsj.net" name="dsj@dsj.net">
<P>
Todd G. Ruskell
<htmlurl url="mailto:ruskell@boulder.nist.gov"
name="ruskell@boulder.nist.gov">
<P>
Rogier Wolff
<htmlurl url="mailto:R.E.Wolff@BitWizard.nl"
name="R.E.Wolff@BitWizard.nl">
<P>
Antonomasia <htmlurl url="mailto:ant@notatla.demon.co.uk"
name="ant@notatla.demon.co.uk">
<P>
Nic Bellamy <htmlurl url="mailto:sky@wibble.net"
name="sky@wibble.net">
<P>
Eric Hanchrow <htmlurl url="mailto:offby1@blarg.net"
name="offby1@blarg.net">
<P>
Robert J. Berger<htmlurl url="mailto:rberger@ibd.com"
name="rberger@ibd.com">
<P>
Ulrich Alpers <htmlurl url="mailto:lurchi@cdrom.uni-stuttgart.de"
name="lurchi@cdrom.uni-stuttgart.de">
<P>
David Noha <htmlurl url="mailto:dave@c-c-s.com" name="dave@c-c-s.com">
<P>
Pavel Epifanov. <htmlurl url="mailto:epv@ibm.net" name="epv@ibm.net">
<P>
Joe Germuska. <htmlurl url="mailto:joe@germuska.com"
name="joe@germuska.com">
<P>
Franklin S. Werren <htmlurl url="mailto:fswerren@bagpipes.net"
name="fswerren@bagpipes.net">
<P>
Paul Rusty Russell <htmlurl url="mailto:Paul.Russell@rustcorp.com.au"
name="<Paul.Russell@rustcorp.com.au>">
<P>
Christine Gaunt <htmlurl url="mailto:cgaunt@umich.edu"
name="<cgaunt@umich.edu>">
<P>
lin <htmlurl url="mailto:bhewitt@refmntutl01.afsc.noaa.gov"
name="bhewitt@refmntutl01.afsc.noaa.gov">
<P>
A. Steinmetz <htmlurl url="mailto:astmail@yahoo.com"
name="astmail@yahoo.com">
<P>
Jun Morimoto <htmlurl url="mailto:morimoto@xantia.citroen.org"
name="morimoto@xantia.citroen.org">
<P>
Xiaotian Sun <htmlurl url="mailto:sunx@newton.me.berkeley.edu"
name="sunx@newton.me.berkeley.edu">
<P>
Eric Hanchrow <htmlurl url="mailto:offby1@blarg.net"
name="offby1@blarg.net">
<P>
The following have translated this HOWTO into various other languages!
<P>
A special thank you to all of them for help spreading the Linux word...
<P>
Polish: Ziemek Borowski <htmlurl
url="mailto:ziembor@FAQ-bot.ZiemBor.Waw.PL"
name="ziembor@FAQ-bot.ZiemBor.Waw.PL">
<P>
Japanese: FUJIWARA Teruyoshi <htmlurl url="mailto:fjwr@mtj.biglobe.ne.jp"
name="fjwr@mtj.biglobe.ne.jp">
<P>
Indonesian: Tedi Heriyanto <htmlurl
url="mailto:22941219@students.ukdw.ac.id"
name="22941219@students.ukdw.ac.id">
<P>
Korean: Bume Chang <htmlurl url="mailto:Boxcar0001@aol.com"
name="Boxcar0001@aol.com">
<P>
Spanish: Juan Carlos Fernandez <htmlurl
url="mailto:piwiman@visionnetware.com"
name="piwiman@visionnetware.com">
<P>
Dutch: R. Ekkebus <htmlurl url="mailto:reggy@zeelandnet.nl"
name="reggy@zeelandnet.nl">
<P>
</tscreen>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</article>
View Git Blame Copy Permalink