tcp ip icmp udp
play

TCP/IP: ICMP, UDP Network Security Lecture 5 Recap and overview - PowerPoint PPT Presentation

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


  1. TCP/IP: ICMP, UDP Network Security Lecture 5

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

  3. Internet Control Message Protocol • Used to exchange control/error messages about the delivery of IP datagrams • Encapsulated in IP datagrams • Messages can be – Requests – Responses – Error messages • RFC 792 Eike Ritter Network Security - Lecture 5 2

  4. ICMP message format 0 4 8 12 16 20 24 28 31 Type Code Checksum Data • Type : ICMP type • Code : ICMP subtype • Checksum : Error checking code - Computed on the ICMP header and data (with checksum field set to 0) Eike Ritter Network Security - Lecture 5 3

  5. ICMP types • Echo request/reply (type: 8, 0) – Network connectivity (ping) • Destination unreachable (type: 3) – Inform host of the impossibility to deliver traffic to a specific destination – Destination network, host, protocol, port unreachable – Destination network, host unknown – Fragmentation required and DF flag set – Source route failed • Source quench (type: 4) – Congestion control Eike Ritter Network Security - Lecture 5 4

  6. ICMP types – cont’d • Time exceeded (type: 11) – Report expired datagrams (TTL = 0) • Redirect (type: 5) – Inform hosts of better routes (gateways) • Address mask request/reply (type: 17, 18) – Used to obtain network mask at boot time Eike Ritter Network Security - Lecture 5 5

  7. ICMP Echo request/reply 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

  8. ICMP echo request Eike Ritter Network Security - Lecture 5 7

  9. ICMP encapsulation Eike Ritter Network Security - Lecture 5 8

  10. 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 9

  11. ICMP echo-based attacks: scanning • Attacker wants to know which hosts in a subnet are up and running • Sends a ping message to all possible hosts in that subnet (pingsweep) • Collects replies from hosts that are alive $ nmap -sP 172.16.48.0/24 Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 09:48 PST 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

  12. ICMP echo-based attacks: smurf • Broadcast ping message – Echo request directed to broadcast address of network – All hosts on that subnet respond with echo reply • Do you see a problem with this scenario? • Consider IP spoofing Eike Ritter Network Security - Lecture 5 11

  13. ICMP echo-based attacks: smurf 2.2.2.1 2.2.2.2 From: 1.1.1.1 2.2.2.3 2.2.2.4 To: 2.2.2.2.255 Attacker: 6.6.6.6 Victim: 1.1.1.1 2.2.2.253 Eike Ritter Network Security - Lecture 5 12

  14. ICMP echo-based attacks: smurf • Defenses – Ignore ICMP echo requests destined to the broadcast address – Linux: $ sysctl net.ipv4.icmp_echo_ignore_broadcasts Eike Ritter Network Security - Lecture 5 13

  15. ICMP redirect (2) Datagram to 1.1.1.42 Gateway: Gateway: 172.16.48.2 172.16.48.1 Destination Gateway (3) ICMP redirect message: 1.1.1.255 172.16.48.2 “use 172.16.48.2 as gateway to communicate with 1.1.1/24” (1) Datagram to 1.1.1.42 Host: 172.16.48.100 Destination Gateway Flags 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

  16. ICMP redirect 0 4 8 12 16 20 24 28 31 Type = 5 Code = 0, 1, 2, or 3 Checksum IP Address IP header + First 8 bytes of original datagram 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 • The redirect cannot tell the host to act as the new gateway • The route that is added must be indirect Eike Ritter Network Security - Lecture 5 15

  17. ICMP redirect-based attacks • ICMP redirect can be abused to re-route traffic to specific router or to a specific host – Hijack traffic – Denial-of-service attack • How? • The attacks works by sending a spoofed ICMP redirect message that appears to come from the host’s default gateway Eike Ritter Network Security - Lecture 5 16

  18. ICMP redirect attack 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 172.16.48.100 00:50:56:00:00:64 Windows host C:\windows\system32> route print -4 IPv4 Route Table ============================================================================ Active Routes: Network Destination Netmask Gateway Interface Metric 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 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 ============================================================================ # 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 17

  19. ICMP redirect attack – cont’d C:\Windows\system32> route print -4 IPv4 Route Table ============================================================================ Active Routes: 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 172.16.48.0 255.255.255.0 On-link 172.16.48.100 266 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 ============================================================================ 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 echo request 00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request Eike Ritter Network Security - Lecture 5 18

  20. ICMP destination unreachable • Used by gateway to inform host that destination is unreachable • Different subtypes – Network unreachable – Host unreachable – Protocol unreachable – Port unreachable – Fragmentation needed and DF flag set – Destination host unknown – Destination network unknown Eike Ritter Network Security - Lecture 5 19

  21. ICMP unreachable attack From 172.16.48.1 Gateway: To: 172.16.48.100 172.16.48.1 Destination unreachable Attacker: Victim: 172.16.48.101 172.16.48.100 Eike Ritter Network Security - Lecture 5 20

  22. ICMP time exceeded 0 4 8 12 16 20 24 28 31 Type = 11 Code = 0 or 1 Checksum Unused IP header + First 8 bytes of original datagram • Sent when – TTL becomes 0 (code: 0) – The reassembling of a fragment times out (code: 1) Eike Ritter Network Security - Lecture 5 21

  23. traceroute • Use ICMP time exceeded messages to determine the path used to deliver a datagram • A series of IP datagrams are sent to the destination • Each datagram has an increasing TTL field value (start value: 1) • Router decrements TTL; if it is 0, sends back a ICMP unreachable message • Useful for network analysis and debugging Eike Ritter Network Security - Lecture 5 22

Recommend


More recommend