Encryption and Filtering– Cisco Security Tools
Stateful and contextual packet filtering rely on information within packets to protect servers and applications, but what if the packets in a stream are encrypted? Encryption prevents middleboxes, including firewalls, from effectively seeing the information needed to filter based on state.
One solution to this problem is to include a proxy function on the firewall. Suppose the firewall acts as a man-in-the middle, unencrypting and encrypting traffic as it travels between the client and server. If the firewall acts as a man-in-the-middle, the firewall will have enough information to filter traffic effectively.
Another solution is to place the firewall between the end of the encrypted tunnel and the application. Application firewalls generally receive traffic after the host’s network stack has unencrypted it but before the application.
As operators and users encrypt larger amounts of traffic, engineers must move toward proxies and application firewalls to continue providing effective security.
Source Address Validation
Chapter 19 describes reflection attacks, where attackers reflect traffic off servers toward a victim. Figure 20-7 illustrates.
Figure 20-7 Reflection Attack
In Figure 20-7, router C receives a valid traffic flow from host A, trying to get to a web server on E. However, an attacker uses host B to reflect traffic through server D as part of a reflection attack against E.
Ideally, router C would be able to block the attack traffic while allowing the valid traffic, but how can C tell the difference between the two?
One difference is A sends packets from its actual IP address, while B sends packets from server E’s source address. In fact, the source of B’s attack traffic is not even in the same subnet as router C’s connection to B. In other words, C’s path to the packet’s source—the reverse path—is not through the interface where it received the packet.
Unicast reverse-path forwarding (uRPF) discards any packet where the reverse path, or the path to the source address, does not match the forwarding interface—the interface through which the router would forward a packet to reach the source address.
Defense in Depth
Systems, including networks, should never have one line of defense. Attackers should always pass through multiple lines of defense to reach their objective. Figure 20-8 illustrates the concept of defense in depth.
Figure 20-8 Defense in Depth
Defense in depth forces an attacker to move through multiple defensive lines or systems to reach their objective.
Figure 20-8 shows these multiple lines of defense as multiple fortified walls. Each line of defense should have a different set of vulnerabilities, if possible.
As an example, imagine an organization has an application with access to sensitive information about its employees. The defenses around this application might include the following:
• The application’s servers are on a separate virtual network topology.
• Users must log in to the organization’s network using 2FA before accessing the application’s website (the website is available only to internal users).
• Users do not get an application account unless they need to.
• Users must log in to the application separately using 2FA.
• Users’ actions are logged while they are using the service.
These layers of defenses, each with vulnerabilities and controls, make it much harder for an attacker to access sensitive information.