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

▶
tcp ip icmp udp
SMART_READER_LITE
LIVE PREVIEW

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

Apr 06, 2023 487 likes •882 views

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 -

slide-1
SLIDE 1

TCP/IP: ICMP, UDP

Network Security Lecture 5

slide-2
SLIDE 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 1 Network Security - Lecture 5

slide-3
SLIDE 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

slide-4
SLIDE 4

ICMP message format

Type Code Checksum Data

Eike Ritter Network Security - Lecture 5 3

4 8 16 12 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

slide-5
SLIDE 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

slide-6
SLIDE 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

slide-7
SLIDE 7

ICMP Echo request/reply

Type = 0 or 8 Code = 0 Checksum Identifier Sequence number Optional data

Eike Ritter Network Security - Lecture 5 6

4 8 16 12 31 20 24 28

slide-8
SLIDE 8

ICMP echo request

Eike Ritter 7 Network Security - Lecture 5

slide-9
SLIDE 9

ICMP encapsulation

Eike Ritter 8 Network Security - Lecture 5

slide-10
SLIDE 10

ping

Eike Ritter Network Security - Lecture 5 9

$ 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

slide-11
SLIDE 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

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 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

slide-12
SLIDE 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

slide-13
SLIDE 13

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

slide-14
SLIDE 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

slide-15
SLIDE 15

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 Flags 0.0.0.0 172.16.48.1 UG 1.1.1.255 172.16.48.2 UGHD Destination Gateway 1.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”

slide-16
SLIDE 16

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 4 8 16 12 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

slide-17
SLIDE 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

slide-18
SLIDE 18

ICMP redirect attack

Eike Ritter Network Security - Lecture 5 17

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

slide-19
SLIDE 19

ICMP redirect attack – cont’d

Eike Ritter Network Security - Lecture 5 18

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

slide-20
SLIDE 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

slide-21
SLIDE 21

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

slide-22
SLIDE 22

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 4 8 16 12 31 20 24 28

slide-23
SLIDE 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

slide-24
SLIDE 24

traceroute – cont’d

Eike Ritter Network Security - Lecture 5 23

$ traceroute www.google.co.uk 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 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 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 0.875 ms 6 fw-sr00.bham.ac.uk (147.188.121.234) 0.865 ms 1.044 ms 1.043 ms 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 10 so-5-1-0.read-sbr1.ja.net (146.97.33.89) 7.324 ms 7.311 ms 7.655 ms 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 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 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 16 lhr14s02-in-f104.1e100.net (173.194.37.104) 8.994 ms 9.342 ms 9.336 ms

slide-25
SLIDE 25

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

slide-26
SLIDE 26

UDP message format

UDP source port UDP dest port UDP message length Checksum Data

Eike Ritter Network Security - Lecture 5 25

4 8 16 12 31 20 24 28

slide-27
SLIDE 27

UDP message

Eike Ritter 26 Network Security - Lecture 5

slide-28
SLIDE 28

UDP encapsulation

Eike Ritter Network Security - Lecture 5 27

Frame data Frame data Frame header Frame header IP header IP header IP data IP data UDP header UDP header UDP data UDP data

slide-29
SLIDE 29

UDP encapsulation

Eike Ritter 28 Network Security - Lecture 5

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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

slide-32
SLIDE 32

UDP spoofing

  • Vulnerable protocols

– DNS – RPC

  • NFS
  • NIS

Eike Ritter Network Security - Lecture 5 31

slide-33
SLIDE 33

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

slide-34
SLIDE 34

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 PST Interesting ports on 172.16.48.130: Not shown: 997 closed ports PORT STATE SERVICE 111/udp open|filtered rpcbind 137/udp open|filtered netbios-ns 2049/udp open|filtered nfs MAC Address: 00:0C:29:27:25:40 (VMware) Nmap done: 1 IP address (1 host up) scanned in 1075.62 seconds

slide-35
SLIDE 35

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 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1433 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.51554: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 51554 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.40915: UDP, length 0 172.16.48.139.43867 > 172.16.48.130.40915: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 40915 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.36489: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 36489 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.1033: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 1033 unreachable, length 36 172.16.48.139.43866 > 172.16.48.130.34862: UDP, length 0 172.16.48.130 > 172.16.48.139: ICMP 172.16.48.130 udp port 34862 unreachable, length 36

slide-36
SLIDE 36

NEXT ON

Eike Ritter 35 Network Security - Lecture 5

slide-37
SLIDE 37

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 36 Network Security - Lecture 5

slide-38
SLIDE 38

Next time

  • TCP

Eike Ritter 37 Network Security - Lecture 5