Hi Susers, just to check the security of my machine I run "nmap -vv -sU mymachineip" from another box on the internet. nmap returns that udp ports 137, 138, 272, 464, 635, 929, 1110 1464 and 2002 are open. I run netstat from my machine and I note that only 137 and 138 are really open, not the others. Furthermore, 137 and 138 are firewalled with ipchains (-j DENY option). Can anybody explain me why nmap does these mistakes, if they really are mistakes? Why it sees 137 and 138 as open while they are firewalled? Thanks in advance Tazio
Where were you running nmap from? Inside or outside the firewall? If inside the firewall, like on the same machine, nmap's requests dont' go thru the firewall, hence no blocking. The other possibility is that your machine has been compromised and nmap is telling you reality and netstat has been replaced with a version that hides certain ports. Jeffrey Quoting Tazio Ceri <praisetazio@tiscalinet.it>:
Hi Susers, just to check the security of my machine I run "nmap -vv -sU mymachineip" from another box on the internet.
nmap returns that udp ports 137, 138, 272, 464, 635, 929, 1110 1464 and 2002 are open. I run netstat from my machine and I note that only 137 and 138 are really open, not the others. Furthermore, 137 and 138 are firewalled with ipchains (-j DENY option).
Can anybody explain me why nmap does these mistakes, if they really are mistakes? Why it sees 137 and 138 as open while they are firewalled?
Thanks in advance
Tazio
-- I don't do Windows and I don't come to work before nine. -- Johnny Paycheck
I am running it outside the firewall, from a PC 150km far. When I run nmap on the same LAN, nmap only return what netstat does to. I suppose there is a problem with udp port scanning reliability, but as I am not an expert about that I just asked. The tcp scanning gives me the appropriate results from everywhere. Tazio Jeffrey Taylor wrote:
Where were you running nmap from? Inside or outside the firewall? If inside the firewall, like on the same machine, nmap's requests dont' go thru the firewall, hence no blocking.
The other possibility is that your machine has been compromised and nmap is telling you reality and netstat has been replaced with a version that hides certain ports.
Jeffrey
Quoting Tazio Ceri <praisetazio@tiscalinet.it>:
Hi Susers, just to check the security of my machine I run "nmap -vv -sU mymachineip" from another box on the internet.
nmap returns that udp ports 137, 138, 272, 464, 635, 929, 1110 1464 and 2002 are open. I run netstat from my machine and I note that only 137 and 138 are really open, not the others. Furthermore, 137 and 138 are firewalled with ipchains (-j DENY option).
Can anybody explain me why nmap does these mistakes, if they really are mistakes? Why it sees 137 and 138 as open while they are firewalled?
Thanks in advance
Tazio
On Sat, May 19, 2001 at 10:41:03PM +0200, Tazio Ceri wrote:
just to check the security of my machine I run "nmap -vv -sU mymachineip" from another box on the internet.
nmap returns that udp ports 137, 138, 272, 464, 635, 929, 1110 1464 and 2002 are open. I run netstat from my machine and I note that only 137 and 138 are really open, not the others. Furthermore, 137 and 138 are firewalled with ipchains (-j DENY option).
Can anybody explain me why nmap does these mistakes, if they really are mistakes? Why it sees 137 and 138 as open while they are firewalled?
Did you create this firewall yourself? The fact that you've firewalled 137 and 138 with the DENY target explains why these ports are showing up on the nmap scan. When nmap performs a UDP scan, it looks for ICMP post unreachable packets being returned when it prods a port. If it doesn't receive such a packet when it prods a port, then it assumes that port is open. By using the DENY target, ipchains (or iptables) will just drop the packet completely, pretending as if it had never received it. This does not generate an ICMP responce to the probing host, so nmap assumes an open port. To get rid of the 'phantom open ports', then use the REJECT target for your firewalling rules, and the appropriate packet will be returned to the nmap'ing host, and all will be well. I assume ports 272, 464, etc. are also firewalled using the DENY target? Hope that helps, Chris -- __ _ -o)/ / (_)__ __ ____ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\
Quoting Chris Reeves <chris.reeves@iname.com>: [snip]
Did you create this firewall yourself? The fact that you've firewalled 137 and 138 with the DENY target explains why these ports are showing up on the nmap scan. When nmap performs a UDP scan, it looks for ICMP post unreachable packets being returned when it prods a port. If it doesn't receive such a packet when it prods a port, then it assumes that port is open.
I am not sure about UDP ports, but I know this is not correct for TCP ports. If nmap receives a RST packet, the result of a REJECT action in the firewall, it reports the port is closed. If it receives no response, the result of a DENY action, it reports the port is filtered. Jeffrey -- I don't do Windows and I don't come to work before nine. -- Johnny Paycheck
On Tue, Jun 05, 2001 at 04:56:26PM -0500, Jeffrey Taylor wrote:
Quoting Chris Reeves <chris.reeves@iname.com>: [snip]
Did you create this firewall yourself? The fact that you've firewalled 137 and 138 with the DENY target explains why these ports are showing up on the nmap scan. When nmap performs a UDP scan, it looks for ICMP post unreachable packets being returned when it prods a port. If it doesn't receive such a packet when it prods a port, then it assumes that port is open.
I am not sure about UDP ports, but I know this is not correct for TCP ports. If nmap receives a RST packet, the result of a REJECT action in the firewall, it reports the port is closed. If it receives no response, the result of a DENY action, it reports the port is filtered.
It is indeed different for UDP, since UDP is a connectionless transport protocol. TCP, on the other hand, is connection oriented, so different packets are send out as the 'handshaking' occurs and nmap can tell how successful the connection attempt was. UDP, on the other hand is different: if the port is open, the probed machine will accept the packet and then may or may not ignore it; if the port is closed, an ICMP packet will be returned; if the port is REJECTed by a firewall, and ICMP packet will be returned; and if the port is DENYed by a firewall, the packet is dropped, and nothing is returned. Hence nmap (for UDP) can only really make the distinction between receiveing an ICMP message and not receiving such a message. Which is the problem Tazio is having. Hope that clears things up ;-) Chris -- __ _ -o)/ / (_)__ __ ____ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\
Chris Reeves wrote:
On Sat, May 19, 2001 at 10:41:03PM +0200, Tazio Ceri wrote:
just to check the security of my machine I run "nmap -vv -sU mymachineip" from another box on the internet.
nmap returns that udp ports 137, 138, 272, 464, 635, 929, 1110 1464 and 2002 are open. I run netstat from my machine and I note that only 137 and 138 are really open, not the others. Furthermore, 137 and 138 are firewalled with ipchains (-j DENY option).
Can anybody explain me why nmap does these mistakes, if they really are mistakes? Why it sees 137 and 138 as open while they are firewalled?
Did you create this firewall yourself? The fact that you've firewalled 137 and 138 with the DENY target explains why these ports are showing up on the nmap scan. When nmap performs a UDP scan, it looks for ICMP post unreachable packets being returned when it prods a port. If it doesn't receive such a packet when it prods a port, then it assumes that port is open.
By using the DENY target, ipchains (or iptables) will just drop the packet completely, pretending as if it had never received it. This does not generate an ICMP responce to the probing host, so nmap assumes an open port. To get rid of the 'phantom open ports', then use the REJECT target for your firewalling rules, and the appropriate packet will be returned to the nmap'ing host, and all will be well.
I assume ports 272, 464, etc. are also firewalled using the DENY target?
Hope that helps, Chris
I thought something like that for my 138 and 139 ports. But the other ports are not firewalled nor opened. And they change every time so I think it's a problem of the network. Tazio
participants (3)
-
Chris Reeves -
Jeffrey Taylor -
Tazio Ceri