Hiding NATs with PF - BSD

This is a discussion on Hiding NATs with PF - BSD ; ? wrote: > 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 37 of 37

Thread: Hiding NATs with PF

  1. Re: Hiding NATs with PF


    ? wrote:
    > 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.


    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.

    > 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 :-).


    Sage advice

    Thanks for your input,

    Max


  2. Re: Hiding NATs with PF

    Max Bolingbroke wrote:

    >> 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.

    >
    > Ah, thats interesting! Sounds like a mistake thats pretty hard to make
    > though, not on the order of the serious routing overhead they describe.
    >

    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.

    >> 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.

    >
    > You're right, I didn't consider a scenario with two users.
    >

    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

  3. Re: Hiding NATs with PF

    Begin <7oslj1tu7n5b9j2pa6e3shqq1bo4r9f23t@4ax.com>
    On 2005-09-28, Greg Hennessy wrote:
    > On 28 Sep 2005 11:02:55 -0700, "Max Bolingbroke"
    > wrote:

    [max, please do include attribution lines]
    >>The claim is that a NAT router causes upstream routing headaches.
    >>Is this true?

    >
    > If it's injecting bogus dynamic routing information into whatever IGP
    > they are using, yes potentially.
    >
    > But for a SoHo appliance methinks not.


    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 .

  4. Re: Hiding NATs with PF

    On 28 Sep 2005 14:04:21 -0700, "Max Bolingbroke"
    wrote:


    >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,
    >


    You're welcome :-)


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

  5. Re: Hiding NATs with PF

    Simon Farnsworth wrote:
    > 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.


    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?

    > 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


    Duly noted

    Thanks a lot for your help,

    Max


  6. Re: Hiding NATs with PF

    On 28 Sep 2005 09:52:29 -0700, tedu wrote:

    > Does synproxy create a new packet or just tweak the ip of the original?


    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

  7. Re: Hiding NATs with PF

    Max Bolingbroke wrote:

    > Simon Farnsworth wrote:
    >> 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.

    >
    > 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
    >

    You need a block rule to get PF to avoid it. Given a table with
    all RFC 1918 addresses in it:

    block quick on $ext_if from 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

  8. Re: Hiding NATs with PF


    Daniel Hartmeier wrote:
    > On 28 Sep 2005 09:52:29 -0700, tedu wrote:
    >
    > > Does synproxy create a new packet or just tweak the ip of the original?

    >
    > 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.


    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


  9. Re: Hiding NATs with PF

    On 28 Sep 2005 23:08:43 GMT, jpd
    wrote:

    >Begin <7oslj1tu7n5b9j2pa6e3shqq1bo4r9f23t@4ax.com>
    >On 2005-09-28, Greg Hennessy wrote:
    >> On 28 Sep 2005 11:02:55 -0700, "Max Bolingbroke"
    >> wrote:

    >[max, please do include attribution lines]
    >>>The claim is that a NAT router causes upstream routing headaches.
    >>>Is this true?

    >>
    >> If it's injecting bogus dynamic routing information into whatever IGP
    >> they are using, yes potentially.
    >>
    >> But for a SoHo appliance methinks not.

    >
    >Well, they might still run RIP.


    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"

  10. Re: Hiding NATs with PF

    On 29 Sep 2005 04:25:42 GMT, Daniel Hartmeier wrote:


    >They might not even look at TCP fingerprints, but do simple traffic
    >analysis.


    True.

    >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.


    Easily explained away by claiming use of VMware.



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

  11. Re: Hiding NATs with PF

    Simon Farnsworth wrote:
    > You need a block rule to get PF to avoid it. Given a table with
    > all RFC 1918 addresses in it:
    >
    > block quick on $ext_if from to any


    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?

    > 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.


    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


  12. Re: Hiding NATs with PF

    Begin
    On 2005-09-29, Greg Hennessy wrote:
    > On 28 Sep 2005 23:08:43 GMT, jpd
    > wrote:
    >>Well, they might still run RIP.

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


    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 .

  13. Re: Hiding NATs with PF

    Max Bolingbroke wrote:
    > Simon Farnsworth wrote:
    >> You need a block rule to get PF to avoid it. Given a table with
    >> all RFC 1918 addresses in it:
    >>
    >> block quick on $ext_if from to any

    >
    > 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?
    >

    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.

    >> 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.

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

    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

  14. Re: Hiding NATs with PF

    Begin
    On 2005-09-29, Simon Farnsworth wrote:
    >> 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?
    >>

    > I'm the paranoid type, so I'd just change the table to not include your
    > external range.


    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.


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

    > 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.


    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 .

  15. Re: Hiding NATs with PF

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


    I use the list from http://www.cymru.com/Bogons/ 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

  16. Re: Hiding NATs with PF

    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


  17. Re: Hiding NATs with PF

    Begin
    On 2005-09-29, Maurice Janssen wrote:
    > jpd wrote:
    >>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.

    [snipping too much context good, too much context snipping not so good]
    > I use the list from http://www.cymru.com/Bogons/ 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...


    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

    http://www.ris.ripe.net/debogon/
    http://www.ripe.net/ripe/draft-docum...ing-draft.html


    [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 .

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2