interesting behavior of ftp helper

["Leonardo Rodrigues Magalhães" <leolistas@solutti.com.br>]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]


    Hello Guys,

    I have always read on documentations and messages on this mailing 
list that the several helpers available for netfilter would 'recognize' 
some complex protocols and make them became RELATED connections. But on 
the development of one firewall script, i found an interesting situation.

    I was running with the following situation:

    forward_interna_externa is the created table that receives all 
traffic flowing from internal to external network. It has, among several 
others, the following rules:

-A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m tcp 
--dport 20:21 -j ACCEPT
-A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m state 
--state RELATED -j ACCEPT
-A forward_interna_externa -j LOG --log-prefix "bloq_forward_externa:" 
--log-level 6 --log-tcp-sequence --log-tcp-options --log-ip-options
-A forward_interna_externa -j DROP


    ip_conntrack_ftp and ip_nat_ftp modules are correctly loaded.

    So, with these rules and all i have read, i was expecting that 20 
and 21 TCP ports would handle the active FTP connections and 
ip_conntrack_ftp+RELATED rule would handle the passive FTP connections.

    But ..... altough i was doing what i tought to be the correct rules 
and loading the needed modules, i couldnt passive FTP. Active FTP was 
OK, but passive wasn't. My connections were blocked and no packets were 
hitting the RELATED rule:

Aug 15 15:20:02 fenix kernel: bloq_forward_externa:IN=eth0 OUT=eth1 
SRC=192.168.0.54 DST=200.182.XX.YY LEN=40 TOS=0x00 PREC=0x00 TTL=127 
ID=756 DF PROTO=TCP SPT=1113 DPT=4846 SEQ=1838929699 ACK=3064370605 
WINDOW=65535 RES=0x00 ACK URGP=0

Aug 15 15:20:08 fenix kernel: bloq_forward_externa:IN=eth0 OUT=eth1 
SRC=192.168.0.54 DST=200.182.XX.YY LEN=40 TOS=0x00 PREC=0x00 TTL=127 
ID=758 DF PROTO=TCP SPT=1113 DPT=4846 SEQ=1838929699 ACK=3064370605 
WINDOW=65535 RES=0x00 ACK URGP=0


    Altough i always tought that helpers would make 'related' 
connections became RELATED ones, i made one modification on my firewall 
rules. The RELATED rule got a 'brother' rule, the ESTABLISHED one:

-A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m tcp 
--dport 20:21 -j ACCEPT
-A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m state 
--state RELATED -j ACCEPT
-A forward_interna_externa -s 192.168.0.0/255.255.255.0 -p tcp -m state 
--state ESTABLISHED -j ACCEPT
-A forward_interna_externa -j LOG --log-prefix "bloq_forward_externa:" 
--log-level 6 --log-tcp-sequence --log-tcp-options --log-ip-options
-A forward_interna_externa -j DROP


    And then, passive FTP starts working !!! I could see, with 'iptables 
-nL forward_interna_externa -v' that ESTABLISHED rule was getting hit by 
the passive FTP packets and not the RELATED one. With some more 
experiences, i tried removing FTP helpers and FTP really stopped working 
because packets werent RELATED not ESTABLISHED. Loading FTP modules made 
packets correctly get identified and were allowed by the ESTABLISHED rule.

    Question is ..... did i always get wrong about the helpers and 
RELATED state ??? Is it possible that helper connections get treated as 
ESTABLISHED ??

    The other theory i got is that only the FIRST packet of a helper 
identified connection is RELATED and all the other packets that belong 
to that RELATED connection are indeed ESTABLISHED ones. That would 
explain this situation i got.

    Where did i get it wrong ?? :)

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes@solutti.com.br
	My SPAMTRAP, do not email it






[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 5672 bytes --]