Firewall Fundamentals
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 NetIQ 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 NetIQ Security Manager. Figure 12-4. NetIQ Security Manager Forensic Analysis Report
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:
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. |
Категории