Mike, "preauth" rules were added without either good documentation nor test cases to back up their functionality, so it is hard even for me to be sure of what they do or were supposed to do now.
As such, I'm looking at removing them. Darren Michael T. Davis wrote: > I'd like to leverage preauth, if possible, to add an optionally > tighter access control to certain services. For example, let's look at > SSH: > > block in quick on fxp0 proto tcp from any to any port = 22 head 22 > block in quick from <bad-ip-1> to any group 22 > block in quick from <bad-ip-2> to any group 22 > #...etc... > pass in quick proto tcp from any to <ip-range-1> \ > flags S/SAFR keep state group 22 > pass in quick proto tcp from any to <ip-range-2> \ > flags S/SAFR keep state group 22 > #...etc... > > Could a preauth rule be added as the second rule in the group...? > > block in quick on fxp0 proto tcp from any to any port = 22 head 22 > preauth in quick from any to any group 22 > block in quick from <bad-ip-1> to any group 22 > block in quick from <bad-ip-2> to any group 22 > #...etc... > pass in quick proto tcp from any to <ip-range-1> \ > flags S/SAFR keep state group 22 > pass in quick proto tcp from any to <ip-range-2> \ > flags S/SAFR keep state group 22 > #...etc... > > I'm concerned over the man page entry, which says, "If no further matching > rule is found, the packet will be dropped..." Is this the case even for a > preauth in a group? I'm hoping that, upon not finding a matching rule in the > pre-auth. list, processing would "bounce back" to the group and continue > processing the group rules. Or, should the paraenthetical statement, "...the > FR_PREAUTH is not the same as FR_PASS," be interpreted to mean that rule > processing doesn't work the same for preauth, and if a matching rule doesn't > exist in the pre-auth. list, the packet really will be dropped right then and > there (regardless of any pre-existing "group context")? > > Thanks, > Mike >
