2951 Security 5

Securing Linux Systems for the Enterprise

a Jupiterweb Security eBook ™

Securing Linux Systems for the Enterprise he Linux operating system is a cornerstone of most modern enterprise computing environments. The power, flexibility, and stability of enterprise-focused Linux distributions such as Red Hat, SUSE, and Ubuntu are well known and respected. Unfortunately, the flexibility and power of Linux has a downside -- the fact that Linux systems can support most known network protocols and services can leave them open to attack unless correctly configured and deployed.

T

The dependence of modern business on Web-based interaction and Internet-oriented applications and execution environments puts increasing demands on networking infrastructure. High-volume data requirements and new network services mean that more devices and data must always be available on the network, 24x7. This constant availability is a modern business fundamental that, unfortunately, isn't limited to authorized users. Those same systems are now always available for attacks from online intruders and other malicious users. Modern computer systems must export an increasingly wide network profile, but only that profile. Most enterprise Linux distributions are delivered with most network ports and services disabled, so that services must be turned on rather than off. Regardless, double-checking some standard aspects of the network and general security configuration of your systems can substantially increase system security and will certainly increase your comfort level with the safety and security of the systems on your network. Note One of the problems with providing general security suggestions that apply to multiple Linux distributions is that different Linux distributions provide different administrative tools. This guide focuses on command-line tools that can be found, or are at least available for, any Linux distribution.

Identifying Open Network Ports and Associated Daemons Any open network port on your system indicates a potential entry point. In this context, an open network port is a port on which some server is listening for and responding to requests. Two common ways of listing open ports when logged in on a machine are by using the lsof and netstat commands. The lsof (list open files) command lists all open files on a Linux system. Its -i option tells the command to list all IP (Internet protocol) related files, while the -n option suppresses trying to map IP addresses to host names for any established connection. (Avoiding these improves the speed with which results are returned.) We then pipe the output of this command to the egrep command, only selecting results that contain COMMAND (which gives us the headings for the various columns), TCP (a daemon listening using the TCP protocol), and UDP (a daemon that is listening using the UDP protocol). The following is sample output from the lsof command on a Red Hat Enterprise Linux (RHEL) 4 system: # lsof -i -n | egrep 'COMMAND|TCP|UDP' COMMAND PID USER FD TYPE portmap 871 rpc 3u IPv4 portmap 1871 rpc 4u IPv4 rpc.statd 1891 rpcuser 4u IPv4 rpc.statd 1891 rpcuser 5u IPv4 rpc.statd 1891 rpcuser 6u IPv4 sshd 2082 root 3u IPv6 xinetd 2097 root 5u IPv4 xinetd 2097 root 6u IPv4 xinetd 2097 root 8u IPv4 ntpd 2113 ntp 4u IPv4

1

DEVICE 4428 4431 4468 4457 4471 4945 5007 5008 5009 5108

SIZE

NODE UDP TCP UDP UDP TCP TCP TCP TCP TCP UDP

NAME *:sunrpc *:sunrpc (LISTEN) *:32768 *:795 *:32769 (LISTEN) *:ssh (LISTEN) *:auth (LISTEN) *:telnet (LISTEN) *:vnc (LISTEN) *:ntp

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise ntpd ntpd ntpd sendmail cupsd cupsd

2113 2113 2113 2132 3427 3427

ntp ntp ntp root root root

5u 6u 7u 3u 0u 2u

IPv6 IPv4 IPv4 IPv4 IPv4 IPv4

5109 5110 5111 5136 10857 10858

UDP UDP UDP TCP TCP UDP

*:ntp 127.0.0.1:ntp 192.168.6.233:ntp 127.0.0.1:smtp (LISTEN) 127.0.0.1:ipp (LISTEN) *:ipp

This output shows that the daemons running directly on this systems are portmap (RPC port mapper), rpc.statd (RPC status monitoring), sshd (secure shell), ntpd (network time protocol), sendmail (mail server), and cupsd (CUPS print daemon). In addition, the xinetd Internet services daemon is running the auth (remote identification daemon), telnet (network terminal), and vnc (virtual network computing) servers. The netstat (network statistics) command provides very similar output when run on the same system. The -t option produces output for all TCP/IP ports, and the -u option produces output for all UDP ports. The -l option restricts the output to ports that are actively listening for connections. The -p option shows the program and process ID that owns the network connection. The following is sample output from the lsof command on a Red Hat Enterprise Linux (RHEL) 4 system: # netstat -tulp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address tcp 0 0 *:32769 tcp 0 0 *:sunrpc tcp 0 0 *:auth tcp 0 0 *:vnc tcp 0 0 localhost.localdomain:ipp tcp 0 0 *:telnet tcp 0 0 localhost.localdomain:smtp tcp 0 0 *:ssh udp 0 0 *:32768 udp 0 0 *:795 udp 0 0 *:sunrpc udp 0 0 *:ipp udp 0 0 rhel4.vonhagen.org:ntp udp 0 0 localhost.localdomain:ntp udp 0 0 *:ntp udp 0 0 *:ntp

Addr *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:*

State LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN

PID/Program name 1891/rpc.statd 1871/portmap 2097/xinetd 2097/xinetd 3427/cupsd 2097/xinetd 2132/sendmail: acce 2082/sshd 1891/rpc.statd 1891/rpc.statd 1871/portmap 3427/cupsd 2113/ntpd 2113/ntpd 2113/ntpd 2113/ntpd

This list provides a bit more detail, but shows the same open ports and associated services as the lsof command. A machine's internal view of the services that it provides should match those that an outside machine would see. To verify this, you can use the nmap (network mapping) command from another system. The -sT option does a TCP port scan, while the -sU option does a UDP port scan. Scanning the same machine from another system produces output like the following: # nmap -sTU 192.168.6.233 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-07-30 16:42 EDT Interesting ports on rhel4.vonhagen.org (192.168.6.233): (The 3131 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 23/tcp open telnet 111/tcp open rpcbind 2

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise 111/udp open|filtered rpcbind 113/tcp open auth 123/udp open|filtered ntp 631/udp open|filtered unknown 795/udp open|filtered unknown 32768/udp open|filtered omad MAC Address: 00:E0:18:76:C0:B4 (Asustek Computer) Nmap finished: 1 IP address (1 host up) scanned in 1475.249 seconds Though the nmap command can't identify the services associated with ports 631 and 795, the local machine output from the lsof and nmap commands shown previously identifies these as a print daemon and the rpc.statd command, respectively. Given that all of this output agrees, the next step is to analyze the services that are available to determine whether they are all necessary and, if not, what to do about them: • First, the cupsd (print) and sendmail (mail server) daemons shown in the netstat and lsof output not visible in the nmap output. The netstat and lsof output confirms that they are only listening on the local loopback interface, and are therefore not accessible from outside the machine and should not pose a security problem. If performance is an issue for the machine you're analyzing, sendmail is useful for local mail delivery, but you may want to terminate the CUPS daemon if no one will be printing from this machine. • The ssh (secure shell) daemon provides a secure mechanism for remote logins and supports encrypted communication, so that's fine. • The telnet daemon (network terminal) represents an older protocol used to establish remote connections, and typically uses unencrypted communications. Some newer versions of telnet support secure authentication and communication mechanisms such as Kerberos, but regardless, this is an unnecessary service because SSH is also supported, and we should therefore shut this down. • The rpcbind (port mapper) and rpc.statd (port 795) daemons are only useful in NFS environments. If the machine we're analyzing is not an NFS client, these should be shut down. • The auth daemon can be useful in analyzing problems network clients, but can also provide intruders with information about the users of your systems. However, some FTP and other network clients essentially require it. It should either be

3

Assuming you're safe from viruses and other malware just because you are on a non-Windows platform is a big mistake, as the number of Linux-based malware doubled in 2005, according to a report from Kaspersky Labs. In a report titled "2005: *nix Malware Evolution," the Russian antivirus software developer pointed out that the number of Linux-based malicious programs -- viruses, Trojans, back-doors, exploits, and whatnot -- doubled from 422 to 863. Numerically, that pales compared to the 11,000 Kaspersky found for Windows in the second half of 2005 alone. However, it could be more devastating because many non-Windows users assume malware is only a Windows problem and don't take any precautions. Kaspersky said Linux users are careful, but one security expert disagrees. "With Linux users, there's a very vigilant effort to make sure the system is as secure as possible, mostly because Linux people are very aware of security dangers and the security that needs to be put in place," said Shane Coursen, senior technical consultant with Kaspersky's U.S. office in Woburn, Mass. "The other thing is that there are people who have transitioned from Windows to Linux, thinking Linux would provide them more security, and they make sure their new Linux system is secured," he added. But Tom Ferris, researcher with Security Protocols, a computer security research firm in Mission Viejo, Calif., said the opposite. "In people's minds, if it's non-Windows, it's secure, and that's not the case," he said. "They think nobody writes malware for Linux or OS X. But that's not necessarily true, as that report showed." The growth in Linux malware is simply due to its increasing popularity, particularly as a desktop operating system, said Coursen. "The use of an operating system is directly correlated to the interest by the malware writers to develop malware for that OS," he added. The Kaspersky report said that the Unix picture mirrors that on the Win32 front. The biggest problems are exploits and back doors designed to steal information. There are also sniffers, flooders and other hack tools. While rootkits get all the headlines, Coursen said the biggest problems will still be exploits and Trojans. --Andy Patrizio, InternetNews.com

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise disabled or started with its -n option, which causes it to display numeric user IDs rather than user names. • The ntp (network time) daemon is used to synchronize the clock across systems on a network, but has been exploited in the past. We'll replace this daemon with running the ntp -q command once at boot time, which queries and synchronizes with a time service once and then exits. • The omad daemon on port 32768 is initially puzzling, but cross-checking against the lsof and netstat output shows that port 32768 is actually being used for rpc.statd queries, and therefore should be eliminated by shutting down the rpc.statd daemon. This daemon is being misidentified by nmap. The next step in this process is to go to the machine that we're analyzing and determine where and when these daemons are being started, so that we can terminate any we have identified as being extraneous (cupsd, portmap, rpc.statd, telnet, vnc), and modify the behavior of any others (authd, ntpd) whose behavior we want to modify.

Locating Start-Up Scripts Associated with Extraneous Network Services Network daemons are generally started in one of two ways on a modern Linux system -- either as part of the system start-up process or in response to incoming network requests that are detected by a general network services daemon. This section focuses on the former; the latter are discussed in the next section. Right now we're trying to determine where the cupsd, ntpd, portmap, and rpc.statd daemons are being started. Note Red Hat Enterprise Linux systems, such as the one being used as an example in this guide, provide a command (chkconfig) that identifies the run levels at which various services are being started. This guide focuses on more generic, distribution-independent mechanisms for deriving that information. Most modern Linux systems use what is known as the SysVInit mechanism to start different systems at different run levels. A central collection of scripts that start all available system services is stored in the directory /etc/init.d. The services associated with different run levels, typically 0 through 6, are identified in each of the directories /etc/rc0.d through /etc/rc6.d, and are actually started and stopped via symbolic links to the main scripts stored in the /etc/init.d directory. The symbolic links for scripts that start services when a run level is entered begin with the letter 'S' (start), followed by a sequence number that reflects the order in which they are started (in ascending order). The symbolic links for scripts that stop services when a run level is entered begin with the letter 'K' (kill), followed by a sequence number that reflects the order in which they are stopped (in descending order). This mechanism is known as "Sys V Init" because the ancestor of this system start-up approach was first introduced on AT&T System V Unix machines. To locate the scripts that are used to start various services, change to the directory /etc/init.d and list its contents. You will see something like the following: # ls acpid amd anacron apmd arptables_jf arpwatch atd auditd

4

FreeWnn functions gpm haldaemon halt hidd hpoj httpd

mysqld named netdump netdump-server netfs netplugd network NetworkManager

rpcidmapd rpcsvcgssd rstatd rusersd rwhod saslauthd sendmail single

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise autofs bgpd bluetooth bootparamd canna cpuspeed crond cups cups-config-daemon cyrus-imapd dc_client dc_server dhcp6r dhcp6s dhcpd dhcrelay diskdump dovecot dund exim firstboot

iiim innd ip6tables iptables irda irqbalance isdn kadmin killall kprop krb524 krb5kdc kudzu ldap lisa lm_sensors mailman mdmonitor mdmpd messagebus microcode_ctl

nfs nfslock nscd ntpd ospf6d ospfd pand pcmcia portmap postfix postgresql psacct radiusd radvd rawdevices readahead readahead_early rhnsd ripd ripngd rpcgssd

smartd smb snmpd snmptrapd spamassassin squid sshd syslog sysstat tux vncserver vsftpd winbind xfs xinetd ypbind yppasswdd ypserv ypxfrd zebra

Looking through this list, it's easy to spot start-up scripts for services such as cups, ntpd, and portmap, since the names of the start-up scripts are evocative of their associated services. However, it's unclear which script is associated with the rpc.statd daemon. We can use grep to determine this: # grep rpc.statd * nfslock:[ -x /sbin/rpc.statd ] || exit 0 nfslock: daemon rpc.statd "$STATDARG" nfslock: killproc rpc.statd nfslock: status rpc.statd nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?" We therefore need to disable the cups, nfslock, and portmap scripts so that they are not executed when we reboot our system. We will also want to modify the ntpd script so that it executes ntpd differently. A system's default run level, which is a way of referring to the specific collection of scripts and services that it starts when it boots normally, is determined by the line containing the initdefault keyword in the file /etc/inittab. On a RHEL system, this line looks like the following: $ grep ':initdefault:' /etc/inittab id:5:initdefault: Different Linux distributions associate different logical meanings with the run levels 2 through 6, but the mechanism is the same regardless of the services that are started at various run levels. For example, the default run level on a Ubuntu Linux server is run level 2, as shown by the following: $ grep 'initdefault:' /etc/inittab id:2:initdefault: Once you know your system's default run level, you can go to its associated directory and remove the symbolic

5

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise links that are associated with the services that you no longer want to start. In this example, this is the directory /etc/rc5.d, because this sample RHEL system boots tom run level 5 by default. Though these are only symbolic links, it's a good idea to keep track of which services you have manually disabled, to make it easy for other system administrators to see the changes that you have made to a given machine from its default configuration. To simplify this, create a directory called DISABLED and move the symbolic links to this directory, rather than just deleting them. # mkdir DISABLED # ls *nfslock *portmap *cups S13portmap S14nfslock S55cups # mv *nfslock *portmap *cups DISABLED You should repeat this process for other run levels that may start these same services. Here's how you can find a complete list: # cd /etc # find {init,rc}.d -name "*nfslock*" rc.d/init.d/nfslock rc.d/rc0.d/K86nfslock rc.d/rc5.d/K86nfslock rc.d/rc5.d/DISABLED/S14nfslock rc.d/rc2.d/K86nfslock rc.d/rc1.d/K86nfslock rc.d/rc3.d/K86nfslock rc.d/rc5.d/S14nfslock rc.d/rc4.d/K86nfslock rc.d/rc5.d/S14nfslock rc.d/rc6.d/K86nfslock This shows that the nfslock script is also being called at run levels 3 and 4, where you should disable it using the same mechanism. You would then run this same command to identify other run levels at which the cups and portmap scripts were called and disabled those using the same mechanism. If you are using a system such as RHEL that provides a run level configuration tool, you will also want to use that tool to disable the system's notion of what services are associated with various run levels. In this case, you would execute that command to disable the specified service at all run, as in the following example: # chkconfig nfslock off # chkconfig cups off # chkconfig portmap off Other Linux distributions, such as Ubuntu and Debian, provide similar tools such as the BootUp Manager (BUM).

Modifying System Start-up Behavior Note This section uses ntpd, the network time protocol daemon, as an example of a process that you still want to run regularly, but not run continuously, as a daemon, for security reasons. Some networked environments require extremely tight synchronization between all participating systems. In those cases, this specific example may be inappropriate, but still illustrates how to replace a daemon with regularly scheduled processes.

6

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise As mentioned earlier, we want to modify the behavior of the network time protocol daemon, ntpd, so that it only executes a single query when you boot the system rather than running the daemon continuously, and then synchronizes daily thereafter. To do this, we'll either want to modify the /etc/init.d/ntpd script or any associated data files, or change how the system invokes the ntpd daemon. We'll do the latter, which is a bit cleaner. First follow the instructions in the previous section to remove the ntpd command from all run levels. Next, edit the file /etc/rc.local, which is a start-up script that is executed as the last step of the boot process. Add the line /usr/sbin/ntpd -q before the last line of the file so that it looks something like this (it will be different depending on your distribution): #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. /usr/sbin/ntpd -q touch /var/lock/subsys/local Your system will now execute the /usr/sbin/ntpd -q command as essentially the last command in its start-up process each time you reboot this system. Next, we want to make sure that the system runs the same command once a day after it has been booted, so that the system clock never gets too far from the real time. To do this, we'll use the cron command to schedule regular execution of the ntpd -q command, in this example on a daily basis. To do this, execute the crontab -e command to edit the table of command scheduled for regular execution and add the following line to the file: 5 0 * * *

echo `date`: `/usr/sbin/ntpd -q` >> /var/log/cron_ntpd.log

Note: All of the quotes in this example are single back-quotes, which cause the command enclosed between each pair of them to be executed. This entry will execute the /usr/sbin/ntpd -q command at five minutes after midnight every day, and will append an entry to the file /var/log/cron_ntpd.log that consists of a timestamp and the output of this command. We can then monitor this log file to see how much readjustment was necessary and increase the frequency of this command, if necessary. (You can consult the online reference page for the crontab command for more information about the format of a crontab file by executing the command man 5 crontab.)

Disabling xinetd-Based Network Services The lsof and netstat output shown in the first section of this guide identified the auth, telnet, and vnc services as being run by the xinetd Internet services daemon. This daemon is a general-purpose network daemon that waits for incoming requests on selected ports and then starts the services associated with those ports. The xinetd daemon is an enhanced, more secure, and more flexible descendent of a similar daemon (known as inetd) that was used on many earlier Linux and Unix systems. One of the capabilities originally introduced with xinetd are known as TCP wrappers. This is a library that is transparent to the end user but provides system administrators with fine-grained control over the hosts that can (or cannot) access a specific network service and associated daemon. The TCP wrappers library does this by checking the files /etc/hosts.allow and /etc/hosts.deny for any restrictions on the hosts that can access a service before allowing a connection to be established. The TCP wrappers concept has proven to be so useful that most modern Linux distributions compile all network daemons, including standalone daemons such as sshd and NFS daemons such as portmap, with the TCP wrappers library.

7

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise The configuration files for all daemons that are managed by the xinetd daemon are located in the directory /etc/xinetd.d. This directory contains the following files on a sample RHEL system: # ls amanda amandaidx amidxtape auth chargen chargen-udp cups-lpd

daytime daytime-udp dbskkd-cdb echo echo-udp eklogin finger

gssftp klogin krb5-telnet krb5-telnet.rpmsave kshell ktalk ntalk

rexec rlogin rsh rsync swat talk telnet

tftp time time-udp vnc

The files in this directory are text files that contain start-up instructions for each associated service. Each of these files contains an entry that identifies whether the associated service is disabled on the target machine. To doublecheck which of these services are actually enabled, you would execute commands like the following:

# cd /etc/xinetd.d # grep disable * | auth: krb5-telnet: vnc:

grep no disable = no disable = no disable = no

The output will be different on your system, but should look fairly similar. This shows that the auth daemon, a Kerberos-enhanced version of the telnet daemon, and the vnc server are all started in response to incoming requests on the ports that they are associated with. As noted earlier, we want to disable the telnet and vnc servers, and modify the behavior of the auth daemon. This section explains the former; modifying the behavior of the auth daemon is explained in the next section. To disable services so that they are not started by the xinetd, simply edit each file in a text editor and change "no" to "yes" in each disable entry. After doing so, the control file for the auth daemon should be the only file in this directory that will be managed by xinetd after a reboot. # grep disable * | grep no auth: disable = no The next section explains how to modify an xinetd control file so that the command is still executed on-demand, but works differently.

Modifying the Behavior of xinetd-Based Network Services As discussed earlier, we still want to run the auth daemon, but we want to change it so that it returns numeric user identifiers rather than actually exposing the log-in names of the users on our systems. The auth daemon's xinetd control file looks like the following (with comments removed): service auth { disable = no socket_type

8

= stream

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise wait user cps instances server server_args

= = = = = =

no ident 4096 10 UNLIMITED /usr/sbin/in.authd -t60 --xerror --os -E

} In this example, we simply want to add the -n option to the authd command line, which you would do using your favorite text editor, so that the modified file would look something like the following: service auth { disable = no socket_type wait user cps instances server server_args

= stream = no = ident = 4096 10 = UNLIMITED = /usr/sbin/in.authd = -n -t60 --xerror --os -E

} After saving this file, the next time that the xinetd is restarted, authd requests will no longer return and display user names, but will return and display numeric user identifiers instead. The same functionality will still be present, but less information about your system will be exposed over the network.

Verifying Changes in Network Services After making changes to your system's start-up process and available services, the best test is to reboot the system and then examine it using the same commands that we used earlier to explore its capabilities. After rebooting the system, the lsof command displays the following information: # lsof -i COMMAND sshd xinetd sendmail

-n | egrep 'COMMAND|TCP|UDP' PID USER FD TYPE DEVICE 2040 root 3u IPv6 4808 2055 root 5u IPv4 4950 2074 root 3u IPv4 4914

SIZE

NODE TCP TCP TCP

NAME *:ssh (LISTEN) *:auth (LISTEN) 127.0.0.1:smtp (LISTEN)

Now that's more like it: a lean, mean, networked machine. To verify how remote systems see this example host, probing the system from another machine using nmap confirms that a much more limited set of services are now available to other machines: # nmap -sTU 192.168.6.233 Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-07-31 01:31 EDT Interesting ports on rhel4.vonhagen.org (192.168.6.233): (The 3139 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 113/tcp open auth MAC Address: 00:E0:18:76:C0:B4 (Asustek Computer) Nmap finished: 1 IP address (1 host up) scanned in 1462.945 seconds

9

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.

Securing Linux Systems for the Enterprise This verifies that the sample system is much less exposed to the network. Reducing the number of available services on a given system also has the fringe benefit of returning the amount of memory required by those services to the pool that is available to the system itself.

Summary The biggest step that you can make towards ensuring the security of a networked system is to reduce the number of open ports and associated services that the system makes available over the network. This guide provided a number of examples of how to eliminate extraneous services that are started as part of the system start-up process and which are managed by other daemons on a machine, such as the xinetd. This guide was written by Bill von Hagen. Copyright 2006, Jupitermedia Corp.

JupiterWeb eBooks bring together the best in technical information, ideas and coverage of important IT trends that help technology professionals build their knowledge and shape the future of their IT organizations. For more information and resources on IT security, visit any of our category-leading sites: www.esecurityplanet.com www.antionline.com www.internetnews.com/security www.earthwebnews.com/security www.enterpriseitplanet.com/security www.insideid.com www.smallbusinesscomputing.com www.linuxtoday.com/security/ For the latest live and on-demand Webcasts on IT security, visit: www.jupiterwebcasts.com/security

10

Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.