TCP and ICMP l l TCP and ICMP

TCP and ICMP l l TCP and ICMP source quench Will modify window size TCP and host/network unreachable is ingored 1

Repacketization l l Repacketization - TCP sends a bigger segment ( less than MSS ) Occurs when TCP timers out and retransmits 2

Applicatios over UDP l l l l DNS NFS ( TCP Implementations also ) NIS ( Yellow Pages ) TFTP BOOTP NTP ( TCP Implementations also ) NNTP 3

UDP l l l User Datagram Protocol UDP sends messages as datagrams UDP is a connectionless, unreliable protocol 4

UDP/IP l l l 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 l l 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 l l 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 l l 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 l l 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 l Mitnik used weaknesses in the TCP/IP implementation – IP Spoofing – TCP Sequence Prediction l 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 l l l 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 l Deduces relationships – Determines that Shimomura’s workstation trusts another host 11

Actual Break-In l l l l 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 l l Enabled finger protocol Enabled BSD-r protocol Allowed IP source routing Allowed weak host level trust relationships 13

Shimomura’s Analysis l l l l 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) l l l 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 l l Secondary logging to a secure external host Using tcpdump Excellent investigative skills Coordinating with other sites 16

Minimal Prevention of Attacks l l l 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 l l l 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 l 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 l l netstat -a -f inet netstat -s | grep “listen_queue overflows” – Received help from Cheswick l What did they do? – Reduce IP Spoofing – Increase listen queue and reduce time to wait for SYN 19

Why SYN Flood attack works l l 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 l l 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 l l 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 l l l Struct sockaddr_in sin_family=AF_INET sin_port=sport 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 l l 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

l Methods for Preventing SYN Floods (2)border exists If no – Install vendor patches – Increase connection queue – Decrease the time out state for 3 -way handshakes (t < 75 seconds) 24