Hands-On Network Security: Practical Tools & Methods Security - PowerPoint PPT Presentation

Hands-On Network Security: Practical Tools & Methods Security Training Course Dr. Charles J. Antonelli The University of Michigan 2012

Hands-On Network Security Module 3 Network Protocol Attacks

Roadmap • Network security  The basic objectives: CIA  Vulnerabilities and defenses for layers 1 - 4 04/12 cja 2012 3

Some notes • Focus on IPv4 and Ethernet  IP is the dominant network protocol  IPv6 not yet widely deployed  Ethernet is ubiquitous • The basic principles apply to other protocols and other media  As always, the devil is in the details… 04/12 cja 2012 4

You are here… • Network security  The basic objectives: CIA  Vulnerabilities and defenses for layers 1 - 4 04/12 cja 2012 5

Network Security: CIA • Confidentiality  No eavesdropping  No mis-directed traffic • Integrity  What’s received = What’s sent • Availability  The network should never go down  Networks should always be fast enough 04/12 cja 2012 6

Availability: Layer 0 • Never forget the physical environment  Fire  Lightning  Flood  Power failures  Backhoe events  Vandalism  HVAC failure  Etc… 04/12 cja 2012 7

You are here… • Network security  The basic objectives: CIA  Vulnerabilities and defenses for layers 1 - 4 04/12 cja 2012 8

Layer 1 CIA issues • Confidentiality I  RF is almost always interceptable  Ex: the Pringles can antenna (Instructions)  Ex: 60 GHz point-to-point radio  Copper is sometimes tappable  Difficulty increases with frequency (to a point)  Equipment isn’t a commodity item  Fiber is hard to tap  Essentially no leakage radiation 04/12 cja 2012 9

Layer 1 CIA issues • Confidentiality II  Electronics are the weak spot  Hubs simply rebroadcast what comes in  Many switches have an “ eavesdrop ” mode  Some switches have “ remote eavesdrop ” mode  Administrative access to equipment must be controlled  Physical access to equipment must be controlled 04/12 cja 2012 10

Layer 1 CIA issues • Integrity  RF is subject to fading and interference  High noise => high BER (bit error rate)  Ex: AA to DBRN microwave link  Ex: RFID jamming (Instructions)  Cables are usually reliable but…  Attenuation leads to low S/N => high BER  Bad termination leads to reflections  Vendors usually get the electronics right 04/12 cja 2012 11

Layer 1 CIA issues • Availability  Same issues as “ Layer 0 ”  Acts of [malevolent] deities  Acts of malevolent people  Acts of the merely ignorant… 04/12 cja 2012 12

Example: Rogue CCS server • We detected a DDoS attack against a central campus CCS address • CCS had no machine at that IP address • ARP data gave us a MAC address • Switch in the Union said MAC address was in West Quad • Switch in West Quad said MAC address was in the Union 04/12 cja 2012 13

Example: Rogue CCS server • On further investigation, we found:  New switch in comm closet in West Quad  Patched into fiber between Union and WQ  Rack-mounted server connected to the switch  Many GB of Warez, photos of unclad persons, music, movies, etc.  Examination of traffic logs found that it had been in service for ca. 6 months  The good news: no sniffer was running (we think…) 04/12 cja 2012 14

Layer 2 vulnerabilities • Broadcast storms • ARP/CAM lifetime mismatch • ARP spoofing/Gateway spoofing • MAC spoofing/CAM flooding • VLAN hopping • Spanning Tree attacks • DHCP attacks 04/12 cja 2012 15

Broadcast storms • A loop in a LAN can be created accidentally or deliberately • Broadcast messages travel around the loop at wire speed • => Entire LAN is flooded with broadcasts • Solutions:  Spanning tree to eliminate loops 04/12 cja 2012 16

ARP/CAM lifetime mismatch • High-volume UDP stream inbound to valid IP • Target goes off-line but source keeps sending • Switch CAM table times out in 5 minutes, router ’ s ARP cache times out in 4 hours • => Switch floods traffic out all ports • Solutions:  Adjust CAM lifetime to match ARP (everywhere!)  Reduce ARP lifetime to match CAM  Can cause high router CPU load from excessive ARPing 04/12 cja 2012 17

ARP/gateway spoofing • Good guy ARPs for default gateway • Bad guy replies faster than router • Bad guy sends gratuitous ARP to router • => Good guy ’ s external traffic all passes through Bad guy ’ s machine • Solutions:  Static ARP and ARP monitoring  “ Private VLANs ” (maybe) 04/12 cja 2012 18

MAC spoofing/CAM flooding • Bad guy floods net with random bogus source MAC addresses (uni- or broadcast) • Switch CAM tables fill up and overflow • => All traffic gets flooded out all ports • Solutions:  Static CAM entries (sometimes)  Switch “ port security ” & broadcast control  SNMP trap on CAM overflow 04/12 cja 2012 19

VLAN hopping I • Frames on trunks have 802.1q VLAN tags • Switches strip tags on incoming frames • Bad guy pretends to be switch and sets up trunking to his machine • => Bad guy has access to all VLANs • Solutions:  Turn off dynamic trunking protocol  Limit trunks to required VLANs only 04/12 cja 2012 20

VLAN hopping II • Bad guy generates frames with multiple 802.1q headers (multiple encapsulation) • Switch only strips one header on ingress • => Bad guy can send to another VLAN • Solutions:  This only works if trunk “ native ” VLAN is a user VLAN, so use a dedicated native VLAN. 04/12 cja 2012 21

Spanning tree attacks I • Bad guy sends lots of BPDU ’ s • => Switches keep recalculating, no traffic gets through • This also DoS ’ s the bad guy, unless he runs the attack remotely… 04/12 cja 2012 22

Spanning tree attacks II • Bad guy sends BPDU with priority 0 • Switches make bad guy the root, or • Bad guy ’ s switch becomes the root • => Bad guy has access to VLAN traffic • => Traffic flow may be non-optimal (DoS) • Solutions:  Shut down access ports with incoming root BPDUs 04/12 cja 2012 23

DHCP attacks • Bad guy floods net with DHCP requests • => DHCP server runs out of addresses • Bad guy runs rogue DHCP server • => Users get bogus addresses, or • => Users use Bad guy as default gateway 04/12 cja 2012 24

Layer 3/4 vulnerabilities • IP spoofing • Ping of Death and other buffer overflows • Smurfing • Zombies & Bots • ICMP/UDP flooding • TCP SYN flooding • Random target scans • Routing table attacks 04/12 cja 2012 25

IP Spoofing • Source address of IP traffic may not be the “ real ” address of the sender  Some machine do have multiple addresses… • Often used with other forms of attack to mask the true location of the attacker • Local spoofing mitigated by router ingress ACLs on all LANs and/or RPF checks • Remote spoofing can be hard to stop… 04/12 cja 2012 26

Packets of Death, etc. • Cisco IOS crashes when ICMP packets are received with certain options set • Solaris crashes when SMTP traffic arrives with a multicast source IP address • Other buffer overflows can push random info (or crafted code) on CPU stack  Modern buffer overflows usually designed to cause compromise rather than death 04/12 cja 2012 27

Smurfing • Send traffic to LAN directed broadcast address (with spoofed source address) • => All machines on LAN reply to the target • Solution:  Turn off directed-broadcast forwarding  Newer exploit - Use a bot to send local broadcasts with a spoofed source address 04/12 cja 2012 28

DNS Multiplication • Build bogus domain with large TXT records • Send requests with spoofed source address to DNS servers with open recursion turned on • All servers reply to the target; large records => fragmentation => hard to filter • Solution:  Fix everyone else ’ s DNS servers…  Turn off open recursion 04/12 cja 2012 29

Zombies and Bots • Use worms/viruses to install remote control software in many machines  Typically communicating via rendezvous  Commands may be embedded in ICMP, etc. • Add a few layers of indirection between the controller and the distribution medium • Result: millions of machines waiting to be told who, how and when to attack. • More on this later … 04/12 cja 2012 30

ICMP/UDP Flooding • Bombard the target with a one-way stream • Can be a single source • Can be multiple sources • Can be run from a bot net • Often use fragmented packets  Harder to filter as frags have no port info • Solution:  Monitor traffic for high-volume flows 04/12 cja 2012 31

TCP SYN flooding • TCP ’ s three-way handshake:  A: SYN -> B (I ’ d like to talk)  B: SYN-ACK -> A (I ’ m willing to talk)  A: ACK -> B (OK, let ’ s talk!) • TCP half-ack:  A: SYN -> B (I ’ d like to talk)  B: SYN-ACK -> A (I ’ m willing to talk)  A: [silence] (Are we talking?) • Solution  Limit # buffers in half-open state 04/12 cja 2012 32