OK, I actually have more than a couple questions. I'm basically
pursuing two IPF-related topics. The first should be relatively easy to
address.
First of all, I'm contemplating upgrading an OpenBSD-based firewall.
Is IPF supported with the most recent stable OpenBSD release (i.e. v4.1 as I
compose this message)? If so, what version of IPF would be the most stable?
(FWIW, I prefer IPF over pf.)
I'm conceptualizing a network authentication system for people
accessing a firewalled network from "outside." I'm hoping to code things via
various scripting mechanisms, rather than compiling anything. The UI is
planned to be a Web page. The idea is that the remote user hits a secure Web
form requiring authentication. Upon successful login, the Web server "back-
end" will initiate addition of a few IPF rules into the authentication table,
presumably via...
% echo "<ipf-rule1>[\n<ipf-rule2>[etc.]]"|ipf -P -f -
I am inferring from ipf(5) that the above will work with a pre-defined preauth
rule (or set of such rules), but it's not exactly clear to me how. For
example, "-P" creates a "temporary" entry in the authentication rule table.
What defines the lifespan of the entry? If that's left to me, do I just need
to subsequently repeat the above with the "-r" flag? A typical rule set for a
protocol I might want to handle this way currently looks something like this
(using MS Remote Desktop as an example):
block return-rst in quick on fxp0 proto tcp \
from any to any port = 3389 head 3389
# Miscreants we don't care about
block return-rst in quick proto tcp \
from <remote-CIDR> to any flags S/SAFR group 3389
[...etc...]
# Allow access to local net.
pass in log first quick proto tcp \
from any to <local-CIDR> flags S/SAFR keep state keep frags group 3389
Could I merely modify that last pass rule to use the same syntax, only starting
it with "preauth" instead of "pass" and then use the above ipf command to
include a pass rule citing the specific IP address from which the remote user
authenticated? I would also be interested in transitioning to this solution
for a short time. Assuming all that's necessary is the switch from "pass" to
"preauth", could I add a subsequent "pass" rule (identical to the one above)
immediately after the preauth rule to allow "unauthenticated" access for a
time?
Thanks for your consideration,
Mike
--
Michael T. Davis (Mike) | Systems Specialist: CBE,MSE
E-mail: [EMAIL PROTECTED] | Departmental Networking/Computing
-or- [EMAIL PROTECTED] | The Ohio State University
http://www.ecr6.ohio-state.edu/~davism/ | 197 Watts, (614) 292-6928
