Re: [Full-Disclosure] NAT router inbound network traffic subversion

Bart.Lansing_at_kohls.com
Date: 01/28/05

  • Next message: byte busters: "Fwd: [Full-Disclosure] FW: MS Antispyware makes deal to leave Weatherbug alone" 
    To: <bart2k@hushmail.com>
Date: Fri, 28 Jan 2005 12:48:15 -0600

    Actually...if you bothered to read the whole work, and did not just skim
    it, you would see that the team at Columbia very specificially states that
    their analytic techniques can be easily confused, and that there are basic
    steps for NAT use/configuration that render their techniques basically
    useless. Also, as intranet traffic fogs their results considerably, they
    state that this technique is not at all valid where such traffic occurs.
    There are more caveats, such as proximity to the source NAT device,
    etc...as well as the process missing multiple machines...in the paper, but
    enough...you get my point.

    No offense, but their work does not say what you said it says.

    Bart Lansing
    Manager, Desktop Services/Lotus Notes
    Kohl's IT

    full-disclosure-bounces@lists.netsys.com wrote on 01/28/2005 10:26:40 AM:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Check it here -> http://www1.cs.columbia.edu/~smb/papers/fnat.pdf
    >
    > This should help clarify why NAT can not be considered a security
    > feature.
    >
    >
    > On Thu, 27 Jan 2005 22:12:19 -0800 Kristian Hermansen
    > <khermansen@ht-technology.com> wrote:
    > >I have Googled around and asked a highly-respected Professor at my
    > >University whether it is possible to direct packets behind a NAT
    > >router
    > >without the internal 192.168.x.x clients first requesting a
    > >connection
    > >to the specific host outside. The answer I received is "not
    > >possible".
    > >I also asked if this can be thought of as a security feature, to
    > >which
    > >the reply was again "yes".
    > >
    > >Now, I wouldn't place all my bets on his answer and I am calling
    > >on
    > >someone out there to clear up my question. If NAT really does
    > >only
    > >allow inbound connections with a preliminary request as he
    > >suggests, it
    > >seems that the only way to get an "unauthorized" packet behind the
    > >router is by some flaw in the firmware of the device.
    > >
    > >How about if the client has requested a connection to Google.com
    > >from
    > >behind his Linksys home NAT router: would it be possible for an
    > >outside
    > >attacker to spoof packets from Google's IP to get packets into the
    > >network? Or do we need to know the sequence numbers as well? Or
    > >is
    > >there an even more devious way to get packets on the inside
    > >without a
    > >client's initiative?
    > >
    > >Has there been any research into this? Are there statistics on
    > >worm
    > >propagation and exploited network hosts in relation to those
    > >individuals
    > >that did not own routers (and instead connected directly to their
    > >modem)? If *all* home users on the Internet had NAT routers
    > >during the
    > >summer of 2003, would we have significantly slowed the spread of
    > >Blaster? I believe these all to be very important questions and
    > >the
    > >security aspects of the ability to route packets behind NAT really
    > >interests me...maybe some of you can elaborate :-)
    > >--
    > >Kristian Hermansen <khermansen@ht-technology.com>
    > -----BEGIN PGP SIGNATURE-----
    > Note: This signature can be verified at https://www.hushtools.com/verify
    > Version: Hush 2.4
    >
    > wkYEARECAAYFAkH6Z/UACgkQ1kZ6e0Djf6zn3wCgiIb4yUWKP82hge9Oml7Qp75lOR0A
    > oK4bjNPHtARambOFA4IallqA/b8C
    > =Z8vB
    > -----END PGP SIGNATURE-----
    >
    >
    >
    >
    > Concerned about your privacy? Follow this link to get
    > secure FREE email: http://www.hushmail.com/?l=2
    >
    > Free, ultra-private instant messaging with Hush Messenger
    > http://www.hushmail.com/services-messenger?l=434
    >
    > Promote security and make money with the Hushmail Affiliate Program:
    > http://www.hushmail.com/about-affiliate?l=427
    > _______________________________________________
    > Full-Disclosure - We believe in it.
    > Charter: http://lists.netsys.com/full-disclosure-charter.html

    CONFIDENTIALITY NOTICE:
    This is a transmission from Kohl's Department Stores, Inc.
    and may contain information which is confidential and proprietary.
    If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited.
    If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000.

    CAUTION:
    Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time
    without any further consent.

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: byte busters: "Fwd: [Full-Disclosure] FW: MS Antispyware makes deal to leave Weatherbug alone"

    Relevant Pages

    • Re: [Full-Disclosure] NAT router inbound network traffic subversion
      ... This should help clarify why NAT can not be considered a security ... >University whether it is possible to direct packets behind a NAT ... >I also asked if this can be thought of as a security feature, ...
      (Full-Disclosure)
    • Re: To run a secure server or not - that is the question?
      ... > I'm considering running a server with SSL security which will not only ... Your ISP can always sniff your packets. ... > SSL and NAT don't mix mainly due the NAT firewall not being able to ...
      (alt.computer.security)
    • Re: Routing and Remote Access NAT - I need to modify TTL
      ... with two interfaces: PUBLIC (internet) and PRIVATE ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL is ... but the replay that comes back to the NAT ... They relay on the fact that client computers accept packets with TTL=0, ...
      (microsoft.public.windows.server.networking)
    • Re: Routing and Remote Access NAT - I need to modify TTL
      ... with two interfaces: PUBLIC (internet) and PRIVATE ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL is ... but the replay that comes back to the NAT ... They relay on the fact that client computers accept packets with TTL=0, ...
      (microsoft.public.windows.server.networking)
    • Re: Routing and Remote Access NAT - I need to modify TTL
      ... with two interfaces: PUBLIC (internet) and PRIVATE ... Hosts on the LAN successfully acquire IP addresses from the NAT SERVER ... use it as a gateway, they can access hosts on the PUBLIC interface, TTL ... They relay on the fact that client computers accept packets with TTL=0, ...
      (microsoft.public.windows.server.networking)