TCP/IP: ICMP, UDP Network Security Lecture 5
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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 1Network Security - Lecture 5
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
ICMP message format
Type Code Checksum
Data
Eike Ritter Network Security - Lecture 5 3
0 4 8 1612 31
• Type: ICMP type
• Code: ICMP subtype
• Checksum: Error checking code
- Computed on the ICMP header and data (with checksum field set to 0)
20 24 28
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
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
ICMP Echo request/reply
Type = 0 or 8 Code = 0 Checksum
Identifier Sequence number
Optional data
Eike Ritter Network Security - Lecture 5 6
0 4 8 1612 3120 24 28
ICMP echo request
Eike Ritter 7Network Security - Lecture 5
ICMP encapsulation
Eike Ritter 8Network Security - Lecture 5
ping
Eike Ritter Network Security - Lecture 5 9
$ ping 192.168.0.1PING 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 ms64 bytes from 192.168.0.1: icmp_seq=2 ttl=52 time=8.24 ms64 bytes from 192.168.0.1: icmp_seq=3 ttl=52 time=8.02 ms64 bytes from 192.168.0.1: icmp_seq=4 ttl=52 time=8.02 ms64 bytes from 192.168.0.1: icmp_seq=5 ttl=52 time=8.16 ms64 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 25082msrtt min/avg/max/mdev = 8.021/8.106/8.245/0.125 ms
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
Eike Ritter Network Security - Lecture 5 10
$ nmap -sP 172.16.48.0/24
Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 09:48 PSTHost 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
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
ICMP echo-based attacks: smurf
Eike Ritter Network Security - Lecture 5 12
Attacker: 6.6.6.6 Victim: 1.1.1.1
From: 1.1.1.1
To: 2.2.2.2.255
2.2.2.1 2.2.2.2
2.2.2.3 2.2.2.4
2.2.2.253
ICMP echo-based attacks: smurf
• Defenses
– Ignore ICMP echo requests destined to the
broadcast address
– Linux:
$ sysctlnet.ipv4.icmp_echo_ignore_broadcasts
Eike Ritter Network Security - Lecture 5 13
ICMP redirect
Eike Ritter Network Security - Lecture 5 14
Host: 172.16.48.100
Gateway:
172.16.48.1
Gateway:
172.16.48.2
Destination Gateway Flags0.0.0.0 172.16.48.1 UG1.1.1.255 172.16.48.2 UGHD
Destination Gateway1.1.1.255 172.16.48.2
(4)
(1) Datagram to 1.1.1.42
(2) Datagram to 1.1.1.42
(3) ICMP redirect message:
“use 172.16.48.2 as gateway
to communicate with 1.1.1/24”
ICMP redirect
Eike Ritter Network Security - Lecture 5 15
Type = 5 Code = 0, 1, 2, or 3 Checksum
IP Address
IP header + First 8 bytes of original datagram
0 4 8 1612 31
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
20 24 28
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
ICMP redirect attack
Eike Ritter Network Security - Lecture 5 17
Address Hwaddress Role172.16.48.1 00:50:56:00:00:01 Gateway172.16.48.2 00:50:56:00:00:02 Linux host172.16.48.100 00:50:56:00:00:64 Windows host
C:\windows\system32> route print -4IPv4 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 11172.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 266172.16.48.255 255.255.255.255 On-link 172.16.48.100 266
============================================================================
# tcpdump –n00: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
ICMP redirect attack – cont’d
Eike Ritter Network Security - Lecture 5 18
C:\Windows\system32> route print -4IPv4 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 11128.111.48.6 255.255.255.255 172.16.48.2 172.16.48.100 10172.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 266172.16.48.255 255.255.255.255 On-link 172.16.48.100 266
============================================================================
C:\Windows\system32> ping 128.111.48.600:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request00:50:56:00:00:64 > 00:50:56:00:00:02, IP 172.16.48.100 > 128.111.48.6: ICMP echo request
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
ICMP unreachable attack
Eike Ritter Network Security - Lecture 5 20
From 172.16.48.1
To: 172.16.48.100
Destination unreachable
Victim:
172.16.48.100
Attacker:
172.16.48.101
Gateway:
172.16.48.1
ICMP time exceeded
• Sent when
– TTL becomes 0 (code: 0)
– The reassembling of a fragment times out (code: 1)
Eike Ritter Network Security - Lecture 5 21
Type = 11 Code = 0 or 1 Checksum
Unused
IP header + First 8 bytes of original datagram
0 4 8 1612 3120 24 28
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 debuggingEike Ritter Network Security - Lecture 5 22
traceroute – cont’d
Eike Ritter Network Security - Lecture 5 23
$ traceroute www.google.co.uktraceroute to www.google.co.uk (173.194.37.104), 30 hops max, 40 byte pkts1 rita-rw (147.188.193.6) 1.115 ms 1.087 ms 1.082 ms2 bes (10.0.9.1) 0.322 ms 0.315 ms 0.299 ms3 hscn-gw (147.188.199.1) 0.633 ms 0.621 ms 0.609 ms4 cs-ac00b7e1-2.bham.ac.uk (147.188.121.129) 0.937 ms 0.933 ms 0.923 ms5 cs-lb00b1e5-8b2e5-8.bham.ac.uk (147.188.120.13) 0.893 ms 0.884 ms
0.875 ms6 fw-sr00.bham.ac.uk (147.188.121.234) 0.865 ms 1.044 ms 1.043 ms7 147.188.121.245 (147.188.121.245) 1.747 ms 1.788 ms 1.775 ms8 193.63.208.21 (193.63.208.21) 1.764 ms 0.980 ms 3.367 ms9 so-1-0-0.warr-sbr1.ja.net (146.97.42.189) 3.314 ms 3.660 ms 3.649 ms
10 so-5-1-0.read-sbr1.ja.net (146.97.33.89) 7.324 ms 7.311 ms 7.655 ms11 as0.lond-sbr3.ja.net (146.97.33.166) 9.121 ms 9.108 ms 9.453 ms12 po1.lond-ban3.ja.net (146.97.35.106) 9.443 ms 9.788 ms 9.775 ms13 google.lond-ban3.ja.net (193.62.157.30) 70.751 ms 71.101 ms 71.088 ms14 209.85.255.175 (209.85.255.175) 8.066 ms 8.271 ms 209.85.252.76 (209.85.252.76) 8.321 ms15 209.85.251.58 (209.85.251.58) 9.036 ms 9.385 ms 209.85.251.202 (209.85.251.202) 9.382 ms16 lhr14s02-in-f104.1e100.net (173.194.37.104) 8.994 ms 9.342 ms 9.336 ms
UDP
• Based on IP
• Provides a connectionless, unreliable, best-effort datagram delivery service– delivery, integrity, non-duplication, ordering, and bandwidth are
not guaranteed
• Introduces the abstraction of ports– Allows one to address different message destinations for the
same IP address
• Commonly used for– Multimedia
– Services based on request/reply schema (e.g., DNS, NFS, RPC)
• RFC 768
Eike Ritter Network Security - Lecture 5 24
UDP message format
UDP source port UDP dest port
UDP message length Checksum
Data
Eike Ritter Network Security - Lecture 5 25
0 4 8 1612 3120 24 28
UDP message
Eike Ritter 26Network Security - Lecture 5
UDP encapsulation
Eike Ritter Network Security - Lecture 5 27
Frame dataFrame dataFrame headerFrame header
IP headerIP header IP dataIP data
UDP headerUDP header UDP dataUDP data
UDP encapsulation
Eike Ritter 28Network Security - Lecture 5
UDP spoofing
• Essentially, it is IP spoofing
Eike Ritter Network Security - Lecture 5 29
Server:
192.168.0.3
Attacker:
192.168.0.2
Client:
192.168.0.1
UDP request
Spoofed
UDP reply
UDP reply
UDP hijacking
• Variation of UDP spoofing attack
Eike Ritter Network Security - Lecture 5 30
Server:
192.168.0.3
Attacker:
192.168.0.2
Trusted client:
192.168.0.1
UDP reply to spoofed request
UDP spoofing
• Vulnerable protocols
– DNS
– RPC
• NFS
• NIS
Eike Ritter Network Security - Lecture 5 31
UDP portscan
• Used to determine which UDP services are available
• A zero-length UDP packet is sent to each port
• If an ICMP error message “port unreachable” is received the service is assumed to be unavailable
• Note that the sending rate of ICMP messages can be limited (depending on the OS): the scan can be slow– Linux: $ sysctl net.ipv4.icmp_ratelimit
(number of jiffies to wait before sending another message)
Eike Ritter Network Security - Lecture 5 32
UDP portscan
Eike Ritter Network Security - Lecture 5 33
$ sudo nmap -sU 172.16.48.130
Starting Nmap 5.00 ( http://nmap.org ) at 2011-01-12 17:17 PSTInteresting ports on 172.16.48.130:Not shown: 997 closed portsPORT STATE SERVICE111/udp open|filtered rpcbind137/udp open|filtered netbios-ns2049/udp open|filtered nfsMAC Address: 00:0C:29:27:25:40 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 1075.62 seconds
UDP portscan
Eike Ritter Network Security - Lecture 5 34
$ sudo tcpdump -n host 172.16.48.130 172.16.48.139.43866 > 172.16.48.130.1433: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1433 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.51554: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 51554 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.40915: UDP, length 0172.16.48.139.43867 > 172.16.48.130.40915: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 40915 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.36489: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 36489 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.1033: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1033 unreachable, length 36172.16.48.139.43866 > 172.16.48.130.34862: UDP, length 0172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 34862 unreachable, length 36
NEXT ON
Eike Ritter 35Network Security - Lecture 5
Take away points
• ICMP has good functionalities to debug and control network.
• Some of them can be abused by attackers– ICMP scanning (pingsweep)
– ICMP smurf attack
– ICMP redirection
• UDP– Format
– Portscan
• nmap
Eike Ritter 36Network Security - Lecture 5
Next time
• TCP
Eike Ritter 37Network Security - Lecture 5
Related Documents
![€TCP/UDP Port Numberspsanchez/Distro_2012... · 19 tcp, udp chargen Character Generator; alias=ttytst source 20 tcp, udp ftp-data File Transfer [Default Data] 21 tcp, udp ftp File](https://static.cupdf.com/doc/110x72/5e9f0261f4657916937549bf/atcpudp-port-psanchezdistro2012-19-tcp-udp-chargen-character-generator.jpg)
