# PF blocking nmap



## bbzz (Dec 18, 2010)

Hi.
These are my pf.conf settings:

```
ext_if="re0"
scrub in on $ext_if all fragment reassemble

block all

set skip on lo0
antispoof for $ext_if inet

### filter spoofs
block in quick on $ext_if proto tcp flags FUP/WEUAPRSF
block in quick on $ext_if proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $ext_if proto tcp flags SRAFU/WEUAPRSF
block in quick on $ext_if proto tcp flags /WEUAPRSF
block in quick on $ext_if proto tcp flags SR/SR
block in quick on $ext_if proto tcp flags SF/SF

### traffic going OUTSIDE
pass out on $ext_if proto { tcp, udp, icmp } from any to any flags any modulate state

### traffic going INSIDE
pass in on $ext_if proto tcp from any to any port ssh flags S/SA
pass in on tap0 
#pass in on $ext_if proto tcp from any to any port www flags S/SA

###  prevent brute force on ssh
table <ssh_abuse> persist
block in log quick from <ssh_abuse>
pass in on $ext_if proto tcp to any port ssh flags S/SA keep state (max-src-conn 10, max-src-conn-rate 3/5, overload <ssh_abuse> flush)
```

Two questions. First - is the configuration above for ssh correct?; meaning, there are two references to it, one in "traffic going INSIDE" part and another at the end. 

My second question is, why is pf blocking certain NMAP generated packets (such as icmp type 13 [timestamp], or certain tcp packets)? I tried to specify all flags rather than just S/SA as it is by default. In order to make NMAP successfully send all packets I have to disable firewall.  
Any help is welcome!


----------



## SirDice (Dec 20, 2010)

You can lose the first rules for ssh. It's more or less overridden by the second.

PF is blocking ICMP because of the "block all" at the beginning. Certain TCP flags are blocked because of the "filter spoof" rules.


----------



## bbzz (Dec 21, 2010)

SirDice said:
			
		

> You can lose the first rules for ssh. It's more or less overridden by the second.
> 
> PF is blocking ICMP because of the "block all" at the beginning. Certain TCP flags are blocked because of the "filter spoof" rules.



Hi,

But, I am permitting ICMP later on, which overrides block all command. And, it's not blocking all ICMP just specific ones, such as type 13.
As for filter spoof rules, are you referring to "antispoof" command at the top? As far as i know it simply blocks any packet with source address equal to IP of interface. 

So, how can I modify my rules so that I am able to permit all packets OUT, regardless of being spoofed/forged/invalid, etc. 
Thanks


----------



## SirDice (Dec 22, 2010)

bbzz said:
			
		

> But, I am permitting ICMP later on, which overrides block all command.


Yes, but only on _outgoing_ ICMP, not incoming.



> As for filter spoof rules, are you referring to "antispoof" command at the top? As far as i know it simply blocks any packet with source address equal to IP of interface.


No, I'm referring to the set of block rules just below the remark "### filter spoofs". 



> So, how can I modify my rules so that I am able to permit all packets OUT, regardless of being spoofed/forged/invalid, etc.


You already have a rule like that.


----------



## kpa (Dec 22, 2010)

Your drop rules with various tcp flag combinations are redundant and potentially harmful, the OpenBSD PF handbook recommends to check only S/SA which is the default anyway, see here: 

http://www.openbsd.org/faq/pf/filter.html#tcpflags


----------



## bbzz (Dec 23, 2010)

SirDice said:
			
		

> Yes, but only on _outgoing_ ICMP, not incoming.



I don't need to explicitly permit ICMP traffic in, as the firewall keeps pseudo-state of outgoing connection. If I do a UDP trace out, it will know to let stuff like ttl-exceeded or port-unreachable back in. Besides, and a this point I fear I wasn't clear enough, I don't have problem letting traffic in, just out. I will take it you misunderstood my question. 



@kpa

S/SA means that firewall checks for SYN flag out of SYN+ACK combo. This is on by default. It won't check for other (invalid) combinations I have in there, which can be useful for mapping out operating systems and is used by nmap, to name one.


----------



## SirDice (Dec 23, 2010)

Ok, now I'm getting confused. Is the problem with nmap going out of the network or is it incoming nmap scans?


----------



## kpa (Dec 23, 2010)

You have scrub on and that means any packets with invalid or ambiguous flags will be dropped before the rules are evaluated so these rules are effectively no-ops and have no effect on the operation of the firewall:


```
block in quick on $ext_if proto tcp flags FUP/WEUAPRSF
block in quick on $ext_if proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $ext_if proto tcp flags SRAFU/WEUAPRSF
block in quick on $ext_if proto tcp flags /WEUAPRSF
block in quick on $ext_if proto tcp flags SR/SR
block in quick on $ext_if proto tcp flags SF/SF
```


----------



## bbzz (Dec 23, 2010)

There is no guarantied list of invalid flags that scrub process will block, and the question is just how well it works on all combinations. This is documented. Some might be redundant, but there is no harm, which is what that guide says as well. 

Anyway, how to I make forged packets go out, without stopping firewall?

Thanks.


----------



## SirDice (Dec 23, 2010)

bbzz said:
			
		

> Anyway, how to I make forged packets go out, without stopping firewall?


Remove all it's rules. Nmap works by sending some 'odd' packets. PF will most likely mangle those or the responses thereby confusing nmap.


----------



## bbzz (Dec 23, 2010)

SirDice said:
			
		

> Remove all it's rules. Nmap works by sending some 'odd' packets. PF will most likely mangle those or the responses thereby confusing nmap.



Nmap forges invalid packets which is why fw doesn't let all go out. I would hate to believe that there is no way of letting ALL packets out, regardless of them being forged. Maybe I should look into different firewall? Stopping a fw so I can do nmap doesn't make sense.


----------



## DutchDaemon (Dec 23, 2010)

But isn't that like not wanting to turn the sprinkler system off, but at the same time not wanting it to douse water on a raging fire?


----------



## SirDice (Dec 23, 2010)

bbzz said:
			
		

> Nmap forges invalid packets which is why fw doesn't let all go out. I would hate to believe that there is no way of letting ALL packets out, regardless of them being forged. Maybe I should look into different firewall? Stopping a fw so I can do nmap doesn't make sense.


You'll only need to do this if you use the more exotic scan and/or spoofing options of nmap. You can pretty much be sure _any_ firewall will mangle the results. A 'regular' SYN (half-open) scan shouldn't be a problem, I do those regularly and noticed no adverse effects on the results (with PF running and my normal rules).


----------



## bbzz (Dec 24, 2010)

Except it doesn't work always, even with tcp syn scan.

This happens pretty often.


```
# nmap -sS 192.168.1.2

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-12-24 16:24 UTC
Stats: 0:00:02 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 1.73% done; ETC: 16:26 (0:02:50 remaining)
Stats: 0:00:03 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 2.75% done; ETC: 16:26 (0:02:21 remaining)
sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, 192.168.1.2, 16) => Operation not permitted
Offending packet: TCP 192.168.1.100:60344 > 192.168.1.2:443 S ttl=44 id=12392 iplen=11264  seq=1362146477 win=1024 <mss 1460>
Stats: 0:00:10 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
```

And, as much as I hate to admit it, I don't remember having this sort of issue on linux default fw.


----------

