Quote:
|
...the second and last lines are not taken by PF which throws up an error...
|
Usage and syntax for the TCP
flags option is described in the
pf.conf(5) man page. There, you will learn how to test for specific cleared or set flags.
---
Disclaimer one: I don't use
flags options in any of my own rule definitions. I also don't recommend them to admins who do not have a clear understanding of each flag. Unless you understand each specific flag's specific purpose and role you may block desired traffic or inadvertantly permit undesired traffic.
TL;DR - Just because the tool gives you a gun, it does not mean you must pull the trigger. It's usually aimed at your own feet.
Disclaimer two: I don't believe blocking scans serves a useful purpose for those of us who use a
block all policy and only pass permitted traffic, since only the permitted traffic will pass. I also use the
return option with my block rules. I do this because appropriate blocked traffic that is dropped should learn about the drop immediately -- this limits application issues at the client. And I'm nice to the inappropriate traffic as well, because I don't believe dropping packets is useful, as there is no security through obscurity. Bad actors can still find the services I present to the Internet. For those services, I rely on application level protections such as authentication mechanisms.
TL;DR - Everything I don't want in is already blocked, whether they scan or not.