Security - Systems

1. Security - Systems • Design Considerations

2. Layer 2 Design • L2 Control protocols - 802.1q, STP and ARP • 802.1q • for Ethernet switches to exchange VLAN info • Primary Issues: VLAN hopping • Spanning Tree Protocol • for L2 loop avoidance • Primary Issues: No authentication on bridge PDUs • Attacks: Cause link failure; pretend to be root of tree. • Defense: Control participation in STP (switch level)

3. Layer 2 Design • ARP • for MAC <-- IP mapping • Primary Issues: gARP messages for high availability • Defense: VLANs, static ARP entries • DHCP • for IP allocation • Issues: MAC Spoofing, rogue DHCP server • allow/deny for specific ports to respond to DHCP requests

4. Layer 2 Design • Wireless Networks – Medium Access • Boundary is diffused (not hard) • Intruders do not have to intercept wires – all messages are broadcast (in a shared medium) • Unauthenticated access modes may cause problems • Contention resolution – Fairness issues • Easy to limit / eliminate availability

5. IP Addressing Design • Subnetting • Administrative / Physical separation • Primary Issues: Access Control • Defense: VLANs, Level 3 ACLs (Access Control Lists)

6. Ingress / Egress Filtering • Private address traffic not seen outside. • Incoming traffic only from outside world • Filtering at edge or close to edge - not necessarily only at the firewall.

7. NAT • Private addresses translated to public addresses • Incoming traffic - reverse translation • static, 1-1, many-1 • avoid using NAT (many-1) for security

8. ICMP Design Issues • ping messages • essential for admin. - turning off is not a solution except in specific cases. • Primary issue - Echo request/reply messages - variable length data field • ping-of-death attacks, DoS attacks, buffer overflows • covert channels (w/ software on host) • Solutions: “Explicitly permit - implicitly deny” • Permit ICMP echo request/reply messages w/ networks of necessity and for required users • Deny all other echo messages

9. ICMP - Design Issues • Other required ICMP messages • (some types of ) Destination Unreachable messages • TTL 0 messages needed by traceroute • lCMP filtering • ACLs for permitting specific messages (seen above) and for denying all others

10. Routing - Issues • Possible attacks: • Traffic Redirection • Traffic sent to a black-hole • Router DoS (Denial of Service) - Attack on Availability • Routing protocol DoS • Unauthorized router prefix origination

11. Routing - Issues • Attack methods & possible solutions: • Configuration modification of routers • Secure routers - Device Hardening • Rogue Router Introduction • Add message authentication to routing protocol • Use ACLs to block routing protocol message types from unwanted networks • Spoofing / Modifying of routing messages • Message authentication; TCP seq. #s help; • Sending malformed or excess packets • DoS mitigation for excess; no easy soln. for malformed packets

12. Router - Device hardening • Disable Unneeded Services • No DNS lookup for router • no echo or fingering services • no bootp service (if not needed) • no source routing and directed broadcast • no ICMP redirects • Password Encryption • Authentication • Use hashed passwords • Use secure protocols (say SSH) for line access • Setup usernames and access controls

13. Routing Protocol - Message Auth. • Passwords with routing update messages • MD5 digest authentication with secret keying • Protocol Specific: • Avoid RIP v1. - has no auth. mechanism • OSPF (widely userd for interior gateways) - supports keyed MD5 • BGP (widely used for cross-domain routing) - supports keyed MD5 through TCP option

14. Routing - Issues • Asymmetric Routing & State-Aware Security • Asymetric traffic - different paths for request and return; per packet routing • Can happen at switches, over the Internet or at ISP. • Causes problems for state-aware security devices and mechanisms - Firewalls, IDS etc.

15. Routing - Issues • Asymmetric Routing - Solutions • Use Symmetric Routing • hard to do and impractical • Load balance per flow (rather than per packet) • cannot avoid request-return asymmetry. • Manipulate flows using NAT or routing • Use state-sharing security devices - e.g exchange info. bet. firewalls • significant traffic overhead • Use stateless security features - e.g. ACLs • works only for easy situations - simple traffic categorizations

16. Transport Protocol - Design Issues • Denial Of Service attacks • easy to launch and cannot be completely stopped. • network flooding (consume bw) vs. transport flooding (consume host resources) • Network Flooding • Detection: thru’ Network Intrusion Detection, routers and firewalls (i.e. their log data) • Stopping: often thru’ Service provider only; stops good as well as bad traffic

17. Transport Protocol - Design Issues • Stopping Network Flooding • Basic ACL: drop all traffic destined for an IP address; configure this throughout the ISP’s network. • Black Hole Filtering: Propagate static routes to divert traffic to a black hole. Faster than basic ACL approach; much less CPU impact. • Sinkhole Routing: Traffic diverted to a specific location so that it can be studied.

18. Transport Protocol - Design Issues • Trace Back (DoS) • Manual ACL trace back : create an ACL with broad permits that are made more specific as more information about attack is gained. • Backscatter Trace back : • combine black hole and sinkhole routing • black hole routing results in ICMP unreachable messages • use a chunk of unallocated IP addresses for internal routing within ISP to forward to a sinkhole. • Tracebacks are useless if the attacker is spoofing a legitimately allocated address.

19. Transport Protocol - Design Issues • DoS Mitigation • QoS techniques - • limit traffic by type (UDP 10 Mbps, ICMP 200Kbps etc.) ;use token system for traffic to limit it; • application specific filtering • (e.g. in ecommerce scenarios UDP traffic is needed) • use a distributed design • content delivery networks

20. Transport Protocol - Design Issues • (back to) Denial Of Service attacks • easy to launch and cannot be completely stopped. • network flooding (consume bw) vs. transport flooding (consume host resources) • Transport Flooding • TCP SYN flooding - use a SYN packet (part of a 3-way handshake) but never respond to the acknowledgment; TCP is connection oriented : connections kept open for a time; connection queues overflow;

21. Transport Protocol - Design Issues • SYN cookies • host specific method of mitigating SYN flooding attacks; • avoid storing SYN packets in queue; use challenge-response model for handshake. • TCP intercept • network-level protection for SYN floods • intercept connection requests at an intermediate node which transparently forwards TCP packets to server; SYN packets are acked ASAP; if client does not respond use a backoff protocol; (e.g PIX firewalls)