recap and overview
play

Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP - PDF document

1/24/2012 Recap and overview Looking at security of TCP/IP IP, Ethernet, ARP TCP/IP: ICMP, UDP Sniffing the network and forging packets tcpdump, wireshark Today: ICMP and UDP Network Security Lecture 5 Eike Ritter Network


  1. 1/24/2012 Recap and overview • Looking at security of TCP/IP – IP, Ethernet, ARP TCP/IP: ICMP, UDP • Sniffing the network and forging packets – tcpdump, wireshark • Today: ICMP and UDP Network Security Lecture 5 Eike Ritter Network Security - Lecture 5 1 Internet Control Message Protocol ICMP message format • Used to exchange control/error messages 0 4 8 12 16 20 24 28 31 Type Code Checksum about the delivery of IP datagrams Data • Encapsulated in IP datagrams • Messages can be • Type : ICMP type • Code : ICMP subtype – Requests • Checksum : Error checking code - Computed on the ICMP header and data (with checksum field set to 0) – Responses – Error messages • RFC 792 Eike Ritter Network Security - Lecture 5 2 Eike Ritter Network Security - Lecture 5 3 ICMP types ICMP types – cont’d • Echo request/reply (type: 8, 0) • Time exceeded (type: 11) – Network connectivity (ping) – Report expired datagrams (TTL = 0) • Destination unreachable (type: 3) • Redirect (type: 5) – Inform host of the impossibility to deliver traffic to a specific destination – Inform hosts of better routes (gateways) – Destination network, host, protocol, port unreachable • Address mask request/reply (type: 17, 18) – Destination network, host unknown – Fragmentation required and DF flag set – Used to obtain network mask at boot time – Source route failed • Source quench (type: 4) – Congestion control Eike Ritter Network Security - Lecture 5 4 Eike Ritter Network Security - Lecture 5 5

  2. 1/24/2012 ICMP Echo request/reply ICMP echo request 0 4 8 12 16 20 24 28 31 Type = 0 or 8 Code = 0 Checksum Identifier Sequence number Optional data Eike Ritter Network Security - Lecture 5 6 Eike Ritter Network Security - Lecture 5 7 ICMP encapsulation ping $ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=52 time=8.16 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=52 time=8.24 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=52 time=8.02 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=52 time=8.02 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=52 time=8.16 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=52 time=8.02 ms --- 192.168.0.1 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 25082ms rtt min/avg/max/mdev = 8.021/8.106/8.245/0.125 ms Eike Ritter Network Security - Lecture 5 8 Eike Ritter Network Security - Lecture 5 9 ICMP echo-based attacks: scanning ICMP echo-based attacks: smurf • Attacker wants to know which hosts in a subnet are up • Broadcast ping message and running – Echo request directed to broadcast address of • Sends a ping message to all possible hosts in that subnet (pingsweep) network • Collects replies from hosts that are alive – All hosts on that subnet respond with echo reply $ nmap -sP 172.16.48.0/24 • Do you see a problem with this scenario? Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 09:48 PST • Consider IP spoofing Host 172.16.48.1 is up (0.0024s latency). Host 172.16.48.2 is up (0.00077s latency). Host 172.16.48.130 is up (0.0065s latency). Host 172.16.48.139 is up (0.00014s latency). Nmap done: 256 IP addresses (4 hosts up) scanned in 2.54 seconds Eike Ritter Network Security - Lecture 5 10 Eike Ritter Network Security - Lecture 5 11

  3. 1/24/2012 ICMP echo-based attacks: smurf ICMP echo-based attacks: smurf • Defenses – Ignore ICMP echo requests destined to the broadcast address 2.2.2.1 2.2.2.2 From: 1.1.1.1 – Linux: 2.2.2.3 To: 2.2.2.2.255 2.2.2.4 $ sysctl net.ipv4.icmp_echo_ignore_broadcasts Attacker: 6.6.6.6 Victim: 1.1.1.1 2.2.2.253 Eike Ritter Network Security - Lecture 5 12 Eike Ritter Network Security - Lecture 5 13 ICMP redirect ICMP redirect (2) Datagram to 1.1.1.42 Gateway: Gateway: 0 4 8 12 16 20 24 28 31 172.16.48.2 172.16.48.1 Type = 5 Code = 0, 1, 2, or 3 Checksum IP Address Destination Gateway (3) ICMP redirect message: 1.1.1.255 172.16.48.2 “use 172.16.48.2 as gateway IP header + First 8 bytes of original datagram to communicate with 1.1.1/24” (1) Datagram to 1.1.1.42 On receiving an ICMP redirect message, host checks that: • The new gateway must be directly reachable (same subnet) • The redirect must be from the current gateway for the destination Host: 172.16.48.100 • The redirect cannot tell the host to act as the new gateway Destination Gateway Flags • The route that is added must be indirect 0.0.0.0 172.16.48.1 UG (4) 1.1.1.255 172.16.48.2 UGHD Eike Ritter Network Security - Lecture 5 14 Eike Ritter Network Security - Lecture 5 15 ICMP redirect-based attacks ICMP redirect attack • ICMP redirect can be abused to re-route Address Hwaddress Role 172.16.48.1 00:50:56:00:00:01 Gateway 172.16.48.2 00:50:56:00:00:02 Linux host traffic to specific router or to a specific host 172.16.48.100 00:50:56:00:00:64 Windows host – Hijack traffic C:\windows\system32> route print -4 IPv4 Route Table – Denial-of-service attack ============================================================================ Active Routes: Network Destination Netmask Gateway Interface Metric • How? 0.0.0.0 0.0.0.0 172.16.48.1 172.16.48.100 11 172.16.48.0 255.255.255.0 On-link 172.16.48.100 266 • The attacks works by sending a spoofed ICMP 172.16.48.100 255.255.255.255 On-link 172.16.48.100 266 172.16.48.255 255.255.255.255 On-link 172.16.48.100 266 redirect message that appears to come from ============================================================================ the host’s default gateway # tcpdump –n 00:50:56:00:00:02 > 00:50:56:00:00:64, IP 172.16.48.1 > 172.16.48.100: ICMP redirect 128.111.48.6 to host 172.16.48.2, length 68 Eike Ritter Network Security - Lecture 5 16 Eike Ritter Network Security - Lecture 5 17

  4. 1/24/2012 ICMP redirect attack – cont’d ICMP destination unreachable • Used by gateway to inform host that destination C:\Windows\system32> route print -4 IPv4 Route Table is unreachable ============================================================================ Active Routes: • Different subtypes Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 172.16.48.1 172.16.48.100 11 128.111.48.6 255.255.255.255 172.16.48.2 172.16.48.100 10 – Network unreachable 172.16.48.0 255.255.255.0 On-link 172.16.48.100 266 – Host unreachable 172.16.48.100 255.255.255.255 On-link 172.16.48.100 266 172.16.48.255 255.255.255.255 On-link 172.16.48.100 266 – Protocol unreachable ============================================================================ – Port unreachable C:\Windows\system32> ping 128.111.48.6 00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP – Fragmentation needed and DF flag set echo request 00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP – Destination host unknown echo request – Destination network unknown Eike Ritter Network Security - Lecture 5 18 Eike Ritter Network Security - Lecture 5 19 ICMP unreachable attack ICMP time exceeded 0 4 8 12 16 20 24 28 31 From 172.16.48.1 Gateway: To: 172.16.48.100 Type = 11 Code = 0 or 1 Checksum 172.16.48.1 Destination unreachable Unused IP header + First 8 bytes of original datagram • Sent when Attacker: Victim: 172.16.48.101 172.16.48.100 – TTL becomes 0 (code: 0) – The reassembling of a fragment times out (code: 1) Eike Ritter Network Security - Lecture 5 20 Eike Ritter Network Security - Lecture 5 21 traceroute traceroute – cont’d $ traceroute www.google.co.uk • Use ICMP time exceeded messages to traceroute to www.google.co.uk (173.194.37.104), 30 hops max, 40 byte pkts 1 rita-rw (147.188.193.6) 1.115 ms 1.087 ms 1.082 ms determine the path used to deliver a 2 bes (10.0.9.1) 0.322 ms 0.315 ms 0.299 ms 3 hscn-gw (147.188.199.1) 0.633 ms 0.621 ms 0.609 ms datagram 4 cs-ac00b7e1-2.bham.ac.uk (147.188.121.129) 0.937 ms 0.933 ms 0.923 ms 5 cs-lb00b1e5-8b2e5-8.bham.ac.uk (147.188.120.13) 0.893 ms 0.884 ms • A series of IP datagrams are sent to the 0.875 ms 6 fw-sr00.bham.ac.uk (147.188.121.234) 0.865 ms 1.044 ms 1.043 ms destination 7 147.188.121.245 (147.188.121.245) 1.747 ms 1.788 ms 1.775 ms 8 193.63.208.21 (193.63.208.21) 1.764 ms 0.980 ms 3.367 ms 9 so-1-0-0.warr-sbr1.ja.net (146.97.42.189) 3.314 ms 3.660 ms 3.649 ms • Each datagram has an increasing TTL field 10 so-5-1-0.read-sbr1.ja.net (146.97.33.89) 7.324 ms 7.311 ms 7.655 ms value (start value: 1) 11 as0.lond-sbr3.ja.net (146.97.33.166) 9.121 ms 9.108 ms 9.453 ms 12 po1.lond-ban3.ja.net (146.97.35.106) 9.443 ms 9.788 ms 9.775 ms 13 google.lond-ban3.ja.net (193.62.157.30) 70.751 ms 71.101 ms 71.088 ms • Router decrements TTL; if it is 0, sends back a 14 209.85.255.175 (209.85.255.175) 8.066 ms 8.271 ms 209.85.252.76 (209.85.252.76) 8.321 ms ICMP unreachable message 15 209.85.251.58 (209.85.251.58) 9.036 ms 9.385 ms 209.85.251.202 (209.85.251.202) 9.382 ms • Useful for network analysis and debugging 16 lhr14s02-in-f104.1e100.net (173.194.37.104) 8.994 ms 9.342 ms 9.336 ms Eike Ritter Network Security - Lecture 5 22 Eike Ritter Network Security - Lecture 5 23

Recommend


More recommend