diff options
Diffstat (limited to '2002/tcp-statetracking-ccc2002')
-rw-r--r-- | 2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp | 201 |
1 files changed, 201 insertions, 0 deletions
diff --git a/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp new file mode 100644 index 0000000..c98ba30 --- /dev/null +++ b/2002/tcp-statetracking-ccc2002/tcp-statetracking-ccc2002.mgp @@ -0,0 +1,201 @@ +%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 <laforge@gnumonks.org> + + +%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 |