%include "default.mgp" %default 1 bgrad %%%%%%%%%%%%%%%% %deffont "typewriter" tfont "MONOTYPE.TTF" %page %nodefault %back "blue" %center %size 7 TCP state + windowtracking %center %size 4 by Harald Welte %page TCP state + window tracking What? Why? TCP is a stateful protocol, each endpoint is a state machine What is TCP state / windowtracking? Some intermediate System (Router/Firewall) is trying to derive the current state of the two TCP endpoints Why does somebody want TCP state / windowtracking Evaluation of TCP stack implementations Hide/Protect broken implementations from a public network %page TCP state + windowtracking TCP basics states of a TCP endpoint: LISTEN: port waiting for connection request from remote end SYN_SENT: we've sent a SYN packet and not received anything yet SYN_RECEIVED: We've received a SYN in reply to our SYN ESTABLISHED: fully established TCP connection FIN_WAIT1: waiting for FIN from remote end or ACK of sent FIN FIN_WAIT2 waiting for FIN from remote end TIME_WAIT: waiting for enough time to pass to be sure the remote end received the ACK of its FIN CLOSED: no connection state at all CLOSE_WAIT: waiting for a connection termination request from local user CLOSING: waiting for a connection termination request acknowledgement from the remote end LAST_ACK: Waiting for ACK of the FIN previously sent to remote end %page TCP state + windowtracking TCP basics sequence numbers every octet has a corrsponding sequence number sequence number is increased by one for every payload octet sent receiver acknowledges last received contiguous sequence number (cumulative ack) EXTENSION: selective acknowledgement (SACK) option, RFC2018 receiver can specify seperate sequencenumber blocks it has received sliding window protocol receiver advertises the size of the receive window sender can only send up to 'window' number of octets which are not ACK'ed yet EXTENSION: window scaling, RFC1323 window size of 16bit is too small for high bandwith links, thus window scaling was introduced %page TCP state + windowtracking TCP state tracking Where do we do TCP state tracking? state tracker needs to see _all_ packets in both directions problems with asymmetric routing! So where's the Problem? IP is an unreliable, best-effort protocol If man in the middle does observe a packet, he can make no assumption on whether it actually arrives at the receiver. %page TCP state + window tracking Problems Example scenario 1 A sends SYN to B man in the middle saves state as SYN_SENT B sends SYN/ACK to A man in the middle detects state transition to SYN_RECEIVED SYN/ACK doesn't arrive at A somebody spoofs ACK A->B to firewall man in the middle detects state transition to ESTABLISHED ==> Any traffic between A and B will be accepted (wrong!) %page TCP state + window tracking Problems Example scenario 2 fully established TCP connection A sends FIN to B man in the middle saves state to FIN_WAIT1 B sends FIN/ACK to A man in the middle saves state CLOSING/TIME_WAIT FIN/ACK doesn't arrive at A B retransmits FIN/ACK to A man in the middle doesn't accept any further packets .oO(booom)Oo. %page TCP state + window tracking Problems Example scenario 3 (FIN/RST spoofing without windowtracking) fully established TCP connection evil guy spoofs FIN A->B (with guessed sequence number man in the middle saves satet as FIN_WAIT1 B ignores FIN/ACK because of wrong sequence number A sends further segments to B man in the middle doesn't accept further segments after FIN was sent in this direction .oO(booom)Oo. Solution: Real Window tracking See paper by Guido van Rooj %page TCP state + window tracking Further Problems pickup of already established connections window scaling sucks in this case window tracking has to be disabled in that case selective acknowledgements man-in-the-middle needs to track all selectively acknowledged segments this can draw lots of resources at the man in the middle and is prone to DoS %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page TCP state + window tracking conntrack subsystem of netfilter Netfilter architecture in IPv4 %font "typewriter" %size 3 --->[1]--->[ROUTE]--->[3]--->[4]---> | ^ | | | [ROUTE] v | [2] [5] | ^ | | v | %font "standard" 1=NF_IP_PRE_ROUTING 2=NF_IP_LOCAL_IN 3=NF_IP_FORWARD 4=NF_IP_POST_ROUTING 5=NF_IP_LOCAL_OUT %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page TCP state + window tracking conntrack subsystem of netfilter Connection tracking... implemented seperately from NAT enables stateful filtering implementation hooks into NF_IP_PRE_ROUTING to track packets hooks into NF_IP_POST_ROUTING and NF_IP_LOCAL_IN to see if packet passed filtering rules protocol modules (currently TCP/UDP/ICMP) application helpers currently (FTP,IRC,H.323,talk,SNMP) divides packets in the following four categories NEW - would establish new connection ESTABLISHED - part of already established connection RELATED - is related to established connection INVALID - (multicast, errors...) does _NOT_ filter packets itself can be utilized by iptables using the 'state' match is used by NAT Subsystem %page TCP state + window tracking Further Reading RFC793,RFC2018,RFC1323: Transmission Control Protocol http://www.netfilter.org/ - netfilter hacking howto contains some info