Firewall Forensics

The underlying objective of a forensic analysis is trying to determine what happened and to establish facts that can be used in court.
Nội dung trích xuất từ tài liệu:
Firewall ForensicsFirewall ForensicsOdds are, you will need to conduct a forensics analysis using your firewall logs at somepoint. The underlying objective of a forensic analysis is trying to determine whathappened and to establish facts that can be used in court. If you have never reviewed thefirewall logs previously, this can be a costly and almost insurmountable process becauseyou do not necessarily have any idea what may or may not be a normal event for thefirewall.Performing a forensic analysis is generally an extremely time-consuming and expensiveprocess because in many cases it is much like trying to find a needle in the haystack. Youmay 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 youneed to gather evidence from the earliest moment possible to establish exactly whattranspired.Because of the potentially sensitive nature of forensic analysis, it is a good idea to usetools that can assist in performing the forensics analysis or to bring in experts who havespecial training in exactly what should and should not be done. This is where tools likeNetIQ Security Manager and Cisco CS-MARS come in particularly handy, because theyinclude built-in correlation, query, and reporting functionality that is particularly suited tothis kind of situation. For example, Figure 12-4 illustrates a forensic analysis report fromNetIQ 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 concernedabout. However, by looking at the data (for example the data in Figure 12-4) with a bitmore of a critical eye, the traffic is all originating from the same source (10.1.1.200) tothe same destination (10.1.1.2) on a whole slew of different port numbers. This is aclassic example of a reconnaissance attack; the attacker is running a port scan in anattempt to determine which ports are open and thereby gain information about the kindsof 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 customizingtheir attack to determine with certainty that yes indeed a web server is running. Thisinformation can then be used to determine the methods of attack that may be successfulagainst the targeted host.The Value (or Not) of IP AddressesOne pitfall to keep in mind when you review your firewall logs is that just because thelogs report that a certain IP address attempted to connect, that does not necessarily meanthat 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 aresult is a trivial process, which is a frequent misconception regarding IP addressspoofing. Although it is easy to spoof an IP address, it is not easy to pull off an attackwhile spoofing addresses. Think of it like this, if the attacker needs to get someinformation as a part of the attack, and he is spoofing his IP address, the information isgoing to be sent to the spoofed IP addresswhich means that in general it is not going tothe attacker. Figure 12-5 illustrates how attackers may spoof their IP address. Figure 12-5. How Spoofing WorksIn the example in Figure 12-5, the attacker builds packets with a source IP address of209.165.201.1 (the IP address of the innocent victim) to transmit to the firewall. Whenthe firewall receives the data, it logs the packets as coming from 209.165.201.1 becausethat is what the source IP address of the packet is. In reality, the packet came from theattacker, but the firewall has no way of knowing that. In fact, if the firewall needs torespond to any of the traffic that it received, it will actually attempt to connect to theinnocent victim, which could well cause alerts to be generated by the folks who monitorand manage that computer. This is also a good reason it is a bad idea (and in many casesis illegal) to launch retributive strikes against systems that you think may be attackingyour systems. If that were to occur in this case, you have gone from being the good guyto attacking someone who was not even involved in the security incident.Where spoofing is particularly effective, however, is when the attacker does notnecessarily need a response to the data that he sent (for example, when trying to flood thefirewall with bogus data), such as when performing attacks that are based onconnectionless protocols such as UDP and ICMP. For example, if an attacker attempts tospoof 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 innocentvictim will send a TCP reset because it is not aware of the connection in question. This isone of the reasons that spoofing using TCP (or any connection-oriented protocol) isdifficult to successfully pull off.The bottom line when it comes to the IP addresses that are logged is that after you havewhat you suspect is the IP address of the system that was involved in the securityincident, you still need to perform a more detailed investigation to ensure that the IPaddress in question was really involved, and that the attacker was not spoofing his IPaddress in an attempt to mask his trail. One method of identifying this is TCP resets fromthe innocent victim in your firewall logs.Deciphering Port NumbersLike IP addresses, port numbers are not an absolute guarantee of what application orservice may have been running. For example, many applications can run on any port thatis configured, allowing things such as peer-to-peer file sharing to use a port suc ...