On Fri, Nov 12, 2010 at 2:16 PM, Frank Brodbeck <[email protected]> wrote: > and please stop using macros for interfaces.
What exactly is wrong with using macros for interfaces? It seems very common, and is repeated in both the OpenBSD's PF FAQ and The Book of PF. OK, so about these rules: @1 block return in log all @2 pass out quick on sis0 proto tcp all flags S/SA modulate state @3 pass out all flags S/SA keep state I still don't see how that "opens any ports" for outbound traffic returning as part of a request from inbound traffic. All traffic inbound on an interface should be blocked; like I mentioned earlier (although I realize I didn't quite say it right) any ingress traffic headed anywhere is blocked unless a later rule allows it to pass. I'm not filtering egress traffic because if the inbound traffic is already blocked by default, that should be enough to prevent the connection...right? To me it made more conceptual sense to only block one direction, instead of both... and unless I am mistaken (as it appears I am), I thought that this approach would be sufficient to supply a default deny policy to all of my interfaces. >From the OpenBSD PF FAQ: "Keep in mind, pf can block traffic coming into or leaving out of an interface. It can simplify your life if you choose to filter traffic in one direction, rather than trying to keep it straight when filtering some things in, and some things out. In our case, we'll opt to filter the inbound traffic, but once the traffic is permitted into an interface, we won't try to obstruct it leaving, so we will do the following:" That sounded like good advice to me. So since there's some stuff between my work machine and my home machine, I wanted to try using a different utility for portscanning. I used GRC's ShieldsUp web application which is OK. With the block policy set to return it shows a handful of ports listed as "stealth", which probably means my ISP filters them and everything else listed as "closed". Now, it's not really clear from their site whether "closed" means, they got a connection refused (the traffic was blocked) or a connection failed (the was no service running on that port). I guess, what I'm saying is... results are still inconclusive whether or not I'm actually correctly implementing a default deny policy. Thanks again to everyone who's taken the time to reply and listened to my drivel.
