old-www/LDP/lame/LAME/linux-admin-made-easy/security.html

634 lines
14 KiB
HTML

<HTML
><HEAD
><TITLE
>Strategies for Keeping a Secure Server</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
"><LINK
REL="HOME"
TITLE="Linux Administration Made Easy"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Server Migration and Scalability Issues"
HREF="server-migration.html"><LINK
REL="NEXT"
TITLE="Help! Trouble in Paradise!"
HREF="trouble-in-paradise.html"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Linux Administration Made Easy</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="server-migration.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="trouble-in-paradise.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="SECURITY"
>Chapter 12. Strategies for Keeping a Secure Server</A
></H1
><P
>Linux can certainly be considered to be as secure -- or more secure
-- than operating systems from other vendors. Admittedly, with Linux
becoming more and more popular, it is becoming a very attractive target
for crackers to concentrate their break-in efforts on. There are exploits
that are discovered from time to time, however the open nature of Linux
usually means that such exploits are patched quickly, and security
announcements are disseminated widely, containing either temporary
workarounds or pointers to updated software.</P
><P
>I won't pretend to be an expert on security issues, however I am at
least aware of these issues, which I believe to be a large part of the
battle towards making one's systems as secure as possible. Although being
aware and diligent in keeping up with security updates will in no way
guarantee that a system's security measures won't be circumvented, the
likelihood of a break-in is greatly reduced.</P
><P
>Although there have been security exploits found in external
services which could have been used by crackers to break into a system
(for example, the IMAP daemon exploit), I believe that it is far more
likely that a determined cracker will penetrate the system from
<EM
>within</EM
>. Compared to the handful of services
communicating with the outside world, there are
<EM
>thousands</EM
> of commands and utilities available from
the shell, one or more of which may contain bugs which can be exploited to
penetrate security (that being said, I must admit to recently discovering
one of the servers I maintain had been compromised through an external
service).</P
><P
>For this reason, I recommend avoiding giving out shell accounts to
users unless they are absolutely necessary. Even if you consider your
users completely trustworthy and have no qualms in providing them with
access to the shell, all it takes is just one of these users to have a
weak password. An outside cracker, finding its way into your system by
exploiting this weak password, will then be able to work at his or her
leisure internally, looking for further weaknesses.</P
><P
>There are, fortunately, things you can do to greatly increase the
security of your Linux system. While a detailed discussion of security
issues is beyond the scope of this document, the following checklist
provides some of the most important things you should do to enhance
security:</P
><P
></P
><UL
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Upgrade system tools, applications, and kernel:</FONT
>
By far the most common cause of system break-ins is by not exercising
diligence in keeping an up-to-date server. Performing regular upgrades of
the system kernel, tools and utilities will ensure that your system is not
filled with older items for which known exploits are available. For
details on keeping an up-to-date server, see <A
HREF="update-redhat.html"
>Section 4.9</A
>, as well as <A
HREF="keeping-up-to-date.html"
>Section 10.3</A
>.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Shadow passwords:</FONT
> You should definitely be using
Shadow passwords; switching to this password format is
<EM
>easy</EM
>! For details, see <A
HREF="shadow-file-formats.html"
>Section 6.6</A
>.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Smart password management:</FONT
> Make sure passwords,
<EM
>especially</EM
> for users you are providing with shell
access, are strong and changed often. Also, if you use multiple servers,
resist the temptation to use the same password for all of them (otherwise,
if a cracker breaks into one server using a discovered password, he or she
can break into them all).</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Use secure shell (ssh):</FONT
> Switch to using ``ssh''
instead of ``telnet''. Telnet is insecure for two reasons: One, sessions
are unencrypted, which means everything, including username and passwords,
are transmitted as clear text. Second, an open telnet port is one of the
first places a cracker will try to connect to.</P
><P
>Ssh provides encrypted and compressed connections and provide
substantially more security than telnet connections. You can run a ssh
server (which allows incoming secure connections) as well as a client (for
outgoing secure connections) under Linux. You can find binary RPM
packages at <A
HREF="ftp://ftp.replay.com/pub/replay/redhat/i386/"
TARGET="_top"
>ftp://ftp.replay.com/pub/replay/redhat/i386/</A
>. You will need the
following files (newer versions may be available by the time you read
this):</P
><P
></P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: Bullet"
><P
><A
HREF="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-1.2.27-5i.i386.rpm"
TARGET="_top"
>ssh-1.2.27-5i.i386.rpm</A
> The base package.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><A
HREF="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-clients-1.2.27-5i.i386.rpm"
TARGET="_top"
>ssh-clients-1.2.27-5i.i386.rpm</A
> Clients for outgoing connections.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><A
HREF="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-extras-1.2.27-5i.i386.rpm"
TARGET="_top"
>ssh-extras-1.2.27-5i.i386.rpm</A
> Some handy perl-based scripts.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><A
HREF="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-server-1.2.27-5i.i386.rpm"
TARGET="_top"
>ssh-server-1.2.27-5i.i386.rpm</A
> Server for incoming connections.</P
></LI
></UL
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>Note: The SSH RPM files listed above are the international
versions. If you reside in the U.S. or Canada, you can choose to download
the U.S. packages (which may have stronger encryption algorithms); these
packages have a ``us'' instead of an ``i'' suffix after their version
numbers. Under U.S. law, it is <EM
>illegal</EM
> to export
strong crypto products outside of the U.S. or Canada. Hopefully one day
the morons in the U.S. Department of Justice will finally see the light,
and remove this silly restriction (Red Hat doesn't include SSH with their
distribution because of this very reason, and we <EM
>all</EM
>
suffer).</P
></BLOCKQUOTE
></DIV
><P
>Should your Windows users be up-in-arms about no longer being able
to connect to your system, they will be happy to know that several free
ssh clients for Windows are available:</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="QUOTE"
>"TeraTerm Pro"</SPAN
> client software</DT
><DD
><P
><A
HREF="http://hp.vector.co.jp/authors/VA002416/teraterm.html"
TARGET="_top"
>http://hp.vector.co.jp/authors/VA002416/teraterm.html</A
></P
></DD
><DT
><SPAN
CLASS="QUOTE"
>"TTSSH"</SPAN
> client software</DT
><DD
><P
><A
HREF="http://www.zip.com.au/~roca/download.html"
TARGET="_top"
>http://www.zip.com.au/~roca/download.html</A
></P
></DD
><DT
><SPAN
CLASS="QUOTE"
>"Cryptlib"</SPAN
> client software</DT
><DD
><P
><A
HREF="http://www.doc.ic.ac.uk/~ci2/ssh"
TARGET="_top"
>http://www.doc.ic.ac.uk/~ci2/ssh</A
></P
></DD
><DT
><SPAN
CLASS="QUOTE"
>"Putty"</SPAN
> client software</DT
><DD
><P
><A
HREF="http://www.chiark.greenend.org.uk/~sgtatham/putty.html"
TARGET="_top"
>http://www.chiark.greenend.org.uk/~sgtatham/putty.html</A
></P
></DD
></DL
></DIV
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>Note: If you do decide to switch to using ssh, make sure you install
and use it on <EM
>all</EM
> your servers. Having five secure
servers and one insecure one is a waste of time,
<EM
>especially</EM
> if you are foolish enough to use the same
password for more than one server.</P
></BLOCKQUOTE
></DIV
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Restrict access to external services:</FONT
> Next, you
should edit the ``<TT
CLASS="LITERAL"
>/etc/hosts.allow</TT
>'' as well as the
``<TT
CLASS="LITERAL"
><TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
></TT
>'' file to
restrict access to services to external hosts. Here is an example of how
to restrict telnet and ftp access. First, the
``<TT
CLASS="LITERAL"
><TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
></TT
>'' file:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># hosts.allow
in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name
in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name</PRE
></TD
></TR
></TABLE
><P
>The above would allow any hosts in the IP class C's 123.12.41.* and
126.27.18.*, as well as any host within the mydomain.name and another.name
domains to make telnet and ftp connections.</P
><P
>Next, the ``<TT
CLASS="LITERAL"
><TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
></TT
>''
file:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># hosts.deny
in.telnetd: ALL
in.ftpd: ALL</PRE
></TD
></TR
></TABLE
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Turn off and uninstall unneeded services:</FONT
> Edit
your ``<TT
CLASS="LITERAL"
><TT
CLASS="FILENAME"
>/etc/inetd.conf</TT
></TT
>'' file,
and disable (ie. comment out using a ``<TT
CLASS="LITERAL"
>#</TT
>'' character)
any services that are not needed (if you're using ssh as recommended
above, you might wish to disable the ``telnet'' service). After you have
done so, as root type ``<TT
CLASS="LITERAL"
>/etc/rc.d/init.d/inet
restart</TT
>'' to restart the inetd daemon with the
changes.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Install a security detection system:</FONT
> Consider
installing security programs such as ``Tripwire'' (see <A
HREF="http://www.tripwiresecurity.com/"
TARGET="_top"
>http://www.tripwiresecurity.com/</A
>) which can detect intrusions, and
``Abacus Sentry'' (see <A
HREF="http://www.psionic.com/abacus/"
TARGET="_top"
>http://www.psionic.com/abacus/</A
>) which can help prevent
them.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
><FONT
COLOR="RED"
>Due diligence:</FONT
> Keeping your eye on your system, performing
random security audits (which can be as simple as checking for suspicious
entries in the password files, examining your process list, and checking
your log files for suspicious entries) can go a long way towards keeping
a secure system. In addition, report any break-in attempts to the
appropriate authorities -- it may be a hassle to do this, particularly if
your system sees several of these attacks in a given week, but such reports
ensures that would-be crackers are deterred by threat of punishment, as well
as ensuring that others' systems (which may themselves have been compromised)
are kept secure.</P
></LI
><LI
STYLE="list-style-type: Bullet"
><P
>Assuming you install and upgrade system tools and
applications using the ``<TT
CLASS="LITERAL"
>RPM</TT
>'' utility, you may wish to
verify the integrity of your installed packages by auditing them with the
following command:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="SCREEN"
><TT
CLASS="USERINPUT"
><B
>rpm --verify -a &#62; /tmp/rpm-audit.txt</B
></TT
></PRE
></TD
></TR
></TABLE
><P
>The above command will check your system's RPM database with all
relevant files, and indicate any files which have been modified, by
displaying a '5'. Here is some example output of such an audit:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="SCREEN"
>S.5....T /bin/ls
S.5....T /usr/bin/du
......G. /dev/tty5
.....U.. /dev/vcs5
.....U.. /dev/vcsa5
S.5....T c /etc/lynx.cfg
S.5....T c /etc/sendmail.cf</PRE
></TD
></TR
></TABLE
><P
>In the sample output above, you can see a list of seven files, four
of which have been modified. Now, obviously there are going to be
several, perhaps many, files which have been modified if you have
customized your system at all. A brief check of the
<TT
CLASS="FILENAME"
>/etc/lynx.cfg</TT
> and
<TT
CLASS="FILENAME"
>/etc/sendmail.cf</TT
> files, perhaps visually or perhaps
from backup, might reveal legitimate configuration changes that you have
made to your system.</P
><P
>However, notice in the sample above, two of the modified files are
<EM
>binary executable</EM
> files? It is likely that these two
binaries, the ``ls'' command as well as the ``du'' command, are actually
trojan binaries which a system cracker has installed to perform some
nefarious purposes (a ``<TT
CLASS="LITERAL"
>diff</TT
>'' command performed on any
modified binaries with those restored from backup or RPM might reveal
significant size or other differences; further evidence of
trojans.)</P
><P
>(For more information on ``<TT
CLASS="LITERAL"
>RPM</TT
>'', see <A
HREF="using-rpm.html"
>Section 10.1</A
>.)</P
></LI
></UL
><P
>For more information on security-related issues, an excellent
resource entitled, <SPAN
CLASS="QUOTE"
>"Securing RedHat 5.x"</SPAN
> document is
available at <A
HREF="http://redhat-security.ens.utulsa.edu/"
TARGET="_top"
>http://redhat-security.ens.utulsa.edu/</A
>. An excellent resource
for Linux crypto and related software is at
<A
HREF="http://replay.com/redhat"
TARGET="_top"
>http://replay.com/redhat/</A
>.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="server-migration.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="trouble-in-paradise.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Server Migration and Scalability Issues</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Help! Trouble in Paradise!</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>