Hiding NATs with PF

? wrote:[color=blue]
> NAT can hide zombied boxes from regular scans for their currently known
> subset of zombied boxes.
> In addition NAT can prevent them from using existing exploits to install
> spyware.
> Some NAT devices were (and may still be) susceptable to being
> compromised.[/color]

I would understand this, but surely the problem would be just as bad if
firewalls were being used on a single non-NAT host connected to the
same part of the network? Actually, firewalls are mandatory in this
network, so it makes even less sense.
[color=blue]
> As a general rule the 11th commandment (Thou shalt not get caught) applies.
> Do not announce the presence of a NAT device.
> Do not obviously abuse it.
> Be prepared to switch to connecting directly with zero notice.
>
> Remember it's easier to seek forgiveness than permission :-).[/color]

Sage advice :)

Thanks for your input,

Max

Max Bolingbroke wrote:
[color=blue][color=green]
>> Assuming the person who sets the NAT router up is competent, it's not an
>> issue. However, it's not uncommon for internal routing infrastructure to
>> be running on RFC 1918 private IP addresses (the same batch you'll choose
>> your private addresses from). If you (by accident or through stupidity)
>> start letting your "private" addresses through, you could kill parts of
>> their campus routing by poisoning ARP tables.[/color]
>
> Ah, thats interesting! Sounds like a mistake thats pretty hard to make
> though, not on the order of the serious routing overhead they describe.
>[/color]
On the other hand, make it, and you have the potential to completely trash
their routing, to the point that they have to send someone round with a
laptop to work out which segment is confusing things.
[color=blue][color=green]
>> You and I share one IP via NAT; said IP is registered to you. I break
>> into a bank's computer system. When the authorities come to get you, you
>> point the finger at me. I point the finger at you, and we have a
>> standoff. By banning NAT routers, your upstream can get you for
>> unauthorised NAT even if they can't get you for the break-in.[/color]
>
> You're right, I didn't consider a scenario with two users.
>[/color]
Incidentally, I used to know an admin of a university network with the same
policy. His view on it was that unofficially, they didn't go looking for
breaches of this rule, but if a security incident brought it to their
attention, you were *toast* (as in facing the risk of being thrown out
altogether). I would guess that you're in a similar situation, so bear that
risk in mind, and get your configs *right* first time :)
--
Simon Farnsworth

Begin <7oslj1tu7n5b9j2pa6e3shqq1bo4r9f23t@4ax.com>
On 2005-09-28, Greg Hennessy <me@privacy.org> wrote:[color=blue]
> On 28 Sep 2005 11:02:55 -0700, "Max Bolingbroke"
><batterseapower@hotmail.com> wrote:[/color]
[max, please do include attribution lines][color=blue][color=green]
>>The claim is that a NAT router causes upstream routing headaches.
>>Is this true?[/color]
>
> If it's injecting bogus dynamic routing information into whatever IGP
> they are using, yes potentially.
>
> But for a SoHo appliance methinks not.[/color]

Well, they might still run RIP. I know for a fact that it's still in
use in places. And AFAIK there do exist SoHo devices that support
it. Nevermind the half-cluebie who thinks ``I want a router, I need
routed!!1!'', despite being not true and in at least the FreeBSD
handbook documented as such.

At my last place of work[1] I was sorely tempted to setup a fake routed
that injected bogus routes into our uplink, as there were RIP announcements
coming in over that line, ie from the demarc. In retrospect it was probably
the SDSL box on site that did it, but I never bothered to find out exactly
and fix it. It did neither anything useful nor anything harmful, and there
were no users in the neighbourhood to fsck with it.

I didn't bother also in the interests of a good working relationship with
their technical people. They had a really small staff (small isp, only
two techs or so) so I almost never had to deal with ``1st line support'',
instead just starting to talk tech and the secretary would ask me to hold
and get the person on call who'd understand what I'd said. :-)


[1] As a systems and networks admin.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

On 28 Sep 2005 14:04:21 -0700, "Max Bolingbroke"
<batterseapower@hotmail.com> wrote:

[color=blue]
>Heh :). My fallback option was going to be a multihomed system with a
>HTTP proxy doing the "routing", but now I have remembred sockscap I can
>use this, far more general solution.
>
>Many thanks for your help,
>[/color]

You're welcome :-)


Greg
--
"Access to a waiting list is not access to health care"

Simon Farnsworth wrote:[color=blue]
> On the other hand, make it, and you have the potential to completely trash
> their routing, to the point that they have to send someone round with a
> laptop to work out which segment is confusing things.[/color]

Very true :). Just so I know what to avoid, would a pf rule causing
this sort of problem look something like this:

rdr on $int_if proto tcp from any to any port 80 -> $some_external_ip

I have a feeling that this is wrong. It also seems a bit contrived. Is
there some subtler way I could introduce this behaviour accidently?
[color=blue]
> Incidentally, I used to know an admin of a university network with the same
> policy. His view on it was that unofficially, they didn't go looking for
> breaches of this rule, but if a security incident brought it to their
> attention, you were *toast* (as in facing the risk of being thrown out
> altogether). I would guess that you're in a similar situation, so bear that
> risk in mind, and get your configs *right* first time :)[/color]

Duly noted :)

Thanks a lot for your help,

Max

On 28 Sep 2005 09:52:29 -0700, tedu wrote:
[color=blue]
> Does synproxy create a new packet or just tweak the ip of the original?[/color]

Good point. It does create a new one. But the handshake isn't the only
evidence to detect different stacks. I guess it depends on how clever
the ISP is.

They might not even look at TCP fingerprints, but do simple traffic
analysis. Like, two nearly concurrent requests from Windows boxen to
their update service, two applications checking for updates at a
higher rate than expected from a single client, two parallel request
to google, etc.

Daniel

Max Bolingbroke wrote:
[color=blue]
> Simon Farnsworth wrote:[color=green]
>> On the other hand, make it, and you have the potential to completely
>> trash their routing, to the point that they have to send someone round
>> with a laptop to work out which segment is confusing things.[/color]
>
> Very true :). Just so I know what to avoid, would a pf rule causing
> this sort of problem look something like this:
>
> rdr on $int_if proto tcp from any to any port 80 -> $some_external_ip
>[/color]
You need a block rule to get PF to avoid it. Given a table <private> with
all RFC 1918 addresses in it:

block quick on $ext_if from <private> to any

This stops your machine sourcing private addresses, and "all" you need to do
is make sure that the cables *never* get swapped; if your internal
interface is connected to the campus network, you run the risk of big
trouble.
--
Simon Farnsworth

Daniel Hartmeier wrote:[color=blue]
> On 28 Sep 2005 09:52:29 -0700, tedu wrote:
>[color=green]
> > Does synproxy create a new packet or just tweak the ip of the original?[/color]
>
> Good point. It does create a new one. But the handshake isn't the only
> evidence to detect different stacks. I guess it depends on how clever
> the ISP is.[/color]

I had actually tried to use this. However, adding the synproxy state
option to outgoing traffic causes no packets whatsoever to be passed to
the outside! Can anyone see what might be wrong when:

pass out on $ext_if proto tcp all modulate state
pass out on $ext_if proto { udp, icmp } all keep state

Works fine and:

pass out on $ext_if proto tcp all synproxy state
pass out on $ext_if proto { udp, icmp } all keep state

Does not?

Thanks in advance,

Max

On 28 Sep 2005 23:08:43 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
wrote:
[color=blue]
>Begin <7oslj1tu7n5b9j2pa6e3shqq1bo4r9f23t@4ax.com>
>On 2005-09-28, Greg Hennessy <me@privacy.org> wrote:[color=green]
>> On 28 Sep 2005 11:02:55 -0700, "Max Bolingbroke"
>><batterseapower@hotmail.com> wrote:[/color]
>[max, please do include attribution lines][color=green][color=darkred]
>>>The claim is that a NAT router causes upstream routing headaches.
>>>Is this true?[/color]
>>
>> If it's injecting bogus dynamic routing information into whatever IGP
>> they are using, yes potentially.
>>
>> But for a SoHo appliance methinks not.[/color]
>
>Well, they might still run RIP.[/color]

LOL, RIP as the IGP on a campus sized network is too horrifying to
contemplate.




greg
--
"Access to a waiting list is not access to health care"

On 29 Sep 2005 04:25:42 GMT, Daniel Hartmeier <daniel@benzedrine.cx> wrote:

[color=blue]
>They might not even look at TCP fingerprints, but do simple traffic
>analysis.[/color]

True.
[color=blue]
>Like, two nearly concurrent requests from Windows boxen to
>their update service, two applications checking for updates at a
>higher rate than expected from a single client, two parallel request
>to google, etc.[/color]

Easily explained away by claiming use of VMware.



greg
--
"Access to a waiting list is not access to health care"

Simon Farnsworth wrote:[color=blue]
> You need a block rule to get PF to avoid it. Given a table <private> with
> all RFC 1918 addresses in it:
>
> block quick on $ext_if from <private> to any[/color]

Thats a great help. However, at the moment I am testing the NAT by
having it nested within another NAT, so enabling this rule would block
the external interface from sending/recieving any packets since it
itself has an address in the 192.168.1.x range. I remedied this by
using a rule like:

block drop out quick on $ext_if from 192.168.2.0/24 to any

Where the NATed network managed by OpenBSD has addresses in the range
192.168.2.x. This should be OK, right?
[color=blue]
> This stops your machine sourcing private addresses, and "all" you need to do
> is make sure that the cables *never* get swapped; if your internal
> interface is connected to the campus network, you run the risk of big
> trouble.[/color]

Mmm.. poisoning routing information would be the least of my worries
given that I'd be handing out dhcp leases to all and sundry.

Thanks for your help,

Max

Begin <ih7nj1t08v0ef2ifnem0jucj81o6mh39h4@4ax.com>
On 2005-09-29, Greg Hennessy <me@privacy.org> wrote:[color=blue]
> On 28 Sep 2005 23:08:43 GMT, jpd <read_the_sig@do.not.spam.it.invalid>
> wrote:[color=green]
>>Well, they might still run RIP.[/color]
>
> LOL, RIP as the IGP on a campus sized network is too horrifying to
> contemplate.[/color]

It happens. Mind that RIPv2 can do CIDR and that you can easily build a
notwork that is mostly switched. I know of one campus where the routers
did about 5% of the routing decisions, the rest was done by the layer 3
``look what the router does and imitate it'' switches. Don't know about
RIP on that network though. But I'm sure it's still deployed in places.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

Max Bolingbroke wrote:[color=blue]
> Simon Farnsworth wrote:[color=green]
>> You need a block rule to get PF to avoid it. Given a table <private> with
>> all RFC 1918 addresses in it:
>>
>> block quick on $ext_if from <private> to any[/color]
>
> Thats a great help. However, at the moment I am testing the NAT by
> having it nested within another NAT, so enabling this rule would block
> the external interface from sending/recieving any packets since it
> itself has an address in the 192.168.1.x range. I remedied this by
> using a rule like:
>
> block drop out quick on $ext_if from 192.168.2.0/24 to any
>
> Where the NATed network managed by OpenBSD has addresses in the range
> 192.168.2.x. This should be OK, right?
>[/color]
I'm the paranoid type, so I'd just change the table to not include your
external range.

table private const { 10/8, 172.16/12, 192.168/16, !192.168.1/24 } should do
it IIRC.
[color=blue][color=green]
>> This stops your machine sourcing private addresses, and "all" you need to
>> do is make sure that the cables *never* get swapped; if your internal
>> interface is connected to the campus network, you run the risk of big
>> trouble.[/color]
>
> Mmm.. poisoning routing information would be the least of my worries
> given that I'd be handing out dhcp leases to all and sundry.
>[/color]
Which is of course another of their worries; if a DHCP lease gets handed to
another user, breaking their internet, the other user won't think it might
be your fault, they'll blame the helpdesk.

In addition, it's possible that some of their equipment (hopefully not
security critical) gets its own address via DHCP. If that equipment picks
up an address from your DHCP server, they'll have to send someone to hit
it, and that someone will want to hit you. Another good reason to be very
careful, and buy your IT staff some beer :)
--
Simon Farnsworth

Begin <mpnt03-pkt.ln1@rimmer.farnz.org.uk>
On 2005-09-29, Simon Farnsworth <usenet@farnz.org.uk> wrote:[color=blue][color=green]
>> block drop out quick on $ext_if from 192.168.2.0/24 to any
>>
>> Where the NATed network managed by OpenBSD has addresses in the range
>> 192.168.2.x. This should be OK, right?
>>[/color]
> I'm the paranoid type, so I'd just change the table to not include your
> external range.[/color]

I'd rather advocate a rule that *only* allows packets with a valid
public (and locally assigned) source IP to go out the external
interface. This after any NAT operations, of course. But since this is
the ultimate goal, it is a good idea to enforce it in spite of other
possible system faillures.

A good place to filter for RFC1918 (and LINK-LOCAL: 169.254.0.0/16,
and localhost, and so on) addresses is *incoming* on the external
interface, both source and destination. I'd also add a rule that
disallows multicast addresses as source address regardless of direction.
Normally I make a point of doing the right thing WRT returning ICMP
UNREACH packets (within reason, and as long as routable) but multicast
source addresses get dropped without exception.

Multicast addresses as destination are acceptable especially if you're on
a campus where multicast may be enabled and thus be experimented with.

[color=blue][color=green]
>> Mmm.. poisoning routing information would be the least of my worries
>> given that I'd be handing out dhcp leases to all and sundry.
>>[/color]
> Which is of course another of their worries; if a DHCP lease gets handed to
> another user, breaking their internet, the other user won't think it might
> be your fault, they'll blame the helpdesk.[/color]

True. This is another reason why ideally the router/firewall should do
nothing else. If you then add another box that does, oh, I don't know,
DCHP, NFS, SMB, DNS, and whatnot else, it should at least be well-contained
within your network courtesy of the router/firewall.

The only thing that you could add on the router-firewall is a (caching,
as a bonus/exception) proxy to scrub out any protocol level mentioning
of internal addresses. Think also SNMP including Received: headers,
IRC, and so on. Also: multicast service announcements from within your
network. This really needs attention if you're going to use multicast.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

jpd wrote:[color=blue]
>A good place to filter for RFC1918 (and LINK-LOCAL: 169.254.0.0/16,
>and localhost, and so on)[/color]

I use the list from [url]http://www.cymru.com/Bogons/[/url] and I guess there are a
few other places that offer the same information.
If the OP wants to use it as well, please subscribe to the mailing list
or update regularly. This information tends to change now and then...

--
Maurice

Thanks a lot for all your replies on this issue: I'll be checking into
all this stuff over the next few days, and I'll try and adopt the most
paranoid option. I hadn't even thought about multicast either: setting
up a NAT is far more complicated than PF makes it appear :)

Thanks again,

Max

Begin <dhhkgq$7d4$1@linux.z74.net>
On 2005-09-29, Maurice Janssen <mauricej@xs4all.nl> wrote:[color=blue]
> jpd wrote:[color=green]
>>A good place to filter for RFC1918 (and LINK-LOCAL: 169.254.0.0/16,
>>and localhost, and so on) addresses is *incoming* on the external
>>interface, both source and destination.[/color][/color]
[snipping too much context good, too much context snipping not so good][color=blue]
> I use the list from [url]http://www.cymru.com/Bogons/[/url] and I guess there are a
> few other places that offer the same information.
> If the OP wants to use it as well, please subscribe to the mailing list
> or update regularly. This information tends to change now and then...[/color]

This is a nice idea[0] but as you say, and as stated there and noted
elsewhere, but repeated here for it deserves stressing:

Doing this *requires regular maintenance*, so doing it means you take
the responsibility for keeping up with it on you, lest you might break
someones fresh and new ip addresses for no good reason. Not good.

Which is why I'd not recommend it for the casual user, but for large
site admins that can commit to updating (and have a much bigger impact
anyway) it certainly is an option. IE it'd be something for the router
admins of OPs campus' border routers to consider.

See also

[url]http://www.ris.ripe.net/debogon/[/url]
[url]http://www.ripe.net/ripe/draft-documents/deboganising-draft.html[/url]


[0] I have my own scripts for doing that, directly feeding off of the IANA
reserved list[1].
[1] You could also use, say, the SPEWS level 1 list, if you wish, altough
the raw list really improves with aggregating. Caveat emptor, though.

--
j p d (at) d s b (dot) t u d e l f t (dot) n l .