|< Day Day Up >|
Chapter 8. Analysis and Management Tools
The tools discussed so far give you a lot of useful information to help you fix your network security problems. But the problem with these wonderful programs is that they can sometimes generate too much information. A single Nessus scan of a sizable network can generate a report that is hundreds of pages long. An active Snort sensor can output thousands of alerts a day. Even the lowly firewall might send out log notices on an hourly basis. Keeping track of all of this security information can be a full-time job. In fact, at larger companies, it often requires a small staff just to track and analyze the security data.
With all the data these tools generate, you can go from being uninformed to information overload very easily. This can be worse than being in the dark regarding your security situation. System administrators can suffer from "analysis paralysis"—feeling like they don't know where to start. For many overwhelmed technical managers, the solution is to do nothing at all, or to put the security issues on the back burner until they have time to deal with them. Of course, that time never seems to come.
To avoid this situation, you need tools to help organize your security data and prioritize the action items. Many commercial packages assist in this task, including HP OpenView, BMC NetPatrol, and NetIQ. Fortunately for the budget-impaired, there are also some great open source packages available.
While these open source applications are not strictly security tools in that they are not actively polling or protecting machines on your network, they are every bit as important as your network scanners and intrusion detection systems. Because if you can't see the forest for the trees, you are no better off than you were before.
One example of the challenges in analyzing security data is the server message logs. Most servers, UNIX and Windows alike, maintain logs on various activities going on in the system. Most of this activity is innocuous, like services starting up, user access, and so on. Linux, for example, keeps the system logs in the /var/log directory. Usually, there are two general logs—syslog and messages— along with several other more specific logs. These text files show you all the things going on in the background of the system. Listing 8.1 shows the typical contents of a Linux messages file.
Listing 8.1. Linux Messages File
Aug 17 04:02:06 earth syslogd 1.4.1: restart. Aug 18 21:07:57 earth sshd(pam_unix): session opened for user john by (uid=502) Aug 18 21:12:39 earth su(pam_unix): session opened for user root by john(uid=502) Aug 18 21:12:52 earth su(pam_unix): session closed for user root Aug 18 21:13:44 earth sshd(pam_unix): session opened for user john by (uid=502) Aug 18 21:14:02 earth sshd(pam_unix): session closed for user john Aug 18 21:23:21 earth su(pam_unix): session opened for user root by john(uid=502) Aug 18 21:24:12 earth su(pam_unix): session closed for user root Aug 18 21:39:00 earth su(pam_unix): session opened for user root by john(uid=502) Aug 18 21:44:57 earth httpd: httpd shutdown succeeded Aug 18 21:44:58 earth httpd: httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName Aug 18 21:45:00 earth httpd: httpd startup succeeded Aug 19 23:39:02 earth sshd(pam_unix): authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=tayhou-tnt-9-216-40-228-250.isp.net user=john Aug 22 10:31:14 earth sshd(pam_unix): session opened for user tony by (uid=500) Aug 22 10:31:20 earth su(pam_unix): session opened for user root by tony(uid=500)
These messages are useful for debugging your system or troubleshooting a new program installation. You can see the details for each program or process that starts on your system. You can also see if there are any problems. In this example, you can see that the httpd process, the Web server, shut down. The next line says the problem is with the domain name set for the server. In this case, an IP address has been set incorrectly as the host name.
Log files also contain information that is of interest from a security standpoint. Certain activities are often the precursor of an attack in progress. Failed login attempts can be one of these signs. In Listing 8.1 you can see the user "john" had a failed login. It even tells where John was trying to log in from—an address owned by Isp.net. If it was just a single failed attempt and you knew John used Isp.net, then you would probably not worry about this entry. It was probably just John mistyping his password. However, if you saw multiple failed logins or this one was coming from an unfamiliar address, you would want to check into it further. Another sign of something going wrong is servers rebooting themselves at strange times. These are some of the things that can show up in logs files that would warrant your attention.
In an ideal world, you would review all your log files on a daily basis. Unfortunately, most of us don't have time to do this even weekly, if at all. There is just too much information in these files to easily be able to find the data that's important to us. Wouldn't it be great if there was a helper program that looked for these kinds of things and let us know when they came up, so we could react in a timely manner, rather than a few days or a week later? Well, as it happens, there is an open source program that does just that.
Swatch stands for Simple watcher or Syslog watcher, depending on whom you ask. Either way, Swatch is a helpful program that does your log watching and alerts you only when things that you are specifically looking for get logged. Swatch is a Perl program that regularly sweeps the main log files and looks for certain key words that you can define. It can be run in the background as a daemon or as a cron job. You can configure Swatch to notify you of any events in the messages or syslog log files that might indicate a security problem. However, Swatch can also be used to flag just about any kind of activity: a certain program being used, a certain user logging in, or anything that might appear in a log file. Swatch can also be configured to watch application-specific log files instead of the general log files that it does by default.
Returning to the security uses of Swatch, certain events that are logged have significance from a security standpoint. The default items that Swatch looks for are a good start.
Here are some other security-specific things that you might want to have Swatch look for.
Note: By default, Swatch is configured to look for terms specific to the Sun operating system. While some of these may be common to Linux and other UNIX-based operating systems, others are not. For example, when looking for a reboot on a Mandrake Linux system, you will want to replace the search terms Sun OS Release with Linux Mandrake Release. If you are using a different OS, use the term from your OS reboot message. To find this, do a reboot and then look in the messages file for a unique statement to search for.
|< Day Day Up >|