Agreeing on definitions for network layer responses is as useful as agreeing on definitions for network layer attacks. Because such responses should not involve information that resides at the transport layer or above, we are limited to the manipulation of network layer headers in one of three ways:
A filtering operation conducted by a device such as a firewall or router to block the source IP address of an attacker
Reconfiguration of a routing protocol to deny the ability of an attacker to route packets to an intended target by means of route blackholing—packets are sent into the void and are never heard from again
Applying thresholding logic to the amount of traffic that is allowed to pass through a firewall or router based on utilized bandwidth
A response that is purely at the network layer can be used to combat an attack that is detected at the application layer, but such a response should not involve things like generating a TCP RST packet for example—this would be a transport layer response, as we'll see in Chapter 3.
After an attack is detected from a particular IP address, you can use the following iptables rules as a network layer response that falls into the filtering category. These rules are added to the INPUT, OUTPUT, and FORWARD chains; they block all communications (regardless of protocol or ports) to or from the IP address 144.202.X.X:
[iptablesfw]# iptables -I INPUT 1 -s 144.202.X.X-j DROP [iptablesfw]# iptables -I OUTPUT 1 -d 144.202.X.X-j DROP [iptablesfw]# iptables -I FORWARD 1 -s 144.202.X.X-j DROP [iptablesfw]# iptables -I FORWARD 1 -d 144.202.X.X-j DROP
There are two rules in the FORWARD chain to block packets that originate from 144.202.X.X (-s 144.202.X.X) as well as responses from internal systems that are destined for 144.202.X.X (-d 144.202.X.X). If you use iptables as your network sentry, then the above rules provide an effective network choke point against the 144.202.X.X address.
Applying thresholding logic to iptables targets is accomplished with the iptables limit extension. For example, the limit extension can be used within an ACCEPT rule to limit the number of packets accepted from a specific source address within a given window of time. The following iptables rules restrict the policy to only accept 10 packets per second to or from the 144.202.X.X IP address.
[iptablesfw]# iptables -I INPUT 1-m limit--limit 10/sec-s 144.202.X.X-j AC CEPT [iptablesfw]# iptables -I INPUT 2 -s 144.202.X.X-j DROP [iptablesfw]# iptables -I OUTPUT 1-m limit --limit 10/sec-d 144.202.X.X-j ACCEPT [iptablesfw]# iptables -I OUTPUT 2 -d 144.202.X.X-j DROP [iptablesfw]# iptables -I FORWARD 1-m limit --limit 10/sec-s 144.202.X.X-j ACCEPT [iptablesfw]# iptables -I FORWARD 2 -s 144.202.X.X-j DROP [iptablesfw]# iptables -I FORWARD 1-m limit --limit 10/sec-d 144.202.X.X-j ACCEPT [iptablesfw]# iptables -I FORWARD 2 -d 144.202.X.X-j DROP
For each ACCEPT rule above that uses the limit match, there is also a corresponding DROP rule. This accounts for packets levels that exceed the 10-per-second maximum permitted by the limit match; once the packet levels are higher than this threshold, they no longer match on the ACCEPT rule and are then compared against the remaining rules in the iptables policy. It is frequently better to just refuse to communicate with an attacker altogether than to allow even thresholded rates of packets through.
You can also use the limit match to place thresholds on the number of iptables log messages that are generated by default logging rules. However, unless disk space is a concern, applying a limit threshold to a LOG rule is not usually necessary, because the kernel uses a ring buffer internally within the LOG target so that log messages are overwritten whenever packets hit a LOG rule faster than they can be written out via syslog.
Responses can be combined across layers, just as attacks can be. For example, a firewall rule could be instantiated against an attacker at the same time that a TCP RST is sent using a combination of tools like fwsnort and psad (see Chapter 11).
One way to knock down a malicious TCP connection would be to use the iptables REJECT target and then instantiate a persistent blocking rule against the source address of the attack. The persistent blocking rule is the network layer response, which prevents any further communication from the attacker's current IP address with the target of the initial attack.
Although this may sound effective, note that a blocking rule in a firewall can frequently be circumvented by an attacker routing attacks over the The Onion Router (Tor) network.[20] By sending an attack over Tor, the source address of the attack is not predictable by the target.
The same is true for attacks where the source IP address is spoofed by the attacker. Spoofed attacks do not require bidirectional communication, and so it is risky to respond to them; doing so essentially gives control to the attacker over who gets blocked in your firewall! It is unlikely that all important IP addresses (such as DNS servers, upstream routers, remote VPN tunnel terminations, and so on) are whitelisted in your firewall policy, and so giving this control to an attacker is risky. Some of the suspicious traffic examples earlier in this chapter, such as spoofed UDP strings, packets with low TTL values, and Nmap ICMP Echo Requests, are perfect examples of traffic that it is not a good idea to actively respond to.
As we will see in later chapters, there are only a few classes of traffic that are best met with automated responses.
[20] 10 Tor anonymizes network communications by sending packets through a cloud of nodes called onion routers in an encrypted and randomized fashion. Tor only supports TCP, so it cannot be used to anonymize attacks over other protocols such as UDP.