How did they get past my NAT? - Firewalls

This is a discussion on How did they get past my NAT? - Firewalls ; goarilla wrote: >> No, this would be rather straight-forward. I'm talking about application >> layer protocol engines that inspect the traffic and setup proper rules. >> For example, if the implementation sees traffic like "PORT >> 192,168,0,1,47,11", it might believe ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 64

Thread: How did they get past my NAT?

  1. Re: How did they get past my NAT?

    goarilla wrote:


    >> No, this would be rather straight-forward. I'm talking about application
    >> layer protocol engines that inspect the traffic and setup proper rules.
    >> For example, if the implementation sees traffic like "PORT
    >> 192,168,0,1,47,11", it might believe that it's part of an Active FTP
    >> session setup and might add an appropriate rule for the reply.
    >> Or if it sees an TCP connection to some server on port 4661 (eDonkey P2P
    >> protocol), it might decide to permanently forward 4662/TCP and 4665/UDP
    >> to that client, without even checking for the actual protocol.
    >> Even worse, what about connections to 1119/TCP? Very likely that it's a
    >> computer game using Battle.net Online service, so better forward
    >> 5000-10000/TCP to that client... oh, and there the VNC server goes.

    > that would be a ****ty NAT router/gateway !



    I'd say this would be an excellent gateway for the low-cost consumer market.
    Since it tries to avoid hassles with the NAT, the user is happy and, due to
    lowerr support costs, the vendor is happy. That's exactly why they implement
    it that way.

  2. Re: How did they get past my NAT?

    Sebastian G. wrote:
    > goarilla wrote:
    >
    >
    >>> No, this would be rather straight-forward. I'm talking about
    >>> application layer protocol engines that inspect the traffic and setup
    >>> proper rules. For example, if the implementation sees traffic like
    >>> "PORT 192,168,0,1,47,11", it might believe that it's part of an
    >>> Active FTP session setup and might add an appropriate rule for the
    >>> reply.
    >>> Or if it sees an TCP connection to some server on port 4661 (eDonkey
    >>> P2P protocol), it might decide to permanently forward 4662/TCP and
    >>> 4665/UDP to that client, without even checking for the actual protocol.
    >>> Even worse, what about connections to 1119/TCP? Very likely that it's
    >>> a computer game using Battle.net Online service, so better forward
    >>> 5000-10000/TCP to that client... oh, and there the VNC server goes.

    >> that would be a ****ty NAT router/gateway !

    >
    >
    > I'd say this would be an excellent gateway for the low-cost consumer
    > market. Since it tries to avoid hassles with the NAT, the user is happy
    > and, due to lowerr support costs, the vendor is happy. That's exactly
    > why they implement it that way.


    true but then again people who use things like that shouldn't be allowed
    to have
    a router/network in my humble opinion. these are prob the same folks
    that go on fastrack
    or edonkey and share their c:\ drive. but if my router did that (5000-10000)
    i would throw it out of the winow in an instant.

  3. Re: How did they get past my NAT?

    Maniaque wrote:


    > OK, so I guess my source of confusion is with regards to "Intended
    > Purpose" vs "Effect". A completely basic Symmetrical NAT effectively
    > does the same basic thing a basic firewall will often be used to do -
    > prevent unintended inbound traffic, allow outbound traffic, optionally
    > allow inbound traffic on specified ports to a specified server.



    For 1:1 NAT aka IP masquerading you got it quite wrong: Such an
    implementation could and even should forward every incoming connection,
    because the target is always exactly known. For 1:many, dropping the
    incoming connections would be the only correct, but not surely the most
    reasonable implementation.

    > eg allowing the Active FTP Data connection only on the


    > condition that the traffic from the remote server is made up of valid
    > FTP data...



    FTP data traffic is not directly defined to be related to the control data.
    Let's say the client surfs to a website containing a Java or Flash applet
    that implements the FTP protocol, it might still issue correct commands to
    open associated ports.

  4. Re: How did they get past my NAT?

    Leythos wrote:
    > In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla <"kevin
    > DOT paulus AT skynet DOT be"> says...
    >> do you consider netfilter to be a firewall (well in essence it's a
    >> statefull packet filter)
    >> because iirc there is no smtp or http netfilter module
    >> and it does its filtering mostly on the data link and transport
    >> protocol's headers
    >> like most firewalls do. it would be very costly performance wise to
    >> implement
    >> application protocol filters into firewalls and i've yet to see one that
    >> does
    >> also implementing complex heuristics because let's face it the higher
    >> you go up in
    >> the tcp/ip stack the more complex the headers and payload become, the
    >> more bugs you'll get
    >> in the code that does the heuristics --> the more flaws there are to be
    >> exploited!

    >
    > Sorry, but I don't consider NAT Routers to be firewalls, they are
    > routers with some fancy features, not firewalls.


    If the router closes all ports and conceals LAN IP addresses
    then it's just as good, and in one respect better than, any
    software firewall.


  5. Re: How did they get past my NAT?

    Rick Merrill writes:

    > Leythos wrote:
    > > In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla
    > > <"kevin DOT paulus AT skynet DOT be"> says...
    > >> do you consider netfilter to be a firewall (well in essence it's a
    > >> statefull packet filter)
    > >> because iirc there is no smtp or http netfilter module
    > >> and it does its filtering mostly on the data link and transport
    > >> protocol's headers
    > >> like most firewalls do. it would be very costly performance wise to
    > >> implement
    > >> application protocol filters into firewalls and i've yet to see one
    > >> that does
    > >> also implementing complex heuristics because let's face it the
    > >> higher you go up in
    > >> the tcp/ip stack the more complex the headers and payload become,
    > >> the more bugs you'll get
    > >> in the code that does the heuristics --> the more flaws there are
    > >> to be exploited!

    > > Sorry, but I don't consider NAT Routers to be firewalls, they are
    > > routers with some fancy features, not firewalls.

    >
    > If the router closes all ports and conceals LAN IP addresses
    > then it's just as good, and in one respect better than, any
    > software firewall.


    Uh oh. Someone said "software firewall."

    Brace for the impending ranting about how they aren't firewalls
    either.

    --
    Todd H.
    http://www.toddh.net/

  6. Re: How did they get past my NAT?

    Todd H. wrote:
    > Rick Merrill writes:
    >
    >> Leythos wrote:
    >>> In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla
    >>> <"kevin DOT paulus AT skynet DOT be"> says...
    >>>> do you consider netfilter to be a firewall (well in essence it's a
    >>>> statefull packet filter)
    >>>> because iirc there is no smtp or http netfilter module
    >>>> and it does its filtering mostly on the data link and transport
    >>>> protocol's headers
    >>>> like most firewalls do. it would be very costly performance wise to
    >>>> implement
    >>>> application protocol filters into firewalls and i've yet to see one
    >>>> that does
    >>>> also implementing complex heuristics because let's face it the
    >>>> higher you go up in
    >>>> the tcp/ip stack the more complex the headers and payload become,
    >>>> the more bugs you'll get
    >>>> in the code that does the heuristics --> the more flaws there are
    >>>> to be exploited!
    >>> Sorry, but I don't consider NAT Routers to be firewalls, they are
    >>> routers with some fancy features, not firewalls.

    >> If the router closes all ports and conceals LAN IP addresses
    >> then it's just as good, and in one respect better than, any
    >> software firewall.

    >
    > Uh oh. Someone said "software firewall."
    >
    > Brace for the impending ranting about how they aren't firewalls
    > either.
    >


    opps, I didn't expect to get off scott free.


  7. Re: How did they get past my NAT?

    Rick Merrill writes:

    >Leythos wrote:
    >> In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla <"kevin
    >> DOT paulus AT skynet DOT be"> says...
    >>> do you consider netfilter to be a firewall (well in essence it's a
    >>> statefull packet filter)
    >>> because iirc there is no smtp or http netfilter module
    >>> and it does its filtering mostly on the data link and transport
    >>> protocol's headers
    >>> like most firewalls do. it would be very costly performance wise to
    >>> implement
    >>> application protocol filters into firewalls and i've yet to see one that
    >>> does
    >>> also implementing complex heuristics because let's face it the higher
    >>> you go up in
    >>> the tcp/ip stack the more complex the headers and payload become, the
    >>> more bugs you'll get
    >>> in the code that does the heuristics --> the more flaws there are to be
    >>> exploited!

    >>
    >> Sorry, but I don't consider NAT Routers to be firewalls, they are
    >> routers with some fancy features, not firewalls.


    >If the router closes all ports and conceals LAN IP addresses
    >then it's just as good, and in one respect better than, any
    >software firewall.



    IF it closes all ports (nat is irrelevant). But the hypothesis of the
    thread was that ports were being punched through the router. Note that a
    router which refuses to pass on ports IS a firewall. And since it operates
    on software loaded on the router, it is a software firewall.


  8. Re: How did they get past my NAT?

    Leythos wrote:
    > In article ,
    > rick0.merrill@NOSPAM.gmail.com says...
    >> Leythos wrote:
    >>> In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla <"kevin
    >>> DOT paulus AT skynet DOT be"> says...
    >>>> do you consider netfilter to be a firewall (well in essence it's a
    >>>> statefull packet filter)
    >>>> because iirc there is no smtp or http netfilter module
    >>>> and it does its filtering mostly on the data link and transport
    >>>> protocol's headers
    >>>> like most firewalls do. it would be very costly performance wise to
    >>>> implement
    >>>> application protocol filters into firewalls and i've yet to see one that
    >>>> does
    >>>> also implementing complex heuristics because let's face it the higher
    >>>> you go up in
    >>>> the tcp/ip stack the more complex the headers and payload become, the
    >>>> more bugs you'll get
    >>>> in the code that does the heuristics --> the more flaws there are to be
    >>>> exploited!
    >>> Sorry, but I don't consider NAT Routers to be firewalls, they are
    >>> routers with some fancy features, not firewalls.

    >> If the router closes all ports and conceals LAN IP addresses
    >> then it's just as good, and in one respect better than, any
    >> software firewall.

    >
    > Actually, a NAT Router is better than any PERSONAL firewall solution
    > installed on a non-dedicated computer.
    >

    what if your Personal Computer runs a BSD (ipfw,pf) or GNU/Linux
    distribution (iptables)
    and is there such a big difference between a firewall that has its code
    burned in flash (firmware)
    and a firewall that hooks into the tcp/ip stack of a a general purpose OS

  9. Re: How did they get past my NAT?

    Leythos writes:

    > This still goes back to these cheap residential units called firewalls
    > by the marketing department - if you look up NAT, it's routing, simple
    > and plain, not Firewalling.


    And if you look up firewalling um... it can be implemented by.... wait
    for it.....


    ROUTERS!


    I don't dispute marketing departments being very prone to overblowing
    capabilities of many devices, but show me a good citation from a
    widely known source for "firewall" implying or requiring all the
    things you include in your definition.

    Point is, it's not nearly as narrowly defined as you seem to require.

    No doubt a "firewall" appliance that implements IPS, IDS, allows
    no traffic by default, has the ability to provide a higher level of
    security than your garden variety broadband router for the home office
    market, but... that does not mean the latter class of devices don't
    also fit the definition of firewall. They're just lesser firewall
    appliances.

    --
    Todd H.
    http://www.toddh.net/

  10. Re: How did they get past my NAT?

    Leythos writes:

    >In article <4710aff1$0$22302$ba620e4c@news.skynet.be>, goarilla <"kevin
    >DOT paulus AT skynet DOT be"> says...
    >> Leythos wrote:
    >> > In article ,
    >> > rick0.merrill@NOSPAM.gmail.com says...
    >> >> Leythos wrote:
    >> >>> In article <470e9db8$0$22311$ba620e4c@news.skynet.be>, goarilla <"kevin
    >> >>> DOT paulus AT skynet DOT be"> says...
    >> >>>> do you consider netfilter to be a firewall (well in essence it's a
    >> >>>> statefull packet filter)
    >> >>>> because iirc there is no smtp or http netfilter module
    >> >>>> and it does its filtering mostly on the data link and transport
    >> >>>> protocol's headers
    >> >>>> like most firewalls do. it would be very costly performance wise to
    >> >>>> implement
    >> >>>> application protocol filters into firewalls and i've yet to see one that
    >> >>>> does
    >> >>>> also implementing complex heuristics because let's face it the higher
    >> >>>> you go up in
    >> >>>> the tcp/ip stack the more complex the headers and payload become, the
    >> >>>> more bugs you'll get
    >> >>>> in the code that does the heuristics --> the more flaws there are to be
    >> >>>> exploited!
    >> >>> Sorry, but I don't consider NAT Routers to be firewalls, they are
    >> >>> routers with some fancy features, not firewalls.
    >> >> If the router closes all ports and conceals LAN IP addresses
    >> >> then it's just as good, and in one respect better than, any
    >> >> software firewall.
    >> >
    >> > Actually, a NAT Router is better than any PERSONAL firewall solution
    >> > installed on a non-dedicated computer.
    >> >

    >> what if your Personal Computer runs a BSD (ipfw,pf) or GNU/Linux
    >> distribution (iptables) and is there such a big difference between
    >> a firewall that has its code burned in flash (firmware)
    >> and a firewall that hooks into the tcp/ip stack of a a general purpose OS


    >As long as it a dedicated computer and not one that users are
    >playing/working on, then it can easily be a firewall. Checkpoint running
    >on a Nix OS is a great example of a dedicated server class firewall -
    >notice the dedicated.


    >With all that is available at a reasonable cost today, a firewall that
    >is just a router is not really a firewall. The appliances I install can
    >tell the difference between SMTP and HTTP or FTP and do a lot more,
    >that's the least I would install.


    >This still goes back to these cheap residential units called firewalls
    >by the marketing department - if you look up NAT, it's routing, simple
    >and plain, not Firewalling.


    And now you are going to tell us what the difference is between a NAT
    router that rejects all incoming unsolicited connections, and a firewall
    that rejects all unsolicited incoming connections.
    It is certainly true that a firewall can be a slightly less blunt
    instrument, and can reject or accept more subtly that a NAT router can, but
    IF that router is set up not to do any port forwarding, then it is also a
    firewall set up to reject all incoming connections.



  11. Re: How did they get past my NAT?

    > It is certainly true that a firewall can be a slightly less blunt

    > instrument, and can reject or accept more subtly that a NAT router can, but
    > IF that router is set up not to do any port forwarding, then it is also a
    > firewall set up to reject all incoming connections.


    There are two major differences:

    1. NAT is not designed to work as a security solution.
    2. Depending on the implementation, it might forward the connection anyway
    without any explicit rule.

  12. Re: How did they get past my NAT?

    Leythos wrote in
    news:MPG.217d12e555dffbb4989ae9@adfree.Usenet.com:
    ....snip more of Leythos' whinging...

    Still hard at the weaselling, eh Leythos? Your stupidity is exceeded only
    by your tenacity.

    Regards,

  13. Re: How did they get past my NAT?

    Leythos wrote in
    news:MPG.217d4df2698e87e3989af7@adfree.Usenet.com:
    ....snip yet more of Leyhtos' whining...

    Still hard at the weaselling, eh Leythos?

    C'mon, don't stop now, just when you're on a roll, Leythos.

    C'mon, say something else really stupid, Leythos, and then defend it to the
    death with you pathetic weaselling. C'mon, Leythos!

    Regards,



  14. Re: How did they get past my NAT?

    "Sebastian G." writes:

    > > It is certainly true that a firewall can be a slightly less blunt


    >> instrument, and can reject or accept more subtly that a NAT router can, but
    >> IF that router is set up not to do any port forwarding, then it is also a
    >> firewall set up to reject all incoming connections.


    >There are two major differences:


    >1. NAT is not designed to work as a security solution.
    >2. Depending on the implementation, it might forward the connection anyway
    >without any explicit rule.


    So might an incompetent firewall. A competently implimented NAT does work
    as a firewall IF set to not forward any unsolicited packetc.
    Of course you have to decide if your particular NAT is a competent
    implimentation. HOwever if you punch holes ( have it forward ports) all
    bets are off.


  15. Re: How did they get past my NAT?

    Unruh wrote:


    >> 1. NAT is not designed to work as a security solution.
    >> 2. Depending on the implementation, it might forward the connection anyway
    >> without any explicit rule.

    >
    > So might an incompetent firewall. A competently implimented NAT does work
    > as a firewall IF set to not forward any unsolicited packetc.



    Wrong.
    - A completely correct NAT implementation might also do a full forwarding in
    a 1:1 setup.
    - As well as it might forward every unsolicited packet to a specified host
    on a 1:many setup (the DMZ host)...
    - Reading layer 7 protocols and associate states isn't wrong either.


    > Of course you have to decide if your particular NAT is a competent
    > implimentation. HOwever if you punch holes ( have it forward ports) all
    > bets are off.



    What about punching holes from the inside? With a Java applet, you can
    create a connection back to a server with a freely chosen port > 1023. With
    Flash applets, you can even get < 1024 with some nifty (documented) tricks.
    Now just create a connection from $local_ip:53 to $your_server:12345, drop
    the connection from the client side, and if the victim fires up his local
    DNS server within the timeout period... without a real firewall explicitly
    denying any outside access to port 53, even for session-related packets, you
    won't get any further. And with NAT alone, you can't solve this dilemma at all.

  16. Re: How did they get past my NAT?

    Leythos writes:

    >In article , unruh-spam@physics.ubc.ca
    >says...
    >> "Sebastian G." writes:
    >>
    >> > > It is certainly true that a firewall can be a slightly less blunt

    >>
    >> >> instrument, and can reject or accept more subtly that a NAT router can, but
    >> >> IF that router is set up not to do any port forwarding, then it is also a
    >> >> firewall set up to reject all incoming connections.

    >>
    >> >There are two major differences:

    >>
    >> >1. NAT is not designed to work as a security solution.
    >> >2. Depending on the implementation, it might forward the connection anyway
    >> >without any explicit rule.

    >>
    >> So might an incompetent firewall. A competently implimented NAT does work
    >> as a firewall IF set to not forward any unsolicited packetc.
    >> Of course you have to decide if your particular NAT is a competent
    >> implimentation. HOwever if you punch holes ( have it forward ports) all
    >> bets are off.


    >No, you don't have to decide, there are quality groups, CERT for one,
    >that can test and tell us if they pass the proper test to be qualified
    >as a firewall. NAT is not a firewall function, it is often included in
    >firewalls, but it is not a firewall function.



    The question was not whether NAT was a firewall function but whether NAT
    with no port holes punched through was effectively a firewall allowing no
    unsolicited incoming traffic.

    Is there a way in which a NAT router, with no holes punched through, is
    more insecure than a firewall which rejects all unsolicited incoming
    traffic? If you claim it is more insecure, please tell us why.


  17. Re: How did they get past my NAT?

    Unruh wrote:


    > The question was not whether NAT was a firewall function but whether NAT
    > with no port holes punched through was effectively a firewall allowing no
    > unsolicited incoming traffic.
    >
    > Is there a way in which a NAT router, with no holes punched through, is
    > more insecure than a firewall which rejects all unsolicited incoming
    > traffic? If you claim it is more insecure, please tell us why.


    It is, for three reasons:

    1. If a connection is initiated from the inside, all related traffic from
    the outside is forwarded. For a firewall you'd need to add such a rule
    explicitly, and you could still overwrite it (e.g. generally denying access
    to a certain port range for every incoming connection from the WAN).

    2. Depending on the implementation, a NAT router itself might decide to
    forward a connection based on assumptions about various Layer 7 protocols.

    3. NAT was never designed to be a security solution, but rather to provide
    connectivity (even the RFC about NAT explicitly states that!). So you should
    never assume that a NAT implementation simply drops a connection for which
    it doesn't know any state.

  18. Re: How did they get past my NAT?

    "Sebastian G." writes:

    >Unruh wrote:



    >> The question was not whether NAT was a firewall function but whether NAT
    >> with no port holes punched through was effectively a firewall allowing no
    >> unsolicited incoming traffic.
    >>
    >> Is there a way in which a NAT router, with no holes punched through, is
    >> more insecure than a firewall which rejects all unsolicited incoming
    >> traffic? If you claim it is more insecure, please tell us why.


    >It is, for three reasons:


    >1. If a connection is initiated from the inside, all related traffic from
    >the outside is forwarded. For a firewall you'd need to add such a rule
    >explicitly, and you could still overwrite it (e.g. generally denying access
    >to a certain port range for every incoming connection from the WAN).


    Not at all sure what you mean. I initiate a http connection. The response
    better get through both on a firewall and on a NAT.


    >2. Depending on the implementation, a NAT router itself might decide to
    >forward a connection based on assumptions about various Layer 7 protocols.


    ?? Not clear what you mean. This sounds like a bad implimentation.


    >3. NAT was never designed to be a security solution, but rather to provide
    >connectivity (even the RFC about NAT explicitly states that!). So you should
    >never assume that a NAT implementation simply drops a connection for which
    >it doesn't know any state.


  19. Re: How did they get past my NAT?

    Leythos writes:

    >In article , unruh-spam@physics.ubc.ca
    >says...
    >> The question was not whether NAT was a firewall function but whether NAT
    >> with no port holes punched through was effectively a firewall allowing no
    >> unsolicited incoming traffic.
    >>
    >> Is there a way in which a NAT router, with no holes punched through, is
    >> more insecure than a firewall which rejects all unsolicited incoming
    >> traffic? If you claim it is more insecure, please tell us why.


    >And you're all wet because a firewall protects in both directions.


    Protects what in both directions? We are talking about and outsider
    attacking a machine behind the NAT/firewall. What is the relevance of "both
    directions" to the issue at hand?


  20. Re: How did they get past my NAT?

    Leythos wrote:
    > In article , unruh-spam@physics.ubc.ca
    > says...
    >> Leythos writes:
    >>
    >>> In article , unruh-spam@physics.ubc.ca
    >>> says...
    >>>> The question was not whether NAT was a firewall function but whether NAT
    >>>> with no port holes punched through was effectively a firewall allowing no
    >>>> unsolicited incoming traffic.
    >>>>
    >>>> Is there a way in which a NAT router, with no holes punched through, is
    >>>> more insecure than a firewall which rejects all unsolicited incoming
    >>>> traffic? If you claim it is more insecure, please tell us why.
    >>> And you're all wet because a firewall protects in both directions.

    >> Protects what in both directions? We are talking about and outsider
    >> attacking a machine behind the NAT/firewall. What is the relevance of "both
    >> directions" to the issue at hand?

    >
    > You don't appear to know about "both directions" and in many cases you
    > don't allow ALL OUTBOUND, in fact, there is little reason to allow all
    > outbound and it's a bad rule to use ALLOW ANY > EXTERNAL.
    >
    > I never allow TCP 1433 or TCP 1434 or TCP 135-139 or TCP 445 outbound on
    > networks. I might only allow SMTP outbound from 1 IP in the LAN and I
    > might want to block outbound connections except from a small range of IP
    > in the LAN but not in the DMZ - a firewall can do that, your home NAT
    > ROUTER can't.


    little question, just for the sake of education
    a router splits up broadcast domains iirc and doesn't forward broadcasts
    unless specified
    so netbios broadcasts (eg who is master browser ... ) are NOT forwarded
    and well
    netbios requests as default should never define a destination ip that
    needs to be gatewayed
    eg if your lan is 192.168.1.* then it should never send packets to
    192.168.1.0.
    well i think that's the way it works with win xp sp2 + and Unix SAMBA
    because i have sniffed and sniffed
    but never saw a netbios packet with a destination that required the
    router to forward it to the wan side

    i do however outbound filter my SMB servers (2 x slackware mahcines)
    since i can't be certain 100 %. the question is: is this somehow correct
    and/or if not please elaborate i just want to learn and spread what i've
    learned
    in no way i mean to start flamewars or belittle people.

    > What about the DMZ network? Most NAT Routers have the option - but most
    > of them don't actually setup/use a DMZ network, it's just an IP on the
    > LAN that gets ALL traffic not forwarded to some other area - which means
    > it's NOT a DMZ and it's not protected from/to the LAN - A firewall
    > doesn't make that mistake.
    >


    true most DMZ's on home routers are not real DMZ's

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast