mirror of https://github.com/tLDP/LDP
5637 lines
168 KiB
XML
5637 lines
168 KiB
XML
<?xml version='1.0' encoding='ISO-8859-1'?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
|
|
<!--
|
|
Changelog: (R) = Publication Released
|
|
20020611: XML converted version.
|
|
20020625: Fixed broken rsalabs link.
|
|
20040115: minor fixes.
|
|
20040122: more minor fixes.
|
|
-->
|
|
|
|
<article id="Security-HOWTO">
|
|
|
|
<articleinfo>
|
|
|
|
<title>Linux Security HOWTO</title>
|
|
<author>
|
|
<firstname>Kevin</firstname>
|
|
<surname>Fenzi</surname>
|
|
<affiliation>
|
|
<orgname>tummy.com, ltd.</orgname>
|
|
<address><email>kevin-securityhowto@tummy.com</email></address>
|
|
</affiliation>
|
|
</author>
|
|
<author>
|
|
<firstname>Dave</firstname>
|
|
<surname>Wreski</surname>
|
|
<affiliation>
|
|
<orgname>linuxsecurity.com</orgname>
|
|
<address><email>dave@linuxsecurity.com</email></address>
|
|
</affiliation>
|
|
</author>
|
|
|
|
<pubdate>v2.3, 22 January 2004</pubdate>
|
|
|
|
<abstract>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</abstract>
|
|
|
|
</articleinfo>
|
|
|
|
<sect1>
|
|
<title>Introduction</title>
|
|
|
|
<para>
|
|
This document covers some of the main issues that affect
|
|
Linux security. General philosophy and net-born resources are
|
|
discussed.
|
|
</para>
|
|
|
|
<para>
|
|
A number of other HOWTO documents overlap with security issues, and
|
|
those documents have been pointed to wherever appropriate.
|
|
</para>
|
|
|
|
<para>
|
|
This document is <emphasis>not</emphasis> 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.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>New Versions of this Document</title>
|
|
|
|
<para>
|
|
New versions of this document will be periodically posted to
|
|
<emphasis remap="it">comp.os.linux.answers</emphasis>. They will also be added to the
|
|
various sites that archive such information, including:
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="http://www.linuxdoc.org/"
|
|
>http://www.linuxdoc.org/</ulink
|
|
></literal>
|
|
</para>
|
|
|
|
<para>
|
|
The very latest version of this document should also be
|
|
available in various formats from:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="http://scrye.com/~kevin/lsh/"
|
|
>http://scrye.com/~kevin/lsh/</ulink
|
|
></literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="http://www.linuxsecurity.com/docs/Security-HOWTO"
|
|
>http://www.linuxsecurity.com/docs/Security-HOWTO</ulink
|
|
></literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="http://www.tummy.com/security-howto"
|
|
>http://www.tummy.com/security-howto</ulink
|
|
></literal>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Feedback</title>
|
|
|
|
<para>
|
|
All comments, error reports, additional information and criticism
|
|
of all sorts should be directed to:
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="mailto:kevin-securityhowto@tummy.com"
|
|
>kevin-securityhowto@tummy.com</ulink
|
|
></literal>
|
|
</para>
|
|
|
|
<para>
|
|
and
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="mailto:dave@linuxsecurity.com"
|
|
>dave@linuxsecurity.com</ulink
|
|
></literal>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Note</emphasis>: Please send your feedback to <emphasis>both</emphasis> authors. Also, be sure and
|
|
include "Linux" "security", or "HOWTO" in your subject to avoid Kevin's
|
|
spam filter.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Disclaimer</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
A number of the examples and descriptions use the RedHat(tm) package
|
|
layout and system setup. Your mileage may vary.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<ulink
|
|
url="http://www.gnu.org/copyleft/gpl.html"
|
|
>GNU</ulink
|
|
> terms.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Copyright Information</title>
|
|
|
|
<para>
|
|
This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski,
|
|
and distributed under the following terms:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
If you have questions, please contact Tim Bynum, the
|
|
Linux HOWTO coordinator, at
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt"><ulink
|
|
url="mailto:tjbynum@metalab.unc.edu"
|
|
>tjbynum@metalab.unc.edu</ulink
|
|
></literal>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Overview</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Why Do We Need Security?</title>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.catb.org/~esr/faqs/hacker-howto.html"
|
|
>http://www.catb.org/~esr/faqs/hacker-howto.html</ulink
|
|
>.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>How Secure Is Secure?</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Another factor to take into account is that the more secure your
|
|
system is, the more intrusive your security becomes. You need to
|
|
decide where in this balancing act your system will still be usable,
|
|
and yet secure for your purposes. For instance, you could require
|
|
everyone dialing into your system to use a call-back modem to call
|
|
them back at their home number. This is more secure, but if someone is
|
|
not at home, it makes it difficult for them to login. You could also
|
|
setup your Linux system with no network or connection to the Internet,
|
|
but this limits its usefulness.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.faqs.org/rfcs/rfc2196.html"
|
|
>http://www.faqs.org/rfcs/rfc2196.html</ulink
|
|
>. It has been recently
|
|
updated, and contains a great framework for establishing a security
|
|
policy for your company.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>What Are You Trying to Protect?</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Risk</emphasis> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">.rhosts</literal> file, or to use an insecure
|
|
service such as <literal remap="tt">tftp</literal>, 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>Threat</emphasis> 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.
|
|
</para>
|
|
|
|
<para>
|
|
There are several types of intruders, and it is useful to keep their
|
|
different characteristics in mind as you are securing your systems.
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis remap="bf">The Curious</emphasis> - This type of intruder is basically
|
|
interested in finding out what type of system and data you have.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis remap="bf">The Malicious</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">The High-Profile Intruder</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">The Competition</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">The Borrowers</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">The Leapfrogger</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Vulnerability describes how well-protected your computer is from
|
|
another network, and the potential for someone to gain unauthorized
|
|
access.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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?
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Developing A Security Policy</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
A generally-accepted security policy starts with the phrase
|
|
</para>
|
|
|
|
<para>
|
|
<quote
|
|
><emphasis remap="bf"> That which is not permitted is prohibited</emphasis></quote
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
<ulink
|
|
url="ftp://www.faqs.org/rfcs/rfc1244.html"
|
|
>rfc1244</ulink
|
|
>
|
|
is a document that describes how to create your own network security
|
|
policy.
|
|
</para>
|
|
|
|
<para>
|
|
<ulink
|
|
url="ftp://www.faqs.org/rfcs/rfc1281.html"
|
|
>rfc1281</ulink
|
|
>
|
|
is a document that shows an example security policy with detailed
|
|
descriptions of each step.
|
|
</para>
|
|
|
|
<para>
|
|
Finally, you might want to look at the COAST policy archive at <ulink
|
|
url="ftp://coast.cs.purdue.edu/pub/doc/policy"
|
|
>ftp://coast.cs.purdue.edu/pub/doc/policy</ulink
|
|
> to see what some
|
|
real-life security policies look like.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Means of Securing Your Site</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Even if you have a single dial up PPP account, or just a small site,
|
|
this does not mean intruders won't be interested in your systems.
|
|
Large, high-profile sites are not the only targets -- many intruders
|
|
simply want to exploit as many sites as possible, regardless of their
|
|
size. Additionally, they may use a security hole in your site to gain
|
|
access to other sites you're connected to.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect3>
|
|
<title>Host Security</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Local Network Security </title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Security Through Obscurity</title>
|
|
|
|
<para>
|
|
One type of security that must be discussed is "security through
|
|
obscurity". This means, for example, moving a service that has known
|
|
security vulnerabilities to a non-standard port in hopes that attackers
|
|
won't notice it's there and thus won't exploit it. Rest assured that
|
|
they can determine that it's there and will exploit it. Security
|
|
through obscurity is no security at all. Simply because you may have a
|
|
small site, or a relatively low profile, does not mean an intruder
|
|
won't be interested in what you have. We'll discuss what you're
|
|
protecting in the next sections.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Organization of This Document</title>
|
|
|
|
<para>
|
|
This document has been divided into a number of sections. They cover
|
|
several broad security issues. The first,
|
|
<xref linkend="physical-security" />,
|
|
covers how you need to protect your physical machine from
|
|
tampering. The second,
|
|
<xref linkend="local-security" />, describes how to
|
|
protect your system from tampering by local users. The third,
|
|
<xref linkend="file-security" />,
|
|
shows you how to setup your file systems and permissions on your
|
|
files. The next, <xref linkend="password-security" />, discusses how to use encryption to better secure
|
|
your machine and network.
|
|
<xref linkend="kernel-security" /> discusses what kernel
|
|
options you should set or be aware of for a more secure system.
|
|
<xref linkend="network-security" />, describes how to
|
|
better secure your Linux system from network attacks.
|
|
<xref linkend="secure-prep" />, discusses how to
|
|
prepare your machine(s) before bringing them on-line. Next,
|
|
<xref linkend="after-breakin" />,
|
|
discusses what to do when you detect a system compromise in progress
|
|
or detect one that has recently happened. In <xref linkend="sources" />, some primary security resources are enumerated.
|
|
The Q and A section <xref linkend="q-and-a" />,
|
|
answers some frequently-asked questions, and finally a conclusion in
|
|
<xref linkend="conclusion" />
|
|
</para>
|
|
|
|
<para>
|
|
The two main points to realize when reading this document are:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
Be aware of your system. Check system logs such as
|
|
<literal remap="tt">/var/log/messages</literal> and keep an eye on your system, and
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="physical-security">
|
|
<title>Physical Security</title>
|
|
|
|
<para>
|
|
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?
|
|
</para>
|
|
|
|
<para>
|
|
How much physical security you need on your system is very dependent
|
|
on your situation, and/or budget.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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. :)
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Computer locks</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Some machines (most notably SPARC's and macs) have a dongle on the back
|
|
that, if you put a cable through, attackers would have to cut the cable
|
|
or break the case to get into it. Just putting a padlock or combo lock
|
|
through these can be a good deterrent to someone stealing your
|
|
machine.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>BIOS Security</title>
|
|
|
|
<para>
|
|
The BIOS is the lowest level of software that configures or
|
|
manipulates your x86-based hardware. LILO and other Linux boot methods
|
|
access the BIOS to determine how to boot up your Linux machine. Other
|
|
hardware that Linux runs on has similar software (Open Firmware on Macs
|
|
and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent
|
|
attackers from rebooting your machine and manipulating your Linux
|
|
system.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Another risk of trusting BIOS passwords to secure your system is the
|
|
default password problem. Most BIOS makers don't expect people to
|
|
open up their computer and disconnect batteries if they forget their
|
|
password and have equipped their BIOSes with default passwords that
|
|
work regardless of your chosen password. Some of the more common
|
|
passwords include:
|
|
</para>
|
|
|
|
<para>
|
|
j262
|
|
AWARD_SW
|
|
AWARD_PW
|
|
lkwpeter
|
|
Biostar
|
|
AMI
|
|
Award
|
|
bios
|
|
BIOS
|
|
setup
|
|
cmos
|
|
AMI!SW1
|
|
AMI?SW1
|
|
password
|
|
hewittrand
|
|
shift + s y x z
|
|
</para>
|
|
|
|
<para>
|
|
I tested an Award BIOS and AWARD_PW worked. These passwords are quite
|
|
easily available from manufacturers' websites and
|
|
<ulink
|
|
url="http://astalavista.box.sk"
|
|
>http://astalavista.box.sk</ulink
|
|
>
|
|
and as such a BIOS password cannot be considered adequate protection
|
|
from a knowledgeable attacker.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Note</emphasis>: 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. ;(
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Boot Loader Security</title>
|
|
|
|
<para>
|
|
The various Linux boot loaders also can have a boot password set.
|
|
LILO, for example, has <literal remap="tt">password</literal> and <literal remap="tt">restricted</literal>
|
|
settings; <literal remap="tt">password</literal> requires password at boot time,
|
|
whereas <literal remap="tt">restricted</literal> requires a boot-time password only if you
|
|
specify options (such as <literal remap="tt">single</literal>) at the <literal remap="tt">LILO </literal> prompt.
|
|
</para>
|
|
|
|
<para>
|
|
>From the lilo.conf man page:
|
|
|
|
<screen>
|
|
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).
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Also keep in mind that the /etc/lilo.conf will need to be mode "600"
|
|
(readable and writing for root only), or others will be able to read
|
|
your passwords!
|
|
</para>
|
|
|
|
<para>
|
|
>From the GRUB info page:
|
|
GRUB provides "password" feature, so that only administrators
|
|
can start the interactive operations (i.e. editing menu entries and
|
|
entering the command-line interface). To use this feature, you need to
|
|
run the command `password' in your configuration file (*note
|
|
password::), like this:
|
|
</para>
|
|
<para>
|
|
password --md5 PASSWORD
|
|
</para>
|
|
<para>
|
|
If this is specified, GRUB disallows any interactive control, until
|
|
you press the key <p> and enter a correct password. The option `--md5'
|
|
tells GRUB that `PASSWORD' is in MD5 format. If it is omitted, GRUB
|
|
assumes the `PASSWORD' is in clear text.
|
|
</para>
|
|
<para>
|
|
You can encrypt your password with the command `md5crypt' (*note
|
|
md5crypt::). For example, run the grub shell (*note Invoking the grub
|
|
shell::), and enter your password:
|
|
</para>
|
|
<para>
|
|
grub> md5crypt
|
|
Password: **********
|
|
Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.
|
|
</para>
|
|
<para>
|
|
Then, cut and paste the encrypted password to your configuration
|
|
file.
|
|
</para>
|
|
<para>
|
|
Grub also has a 'lock' command that will allow you to lock a partition
|
|
if you don't provide the correct password. Simply add 'lock' and the
|
|
partition will not be accessable until the user supplies a password.
|
|
</para>
|
|
|
|
<para>
|
|
If anyone has security-related information from a different boot
|
|
loader, we would love to hear it. (<literal remap="tt">grub</literal>, <literal remap="tt">silo</literal>, <literal remap="tt">milo</literal>, <literal remap="tt">linload</literal>, etc).
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Note</emphasis>: If you have a server machine, and you set up a boot password,
|
|
your machine will <emphasis>not</emphasis> boot up unattended. Keep in mind that you will
|
|
need to come in and supply the password in the event of a power
|
|
failure. ;(
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>xlock and vlock</title>
|
|
|
|
<para>
|
|
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: <literal remap="tt">xlock</literal> and <literal remap="tt">vlock</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">xlock</literal> 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 <literal remap="tt">xlock</literal> from any xterm on your
|
|
console and it will lock the display and require your password to
|
|
unlock.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">vlock</literal> 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. <literal remap="tt">vlock</literal> ships with RedHat
|
|
Linux, but your mileage may vary.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Security of local devices</title>
|
|
|
|
<para>
|
|
If you have a webcam or a microphone attached to your system, you
|
|
should consider if there is some danger of a attacker gaining access
|
|
to those devices. When not in use, unplugging or removing such devices
|
|
might be an option. Otherwise you should carefully read and look at
|
|
any software with provides access to such devices.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Detecting Physical Security Compromises</title>
|
|
|
|
<para>
|
|
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 <emphasis>you</emphasis> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Some things to check for in your logs:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
Short or incomplete logs.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Logs containing strange timestamps.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Logs with incorrect permissions or ownership.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Records of reboots or restarting of services.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
missing logs.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<literal remap="tt">su</literal> entries or logins from strange places.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
We will discuss system log data <xref linkend="logs" />
|
|
in the HOWTO.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="local-security">
|
|
<title>Local Security</title>
|
|
|
|
<para>
|
|
The next thing to take a look at is the security in your system
|
|
against attacks from local users. Did we just say <emphasis>local</emphasis> users? Yes!
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Creating New Accounts</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Several good rules of thumb when allowing other people legitimate
|
|
access to your Linux machine:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
Give them the minimal amount of privileges they need.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Be aware when/where they login from, or should be logging in from.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Make sure you remove inactive accounts, which you can determine by
|
|
using the 'last' command and/or checking log files for any activity by
|
|
the user.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The use of the same userid on all computers and networks is advisable
|
|
to ease account maintenance, and permits easier analysis of log
|
|
data.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The creation of group user-id's should be absolutely prohibited. User
|
|
accounts also provide accountability, and this is not possible with
|
|
group accounts.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="root-security">
|
|
<title>Root Security</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Several tricks to avoid messing up your own box as root:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
When doing some complex command, try running it first in a
|
|
non-destructive way...especially commands that use globing: e.g., if
|
|
you want to do <literal remap="tt">rm foo*.bak</literal>, first do <literal remap="tt">ls foo*.bak</literal> and make
|
|
sure you are going to delete the files you think you are. Using <literal remap="tt">echo</literal>
|
|
in place of destructive commands also sometimes works.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Provide your users with a default alias to the <literal remap="tt">rm</literal> command to ask for
|
|
confirmation for deletion of files.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
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 <emphasis>sure</emphasis> what needs to be done by root.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The command path for the root user is very important. The command
|
|
path (that is, the <literal remap="tt">PATH</literal> 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 <emphasis>never</emphasis>
|
|
include <literal remap="tt">.</literal> (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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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 <literal remap="tt">.rhosts</literal> file for root.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The <literal remap="tt">/etc/securetty</literal> 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 <literal remap="tt">su</literal> if you need to (hopefully over
|
|
<xref linkend="ssh" /> or other encrypted channel), so there is no
|
|
need to be able to login directly as root.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Always be slow and deliberate running as root. Your actions could
|
|
affect a lot of things. Think before you type!
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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. <literal remap="tt">sudo</literal> 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. <literal remap="tt">sudo</literal> 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 <literal remap="tt">sudo</literal>
|
|
works well even in places where a number of people have root access,
|
|
because it helps you keep track of changes made.
|
|
</para>
|
|
|
|
<para>
|
|
Although <literal remap="tt">sudo</literal> 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 <literal remap="tt">sudo</literal>. This includes
|
|
most editors, for example. Also, a program as innocuous as
|
|
<literal remap="tt">/bin/cat</literal> can be used to overwrite files, which could allow
|
|
root to be exploited. Consider <literal remap="tt">sudo</literal> as a means for
|
|
accountability, and don't expect it to replace the root user and still
|
|
be secure.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="file-security">
|
|
<title>Files and File system Security</title>
|
|
|
|
<para>
|
|
A few minutes of preparation and planning ahead before putting your
|
|
systems on-line can help to protect them and the data
|
|
stored on them.
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
There should never be a reason for users' home directories to allow
|
|
SUID/SGID programs to be run from there. Use the <literal remap="tt">nosuid</literal> option in
|
|
<literal remap="tt">/etc/fstab</literal> for partitions that are writable by others than root. You
|
|
may also wish to use <literal remap="tt">nodev</literal> and <literal remap="tt">noexec</literal> on users' home partitions,
|
|
as well as <literal remap="tt">/var</literal>, thus prohibiting execution of programs, and
|
|
creation of character or block devices, which should never be
|
|
necessary anyway.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
If you are exporting file-systems using NFS, be sure to configure
|
|
<literal remap="tt">/etc/exports</literal> with the most restrictive access possible. This means
|
|
not using wild cards, not allowing root write access, and exporting
|
|
read-only wherever possible.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Configure your users' file-creation <literal remap="tt">umask</literal> to be as restrictive as
|
|
possible. See <xref linkend="umask" />.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
If you are mounting file systems using a network file system such as
|
|
NFS, be sure to configure /etc/exports with suitable restrictions.
|
|
Typically, using `nodev', `nosuid', and perhaps `noexec', are
|
|
desirable.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Set file system limits instead of allowing <literal remap="tt">unlimited</literal> as is the
|
|
default. You can control the per-user limits using the
|
|
resource-limits PAM module and <literal remap="tt">/etc/pam.d/limits.conf</literal>. For example,
|
|
limits for group <literal remap="tt">users</literal> might look like this:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
@users hard core 0
|
|
@users hard nproc 50
|
|
@users hard rss 5000
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
This says to prohibit the creation of core files, restrict the
|
|
number of processes to 50, and restrict memory usage per user to
|
|
5M.
|
|
</para>
|
|
|
|
<para>
|
|
You can also use the /etc/login.defs configuration file to set the
|
|
same limits.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The <literal remap="tt">/var/log/wtmp</literal> and <literal remap="tt">/var/run/utmp</literal> 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 <literal remap="tt">644</literal> permissions, without affecting normal system
|
|
operation.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The immutable bit can be used to prevent accidentally deleting or
|
|
overwriting a file that must be protected. It also prevents someone
|
|
from creating a hard link to the file. See the <literal remap="tt">chattr</literal>(1)
|
|
man page for information on the immutable bit.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
|
|
SUID and SGID files on your system are a potential security risk, and
|
|
should be monitored closely. Because these programs grant special
|
|
privileges to the user who is executing them, it is necessary to
|
|
ensure that insecure programs are not installed. A favorite trick of
|
|
crackers is to exploit SUID-root programs, then leave a SUID
|
|
program as a back door to get in the next time, even if the original
|
|
hole is plugged.
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# find / -type f \( -perm -04000 -o -perm -02000 \)
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">/var/log/setuid*</literal> for this log.
|
|
</para>
|
|
|
|
<para>
|
|
You can remove the SUID or SGID permissions on a
|
|
suspicious program with <literal remap="tt">chmod</literal>, then restore them back if you
|
|
absolutely feel it is necessary.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
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:
|
|
</para>
|
|
<para>
|
|
|
|
<screen>
|
|
root# find / -perm -2 ! -type l -ls
|
|
</screen>
|
|
|
|
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 <literal remap="tt">/dev</literal>, and symbolic links, thus the <literal remap="tt">! -type l</literal>
|
|
which excludes these from the previous <literal remap="tt">find</literal> command.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# find / \( -nouser -o -nogroup \) -print
|
|
</screen>
|
|
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Finding <literal remap="tt">.rhosts</literal> 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
|
|
<literal remap="tt">.rhosts</literal> files on your system with the following command:
|
|
|
|
<screen>
|
|
root# find /home -name .rhosts -print
|
|
</screen>
|
|
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<sect2 id="umask">
|
|
<title>Umask Settings</title>
|
|
|
|
<para>
|
|
The <literal remap="tt">umask</literal> 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 <literal remap="tt">umask</literal>
|
|
settings include <literal remap="tt">022</literal>, <literal remap="tt">027</literal>, and <literal remap="tt">077</literal> (which is the most
|
|
restrictive). Normally the umask is set in <literal remap="tt">/etc/profile</literal>, so it applies
|
|
to all users on the system. The resulting permission is calculated as
|
|
follows: The default permission of user/group/others (7 for
|
|
directories, 6 for files) is combined with the inverted mask (NOT)
|
|
using AND on a per-bit-basis.
|
|
</para>
|
|
<para>
|
|
Example 1:
|
|
</para>
|
|
<para>
|
|
file, default 6, binary: 110
|
|
mask, eg. 2: 010, NOT: 101
|
|
</para>
|
|
<para>
|
|
resulting permission, AND: 100 (equals 4, r__)
|
|
</para>
|
|
<para>
|
|
Example 2:
|
|
</para>
|
|
<para>
|
|
file, default 6, binary: 110
|
|
mask, eg. 6: 110, NOT: 001
|
|
</para>
|
|
<para>
|
|
resulting permission, AND: 000 (equals 0, ___)
|
|
</para>
|
|
<para>
|
|
Example 3:
|
|
</para>
|
|
<para>
|
|
directory, default 7, binary: 111
|
|
mask, eg. 2: 010, NOT: 101
|
|
</para>
|
|
<para>
|
|
resulting permission, AND: 101 (equals 5, r_x)
|
|
</para>
|
|
<para>
|
|
Example 4:
|
|
</para>
|
|
<para>
|
|
directory, default 7, binary: 111
|
|
mask, eg. 6: 110, NOT: 001
|
|
</para>
|
|
<para>
|
|
resulting permission, AND: 001 (equals 1, __x)
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
# Set the user's default umask
|
|
umask 033
|
|
</screen>
|
|
|
|
Be sure to make root's umask <literal remap="tt">077</literal>, which will disable read, write, and
|
|
execute permission for other users, unless explicitly changed using
|
|
<literal remap="tt">chmod</literal>. 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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">002</literal>
|
|
for a <literal remap="tt">umask</literal>. This is due to the fact that the default configuration
|
|
is one user per group.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>File Permissions</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
A quick explanation of Unix permissions:
|
|
</para>
|
|
|
|
<para>
|
|
Ownership - Which user(s) and group(s) retain(s) control of the
|
|
permission settings of the node and parent of the node
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">Read:</emphasis>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to view contents of a file
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to read a directory
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">Write:</emphasis>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to add to or change a file
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to delete or move files in a directory
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">Execute:</emphasis>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to run a binary program or shell script
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
To be able to search in a directory, combined with read permission
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term>Save Text Attribute: (For directories)</term>
|
|
<listitem>
|
|
<para>
|
|
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 <literal remap="tt">/tmp</literal>, 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 <literal remap="tt">t</literal> in a long
|
|
directory listing.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term>SUID Attribute: (For Files)</term>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term>SGID Attribute: (For Files)</term>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term>SGID Attribute: (For directories)</term>
|
|
<listitem>
|
|
<para>
|
|
If you set the SGID bit on a directory (with <literal remap="tt">chmod g+s directory</literal>),
|
|
files created in that directory will have their group set to the
|
|
directory's group.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
You - The owner of the file
|
|
</para>
|
|
|
|
<para>
|
|
Group - The group you belong to
|
|
</para>
|
|
|
|
<para>
|
|
Everyone - Anyone on the system that is not the owner or a member
|
|
of the group
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis remap="bf">File Example:</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
-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)
|
|
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
|
|
-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)
|
|
|
|
</screen>
|
|
|
|
<emphasis remap="bf">Directory Example:</emphasis>
|
|
|
|
<screen>
|
|
|
|
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)
|
|
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
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
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
System configuration files (usually in <literal remap="tt">/etc</literal>) are usually mode <literal remap="tt">640</literal>
|
|
(<literal remap="tt">-rw-r-----</literal>), 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
|
|
<literal remap="tt">/etc/shadow</literal>, should only be readable by root, and directories in <literal remap="tt">/etc</literal>
|
|
should at least not be accessible by others.
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term>SUID Shell Scripts</term>
|
|
<listitem>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Integrity Checking</title>
|
|
|
|
<para>
|
|
Another very good way to detect local (and also network) attacks on
|
|
your system is to run an integrity checker like <literal remap="tt">Tripwire</literal>,
|
|
<literal remap="tt">Aide</literal> or <literal remap="tt">Osiris</literal>.
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
You can even add a <literal remap="tt">crontab</literal> entry to run the checker from your floppy
|
|
every night and mail you the results in the morning. Something like:
|
|
|
|
<screen>
|
|
# set mailto
|
|
MAILTO=kevin
|
|
# run Tripwire
|
|
15 05 * * * root /usr/local/adm/tcheck/tripwire
|
|
</screen>
|
|
|
|
will mail you a report each morning at 5:15am.
|
|
</para>
|
|
|
|
<para>
|
|
Integrity checkers can be a godsend to detecting intruders before you would
|
|
otherwise notice them. Since a lot of files change on the average
|
|
system, you have to be careful what is cracker activity and what is
|
|
your own doing.
|
|
</para>
|
|
|
|
<para>
|
|
You can find the freely available unsusported version of
|
|
<literal remap="tt">Tripwire</literal> at <ulink
|
|
url="http://www.tripwire.org"
|
|
>http://www.tripwire.org</ulink
|
|
>,
|
|
free of charge. Manuals and support can be purchased.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">Aide</literal> can be found at <ulink
|
|
url="http://www.cs.tut.fi/~rammer/aide.html"
|
|
>http://www.cs.tut.fi/~rammer/aide.html</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">Osiris</literal> can be found at <ulink
|
|
url="http://www.shmoo.com/osiris/"
|
|
>http://www.shmoo.com/osiris/</ulink
|
|
>.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Trojan Horses</title>
|
|
|
|
<para>
|
|
"Trojan Horses" are named after the fabled ploy in Virgil's "Aenid".
|
|
The idea is that a cracker distributes a program or binary that sounds
|
|
great, and encourages other people to download it and run it as root. Then
|
|
the program can compromise their system while they are not paying
|
|
attention. While they think the binary they just pulled down does one
|
|
thing (and it might very well), it also compromises their security.
|
|
</para>
|
|
|
|
<para>
|
|
You should take care of what programs you install on your
|
|
machine. RedHat provides MD5 checksums and PGP signatures on its RPM
|
|
files so you can verify you are installing the real thing. Other
|
|
distributions have similar methods. You should never run any unfamiliar
|
|
binary, for which you don't have the source, as root. Few attackers are
|
|
willing to release source code to public scrutiny.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="password-security">
|
|
<title>Password Security and Encryption </title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">passwd</literal> programs that do not allow you to set a
|
|
easily guessable password. Make sure your <literal remap="tt">passwd</literal> program is up to date
|
|
and has these features.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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)
|
|
<literal remap="tt">/etc/passwd</literal> (or less commonly) <literal remap="tt">/etc/shadow</literal>. When you attempt to login,
|
|
the password you type in is encrypted again and compared with the entry in
|
|
the file that stores your passwords. If they match, it must be the
|
|
same password, and you are allowed access. Although DES is a two-way
|
|
encryption algorithm (you can code and then decode a message, given
|
|
the right keys), the variant that most Unixes use is one-way. This
|
|
means that it should not be possible to reverse the encryption to get
|
|
the password from the contents of <literal remap="tt">/etc/passwd</literal> (or <literal remap="tt">/etc/shadow</literal>).
|
|
</para>
|
|
|
|
<para>
|
|
Brute force attacks, such as "Crack" or "John the Ripper" (see section <xref linkend="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.
|
|
</para>
|
|
|
|
<para>
|
|
You can go to <ulink
|
|
url="http://consult.cern.ch/writeup/security/security_3.html"
|
|
>http://consult.cern.ch/writeup/security/security_3.html</ulink
|
|
> for
|
|
information on how to choose a good password.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>PGP and Public-Key Cryptography</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There are advantages to both public key and private key cryptography,
|
|
and you can read about those differences in <ulink
|
|
url="http://www.rsa.com/rsalabs/faq/"
|
|
>the RSA Cryptography FAQ</ulink
|
|
>,
|
|
listed at the end of this section.
|
|
</para>
|
|
|
|
<para>
|
|
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: <ulink
|
|
url="http://www.pgp.com/service/export/faq/55faq.cgi"
|
|
>http://www.pgp.com/service/export/faq/55faq.cgi</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
US export controls are now managed by EAR (Export Administration
|
|
Regulations). They are no longer governed by ITAR.
|
|
</para>
|
|
|
|
<para>
|
|
There is also a step-by-step guide for configuring PGP on Linux
|
|
available at <ulink
|
|
url="http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html"
|
|
>http://mercury.chem.pitt.edu/~angel/LinuxFocus/English/November1997/article7.html</ulink
|
|
>.
|
|
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 <ulink
|
|
url="ftp://metalab.unc.edu/pub/Linux/apps/crypto"
|
|
>ftp://metalab.unc.edu/pub/Linux/apps/crypto</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
There is a project maintaining a free re-implementation of pgp with
|
|
open source. GnuPG is a complete and free replacement for PGP. Because
|
|
it does not use IDEA or RSA it can be used without any
|
|
restrictions. GnuPG is in compliance with <ulink
|
|
url="http://www.faqs.org/rfcs/rfc2440.html"
|
|
>OpenPGP</ulink
|
|
>.
|
|
See the GNU Privacy Guard web page for more information:
|
|
<ulink
|
|
url="http://www.gnupg.org"
|
|
>http://www.gnupg.org/</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
More information on cryptography can be found in the RSA cryptography
|
|
FAQ, available at <ulink
|
|
url="http://www.rsa.com/rsalabs/newfaq/"
|
|
>http://www.rsa.com/rsalabs/newfaq/</ulink
|
|
>. Here you will find
|
|
information on such terms as "Diffie-Hellman", "public-key
|
|
cryptography", "digital certificates", etc.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>SSL, S-HTTP and S/MIME</title>
|
|
|
|
<para>
|
|
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.
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">SSL:</emphasis> - 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 <ulink
|
|
url="http://www.consensus.com/security/ssl-talk-faq.html"
|
|
>http://www.consensus.com/security/ssl-talk-faq.html</ulink
|
|
>.
|
|
Information on Netscape's other security implementations, and a good
|
|
starting point for these protocols is available at <ulink
|
|
url="http://home.netscape.com/info/security-doc.html"
|
|
>http://home.netscape.com/info/security-doc.html</ulink
|
|
>. It's also
|
|
worth noting that the SSL protocol can be used to pass many other
|
|
common protocols, "wrapping" them for security. See
|
|
<ulink
|
|
url="http://www.quiltaholic.com/rickk/sslwrap/"
|
|
>http://www.quiltaholic.com/rickk/sslwrap/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">S-HTTP:</emphasis> - S-HTTP is another protocol that provides
|
|
security services across the Internet. It was designed to provide
|
|
confidentiality, authentication, integrity, and non-repudiability [cannot be mistaken for someone else] while supporting multiple
|
|
key-management mechanisms and cryptographic algorithms via option
|
|
negotiation between the parties involved in each transaction. S-HTTP
|
|
is limited to the specific software that is implementing it, and
|
|
encrypts each message individually. [ From RSA Cryptography FAQ,
|
|
page 138]
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis remap="bf">S/MIME:</emphasis> - 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 <ulink
|
|
url="http://home.netscape.com/assist/security/smime/overview.html"
|
|
>http://home.netscape.com/assist/security/smime/overview.html</ulink
|
|
>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Linux IPSEC Implementations</title>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.ietf.org/html.charters/ipsec-charter.html"
|
|
>http://www.ietf.org/html.charters/ipsec-charter.html</ulink
|
|
>. You can
|
|
also find links to other protocols involving key management, and an
|
|
IPSEC mailing list and archives.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html"
|
|
>http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html</ulink
|
|
>. Most
|
|
simply, the x-kernel is a method of passing messages at the kernel
|
|
level, which makes for an easier implementation.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
It's available for download from <ulink
|
|
url="http://www.xs4all.nl/~freeswan/"
|
|
>http://www.xs4all.nl/~freeswan/</ulink
|
|
>, and has just reached 1.0 at the
|
|
time of this writing.
|
|
</para>
|
|
|
|
<para>
|
|
As with other forms of cryptography, it is not distributed with the
|
|
kernel by default due to export restrictions.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="ssh">
|
|
<title><literal remap="tt">ssh</literal> (Secure Shell) and <literal remap="tt">stelnet</literal></title>
|
|
|
|
<para>
|
|
<literal remap="tt">ssh</literal> and <literal remap="tt">stelnet</literal> are suites of programs that
|
|
allow you to login to remote systems and have a encrypted connection.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">openssh</literal> is a suite of programs used as a secure replacement
|
|
for <literal remap="tt">rlogin</literal>, <literal remap="tt">rsh</literal> and <literal remap="tt">rcp</literal>. 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.
|
|
</para>
|
|
|
|
<para>
|
|
There are several ssh implementiations now. The original commercial
|
|
implementation by Data Fellows can be found at
|
|
The <literal remap="tt">ssh</literal> home page can be found at <ulink
|
|
url="http://www.datafellows.com"
|
|
>http://www.datafellows.com</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
The excellent Openssh implementation is based on a early version of
|
|
the datafellows ssh and has been totally reworked to not include any
|
|
patented or proprietary pieces. It is free and under a BSD
|
|
license. It can be found at: <ulink
|
|
url="http://www.openssh.com"
|
|
>http://www.openssh.com</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
There is also a open source
|
|
project to re-implement ssh from the ground up called "psst...". For
|
|
more information see: <ulink
|
|
url="http://www.net.lut.ac.uk/psst/"
|
|
>http://www.net.lut.ac.uk/psst/</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
You can also use <literal remap="tt">ssh</literal> from your Windows workstation to your
|
|
Linux <literal remap="tt">ssh</literal>
|
|
server. There are several freely available Windows client
|
|
implementations, including the one at <ulink
|
|
url="http://guardian.htu.tuwien.ac.at/therapy/ssh/"
|
|
>http://guardian.htu.tuwien.ac.at/therapy/ssh/</ulink
|
|
> as well as a
|
|
commercial implementation from DataFellows, at <ulink
|
|
url="http://www.datafellows.com"
|
|
>http://www.datafellows.com</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.psy.uq.oz.au/~ftp/Crypto/"
|
|
>http://www.psy.uq.oz.au/~ftp/Crypto/</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
SRP is another secure telnet/ftp implementation. From their web page:
|
|
</para>
|
|
|
|
<para>
|
|
<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
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
For more information, go to <ulink
|
|
url="http://www-cs-students.stanford.edu/~tjw/srp/"
|
|
>http://www-cs-students.stanford.edu/~tjw/srp/</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>PAM - Pluggable Authentication Modules</title>
|
|
|
|
<para>
|
|
Newer versions of the Red Hat Linux and Debian Linux distributions ship with a unified
|
|
authentication scheme called "PAM". PAM allows you to change
|
|
your authentication methods and requirements on the
|
|
fly, and encapsulate all
|
|
local authentication methods without recompiling any of your
|
|
binaries. Configuration of PAM is beyond the scope of this document,
|
|
but be sure to take a look at the PAM web site for more
|
|
information. <ulink
|
|
url="http://www.kernel.org/pub/linux/libs/pam/index.html"
|
|
>http://www.kernel.org/pub/linux/libs/pam/index.html</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
Just a few of the things you can do with PAM:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
Use encryption other than DES for your passwords. (Making them harder to
|
|
brute-force decode)
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Set resource limits on all your users so they can't perform
|
|
denial-of-service attacks (number of processes, amount of memory, etc)
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Enable shadow passwords (see below) on the fly
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
allow specific users to login only at specific times from specific
|
|
places
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">.rhosts</literal> files in user's home
|
|
directories by adding these lines to <literal remap="tt">/etc/pam.d/rlogin</literal>:
|
|
|
|
<screen>
|
|
#
|
|
# Disable rsh/rlogin/rexec for users
|
|
#
|
|
login auth required pam_rhosts_auth.so no_rhosts
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Cryptographic IP Encapsulation (CIPE)</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Summarized from the CIPE documentation:
|
|
</para>
|
|
|
|
<para>
|
|
<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
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Further information can be found at
|
|
<ulink
|
|
url="http://www.inka.de/~bigred/devel/cipe.html"
|
|
>http://www.inka.de/~bigred/devel/cipe.html</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
As with other forms of cryptography, it is not distributed with the
|
|
kernel by default due to export restrictions.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Kerberos</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
This authentication is then used by programs such as <literal remap="tt">rlogin</literal> to allow
|
|
the user to login to other hosts without a password (in place of the
|
|
<literal remap="tt">.rhosts</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
You can find more information about kerberos by looking at <ulink
|
|
url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/kerberos-faq/general/faq.html"
|
|
>the kerberos FAQ</ulink
|
|
>, and the code can be found at <ulink
|
|
url="http://nii.isi.edu/info/kerberos/"
|
|
>http://nii.isi.edu/info/kerberos/</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
[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.]
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Shadow Passwords.</title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">/etc/passwd</literal> 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 <literal remap="tt">/etc/shadow</literal>, 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 <ulink
|
|
url="http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html"
|
|
>http://metalab.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html</ulink
|
|
>
|
|
It is rather dated now, and will not be required for distributions
|
|
supporting PAM.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="crack">
|
|
<title>"Crack" and "John the Ripper"</title>
|
|
|
|
<para>
|
|
If for some reason your <literal remap="tt">passwd</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There are a number of programs out there...the two most notable of
|
|
which are "Crack" and "John the Ripper"
|
|
(<ulink
|
|
url="http://www.openwall.com/john/"
|
|
>http://www.openwall.com/john/</ulink
|
|
>) . 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
|
|
<literal remap="tt">/etc/passwd</literal> file, but such holes are more common than you might think.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.l0pht.com"
|
|
>http://www.l0pht.com</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>CFS - Cryptographic File System and TCFS - Transparent Cryptographic File System</title>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.zedz.net/redhat/"
|
|
>http://www.zedz.net/redhat/</ulink
|
|
>, and more information on how it
|
|
all works is at <ulink
|
|
url="ftp://ftp.research.att.com/dist/mab/"
|
|
>ftp://ftp.research.att.com/dist/mab/</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
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: <ulink
|
|
url="http://www.tcfs.it/"
|
|
>http://www.tcfs.it/</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
It also need not be used on entire file systems. It works on
|
|
directory trees as well.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>X11, SVGA and display security</title>
|
|
|
|
<sect3>
|
|
<title>X11</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
X has a number of access-control mechanisms. The simplest of them is
|
|
host-based: you use <literal remap="tt">xhost</literal> 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 <literal remap="tt">xhost + their machine</literal> and get in
|
|
easily. Also, if you have to allow access from an untrusted machine,
|
|
anyone there can compromise your display.
|
|
</para>
|
|
|
|
<para>
|
|
When using <literal remap="tt">xdm</literal> (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 <literal remap="tt">.Xauthority</literal> file. If you need to allow a remote machine
|
|
access to your display, you can use the <literal remap="tt">xauth</literal> command and the
|
|
information in your <literal remap="tt">.Xauthority</literal> file to provide access to only that connection.
|
|
See the Remote-X-Apps mini-howto, available at <ulink
|
|
url="http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html"
|
|
>http://metalab.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
You can also use <literal remap="tt">ssh</literal> (see <xref linkend="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.
|
|
</para>
|
|
|
|
<para>
|
|
You can also disable any remote connections to your X server by using
|
|
the '-nolisten tcp' options to your X server. This will prevent any
|
|
network connections to your server over tcp sockets.
|
|
</para>
|
|
|
|
<para>
|
|
Take a look at the <literal remap="tt">Xsecurity</literal> man page for more information on X
|
|
security. The safe bet is to use <literal remap="tt">xdm</literal> to login to your console and then
|
|
use <literal remap="tt">ssh</literal> to go to remote sites on which you wish to run X programs.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>SVGA </title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>GGI (Generic Graphics Interface project)</title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">login</literal> program
|
|
running on your console. <ulink
|
|
url="http://synergy.caltech.edu/~ggi/"
|
|
>http://synergy.caltech.edu/~ggi/</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="kernel-security">
|
|
<title>Kernel Security</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="ftp://ftp.kernel.org"
|
|
>�</ulink
|
|
> or from your distribution
|
|
vendor.
|
|
</para>
|
|
|
|
<para>
|
|
There is also a international group providing a single unified crypto
|
|
patch to the mainstream Linux kernel. This patch provides support for
|
|
a number of cryptographic subsystems and things that cannot be
|
|
included in the mainstream kernel due to export restrictions. For more
|
|
information, visit their web page at: <ulink
|
|
url="http://www.kerneli.org"
|
|
>http://www.kerneli.org</ulink
|
|
>
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>2.0 Kernel Compile Options</title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">./linux/Documentation/Configure.help</literal>, which is
|
|
the same document that is referenced while using the Help facility during
|
|
the <literal remap="tt">make config</literal> stage of compiling the kernel.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Network Firewalls
|
|
(CONFIG_FIREWALL)
|
|
</para>
|
|
<para>
|
|
This option should be on if you intend to run any firewalling or
|
|
masquerading on your Linux machine. If it's just going to be a regular
|
|
client machine, it's safe to say no.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: forwarding/gatewaying
|
|
(CONFIG_IP_FORWARD)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
You can enable IP forwarding dynamically using the following command:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# echo 1 > /proc/sys/net/ipv4/ip_forward
|
|
</screen>
|
|
|
|
and disable it with the command:
|
|
|
|
<screen>
|
|
root# echo 0 > /proc/sys/net/ipv4/ip_forward
|
|
</screen>
|
|
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: syn cookies
|
|
(CONFIG_SYN_COOKIES)
|
|
</para>
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>
|
|
</screen>
|
|
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: Firewalling
|
|
(CONFIG_IP_FIREWALL)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: firewall packet logging
|
|
(CONFIG_IP_FIREWALL_VERBOSE)
|
|
</para>
|
|
<para>
|
|
This option gives you information about packets your firewall
|
|
received, like sender, recipient, port, etc.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: Drop source routed frames
|
|
(CONFIG_IP_NOSR)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: masquerading
|
|
(CONFIG_IP_MASQUERADE)
|
|
If one of the computers on your local network for which your Linux
|
|
box acts as a firewall wants to send something to the outside, your
|
|
box can "masquerade" as that host, i.e., it forewords the traffic
|
|
to the intended destination, but makes it look like it came from the
|
|
firewall box itself. See <ulink
|
|
url="http://www.indyramp.com/masq"
|
|
>http://www.indyramp.com/masq</ulink
|
|
> for more information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: ICMP masquerading
|
|
(CONFIG_IP_MASQUERADE_ICMP)
|
|
This option adds ICMP masquerading to the previous option of only
|
|
masquerading TCP or UDP traffic.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.indyramp.com/masq"
|
|
>http://www.indyramp.com/masq</ulink
|
|
> for more information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: always defragment
|
|
(CONFIG_IP_ALWAYS_DEFRAG)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Packet Signatures
|
|
(CONFIG_NCPFS_PACKET_SIGNING)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: Firewall packet netlink device
|
|
(CONFIG_IP_FIREWALL_NETLINK)
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>2.2 Kernel Compile Options</title>
|
|
|
|
<para>
|
|
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
|
|
<literal remap="tt">./linux/Documentation/Configure.help</literal>, which is the same
|
|
document that is referenced while using the Help facility during
|
|
the <literal remap="tt">make config</literal> 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 <literal remap="tt">ipchains</literal>
|
|
program is now used to install IP firewalling, instead of the
|
|
<literal remap="tt">ipfwadm</literal> program used in the 2.0 kernel.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Socket Filtering
|
|
(CONFIG_FILTER)
|
|
</para>
|
|
<para>
|
|
For most people, it's safe to say no to this option. This option
|
|
allows you to connect a user-space filter to any socket and determine
|
|
if packets should be allowed or denied. Unless you have a very
|
|
specific need and are capable of programming such a filter, you should
|
|
say no. Also note that as of this writing, all protocols were
|
|
supported except TCP.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Port Forwarding
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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/
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Socket Filtering
|
|
(CONFIG_FILTER)
|
|
</para>
|
|
<para>
|
|
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 <literal remap="tt">./linux/Documentation/networking/filter.txt</literal> for
|
|
more information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
IP: Masquerading
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Kernel Devices</title>
|
|
|
|
<para>
|
|
There are a few block and character devices available on Linux that
|
|
will also help you with security.
|
|
</para>
|
|
|
|
<para>
|
|
The two devices <literal remap="tt">/dev/random</literal> and <literal remap="tt">/dev/urandom</literal> are provided by the
|
|
kernel to provide random data at any time.
|
|
</para>
|
|
|
|
<para>
|
|
Both <literal remap="tt">/dev/random</literal> and <literal remap="tt">/dev/urandom</literal> should be secure enough to use in
|
|
generating PGP keys, <literal remap="tt">ssh</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
The only difference between the two devices, is that <literal remap="tt">/dev/random</literal> 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 <literal remap="tt">/dev/random</literal>. (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".)
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">/dev/random</literal> is high quality entropy, generated from measuring the
|
|
inter-interrupt times etc. It blocks until enough bits of random data
|
|
are available.
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">/dev/urandom</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
You might read from the devices using something like:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# head -c 6 /dev/urandom | mimencode
|
|
</screen>
|
|
|
|
This will print six random characters on the console, suitable for
|
|
password generation. You can find <literal remap="tt">mimencode</literal> in the <literal remap="tt">metamail</literal>
|
|
package.
|
|
</para>
|
|
|
|
<para>
|
|
See <literal remap="tt">/usr/src/linux/drivers/char/random.c</literal> for a description of the
|
|
algorithm.
|
|
</para>
|
|
|
|
<para>
|
|
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel
|
|
for helping me (Dave) with this.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="network-security">
|
|
<title>Network Security</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There are a number of good tools to assist with network security, and
|
|
more and more of them are shipping with Linux distributions.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Packet Sniffers</title>
|
|
|
|
<para>
|
|
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
|
|
<literal remap="tt">passwd</literal> and <literal remap="tt">login</literal> and <literal remap="tt">su</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
Example: Host A has been compromised. Attacker installs a
|
|
sniffer. Sniffer picks up admin logging into Host B from Host C. It
|
|
gets the admins personal password as they login to B. Then, the admin
|
|
does a <literal remap="tt">su</literal> to fix a problem. They now have the root password for Host
|
|
B. Later the admin lets someone <literal remap="tt">telnet</literal> from his account to Host Z on
|
|
another site. Now the attacker has a password/login on Host Z.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Using <literal remap="tt">ssh</literal> 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.)
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>System services and tcp_wrappers</title>
|
|
|
|
<para>
|
|
Before you put your Linux system on <emphasis>ANY</emphasis> 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.
|
|
</para>
|
|
|
|
<para>
|
|
There are a number of ways to disable services under Linux. You can
|
|
look at your <literal remap="tt">/etc/inetd.conf</literal> file and see what services are being
|
|
offered by your <literal remap="tt">inetd</literal>. Disable any that you do not need by commenting
|
|
them out (<literal remap="tt">#</literal> at the beginning of the line), and then sending
|
|
your inetd process a SIGHUP.
|
|
</para>
|
|
|
|
<para>
|
|
You can also remove (or comment out) services in your <literal remap="tt">/etc/services</literal>
|
|
file. This will mean that local clients will also be unable to find
|
|
the service (i.e., if you remove <literal remap="tt">ftp</literal>, 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 <literal remap="tt">/etc/services</literal>, since it provides no
|
|
additional security. If a local person wanted to use <literal remap="tt">ftp</literal> even though
|
|
you had commented it out, they would make their own client that used
|
|
the common FTP port and would still work fine.
|
|
</para>
|
|
|
|
<para>
|
|
Some of the services you might want to leave enabled are:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
<literal remap="tt">ftp</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<literal remap="tt">telnet</literal> (or <literal remap="tt">ssh</literal>)
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
mail, such as <literal remap="tt">pop-3</literal> or <literal remap="tt">imap</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<literal remap="tt">identd</literal>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
If you know you are not going to use some particular package, you can
|
|
also delete it entirely. <literal remap="tt">rpm -e packagename</literal> under
|
|
the Red Hat distribution will erase an entire package. Under Debian
|
|
<literal remap="tt">dpkg --remove</literal> does the same thing.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, you really want to disable the rsh/rlogin/rcp utilities,
|
|
including login (used by <literal remap="tt">rlogin</literal>), shell (used by <literal remap="tt">rcp</literal>),
|
|
and exec (used
|
|
by <literal remap="tt">rsh</literal>) from being started in <literal remap="tt">/etc/inetd.conf</literal>.
|
|
These protocols are extremely insecure and have been the cause of exploits
|
|
in the past.
|
|
</para>
|
|
|
|
<para>
|
|
You should check <literal remap="tt">/etc/rc.d/rc[0-9].d</literal> (on Red Hat;
|
|
<literal remap="tt">/etc/rc[0-9].d</literal> 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
|
|
<literal remap="tt">/etc/rc.d/init.d</literal> (on Red Hat; <literal remap="tt">/etc/init.d</literal> on Debian).
|
|
Renaming the files in the <literal remap="tt">init.d</literal> 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 <literal remap="tt">S</literal> with a lower-case
|
|
<literal remap="tt">s</literal>, like this:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# cd /etc/rc6.d
|
|
root# mv S45dhcpd s45dhcpd
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
If you have BSD-style <literal remap="tt">rc</literal> files, you will want to check
|
|
<literal remap="tt">/etc/rc*</literal> for programs you don't need.
|
|
</para>
|
|
|
|
<para>
|
|
Most Linux distributions ship with tcp_wrappers "wrapping" all your
|
|
TCP services. A tcp_wrapper (<literal remap="tt">tcpd</literal>) is invoked from <literal remap="tt">inetd</literal> instead of
|
|
the real server. <literal remap="tt">tcpd</literal> then checks the host that is requesting the
|
|
service, and either executes the real server, or denies access from that
|
|
host. <literal remap="tt">tcpd</literal> allows you to restrict access to your TCP services. You
|
|
should make a <literal remap="tt">/etc/hosts.allow</literal> and add in only those hosts that need
|
|
to have access to your machine's services.
|
|
</para>
|
|
|
|
<para>
|
|
If you are a home dial up user, we suggest you deny ALL. <literal remap="tt">tcpd</literal> 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 <literal remap="tt">/etc/hosts.allow</literal>:
|
|
</para>
|
|
|
|
<para>
|
|
ALL: 127.
|
|
</para>
|
|
|
|
<para>
|
|
And of course /etc/hosts.deny would contain:
|
|
</para>
|
|
|
|
<para>
|
|
ALL: ALL
|
|
</para>
|
|
|
|
<para>
|
|
which will prevent external connections to your machine, yet still
|
|
allow you from the inside to connect to servers on the Internet.
|
|
</para>
|
|
|
|
<para>
|
|
Keep in mind that tcp_wrappers only protects services executed from
|
|
<literal remap="tt">inetd</literal>, and a select few others. There very well may be other
|
|
services running on your machine. You can use <literal remap="tt">netstat -ta</literal> to
|
|
find a list of all the services your machine is offering.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Verify Your DNS Information</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>identd</title>
|
|
|
|
<para>
|
|
<literal remap="tt">identd</literal> is a small program that typically runs out of your
|
|
<literal remap="tt">inetd</literal> server. It keeps track of what user is running what TCP
|
|
service, and then reports this to whoever requests it.
|
|
</para>
|
|
|
|
<para>
|
|
Many people misunderstand the usefulness of <literal remap="tt">identd</literal>, and so disable it
|
|
or block all off site requests for it. <literal remap="tt">identd</literal> is not there to help out
|
|
remote sites. There is no way of knowing if the data you get from the
|
|
remote <literal remap="tt">identd</literal> is correct or not. There is no authentication in <literal remap="tt">identd</literal>
|
|
requests.
|
|
</para>
|
|
|
|
<para>
|
|
Why would you want to run it then? Because it helps <emphasis>you</emphasis> out, and is
|
|
another data-point in tracking. If your <literal remap="tt">identd</literal> 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 <literal remap="tt">identd</literal>,
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal remap="tt">identd</literal> that ships with most distributions is more configurable
|
|
than many people think. You can disable it for specific users
|
|
(they can make a <literal remap="tt">.noident</literal> file), you can log all
|
|
<literal remap="tt">identd</literal> requests (We recommend it), you can even have identd
|
|
return a uid instead of a user name or even NO-USER.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Configuring and Securing the Postfix MTA</title>
|
|
|
|
<para>
|
|
The Postfix mail server was written by Wietse Venema, author of
|
|
Postfix and several other staple Internet security products, as an "attempt to
|
|
provide an alternative to the widely-used Sendmail program. Postfix attempts
|
|
to be fast, easy to administer, and hopefully secure, while at the same time
|
|
being sendmail compatible enough to not upset your users."
|
|
</para>
|
|
|
|
<para>
|
|
Further information on postfix can be found at the
|
|
<ulink
|
|
url="http://www.postfix.org"
|
|
>Postfix home</ulink
|
|
> and in the
|
|
<ulink
|
|
url="http://www.linuxsecurity.com/feature_stories/feature_story-91.html"
|
|
>Configuring and Securing Postfix</ulink
|
|
>.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>SATAN, ISS, and Other Network Scanners</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://metalab.unc.edu/pub/packages/security/Satan-for-Linux/"
|
|
>metalab</ulink
|
|
> or a reputable FTP or web site. There was a Trojan
|
|
copy of SATAN that was distributed out on the net. <ulink
|
|
url="http://www.trouble.org/~zen/satan/satan.html"
|
|
>http://www.trouble.org/~zen/satan/satan.html</ulink
|
|
>. Note that SATAN
|
|
has not been updated in quite a while, and some of the other tools
|
|
below might do a better job.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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. <ulink
|
|
url="http://www.psionic.com/abacus"
|
|
>http://www.psionic.com/abacus/</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
<ulink
|
|
url="http://www.wwdsi.com/saint"
|
|
>http://www.wwdsi.com/~saint</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Nessus is a free security scanner. It has a GTK graphical interface
|
|
for ease of use. It is also designed with a very nice plug in setup for
|
|
new port-scanning tests. For more information, take a look at: <ulink
|
|
url="http://www.nessus.org/"
|
|
>http://www.nessus.org</ulink
|
|
>
|
|
</para>
|
|
|
|
<sect3>
|
|
<title>Detecting Port Scans</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<emphasis>_had no established session_</emphasis> can be taken as proof of life on
|
|
that port. I don't think TCP wrappers will detect this.
|
|
</para>
|
|
|
|
<para>
|
|
You might also look at SNORT, which is a free IDS (Intrusion Detection
|
|
System), which can detect other network intrusions. <ulink
|
|
url="http://www.snort.org"
|
|
>http://www.snort.org</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>sendmail, qmail and MTA's</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
If you are using <literal remap="tt">sendmail</literal> it is very important to keep up on current
|
|
versions. <literal remap="tt">sendmail</literal> has a long long history of security
|
|
exploits. Always make sure you are running the most recent version from
|
|
<ulink
|
|
url="http://www.sendmail.org/"
|
|
>http://www.sendmail.org</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
|
|
<screen>
|
|
# /usr/lib/sendmail -q15m
|
|
</screen>
|
|
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Many administrators choose not to use sendmail, and instead choose one
|
|
of the other mail transport agents. You might consider switching over
|
|
to <literal remap="tt">qmail</literal>. <literal remap="tt">qmail</literal> was designed with security in mind
|
|
from the ground up. It's fast, stable, and secure. Qmail can be found at
|
|
<ulink
|
|
url="http://www.qmail.org"
|
|
>http://www.qmail.org</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http:/www.postfix.org"
|
|
>http://www.postfix.org</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Denial of Service Attacks</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">SYN Flooding</emphasis> - 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 <xref linkend="kernel-security" /> for proper kernel
|
|
protection options.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">Pentium "F00F" Bug</emphasis> - 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!
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">Ping Flooding</emphasis> - 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 <emphasis>your</emphasis> machine's return IP, allowing them to
|
|
flood you less detectably. You can find more information about the
|
|
"smurf" attack at <ulink
|
|
url="http://www.quadrunner.com/~chuegen/smurf.txt"
|
|
> http://www.quadrunner.com/~chuegen/smurf.txt</ulink
|
|
>
|
|
</para>
|
|
<para>
|
|
If you are ever under a ping flood attack, use a tool like <literal remap="tt">tcpdump</literal> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">Ping o' Death</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">Teardrop / New Tear</emphasis> - 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.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
You can find code for most exploits, and a more in-depth description of how
|
|
they work, at <ulink
|
|
url="http://www.rootshell.com"
|
|
>http://www.rootshell.com</ulink
|
|
> using their search engine.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>NFS (Network File System) Security. </title>
|
|
|
|
<para>
|
|
NFS is a very widely-used file sharing protocol. It allows servers
|
|
running <literal remap="tt">nfsd</literal> and <literal remap="tt">mountd</literal> to "export" entire file systems
|
|
to other machines using NFS filesystem support built in to their kernels
|
|
(or some other client support if they are not Linux machines).
|
|
<literal remap="tt">mountd</literal> keeps track of mounted file systems in <literal remap="tt">/etc/mtab</literal>,
|
|
and can display them with <literal remap="tt">showmount</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There is some small amount of security allowed in exporting
|
|
file systems. You can make your <literal remap="tt">nfsd</literal> map the remote root user (uid=0)
|
|
to the <literal remap="tt">nobody</literal> 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 <literal remap="tt">su</literal> to
|
|
their account and have total access to their files. This is only a
|
|
small hindrance to an attacker that has access to mount your remote
|
|
file systems.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
See the NFS HOWTO for more information on NFS, available at <ulink
|
|
url="http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html"
|
|
>http://metalab.unc.edu/mdw/HOWTO/NFS-HOWTO.html</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>NIS (Network Information Service) (formerly YP). </title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">/etc/passwd</literal> file). This allows users to
|
|
change their password once and have it take effect on all the machines
|
|
in the NIS domain.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
There is a much more secure replacement for NIS, called NIS+.
|
|
Check out the NIS HOWTO for more information: <ulink
|
|
url="http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html"
|
|
>http://metalab.unc.edu/mdw/HOWTO/NIS-HOWTO.html</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Firewalls</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">ipfwadm</literal> for 2.0
|
|
kernels and <literal remap="tt">ipchains</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">Firewall-HOWTO</literal> at your latest metalab archive for
|
|
more information on firewalls and Linux. <ulink
|
|
url="http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html"
|
|
>http://metalab.unc.edu/mdw/HOWTO/Firewall-HOWTO.html</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
More information can also be found in the IP-Masquerade
|
|
mini-howto: <ulink
|
|
url="http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html"
|
|
>http://metalab.unc.edu/mdw/HOWTO/mini/IP-Masquerade.html</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
More information on <literal remap="tt">ipfwadm</literal> (the tool that lets you change settings on
|
|
your firewall, can be found at it's home page: <ulink
|
|
url="http://www.xos.nl/linux/ipfwadm/"
|
|
>http://www.xos.nl/linux/ipfwadm/</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.ora.com"
|
|
>http://www.ora.com</ulink
|
|
>
|
|
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
|
|
<ulink
|
|
url="http://csrc.nist.gov/nistpubs/800-10/main.html"
|
|
>http://csrc.nist.gov/nistpubs/800-10/main.html</ulink
|
|
>. Also of interest:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
The Freefire Project -- a list of freely-available firewall tools,
|
|
available at <ulink
|
|
url="http://sites.inka.de/sites/lina/freefire-l/index_en.html"
|
|
>http://sites.inka.de/sites/lina/freefire-l/index_en.html</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.sunworld.com/swol-01-1996/swol-01-firewall.html"
|
|
>http://www.sunworld.com/swol-01-1996/swol-01-firewall.html</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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: <ulink
|
|
url="http://www.pobox.com/~wstearns/mason/"
|
|
>http://www.pobox.com/~wstearns/mason/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>IP Chains - Linux Kernel 2.2.x Firewalling</title>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
More flexible packet manipulations
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
More complex accounting
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Simple policy changes possible atomically
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fragments can be explicitly blocked, denied, etc.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Logs suspicious packets.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Can handle protocols other than ICMP/TCP/UDP.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
If you are currently using <literal remap="tt">ipfwadm</literal> on your 2.0 kernel, there are scripts
|
|
available to convert the <literal remap="tt">ipfwadm</literal> command format to the format <literal remap="tt">ipchains</literal> uses.
|
|
</para>
|
|
|
|
<para>
|
|
Be sure to read the IP Chains HOWTO for further information. It is
|
|
available at <ulink
|
|
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
|
|
>http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Netfilter - Linux Kernel 2.4.x Firewalling</title>
|
|
|
|
<para>
|
|
In yet another set of advancements to the kernel IP packet filtering code,
|
|
netfilter allows users to set up, maintain, and inspect the packet filtering
|
|
rules in the new 2.4 kernel.
|
|
</para>
|
|
|
|
<para>
|
|
The netfilter subsystem is a complete rewrite of previous packet filtering
|
|
implementations including ipchains and ipfwadm. Netfilter provides a large
|
|
number of improvements, and it has now become an even more mature and robust
|
|
solution for protecting corporate networks.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<programlisting>
|
|
iptables
|
|
</programlisting>
|
|
is the command-line interface used to manipulate
|
|
the firewall tables within the kernel.
|
|
</para>
|
|
|
|
<para>
|
|
Netfilter provides a raw framework for manipulating packets as they traverse
|
|
through various parts of the kernel. Part of this framework includes support for
|
|
masquerading, standard packet filtering, and now more complete network
|
|
address translation. It even includes improved support for load balancing
|
|
requests for a particular service among a group of servers behind the
|
|
firewall.
|
|
</para>
|
|
|
|
<para>
|
|
The stateful inspection features are especially powerful. Stateful inspection
|
|
provides the ability to track and control the flow of communication passing
|
|
through the filter. The ability to keep track of state and context information
|
|
about a session makes rules simpler and tries to interpret higher-level protocols.
|
|
</para>
|
|
|
|
<para>
|
|
Additionally, small modules can be developed to perform additional specific
|
|
functions, such as passing packets to programs in userspace for processing
|
|
then reinjecting back into the normal packet flow. The ability to develop these
|
|
programs in userspace reduces the level of complexity that was previously
|
|
associated with having to make changes directly at the kernel level.
|
|
</para>
|
|
|
|
<para>
|
|
Other IP Tables references include:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/feature_stories/feature_story-94.html"
|
|
>Oskar Andreasson IP Tables Tutorial</ulink
|
|
></emphasis> -- Oskar Andreasson speaks
|
|
with LinuxSecurity.com about his comprehensive IP Tables tutorial and
|
|
how this document can be used to build a robust firewall for your organization.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/feature_stories/feature_story-93.html"
|
|
>Hal Burgiss Introduces Linux Security Quick-Start Guides</ulink
|
|
></emphasis> -- Hal Burgiss has written two authoritative guides on securing Linux,
|
|
including managing firewalling.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://netfilter.samba.org"
|
|
>Netfilter Homepage</ulink
|
|
></emphasis> -- The netfilter/iptables homepage.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html"
|
|
>Linux Kernel 2.4 Firewalling Matures: netfilter</ulink
|
|
></emphasis> -- This
|
|
LinuxSecurity.com article describes the basics of packet filtering, how to
|
|
get started using iptables, and a list of the new features available in
|
|
the latest generation of firewalling for Linux.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>VPNs - Virtual Private Networks</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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: <ulink
|
|
url="ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html"
|
|
>ip-masq-vpn</ulink
|
|
>.
|
|
</para>
|
|
|
|
<para>
|
|
There are several Linux VPN solutions available:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
vpnd. See the <ulink
|
|
url="http://sunsite.dk/vpnd/"
|
|
>http://sunsite.dk/vpnd/</ulink
|
|
>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Free S/Wan, available at <ulink
|
|
url="http://www.xs4all.nl/~freeswan/"
|
|
>http://www.xs4all.nl/~freeswan/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
ssh can be used to construct a VPN. See the VPN mini-howto
|
|
for more information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
vps (virtual private server) at <ulink
|
|
url="http://www.strongcrypto.com"
|
|
>http://www.strongcrypto.com</ulink
|
|
>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
yawipin at <ulink
|
|
url="mailto:http://yavipin.sourceforge.net"
|
|
>http://yavipin.sourceforge.net</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
See also the section on IPSEC for pointers and more information.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="secure-prep">
|
|
<title>Security Preparation (before you go on-line)</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Make a Full Backup of Your Machine</title>
|
|
|
|
<para>
|
|
Discussion of backup methods and storage is beyond the scope of this
|
|
document, but here are a few words relating to backups and security:
|
|
</para>
|
|
|
|
<para>
|
|
If you have less than 650mb of data to store on a partition, a CD-R
|
|
copy of your data is a good way to go (as it's hard to tamper with
|
|
later, and if stored properly can last a long time), you will of
|
|
course need at least 650MB of space to make the image. Tapes and other
|
|
re-writable media should be write-protected as soon as your backup is
|
|
complete, and then verified to prevent tampering. Make sure you store your
|
|
backups in a secure off-line area. A good backup will ensure that you
|
|
have a known good point to restore your system from.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Choosing a Good Backup Schedule</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Testing your backups</title>
|
|
|
|
<para>
|
|
You should do periodic tests of your backups to make sure they are
|
|
working as you might expect them to. Restores of files and checking
|
|
against the real data, sizes and listings of backups, and reading old
|
|
backups should be done on a regular basis.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Backup Your RPM or Debian File Database</title>
|
|
|
|
<para>
|
|
In the event of an intrusion, you can use your RPM database like you
|
|
would use <literal remap="tt">tripwire</literal>, 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.
|
|
</para>
|
|
|
|
<para>
|
|
The files <literal remap="tt">/var/lib/rpm/fileindex.rpm</literal> and
|
|
<literal remap="tt">/var/lib/rpm/packages.rpm</literal> most likely won't fit on a single floppy.
|
|
But if compressed, each should fit on a seperate floppy.
|
|
</para>
|
|
|
|
<para>
|
|
Now, when your system is compromised, you can use the command:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<screen>
|
|
root# rpm -Va
|
|
</screen>
|
|
|
|
to verify each file on the system. See the <literal remap="tt">rpm</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="logs">
|
|
<title>Keep Track of Your System Accounting Data</title>
|
|
|
|
<para>
|
|
It is very important that the information that comes from <literal remap="tt">syslog</literal>
|
|
not be compromised. Making the files in <literal remap="tt">/var/log</literal> readable and
|
|
writable by only a limited number of users is a good start.
|
|
</para>
|
|
|
|
<para>
|
|
Be sure to keep an eye on what gets written there, especially under
|
|
the <literal remap="tt">auth</literal> facility. Multiple login failures, for example, can
|
|
indicate an attempted break-in.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">/var/log</literal> and check <literal remap="tt">messages</literal>,
|
|
<literal remap="tt">mail.log</literal>, and others.
|
|
</para>
|
|
|
|
<para>
|
|
You can find out where your distribution is logging to by looking at
|
|
your <literal remap="tt">/etc/syslog.conf</literal> file. This is the file that tells
|
|
<literal remap="tt">syslogd</literal> (the system logging daemon) where to log various messages.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">logrotate</literal> package on recent Red Hat distributions. Other
|
|
distributions likely have a similar process.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
You should also be sure to separate the <literal remap="tt">auth</literal> facility from other log
|
|
data, including attempts to switch users using <literal remap="tt">su</literal>, login attempts,
|
|
and other user accounting information.
|
|
</para>
|
|
|
|
<para>
|
|
If possible, configure <literal remap="tt">syslog</literal> 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
|
|
<literal remap="tt">syslog.conf</literal> man page, and refer to the <literal remap="tt">@</literal> option.
|
|
</para>
|
|
|
|
<para>
|
|
There are several more advanced <literal remap="tt">syslogd</literal> programs out
|
|
there. Take a look at <ulink
|
|
url="http://www.core-sdi.com/ssyslog/"
|
|
>http://www.core-sdi.com/ssyslog/</ulink
|
|
> for Secure Syslog. Secure
|
|
Syslog allows you to encrypt your syslog entries and make sure no one
|
|
has tampered with them.
|
|
</para>
|
|
|
|
<para>
|
|
Another <literal remap="tt">syslogd</literal> with more features is <ulink
|
|
url="http://www.balabit.hu/en/downloads/syslog-ng/"
|
|
>syslog-ng</ulink
|
|
>. It allows you a lot more flexibility in your
|
|
logging and also can has your remote syslog streams to prevent
|
|
tampering.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Apply All New System Updates.</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="after-breakin">
|
|
<title>What To Do During and After a Breakin</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Security Compromise Underway.</title>
|
|
|
|
<para>
|
|
Spotting a security compromise under way can be a tense
|
|
undertaking. How you react can have large consequences.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">tcp_wrappers</literal> or <literal remap="tt">ipfwadm</literal>
|
|
to deny access from the intruder's site.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">.rhosts</literal> files,
|
|
FTP access, and a host of possible backdoors.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Security Compromise has already happened</title>
|
|
|
|
<para>
|
|
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?
|
|
</para>
|
|
|
|
<sect3>
|
|
<title>Closing the Hole</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <ulink
|
|
url="http://www.caldera.com/tech-ref/security/"
|
|
>http://www.caldera.com/tech-ref/security/</ulink
|
|
>. Red Hat has not
|
|
yet separated their security fixes from bug fixes, but their
|
|
distribution errata is available at <ulink
|
|
url="http://www.redhat.com/errata"
|
|
>http://www.redhat.com/errata</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Debian now has a security mailing list and web page. See: <ulink
|
|
url="http://www.debian.org/security/"
|
|
>http://www.debian.org/security/</ulink
|
|
> for more information.
|
|
</para>
|
|
|
|
<para>
|
|
It is very likely that if one vendor has released a security update,
|
|
that most other Linux vendors will as well.
|
|
</para>
|
|
|
|
<para>
|
|
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:
|
|
</para>
|
|
|
|
<para>
|
|
<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
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Assessing the Damage</title>
|
|
|
|
<para>
|
|
The first thing is to assess the damage. What has been compromised?
|
|
If you are running an integrity checker like <literal remap="tt">Tripwire</literal>, 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
Then you have to worry about how long ago the compromise happened, and
|
|
whether the backups hold any damaged work. More on backups later.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Backups, Backups, Backups!</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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!
|
|
</para>
|
|
|
|
<para>
|
|
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.)
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Tracking Down the Intruder.</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">whois</literal> 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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
You should also notify any security organizations you are a part of
|
|
(<ulink
|
|
url="http://www.cert.org/"
|
|
>CERT</ulink
|
|
> or similar), as well as your Linux system vendor.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="sources">
|
|
<title>Security Sources</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<sect2 id="linuxsecurity">
|
|
<title>LinuxSecurity.com References</title>
|
|
|
|
<para>
|
|
The LinuxSecurity.com web site has numerous Linux and open source security
|
|
references written by the LinuxSecurity staff and people collectively around
|
|
the world.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/vuln-newsletter.html"
|
|
>Linux Advisory Watch</ulink
|
|
></emphasis> -- A comprehensive newsletter that outlines the security
|
|
vulnerabilities that have been announced throughout the week. It includes
|
|
pointers to updated packages and descriptions of each vulnerability.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/newsletter.html"
|
|
>Linux Security Week</ulink
|
|
></emphasis> --
|
|
The purpose of this document is to provide our readers with a quick summary
|
|
of each week's most relevant Linux security headlines.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/general/mailinglists.html"
|
|
>Linux Security Discussion List</ulink
|
|
></emphasis> -- This mailing list is for general security-related questions and comments.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/general/mailinglists.html"
|
|
>Linux Security Newsletters</ulink
|
|
></emphasis> -- Subscription information for all newsletters.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/docs/colsfaq.html"
|
|
>comp.os.linux.security FAQ</ulink
|
|
></emphasis> -- Frequently Asked Questions with answers for the comp.os.linux.security newsgroup.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis><ulink
|
|
url="http://www.linuxsecurity.com/docs/"
|
|
>Linux Security Documentation</ulink
|
|
></emphasis> -- A great starting point for information pertaining to Linux and Open Source security.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="ftpsites">
|
|
<title>FTP Sites</title>
|
|
|
|
<para>
|
|
CERT is the Computer Emergency Response Team. They often send out
|
|
alerts of current attacks and fixes. See <ulink
|
|
url="ftp://ftp.cert.org"
|
|
>ftp://ftp.cert.org</ulink
|
|
> for more information.
|
|
</para>
|
|
|
|
<para>
|
|
ZEDZ (formerly Replay) (<ulink
|
|
url="http://www.zedz.net"
|
|
>http://www.zedz.net</ulink
|
|
>)
|
|
has archives of many security programs. Since they are outside
|
|
the US, they don't need to obey US crypto restrictions.
|
|
</para>
|
|
|
|
<para>
|
|
Matt Blaze is the author of CFS and a great security advocate. Matt's
|
|
archive is available at <ulink
|
|
url="ftp://ftp.research.att.com/pub/mab"
|
|
>ftp://ftp.research.att.com/pub/mab</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
<literal remap="tt">tue.nl</literal> is a great security FTP site in the Netherlands.
|
|
<ulink
|
|
url="ftp://ftp.win.tue.nl/pub/security/"
|
|
>ftp.win.tue.nl</ulink
|
|
>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="websites">
|
|
<title>Web Sites</title>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
The Hacker FAQ is a FAQ about hackers: <ulink
|
|
url="http://www.solon.com/~seebs/faqs/hacker.html"
|
|
>The Hacker FAQ</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The COAST archive has a large number of Unix security programs and
|
|
information: <ulink
|
|
url="http://www.cs.purdue.edu/coast/"
|
|
>COAST</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
SuSe Security Page: <ulink
|
|
url="http://www.suse.de/security/"
|
|
>http://www.suse.de/security/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Rootshell.com is a great site for seeing what exploits are currently
|
|
being used by crackers: <ulink
|
|
url="http://www.rootshell.com/"
|
|
>http://www.rootshell.com/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
BUGTRAQ puts out advisories on security issues: <ulink
|
|
url="http://www.netspace.org/lsv-archive/bugtraq.html"
|
|
>BUGTRAQ archives</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
CERT, the Computer Emergency Response Team, puts out advisories on
|
|
common attacks on Unix platforms: <ulink
|
|
url="http://www.cert.org/"
|
|
>CERT home</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
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: <ulink
|
|
url="http://www.trouble.org"
|
|
>http://www.trouble.org</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The Linux security WWW is a good site for Linux security information:
|
|
<ulink
|
|
url="http://www.aoy.com/Linux/Security/"
|
|
>Linux Security WWW</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Infilsec has a vulnerability engine that can tell you what
|
|
vulnerabilities affect a specific platform: <ulink
|
|
url="http://www.infilsec.com/vulnerabilities/"
|
|
>http://www.infilsec.com/vulnerabilities/</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
CIAC sends out periodic security bulletins on common exploits: <ulink
|
|
url="http://ciac.llnl.gov/cgi-bin/index/bulletins"
|
|
>http://ciac.llnl.gov/cgi-bin/index/bulletins</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
A good starting point for Linux Pluggable Authentication modules can
|
|
be found at <ulink
|
|
url="http://www.kernel.org/pub/linux/libs/pam/"
|
|
>http://www.kernel.org/pub/linux/libs/pam/</ulink
|
|
>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The Debian project has a web page for their security fixes and
|
|
information. It is at <ulink
|
|
url="http://www.debian.com/security/"
|
|
>http://www.debian.com/security/</ulink
|
|
>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
WWW Security FAQ, written by Lincoln Stein, is a great web
|
|
security reference. Find it at <ulink
|
|
url="http://www.w3.org/Security/Faq/www-security-faq.html"
|
|
>http://www.w3.org/Security/Faq/www-security-faq.html</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Mailing Lists</title>
|
|
|
|
<para>
|
|
Bugtraq: To subscribe to bugtraq, send mail to listserv@netspace.org
|
|
containing the message body subscribe bugtraq. (see links above for
|
|
archives).
|
|
</para>
|
|
|
|
<para>
|
|
CIAC: Send e-mail to majordomo@tholia.llnl.gov. In the BODY (not
|
|
subject) of the message put (either or both): subscribe ciac-bulletin
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Red Hat has a number of mailing lists, the most important of which is
|
|
the redhat-announce list. You can read about security (and other)
|
|
fixes as soon as they come out. Send email to
|
|
redhat-announce-list-request@redhat.com with the Subject Subscribe
|
|
See <ulink
|
|
url="https://listman.redhat.com/mailman/listinfo/"
|
|
>https://listman.redhat.com/mailman/listinfo/</ulink
|
|
> for
|
|
more info and archives.
|
|
</para>
|
|
|
|
<para>
|
|
The Debian project has a security mailing list that covers their
|
|
security fixes. See <ulink
|
|
url="http://www.debian.com/security/"
|
|
>http://www.debian.com/security/</ulink
|
|
> for more information.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Books - Printed Reading Material</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky,
|
|
1st Edition September 1995,
|
|
ISBN: 1-56592-124-0
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel & Gene Spafford, 2nd Edition April 1996, ISBN: 1-56592-148-8
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr., 1st
|
|
Edition July 1991, ISBN: 0-937175-71-4
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Linux Network Administrator's Guide By Olaf Kirch, 1st Edition January
|
|
1995, ISBN: 1-56592-087-2
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
PGP: Pretty Good Privacy By Simson Garfinkel, 1st Edition December 1994,
|
|
ISBN: 1-56592-098-8
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Computer Crime A Crimefighter's Handbook By David Icove, Karl
|
|
Seger & William VonStorch (Consulting Editor Eugene H. Spafford),
|
|
1st Edition August 1995, ISBN: 1-56592-086-4
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Linux Security By John S. Flowers, New Riders; ISBN: 0735700354, March 1999
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Maximum Linux Security : A Hacker's Guide to Protecting Your Linux Server
|
|
and Network, Anonymous, Paperback - 829 pages, Sams; ISBN: 0672313413, July
|
|
1999
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Intrusion Detection By Terry Escamilla, Paperback - 416 pages
|
|
(September 1998), John Wiley and Sons; ISBN: 0471290009
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Fighting Computer Crime, Donn Parker, Paperback - 526 pages (September
|
|
1998), John Wiley and Sons; ISBN: 0471163783
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Glossary</title>
|
|
|
|
<para>
|
|
Included below are several of the most frequently used terms in computer
|
|
security. A comprehensive dictionary of computer security terms is available
|
|
in the <ulink
|
|
url="http://www.linuxsecurity.com/dictionary/"
|
|
>LinuxSecurity.com Dictionary</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">authentication:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">bastion Host:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">buffer overflow:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">denial of service:</emphasis> An attack that consumes the
|
|
resources on your computer for things it was
|
|
not intended to be doing, thus preventing normal use of your network
|
|
resources for legitimate purposes.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">dual-homed Host:</emphasis> A general-purpose computer system that
|
|
has at least two network interfaces.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">firewall:</emphasis> A component or set of components that restricts
|
|
access between a protected network and the Internet, or between other
|
|
sets of networks.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">host:</emphasis> A computer system attached to a network.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">IP spoofing:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">non-repudiation:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">packet:</emphasis> The fundamental unit of communication on the
|
|
Internet.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">packet filtering:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">perimeter network:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">proxy server:</emphasis> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis remap="bf">superuser:</emphasis> An informal name for <literal remap="tt">root</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="q-and-a">
|
|
<title>Frequently Asked Questions</title>
|
|
|
|
<para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
Is it more secure to compile driver support directly into the
|
|
kernel, instead of making it a module?
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Why does logging in as root from a remote machine always fail?
|
|
</para>
|
|
<para>
|
|
Answer: See <xref linkend="root-security" />. This is done
|
|
intentionally to prevent remote users from attempting to connect via
|
|
<literal remap="tt">telnet</literal> to your machine as <literal remap="tt">root</literal>, which is a serious
|
|
security
|
|
vulnerability, because then the root password would be transmitted, in
|
|
clear text, across the network. Don't forget: potential intruders have time on their
|
|
side, and can run automated programs to find your
|
|
password. Additionally, this is done to keep a clear record of who
|
|
logged in, not just root.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
How do I enable shadow passwords on my Linux box?
|
|
</para>
|
|
<para>
|
|
Answer:
|
|
</para>
|
|
|
|
<para>
|
|
To enable shadow passwords, run <literal remap="tt">pwconv</literal> as root, and
|
|
<literal remap="tt">/etc/shadow</literal> 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 <literal remap="tt">/etc/passwd</literal> to shadow
|
|
passwords without any other change.
|
|
</para>
|
|
|
|
<para>
|
|
Some background: shadow passwords is a mechanism for storing your
|
|
password in a file other than the normal <literal remap="tt">/etc/passwd</literal> file. This has
|
|
several advantages. The first one is that the shadow file,
|
|
<literal remap="tt">/etc/shadow</literal>, is only readable by root, unlike <literal remap="tt">/etc/passwd</literal>,
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal remap="tt">/etc/passwd</literal> file is then used to store user and group names, used
|
|
by programs like <literal remap="tt">/bin/ls</literal> to map the user ID to the proper user name
|
|
in a directory listing.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal remap="tt">/etc/shadow</literal> file then only contains the user name and his/her
|
|
password, and perhaps accounting information, like when the account
|
|
expires, etc.
|
|
</para>
|
|
|
|
<para>
|
|
To enable shadow passwords, run <literal remap="tt">pwconv</literal> as root, and
|
|
<literal remap="tt">/etc/shadow</literal> 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 <literal remap="tt">/etc/passwd</literal> to shadow
|
|
passwords without any other change.
|
|
</para>
|
|
|
|
<para>
|
|
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 <literal remap="tt">pam_cracklib</literal> 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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
How can I enable the Apache SSL extensions?
|
|
</para>
|
|
<para>
|
|
Answer:
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
Get SSLeay 0.8.0 or later from <ulink
|
|
url="ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL"
|
|
>�</ulink>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Build and test and install it!
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Get Apache source
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Get Apache SSLeay extensions from
|
|
<ulink
|
|
url="ftp://ftp.ox.ac.uk/pub/crypto/SSL/"
|
|
>here</ulink>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Unpack it in the apache source directory and patch Apache as
|
|
per the README.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Configure and build it.
|
|
</para>
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
You might also try <ulink
|
|
url="http://www.zedz.net"
|
|
>ZEDZ net</ulink
|
|
>
|
|
which has many pre-built packages, and is located outside of the United States.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
How can I manipulate user accounts, and still retain security?
|
|
</para>
|
|
<para>
|
|
Answer: most distributions contain a great number of tools to change
|
|
the properties of user accounts.
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
|
|
<para>
|
|
The <literal remap="tt">pwconv</literal> and <literal remap="tt">unpwconv</literal> programs can be used to convert
|
|
between shadow and non-shadowed passwords.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The <literal remap="tt">pwck</literal> and <literal remap="tt">grpck</literal> programs can be used to verify proper
|
|
organization of the <literal remap="tt">passwd</literal> and <literal remap="tt">group</literal> files.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
The <literal remap="tt">useradd</literal>, <literal remap="tt">usermod</literal>, and <literal remap="tt">userdel</literal> programs can be used to
|
|
add, delete and modify user accounts. The <literal remap="tt">groupadd</literal>,
|
|
<literal remap="tt">groupmod</literal>, and <literal remap="tt">groupdel</literal> programs will do the same for groups.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
Group passwords can be created using <literal remap="tt">gpasswd</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
All these programs are "shadow-aware" -- that is, if you enable shadow
|
|
they will use <literal remap="tt">/etc/shadow</literal> for password information, otherwise they won't.
|
|
</para>
|
|
|
|
<para>
|
|
See the respective man pages for further information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
How can I password-protect specific HTML documents using
|
|
Apache?
|
|
</para>
|
|
<para>
|
|
I bet you didn't know about <ulink
|
|
url="http://www.apacheweek.com"
|
|
>http://www.apacheweek.org</ulink
|
|
>, did you?
|
|
</para>
|
|
|
|
<para>
|
|
You can find information on user authentication at <ulink
|
|
url="http://www.apacheweek.com/features/userauth"
|
|
>http://www.apacheweek.com/features/userauth</ulink
|
|
> as well as other
|
|
web server security tips from <ulink
|
|
url="http://www.apache.org/docs/misc/security_tips.html"
|
|
>http://www.apache.org/docs/misc/security_tips.html</ulink
|
|
>
|
|
</para>
|
|
</listitem>
|
|
|
|
</orderedlist>
|
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="conclusion">
|
|
<title>Conclusion</title>
|
|
|
|
<para>
|
|
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 <literal remap="tt">tripwire</literal> regularly,
|
|
you can do even more.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Acknowledgments</title>
|
|
|
|
<para>
|
|
Information here is collected from many sources. Thanks to the
|
|
following who either indirectly or directly have contributed:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
Rob Riggs
|
|
<ulink url="mailto:rob@DevilsThumb.com">rob@DevilsThumb.com</ulink>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
S. Coffin
|
|
<ulink
|
|
url="mailto:scoffin@netcom.com"
|
|
>scoffin@netcom.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Viktor Przebinda
|
|
<ulink
|
|
url="mailto:viktor@CRYSTAL.MATH.ou.edu"
|
|
>viktor@CRYSTAL.MATH.ou.edu</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Roelof Osinga
|
|
<ulink
|
|
url="mailto:roelof@eboa.com"
|
|
>roelof@eboa.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Kyle Hasselbacher
|
|
<ulink
|
|
url="mailto:kyle@carefree.quux.soltec.net"
|
|
>kyle@carefree.quux.soltc.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
David S. Jackson
|
|
<ulink
|
|
url="mailto:dsj@dsj.net"
|
|
>dsj@dsj.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Todd G. Ruskell
|
|
<ulink
|
|
url="mailto:ruskell@boulder.nist.gov"
|
|
>ruskell@boulder.nist.gov</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Rogier Wolff
|
|
<ulink
|
|
url="mailto:R.E.Wolff@BitWizard.nl"
|
|
>R.E.Wolff@BitWizard.nl</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Antonomasia <ulink
|
|
url="mailto:ant@notatla.demon.co.uk"
|
|
>ant@notatla.demon.co.uk</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Nic Bellamy <ulink
|
|
url="mailto:sky@wibble.net"
|
|
>sky@wibble.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Eric Hanchrow <ulink
|
|
url="mailto:offby1@blarg.net"
|
|
>offby1@blarg.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Robert J. Berger<ulink
|
|
url="mailto:rberger@ibd.com"
|
|
>rberger@ibd.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Ulrich Alpers <ulink
|
|
url="mailto:lurchi@cdrom.uni-stuttgart.de"
|
|
>lurchi@cdrom.uni-stuttgart.de</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
David Noha <ulink
|
|
url="mailto:dave@c-c-s.com"
|
|
>dave@c-c-s.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Pavel Epifanov. <ulink
|
|
url="mailto:epv@ibm.net"
|
|
>epv@ibm.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Joe Germuska. <ulink
|
|
url="mailto:joe@germuska.com"
|
|
>joe@germuska.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Franklin S. Werren <ulink
|
|
url="mailto:fswerren@bagpipes.net"
|
|
>fswerren@bagpipes.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Paul Rusty Russell <ulink
|
|
url="mailto:Paul.Russell@rustcorp.com.au"
|
|
><Paul.Russell@rustcorp.com.au></ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Christine Gaunt <ulink
|
|
url="mailto:cgaunt@umich.edu"
|
|
><cgaunt@umich.edu></ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
lin <ulink
|
|
url="mailto:bhewitt@refmntutl01.afsc.noaa.gov"
|
|
>bhewitt@refmntutl01.afsc.noaa.gov</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
A. Steinmetz <ulink
|
|
url="mailto:astmail@yahoo.com"
|
|
>astmail@yahoo.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Jun Morimoto <ulink
|
|
url="mailto:morimoto@xantia.citroen.org"
|
|
>morimoto@xantia.citroen.org</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Xiaotian Sun <ulink
|
|
url="mailto:sunx@newton.me.berkeley.edu"
|
|
>sunx@newton.me.berkeley.edu</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Eric Hanchrow <ulink
|
|
url="mailto:offby1@blarg.net"
|
|
>offby1@blarg.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Camille Begnis <ulink
|
|
url="mailto:camille@mandrakesoft.com"
|
|
>camille@mandrakesoft.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Neil D <ulink
|
|
url="mailto:neild@sympatico.ca"
|
|
>neild@sympatico.ca</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Michael Tandy <ulink
|
|
url="mailto:Michael.Tandy@BTInternet.com"
|
|
>Michael.Tandy@BTInternet.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Tony Foiani <ulink
|
|
url="mailto:tkil@scrye.com"
|
|
>tkil@scrye.com</ulink
|
|
>
|
|
</para>
|
|
|
|
|
|
<para>
|
|
Matt Johnston <ulink
|
|
url="mailto:mattj@flashmail.com"
|
|
>mattj@flashmail.com</ulink>
|
|
</para>
|
|
|
|
<para>
|
|
Geoff Billin <ulink
|
|
url="mailto:gbillin@turbonet.com"
|
|
>gbillin@turbonet.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Hal Burgiss <ulink
|
|
url="mailto:hburgiss@bellsouth.net"
|
|
>hburgiss@bellsouth.net</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Ian Macdonald <ulink
|
|
url="mailto:ian@linuxcare.com"
|
|
>ian@linuxcare.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
M.Kiesel <ulink
|
|
url="mailto:m.kiesel@iname.com"
|
|
>m.kiesel@iname.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Mario Kratzer <ulink
|
|
url="mailto:kratzer@mathematik.uni-marburg.de"
|
|
>kratzer@mathematik.uni-marburg.de</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Othmar Pasteka <ulink
|
|
url="mailto:pasteka@kabsi.at"
|
|
>pasteka@kabsi.at</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Robert M <ulink
|
|
url="mailto:rom@romab.com"
|
|
>rom@romab.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Cinnamon Lowe <ulink
|
|
url="mailto:clowe@cinci.rr.com"
|
|
>clowe@cinci.rr.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Rob McMeekin <ulink
|
|
url="mailto:blind_mordecai@yahoo.com"
|
|
>blind_mordecai@yahoo.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Gunnar Ritter <ulink url="mailto:g-r@bigfoot.de"> g-r@bigfoot.de</ulink>
|
|
</para>
|
|
|
|
<para>
|
|
Frank Lichtenheld<ulink url="mailto:frank@lichtenheld.de">frank@lichtenheld.de</ulink>
|
|
</para>
|
|
|
|
<para>
|
|
Björn Lotz<ulink url="mailto:blotz@suse.de">blotz@suse.de</ulink>
|
|
</para>
|
|
|
|
<para>
|
|
Othon Marcelo Nunes Batista<ulink url="mailto:othonb@superig.com.br">othonb@superig.com.br</ulink>
|
|
</para>
|
|
|
|
<para>
|
|
The following have translated this HOWTO into various other languages!
|
|
</para>
|
|
|
|
<para>
|
|
A special thank you to all of them for help spreading the Linux word...
|
|
</para>
|
|
|
|
<para>
|
|
Polish: Ziemek Borowski <ulink
|
|
url="mailto:ziembor@FAQ-bot.ZiemBor.Waw.PL"
|
|
>ziembor@FAQ-bot.ZiemBor.Waw.PL</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Japanese: FUJIWARA Teruyoshi <ulink
|
|
url="mailto:fjwr@mtj.biglobe.ne.jp"
|
|
>fjwr@mtj.biglobe.ne.jp</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Indonesian: Tedi Heriyanto <ulink
|
|
url="mailto:22941219@students.ukdw.ac.id"
|
|
>22941219@students.ukdw.ac.id</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Korean: Bume Chang <ulink
|
|
url="mailto:Boxcar0001@aol.com"
|
|
>Boxcar0001@aol.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Spanish: Juan Carlos Fernandez <ulink
|
|
url="mailto:piwiman@visionnetware.com"
|
|
>piwiman@visionnetware.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Dutch: "Nine Matthijssen" <ulink
|
|
url="mailto:nine@matthijssen.nl"
|
|
>nine@matthijssen.nl</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Norwegian: ketil@vestby.com <ulink
|
|
url="mailto:ketil@vestby.com"
|
|
>ketil@vestby.com</ulink
|
|
>
|
|
</para>
|
|
|
|
<para>
|
|
Turkish: tufan karadere <ulink url="mailto:tufank@metu.edu.tr">tufank@metu.edu.tr</ulink>
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
</article>
|
|
|