11

By the NMAP definition, unfiltered ports are the ones which cannot be determined to be open or closed since packet filtering prevents its probes from reaching the port. (ISBN 9780979958717 pag. 77)

  • So that being said, is my assumption correct that every probe which manage to reach the port will always be properly replied by either a SYN/ACK or a RST?
  • The only thing which might prevent me to reach the port or get a reply from it would be a security device (e.g. Firewall) -- is that correct?
  • Can't the application itself just ignore my probes?
Improve this question
1
  • 1
    it's important to note that in nmap parlance "filtered" really means "I received no response", if you disable discovery you could have all filtered ports just 'cause there's nothing on that IP address at all...
    – Rory McCune
    Commented Jul 28, 2015 at 11:35

4 Answers 4

Reset to default
8

Generally there are multiple devices between you and your target. Along the way firewalls, routers, switches, and other network devices can restrict your packets from actually getting to your target. Also host based firewalls or application access controls can cause a filtered response.

Sometimes you get a response from the filtering device in the response of a ICMP error message but in most cases somewhere along the route the packets are just dropped.

Your assumptions:

  • No. Iptables can be configured to not respond at all unless you are on an approved list. Or iptables can be configured with a list of hosts/networks to not respond to at all.
  • It depends on how you define security device. A better term would be access control device since it could be something like ACLs on a router.
  • Depending on the application and its networking stack its possible. A application with a user land network stack can choose what to do with the requests instead of the OS.
Improve this answer
9

In most operating systems, handling the TCP three-way handshake is the responsibility of the operating system's networking code. Applications can only declare interest in receiving connections on a certain port by means of the listen() system call. The operating system will answer a SYN with a SYN/ACK if there is an application listening on the port, and with a RST otherwise. No application has any say in that.

This is the default behaviour. It can be modified by many things, including but not limited to packet filtering mechanisms on the host. In addition, specialized implementation of TCP/IP may behave differently on purpose.

When NMAP receives neither a SYN/ACK nor a RST in reply to a SYN packet it reports that port as "filtered". It has no way to determine the reason why it didn't receive a reply. Conversely, if an intervening firewall blocks the port by replying with RST then NMAP will report the port as closed even though the probe packet never actually reached its destination.

In sum, your quote is at least inexact. NMAP also reports ports as filtered if they cannot be determined as open or closed for other reasons besides packet filtering. Packet filtering is just the most common of causes, and has therefore become the eponym for that result. What's more, NMAP may even report a port as closed when it cannot determine it as open or closed because of an intervening packet filter.

Improve this answer
3

Upon trying to enter the simplest form of target network:

Internet   ---  firewall  ---   target

you will cross at least 3 level of filtering:

  1. firewall
  2. at the OS level of the target
  3. at the application level of the target

At each of these levels a 1st IP packet (and any other protocol packet as an ESP or AH packet) might receive 4 types of treatment:

  1. the packet is simply dropped (not any form of reply)
  2. the packet is droped and an ICMP type 3, code 9 or 10 is returned,
  3. receive a TCP RST packet
  4. receive a TCP ACK packet

Real networks are build up of this basic brick.

Improve this answer
0

There are several questions here, let me try and rephrase them, so a proper response can be given.

Question 1. Do systems reply with SYN/ACK or RST if the traffic reaches a host?

Short answer - not necessarily, you may get an ICMP destination unreachable (port unreachable), which is considered an acceptable reply when there is no process listening on that port (RFC 1122, page 40 and RFC 792, page 5). You also may get no reply at all - unfortunately not everyone complies with RFC specifications. Unfortunately, I've seen implementations that reply to SYN with a FIN! Yes, it can be that bad.

Question 2. Will every probe that manages to reach the port will be properly replied?

Short answer - not necessarily, TCP stack implementations across operating systems vary, for example, I've seen embedded systems with limited resources that have had the listener process swapped out, and by the time the process has been restored back to memory, the window of opportunity for a reply has closed. It's an exception rather than the rule, but you should keep in mind that not everyone would comply with the standard - some may have built-in SYN flood protection mechanisms that may see too many SYN segments from the same host as an attempt at DoS.

Question 3. Can an application ignore probes?

Typically it's not the application's responsibility to do that, it's the OS stack that looks after these things. It's not to say that you cannot implement your own protocol handler, but it's rarely the case. But I'd say that few applications have a say in the TCP handshake part of their communications.

I hope you find these answers helpful :-)

Improve this answer

You must log in to answer this question.