Analyzing Host-Based Firewall and IDS Logs

So far, we have discussed performing analysis on logs from network firewalls and routers. These devices are monitoring connections to and from many different hosts. Now let's turn our attention to host-based firewalls and intrusion detection systems, which also record suspicious network activity, but only involve a single host. Such systems are most often installed on workstations. They are discussed in Chapter 10, "Host Defense Components."

Host-based firewall and IDS software often records activity that is otherwise unnoticed by network devices. For example, a firewall that only logs denied or rejected traffic won't keep a record of a connection that it permits to an internal host. In such a case, the internal host is the only device that might record the activity if it is using a firewall and/or IDS that is configured to reject and log such an attempt. Also, in many environments, few restrictions are placed on connections between hosts on the internal network; host-based network logs might be the only way that some malicious activity between internal hosts is recorded.

ZoneAlarm

The format of ZoneAlarm logs is easy to understand. By default, ZoneAlarm records all its information in a comma-separated value format in a text file called ZAlog.txt. (ZoneAlarm can also generate tab- and semicolon-separated log files.) Following are sample log entries for blocked TCP, UDP, and ICMP activity, respectively:

 FWIN,2004/11/28,03:47:43 -6:00 GMT,172.30.128.23:15384,10.20.84.167:80,TCP (flags:S) FWIN,2004/11/28,03:57:46 -6:00 GMT,172.30.128.23:3283,10.20.84.167:3283,UDP FWIN,2004/11/28,04:06:30 -6:00 GMT,172.30.128.23:0,10.20.84.167:0,ICMP (type:8/subtype:0) 

By now, this format should be pretty easy for you to decipher. The first address and port number are for the source; the second pair is for the destination. The FWIN label indicates that the firewall blocked traffic in the entry and that it was incoming. Lines that begin with FWOUT indicate that outgoing traffic was blocked. Finally, lines that start with PE indicate that the ZoneAlarm user has permitted a particular application's traffic to pass through the firewall.

Although you don't see much detailed information in each entry, remember that these entries are being recorded on a particular host. If ZoneAlarm is being run on a user's workstation, odds are good that the workstation offers few or no services and that there are only a few ports on which it might legitimately be contacted. ZoneAlarm should be configured to permit those connections and to reject and record any other incoming connection attempts, which are almost certainly caused by misconfigured or unauthorized equipment or software, mistakes such as a typo in an address, or malicious activity.

Each ZoneAlarm log by itself can contain valuable information. These logs become much more useful when they are gathered together from many different hosts. If most or all of your workstations are using host-based firewalls and you can monitor all of their firewall logs, you can get a great picture of what suspicious activities are occurring within your network. Check Point, the manufacturer of ZoneAlarm, sells a product called Integrity (http://www.checkpoint.com/products/integrity/) that facilitates centralized logging and has other features that are extremely helpful to analysts. There are also free utilities available for performing intrusion analysis and report generation with ZoneAlarm log data; examples include VisualZone (http://www.visualizesoftware.com/) and ZoneLog Analyser (http://zonelog.co.uk/).

Here's an interesting entry from a ZoneAlarm log:

 FWIN,2004/12/01,22:30:51 -5:00 GMT,172.30.128.198:22,10.20.84.94:22,TCP (flags:SF) 

You can see that this blocked connection was intended to target TCP port 22 on host 10.20.84.94. SSH usually utilizes this port, so this looks like an attempt to find or use an SSH server. Can you tell whether this is a benign or malicious activity?

There are two telltale signs in this log entry. The more obvious one is that the SYN and FIN flags are both set, which is a classic sign of malicious activity. The less obvious one is that the source port is also set to 22. In a normal SSH connection, you should see a high source port and destination port 22. Because the source port is also set to 22, this is almost certainly crafted traffic that is malicious in nature. Just through this single log entry, you can determine that an attacker is hoping to exploit SSH vulnerabilities on this host.

Norton Personal Firewall

Norton Personal Firewall records information similar to ZoneAlarm. However, like several other personal firewalls, Norton Personal Firewall does not automatically log to a text file. Instead, it provides a GUI log viewer that displays events and permits administrators to export logs to text files. The text files have a simple comma-separated format: date, user, message, and details. The log excerpt shown next is easy to understand without additional explanation. It records an attempt to connect to port 27374 on the local workstation, which is not an available port on this host:

[View full width]
 12/4/2004 4:02:26 PM,Supervisor,"Rule ""Default Block Backdoor/SubSeven Trojan horse""  blocked (172.30.128.23,27374).", "Rule ""Default Block Backdoor/SubSeven Trojan horse""  blocked (172.30.128.101,27374).  Inbound TCP connection Local address,service is (MYSYSTEM (172.30.128.23),27374) Remote address,service is (172.30.128.101,1380) Process name is ""N/A""" 

Here's a great example of a potential incident that has been recorded in a Norton Personal Firewall log. Take a few minutes to review these entries and to get as much information about the incident from them as you can:

[View full width]
 12/4/2004 4:13:50 PM,Supervisor,Unused port blocking has blocked communications.,"Unused  port blocking has blocked communications. Inbound TCP connection   Remote address,local  service is (172.30.128.101,http-proxy(8080))" 12/4/2004 4:13:50 PM,Supervisor,Unused port blocking has blocked communications.,"Unused  port blocking has blocked communications. Inbound TCP connection   Remote address,local  service is (172.30.128.101,http(80))" 12/4/2004 4:13:50 PM,Supervisor,Unused port blocking has blocked communications.,"Unused  port blocking has blocked communications. Inbound TCP connection   Remote address,local  service is (172.30.128.101,3128)" 12/4/2004 4:13:50 PM,Supervisor,Unused port blocking has blocked communications.,"Unused  port blocking has blocked communications. Inbound TCP connection   Remote address,local  service is (172.30.128.101,socks(1080))" 

Are you finished with your review? Let's take another look at the log entries to see what they're trying to tell us. Here are the key pieces of information and their significance:

• All four log entries show the same source IP address. If you saw one attempt from the source address, it could be an accident; however, four separate attempts are much more likely to be malicious activity than an accident.

• All four connection attempts occurred within the same second. This indicates that the activity was almost certainly automated or scripted. It also gives you more proof that this activity is purposeful, not accidental.

• The destination ports8080, 80, 3128, and 1080might not all look familiar to you. Fortunately, Norton Personal Firewall tries to assist your analysis by listing the name of the service typically found at each common port. The three identified services are all web related, and a quick check of any good ports list shows that the fourth port, 3128, is also often used for web-related services.

Based on these three points, it appears that this log has recorded a scan by a single host for web-related services. If the source address is external, you might want to consider restricting incoming traffic to block such attempts in the future, only permitting incoming traffic on the necessary ports to those hosts that are authorized to provide web services to external hosts. It's also likely that other hosts on your network were scanned; therefore, correlating this activity by checking your other network log files for similar events is highly recommended.

Initially, most host-based firewalls had minimal IDS capabilities, if any. Host-based firewalls logged blocked connections, but they didn't do any analysis of the activity that they saw, and couldn't determine the likely intent of a connection attempt or packet. As host-based firewalls have evolved, they have incorporated basic intrusion detection principles to attempt to identify the intent of apparently unwanted connection attempts.

The IDS capabilities of host-based firewalls can save you time when you perform an analysis. For example, by listing the service most often associated with a certain port, host-based firewalls reduce the need to look up port numbers. The text descriptions that explain why the event was logged also facilitate easy searching and log automation. From an analysis standpoint, it's definitely advantageous to have intrusion detection capability built in to host-based firewalls.