College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001 |
Security Fortification
|
| |
|
|
| |
| Abstract: This lecture is about adding a layer of
protection beyond proper configuration of the OS and
applications. This layer of protection consists of tools that
help detect changes in the system and monitor (suspicious)
system activity. |
| |
| This work is supported in part by NSF
DUE-9951380. |
|
- Educational
Objectives
- Security Fortification
- Virus Scanners
- Root Kit Detection
- File System Auditor
- Activity Monitors
- Log Analyzers
- Lab
Experiment
- Acknowledgements
- References
- Appreciate the need for adding extra layers of protection beyond
out-of-the-box installation of an operating system
- Understand the limitations of such a protective layer
- Aware of widely available tools for fortification.
Security Fortification
Fortification is the addition of packages to improve security. It
should be done after a system has been properly configured with the supplied
components. Fortification frequently will discard a supplied component in
preference to a carefully chosen added component. In our discussion, we
will postpone certain "fortification" items as "hardening"
items even though we cannot offer a rigorous definition regarding the use of
these two terms.
Virus Scanners
Of the many fortification suggestions made in this lecture, virus scanners
are probably the most universally experienced item.
Process Audit
Capture the output of ps aux and examine all processes
periodically. An example ps list is shown below.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.3 1092 432 ? S Jun21 0:04 init [5]
root 2 0.0 0.0 0 0 ? SW Jun21 0:00 [kflushd]
root 3 0.0 0.0 0 0 ? SW Jun21 0:00 [kpiod]
root 4 0.0 0.0 0 0 ? SW Jun21 0:00 [kswapd]
root 5 0.0 0.0 0 0 ? SW< Jun21 0:00 [mdrecoveryd]
root 103 0.0 0.1 1072 156 ? S Jun21 0:01 update (bdflush)
root 541 0.0 0.3 1152 464 ? S Jun21 0:00 syslogd
root 544 0.0 0.5 1400 660 ? S Jun21 0:00 klogd -k /boot/Sy
root 563 0.0 0.3 1128 428 ? S Jun21 0:00 inetd
bin 565 0.0 0.2 1112 284 ? S Jun21 0:00 rpc.portmap
daemon 606 0.0 0.2 1228 300 ? S Jun21 0:00 atd
root 647 0.0 0.6 2284 828 ? S Jun21 0:02 httpd -f /etc/htt
root 665 0.0 0.4 1644 532 ? S Jun21 0:00 /usr/X11R6/bin/xf
root 732 0.0 0.3 1096 428 tty1 S Jun21 0:00 /sbin/getty tty1
root 741 0.0 1.7 5452 2252 ? S Jun21 0:00 /opt/kde/bin/kdm
root 743 1.3 10.0 48160 12868 ? S Jun21 18:26 /usr/X11R6/bin/X
root 748 0.0 2.5 6372 3264 ? S Jun21 0:00 -:0
root 750 0.0 0.8 6888 1060 ? S Jun21 0:00 /usr/X11R6/bin/xf
pmateti 765 0.3 3.2 6280 4208 ? S Jun21 4:16 kwm
pmateti 792 0.0 2.8 6156 3608 ? S Jun21 0:00 /opt/kde/bin/kbgn
pmateti 809 0.0 2.6 5864 3396 ? S Jun21 0:01 /opt/kde/bin/kbla
pmateti 816 0.0 3.6 8096 4648 ? S Jun21 0:01 kfm
pmateti 819 0.0 2.6 5724 3456 ? S Jun21 0:00 krootwm
pmateti 820 0.0 3.4 6424 4372 ? S Jun21 0:01 kpanel
The first five are not expected to have different process ids than what is
shown. The remainder may get higher or lower pids depending on what is included
in the bootup scripts. However, once the boot scripts have stabilized you must
make a note of all process ids, and expect them to remain unchanged until the
scripts change again.
You should also check that: All processes owned by user
"nobody" are running programs explicitly identified as legitimate for
untrusted, unverified, remote users. Each process belonging to each
non-root system user is explicitly identified as legitimate for that user in
this environment. Each process belonging to each user is explicitly identified
as legitimate for that user in this environment.
File System Auditor
Early on, many intruders replaced binaries with their own Trojan
versions. Many system administrators relied on time-stamping and check sum
the files to determine when a binary file has been modified. But it is fairly
simple to recreate the same time-stamp for the Trojan file as the original file.
For example, if your standard touch does not do touch -r
/bin/.login /bin/login develop a touch program that does
it. Or, by setting the system clock time back to the original file's time
and then adjusting the trojan file's time to the system clock. Once the binary
Trojan file has the exact same time as the original, the system clock is reset
to the current time. Simple check sum programs rely on a CRC checksum and is
easily spoofed. MD5 check sums are based on an algorithm that no one has
yet spoofed. This technology is behind the well known Tripwire.
Root Kit Detection
Installing a rootkit is the logical next step that Internet intruders will
perform once they have obtained root privileges of a workstation in the
hope of prolonging his root status. A rootkit replaces standard utilities
such as ps, lsof, netstat, etc. that a real root may use to notice suspicious
activity. Unless a file system auditor is in place, it is not easy to spot
the rootkits after their installation. The time to be alert is when the
root kits are being installed.
Activity Monitors
TCP Wrapper: When a potentially insecure service must be run, tcp_wrappers
should be utilized to "wrap" it. The wrapper software does more
detailed logging and better access control checking by "wrapping"
itself around the normal network daemons configured in inetd.conf.
The tcpd used in Linux is a new version of the TCP wrapper.
PortSentry for NT is a program which logs (and optionally blocks) access to
TCP and UDP services on the system. It will detect scans for exploitable
services (old versions of imap, ftp) and scans for Trojan horses (Back Orifice,
Netbus etc.) PortSentry is available from http://www.psionic.com/
ifstatus by David A Curry is a standalone program to check for promiscuous
interfaces available from ftp://coast.cs.purdue.edu/pub/tools/unix/ifstatus
dtk or "Deception Toolkit" is a kit of fake daemons and services
designed to waste an intruders time. dtk is available from all.net/dtk/example.html
Bastille Linux is a series of scripts which tighten up security on stock
Linux systems, by changing permissions and disabling features. Taken to extreme,
this will also prevent legitimate work and is more suitable for hardening a
dedicated loghost or fileserver than a development system. Bastille is available
from www.bastille-linux.org
NIS replacement
Using Rsync + SSH as a Replacement for NIS
Log Analyzers
Logs produced by the kerneld, syslogd, tcpd, and the various services can
become so large that it is humanly impossible to scan them for spotting
suspicious activity and take a more serious look. A few well know log
analyzers are listed below.
- wwwstat, HTTPd Log file Analysis Software, http://www.ics.uci.edu/pub/websoft/wwwstat/
- Analog, Web server log file analyzer, http://www.statslab.cam.ac.uk/~sret1/analog/
- freq, A lastlog analyzer, http://www.bangmoney.org/projects/freq/
- tcpdstats, tcpd log analyzer, http://www.kaostech.com/products/html/tcpdstats.html
- Wietse Venema, "TCP Wrapper: Network monitoring, access control, and
booby traps", Proceedings of the Third Usenix UNIX Security
Symposium, pp. 85-92, Baltimore, September 1992. The source
distribution is available at ftp://ftp.porcupine.org/pub/security/.
Required reading. [Local
copy in .ps].
- Unix Workstation Support Group, Using Rsync + SSH as a Replacement for NIS,
www.uwsg.iu.edu/
security/rsync.html Recommended Reading.
- D. O'Brien, "Recognizing and Recovering from Rootkit Attacks".
Sys Admin 5(11) (November 1996), pp. 8-20. Required reading. [local
copy]
- Fred Cohen and Assoc, Audit Check Lists, http://www.all.net/books/audit/unix/top.html
Recommended Reading.