0

I have an AWS server running linux. When I do an netstat -lntp from the machine itself, it shows me a few ports open (as expected), but it does not show 445 or 139. This makes sense, since I have never setup samba on this machine. Furthermore, when I list the running processes and grep for smb or samba, it shows nothing running.

Looking at the firewall rules for the server, I see that it only allows inbound traffic on port 80 and 22. It allows outbound traffic on all ports to all destinations, but I don't think this is relevant.

The problem is that when I do an nmap from outside the network, it shows that port 139 and 445 are closed. Why is that? My understanding is that 'closed' means the firewall is letting the packets through to the server, but there is nothing listening on the port. Why is the firewall letting the traffic through?

DatsunBing
  • 437

1 Answers1

1

My understanding is that 'closed' means the firewall is letting the packets through to the server, but there is nothing listening on the port. Why is the firewall letting the traffic through?

"Closed" means nmap received a TCP RST packet, which is indeed how IP hosts are supposed to respond when there's nothing listening on the port.

However, nmap does not know whether that Reset packet came from the actual host, or whether it was spoofed by a firewall along the way. (Many firewalls are indeed configured to explicitly reject connection attempts and not quietly ignore them; this avoids long timeouts on the client side.)

  • It could be that your server's firewall uses reject with tcp-reset or similar.

  • It could also be that the network that you're scanning from is configured to block all outbound SMB connections as a safety measure (e.g. to prevent workstations talking NTLM to malicious servers), and it's generating the 'RST's.

  • It could even be that the ISP that you're scanning from – or the ISP that your server is hosted at – is blocking SMB connections across its WAN to prevent possible spreading of malware (like the old Conficker worm).

If you look at the packets using tcpdump, a RST spoofed by a middlebox will of course be invisible to the server (because the server did not send it), and such packets might have a suspiciously different TTL from real responses that the server generates.

Use nmap --reason to see why it's showing a specific state. Beware that even though nmap considers a TCP RST to indicate "closed" (as the host did not accept connections), some other tools actually call it "open" (thinking that the firewall allowed the packets through).

grawity
  • 501,077