ip_conntrack_ftp doesn't work

ip_conntrack_ftp doesn't work

[Giovanni Cardone]

On 2.4.18 with 1.2.7(1.2.6a too) ftp conntrack module doesn't work.
I'm trying to understand this using a simple script:

<begin script>
#!/bin/sh

ipt='/usr/local/sbin/iptables'

modprobe ip_tables
modprobe iptable_filter
modprobe ipt_state
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_LOG

$ipt -P INPUT DROP
$ipt -P OUTPUT DROP
$ipt -P FORWARD DROP
$ipt -A INPUT -i lo -j ACCEPT
$ipt -A OUTPUT -o lo -j ACCEPT
$ipt -A OUTPUT -o ppp0 -j ACCEPT
$ipt -A INPUT -p tcp -m state --state RELATED -j ACCEPT 
$ipt -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix 
"NEW_NOT_SYN "
$ipt -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$ipt -A INPUT -j LOG
$ipt -A OUTPUT -j LOG
$ipt -A FORWARD -j LOG
<end script>

The logs shows up some entries like these:

Jun 14 19:10:44 darkstar kernel: IN=ppp0 OUT= MAC= SRC=195.210.93.107
DST=151.26.80.131 LEN=60 TOS=0x08 PREC=0x00 TTL=58 ID=40516 DF PROTO=TCP
SPT=20 DPT=1039 WINDOW=32120 RES=0x00 SYN URGP=0

When I try to contact an ftp server, lsmod says:

darkstar\# lsmod | awk '/ftp/'
ip_conntrack_ftp        3120   0  (unused)
ip_conntrack           13264   1  [ip_conntrack_ftp]

So the syn about the data channel from the server port 20 to me is not RELATED
to the connections in the table. It's normal that lsmod shows up the
conntrack_ftp as unused? I was thinking no ... :)

What do I need to do?


Many Thanks 

Re: ip_conntrack_ftp doesn't work

[Adam Young]

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

On Fri, 14 Jun 2002 19:42:04 +0200
Giovanni Cardone <g_cardone@libero.it> wrote:

> On 2.4.18 with 1.2.7(1.2.6a too) ftp conntrack module doesn't work.
> I'm trying to understand this using a simple script:
> 
> <begin script>
> #!/bin/sh
> 
> ipt='/usr/local/sbin/iptables'
> 
> modprobe ip_tables
> modprobe iptable_filter
> modprobe ipt_state
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> modprobe ipt_LOG
> 
> $ipt -P INPUT DROP
> $ipt -P OUTPUT DROP
> $ipt -P FORWARD DROP
> $ipt -A INPUT -i lo -j ACCEPT
> $ipt -A OUTPUT -o lo -j ACCEPT
> $ipt -A OUTPUT -o ppp0 -j ACCEPT
> $ipt -A INPUT -p tcp -m state --state RELATED -j ACCEPT 
> $ipt -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix 
> "NEW_NOT_SYN "
> $ipt -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
> $ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $ipt -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> $ipt -A INPUT -j LOG
> $ipt -A OUTPUT -j LOG
> $ipt -A FORWARD -j LOG
> <end script>
> 
> The logs shows up some entries like these:
> 
> Jun 14 19:10:44 darkstar kernel: IN=ppp0 OUT= MAC= SRC=195.210.93.107
> DST=151.26.80.131 LEN=60 TOS=0x08 PREC=0x00 TTL=58 ID=40516 DF
> PROTO=TCP SPT=20 DPT=1039 WINDOW=32120 RES=0x00 SYN URGP=0
> 
> When I try to contact an ftp server, lsmod says:
> 
> darkstar\# lsmod | awk '/ftp/'
> ip_conntrack_ftp        3120   0  (unused)
> ip_conntrack           13264   1  [ip_conntrack_ftp]
> 
> So the syn about the data channel from the server port 20 to me is not
> RELATED to the connections in the table. It's normal that lsmod shows
> up the conntrack_ftp as unused? I was thinking no ... :)
> 
> What do I need to do?

	perhaps modprobe'ing ip_nat_ftp ? I believe that's the module name,
that you may need.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ip_conntrack_ftp doesn't work

[Antony Stone]

On Monday 24 June 2002 8:16 pm, Adam Young wrote:

> On Fri, 14 Jun 2002 19:42:04 +0200
>
> Giovanni Cardone <g_cardone@libero.it> wrote:
> > On 2.4.18 with 1.2.7(1.2.6a too) ftp conntrack module doesn't work.
> > I'm trying to understand this using a simple script:

[script snipped]

> > The logs shows up some entries like these:
> >
> > Jun 14 19:10:44 darkstar kernel: IN=ppp0 OUT= MAC= SRC=195.210.93.107
> > DST=151.26.80.131 LEN=60 TOS=0x08 PREC=0x00 TTL=58 ID=40516 DF
> > PROTO=TCP SPT=20 DPT=1039 WINDOW=32120 RES=0x00 SYN URGP=0

> > What do I need to do?
>
> 	perhaps modprobe'ing ip_nat_ftp ? I believe that's the module name,
> that you may need.

But the script is not doing any NAT, and the log entry shows valid addresses 
for both source and destination, so I don't think an FTP NAT module is going 
to help ?

 

Antony.

Re: ip_conntrack_ftp doesn't work

[Giovanni Cardone]

> But the script is not doing any NAT, and the log entry shows valid addresses 
> for both source and destination, so I don't think an FTP NAT module is going 
> to help ?

You right. I'm not doing any kind of NAT because I do not need it :). I've only 
this machine with a single dial-up access to the outside. No LAN/other machine 
behind that one. Simply, I can't have a standard(read: *no* passive) FTP
session and I dunno why. Have you some suggestions?

Thanks

Re: ip_conntrack_ftp doesn't work

[Jozsef Kadlecsik]

On Fri, 14 Jun 2002, Giovanni Cardone wrote:

> On 2.4.18 with 1.2.7(1.2.6a too) ftp conntrack module doesn't work.
> I'm trying to understand this using a simple script:
>
> <begin script>
> #!/bin/sh
>
> ipt='/usr/local/sbin/iptables'
>
> modprobe ip_tables
> modprobe iptable_filter
> modprobe ipt_state
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
> modprobe ipt_LOG
>
> $ipt -P INPUT DROP
> $ipt -P OUTPUT DROP
> $ipt -P FORWARD DROP
> $ipt -A INPUT -i lo -j ACCEPT
> $ipt -A OUTPUT -o lo -j ACCEPT
> $ipt -A OUTPUT -o ppp0 -j ACCEPT
> $ipt -A INPUT -p tcp -m state --state RELATED -j ACCEPT
> $ipt -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix
> "NEW_NOT_SYN "
> $ipt -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
> $ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $ipt -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> $ipt -A INPUT -j LOG
> $ipt -A OUTPUT -j LOG
> $ipt -A FORWARD -j LOG
> <end script>
>
> The logs shows up some entries like these:
>
> Jun 14 19:10:44 darkstar kernel: IN=ppp0 OUT= MAC= SRC=195.210.93.107
> DST=151.26.80.131 LEN=60 TOS=0x08 PREC=0x00 TTL=58 ID=40516 DF PROTO=TCP
> SPT=20 DPT=1039 WINDOW=32120 RES=0x00 SYN URGP=0
>
> When I try to contact an ftp server, lsmod says:
>
> darkstar\# lsmod | awk '/ftp/'
> ip_conntrack_ftp        3120   0  (unused)
> ip_conntrack           13264   1  [ip_conntrack_ftp]
>
> So the syn about the data channel from the server port 20 to me is not RELATED
> to the connections in the table. It's normal that lsmod shows up the
> conntrack_ftp as unused? I was thinking no ... :)

What is the MTU on your PPP link? Don't you see log entries from the
ip_conntrack_ftp module like

conntrack_ftp: partial PORT nnnnnnn...

I suspect that your link has a very low MTU size and the FTP conntrack
module don't have a chance to get the whole command pattern in one packet.

[The module usage counter of the ip_conntrack_ftp module has nothing to do
with the number of the handled FTP session. It says "No other module
depends on me"].

> What do I need to do?

If your MTU is really small and must be kept small, then the case cannot
be handled by the netfilter conntrack subsystem :-(.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Allowing limited broadcasts between LAN <-> DMZ?

[Chris]

Hello,


i am wondering if it would be a security risk to generally allow ALL
limited broadcasts (255.255.255.255)?!

We have a heterogenous network with Linux (Firewalls, Mail/Proxy/Time/
etc-server), WinNT/W2k Clients & Servers and one AS/400 as server.
Now there is our internal firewall between the LANs and the DMZ.
At the moment i am blocking limited broadcasts, which breaks the 
functionality of some windows stuff (SQL-Server, NetBIOS, SMB, ...).
So i allow this traffic "manually" with adding according rules to the
internal firewall.

Why am i blocking the limited broadcast? Because i was sniffing around
and found several "example scripts" which do this. The question is
if this is REALLY necessary and if someone could exploit a not blocked,
limited broadcast?

Just yesterday we connected a printer to our LAN, and now it is sending
limited broadcasts to UDP port 123?!? (it want's to know the time?? :))
However, it's kind of annoying to see those entries in the logfile now
every five minutes.. sure i could allow/drop this without logging,
but the question is - again :) - can't i just allow ALL limited broad-
casts on the internal firewall?

	
		regards, Chris

Re: Allowing limited broadcasts between LAN <-> DMZ?

[Antony Stone]

On Tuesday 25 June 2002 10:27 am, Chris wrote:

> Hello,
>
>
> i am wondering if it would be a security risk to generally allow ALL
> limited broadcasts (255.255.255.255)?!
>
> We have a heterogenous network with Linux (Firewalls, Mail/Proxy/Time/
> etc-server), WinNT/W2k Clients & Servers and one AS/400 as server.
> Now there is our internal firewall between the LANs and the DMZ.
> At the moment i am blocking limited broadcasts, which breaks the
> functionality of some windows stuff (SQL-Server, NetBIOS, SMB, ...).

Broadcasts will not cross a router, from one network to another, so even if 
you did not actively block them with netfilter, they still wouldn't pass from 
your LAN to your DMZ.

 

Antony.

Re: ip_conntrack_ftp doesn't work

[Giovanni Cardone]

On Tue, Jun 25, 2002 at 10:52:12AM +0200, you wrote:
> What is the MTU on your PPP link? Don't you see log entries from the
> ip_conntrack_ftp module like
> 
> conntrack_ftp: partial PORT nnnnnnn...
> 
> I suspect that your link has a very low MTU size and the FTP conntrack
> module don't have a chance to get the whole command pattern in one packet.
> 
> [The module usage counter of the ip_conntrack_ftp module has nothing to do
> with the number of the handled FTP session. It says "No other module
> depends on me"].
I can't understand so well what you are saying... I'm not yet so smart like 
you :) 
Anyway, I tried this(give me some hints, if I'm wrong) :

darkstar\$ /sbin/ifconfig | egrep 'MTU'
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
	  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

So, it looks like 1500. Is it so small? Are you right, then? 
		    
> If your MTU is really small and must be kept small, then the case cannot
> be handled by the netfilter conntrack subsystem :-(.

I hope that's not my case(I know, I always have the passive type then...) :(

Re: ip_conntrack_ftp doesn't work

[Jozsef Kadlecsik]

On Tue, 25 Jun 2002, Giovanni Cardone wrote:

> darkstar\$ /sbin/ifconfig | egrep 'MTU'
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
> 	  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>
> So, it looks like 1500. Is it so small? Are you right, then?

No, then I'm wrong and it's not an MTU issue.

But were there any 'partial' FTP requests detected by the module
according to the kernel log?

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ip_conntrack_ftp doesn't work

[Giovanni Cardone]

On Tue, Jun 25, 2002 at 12:03:24PM +0200, you wrote:
> But were there any 'partial' FTP requests detected by the module
> according to the kernel log?

The only place I know to look in is /proc/net/ip_conntrack(I hope you are 
talking about this now...). For example, when I do :

darkstar\$ ftp 195.210.93.14 

it looks like :

darkstar\$ cat /proc/net/ip_conntrack
tcp      6 431998 ESTABLISHED src=151.26.68.170 dst=195.210.93.14 sport=1052
dport=21 src=195.210.93.14 dst=151.26.68.170 sport=21 dport=1052 [ASSURED]
use=1 
EXPECTING: proto=6 src=195.210.93.14 dst=151.26.68.170 sport=0 dport=1053

In the iptables logs I see :

Jun 26 01:51:59 darkstar kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jun 26 01:51:59 darkstar kernel: ip_conntrack (511 buckets, 4088 max)
Jun 26 01:52:19 darkstar kernel: +SYN IN=ppp0 OUT= MAC= SRC=195.210.93.107
DST=151.2 6.68.170 LEN=60 TOS=0x08 PREC=0x00 TTL=58 ID=33120 DF PROTO=TCP 
SPT=20 DPT=1053 WINDOW=32120 RES=0x00 SYN URGP=0 


But now it comes for me the strange part...
Now I tried to do ftp to another server, ftp.unina.it. Passive FTP now it
seems to work.

After I logged in the server, I tried the ls command and it works. To be sure
about the fact that I was using Passive mode, I did :

darkstar\# tcpdump port 20
02:01:26.828426 192.132.34.17.ftp-data > 151.26.68.170.1061: S
1536506260:1536506260(0) win 32768 <mss 1460,nop,wscale 0> (DF)
02:01:26.828491 151.26.68.170.1061 > 192.132.34.17.ftp-data: S
4196382663:4196382663(0) ack 1536506261 win 5840 <mss 1460,nop,wscale 0> (DF)

and so on like those two. So a data channel was opened...
But if I do :

darkstar\# lsmod | egrep 'ftp'
ip_conntrack_ftp        3120   0  (unused)
ip_conntrack           13264   2  [ipt_state ip_conntrack_ftp]

it shows unused, but it's working I believe...
The proc file system :

darkstar\# cat /proc/net/ip_conntrack
tcp      6 117 TIME_WAIT src=192.132.34.17 dst=151.26.68.170 sport=20
dport=1067 src=151.26.68.170 dst=192.132.34.17 sport=1067 dport=20 [ASSURED]
use=1 
tcp      6 431997 ESTABLISHED src=151.26.68.170 dst=192.132.34.17 sport=1066
dport=21 src=192.132.34.17 dst=151.26.68.170 sport=21 dport=1066 [ASSURED]
use=2 
udp      17 12 src=151.26.68.170 dst=193.70.192.25 sport=1027 dport=53
src=193.70.192.25 dst=151.26.68.170 sport=53 dport=1027 use=1 



That's all I know at this time. I'm really new to Netfilter :( Is there other 
I can do to provide more info about my situation? Let me know please.


Thanks