Re: Iptables FTP question
From: David (davidwnh_at_adelphia.net)
Date: 10/25/03
- Next message: David: "Re: lsass.exe"
- Previous message: Jens Hoffmann: "Re: DHCP"
- In reply to: Peter Eberz: "Re: Iptables FTP question"
- Next in thread: Maxime Ducharme: "Re: Iptables FTP question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 25 Oct 2003 09:11:32 GMT
The new helper module looks good. Definitely seems to tighten up things
for someone who has more than one module loaded that provide support
for secondary connections. It allows you to write distinct RELATED
rules to deal with different modules. It could also add a bit more
security for poorly programmed modules or for people who tend to write
poorly implemented rulesets. The tcp-window-tracking module doesn't
really deal with your problem, but is more just something that tightens
up the connection tracking module overall.
>
> The -m helper "ftp" which was suggested by Cedric will propably do what I
> am looking for. Since it is in the office 1.2.8 it is likely to be more
> reliable. I will check out the tcp-window-tracking as well to see how it
> works and if it will do the job.
>
>
Some ftp servers don't allow passive mode because it is less safe from
the server side of things, but I will show you below how passive mode is
safer for the client end. It's actually quite easy to get past some ftp
algs that allow port mode for client machines.
>
>
> Yes the active FTP is not so tricky. This is only possible to use from
> the command line and a few clients like gftp.
> No problem for me, but all browers and most FTP clients use passive FTP as
> default.
>
>
You are not opening the whole range of high ports in the passive mode
rules. The rules only bypass your other rules when dealing with
established or related traffic that match an entry in the state table.
So what truly defines the allowable ports are your rules for new and
related connections and how tight the modules you use for protocols that
generate secondary connections are. If your rules for new and related
sessions are tight then any "established" traffic will be coming inbound
only from the specific service ports for which you have allowed your
client machines to access in the first place. Take a closer look at the
rules for passive and you will notice that the RELATED statement is only
used in the rule to forward from inside your firewall to the internet.
This means that a new state table entry for a secondary connection can
only be initiated from inside and only within the context of the modules
that you are using on your firewall that support RELATED. So if you are
only using the ftp module it has to be done with an ftp port command
initiated from inside your firewall. So even though the port mode rule
only allows for a source port of 20 coming in, it allows for the
secondary connections to be initiated from outside as is required by
port mode ftp. This is why most client programs default to passive mode
these days. So even though the incoming rule for passive looks like it
allows more, it doesn't as long as you don't write lousy or conflicting
new and related rules for your other protocols. You have to keep in mind
that although incoming established rules may have very few restrictions,
they are still restricted by the ports and addresses, etc that you are
using in your NEW and RELATED rules because there has to a matching
entry in the state table.
>>For Passive mode data connections
>>
>>iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --sport 1024: --dport
>>1024: -m state --state ESTABLISHED -j ACCEPT
>>iptables -A FORWARD -i $INTIF -o $EXTIF -p tcp --sport 1024: --dport
>>1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>
>
Ultimately you don't want any port checking on your incoming established
rule(unless you are using this info to jump to other chains) because it
is most efficient without it. Your rules that establish new and related
connections should control which ports you allow connections for in the
first place. That is why my optimized example in the other post had none
and is also why you should use separate rules for established and
related. All the port checking is done during the session handshake so
the combinations of source and destinations ports, addresses, etc. that
you aren't allowing there will never match a state table entry for any
established traffic.
> Yes, this is an option that is a little bit stricter than mine but not a
> lot. I do not want to open a complete port range just for passive FTP to work.
> OK this rule protects the priviledged ports but all others are open.
> Additionally it conficts with my security policy (just to open the absolut
> minimum, no port ranges).
>
>
- Next message: David: "Re: lsass.exe"
- Previous message: Jens Hoffmann: "Re: DHCP"
- In reply to: Peter Eberz: "Re: Iptables FTP question"
- Next in thread: Maxime Ducharme: "Re: Iptables FTP question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
