OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: ftp-proxy binat design -- Was: Re: binat questions

From: Camiel Dobbelaar (cdsentia.nl)
Date: Sun Jul 01 2007 - 12:53:59 CDT


On Sun, 1 Jul 2007, Karl O. Pinc wrote:
> On 03/22/2007 03:17:00 PM, Stuart Henderson wrote:
>
> > One thing to watch out for with binat: you can't use it with
> > ftp-proxy(8), since binat is of higher priority than the rdr or
> > nat rules which are added to the anchor. The workaround there
> > is to list nat and rdr separately.
>
> I just figured this out myself.
>
> binat + ftp-proxy => passive ftp broken
>
> It seems a bit clunky to work-around this in pf.conf
> by doing both an rdr and a nat, and having double the
> states in consequence.
>
> Instead, how does the design below sound?
>
> The basic idea is to modify ftp-proxy so it adds binat
> rules to it's anchors.
>
> ftp-proxy adds a binat rule for every nat rule
> added to its anchors. Like so (based on the man page):
>
> ----<snip>-------
> In case of passive mode (PASV or EPSV):
>
> binat from $client to $server port $port -> $proxy

You cannot use port in binat rules, so that would not work. An
alternative would be to use a

no binat from $client to $server

so the nat rule in the ftp-proxy can take effect. But that would
disable binat completely from $client to $server which is unacceptable,
even for a short while.

I think this problem can only be fixed in pf itself, by not prioritizing
binat and just use the order in which all NAT rules are configured. That
could subtly break some rulesets though, and it might be quite a lot of
work.

So rewriting binat to nat+rdr for hosts that need proxied FTP remains the
only solution.

--
Cam