1:

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?

A1:
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
 
2:

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

A2:

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.

3:

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

A3:

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.

4:

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

A4:

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).

5:

Should the average user worry about van Eck phreaking?

A5:

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.

6:

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

A6:

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.

7:

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

A7:

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.

Part I. Network Security Foundations

Network Security Axioms

Security Policy and Operations Life Cycle

Secure Networking Threats

Network Security Technologies

Part II. Designing Secure Networks

Device Hardening

General Design Considerations

Network Security Platform Options and Best Deployment Practices

Common Application Design Considerations

Identity Design Considerations

IPsec VPN Design Considerations

Supporting-Technology Design Considerations

Designing Your Security System

Part III. Secure Network Designs

Edge Security Design

Campus Security Design

Teleworker Security Design

Part IV. Network Management, Case Studies, and Conclusions

Secure Network Management and Network Security Management

Case Studies

Conclusions

References

Appendix A. Glossary of Terms

Appendix B. Answers to Applied Knowledge Questions

Appendix C. Sample Security Policies

INFOSEC Acceptable Use Policy

Password Policy

Guidelines on Antivirus Process

Index



Network Security Architectures
Network Security Architectures
ISBN: 158705115X
EAN: 2147483647
Year: 2006
Pages: 249
Authors: Sean Convery

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net