Re: nmap inconsistent results - via intermedite router?

On 27 Feb 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1141091632.524233.281110@i39g2000cwa.googlegroups.com>, ads wrote:

>Thanks for persisting.

Actually, it's not that hard

>SSH-ing into the remote machine (on the internet), I setup
>this...(where source=home machine's internet ip, and dest=remote
>machine's ip)

>01:46:55.095342 IP source.2226 > dest.5190: S 4260908126:4260908126(0)
>win 5808 <mss 1452,sackOK,timestamp 17554350 0,nop,wscale 0>

"Hello, I'd like to talk"

>01:46:55.095396 IP dest.5190 > source.2226: R 0:0(0) ack 4260908127 win
>0

"<Hello???> Go away Kid, ya bother me"

In the first packet, the 'S' flag is the SYN of the contact initiation.
The rest of the stuff is not important, because of packet two. In that
packet, the "R" flag is the connection RST flag (nobody home) and the
"win" on the end shuts the window to zero size "don't send any more
packets". This is not open. Some people call the combination of the
"R" flag and "win 0" the "FOAD" packet, and that's pretty close to the
explicit meaning. In the second packet, "remote" kernel looked around,
and found there was no application interested in receiving the packet.
The kernel (actually the networking stack code) then responds with this
message telling the connecting system that there is nothing to connect
to, and further conversation is impossible.

>On my local machine (behind the netgear router) I did this...
>mirror:~# telnet dest 5190
>Trying dest...

"Connect to that host on that port? Yeah, I can try that. Hang on..."

>Connected to dest.
>Escape character is '^]'.

"OK, I figured out how - let's see what they have to say"

>Connection closed by foreign host.

"The other end hung up the phone."

>I guess this is good - but not sure about the result. I do not have a
>firewall on the remote machine.

That's correct - no firewall, but also no server listening. The result is
the same - no connection = nothing to exploit.

OK, let's repeat this, but run tcpdump on the "local" machine. Look at
the source of the second packet - is it the remote? If so, then whatever
it was that said that this port is open is lying (or at least confusseled).

        Old guy
Received on Mon May 1 00:53:42 2006