Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Bypassing NAT

  1. #1

    Bypassing NAT

    I've been wondering for awhile now about how people get passed NAT. I've noticed that even behind a NAT router, with no port forwarding, my software firewall still picks up a lot of attempted scans, worm probes etc. I've noticed this both on home broadband routers and larger ISP setups. I assume its done with some variations of source routing and/or spoofing but is anyone know how it is actually executed??
    [gloworange]
    find /home/$newbie -name *? | www.google.com 2>/dev/null
    [/gloworange]

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    That is unreasonable. Your software firewall is either malfunctioning or incorrectly configured.

    I suspect it's identifying legit traffic which has been NAT'd correctly as an attack (example: DNS replies). Either that or your NAT box is exhibiting uncharacteristic behaviour.

    Please post:

    1. Make, model, software versions of the software firewall and hardware NAT box
    2. Sanitised logs

    And maybe people will help you further

    Slarty

  3. #3
    FWIN,2004/02/14,21:03:48 -5:00 GMT,209.x.0.70:2785,10.x.4.254:3127,TCP (flags:S)
    FWIN,2004/02/14,21:03:56 -5:00 GMT,209.x.0.70:x52,10.x.4.254:31x,TCP (flags:S)
    FWIN,2004/02/14,21:04:04 -5:00 GMT,209.x.0.70:2917,10.x.4.254:1080,TCP (flags:S)
    FWIN,2004/02/14,21:09:38 -5:00 GMT,212.x.150.131:1025,10.x.4.254:135,TCP (flags:S)
    FWIN,2004/02/14,21:12:54 -5:00 GMT,193.x.53.241:1903,10.x.4.254:901,TCP (flags:S)
    FWIN,2004/02/14,21:13:38 -5:00 GMT,63.207.x.185:0,10.x.4.254:0,ICMP
    FWIN,2004/02/14,21:25:20 -5:00 GMT,217.82.2x.145:40410,10.x.4.254:137,UDP
    FWIN,2004/02/14,21:27:12 -5:00 GMT,207.x.42.70:4778,10.x.4.254:135,TCP (flags:S)
    FWIN,2004/02/14,21:x:58 -5:00 GMT,63.191.193.x:3631,10.x.4.254:135,TCP (flags:S)
    FWIN,2004/02/14,21:37:58 -5:00 GMT,63.x.214.3:0,10.x.4.254:0,ICMP (type:8/subtype:0)
    FWIN,2004/02/14,21:56:22 -5:00 GMT,65.24.59.x5:1979,10.x.4.254:3127,TCP (flags:S)
    FWIN,2004/02/14,21:59:48 -5:00 GMT,216.x.10.130:0,10.x.4.254:0,ICMP (type:8/subtype:0)
    FWIN,2004/02/14,21:59:50 -5:00 GMT,218.x.58.87:3860,10.x.4.254:445,TCP (flags:S)
    FWIN,2004/02/14,21:59:50 -5:00 GMT,218.x.58.87:3861,10.x.4.254:139,TCP (flags:S)



    Notice in particular the attempted scans/connects to mydoom ports(I'm not infected nor do I have an open port on 3128/27). This is behind my ISPs NAT router. None of these IPs are owned by my isp, so they are all outside traffic, and I have a private IP, (10.x)

    But this is not the only time I've seen this. I've gotten windows messenger popups(the real thing, not MSN messenger or web faked ones) behind linksys/dlink broadband routers with nat and no port forwarding configured.

    Perhaps some broadband routers automatically forward requests to open services, but I'm more interested in the ISP situation as it can't possibly be doing this with hundreds of clients behind its NAT router.
    [gloworange]
    find /home/$newbie -name *? | www.google.com 2>/dev/null
    [/gloworange]

  4. #4
    Senior Member
    Join Date
    Dec 2003
    Location
    Pacific Northwest
    Posts
    1,675
    Extremez,

    More info needed, as slarty indicated. The router routes what you instruct it to, it might be misconfig'd. So get us some logs from the boxes and we might be able to help you. Also if you have a computer on your network that can and does use a dialup connection or another method of getting on the internet, in addition to the router, that may be the source of of your software firewall's activity and whole bunch of other issues may surface as well. And yes addresses can be spoofed as well. Let us know.

    good day

    edit: oops was a little late.....

  5. #5
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    extremez, it looks like your NAT box is set up with a static NAT to NAT all incoming traffic to the same internal IP address (10.whatever).

    This is a highly abnormal configuration as it provides little security, and doesn't allow more than one box to share the same public IP. I recommend that if you're worried about security, you reconfigure it to do the more normal dynamic NAT, whereby packets are only NAT'd if they're part of an existing connection or are going outwards (or are incoming matched by a port forwarding rule)

    Slarty

  6. #6
    Senior Member
    Join Date
    Feb 2004
    Posts
    105

    re: NAT bypass...

    I agree w/ Slarty here...

    It is almost like the NAT box is working in the exact opposite manner in which "normal" devices work. Meaning, one normally has a range of internal private IP addresses that are NAT'd through the border device to one public routable IP. This is typically dubbed PAT or port address translation.

    Your description of the problem seems like inverted-PAT.

    I would agree with the posters that this is likely a misconfiguration or hardware defect. I'd posit that it is likely the former.

    Remember, any device worth its weight will not allow ingress of source-based packets unless they are already established in a translation table/connection table.

    Cheers,
    <0
    Ego is the great Logic killer

  7. #7
    I fully understand how the various methods of NATing work, I was wondering how NAT was bypassed, it seems from what your saying this is rather unusual situation.

    To clarify: I'm not being NATed by a device a control. My ISP is doing the NATing(they don't give out public IPs, rather they use several for the the whole neighborhood) Anyway that nixes any possibility of static forwarding because their are hundreds of other users being nated by the same IP. My guess then is that the router is not very well configured and is allowing forwarding of random source routed address to the internal hosts. Hmm, I gonna have to look into it more.
    [gloworange]
    find /home/$newbie -name *? | www.google.com 2>/dev/null
    [/gloworange]

  8. #8
    Senior Member
    Join Date
    Feb 2004
    Posts
    105

    re: original bypass question

    Well, there are a few methods to bypass NAT that I'm aware of...here goes:

    1. VPN

    Meaning, in all VPN implementations that I'm aware (which is confined to the Cisco world....PIX-PIX, PIX-router, router-router, PIX/Router-Client) NAT must be bypassed in order for IPsec tunneling to work.

    This is because you're basically building a private IP/LAN - LAN tunnel, which the endpoints indentifying one another on public IPs. Like this:

    HOST A - - - PIX 1 - - - - WWW - - - - PIX 2 - - - - HOST B

    So, when host A wants to talk with host B, PIX 1 erects a tunnel with PIX 2 using publically routable IPs assigned most likely from the ISP(s). But, HOST A and HOST B speak using their normal private IPs. NAT is bypassed by configuration b/c translating the private IPs to public IPs, as in the case of PAT or Global NAT, will prevent crypto-acls from identifying the private IP traffic, encrypting it, and sending it across the established tunnel.

    This is again the intention of the setup, so I don't think it is what you're after...

    1b. The reason i ranted on above is to explain how any type of tunneling will bypass NAT. HTTP/SSL tunneling, TCP/IP covert channels, ICMP tunneling are all additional methods I can think of...


    2. Source-routing

    This is when packets coming from "outisde" the NAT device contain crafted/forged source & destination header information, thus dictating how the packet(S) should be routed on the other side of the device.

    To pull off source-routing you'd have to possess intimate knowledge of the target topology- both public-facing and private-facing. Sending forged packets for a network/host that doesn't exist within the private architecture isn't going to do well for you.

    Also, stateful packet inspection will/should prevent this b/c packets are going to be compared to translation/connection tables in the device. It is highly likely that the crafted/forged packets your source-routing with won't match a valid connection entry in the table and will be dropped.


    Does that help in anyway?

    Cheers,
    <0
    Ego is the great Logic killer

  9. #9
    Senior Member
    Join Date
    Oct 2002
    Posts
    314
    You can also try and get a trojan installed on a host within the network (via email, social engineering etc..) as that will then create a tunnel out that you can connect to.


    The problem is that a network using NAT will typically be using non routable IP addresses, so that you cannot simply send traffic across the net to get to them. Now, what often happens is that the DMZ will be using routable IPs (or have port forwarding set up so that non routable is mapped to a routable), so your task is to get to those boxes, which you do in much the same way as you would any other box. Then you will hopefully be able to find a connection from the DMZ back into the internal LAN, (Now on a well configured network the configuration will only allow traffic from the Internal to the DMZ and not vice versa)such as a web server connecting to a database etc... which you then try and exploit to get into the internal (non routable) network.

    So you are bypassing the NAT, but in a indirect way.

    Hope that is some help.

    Quis custodiet ipsos custodes

  10. #10

    Re: re: original bypass question

    Originally posted here by lessthanzero
    Well, there are a few methods to bypass NAT that I'm aware of...here goes:
    2. Source-routing

    This is when packets coming from "outisde" the NAT device contain crafted/forged source & destination header information, thus dictating how the packet(S) should be routed on the other side of the device.

    To pull off source-routing you'd have to possess intimate knowledge of the target topology- both public-facing and private-facing. Sending forged packets for a network/host that doesn't exist within the private architecture isn't going to do well for you.

    Also, stateful packet inspection will/should prevent this b/c packets are going to be compared to translation/connection tables in the device. It is highly likely that the crafted/forged packets your source-routing with won't match a valid connection entry in the table and will be dropped.
    <0
    By the fact that several spam net send messages have made it through I doubt there useing much stateful firewall filtering if any. Perhaps these connections are being made through a sort of source-routing bruteforcing, i.e. sending packets to the perimeter with methodically random private addresses for the next hop. There's not that many private network ranges, and since the private addresses are only one hop from the perimeter router, it shouldn't be to difficult, at least in theory. I'm gonna try to devise a method to test whether it works.
    [gloworange]
    find /home/$newbie -name *? | www.google.com 2>/dev/null
    [/gloworange]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •