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

[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
-- 

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: 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