202 lines
5.6 KiB
Plaintext
202 lines
5.6 KiB
Plaintext
%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
|