Re: Natted IP
From: Jim Nugent (njim2k-nntp_at_yahoo.com)
Date: Wed, 23 Feb 2005 15:03:10 GMT
"winged" <firstname.lastname@example.org> wrote in message
> While it is not desirable to advertise the local IP (if one knows the
> local IP and can guess other protocols that might be allowed through the
> firewall, knowing the natted IP (even if the IP is un-routable)is very
> useful if one trys to tunnel an exploit of one protocol inside a second
Just how would that work? How would you guess? Lots of protocols are
"allowed though the router" if the connection is initiated from the inside,
but the router "firewall" will block all unsolicited packets unles they are
addressed to a port that you have forwarded to a machine inside. And then,
there has to be a program (server) listening on the socket connected to that
port or the port will appear closed (return "Connection Refused"). If all
these conditions are met, you can try to start a converstation with a server
WITHOUT knowing or caring about the LAN address.
The only way to reach an IP on the inside if if the router forwards it, and
that's transparent. The remote end has to address the packet to
<WAN_IP>:<Port#>. The remote doesn't know which LAN IP it's forwarded to,
and can't find out unless (e.g. with auditmypc.com) mobile code is
downloaded and allowed to retreive it.
If you send some kind of tunneled packet wrapped inside, what's going to be
there on the other end to unwrap it? Remember, a packet is not on the LAN
until the router forwards it, and it forwards it to a SPECIFIC IP.
> Knowing the internal IP assists in the footprinting effort
> against a target and required for firewall protocol tunneling exploits.
Again I asked, where is the tunnel endpoint? What knows how to "unwrap" it?
> Firewalls (especially stateful ones) are very rude when one tries to
> guess the internal address with multiple attempts often shunning the
> attacker for a preset time before another attack can be attempted.
My router's WAN side would never see a packet addressed to, say
192.168.1.20, because it can't get there over the internet. If it's wrapped
in another packet addressed to my WAN address, how does it magically get
unwrapped so the router can decide to "be rude" to it.
> of the footprinting process should determine how many attempts can be
> made before the firewall shuns the attacker and how long the trigger
> lasts. Firewalls do impede attacks but should only be considered the
> first line of defense not the only line of defense. They are devices
> with their own peculiarities, but can not be relied on to keep all the
> bad guys out.
I'd be curious to see an explanation (or a reference to one) that describes
how such an attack is carried out. The only thing I can guess is VPN, and I
have to set that up on my end as well as the remote end before it will work.
> When Java (applets) are enabled and JS enabled site does what is
> described. When either is disabled the function breaks. Typically I
> run only with JS enabled with Java applets disabled. Java applets can
> break out of the sandbox. I have found Java script to be far less
> dangerous to the local machine. I try to restrict Java applets or
> programs from trusted sources like any other executable program.
I could be wrong but i don't think an applet has to break out of the Sandbox
to get the machine's IP. I've never seen a vulnerability related to this.
> While I have seen issues with the MS implementation of Java, Sun's
> flavor has overall been much more respectful of my computer space. Sun
> has had a few vulnerabilities, but I have had few problems from their
> implementation. But I am sure some one else's mileage may vary.
FWIW I'm running Sun Java 1.5.
BTW my questions are genuine. I'm willing to learn.
-- Jim "Be right back... Godot"