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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend