Ip_conntrack_ftp with PASSIVE FTP does not work

Ip_conntrack_ftp with PASSIVE FTP does not work

[Chandra.Vempali]

Hi all,

For me, ip_conntrack_ftp does not work for PASSIVE ftp.

In the firewall rules, I blocked everything and put the following rules,
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED,NEW -j
ACCEPT 
iptables -A OUTPUT -p tcp --dport 21 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT 
And when I try to ftp, the control channel goes through firwall, but
data channel fails to pass through.
Is there any thing else I should add to the firewall rules to allow ftp
data through firwall.
Any help will be highly appreciated.
Regards,
Chandra

*Disclaimer*
"This e-mail and any attachments are confidential and may contain trade
secrets or privileged or undisclosed information. They may also be
subject to copyright protection. Please do not copy, distribute or
forward this email to anyone unless authorised. If you are not a named
addressee, you must not use, disclose, retain or reproduce all or any
part of the information contained in this e-mail or any attachments. If
you have received this email by mistake please notify the sender
immediately by return email and destroy/delete all copies of the email."

Re: Ip_conntrack_ftp with PASSIVE FTP does not work

[Jörg Harmuth]

Chandra.Vempali@infineon.com schrieb:
> Hi all,
> 
> For me, ip_conntrack_ftp does not work for PASSIVE ftp.
> 
> In the firewall rules, I blocked everything and put the following rules,
> iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED,NEW -j
> ACCEPT 
> iptables -A OUTPUT -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT 
> And when I try to ftp, the control channel goes through firwall, but
> data channel fails to pass through.
So, your firewall connects to the FTP server, why not. First of all make
sure that ip_conntrack_ftp is compiled into the kernel or as a module.
If compiled as a module, make sure it is loaded.

As your firewall connects to the FTP server and your OUTPUT policy seems
to be DROP or REJECT, you need rules like these:

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 --syn -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Hmm, many people, including myself, think, that filtering in OUTPUT is
pointless. More troublesome than usefull. If you decide to set OUTPUT
policy to ACCEPT, you don't need the first two rules. Up to you.

Have a nice time,

Joerg

RE: Ip_conntrack_ftp with PASSIVE FTP does not work

[Chandra.Vempali]

Hi 
Thanks for your reply.

My ip_conntrack_ftp module gets loaded properly.

If I keep a rule like "iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT"
It means that traffic is allowed to pass through for all ports which should not be done for security reasons.

As for passive FTP, I added two rules to allow traffic thru only 21 port.
iptables -A INPUT -p tcp --sport 21 -m state --state  ESTABLISHED,NEW -j ACCEPT 
iptables -A OUTPUT -p tcp --dport 21 -m  state --state NEW,ESTABLISHED,RELATED -j ACCEPT

So, control messages goes thru firwall successfully.


But for the data, now both server and client work on random ports.
ip_conntrack_ftp module should read this PASSIVE port from FTP message and then it should create an expectation.

In my case, it is creating an expectation too. But when data starts flowing, firewall does not allow
even through it is expectation.

Any help will be highly appreciated ...

Chandra
P.S : I guess there is some patch for this problem.
Can anybody please point me to such patch and how to get it


-----Original Message-----
From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jörg Harmuth
Sent: Wednesday, July 13, 2005 3:09 PM
To: netfilter@lists.netfilter.org
Subject: Re: Ip_conntrack_ftp with PASSIVE FTP does not work


Chandra.Vempali@infineon.com schrieb:
> Hi all,
> 
> For me, ip_conntrack_ftp does not work for PASSIVE ftp.
> 
> In the firewall rules, I blocked everything and put the following 
> rules, iptables -A INPUT -p tcp --sport 21 -m state --state 
> ESTABLISHED,NEW -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -m 
> state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> And when I try to ftp, the control channel goes through firwall, but
> data channel fails to pass through.
So, your firewall connects to the FTP server, why not. First of all make sure that ip_conntrack_ftp is compiled into the kernel or as a module. If compiled as a module, make sure it is loaded.

As your firewall connects to the FTP server and your OUTPUT policy seems to be DROP or REJECT, you need rules like these:

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 --syn -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Hmm, many people, including myself, think, that filtering in OUTPUT is pointless. More troublesome than usefull. If you decide to set OUTPUT policy to ACCEPT, you don't need the first two rules. Up to you.

Have a nice time,

Joerg

Re: Ip_conntrack_ftp with PASSIVE FTP does not work

[Jan Engelhardt]

>> iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED,NEW -j
>> ACCEPT 
>> iptables -A OUTPUT -p tcp --dport 21 -m state --state
>> NEW,ESTABLISHED,RELATED -j ACCEPT 

If using passive ftp, the host you are connecting to does not necessarily send 
from port 21.

>Hmm, many people, including myself, think, that filtering in OUTPUT is
>pointless. More troublesome than usefull. If you decide to set OUTPUT
>policy to ACCEPT, you don't need the first two rules. Up to you.

Not at all. Because certains things can not happen in certain environments, 
e.g. I read/write mail by logging into a mail server via SSH / no sendmail 
running, I can exclude certain things. In netfilter parlance:

 -P OUTPUT ACCEPT (same for FORWARD, btw)
 -A OUTPUT -j REJECT -p tcp --dport 25

This stops users that also have access to my machine to not spam smtp servers, 
should they find an open one.


Jan Engelhardt
-- 

Re: Ip_conntrack_ftp with PASSIVE FTP does not work

[Jörg Harmuth]

Chandra.Vempali@infineon.com schrieb:
> My ip_conntrack_ftp module gets loaded properly.
> 
> If I keep a rule like "iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT"
> It means that traffic is allowed to pass through for all ports which should not be done for security reasons.

No, it means that any packet on any port with any protocol that is in
state ESTABLISHED or RELATED is allowed to pass. Not *all* packets.
Especially SYN packets (in state NEW) don't hit this rule. So, if you
set policy to DROP and allow no NEW packets, no communication can be
established at all. On the other hand, if you allow NEW packets to a
certain port, ofcourse you also want the ESTABLISHED packets and
sometimes the RELATED packets (in case of FTP). So, I don't think this
is a security risc.

If I'm wrong, somebody correct me, please.

> As for passive FTP, I added two rules to allow traffic thru only 21 port.
> iptables -A INPUT -p tcp --sport 21 -m state --state  ESTABLISHED,NEW -j ACCEPT 
> iptables -A OUTPUT -p tcp --dport 21 -m  state --state NEW,ESTABLISHED,RELATED -j ACCEPT

As Jan pointed out, when using passive FTP the source port is not
necessarily 21 - commonly both sides use high ports. I think, the reason
is that your rules are "bound" to port 21, where no RELATED connection
can be established. Thus the rule doesn't match and you hit the DROP
policy. Give

iptables -I [IN | OUT]PUT [-p tcp] -m state \
         --state RELATED,ESTABLISHED -j ACCEPT

a chance for testing. I would bet, it works.

Have a nice time,

Joerg

Re: Ip_conntrack_ftp with PASSIVE FTP does not work

[Jason Opperisano]

On Wed, Jul 13, 2005 at 03:30:37PM +0530, Chandra.Vempali@infineon.com wrote:
> Hi 
> Thanks for your reply.
> 
> My ip_conntrack_ftp module gets loaded properly.
> 
> If I keep a rule like "iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT"
> It means that traffic is allowed to pass through for all ports which should not be done for security reasons.

that's not what it means at all, but your rules as written make no sense
whatsoever, so something's going to have to change.

> As for passive FTP, I added two rules to allow traffic thru only 21 port.
> iptables -A INPUT -p tcp --sport 21 -m state --state  ESTABLISHED,NEW -j ACCEPT 

the only src port tcp 21 traffic are the replies from the server to the
client on the control channel connection.  these packets will never
be NEW. so let's go with:

  iptables -A INPUT -p tcp --sport 21 \
    -m state --state ESTABLISHED -j ACCEPT

> iptables -A OUTPUT -p tcp --dport 21 -m  state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> So, control messages goes thru firwall successfully.

dst port 21 traffic will never be related to anything, they will only be
NEW or ESTABLISHED:

  iptables -A OUTPUT -p tcp --dport 21 \
    -m state --state NEW,ESTABLISHED -j ACCEPT

> But for the data, now both server and client work on random ports.
> ip_conntrack_ftp module should read this PASSIVE port from FTP message and then it should create an expectation.

it does, and it marks those packets as RELATED, which you have not
allowed in your rules, because you do not trust the conntrack mechanism
because you are smarter than it.

> In my case, it is creating an expectation too. But when data starts flowing, firewall does not allow
> even through it is expectation.

the "proper" solution to this is just to use the conntrack functionality
as it was intended:

  iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

but for what ever reason; this is not acceptable to you, so let's HIPPA
them up a bit:

  # allow packets related to FTP connections in
  iptables -A INPUT -p tcp --dport 1024: -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

  # allow packets related to FTP connections out
  iptables -A OUTPUT -p tcp --dport 1024: -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT
  iptables -A OUTPUT -p tcp --dport 20 -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

those rules give the appearance of more security.  if you think that the
conntrack mechanism in netfilter actually works--they offer no security
and simply create administrative and computational overhead.

HTH...

-j

--
"Stewie: Baby needs to suck ash. Baby needs to suck ash. Not ass,
 you pervert.  Save it for the interns."
        --Family Guy

OUTPUT filtering (was: Re: Ip_conntrack_ftp ...)

[/dev/rob0]

Jan Engelhardt wrote:
>>Hmm, many people, including myself, think, that filtering in OUTPUT is
>>pointless. More troublesome than usefull. If you decide to set OUTPUT
>>policy to ACCEPT, you don't need the first two rules. Up to you.
> 
> Not at all. Because certains things can not happen in certain environments, 
> e.g. I read/write mail by logging into a mail server via SSH / no sendmail 
> running, I can exclude certain things. In netfilter parlance:
> 
>  -P OUTPUT ACCEPT (same for FORWARD, btw)
>  -A OUTPUT -j REJECT -p tcp --dport 25
> 
> This stops users that also have access to my machine to not spam smtp servers, 
> should they find an open one.

(Be sure you also restrict access to any sendmail(1)-style mail 
injection binary in that case, if there's an MTA running.)

True, you have illustrated one example of sane OUTPUT filtering. The 
OP's use of OUTPUT filtering was not in this category.

Note that OUTPUT filtering only controls non-root users. A root user can 
disable or bypass it. If you have local shell users who cannot be 
trusted, and if you didn't already understand all this, chances are 
those users already have rooted you. :)

I agree with Joerg above. I don't think you have contradicted his 
general point. Netfilters should:
   1. Learn to walk before they try to run
      Rule of thumb: if you need to post here to try to get explanations
      of what your rules are doing, you're not ready for OUTPUT filters.
   2. Only experiment with carefully-crafted OUTPUT rules
   3. Generally not attempt "iptables -P OUTPUT DROP" (see #1.)
-- 
     mail to this address is discarded unless "/dev/rob0"
     or "not-spam" is in Subject: header

RE: Ip_conntrack_ftp with PASSIVE FTP does not work

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 13 Jul 2005 Chandra.Vempali@infineon.com wrote:

> Hi
> Thanks for your reply.
>
> My ip_conntrack_ftp module gets loaded properly.
>
> If I keep a rule like "iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT"
> It means that traffic is allowed to pass through for all ports which should not be done for security reasons.

no, it means that traffic that is started from the FW is allowed back to 
the FW from whatever system<s> the fw was trying to communicate with to 
begin with.  If you require something more secure then this, then there 
should be no network card in the system to begin with.

>
> As for passive FTP, I added two rules to allow traffic thru only 21 port.
> iptables -A INPUT -p tcp --sport 21 -m state --state  ESTABLISHED,NEW -j ACCEPT
> iptables -A OUTPUT -p tcp --dport 21 -m  state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>

NEW is the problem you though you were abvoiding in the first comment, 
should not be required.  Not unless something totally insecure like 
allowing folks to ftp to the fw from outside.  The rules provied in the 
prior post which you are commenting on her, would require that the fw box 
innitiate the ftp, here you are trying to do something less secure and 
allow anyone to ftp to the fw.   Certainly it is highly unlikly you intend 
to allow that.  rtfm might help, the concepts of NEW, ESTABLISHED and 
RELATED semm to have you confuzzeled.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC1YRnst+vzJSwZikRAu5OAJwJcFX31ZGYx4tkq2HhGBsPeyqbzwCg2ETL
4P5PUgKa9KiTBZitSWs/ANQ=
=qnTq
-----END PGP SIGNATURE-----

Re: OUTPUT filtering

[Amin Azez]

/dev/rob0 wrote:
> Note that OUTPUT filtering only controls non-root users. A root user can
> disable or bypass it. If you have local shell users who cannot be
> trusted, and if you didn't already understand all this, chances are
> those users already have rooted you. :)

Quite so, but output filtering can also be applied to a
firewall/router/bridge with no user accounts.

Amin

Re: OUTPUT filtering

[Jörg Harmuth]

Amin Azez schrieb:
> Quite so, but output filtering can also be applied to a
> firewall/router/bridge with no user accounts.

Definitely this is true. But why would you want to apply output
filtering to a firewall,..., without any user account ? I can't see the
point in this, if we are talking about general output filtering like
having a DROP policy in OUTPUT.

Only locally generated packets go through OUTPUT and most likely you
want this traffic (proxies,...). Given that there is no config error, if
there is unwanted traffic on the box - let's say IRC - chances are best
that the box is compromized and as there is no user account, the
intruder has root priveleges. So he is perfectly able to circumvent any
filtering. So, output filtering didn't help.

Ofcourse there are good reason for single OUTPUT rules - this list
helped me to remember identd, which caused a responding delay of about
30s - but this is not generally.

May be I'm missing important views, but I can't see that output
filtering makes sense.

Have a nice time,

Joerg