Hiding NATs with PF - BSD

This is a discussion on Hiding NATs with PF - BSD ; Hi, It's my first time out with OpenBSD and I'm building a little NAT device. Its been great so far, it's really well put together. I especially like PF, but I'm having trouble making my NAT "invisible". What I mean ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 37

Thread: Hiding NATs with PF

  1. Hiding NATs with PF

    Hi,

    It's my first time out with OpenBSD and I'm building a little NAT
    device. Its been great so far, it's really well put together. I
    especially like PF, but I'm having trouble making my NAT "invisible".
    What I mean by this is that I want to make it look identical to a single
    host on the internet (assume application level proxying is not practical
    in this scenario). I've already enabled the usual suspects in scrub:
    no-df, min-ttl, random-id, fragment reassemble and reassemble tcp. I
    also added state modulation to outgoing traffic for good measure.

    This has covered the two main bases: TTL monitoring and statistical
    analysis of IP IDs. However, I'm still going to be vunerable to passive
    OS fingerprinting. Are there any further ways I can have PF munge my
    outgoing packets so look like they all come from the same flavour of TCP
    stack?

    Thanks in advance!

    Max Bolingbroke

  2. Re: Hiding NATs with PF

    Begin
    On 2005-09-28, Max Bolingbroke wrote:
    > This has covered the two main bases: TTL monitoring and statistical
    > analysis of IP IDs. However, I'm still going to be vunerable to passive
    > OS fingerprinting.


    Vulnerable in what way? If the boxen behind it aren't reachable there
    isn't much to attack on that level, now is there?


    > Are there any further ways I can have PF munge my
    > outgoing packets so look like they all come from the same flavour of TCP
    > stack?


    Thought of upper-level leakage, like received: headers in outgoing email?


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

  3. Re: Hiding NATs with PF

    On Wed, 28 Sep 2005 03:01:55 +0100, Max Bolingbroke
    wrote:


    >This has covered the two main bases: TTL monitoring and statistical
    >analysis of IP IDs. However, I'm still going to be vunerable to passive
    >OS fingerprinting.


    What are you protecting yourself against exactly ?

    > Are there any further ways I can have PF munge my
    >outgoing packets so look like they all come from the same flavour of TCP
    >stack?




    You mean a http://lcamtuf.coredump.cx/p0f-help/
    response looking something like ?

    UNKNOWN [65535:56:1:64:M1438,N,W3,N,N,T,S,E:P:?:?] (up: 8454 hrs) ->
    213.134.128.25:80 (link: unknown-1478)


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

  4. Re: Hiding NATs with PF

    On Wed, 28 Sep 2005 03:01:55 +0100, Max Bolingbroke wrote:

    > assume application level proxying is not practical
    > in this scenario


    Why?

    It doesn't have to be application level, a generic TCP proxy will do.
    You can redirect connections to it transparently (without the clients'
    cooperation) and have the proxy find out the real destination from pf,
    connect there and relay. All outgoing connections will then originate
    from the OpenBSD box and have its fingerprints.

    Or did you mean 'economical', as in you're (ab)using an ISP contract
    prohibiting multiple hosts to safe a couple of dollars a month, and
    those savings do not warrant you spending time on the setup? Sorry,
    in that case it's not worth anyone else's time, either.

    > Are there any further ways I can have PF munge my
    > outgoing packets so look like they all come from the same flavour of TCP
    > stack?


    No.

    Daniel

  5. Re: Hiding NATs with PF


    jpd wrote:
    > Begin
    > On 2005-09-28, Max Bolingbroke wrote:
    > > This has covered the two main bases: TTL monitoring and statistical
    > > analysis of IP IDs. However, I'm still going to be vunerable to passive
    > > OS fingerprinting.

    >
    > Vulnerable in what way? If the boxen behind it aren't reachable there
    > isn't much to attack on that level, now is there?


    I'm not concerned about attacks here, I was talking about the scenario
    whereby my outgoing requests could be captured and analysed to
    determine I had more than 1 OS accessing the internet simultaneously.
    This would make the NAT "visible".

    > > Are there any further ways I can have PF munge my
    > > outgoing packets so look like they all come from the same flavour of TCP
    > > stack?

    >
    > Thought of upper-level leakage, like received: headers in outgoing email?


    Sure have. Since my original post I've implemented a transparent Squid
    proxy which scrubs my outgoing HTTP requests of identifying
    information. I'm less worried about infrequently used protocols like
    SMTP/POP since they are quite unusual ways to detect, which would most
    likely require manual monitoring. I just want to be able to beat
    automatic tools here: it's simply to hard to win against a human to be
    worth it.

    Thanks for your reply,

    Max


  6. Re: Hiding NATs with PF

    > What are you protecting yourself against exactly ?

    Well, the problem is that I am going to be connecting to a network
    which has a strict limit of 1 IP address per person but also
    inexplicably has a policy where you are not allowed to run your own
    router. I'm trying to circumvent this restriction . If you don't want
    to help me given this, I would understand.

    > > Are there any further ways I can have PF munge my
    > >outgoing packets so look like they all come from the same flavour of TCP
    > >stack?

    >
    > You mean a http://lcamtuf.coredump.cx/p0f-help/
    > response looking something like ?
    >
    > UNKNOWN [65535:56:1:64:M1438,N,W3,N,N,T,S,E:P:?:?] (up: 8454 hrs) ->
    > 213.134.128.25:80 (link: unknown-1478)


    That would be nice, but I've been using that page to diagnose my setup
    and it stubbonly tells me I am running OpenBSD whatever I do. How did
    you achieve this signature? With PF?

    Thanks for your reply,

    Max


  7. Re: Hiding NATs with PF

    > > assume application level proxying is not practical
    > > in this scenario

    >
    > Why?
    >
    > It doesn't have to be application level, a generic TCP proxy will do.
    > You can redirect connections to it transparently (without the clients'
    > cooperation) and have the proxy find out the real destination from pf,
    > connect there and relay. All outgoing connections will then originate
    > from the OpenBSD box and have its fingerprints.


    Really? That sounds very interesting, I was not aware of such a TCP
    proxy. I'll start googling now, but I would be much obliged if you
    would point me to a guide on how to do this or link me to the relevant
    programs. Thanks!

    > Or did you mean 'economical', as in you're (ab)using an ISP contract
    > prohibiting multiple hosts to safe a couple of dollars a month, and
    > those savings do not warrant you spending time on the setup? Sorry,
    > in that case it's not worth anyone else's time, either.


    I've explained my situation in my reply to Greg Hennessy. If the
    network I was attaching to allowed me to pay more for more IP addresses
    I would gladly do so rather than attempt this elaborate and time
    consuming scheme, but they don't offer that flexibility.

    > > Are there any further ways I can have PF munge my
    > > outgoing packets so look like they all come from the same flavour of TCP
    > > stack?

    >
    > No.


    Nice to see my PF research caught everything! As I said above, I would
    be very grateful for any information about transparent TCP proxying
    with PF.

    Thanks for your reply,

    Max


  8. Re: Hiding NATs with PF


    Daniel Hartmeier wrote:
    > On Wed, 28 Sep 2005 03:01:55 +0100, Max Bolingbroke wrote:


    > > Are there any further ways I can have PF munge my
    > > outgoing packets so look like they all come from the same flavour of TCP
    > > stack?


    > No.


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


  9. Re: Hiding NATs with PF

    On 28 Sep 2005 07:53:23 -0700, "Max Bolingbroke"
    wrote:

    >> What are you protecting yourself against exactly ?

    >
    >Well, the problem is that I am going to be connecting to a network
    >which has a strict limit of 1 IP address per person but also
    >inexplicably has a policy where you are not allowed to run your own
    >router. I'm trying to circumvent this restriction . If you don't want
    >to help me given this, I would understand.



    How do they 'enforce' this policy exactly ? I've worked in environments
    with ridiculous policies because some clueless idiot copied something out
    of a textbook.

    Dictating the network architecture of an external 3rd party would fit the
    'ridiculous' category.

    Dictating to anyone connecting over the internet that they cannot have a
    router and are required to directly expose their network would definitely
    fit into the 'ridiculous' category.


    >
    >> > Are there any further ways I can have PF munge my
    >> >outgoing packets so look like they all come from the same flavour of TCP
    >> >stack?

    >>
    >> You mean a http://lcamtuf.coredump.cx/p0f-help/
    >> response looking something like ?
    >>
    >> UNKNOWN [65535:56:1:64:M1438,N,W3,N,N,T,S,E:P:?:?] (up: 8454 hrs) ->
    >> 213.134.128.25:80 (link: unknown-1478)

    >
    >That would be nice, but I've been using that page to diagnose my setup
    >and it stubbonly tells me I am running OpenBSD whatever I do. How did
    >you achieve this signature?



    That's done using transparent squid in the middle.

    >With PF?


    Yep, worked a treat on OpenBSD and currently on Free.

    Regarding Daniel's comment on proxies, you could do a lot worse than using
    the Dante socks proxy (dunno if it's in the OpenBSD ports tree, it is in
    FreeBSD)

    If you're using win32 on the LAN side of your network adding sockscap to
    the mix makes using it seamless from all applications.


    Greg


    >
    >Thanks for your reply,
    >
    >Max

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

  10. Re: Hiding NATs with PF

    Begin <5dhlj1lh74hdtmkb5ekb2ncc9k498d47lh@4ax.com>
    On 2005-09-28, Greg Hennessy wrote:
    > On 28 Sep 2005 07:53:23 -0700, "Max Bolingbroke"
    > wrote:
    >>Well, the problem is that I am going to be connecting to a network
    >>which has a strict limit of 1 IP address per person but also
    >>inexplicably has a policy where you are not allowed to run your own
    >>router. I'm trying to circumvent this restriction . If you don't want
    >>to help me given this, I would understand.

    >
    > How do they 'enforce' this policy exactly ? I've worked in environments
    > with ridiculous policies because some clueless idiot copied something out
    > of a textbook.


    Not to mention the time it would take humans to go out and try and
    detect this.

    To the OP: Are there policies on using vmware or similar
    multiple-os-per-machine constructs?


    > Dictating the network architecture of an external 3rd party would fit the
    > 'ridiculous' category.


    Ah, but if the OP is on a campus or something, _his_ network may
    very well be counted part of the network the policy is set for.

    I know of such networks where there is a strict ``no nat'' policy
    because they don't want to deal with abuse hidden by that and the
    resulting expected gefingerpointing. I can't blame them for their
    motives.


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

  11. Re: Hiding NATs with PF


    Greg Hennessy wrote:
    > >That would be nice, but I've been using that page to diagnose my setup
    > >and it stubbonly tells me I am running OpenBSD whatever I do. How did
    > >you achieve this signature?

    >
    >
    > That's done using transparent squid in the middle.


    Ah, really? Even with my transparent squid setup I still get OpenBSD
    detected (which I guess is what I expected, since its the OpenBSD
    router which will be initating the connections to be proxied back to
    the client). Is there particular squid configuration directives I
    should be looking at to get your behaviour?

    > Regarding Daniel's comment on proxies, you could do a lot worse than using
    > the Dante socks proxy (dunno if it's in the OpenBSD ports tree, it is in
    > FreeBSD)
    >
    > If you're using win32 on the LAN side of your network adding sockscap to
    > the mix makes using it seamless from all applications.


    Ah, I forgot totally about sockscap! I'll certainly look into that,
    thank you.

    Thanks again for your help,

    Max


  12. Re: Hiding NATs with PF

    > > How do they 'enforce' this policy exactly ? I've worked in environments
    > > with ridiculous policies because some clueless idiot copied something out
    > > of a textbook.

    >
    > Not to mention the time it would take humans to go out and try and
    > detect this.
    >
    > To the OP: Are there policies on using vmware or similar
    > multiple-os-per-machine constructs?


    None. The only restriction is against routers. The claim is that a NAT
    router causes upstream routing headaches. Is this true? I would have
    thought that since it acts just like a single host all the performance
    penalty is occured by the NAT device itself, as ti does the source port
    translation etc.

    > Ah, but if the OP is on a campus or something, _his_ network may
    > very well be counted part of the network the policy is set for.


    Exactly.

    > I know of such networks where there is a strict ``no nat'' policy
    > because they don't want to deal with abuse hidden by that and the
    > resulting expected gefingerpointing. I can't blame them for their
    > motives.


    Interesting, they don't cite that as a reason. What abuse could be
    hidden by a NAT that could not be hidden by a single host with firewall
    enabled? Could you please tell me if the one they give (above) is
    actually valid? If so I will of course comply with their request.

    Thanks for your reply,

    Max


  13. Re: Hiding NATs with PF

    Max Bolingbroke wrote:

    > None. The only restriction is against routers. The claim is that a NAT
    > router causes upstream routing headaches. Is this true? I would have
    > thought that since it acts just like a single host all the performance
    > penalty is occured by the NAT device itself, as ti does the source port
    > translation etc.
    >

    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.

    >> I know of such networks where there is a strict ``no nat'' policy
    >> because they don't want to deal with abuse hidden by that and the
    >> resulting expected gefingerpointing. I can't blame them for their
    >> motives.

    >
    > Interesting, they don't cite that as a reason. What abuse could be
    > hidden by a NAT that could not be hidden by a single host with firewall
    > enabled? Could you please tell me if the one they give (above) is
    > actually valid? If so I will of course comply with their request.
    >

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

  14. Re: Hiding NATs with PF

    On 28 Sep 2005 17:29:40 GMT, jpd
    wrote:


    >> How do they 'enforce' this policy exactly ? I've worked in environments
    >> with ridiculous policies because some clueless idiot copied something out
    >> of a textbook.

    >
    >Not to mention the time it would take humans to go out and try and
    >detect this.


    Quite, and it requires 'specialist' (read expensive) know how to do this.


    >> Dictating the network architecture of an external 3rd party would fit the
    >> 'ridiculous' category.

    >
    >Ah, but if the OP is on a campus or something, _his_ network may
    >very well be counted part of the network the policy is set for.


    That's true.

    >
    >I know of such networks where there is a strict ``no nat'' policy
    >because they don't want to deal with abuse hidden by that and the
    >resulting expected gefingerpointing. I can't blame them for their
    >motives.


    Much easier to police using a default deny policy :-)



    greg

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

  15. Re: Hiding NATs with PF

    On 28 Sep 2005 11:02:55 -0700, "Max Bolingbroke"
    wrote:

    >> > How do they 'enforce' this policy exactly ? I've worked in environments
    >> > with ridiculous policies because some clueless idiot copied something out
    >> > of a textbook.

    >>
    >> Not to mention the time it would take humans to go out and try and
    >> detect this.
    >>
    >> To the OP: Are there policies on using vmware or similar
    >> multiple-os-per-machine constructs?

    >
    >None. The only restriction is against routers.



    I can see some reasoning for that with potential issues to do with dynamic
    routing and as Simon says, 'leakage'.

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


    >> I know of such networks where there is a strict ``no nat'' policy
    >> because they don't want to deal with abuse hidden by that and the
    >> resulting expected gefingerpointing. I can't blame them for their
    >> motives.

    >
    >Interesting, they don't cite that as a reason. What abuse could be
    >hidden by a NAT that could not be hidden by a single host with firewall
    >enabled?


    Nothing routing related, but as Simon also says, if your LAN is compromised
    with a hijacked system......


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

  16. Re: Hiding NATs with PF

    On 28 Sep 2005 10:35:26 -0700, "Max Bolingbroke"
    wrote:


    >
    >Ah, really? Even with my transparent squid setup I still get OpenBSD
    >detected (which I guess is what I expected, since its the OpenBSD
    >router which will be initating the connections to be proxied back to
    >the client).


    Try adding the following to your OpenBSD recipe :-)

    ~ # grep -i scrub /etc/pf.conf
    scrub on $Ext all reassemble tcp random-id max-mss 1438

    The MSS figure may not be optimal for your network, do experiment as
    appropriate.


    ~ # grep -i inet /etc/sysctl.conf | grep -v "^#"
    net.inet.tcp.recvspace=262144
    net.inet.tcp.sendspace=262144

    Cant remember if the sysctls share the same OID's on Open.
    So you may have to tweak.

    >Is there particular squid configuration directives I
    >should be looking at to get your behaviour?


    Here's what's different in my squid.conf when compared to the default one.

    /usr/local/etc/squid # diff -u squid.conf.default squid.conf | egrep -v\
    "#|^\@@" | grep "^\+[a-z].*"
    +http_port 127.0.0.1:3128
    +icp_port 0
    +udp_incoming_address 127.0.0.1
    +cache_mem 256 MB
    +maximum_object_size 32768 KB
    +maximum_object_size_in_memory 4096 KB
    +fqdncache_size 2048
    +cache_replacement_policy heap GDSF
    +memory_replacement_policy heap GDSF
    +cache_dir diskd /usr/local/squid/cache 2000 16 256
    +cache_store_log none
    +acl snmppublic snmp_community somecommunitystring
    +acl our_networks src 192.168.0.0/24 192.168.1.0/24 127.0.0.0/8
    +acl intellitxt dstdom_regex .intellitxt.com
    +acl contextclick dstdom_regex .contextclick.com
    +acl kontera dstdom_regex .kontera.com
    +acl digitalmediaonline dstdom_regex .digitalmediaonlineinc.com
    +http_access deny intellitxt
    +http_access deny contextclick
    +http_access deny kontera
    +http_access deny digitalmediaonline
    +http_access allow our_networks
    +http_access deny to_localhost
    +icp_access deny all
    +visible_hostname cache
    +httpd_accel_host virtual
    +httpd_accel_port 0
    +httpd_accel_with_proxy on
    +httpd_accel_uses_host_header on
    +forwarded_for off
    +snmp_access allow snmppublic localhost
    +snmp_incoming_address 127.0.0.1
    +wccp_incoming_address 127.0.0.1

    >> If you're using win32 on the LAN side of your network adding sockscap to
    >> the mix makes using it seamless from all applications.

    >
    >Ah, I forgot totally about sockscap! I'll certainly look into that,
    >thank you.


    Strictly speaking, a multi homed unix box with Socks on one interface and
    routing disabled between them cannot be described as a 'router' per-ce.

    Think of it as obeying the letter rather than spirit of the directive LOL.



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

  17. Re: Hiding NATs with PF

    On 28 Sep 2005 11:02:55 -0700 in <1127930574.982857.72530@g14g2000cwa.googlegroups.c om> Max Bolingbroke wrote:
    >
    > Interesting, they don't cite that as a reason. What abuse could be
    > hidden by a NAT that could not be hidden by a single host with firewall
    > enabled? Could you please tell me if the one they give (above) is
    > actually valid? If so I will of course comply with their request.


    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.

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


    --
    Chris Dukes
    Suspicion breeds confidence -- Brazil

  18. Re: Hiding NATs with PF

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

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

    Thanks very much for your help,

    Max


  19. Re: Hiding NATs with PF


    Greg Hennessy wrote:
    > >Interesting, they don't cite that as a reason. What abuse could be
    > >hidden by a NAT that could not be hidden by a single host with firewall
    > >enabled?

    >
    > Nothing routing related, but as Simon also says, if your LAN is compromised
    > with a hijacked system......


    I see. I would have considered this only as bad as having a single
    attached PC (no NAT) comprimised, but they may have their reasons..

    Thanks for your help,

    Max


  20. Re: Hiding NATs with PF


    Greg Hennessy wrote:
    > ~ # grep -i inet /etc/sysctl.conf | grep -v "^#"
    > net.inet.tcp.recvspace=262144
    > net.inet.tcp.sendspace=262144
    >
    > Cant remember if the sysctls share the same OID's on Open.
    > So you may have to tweak.


    They are the same, just FYI. All your settings worked beautifully

    > Strictly speaking, a multi homed unix box with Socks on one interface and
    > routing disabled between them cannot be described as a 'router' per-ce.
    >
    > Think of it as obeying the letter rather than spirit of the directive LOL.


    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,

    Max


+ Reply to Thread
Page 1 of 2 1 2 LastLast