It is not as simple as it was presented here - in theory it could be done through source routing (and this assuming that all devices on the way "cooperate" in letting you do that) - you first do a traceroute from the station you want to reach it from, to the external interface of the NAT-in device, then record all hops, then create packets source-routed with all the hops included, and the last one the 192.x.y.z internal address ... but due to many routers not allowing source-routing, this will probably fail :( Stef
On Tuesday 29 October 2002 03:13 pm, Daniel Miessler wrote: > 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.
