Printable View
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??
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
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.
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.....
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
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
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.
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
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.
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.Quote:
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
If you were on an internal ip, could you use software such as no-ip to give your computer a hostname. (http://www.no-ip.com/). Or would it just assign the hostname to the gateway/DMZ?
It would assign it to the public IP(gateway), so unless you had access to it and could forward it on to your private one, you'd be out of luck.
Looks a lot like my ZoneAlarm's logs when i put my PC's IP address as being in the DMZ on my Linksys or Netgear firewalls. It sees everything which is what this seems to be doing.
Check to make sure you didn't put yourself in the DMZ.
Why would NAT have to be "bypassed" for you to see this traffic. I think you're missing an important piece of network address translation. Key point - NAT does not provide any security whatsoever. It simply translates source and destination addresses. If the ISP has not configured any access-lists on their router (most ISPs don't restrict any Internet traffic - check your end user agreement) then all Internet traffic will be permitted through to your host. No source routing or any other sourcery is necessary.
If the ISPs router is configured with a dynamic NAT pool, your host will be assigned a public IP from the pool, which the router will maintain in it's translation table for a predefined timeout period. While the translation state is maintained in the router, every packet going to the public IP will make it through to your internal IP address and vice versa.
As far as PAT goes, I doubt the ISP is using any type of address overload function on the router because PAT ONLY works with TCP and UDP traffic. Traffic such as ESP, AH and GRE will not be port address translated. Because of the loss of functionality by using PAT, the ISP will most likely use some sort of dynamic NAT pool WITHOUT access-lists.
_TOMDAQ
There is a way to do this, some company with a z in the name offerd a solution (thats the closest I can come to remembering I havent delt with them for a while) basicly a client is put on your machine it runs out to their dns server and oppens a session through nat, then any request for your IP comes in on that client as a host routed request.Quote:
Originally posted here by br_fusion
If you were on an internal ip, could you use software such as no-ip to give your computer a hostname. (http://www.no-ip.com/). Or would it just assign the hostname to the gateway/DMZ?
I think tomdaq nailed it. I"m assuming that there using NAT overloading here, when they may very well have a large public IP pool dynamically assigned(this would explain why I occassionally can't get past my gateway router in the evening) which without Access lists would provide full access to my internal addressed computer.
Tomdaq, many would argue that NAT can provide some security, if, in this case, on your home network you are using NAT and have non routable IP addresses then all people are going to be able to do is hit your external IP address.
So, if your set up is Router ----> Internal machine (on Non routable IP)
then you are afforded some protection in that no one outside your router can send a packet to you machine at will, only by having a trojan installed on your machine, or by taking over your router, can they get to you.
Now, on large corp networks the majority of the users will not have NAT addresses and instead will show as coming from one IP address (e.g hide NAT on FW1), the firewall (which they hopefully have) maintains state on their connections and routes the traffic appropriately, so no one on the outside can get to those boxes either.
Of course the counter arguement to this would be that if the firewall is operating correctly then it doesn`t matter if routable addresses are being used or not as the firewall controls the flow of traffic.
NAT isn`t much use for machines that are actually using a static NAT to provide an IP address as they can be reached regardless.
R0n1n, I suppose it depends on the router you are using and the manufacturer's interpretation of NAT. If your router has a built in firewall, then some protection will be afforded, however, NAT by itself will not drop any traffic to the public IP. It simply changes the source or destination address accordingly and passes the traffic to the internal/external network. If the router is doing PAT/address overload (or "hide NAT" as Checkpoint calls it) then, yes only packets responding to traffic generated from inside the router will be permitted back into the internal network. Once again, this is not NAT but PAT. As I mentioned before, I am speculating that extremez' ISP is using a NAT pool (possibly with overload enabled in the event that all the IPs in the pool are used up, as extremez had previously mentioned), otherwise he would not be experiencing the issue in question.
_TOMDAQ