2

I am trying to understand the results I am getting when scanning ports on a machine that has an active built-in Windows Firewall. My test environment has two Windows 7 machines running in Hyper-V VMs connected directly with an internal virtual switch and in the same subnet with no other firewalls between them.

Machine A - Windows Firewall turned off and running Nmap 7.60

Machine B - Machine being scanned

When Windows Firewall is turned off on Machine B, all ports are showing as either open or closed - EXPECTED.

When Windows Firewall is turned on on Machine B with default rules, some ports are showing as opened (EXPECTED) and the rest are showing as Filtered.

When I create an inbound rule to allow connections on a specific port that doesn't have a listener, I would expect that port to be scanned as closed, however it is still showing as Filtered with the reason No Response.

Can someone explain why is there no response when scanning a port for which there is an active inbound rule to allow connections and no deny rule? I am using SYN scan.

David
  • 21
  • 1
  • 2
  • It's probably because TCP isn't sending a RST. – Ron Maupin Oct 04 '17 at 02:18
  • Sure but why is TCP sending a RST when Firewall is OFF and not sending it when Firewall is ON? – David Oct 04 '17 at 02:23
  • TCP is required to send a RST when it doesn't have the requested port open. The firewall filters the request to TCP, so it never receives it to send the RST. – Ron Maupin Oct 04 '17 at 02:44
  • Firewall shouldn't filter the request as there is an inbound rule to allow connection. – David Oct 04 '17 at 11:36
  • If there is also a rule that blocks the port, e.g. a rule blocking all ports, it will take precedence, even over a rule allowing the connection. Windows firewall is rather strange this way. – Ron Maupin Oct 04 '17 at 12:49
  • There is nothing blocking the ports. I even tried another simple test to confirm. I installed an FTP server listening on port 21. Without an inbound rule the port shows as FILTERED. I then created an inbound rule and the port showed as OPENED (meaning the inbound rule works). But as soon as I stopped the listener (FTP) service, the port went back to FILTERED. – David Oct 04 '17 at 14:58

3 Answers3

2

The firewall filters the TCP SYN so that TCP never receives it, and TCP cannot then send the required RST. From RFC 793, Transmission Control Protocol:

Reset Generation

As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.

There are three groups of states:

  1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the CLOSED state.

  2. If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.

    If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the same state.

  3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.

Community
  • 1
Ron Maupin
  • 3,243
  • 1
  • 12
  • 20
  • That doesn't explain why the port is still showing as filtered when the firewall is modified to allow connections to a specific port. – womble Oct 04 '17 at 03:02
  • 1
    Yes, because deny takes precedence over allow. Specifically allowing something denied is still denied. The Windows firewall doesn't process in order of entries the way something like a Cisco ACL does. – Ron Maupin Oct 04 '17 at 05:14
  • There are no deny rules in this firewall that I can see. – David Oct 04 '17 at 11:36
  • The default behavior of the Windows Firewall is to block unsolicited inbound network traffic, there doesn't need to be an explicit deny rule. – joeqwerty Oct 04 '17 at 23:18
0

When I create an inbound rule to allow connections on a specific port that doesn't have a listener

If you create a firewall rule for a port with no LISTENER, then its completly normal you have no response, as nothing answer on that port.

Quote from there

If something other than LISTENING is returned then there could be a problem with a port being blocked somewhere. If the port shows to be FILTERED then a firewall or VLAN could be blocking that port, if the port returns NOT LISTENING then we got to the machine but the machine is not listening on that port number.

yagmoth555
  • 16,758
  • 4
  • 29
  • 50
  • I should still get a RST as I do when Firewall is turned off. – David Oct 04 '17 at 11:38
  • It almost seems like the Windows Firewall has some sort of built-in functionality to not allow RST to go back in this scenario. Maybe it is designed to prevent this kind of port scanning because otherwise it would be easy for a hacker to enumerate inbound rules even when there are no listeners. Is that possible? – David Oct 04 '17 at 11:47
  • @David try the tool listed in the article I link too, as the article fit the symptom you have – yagmoth555 Oct 04 '17 at 11:47
  • @David yes its possible, kinda why I searched a doc from microsoft – yagmoth555 Oct 04 '17 at 11:48
  • thanks, I carefully reviewed it but don't really see any new information. I also tried portqry and it shows ports as FILTERED where I would expect it to show them as NOT LISTENING. – David Oct 04 '17 at 14:19
0

Found the answer.

The reason that ports come out as FILTERED even though there is an inbound rule is the feature called “Stealth Mode” that “blocks outgoing ICMP unreachable and TCP reset messages for a port when no application is listening on that port”.

https://technet.microsoft.com/en-us/library/dd448557(v=ws.10).aspx

David
  • 21
  • 1
  • 2