[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: self-defeating pf?

At 03:28 AM 7/27/2002 -0700, Rudolfo Munguia wrote:
>On Sat, 27 Jul 2002, David Norman wrote:
>> > > You could do:
>> > > pass in quick on fxp0 proto tcp from any to any port 80 flags S/SA 
>> > > keep state
>> > 
>> > rdr does keep state, therefore keep state doesn't need to be 
>> > called by the filter rule. And placing 'from any to any' in 
>> > the filter rules just makes a larger hole.

>> It still only passes requests bound for port 80 and rdr should force it
>> on to the internal IP. A external request for your internal IP would
>point of fact: if rdr forced the packets to the internal ip then we
>wouldn't be having this exchange :)
	Point of fact: that's the point of a rdr.

>> never work because it wouldn't route on the internet (a request for
>> won't ever get to your machine from the
>> outside). Make it 'from any to extif' if you want.
>I am not worried about a 'request' to an internal address because that
>would not be routed, what I am worried about there is spoofing, where the
>source ip in the packet header is written with my internal ip so as to
>fool the state machine into seeing the incoming packets as belonging on
>the internal network.
	Um, it kinda would route.  You're contradicting yourself.

In the FAQ, there is a rule for:

block in quick on fxp0 inet from {,, \, } to any
block out quick on fxp0 inet from any to {,, \, }

This is there (in the sample configuration) for exactly that reason.
And I hate to tell David this, but I do see packets for RFC1918 addresses
show up at my edge firewall.  They happen.  They're not supposed to, but
tell my luser ISP and other luser ISPs to filter that shit at their border

Referring back to your *first* email:

>Allowing 'from any to private ip port 80' on ExtInt (as per the man page)
>will not only allow the re-directed packets through, but it will defeat
>the purpose of having the re-direct.(I can't be the only one who see's
>this as a gaping hole)
	Say it with me.  NAT before PF.  You MUST do that rule for any traffic to
reach that internal resource.  Trust me, I've been bitten in the ass by
that more times than I can count.
The gaping hole is the "from any".  Redirects are not there for security
purposes, they are to provide external access to internal ports on
privately addressed systems.  You want to be a part of the public Internet?
 You pays your money and you takes your chances.  Your application software
needs to be as secure as you can make it in this instance.


This is also a good place for a DMZ subnet where you can isolate publically
exposed servers, to prevent servers that *might* get exploited from taking
out the rest of your network.  Use a block out all from the DMZ interface
to the Internal interface, and a pass out (whatever) from the internal to
the DMZ, keeping state, no NAT needed (unless you want it)
In fact, unless there is a concrete reason to be running this server on
8080 (such as another webserver using 80, etc.), I highly suggest
simplifying the issue and just use port 80.  Using an alternate port for
security purposes is security through obscurity.

Here's an example of what I did for a redirect, from an example I'm
currently using.  The access is from any subnet I control directly, the
destination is a Citrix server on a nonstandard port:
(Yes, there is a block in all before these lines, assume the packets would
be denied otherwise)

ManagedNets="{ foo.foo.foo.foo/26, bar.bar.bar.bar/27, baz.baz.baz.baz/27 }"
Citrix = "int.int.int.int"

rdr on fxp0 proto tcp from $ManagedNets to \
$ExtIf port 1234 -> $Citrix port 1494

pass in log quick on fxp0 inet proto tcp from $ManagedNets \
	to $Citrix port 1494 flags S/SA keep state label Citrix-ica

s/$ManagedNets/any in your instance.

>We can't create an anti-spoofing rule to protect ourselves from aliens,
>as we would still have to leave it open to packets from ourself destined
>to our private ip space. (basically allowing spoofing anyway)
	Hint - Split horizon DNS.
	Hint - NAT's can't be reversed through an interface anyway.
	And see above about those other blocking rules.

And I don't see how.  LAN clients talk to LAN clients directly if they are
on the same subnet, not through the gateway.

Signing off, 

Joseph Bender
benderjc (at) benderhome.net
This account is used primarily for reading and responding to mailing list
traffic and is not my main mailing address.

Visit your host, monkey.org