Yes. If you can't ensure that the ftp server never has a vulnerable
   service listen on a port inside the range used for ftp passive data
   connections [...]

I would hope that I am always able to ensure this.  But it's a matter
of 'security in depth': you may as well firewall the systems you
believe to be secure, not just those you believe not to be.

It might conceivably defeat a backdoor that a hacker plants should the
FTP server have a vulnerability.  Don't underestimate the
effectiveness of this -- given that most compromises are made by
script kiddies running exploit scripts, anything that stops the script
from behaving as expected might save you.  And if nothing else the
firewall might protect you from configuration errors on your server...

   [...] you could use ftp-proxy with the reverse proxy diff (see
   archive)

I have to admit that I can't immediately see why ftp-proxy should need
to be patched to allow this.  Isn't this just the same as the usual
case?

   I don't understand how the ability to specify both interfaces in a
   single rule in iptables helps you there. 

In my case the routing table is static, and it's largely just a
syntactic convenience (but an important one)

I currently (in ipchains) find myself doing the equivalent of:

   pass in on <interface_A> to <long_list_of_networks_behind_interface_B> ...

which results in a rule that is far more complex than what I am
conceptually trying to accomplish.  It also means that the long list
of networks behind interface B has to be maintained in two places,
namely in my static routes and in my packet filters -- and there is a
security risk if an error is made editing these lists.

iptables allows me to neatly sidestep this issue by defining my rules
in topological terms.  I can write a rule that applies to packets sent
from interface A to interface B without having to hardwire the list of
networks into my packet filters.

(And the explicit form gets really messy when you have a network
routed out of one interface, except for a small subnet of it which
sits on another interface.)

     -roy

Reply via email to