Firewall Forensics
Odds are, you will need to conduct a forensics analysis using your firewall logs at some
point. The underlying objective of a forensic analysis is trying to determine what
happened and to establish facts that can be used in court. If you have never reviewed the
firewall logs previously, this can be a costly and almost insurmountable process because
you do not necessarily have any idea what may or may not be a normal event for the
firewall.
Performing a forensic analysis is generally an extremely time-consuming and expensive
process because in many cases it is much like trying to find a needle in the haystack. You
may know what was done, but you do not know necessarily when or how it was done,
which can make it tricky indeed to be successful. This is compounded by the fact that you
need to gather evidence from the earliest moment possible to establish exactly what
transpired.
Because of the potentially sensitive nature of forensic analysis, it is a good idea to use
tools that can assist in performing the forensics analysis or to bring in experts who have
special training in exactly what should and should not be done. This is where tools like
N
etIQ Security Manager and Cisco CS-MARS come in particularly handy, because they
include built-in correlation, query, and reporting functionality that is particularly suited to
this kind of situation. For example, Figure 12-4 illustrates a forensic analysis report from
N
etIQ Security Manager.
Figure 12-4. NetIQ Security Manager Forensic Analysis Report
[View full size image]
On the surface, the firewall denying traffic is not necessarily something to be concerned
about. However, by looking at the data (for example the data in Figure 12-4) with a bit
more of a critical eye, the traffic is all originating from the same source (10.1.1.200) to
the same destination (10.1.1.2) on a whole slew of different port numbers. This is a
classic example of a reconnaissance attack; the attacker is running a port scan in an
attempt to determine which ports are open and thereby gain information about the kinds
of applications that may be running on those ports. For example, if TCP port 80 is open,
it is safe bet that a web server is running on that port, and attackers can begin customizing
their attack to determine with certainty that yes indeed a web server is running. This
information can then be used to determine the methods of attack that may be successful
against the targeted host.
The Value (or Not) of IP Addresses
One pitfall to keep in mind when you review your firewall logs is that just because the
logs report that a certain IP address attempted to connect, that does not necessarily mean
that IP address was indeed responsible. IP addresses can be spoofed relatively easily.
That is not to say that spoofing addresses and actually doing something malicious as a
result is a trivial process, which is a frequent misconception regarding IP address
spoofing. Although it is easy to spoof an IP address, it is not easy to pull off an attack
while spoofing addresses. Think of it like this, if the attacker needs to get some
information as a part of the attack, and he is spoofing his IP address, the information is
going to be sent to the spoofed IP addresswhich means that in general it is not going to
the attacker. Figure 12-5 illustrates how attackers may spoof their IP address.
Figure 12-5. How Spoofing Works
In the example in Figure 12-5, the attacker builds packets with a source IP address of
209.165.201.1 (the IP address of the innocent victim) to transmit to the firewall. When
the firewall receives the data, it logs the packets as coming from 209.165.201.1 because
that is what the source IP address of the packet is. In reality, the packet came from the
attacker, but the firewall has no way of knowing that. In fact, if the firewall needs to
respond to any of the traffic that it received, it will actually attempt to connect to the
innocent victim, which could well cause alerts to be generated by the folks who monitor
and manage that computer. This is also a good reason it is a bad idea (and in many cases
is illegal) to launch retributive strikes against systems that you think may be attacking
your systems. If that were to occur in this case, you have gone from being the good guy
to attacking someone who was not even involved in the security incident.
Where spoofing is particularly effective, however, is when the attacker does not
necessarily need a response to the data that he sent (for example, when trying to flood the
firewall with bogus data), such as when performing attacks that are based on
connectionless protocols such as UDP and ICMP. For example, if an attacker attempts to
spoof using TCP and is not blocking traffic between the firewall and the innocent victim,
when the innocent victim receives a packet based on the spoofed connection, the innocent
victim will send a TCP reset because it is not aware of the connection in question. This is
one of the reasons that spoofing using TCP (or any connection-oriented protocol) is
difficult to successfully pull off.
The bottom line when it comes to the IP addresses that are logged is that after you have
what you suspect is the IP address of the system that was involved in the security
incident, you still need to perform a more detailed investigation to ensure that the IP
address in question was really involved, and that the attacker was not spoofing his IP
address in an attempt to mask his trail. One method of identifying this is TCP resets from
the innocent victim in your firewall logs.
Deciphering Port Numbers
Like IP addresses, port numbers are not an absolute guarantee of what application or
service may have been running. For example, many applications can run on any port that
is configured, allowing things such as peer-to-peer file sharing to use a port such as TCP
port 80 for communications, which will frequently allow the application to bypass most
packet filtering firewalls (but not necessarily application proxy or application-aware
inspection) because TCP port 80 is frequently permitted through the firewall.
The lists of default TCP and UDP port numbers, IP protocol numbers, and ICMP
message types are managed by the Internet Assigned Numbers Authority (IANA) and can
be accessed as follows:
• TCP and UDP port numbers
http://www.iana.org/assignments/port-numbers
• IP protocols
http://www.iana.org/assignments/protocol-numbers
• ICMP message types
http://www.iana.org/assignments/icmp-parameters
Again, although you will need to do additional verification to ensure that the ports logged
are actually running the applications and services that are claimed, these lists provide at
least an initial starting point from which to begin the investigation.
Securing the Firewall
An important result of performing a forensic analysis is to use that information to
determine what needs to be done in the future to secure the firewall. As you identify what
transpired and how the incident occurred, use that information to identify flaws in both
the written security policy of the organization as well as the actual firewall policy and
ruleset. For example, if an attacker was able to compromise a resource on a DMZ
segment and then use that resource to gain access to the firewall, that is probably a good
indication that access to the firewall from that resource (or from the entire DMZ for that
matter) should probably not be permitted.