View Single Post
  #2   (View Single Post)  
Old 13th March 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,937
Default

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.
Reply With Quote