Home / server / Questions / 672938
Accepted
Eduard Florinescu
Asked: 2015-03-05 02:33:18 +0800 CST

Is there a way to see what is actually filtering TCP port communication?

  • 772
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?

firewall

4 Answers

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

    • 13
  2. Best Answer

    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.

    • 12

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

    • 5

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

    • 2