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.
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.
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
within. Compared to the handful of services
communicating with the outside world, there are
thousands 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).
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.
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:
Upgrade system tools, applications, and kernel:
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 Section 4.9, as well as Section 10.3.
Shadow passwords: You should definitely be using
Shadow passwords; switching to this password format is
easy! For details, see Section 6.6.
Smart password management: Make sure passwords,
especially 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).
Use secure shell (ssh): 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.
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 ftp://ftp.replay.com/pub/replay/redhat/i386/. You will need the
following files (newer versions may be available by the time you read
this):
ssh-1.2.27-5i.i386.rpm The base package.
ssh-clients-1.2.27-5i.i386.rpm Clients for outgoing connections.
ssh-extras-1.2.27-5i.i386.rpm Some handy perl-based scripts.
ssh-server-1.2.27-5i.i386.rpm Server for incoming connections.
Note: 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 illegal 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 all
suffer).
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:
- "TeraTerm Pro" client software
http://hp.vector.co.jp/authors/VA002416/teraterm.html
- "TTSSH" client software
http://www.zip.com.au/~roca/download.html
- "Cryptlib" client software
http://www.doc.ic.ac.uk/~ci2/ssh
- "Putty" client software
http://www.chiark.greenend.org.uk/~sgtatham/putty.html
Note: Note: If you do decide to switch to using ssh, make sure you install
and use it on all your servers. Having five secure
servers and one insecure one is a waste of time,
especially if you are foolish enough to use the same
password for more than one server.
Restrict access to external services: Next, you
should edit the ``/etc/hosts.allow'' as well as the
``/etc/hosts.deny'' file to
restrict access to services to external hosts. Here is an example of how
to restrict telnet and ftp access. First, the
``/etc/hosts.allow'' file:
# 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 |
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.
Next, the ``/etc/hosts.deny''
file:
# hosts.deny
in.telnetd: ALL
in.ftpd: ALL |
Turn off and uninstall unneeded services: Edit
your ``/etc/inetd.conf'' file,
and disable (ie. comment out using a ``#'' 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 ``/etc/rc.d/init.d/inet
restart'' to restart the inetd daemon with the
changes.
Install a security detection system: Consider
installing security programs such as ``Tripwire'' (see http://www.tripwiresecurity.com/) which can detect intrusions, and
``Abacus Sentry'' (see http://www.psionic.com/abacus/) which can help prevent
them.
Due diligence: 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.
Assuming you install and upgrade system tools and
applications using the ``RPM'' utility, you may wish to
verify the integrity of your installed packages by auditing them with the
following command:
rpm --verify -a > /tmp/rpm-audit.txt |
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:
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 |
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
/etc/lynx.cfg and
/etc/sendmail.cf files, perhaps visually or perhaps
from backup, might reveal legitimate configuration changes that you have
made to your system.
However, notice in the sample above, two of the modified files are
binary executable 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 ``diff'' command performed on any
modified binaries with those restored from backup or RPM might reveal
significant size or other differences; further evidence of
trojans.)
(For more information on ``RPM'', see Section 10.1.)
For more information on security-related issues, an excellent
resource entitled, "Securing RedHat 5.x" document is
available at http://redhat-security.ens.utulsa.edu/. An excellent resource
for Linux crypto and related software is at
http://replay.com/redhat/.
