CSA Internals
| CSA is unique in the way it stops attacks against hosts and servers. Many prevention technologies use anomaly-type detection or attack signatures, both of which can be subverted by a knowledgeable attacker. Anomaly detection can be circumvented by launching an attack that uses only normal valid data packets. Signatures can be circumvented by using a variation of known attacks. A simplistic example that does not represent a real-world way to circumvent Nimda is where a signature for Nimda might be looking for a string that has the string "NIMDA" in the payload. An attacker can easily change that string to add null characters between the text letters, with the result "N00I00M00D00A00". The attack packet no longer has the string "NIMDA" and could now possibly be a successful attack. CSA doesn't look for signatures and it doesn't do anomaly detection. CSA looks for behavior on a device that indicates that it could be under attack. For example, code injected onto a buffer after a buffer overflow and then executed is always going to be bad behavior. CSA will stop this behavior or kill the process before it can execute the code. CSA in ActionThe CSA has three engines that work together to protect a device against a malicious attack. These engines all use default or custom rules to stop bad behavior on a processor. These rules are flexible and easy to change with a Java-based GUI management console. The three parts of CSA are as follows:
These engines are implemented in two software modules that run on a protected device. One module runs on top of the operating system kernel; the other runs on the network stack. The module that runs on top of the kernel can recognize actions important to the behavior engine and the application engine. The module that runs on the network stack recognizes actions that are important to the firewall engine. Behavior EngineThe behavior-based engine looks for generalized bad behavior on the processor from applications that might exhibit the following:
Any of these actions could indicate an attack in process on a device; however, it is important to note that just because an application might be performing one of these actions, it doesn't mean an attack is definitely happening. CSA "talks" to the other engines and correlates their events to determine whether an attack is actually in process. Application EngineThe application engine recognizes bad behavior of a certain application and stops that application if it violates its behavioral rules. For example, it is known that a web browser should have the following behaviors:
We know that a web browser should not have the following behaviors:
If CSA detects an application performing an action that violates its application rules, it correlates with the other three engines and determines whether an attack is in process. If CSA decides that an attack is in fact occurring, it stops the behavior or the process, effectively mitigating the attack. Firewall EngineThe firewall engine is similar to many personal firewalls in the sense that it filters only wanted traffic. However, it also has the advantage of being able to share information with the behavior and application engines to determine whether an attack is really in progress. NOTE Correlation has been brought up many times in this chapter. Correlation is one of the many strengths of CSA and a key to a successful host intrusion prevention solution. With endpoint prevention, you need to ensure that you stop a process only if an attack is definitely occurring. Effective correlation is the key to making sure that processes are not being stopped unnecessarily. The firewall engine watches the behavior of both inbound and outbound network traffic and takes appropriate action if bad behavior is detected. On the inbound side, it blocks or rate limits unwanted traffic. On the outbound side, it stops traffic or kills a process that starts to send unsolicited or invalid network traffic. One of the features of the firewall engine is a function called Net Shield. Net Shield can mitigate the probe portion of an attack. As mentioned previously in this chapter, the first part of an attack on a host or server is a probe to determine the operating system, open ports, and applications running on a network device. Net Shield can fool probing applications into thinking they are communicating with a Linux box when the target of the probe might actually be a machine running the Windows operating system. Like almost all functions in CSA, this feature is implemented as a rule and can be turned on or off by the system administrator. CSA ArchitectureThe CSA architecture consists of two separate parts:
Another valuable part of the CSA Management Console is that it looks at data that has been collected and can create rules on-the-fly that might help stop attacks. For example, each agent reports to the Management Console if he has been pinged or probed. If the Management Console determines that a ping has come from the same machines several times, it can put that device into a quarantine list and disallow all traffic from that device until there has been a chance to determine whether the traffic is valid. With this, as well as all rules within CSA, the rules can be modified or turned off. For example, if you have a management workstation or a load balancer that needs to do ping sweeps as part of its job, you can let CSA know and it will not take action against those hosts. NOTE If the CSA agent is not connected to the Management Console, as the situation would be if a user took his laptop home, CSA would still protect the laptop using the last downloaded policy. CSA Attack MitigationThe number of attacks that CSA can mitigate with the three behavior-based rule engines and the Management Console are endless. When you look closely at the attack paradigm examined earlier in the chapter, you will see that all phases of an attack are mitigated by at least one of the CSA behavior-based rules engines. Note that because of the way CSA works, if an attack did indeed circumvent part of the CSA defense, the attack would be stopped in the next phase of the attack. For example, CSA stopped a worm called Korgo when it tried to execute code off of an overflowed buffer. If CSA didn't stop Korgo at that point, Table 9-2 lists how many ways it would have been stopped by the CSA. This list is derived in the lab by the following procedure:
Table 10-3 takes a practical look at how CSA stops attacks. Using the attack paradigm discussed previously in this chapter, this table maps the CSA engine (or rule type) that stops the malicious behavior. With this breadth and flexibility of mitigating attacks based on behavior, a combination of CSA and antivirus software has been reported to have stopped all known zero-day attacks from infecting PCs. NOTE Some of these attack actions have "not applicable" (n/a) under the mitigation engine. This designation appears because that the action cannot be stopped because the action being done is a user trying to guess passwords. In these cases, operating systems have built-in preventive measures that limit the number of times someone can incorrectly enter a password (see Table 10-3). If hackers gain access through guessing, CSA could still stop them when they try to run malicious code.
|
EAN: 2147483647
Pages: 120