[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pf NAT confusion
First, you should take a moment to consider your current
policy. Why don't you let everything go out?
If you allow access to unrestricted IPs with restricted ports, a
``bad guy'' will just set up a server of his choice to listen on
one of the ports you do allow out. For example, ``sshd -p 80''
will start an ssh daemon listening on port 80. Your packet filter
(whether pf or ipf or PIX or...) won't be able to tell that the
connection being made is ssh rather than HTTP. Tunneling arbitrary
connections over ssh is trivial. Somebody with SSH access to a
computer has the same network access as the remote computer.
If you really want to decide what is and isn't okay to let out,
you need to proxy *everything.* You'll give unrestricted access to
the proxy server, but only run proxies for those services you
actually want to let out. Everything that isn't coming from the
proxy server gets blocked. Note that there are methods to tunnel
IP over HTTP designed to work through a proxy, so even this isn't
foolproof. Anybody who can ssh into the proxy server can bounce
arbitrary ports off it as well, so you probably don't want to let
just anybody log in....
Because of the interactions of NAT and state keeping, the general
method to accomplish what you describe is basically the same as
what's done with a bridging firewall: pick an interface to filter
on, and let everything else through on the other(s). You could,
for example, let everything go through the Internet side of the
firewall, but only permit selected outbound packets to your
servers (with keep state) and selected inbound packets from your
proxy server on the workgroup network. You could still reject all
non-routeable addresses, spoofs, and the like that appear on the
Internet side.
There's another advantage to using a proxy server for everything:
it dramatically reduces the number of IPs you need, and eliminates
the need for NAT for clients that use the proxy. NAT is evil to
begin with; if you can get rid of it, you'll be happier.
According to http://aim.aol.com/#httpproxy you can use AIM with an
HTTP proxy (presumably such as Squid, available in the ports
tree); it also would seem to support SOCKS. I'd strongly
recommend avoiding the AIM native protocol and using the proxy if
at all possible--I've read too many things from people having
trouble with the protocol to make me think it was at all well
designed.
Yours,
b&
On Mon, Apr 01, 2002 at 12:18:43PM -0500, Joel Schander wrote:
> Hello,
>
> I am upgrading several OBSD 2.9 firewalls to 3.0 and am making
> the IP Filter -> pf conversion. I'm seeing something I didn't
> expect when performing NAT for a triple-homed host and hope
> someone can clue me in on the elegant fix -- we dont' like the
> kluge. I didn't see anything in the archives for the past four
> months on the subject, but if I missed it, a link would be
> great.
>
> Network layout:
>
> Workgroup -------- Firewall ------- Net
> |
> |
> |
> |
> Servers
>
> The firewall uses a default deny policy, but all outbound TCP,
> UDP, and ICMP is allowed from the workgroup. Traffic going out
> both the server and Net-side interfaces have a NAT rule setting
> their IP to the appropriate IP used by firewall. Initially,
> everything seemed great -- DNS, HTTP, and SSH traffic got
> through from the workgroup just fine. Then I tried AIM -- never
> connected.
>
> ``pfctl -s state'' returned this (public IP obscured):
>
> TCP 192.168.100.205:1697 -> 24.132.98.223:58824 -> 64.12.26.2:5190
> TIME_WAIT:TIME_WAIT
>
> But the other traffic went through just fine...DNS, HTTP, SSH
> are all allowed out from the firewall to the Net, but AIM isn't,
> so let's try allowing AIM outbound from the firewall's Net-side
> interface...works perfectly:
>
> TCP 192.168.100.205:1697 -> 24.132.98.223:58824 -> 64.12.26.2:5190
> ESTABLISHED:ESTABLISHED
>
> So, we have a kluge -- open up all TCP, UDP, ICMP traffic
> outbound from the Net-side firewall interface -- but we really
> don't want to do that. Can I do the following with one quick,
> keep state rule in pf.conf and one NAT rule per external
> interface in nat.conf?
> - allow workgroup traffic in on the workgroup interface, passing
> quick and keeping state
> - NAT the workgroup traffic on the appropriate external
> interface, using the interface's public IP
> - have that traffic passed through the NATted interfaces as if
> it weren't
>
> <fingers_crossed>
> I really hope It's me doing something wrong and not a case of
> having to use the kluge.
> </fingers_crossed>
>
> Joel
--
Ben Goren
mailto:ben@trumpetpower.com
http://www.trumpetpower.com/
icbm:33o25'37"N_111o57'32"W
[demime 0.98d removed an attachment of type application/pgp-signature]