nmap inconsistent results - via intermedite router?

Most recent version is 4.00.

Wow, what an accurate description.

Different interfaces?

So, and where exactly is it located in your network?

Because your ISP is filtering traffic?

Multiple answers.

1. Using nmap against the loopback won't detect ports that are ONLY open on the Ethernet interfaces. Try 'netstat -tupan' on that internet system.

1. 5190... which protocol? If UDP, re-read the nmap man page.

2. From the internet system, run tcpdump which looks lower in the stack than your firewall. What's there?

1. From your home system, run tcpdump, and attempt to connect to that port on the remote system (nmap will do, but restrict the range scanned so as to not be overwhelmed with data). Who is responding with the 'SYN/ACK'? Do you get a banner?

Depends on what other "tools" you have available. tcpdump may not be easy to understand, but it should provide the answer.

You need to spend more time reading the documentation that comes with nmap. It can do a whole lot of things, but some things may get misinterpreted at some point in the game.

The description of the network isn't that clear.

Old guy

Thanks for your replies. I had a look at tcpdump and don't particularly want to understand at that low level just yet. I'll take a look at it again in a few weeks. I need to move on and for now, I'm happy to trust nmap! - so I'll just continue to use if from the remote machine rather than try it from my home machine. netstat has never shown anything listening on 5190.

ads

Assuming that it's 5190/tcp that is open, on your local system start 'tcpdump -n -i eth0' (correct the interface as required). Then, simply issue the command 'telnet remote_host 5190' and look at the tcpdump output. Who is responding - what address?

Remember that it _can_ be confused.

That's the good news. But what is responding?

Old guy

Thanks for persisting.

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)

/home/adam# tcpdump -n -i eth0 | grep 5190 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

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

On my local machine (behind the netgear router) I did this... mirror:~# telnet dest 5190 Trying dest... Connected to dest. Escape character is '^]'. Connection closed by foreign host.

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

Regards, ads

Moe Tr> >

Actually, it's not that hard

"Hello, I'd like to talk"

" 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.

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

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

"The other end hung up the phone."

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

Such a message only appears if a full TCP handshake was performed. Well, totally inconsistent with the things mentioned above.