[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bugtraq PF vuln issue
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: Bugtraq PF vuln issue
- From: Henning Brauer <lists-openbsd_(_at_)_bsws_(_dot_)_de>
- Date: Tue, 8 Jul 2003 01:02:12 +0200
- Mail-followup-to: misc_(_at_)_openbsd_(_dot_)_org
On Mon, Jul 07, 2003 at 11:28:37PM +0100, Nick Besant wrote:
> I've been watching both tech and misc since this came out but haven't seen any discussion; looking at this I felt this could be due to bad configuration, but I'm not too sure how real the problem is. Does anyone have any thoughts/flames/ideas on this ?
> The article concerns an apparent vulnerability in PF's rdr handling.
oh this one... we got notice before, I consider that pretty boring.
actually, I'd s/low/nonexistant/ ...
Depending on the scenario an attacker could
discover the private IP and/or port number where
packets are redirected to by PF.
first question: what exactly does the "atacker" gain from knowing the
internal IP address... ? pretty much nothing.
then, there are invalid prerequisites. packets with source or target
RFC1918 addresses should never ever enter your network; in any even
close-to-reasonable setup they are already filtered out on the border
even if not, due to the lack of routes to RFC1918 on bgp full mesh
routers, the "attacker" needs to be very very very close to the
"attacked" pf box - in nearly every real-world setup, directly
connected. every intermediate box would need to route the RFC1918
addresses in question to _your_ box! how realistic!
this list can be continued quite a bit more...
so even if an "attacker" might find out the internal IP address of the
system pf rdrs to in a very constructed environment, the impact is
and still, there are multiple ways to work around that.
1) block outgoing packets with src addresses not in the acceptable
range. that should be standard practice.
example: one external IP, 10/8 inside. thus all NAT.
block out quick inet on $ext_if from ! $ext_if
if you have multiple external IPs you might need to use a table or
only do spoof protection filters on the external interface and policy
on the inner one(s) (that's what I'm doing here), tho the latter might
conflict with NAT a bit. anyway, table works always.
2) (-current) use tags instead of passing based on the translated
rdr on $ext_if proto tcp from any to $ext_if port 80 -> 10.0.0.1 port 8080
pass in on $ext_if proto tcp from any to 10.0.0.1 port 8080 keep state
rdr on $ext_if proto tcp from any to $ext_if port 80 tag redirected \
-> 10.0.0.1 port 8080
pass in on $ext_if tagged redirected keep state
3) (-current) use rdr pass.
rdr pass on $ext_if proto tcp from any to $ext_if port 80 -> 10.0.0.1 port 8080
I find it a bit surprising and even, well, annoying that such stuff
makes bugtraq nowadays...
http://2suck.net/hhwl.html - http://www.bsws.de/
Unix is very simple, but it takes a genius to understand the simplicity.