12
nmap -p 7000-7020 10.1.1.1

Will output all the filtered ports

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-04 12:18 EET
Nmap scan report for 10.1.1.1
Host is up (0.00091s latency).
PORT     STATE    SERVICE
7000/tcp filtered afs3-fileserver
7001/tcp filtered afs3-callback
7002/tcp filtered afs3-prserver
7003/tcp filtered afs3-vlserver
7004/tcp filtered afs3-kaserver
7005/tcp filtered afs3-volser
7006/tcp filtered afs3-errors
7007/tcp filtered afs3-bos
7008/tcp filtered afs3-update
7009/tcp filtered afs3-rmtsys
7010/tcp filtered ups-onlinet
7011/tcp filtered unknown
7012/tcp filtered unknown
7013/tcp filtered unknown
7014/tcp filtered unknown
7015/tcp filtered unknown
7016/tcp filtered unknown
7017/tcp filtered unknown
7018/tcp filtered unknown
7019/tcp filtered unknown
7020/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.78 seconds

Is there a way that I can see what exactly is filtering those ports?

4 Answers 4

12

This is what the nmap docs say about the filtered state

filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software...

The only way to find out what is doing the filtering is to know what 'machines' are between you and the remote target.

This can be achieved using a route trace utility, which attempts to determine hosts between you and the target using special TCP packets. In your case the command might look something like:

traceroute 10.1.1.1

Once you know the machines between you and the target, you investigate the configuration of each to find out if it is filtering and if so how.

4
  • There are no active software firewalls on those two machines, nmap -p 7000-7020 localhost shows the ports opened, and the dedicate firewall is reportedly opened. Mar 4, 2015 at 10:49
  • 4
    The evidence you have suggests that something is filtering we can't know what that is as we don't know your config. Host based firewalls often allow all traffic on the loopback (localhost) interface so that's a possibly misleading test.
    – user9517
    Mar 4, 2015 at 10:54
  • Is there any chance that you use linux with iptables "-j DROP"? What nmap documentation refers as filtered is actually a dropped packet on any protocol.
    – risyasin
    Mar 4, 2015 at 12:04
  • Is this software actually bound to an external IP? If it's all bound to 127.0.0.1 instead, it could cause this. Check netstat
    – devicenull
    Mar 4, 2015 at 14:18
14

Nmap provides several ways to get more information about what is causing the filtering:

  • The --reason option will show the type of response that caused the "filtered" port state. This could be "no-response" or "admin-prohibited" or something else.
  • The TTL of response packets is reported in the XML output as the reason_ttl attribute of the state element for the port. If the TTL for a filtered port is different from (usually greater than) the TTL for open ports, then the difference between the TTLs is the network distance between the target and the filtering device. There are exceptions, such as targets which use different initial TTLs for ICMP vs TCP packets, or a filtering device that falsifies or overwrites TTL information.
  • The --traceroute function will show information about hops along your route, any of which could be filtering your traffic. In some cases, the reverse DNS name for one of the hops will even be something like "firewall1.example.com"
  • The firewalk NSE script will send packets with initial TTLs that will time out at different hops along the route in an attempt to find where the packets are being blocked. This is something like a combination of the previous two techniques, and usually works quite well.

The currently-unreleased development version of Nmap also reports TTL for response packets in the normal text output with the -v --reason options. For now, though, you have to use the XML output to get this information.

EDITED TO ADD: Nmap 6.49BETA1 was the first release to show TTL for response packets in text output with -v --reason or -vv, and was released in June 2015.

2
  • 1
    Very useful options +1 Mar 4, 2015 at 16:13
  • 1
    Yes, --script=firewalk is what I was trying to find. Thanks.
    – ulidtko
    Aug 7, 2019 at 8:58
5

Short answer - No, there is no way that you can see it.

Longer answer:

From: https://nmap.org/book/man-port-scanning-basics.html

"filtered Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically."

You can try discover network topology with tools like traceroute. Usually ports are filtered on the host it self (i.e. ip tables), target network edge router, target network core router or top of the rack L3 switch.

If you are in the same subnet as target host almost for sure firewall is on target machine.

2

Try comparing a result of tcptrace to one of the filtered ports with a tcptrace to an open port (or a standard traceroute). If the tcptraces are the same it means that there's something on the destination machine filtering the ports.

Update: I meant tcptraceroute, I have it aliased.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .