Hmm. I am wondering where the attacker is going to put this route that you mention so that it routes right past your NAT.
> It can not be stressed enough that NAT alone is _no protection at > all_, there must be some filtering or you are running wide open > looking for trouble. > > By adding a route to the network you can directly reach the machines > from outside the NAT box, something like[1] > > # route add -net 192.168/16 gw 123.123.123.123 > > would do. Then just ping around to find what hosts are alive... > > It is raining on the Internet. Don't leave your house with the windows > open... > > [1] Assuming the corporate LAN uses 192.168.0.0--192.168.255.255 as > their internal addresses and the gateways external IP is > 123.123.123.123. > ---- > > In other words, NAT gains you pretty much nothing for security. The > existance of your network behind a NATting device might not be immediately > obvious to someone scanning from the outside, but anyone watching traffic > from your NAT device will be able to figure out pretty easily that there is > a network behind that one IP address, and if they care to probe to see what > is there, the NAT does not do much to protect the network. > > Randy Graham > > > -----Original Message----- > From: Schuler, Jeff [mailto:Jeff.Schuler@;hit.cendant.com] > Sent: Wednesday, September 25, 2002 1:17 PM > To: [EMAIL PROTECTED] > Subject: Network Address Translation insecurities > > > I am looking for information regarding the insecurities and vulnerabilities > that exist in Network Address Translation. One of our admins feels that > because everything is NAT'd that there is no way anyone can break into the > systems that are NAT'd. I know that this is not a completely accurate > statement but need to find some research and documentation regarding this. > All our systems are behind at least one firewall so please don't advise me > to install a firewall as extra security as they are already there. I just > want to make sure that we are not overlooking serious vulnerabilities just > because the box is behind a NAT. In order to justify doing vulnerability > testing on some of our internal systems I need to demonstrate the > insecurities in NAT. > > Thanks in advance > > Jeff Schuler > > -----Original Message----- > From: Damon McMahon [mailto:inst_karma@;hotmail.com] > Sent: Thursday, October 24, 2002 11:36 PM > To: [EMAIL PROTECTED] > Subject: NetBIOS Messenger spam - how did it get in? > > > > > Greetings, The gateway host of my small workgroup has just become a > 'victim' of the recent spate of SPAM using the NetBIOS Messenger Service. > However, I'm seeking advice on how it managed to get through what I thought > was a reasonably secure gateway. The gateway is a Windows 2000 host which > connects to the internet via an external IP dynamically assigned by my ISP, > and to an internal network via a 192.168.0.0/24 IP assigned by the Windows > Internet Connection Sharing service. I have ZoneAlarm Pro installed on the > gateway, which allows NetBIOS traffic over the 192.168.0.0/24 subnet but > rejects NetBIOS traffic from any other IP. This rule is explicitly defined > in the ZA Pro configuration, and appears to be working as the ZA Pro logs > are full of rejected packets from internet IPs attempting to access NetBIOS > ports on the host. From what I understand, such a firewall configuration > should discard any traffic to ports 135, 137-139 from any hosts not on the > internal network. Clearly there has been a breach. The only possible > explanation I can conceive is that the source of the NetBIOS message spoofed > it's IP address to be in the 192.168.0.0/24 range: 1. Is this possible? I > would have thought any packet with such a spoofed IP address would be deemed > non-routable by any of the routers between the source host and mine, and > hence would never make it to my host? 2. If this is possible, is there any > inexpensive [preferably free!] method of configuring Windows 2000 (with or > without ZA Pro) to filter packets on the basis of interface as well as IP > address? For example, BSD variants come with an inbuilt firewall called ipfw > which enables you to construct a rule denying all packets with an address > 192.168.0.0/24 from passing via the external interface, while allowing such > packets to pass via the internal interface. 3. Are there any other > explanations for this intrusion? Any advice will be most appreciated. > Please email me on inst_karma A T hotmail D O T com if you require more > detailed information.
