Skip to main content

Firewall and IDS/IPS Evasion

Nmap gives you several ways to work around firewall rules and IDS/IPS controls. These methods include packet fragmentation, decoys, custom source settings, and other techniques that reduce how obvious your scans look.

Firewalls

A firewall is a security control that blocks or permits connection attempts from external networks. Every firewall is built around a software component that monitors traffic between the host and incoming connections, then decides how to handle each packet based on configured rules. The firewall can pass, ignore, or block individual network packets. This mechanism is designed to prevent unwanted connections that could be dangerous.

IDS/IPS

Like a firewall, an intrusion detection system (IDS) and intrusion prevention system (IPS) are software-based security controls. IDS monitors the network for potential attacks, analyzes suspicious activity, and reports what it finds. IPS extends this by taking defensive action automatically when it detects traffic that matches configured rules. These systems often rely on pattern matching and signatures. If they detect recognizable scan behavior, such as aggressive service detection, they may flag or block the traffic.

Determine Firewalls and Their Rules

When Nmap shows a port as filtered, several explanations are possible. In many cases, a firewall is enforcing rules for that connection attempt. The packet may be dropped or rejected. Dropped packets are ignored and generate no response. Rejected packets trigger an explicit reply. TCP packets are commonly rejected with the RST flag, while ICMP responses may include different error codes. Common ICMP errors include:
  • Net Unreachable
  • Net Prohibited
  • Host Unreachable
  • Host Prohibited
  • Port Unreachable
  • Proto Unreachable
Nmap’s TCP ACK scan (-sA) is often harder for firewalls and IDS/IPS controls to filter than SYN (-sS) or connect (-sT) scans because it sends a packet with only the ACK flag set. If the target port is open or closed, the host typically replies with RST. By contrast, new inbound connection attempts that start with SYN are more likely to be filtered by a firewall. ACK packets are sometimes allowed through because the firewall cannot always tell whether the connection originated externally or from inside the network. If you compare these scans, the difference becomes visible quickly.

SYN Scan

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -p 21,22,25 -sS -Pn -n --disable-arp-ping --packet-trace

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 14:56 CEST
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:22 S ttl=53 id=22412 iplen=44  seq=4092255222 win=1024 <mss 1460>
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:25 S ttl=50 id=62291 iplen=44  seq=4092255222 win=1024 <mss 1460>
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:21 S ttl=58 id=38696 iplen=44  seq=4092255222 win=1024 <mss 1460>
RCVD (0.0329s) ICMP [10.129.2.28 > 10.10.14.2 Port 21 unreachable (type=3/code=3)] IP [ttl=64 id=40884 iplen=72]
RCVD (0.0341s) TCP 10.129.2.28:22 > 10.10.14.2:57347 SA ttl=64 id=0 iplen=44  seq=1153454414 win=64240 <mss 1460>
RCVD (1.0386s) TCP 10.129.2.28:22 > 10.10.14.2:57347 SA ttl=64 id=0 iplen=44  seq=1153454414 win=64240 <mss 1460>
SENT (1.1366s) TCP 10.10.14.2:57348 > 10.129.2.28:25 S ttl=44 id=6796 iplen=44  seq=4092320759 win=1024 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.0053s latency).

PORT   STATE    SERVICE
21/tcp filtered ftp
22/tcp open     ssh
25/tcp filtered smtp
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)

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

ACK Scan

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -p 21,22,25 -sA -Pn -n --disable-arp-ping --packet-trace

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 14:57 CEST
SENT (0.0422s) TCP 10.10.14.2:49343 > 10.129.2.28:21 A ttl=49 id=12381 iplen=40  seq=0 win=1024
SENT (0.0423s) TCP 10.10.14.2:49343 > 10.129.2.28:22 A ttl=41 id=5146 iplen=40  seq=0 win=1024
SENT (0.0423s) TCP 10.10.14.2:49343 > 10.129.2.28:25 A ttl=49 id=5800 iplen=40  seq=0 win=1024
RCVD (0.1252s) ICMP [10.129.2.28 > 10.10.14.2 Port 21 unreachable (type=3/code=3)] IP [ttl=64 id=55628 iplen=68]
RCVD (0.1268s) TCP 10.129.2.28:22 > 10.10.14.2:49343 R ttl=64 id=0 iplen=40  seq=1660784500 win=0
SENT (1.3837s) TCP 10.10.14.2:49344 > 10.129.2.28:25 A ttl=59 id=21915 iplen=40  seq=0 win=1024
Nmap scan report for 10.129.2.28
Host is up (0.083s latency).

PORT   STATE      SERVICE
21/tcp filtered   ftp
22/tcp unfiltered ssh
25/tcp filtered   smtp
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Scanning OptionDescription
10.129.2.28Scan the specified target.
-p 21,22,25Scan only the specified ports.
-sSPerform a SYN scan on the specified ports.
-sAPerform an ACK scan on the specified ports.
-PnDisable ICMP echo requests.
-nDisable DNS resolution.
--disable-arp-pingDisable ARP ping.
--packet-traceShow all packets sent and received.
Pay close attention to the RCVD packets and the flags returned by the target. With the SYN scan (-sS), the target tries to establish the TCP connection by returning a packet with SYN-ACK (SA) set. With the ACK scan (-sA), you receive RST because TCP port 22 is open. For TCP port 25, the target sends nothing back, which indicates that the packets are being dropped.

Detect IDS/IPS

Unlike firewall detection, identifying IDS/IPS controls is much harder because these are often passive traffic-monitoring systems. IDS reviews connections between hosts and looks for traffic that matches predefined content, signatures, or behavior. If it finds a match, it alerts an administrator. IPS goes one step further and can block traffic automatically based on administrator-defined rules. IDS and IPS are separate functions, even when they operate together. During a penetration test, using several VPS hosts with different IP addresses can help you determine whether these controls are active. If one host suddenly loses access to the target network, that is often a strong sign that defensive action has been taken against that source. IDS by itself is usually intended to help administrators detect suspicious traffic and decide how to respond. You can sometimes trigger defensive action by scanning a service too aggressively. When that happens, you learn that the network is being watched and that future scans need to be quieter and better disguised. One simple test is to scan from a single VPS and watch for a sudden loss of access. If that source gets blocked, continue only from another controlled host and reduce how noisy your probes are.

Decoys

Sometimes administrators block traffic from specific regions or subnets by default. In other cases, IPS may respond directly to your source IP. For these situations, decoy scanning with -D can help disguise where the packets came from. With this option, Nmap inserts additional IP addresses into the packet headers. You can generate random decoys with RND, followed by a number such as 5. Nmap places your real IP somewhere among those decoys. In the next example, the real source appears in the second position. The decoys must be alive. If they are not, the target service may become unreachable because SYN flood protections can react badly to obviously fake traffic.

Scan by Using Decoys

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -p 80 -sS -Pn -n --disable-arp-ping --packet-trace -D RND:5

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 16:14 CEST
SENT (0.0378s) TCP 102.52.161.59:59289 > 10.129.2.28:80 S ttl=42 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
SENT (0.0378s) TCP 10.10.14.2:59289 > 10.129.2.28:80 S ttl=59 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 210.120.38.29:59289 > 10.129.2.28:80 S ttl=37 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 191.6.64.171:59289 > 10.129.2.28:80 S ttl=38 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 184.178.194.209:59289 > 10.129.2.28:80 S ttl=39 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 43.21.121.33:59289 > 10.129.2.28:80 S ttl=55 id=29822 iplen=44  seq=3687542010 win=1024 <mss 1460>
RCVD (0.1370s) TCP 10.129.2.28:80 > 10.10.14.2:59289 SA ttl=64 id=0 iplen=44  seq=4056111701 win=64240 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.099s latency).

PORT   STATE SERVICE
80/tcp open  http
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Scanning OptionDescription
10.129.2.28Scan the specified target.
-p 80Scan only the specified port.
-sSPerform a SYN scan on the specified port.
-PnDisable ICMP echo requests.
-nDisable DNS resolution.
--disable-arp-pingDisable ARP ping.
--packet-traceShow all packets sent and received.
-D RND:5Generate five random IP addresses as decoys for the scan source.
Spoofed packets are often filtered by ISPs and routers, even when they appear to come from the same network range. In those cases, use reachable VPS addresses as decoys and combine them with IP ID manipulation techniques when appropriate. Another possibility is that only specific subnets are blocked from accessing a service. In that case, set a different source IP with -S to test whether a more trusted address changes the result. Decoys can be used with SYN, ACK, ICMP, and OS detection scans.

Testing a Firewall Rule

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -n -Pn -p 445 -O

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-22 01:23 CEST
Nmap scan report for 10.129.2.28
Host is up (0.032s latency).

PORT    STATE    SERVICE
445/tcp filtered microsoft-ds
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.14 seconds

Scan by Using a Different Source IP

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -n -Pn -p 445 -O -S 10.129.2.200 -e tun0

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-22 01:16 CEST
Nmap scan report for 10.129.2.28
Host is up (0.010s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 2.6.32 (96%), Linux 3.2 - 4.9 (96%), Linux 2.6.32 - 3.10 (96%), Linux 3.4 - 3.10 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Synology DiskStation Manager 5.2-5644 (94%), Linux 2.6.32 - 2.6.35 (94%), Linux 2.6.32 - 3.5 (94%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.11 seconds
Scanning OptionDescription
10.129.2.28Scan the specified target.
-nDisable DNS resolution.
-PnDisable ICMP echo requests.
-p 445Scan only the specified port.
-OPerform operating system detection.
-SSet a different source IP address for the scan.
10.129.2.200Use this IP as the scan source.
-e tun0Send requests through the specified interface.

DNS Proxying

By default, Nmap performs reverse DNS resolution unless you disable it. These DNS queries are often allowed because the target’s services are expected to be reachable. DNS usually uses UDP port 53, while TCP port 53 has historically been used for zone transfers or responses larger than 512 bytes. With IPv6 and DNSSEC, TCP 53 is more common than it used to be. Nmap lets you define your own DNS servers with --dns-server <ns>,<ns>. This can be valuable when you are operating from a DMZ, where internal DNS servers may be more trusted than public ones. You can also use TCP port 53 as the source port with --source-port. If the administrator permits traffic based on that port and IDS/IPS filtering is weak, those packets may be treated as trusted and allowed through.

SYN Scan of a Filtered Port

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -p 50000 -sS -Pn -n --disable-arp-ping --packet-trace

Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 22:50 CEST
SENT (0.0417s) TCP 10.10.14.2:33436 > 10.129.2.28:50000 S ttl=41 id=21939 iplen=44  seq=736533153 win=1024 <mss 1460>
SENT (1.0481s) TCP 10.10.14.2:33437 > 10.129.2.28:50000 S ttl=46 id=6446 iplen=44  seq=736598688 win=1024 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up.

PORT      STATE    SERVICE
50000/tcp filtered ibm-db2

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

SYN Scan from DNS Port

Dudji@htb[/htb]$ sudo nmap 10.129.2.28 -p 50000 -sS -Pn -n --disable-arp-ping --packet-trace --source-port 53

SENT (0.0482s) TCP 10.10.14.2:53 > 10.129.2.28:50000 S ttl=58 id=27470 iplen=44  seq=4003923435 win=1024 <mss 1460>
RCVD (0.0608s) TCP 10.129.2.28:50000 > 10.10.14.2:53 SA ttl=64 id=0 iplen=44  seq=540635485 win=64240 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.013s latency).

PORT      STATE SERVICE
50000/tcp open  ibm-db2
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
Scanning OptionDescription
10.129.2.28Scan the specified target.
-p 50000Scan only the specified port.
-sSPerform a SYN scan on the specified port.
-PnDisable ICMP echo requests.
-nDisable DNS resolution.
--disable-arp-pingDisable ARP ping.
--packet-traceShow all packets sent and received.
--source-port 53Send the scan from source port 53.
Now that you know the firewall accepts TCP port 53, there is a good chance IDS/IPS filtering is weaker there as well. You can test that by attempting an actual connection with Netcat.

Connect to the Filtered Port

Dudji@htb[/htb]$ ncat -nv --source-port 53 10.129.2.28 50000

Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 10.129.2.28:50000.
220 ProFTPd

Firewall and IDS/IPS Evasion Labs

In the next sections, you can practice against scenarios where firewall rules and IDS/IPS protections interfere with scanning. Use the techniques above to work around those controls as quietly as possible. If you scan too aggressively, IPS may block you before you collect enough data.