[QueueNews] The Seven Deadly Sins of Linux Security

Mon Jun 18 08:00:02 PDT 2007

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
. . . . . . . . . . . . . . . . . . . . . . . .
   Queue E-Mail Newsletter
   for the Week of Jun/18/2007
. . . . . . . . . . . . . . . . . . . . . . . .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------
      Sponsored by

      Quest Software
      Aladdin
      Macrovision
      O'Reilly Open Source Convention

/----------------------------------------------------------\

Learn to manage the production application at your organization!

Unplanned change has a huge impact on IT. Improve application
performance and end user satisfaction through automation and careful
planning.  http://acmqueue.com/special/qclg4.php

\----------------------------------------advertisement------/

Latest Articles:

The Seven Deadly Sins of Linux Security
Avoid these common security risks like the devil
http://acmqueue.com/rd.php?c.484
   (scroll down to read an excerpt from this article)

Ode or Code? - Programmers Be Mused!
Is your code literate or literary?
http://acmqueue.com/rd.php?c.483

/----------------------------------------------------------\

Power of IP Protection!

Protect your intellectual property. Find out how by downloading the
Power of IP Protection and Software Licensing podcast!
http://acmqueue.com/modules.php?name=Queuecasts&id=20

\----------------------------------------advertisement------/

New article on ACM Queue:
The Seven Deadly Sins of Linux Security
http://acmqueue.com/rd.php?c.484
Avoid these common security risks like the devil
by Bob Toxen, Horizon Network Security

>From the API Design issue, vol. 5, no. 4 - May/June 2007

article excerpt:
The problem with security advice is that there is too much of it and
that those responsible for security certainly have too little time to
implement all of it. The challenge is to determine what the biggest
risks are and to worry about those first and about others as time
permits. Presented here are the seven common problems - the seven
deadly
sins of security - most likely to allow major damage to occur to your
system or bank account. If any of these are a problem on any of your
systems, you will want to take care of them immediately.

These
seven deadly sins are based on my research and experience, which
includes too many people who wait until after their Linux or Unix
systems have suffered security breaches before they take action to
increase system security, and on forensics analysis and discussions
with
systems administrators. Most of these sins and their solutions also
apply to Macs, Windows, and other platforms.

They are not
ordered by risk level because committing any one of them will likely
allow your system to be compromised if it is accessible from the
Internet. Even if you are behind a firewall, if you receive any
untrusted data from the Internet, such as Web pages, e-mail, or instant
messages, your system is at great risk. Avoid these sins like the
devil.

Without further ado, here are the seven deadly sins and
what to do about them.

 SIN ONE: Weak Passwords

As a
systems administrator, you are aware of the system breaches possible on
your Linux or Unix machine. You have taken the time and effort to
devise
a difficult-to-guess root password that uses at least 12 characters
that
include at least two words or no words from the dictionary, uses both
letters and digits, and has upper- and lowercase letters and some
punctuation characters.

I still run into clients with passwords
so simple that any hacker could break them in a few minutes with a
tweaked version of ssh that guesses different passwords. Such hacker
tools can be found on the Web easily with Google or built by any C or
C++ programmer. On Internet-accessible systems, I have seen root
passwords consisting of a word followed by a small number, where that
word is related to the company, what it does, who is in it, or where it
is. A good hacker will go to your Web site and see all of this
information, then feed it into a password-cracking program.

Another common mistake is to use the same password or very similar
passwords for root accounts (or other important accounts) on different
systems. Thus, a cracker who breaches one system through a means other
than password guessing will then be able to install a Trojaned server
for ssh, FTP, or IMAP, or a Trojaned CGI program on that system, see
what passwords you use, and try them on the other systems. I have seen
this happen many times.

A variation is to use ssh public keys to
allow an account on one system to ssh into another system without
supplying any password. At the very least, pick a moderately
hard-to-crack password for your ssh keys. If you must have an automatic
program use ssh without a password to ssh into another system, then
create either a separate nonroot account on the target system or an
alternate account with UID 0 but a login "shell" that does just what is
needed, such as doing a backup.

[]
src="http://acmqueue.com/figures/issue043/tip1.gif" width="392"
height="327">

An even better solution, say for a remote backup,
would be for the system needing to be backed up to ssh into the system
receiving the backups as a unique unprivileged account for this purpose
and copy an encrypted version of the backup. Thus, if the backup server
is compromised, no confidential data will be obtained.

Let's
hope your root password is awesome and that no one could guess it in
100
years. OK, some obsessive with a program such as Crack could destroy it
in a few days except that you use shadow passwords, but that's another
story. It is critically important to select good passwords.

How
are your users doing? Choke, cough, gag, hack. Every account is a
possible entry point. Have your users followed your advice, company
policy, or threats to devise good passwords? Are they being as careful
as you are? Probably not. Now it is your turn to don the black hat and
think like your enemy.

[]
src="http://acmqueue.com/figures/issue043/tip2.gif" width="390"
height="259">

Can you break into your users' accounts by using a
password-cracking program? You definitely will need to get written
management approval to conduct this level of security audit. There are
notable cases of unauthorized audits landing people in jail or at least
on the unemployment rolls. (Randal Schwartz is one. The software
consultant and author was brought to trial for accessing a password
file
at Intel in what he says was an attempt to show lapses in security.)
You might even install a module in the passwd program that
automatically tries to break a user's proposed new password. Though the
standard passwd program makes very simple tests, there are more
sophisticated routines that include much of Crack's capability. One way
to do this is to make use of the cracklib capability in the PAM
(pluggable authentication modules) enhancements to the passwd program.
The cracklib library analyzes passwords to determine if they can be
easily cracked. PAM offers additional security for Linux and Unix
systems.

Edit the /etc/pam.d/passwd file to include the
code in figure 1. This will cause the PAM-enabled passwd program to
load
these dynamically loadable program libraries. PAM now is standard with
Red Hat. On some systems these are in /lib instead of
/usr/lib. (Another good source for PAM information is
href="http://www.sun.com/software/solaris/pam/">http://www.sun.com/software/sola
ris/pam/.)
[fig1.gif] height="162">

On Slackware this capability will be enabled if
the following line is present in /etc/login.defs (and the
dictionary is installed):

CRACKLIB_DICTPATH
/var/cache/cracklib/cracklib_dict

Consider restricting
which remote systems can ssh into your systems' various accounts either
through IP tables firewall rules or by editing your ssh server's
configuration file, /etc/ssh/sshd_config, to limit which remote
systems can ssh in and which accounts they can ssh into, or use both
methods for additional security. Make this list very short for root (in
sshd_config).
Read the rest of this article at acmqueue.com
http://acmqueue.com/rd.php?c.484

/----------------------------------------------------------\

Arm your Applications for Bulletproof Deployment

Gartner reports that even after 10 years of experience, most companies
cannot automatically deploy software with a success rate of 90 percent
or better. In this ACM Premium Queuecast with host Mike Vizard,
installation expert Tom Spalthoff from Macrovision discusses how
companies can achieve a reliable desktop environment while reducing the
time and cost spent preparing high-quality application packages that
deploy successfully http://acmqueue.com/special/qclg8.php
\----------------------------------------advertisement------/

See all the latest articles and audio interviews with Queue's RSS Feeds
http://acmqueue.com/rd.php?s.48.7

To unsubscribe to this newsletter, send an email to
queuenews-request at acmqueue.com
with the words 'unsubscribe' in the subject line.

Change your email address
http://www.acmqueue.com/mailman/options/queuenews

Subscribe to Queue in print
http://www.acmqueue.com/click.php?id=30
About Queue
http://acmqueue.com/rd.php?s.31.5
Contact Us
http://acmqueue.com/rd.php?s.32.10
Privacy policy
http://acmqueue.com/rd.php?s.27.9

For advertising information, contact advertising at acmqueue.com

/----------------------------------------------------------\

OSCON July 23-27, 2007 in Portland Oregon

Now in its ninth year, the O'Reilly Open Source Convention is the
bazaar
of open source technologies, welcoming new voices and projects
alongside
the platforms, languages, and apps that started the open source
movement. More then 2500 open source professionals come together to
network, learn, and share the latest knowledge around open source
software. ACM Queue readers save 10% when they use discount code
os07acm. http://conferences.oreilly.com/oscon
\----------------------------------------advertisement------/