Analyzing Network Firewall Logs

Dozens of different network firewall solutions are available, each with a unique logging format. Some such devices log little information about trafficapproximately the same information that most routers log. Other firewalls are capable of recording a great deal of detail about the traffic they monitor. As you will see in the examples that follow, the variety in the amount of information logged has a large impact on how deeply you can analyze incidents and suspicious activity. We have chosen to review the log formats of some of the firewalls that were discussed in Chapter 3, "Stateful Firewalls": the Cisco PIX, Check Point FireWall-1, and IPTables.

Cisco PIX Logs

The Cisco PIX firewall logs events of interest in the following format:

[View full width]

Jan 28 03:10:04 [] %PIX-2-106001: Inbound TCP connection denied from 172.30.128 .12/1938 to flags SYN on interface outside

Take a moment to compare the format of this entry with that of the Cisco routers. Although the two have some similarities, they are different in certain ways as well. Whereas the Cisco router logs simply refer to the rule number that caused the entry to be logged, the Cisco PIX provides a detailed text-based explanation as to why this traffic was recorded. Also, note that the Cisco PIX records the TCP flags in its log entry, but the Cisco router does not. Because you're already familiar with the Cisco router log format, the rest of the Cisco PIX log format should be self-explanatory.

Let's practice log analysis a little more formally by examining the Cisco PIX log entry excerpt. What can be determined about the nature of this event based solely on the log entry? Of course, you know what date and time the event occurred. You can see which of your hosts was the target of the event and what the IP address of the potential attacker is. You know which firewall logged the activity, which might be helpful in determining why the traffic was blocked because you can examine that particular firewall's rule set. In addition, the log shows that the traffic was blocked trying to enter the firewall from an external interface. All this information helps you investigate the event and correlate it with logs on other devices.

One of the reasons that correlation is so important is that it's difficult to determine the nature of this event based on just this log entry. You can see that the blocked connection attempt had a destination of TCP port 53, which is typically associated with DNS traffic. Attackers often target TCP port 53 to get information from DNS servers or to attack vulnerabilities in those servers. However, there's not enough data here to make that assumption; a misconfiguration or another benign reason could cause this activity. By correlating this log entry with other logsparticularly a network intrusion detection sensor that saw this attemptyou can make a better determination as to the significance of this event.

Check Point FireWall-1 Logs

Check Point's FireWall-1 is another popular network firewall product. Check Point has a utility called SmartView Tracker that can be used to review logs from several security products, including FireWall-1. SmartView Tracker provides a GUI interface that displays the log entries in a table format. Some of the fields included in FireWall-1 log entries are listed next:

  • The log entry number

  • The date

  • The time

  • The interface that saw the activity

  • The device that saw this activity

  • The type of log entry

  • The action that was performed (such as "block")

  • The destination port number or service name

  • The source IP address or hostname

  • The destination IP address or hostname

  • The protocol of the logged packet (such as "udp")

  • The rule in the firewall's rule base that is associated with the log entry

  • The source port number or service name

  • Additional information that might be applicable to the log entry

You might look at the order of these fields and think that it's rather peculiar. Most devices list the source IP address and port together and then the destination IP address and port together; the FireWall-1 format is quite different. However, there's a good reason for this. Think of what information you, as a log analyst, are typically most interested in. You want to know what the target was; that is listed in the destination address and port, which in most cases will correspond to a particular protocol, such as HTTP or DNS. From an analyst's point of view, it makes a great deal of sense to pair the action with the destination service because they are often related. The source port, which is often not a factor when analyzing traffic, is not listed with the more pertinent data. Although this arrangement might be confusing at first, at least now you understand why it might be done that way.

IPTables Logs

In Chapter 3, we discussed IPTables. As you will see, IPTables logs more comprehensively than the other firewalls reviewed in this section:

[View full width]

Jan 28 03:09:31 mybox kernel: Packet log: IN=ppp0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx :xx:xx:xx:xx SRC= DST= LEN=80 TOS=0x00 PREC=0x00 TTL=55 ID=13492 PROTO=UDP SPT=1907 DPT=27374 LEN=60

Here's a quick interpretation of the fields in this log entry: date, time, IPTables hostname, Syslog level, incoming and outgoing interfaces, MAC addresses, source IP address, destination IP address, packet length (LEN), type of service (TOS), TOS precedence (PREC), time to live (TTL), IP identification number (ID), IP protocol, source port, destination port, and IP payload length (LEN). You may have noticed that the outgoing interface value is blank; this indicates that the packet was received locally.

Not only does IPTables log all the information that the Cisco PIX and Check Point FireWall-1 do, but it also logs several other fields that are helpful in performing advanced log analysis. If you are highly experienced with network intrusion detection, you probably already know how valuable this data can be when identifying the nature of an attack, as well as the characteristics of the attacker.

    Inside Network Perimeter Security
    Inside Network Perimeter Security (2nd Edition)
    ISBN: 0672327376
    EAN: 2147483647
    Year: 2005
    Pages: 230

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: