 | Level: Intermediate Emily Ratliff (ratliff@austin.ibm.com), Software Engineer,
IBM
30 Apr 2007 Think you have a secure Linux® system? Following best
practices during installation and setup is a must, but if you haven't set up regular
system auditing, you're missing half the picture. This article discusses some
existing tools and offers a couple of sample scripts to automate the process in a
real-world environment.
Many articles and books have been written on how to install a secure Linux
system. But once the system has been installed to meet security requirements, only
half the battle is won. The second half involves ensuring that the system
continues to meet its security requirements throughout its lifetime (and that you
can prove it). This means that periodic system auditing is required to make sure
that nothing goes wrong.
System audit requirements
The security requirements that you verify during routine system auditing should
be the same requirements and security principles that guide the system
installation. The three-part developerWorks series
"Securing
Linux"
gives you an introduction on how to install a reasonably secure Linux system.
Regular system auditing will also help refine the security policy used for new
machine installations as it helps close the feedback loop on what subsystems are
actually in use.
The first tools for meeting these requirements are system auditing and
host-based intrusion detection. This article focuses on system auditing.
Host-based intrusion detection systems such as tripwire, AIDE, and Samhain detect
when changes have been made to the file system and are therefore critical tools
for ensuring that the system retains its known state. The Linux Gazette has
an interesting article, "Constructive Paranoia," on using these tools (see
Resources section below for a link).
This article focuses specifically on the practical aspects of periodic system
auditing based on real-world requirements from a system administrator of a subnet
in a large academic network. The lessons learned by this administrator apply to
everyone from business intranets to home users who want to prevent their home
machine from becoming a zombie in the bot army. The administrator's system is
required to undergo periodic, random system audits, during which routine audit
activities (such as showing that the audit and system logs are regularly reviewed,
and checking for user accounts that have lapsed), In addition, the administrator
also has to address the following:
- Justification for suid/sgid executables that are on the system and why they
are suid/sgid
- Proof that no file system with a world writable directory (/tmp and /var/tmp)
has any suid/sgid files
- Open ports and the impact of firewalling off of those ports
What are all those suid files for?
Identifying the suid and sgid files on your system — and disabling the
unnecessary ones — is one of the fundamental rules of installing a secure
system. This task is so common that the man page for
find lists the parameters for this in its examples.
Listing 1 is a script that executes the typical find
command and also helps answer the question of what the suid file does and what
package it belongs to, in order to help the administrator to identify it, and
decide if it should stay on the system or be removed. (You can download the code
for Listings 1, 3, and 4 from the zip file in the Download
section later in this article.)
Listing 1. Abbreviated sample output on suid/sgid files
[root@localhost hpc]# ./find_setuids.pl /
04755 root /usr/X11R6/bin/cardinfo
cardinfo - PCMCIA card monitor and control utility for X
pcmcia-cardinfo-3.2.7-107.3
04755 root /usr/bin/opiepasswd
opiepasswd - Change or set a user's password for the
OPIE authentication system.
Opie-2.4-544.1
04755 root /usr/bin/opiesu
opiesu - Replacement su(1) program that uses OPIE challenges
opie-2.4-544.1
04755 root /usr/bin/sudo
sudo - execute a command as another user
sudo-1.6.7p5-117.4
|
Which file systems contain world writable
directories?
As an administrator, you might be interested in world writable directories to
meet the requirement that all user-writable file systems be mounted with the
nosuid attribute. User-writable directories include users' home directories as
well as any world writable directories. This requirement is in place to prevent
users from creating suid executables that another user or administrator might
inadvertently execute. However, if a legitimate suid executable is on the same
file system as a world writable directory and is thus mounted nosuid, the suid
bits are ignored and the executable will not operate correctly. You might consider
implementing this restriction on your multi-user systems as well.
The script in Listing 1 also tests each regular file system for world writable
directories and reports whether the file system contains a world writable
directory at the end of the output. For each suid/sgid file, it also reports
whether the file is on a filesystem that contains world writable directories.
Abbreviated example output on world writable directories:
/ Contains both suid/sgid files and world writable directories.
What network ports does the system use
and for what purpose?
There are several ways to detect which ports are in use on your system. Nmap,
netstat, and lsof are the most helpful tools.
-
Nmap is an extremely flexible tool that can do active and passive
scanning of remote (and local) systems.
-
Netstat shows the network information about the local system. By
default, it shows open connections.
-
Lsof lists open files on the system. It can be used to get information
about port usage because it also shows information about network sockets.
Kurt Seifried maintains a listing of 8,457 commonly used ports. (A link to his
ports list is in the Resources below.) You can use this
data to help explain what the port is being used for and what the impact would be
of firewalling it off. He includes information about ports that are commonly used
for trojans and root kits; for example, 31337 is commonly used by Back Orifice and
12345, 12346, and 20034 are used by netbus.
Listing 2 contains a script that uses lsof and netstat to show the system's
current port usage in an easily readable format.
Listing 2. Sample output from port_scan.sh:
[root@localhost hpc]# ./port_scan.sh
please wait...
PORT SERVICE LINK
22 sshd
http://www.seifried.org/security/ports/0/22.html
25 sendmail
http://www.seifried.org/security/ports/0/25.html
123 ntpd
http://www.seifried.org/security/ports/0/123.html
631 cupsd
http://www.seifried.org/security/ports/0/631.html
46336 <-> 22 ssh **
|
In Listing 2, the low-number ports (<1024) indicate daemons running on
the system that accept incoming communication unless firewalled off. The
high-number port 46336 shows an outgoing ssh connection and the port (22) that it
is connected to on the other end. This means that blocking outbound communication
on ephemeral ports will break commonly used client programs such as ssh. See
Kurt's ports list in Resources for more details on the
effects of firewalling the higher-number ports.
These scripts and tools show port usage at a point in time. The audit subsystem
can be used to find out which ports have been used (for the duration of the audit
log files) even if they are not currently in use. Adding the following audit rule
to /etc/audit.rules will log calls to bind.
-a entry,always -S socketcall -F a0=2
The parameter -a entry,always indicates that the rule
should always be invoked at the beginning of the system call execution. The
-S socketcall indicates that this audit rule is for the
socketcall syscall. The socketcall syscall is multiplexed on the i386
architecture, so the -F
a0=2 is required to limit the
audit records generated to bind only.
Other architectures handle the bind system call differently, so these commands
and scripts will have to be altered slightly to handle architectures other than
i386. Audit events are recorded as multiple audit records that are correlated by a
shared serial number. ausearch will correlate the related records using the serial
number and present them as a group. The -i flag requests that numeric values,
indicating, for example, that saddr (IP address) and uid (user name) be translated
to human readable text when possible.
Listing 3. Abbreviated output from ausearch
# ausearch -i -sc socketcall
Abbreviated example output
----
type=SOCKETCALL msg=audit(11/20/2006 11:28:43.844:10) : nargs=3 a0=0
a1=b8004004 a2=10
type=SOCKADDR msg=audit(11/20/2006 11:28:43.844:10) : saddr=inet
host:127.0.0.1 serv:631
type=SYSCALL msg=audit(11/20/2006 11:28:43.844:10) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bfffaca0 a2=b8000664
a3=1 items=0 pid=3340 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=cupsd
exe=/usr/sbin/cupsd
----
type=SOCKETCALL msg=audit(11/20/2006 16:40:46.169:16) : nargs=3 a0=6
a1=b8056720 a2=10
type=SOCKADDR msg=audit(11/20/2006 16:40:46.169:16) : saddr=inet
host:192.0.34.166 serv:123
type=SYSCALL msg=audit(11/20/2006 16:40:46.169:16) : arch=i386
syscall=socketcall(bind) success=yes exit=0 a0=2 a1=bffff9a0 a2=b80004a8
a3=6 items=0 pid=3523 auid=unknown(4294967295) uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpd
exe=/usr/sbin/ntpd
|
This output shows that each call to bind generated three audit records. The
first record type is the SOCKETCALL record, which shows the number and value of
the arguments passed to bind on entry. The second record type is the SOCKADDR
record, which shows the host by IP address and the port used. The third record
type is the SYSCALL record, which shows whether the call to bind was successful,
the arguments upon exit, gives the process ID, file executed, and shows the
effective and real user and group information of the process that made the call.
For our purposes, we are interested mostly in the serv:
part of the SOCKADDR record, which documents the port used and the
exe= field of the SYSCALL record, which documents the
program that made the call to bind.
Listing 4 contains a simple script using sed and awk to compress the output of
ausearch down to only the non-duplicated (time omitted) executable and port number
fields.
Listing 4. Sample output from auportprint.sh:
[root@localhost hpc]# ./auportprint.sh
22 /usr/sbin/sshd
123 /usr/sbin/ntpd
123 /usr/sbin/ntpdate
631 /usr/sbin/cupsd
|
Conclusion
This article introduced some tools and techniques that can help you maintain your
system's adherence to its security policy. It also gave you some simple scripts to
help parse system data into an easily readable format that can help you prove the
security status of the system quickly and easily to anyone less familiar with the
tools and system. I hope that you can use these simple tools and techniques to
create your own scripts to periodically test the security stance of your systems.
Acknowledgments
Many thanks to Kylene Hall, Dustin Kirkland, Flavio Ivan da Silva, Rodrigo
Rubira Branco, and Flavio C. Buccianti for their code, suggestions, and hard work
on this article.
Download | Description | Name | Size | Download method |
|---|
| Code for Listings 1, 3, and 4 in this article | hpc.zip | 4KB | HTTP |
|---|
Resources Learn
Get products and technologies
-
Order
the SEK for Linux,
a two-DVD set containing the latest IBM trial software for Linux from DB2®,
Lotus®, Rational®, Tivoli®, and WebSphere®.
- With
IBM
trial software,
available for download directly from developerWorks, build your next development
project on Linux.
Discuss
About the author | | | Emily Ratliff works in the IBM Linux Technology Center on Linux security.
She has worked on multiple Common Criteria evaluations, Trusted Computing, Kerberos, and Enterprise Identity Mapping, among other projects.
Emily's ultimate goal is to protect her unattended workstation from her toddler's random (and surprisingly successful) attacks. |
Rate this page
| |
