[aclug-L] FW: To stop an attacker, think like a cracker, Part 2

["Dale W Hodge" <dwh@xxxxxxxxxxxxxxxx>]

LINUX SECURITY --- September 25, 2001
Published by ITworld.com -- changing the way you view IT
http://www.itworld.com/newsletters
________________________________________________________________________________

HIGHLIGHTS

* Whether they use network scanners to find vulnerabilities or they
  concentrate on stealing one of your passwords, attackers are looking
  to break into your network and you need to understand how they are
  going about it.
________________________________________________________________________________


Attacking Linux, Part 2
By Rick Moen

Camouflage
However, regardless of whether your attacker entered via the front or
back door, his next priority after gaining root access is to cover his
tracks, preventing the administrator from noticing his presence and
locking him out. He'll do that by sabotaging the system logs and
accounting software, disabling any security-monitoring software, and
installing trojan horse (trojaned) software to conceal his activities,
gain additional intelligence, and create back doors in case he needs
another way in.

The trojaned software usually includes replacement binaries for the
genuine login, netstat, ps, ifconfig, du, df, ls, top, syslogd, tcpd,
locate, and various servers run by the inetd superserver. The aim is to
hide the attacker's tools, logs, and processes, so that they are
invisible to the legitimate root user.

And tomorrow the world!
Some of those processes will be spy programs, running to capture login
information entered by local users for remote systems elsewhere. Those
will be logged and conveyed back to the attacker, giving him new
targets. Some may be network sniffers, monitoring the traffic passing
nearby, to or from other nearby machines, and likewise capturing
private information for the bad guys. Those work by putting your
network interface in promiscuous mode, in which the normal disregarding
of other machines' network traffic gets disabled. Some may be
clandestine network services, such as file-swapping, that are useful
for the attacker and his friends. Most distressing of all, some may be
carrying out attacks on other systems. The older variety of those
involved flooding distant machines with either normal or deliberately
malformed network traffic (ping, ping of death, smurf, SYN flooding,
teardrop, land, bonk), as a denial of service (DoS) attack. Then
starting last year, the more-organized DDoS tools (trinoo, Tribal Flood
Network, stacheldraht, Trank, and so on) came to sudden public
attention when they were used to overwhelm popular Internet sites. The
third-party, subverted machines (zombies) used to carry out those
attacks appear to have been university machines, favored for their lax
security and high Internet bandwidth, but your Linux hosts could be the
attackers' next tools.

Even if your machines don't cause you that order of embarrassment, the
other risks are equally grim: you can reveal confidential data with
business and/or personal consequences, lose that data entirely, see it
corrupted or sabotaged, be involved in wrongful or even criminal
activity, lose access to your computing resources, and indirectly cause
harm to your staff and business associates. Your Website can be defaced
or modified, or visitors might be redirected by sabotaged company DNS
servers to entirely different sites.

What would the Master Control Program do?
As Ozancin pointed out, to prevent, detect, and recover from such
attacks, your first step is to spend some time thinking like an
attacker. Spend some time exploring your network with Nessus, nmap2,
and Firewalk, discovering its vulnerabilities as if you were an
outsider peeking in. Set John the Ripper loose on your password files
to discover any trivial-to-break passwords with which your users are
damaging your security posture. Subscribe to the security-alert mailing
list for your Linux distribution. Install one or more security-checking
packages LIDS, LogCheck, Tripwire, or HostSentry, or simply generate
and store (off-system) MD5 checksums for all critical system files (see
Resources).

Disable all network services you're not sure you need (if you're wrong,
you'll find out), including those in /etc/inetd.conf), and the CGI
scripts on Web servers. (Never place scripting executables such as the
Perl interpreter in your CGI-BIN directory.) If you wish to leave the
user-information service finger running, make sure it's not one that
lists all logged-in users if you run finger @hostname (substituting
your machine's name for hostname). Stay current on security-related
revisions, especially for the network services you leave enabled. The
foregoing measures are probably the second most valuable precautions
you can take.

The most valuable measure would involve password policies. you'll want
to always used shadowed passwords. The utility pwconv will switch you
over to those (populating /etc/shadow, and removing all passwords
from /etc/passwd) if you aren't running shadowed already. That
essentially eliminates the risk of password cracking.

You'll also want to set a minimum password length. Most Linux
distributions require five or six minimum characters, but Ozancin
suggests changing that to require a full eight characters. Since most
Linux systems these days use a Pluggable Authentication Module (PAM)
security architecture, the minimum length can usually be set easily in
the /etc/pam.d/passwd configuration file.

In addition, you should consider avoiding plaintext-password network
services: The POP3, FTP, and Telnet daemons pose a special risk because
their passwords pass unencrypted across the open network, sniffable by
any nearby machine along the way. SSH (the secure-shell suite) and
stunnel can replace or protect the vulnerable protocols, and you can
use SSL encryption for any sensitive Web-based information. For best
protection, Ozancin recommends two-factor authentication3: adding an
additional security mechanism to the password one such as a smart card
or an encryption key pair. Users should be encouraged (and equipped) to
encrypt any sensitive email using PGP or GNU Privacy Guard (see
Resources). Also, given the possibility of network sniffing, use
switched Ethernet hubs wherever possible to isolate traffic (thus
minimizing the amount of sniffable information).

Next Week: Attacking Linux, Part 3


Notes

    2. Among nmap's interesting features is the ability to estimate
       your chances of successfully predicting TCP sequence numbers on
       a target system, a method described by Steven Bellovin in 1989
       and reportedly used by Kevin Mitnick in 1994 to remotely take
       over security consultant Tsutomu Shimomura's Unix host. Ozancin
       used nmap to show that such guessing is thousands of times more
       difficult against a remote machine running a generic Linux 2.2
       kernel than against one running MS Windows NT 4.0 with the
       latest service pack. nmap can also operate in decoyed mode, in
       which a high percentage of the probe packets purport to come
       from elsewhere entirely. One series of probes against Pentagon
       systems in December 1998 seemed to originate from addresses all
       over Russia, but is now thought to have involved a single
       university machine running nmap.

    3. The rule of thumb in security is that you can maximize security
       through a three-factor approach: something you know, something
       you have, and something you are. Passwords typify something you
       know, smart cards are an example of something you have, and
       biometric scanning techniques exemplify something you are. The
       latter may seem science-fictional, but I saw a mouse device that
       incorporates a fingerprint reader at the August 2000 Stanford
       Cypherpunks meeting: they are being mass produced as you read
       this.

________________________________________________________________________________



About the author(s)
-------------------
Rick Moen is a recovering system administrator in the San Francisco Bay
Area, who served as primary Bay Area organizer for Windows Refund Day,
and has been one of the main troublemakers behind Silicon Valley Linux
User Group's Silicon Valley Tea Party, the Great Linux Revolt of '98,
and other Bay Area Linux PR events.
________________________________________________________________________________

ADDITIONAL RESOURCES

Security-checking packages:

LIDS:
http://www.lids.org/

LogCheck:
http://www.psionic.com/abacus/logcheck/

Tripwire:
http://www.tripwire.com/

HostSentry:
http://www.psionic.com/abacus/hostsentry/

MD5:
http://www.gl.umbc.edu/~mabzug1/cs/md5/md5.html

Safer protocols:

Secure-shell (SSH):
http://www.tigerlair.com/ssh/faq/

stunnel:
http://www.stunnel.org/

PGP:
http://www.pgpi.org/

GNU Privacy Guard:
http://www.gnupg.org/
________________________________________________________________________________

CUSTOMER SERVICE

SUBSCRIBE/UNSUBSCRIBE:
- Go to: http://www.itworld.com/newsletters
- Click on "View my newsletters" to log in and manage your account
- To subscribe, check the box next to the newsletter
- To unsubscribe, uncheck the box next to the newsletter
- When finished, click submit

Questions? Please e-mail customer service at: mailto:support@xxxxxxxxxxx
________________________________________________________________________________

CONTACTS

* Editorial: Andrew Santosusso, Associate Editor, Newsletters,
  andrew_santosusso@xxxxxxxxxxx
* Advertising: Clare O'Brien, Vice President of Sales,
  clare_obrien@xxxxxxxxxxx
* Recruitment advertising: Jamie Swartz, Eastern, Regional Sales
  Manager, jamie_swartz@xxxxxxxxxxx or Paul Duthie, Western Regional
  Sales Manager, paul_duthie@xxxxxxxxxxxxx
* Other inquiries: Jodie Naze, Senior Product Marketing Manager,
  jodie_naze@xxxxxxxxxxx
________________________________________________________________________________

PRIVACY POLICY

http://www.itworld.com/Privacy/

Copyright 2001 ITworld.com, Inc., All Rights Reserved.
http://www.itworld.com


-- This is the discussion@xxxxxxxxx list.  To unsubscribe,
visit http://tmp2.complete.org/cgi-bin/listargate-aclug.cgi