On Mon, Oct 14, 2002 at 04:46:33PM -0400, Mike Frantzen wrote: > > The application has to specify not only the > > complete rule parameters, but has to know _where_ exactly to place the > > rule in the ruleset (beginning, end, after a rule? etc.) > > I'd hope so. I wouldn't want authpf to start placing rules at the end > of my ruleset of mostly quicks.
Yes and at present there is no way to tell an application exactly where to place the rule and that is one of the problems I was trying to solve. > > Furthermore, > > the administrator has no control on what rule an application inserts, or > > a way to konw which rules are inserted by an application. > > Configure your app to add a label to the rules if you want to > distinguish them. If an admin has no control over what an application > inserts, why would he run the app? 'control' is the wrong word. I guess 'fine-tune' would have been better. Given the large number of different network configurations, possible rulesets and continuing pf improvements, it is hard for an application to supply reasonable values to all the rule fields. There was no 'user' keyword when I started thiking about this and now there is the altq integration (no I am not complaining). > > To make matters > > more complex, if the application crashes, it may leave permanent rules > > in the ruleset. > > Aha! That is a real issue. The way we had talked about solving that up > in Calgary was to extend proc so rules could be tied to a process. When > the process goes away, it calls back into PF which removes the rules. > Were we talking about that in Calgary or in DC a year ago?? Hell, I > can't remember. Bob was running around in a tizzy with excitement > though (now that was a sight!) I would like to see that (both :) ). > > Now, after all that talk, I should note that, with proper usage of > > static rules (especially the user keyword) most proxy servers would > > never need to insert rules (or can be designed to remove that requirement) > > However there are isolated cases where it would be useful see > > the recent post by Matthew Sweet for instance. That is why I could not > > easily come up with a real world example. > > It is a cool concept, I'll give you that. But I still don't see the > problem you're trying to solve. Thanks, and thank you for the comments. That is exactly the kind of feedback I was waiting for. Although it probably would not matter any more, I have been refining the idea and could not resist posting the final version which is much more intuitive: * all rules including nat/rdr have a optional 'dynamic' flag. * dynamic rules hold a list of (initially empty) instances. * the instances only contain src/dest addr/port filters and redirection information, most of which is optional. * the list is evaluated after the rule matches, the rule acts as a template, refined by the instances. * a dynamic rule does NOT match unless an instance matches. * the applications attach instances to dynamic rules using an ioctl. * the instances expire with time, activation count (or process termination :) ) The result is: * better, consistent syntax. * dynamic rules can now block as well as pass. A real life example - IDS triggered dynamic blacklists with auto expiration: The IDS engine requires two label strings (that could be identical) and adds the suspect IP address to rules identified by the labels. these labels, one for src addr and one for the destination. The IDS needs no configuration about interfaces, protocols and other rule options except for expiration timeouts. The administrator can define the rule template in pf.conf and can block, log, route to another interface or rdr to a honeypot as necessary. # Block all attacks recognized by IDS # same label for src/dest block in all dynamic label_ids or # redirect to honeypot rdr on $ext_if from any to any -> $honeypot dynamic label_ids_src # block all non-redirected packets block out quick on $ext_if from any to any dynamic label_ids_dst Can
