What would the inbound ACL look like on your router's serial interface connected to the Internet if you decided to block RFC 1918 addresses, the bogons listed in this chapter, and RFC 2827 filtering, assuming your local IP range is 96.0.20.0/24?

access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip 0.0.0.0 0.255.255.255 any
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 169.254.0.0 0.0.255.255 any
access-list 101 deny ip 192.0.2.0 0.0.0.255 any
access-list 101 deny ip 198.18.0.0 0.1.255.255 any
access-list 101 deny ip 224.0.0.0 15.255.255.255 any
access-list 101 deny ip 240.0.0.0 15.255.255.255 any
access-list 101 deny ip 96.0.20.0 0.0.0.255 any
access-list 101 permit ip any 96.0.20.0 0.0.0.255

When evaluating the SYN flood protections required for a server, when might you use SYN cookies and when might you use TCP Intercept?

Because security protections are best employed as close to the host as possible, SYN cookies should be preferred in most situations. Use TCP Intercept for systems that do not support SYN cookies. Although it is true that implementing security controls in a central location (such as a firewall) generally offers greater scalability, in this case the feature doesn't require ongoing management by the OS support team and must only be enabled once on the system. Even then, SYN cookies are used only when the incoming SYN queue fills up, meaning the system is likely under attack.

What is the most important step when you are trying to get help from your ISP to stop a DDoS attack?

Before backscatter, CAR, black hole routing, or any other security control can be implemented, it is critical to have a policy in place with your SP that defines how it will react when you are under attack.

When might it not be necessary to implement L2 security features on your network?

The most common reason to not implement L2 security is when you have a security policy that relies on strong physical security controls and a trust of internal users. Even in these cases, though, it probably makes sense to implement the nonintrusive security features to protect against accidental attacks from your trusted users. Oftentimes, it is a trusted user who makes a mistake that causes a network failure (security or otherwise).

Should the average user worry about van Eck phreaking?

No, because an attacker willing to finance the expense to go after data by using van Eck phreaking is likely to be very determined and very well funded. You should hope never to be the target of such an attacker because there are many avenues of attack available to such an adversary. Most of these avenues of attack don't involve direct network attack but rather social engineering or coercion.

When should you use uRPF as compared to traditional ACL filtering?

Different network platforms have different capabilities. The first question to answer is: which technology has the least performance impact on a system? The second consideration is whether uRPF can take care of all the filtering needs of your system. For example, in the Internet edge, bogon filtering is still probably required, which mandates the use of an ACL. Within a campus network, uRPF is easy to implement and very effective. At the Internet edge, with all other considerations equal, I would default to using ACLs.

Is it worth implementing Rob Thomas's entire bogon-filtering range on your Internet edge?

This falls back to an operations issue. If ACLs on your gateway device do not carry a significant performance penalty and you have the staff to ensure the bogon ranges stay current, by all means implement the filtering, which filters out some of the noise, especially if implemented by your ISP. Remember, though, that savvy attackers are beginning to avoid spoofing ranges that haven't yet been allocated, rendering bogon filtering meaningless for these attacks.