TCP and ICMP


TCP and ICMP source quench
Will modify window size
TCP and host/network unreachable is ingored
1
Repacketization


Repacketization - TCP sends a bigger segment
( less than MSS )
Occurs when TCP timers out and retransmits
2
Applicatios over UDP







DNS
NFS ( TCP Implementations also )
NIS ( Yellow Pages )
TFTP
BOOTP
NTP ( TCP Implementations also )
NNTP
3
UDP



User Datagram Protocol
UDP sends messages as datagrams
UDP is a connectionless, unreliable protocol
4
UDP/IP





IP carries out fragmentation
IP performs datagram re-assembly at destination
If the IP DF flag is set and ICMP error occurs the
datagram is discarded
Each fragmented IP datagram becomes it’s own IP
packet
Fragmentation causes performance loss
5
UDP and ARP




Example of UDP/IP vulnerability
ARP is the address resolution protocol
ARP flooding can occur because of the way
ARPresponds to requests and its interaction
between IP fragments
NFS times out if it sends UDP datagrams greater
that a certain size
6
UDP Datagram




The maximum size of a datagram is 65535 bytes
The datagram size may be limited by the
application program
The datagram size may be limited by the IP
implementation
Depending on the implementation, the datagram
size may be limited by receiver’s application
program
7
UDP and ICMP




Example of unreliable delivery
UDP cna generate ICMP Source Quench Error
Datagrams can be queued for output
Sender’s application may never receive ICMP
error
8
Mitnik-Shimomura Case Study


Multi-phased tracking of attacker via Shimomura
Sequence of Events
–
–
–
–
–
Initial Break-in and Detection
Data Analysis of Attack
Cooperating with other sites with similar problems
Cooperating with ISP that Mitnik used
Coordinating with Sprint to locate Mitnik via cellular
phone use
– Eventual Warrant and Arrest
9
Initial Network Attack by Mitnik

Mitnik used weaknesses in the TCP/IP
implementation
– IP Spoofing
– TCP Sequence Prediction

Steps taken by the attacker
–
–
–
–
–
–
–
Information gathering phase
Examining trust relationships
‘Gagging’ trusted host
Spoofing trusted host
Sequence Prediction
Data Exchange
Host Level Attacks
10
Information Gathering



Mitnik breaks in from toad.com
Issues finger command for user/host information
Other UNIX commands - showmount, rpcinfo
used to determine trust relationships
– Note: Mitnik does not use a scanner

Deduces relationships
– Determines that Shimomura’s workstation trusts
another host
11
Actual Break-In







Mitnik decides to wait for Christmas Day
Mitnik ‘gags’ the host Shimomura’s machine
trusts
Mitnik sends spoofed IP packets
Begins TCP sequence number attack from luc.edu
Establishes connection from luc.edu
Exchanges Data to open Shimomura’s host
Mitnik closes connection
12
Shimomura’s Lack of Prevention




Enabled finger protocol
Enabled BSD-r protocol
Allowed IP source routing
Allowed weak host level trust relationships
13
Shimomura’s Analysis







Shimomura receives a report of intrusion
Notices inconsistencies in logs
Checks the host for last accessed files, libraries
and suid programs
Uses tcpdump for traffic analysis
Detects IP Spoofing
Detects that the attacker is searching for trust
relationship
Detects Sequence Guessing attack
14
Shimomura’s Analysis (2)





Detects data exchange from foreign host
Detects closed connection
Examines host files on the system
The attacker leaves a ‘calling card’
Shimomura informs CERT
15
Shimomura’s Best Defenses




Secondary logging to a secure external host
Using tcpdump
Excellent investigative skills
Coordinating with other sites
16
Minimal Prevention of Attacks



Authentication and Encryption should be used
TCP/IP implementation should be addressed
Current Methods
–
–
–
–
Firewalls/Packet Filtering
External Logging
Disable non-essential or buggy services
Install host checks
17
Panix Case Study





In late 1996 Panix.com suffered a loss of service
for two days
Other ISP and sites around the Internet suffered
slowdowns and similar problems
One of the first cases of SYN flood attacks
ISP’s were the most vulnerable
No way to discover origin of attack because of
source IP spoofing
18
Panix Administrators

What did they notice?
– Servers were unresponsive and approximately 6000 ISP
customers had sporadic or non-existent connectivity
– Check servers state
» Resource Usage Up
» netstat showed connections in SYN_RCVD state


netstat -a -f inet
netstat -s | grep “listen_queue overflows”
– Received help from Cheswick

What did they do?
– Reduce IP Spoofing
– Increase listen queue and reduce time to wait for SYN
19
Why SYN Flood attack works




Victim can’t respond with SYN-ACK
Victim demuxes the packet and stores information
in memory via socket{}, inpcb{}, tcpcb{}
Increasing backlog queue helps minimally since it
holds incoming and pending connection requests
Client remains in SYN_RCVD state until
connection timer expires and memory allocated to
buffers is destroyed
20
TCP Queues


An incoming segment has a slave socket created
Secondary socket{}, tcpcb{}, pcb{} created
– If backlog queue limit is reached here, then the resource
allocation takes effect


If backlog is not full, socket is in LISTEN state
The victim host will be waiting in SYN_RCVD
state until timer is off
21
Struct/var allowing for attack





Struct sockaddr_in sin
sin.sin_family=AF_INET
sin.sin_port=sport
sin.sin_saddr.s_addr=dadd
Creation of a flood loop that works within a good
window of time, where too many SYNs are not
sent to quickly. Recall that most implementations
use 5 as the per connection limit
22
Methods for Preventing SYN-Floods




These methods at best only REDUCE
vulnerability. They do not eliminate it
Reduce IP Spoofing
Install Vendor Patches
Install Firewalls/Packet Filters
– Filter incoming and outgoing IP addresses
– Stop inbound SYN packets at border and store and
forward them via a bounded linked list
– Use Access List at border
23
Methods for Preventing SYN Floods (2)

If no border exists
– Install vendor patches
– Increase connection queue
– Decrease the time out state for 3-way handshakes
(t < 75 seconds)
24