preauth usage
"Michael T. Davis" <[email protected]> Mon, 05 Apr 2010 12:32:40 -0400 (EDT)
| Newsgroups | gmane.comp.security.firewalls.ipfilter |
|---|---|
| Message-ID | <18967_1270485292_4BBA112C_18967_2883_1_01NLLCNLRJYQ96DXHF@ecr6.ohio-state.edu> |
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