Re: RFC: libpf, simplifying pf(4) access to userland apps
On Fri, Jan 10, 2003 at 07:53:47AM +0100, Saad Kadhi wrote: > > echo 'block in quck from $attacker to any' | pfctl -a attacks -R -f - > is the '-R' flag required for this? wouldn't it just make pf reload the > whole bunch of rules instead of just adding a rule to the anchor rule > subset? No, when -a anchorname is specified, the entire pfctl invocation applies only to that anchor ruleset. So -f means 'load the rules into the anchor', -Fr means 'flush the filter rules from the anchor', -sr 'show the filter rules in the anchor', etc. An anchor can also contain nat/binat/rdr rules. If it does, there's a difference between echo 'block in quick from 10.1.2.3 to any' | pfctl -a foo:bar -R -f - and echo 'block in quick from 10.1.2.3 to any' | pfctl -a foo:bar -f - The latter will remove not just the existing filter rules in anchor foo's ruleset bar first, but nat/binat/rdr rules, too. The former just replaces the filter rules in foo:bar. If you created the sub-ruleset just to hold such block rules, and know there are no translation rules, it doesn't matter. But -R doesn't make the command apply to the main ruleset in this case, it means 'only process filter rules (in the anchor ruleset that was specified)'. Daniel
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 08:21:29PM -0500, Marina Brown wrote: > On Thu, 09 Jan 2003, Srebrenko Sehic wrote: > > > > 4) I've never used authpf, but I wonder why authpf does not > > > call the pfctl binary, to have the benefit of code reuse without > > > that tricky sharing of files. Combining binaries is usually the > > > Unix way, I believe. > > > > pfctl does not support inserting rules on the fly and authpf needs that. > > On the other hand, the overhead of having that would be too big. > > > > I run an ISP that is almost totally OpenBSD. While i understand the > need for pfctl to be lightweight, it would be VERY nice to have a > utility to add or delete a temporary rule when an attack is on. for this kind of stuff (you wanna block attacking IPs completely I might guess), tables are optimal. If the rules are more complex, you just add an anchor to your main ruleset where you insert the anti-attacker rules when needed. This is all possible with -current. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 11:12:35PM +0100, Daniel Hartmeier wrote: > See the updated patch in the -current ports tree, it's fixed. Thanks :) > There's no reason to gamble with sanity by trying to backport features, > people running 3.0, 3.1 and 3.2 -release or -stable are supposed to use > the appropriate ports tree. If it worked when 3.1 was shipped, it can > still be built using that ports tree. I wouldn't go insane over trying > to backport all changes and supply one version that compiles with all > old releases. If people can't be bothered with upgrading, why would you > bother delivering them the latest features to compile on their old > systems? :) You are right, too many things have changed between 3.2 and -current. I will probably stop supporting pre 3.3 in later releases of pftop. Can
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 07:17:05PM -0700, [EMAIL PROTECTED] wrote: > Basically, find the spot in the ruleset where you want to insert > your rules, and drop an "anchor attacks" in there. > > Then, for an attack in progress, do a: > > echo 'block in quck from $attacker to any' | pfctl -a attacks -R -f - is the '-R' flag required for this? wouldn't it just make pf reload the whole bunch of rules instead of just adding a rule to the anchor rule subset? -- Saad Kadhi -- [[EMAIL PROTECTED]] [[EMAIL PROTECTED]] [pgp keyid: 35592A6D http://pgp.mit.edu] [pgp fingerprint: BF7D D73E 1FCF 4B4F AF63 65EB 34F1 DBBF 3559 2A6D] ---
Re: RFC: libpf, simplifying pf(4) access to userland apps
> ...Guess i should take a look at the authpf and pfctl code Or just look at anchors in the -current code. Basically, find the spot in the ruleset where you want to insert your rules, and drop an "anchor attacks" in there. Then, for an attack in progress, do a: echo 'block in quck from $attacker to any' | pfctl -a attacks -R -f - Alternately, you can now use tables for that purpose. In fact, that may be even more useful, as you can add/remove hosts from the table on the fly, without disturbing the existing entries. What is being said here is: you don't need a utility. you will be able to do it from the command line. (effectively, pfctl *IS* the API) -kj
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 08:21:29PM -0500, Marina Brown wrote: > I run an ISP that is almost totally OpenBSD. While i understand the > need for pfctl to be lightweight, it would be VERY nice to have a > utility to add or delete a temporary rule when an attack is on. Check out the 'anchor' feature in -current. An anchor is just a placeholder you can put in your main ruleset like this: block in all anchor temporary pass in from ... At any time, and without reloading the main ruleset, you can load sub-rulesets into the anchor, like echo "block in quick from 1.2.3.4 to any" | \ pfctl -a temporary:badguy -f - Evaluation of the main ruleset will branch into all sub-rulesets of the specified anchor. In this example, the anchor name is 'temporary', and I added one ruleset called 'badguy' to it. You can add any number of rulesets to an anchor, and use any number of anchors anywhere in the main ruleset. Useful if you want to manage sub-rulesets from scripts or cronjobs, etc. Daniel
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, 09 Jan 2003, Srebrenko Sehic wrote: > > 4) I've never used authpf, but I wonder why authpf does not > > call the pfctl binary, to have the benefit of code reuse without > > that tricky sharing of files. Combining binaries is usually the > > Unix way, I believe. > > pfctl does not support inserting rules on the fly and authpf needs that. > On the other hand, the overhead of having that would be too big. > I run an ISP that is almost totally OpenBSD. While i understand the need for pfctl to be lightweight, it would be VERY nice to have a utility to add or delete a temporary rule when an attack is on. ...Guess i should take a look at the authpf and pfctl code Marina Brown > // haver -- == "Speculators may do no harm as bubbles on a steady stream of enterprise. But the position is serious when the enterprise becomes the bubble on a whirlpool of speculation. When the capital development of a country becomes a by-product of the activities of a casino, the job is likely to be ill-done". John Maynard Keynes. "The General Theory of Employment, Interest and Money". 1936 ===
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 09:27:01PM +0100, Srebrenko Sehic wrote: > On Thu, Jan 09, 2003 at 07:50:09PM +0100, Henning Brauer wrote: > > > > pfctl does not support inserting rules on the fly and authpf needs that. > > > On the other hand, the overhead of having that would be too big. > > > > h, things changed... authpf uses anchors now, that IS possible with > > pfctl... hmmm. > > Didn't know that. So, authpf can insert rules on fly using anchors, but is > this possible with arbitrary applications? Say I want my snort box to insert > filter rules into pf, by sending a messages (something like > 'block 192.168.0.1') to a daemon running on my pf fw and have the daemon > translate that into a rules which can be added to the filter/anchor. > > I guess the answer is yes. Write an authpf-like daemon (with a remote > interface) and let is do the job. Oh, this brings us back to the > original issue. It would be hell to maintain. what? no, easier, you just call pfctl and let it load the set of custom rules to the anchor defined in your main pf.conf... -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 09:22:47PM +0200, Can Erkin Acar wrote: > Right now things are changing too fast. I had to stop working on pftop > or risk losing my sanity ;) (Ouch! it is broken again, I will make a new > release in a week). I think we need a 'pf version' incremented with > api/structure changes. That would really make maintaining portable code > MUCH easier. See the updated patch in the -current ports tree, it's fixed. There's no reason to gamble with sanity by trying to backport features, people running 3.0, 3.1 and 3.2 -release or -stable are supposed to use the appropriate ports tree. If it worked when 3.1 was shipped, it can still be built using that ports tree. I wouldn't go insane over trying to backport all changes and supply one version that compiles with all old releases. If people can't be bothered with upgrading, why would you bother delivering them the latest features to compile on their old systems? :) Daniel
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 11:13:41PM +0100, Henning Brauer wrote: > > Didn't know that. So, authpf can insert rules on fly using anchors, but is > > this possible with arbitrary applications? Say I want my snort box to insert > > filter rules into pf, by sending a messages (something like > > 'block 192.168.0.1') to a daemon running on my pf fw and have the daemon > > translate that into a rules which can be added to the filter/anchor. > > > > I guess the answer is yes. Write an authpf-like daemon (with a remote > > interface) and let is do the job. Oh, this brings us back to the > > original issue. It would be hell to maintain. > > what? no, easier, you just call pfctl and let it load the set of custom > rules to the anchor defined in your main pf.conf... Perhaps. But it would be better to talk to the kernel directly, thru an API, instead of forking pfctl every time I need a rule added/removed from an anchor/table. Does authpf call pfctl? AFAIK, no. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 09:43:34PM +0100, Daniel Hartmeier wrote:
> As for a library, that would only make sense if it were an additional
> abstraction layer somewhere between pf(4) ioctls and pfctl command line.
> Whether you find a level that changes less often than pf(4) but is more
> generic than pfctl decides how useful it would be. If it changes with
> each pf(4) change, it will just be another piece in the puzzle to update
> everytime, increasing the amount of work caused by changes.
Good abstraction layer is possible. I don't really see why a library
'hiding' the behind the scene changes happening to pf could cause more
grief. In fact, even the in tree things (authpf, pfsync, whatever) might
benefit from that. Imagine,
#include
int ret = insert_pf_rule("block in from 192.168.0.1 to any");
Perhaps I'm asking for too much, but that would be nice.
> I don't suggest that userland tools like libdnet, pftop, symon, etc.
> should immediately adjust to all -current changes in pf. It's probably
> enough if they just provide one working source for each OpenBSD
> -release/-stable.
Perhaps. But if you have a single box and want to follow -current, but
you also want to maintain a piece of software, that becomes rather
difficult ;)
> If you want an update to -current, mail me, I'll happily adjust your
> source to -current. It causes me less work to adjust a handful of userland
> tools than maintaining a library. :)
Heh. Thanks for the offer, but I can do that myself. As Car mentioned
before, you might go mad after a couple of -current synchs. It might be a
handful of tools now, but with a decent library API, there might be many more.
But ok, I'll shut up now.
// haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 10:00:55PM +0100, Srebrenko Sehic wrote: > Nic. Btw, what's the main difference between tables and > anchors? An anchor is a bunch of rules, while a table is a bunch of addresses (or netmasks). If you have a block of rules in your main ruleset like pass out from 10.1.2.3 to any pass out from 10.1.2.4 to any pass out from 10.1.2.5 to any which only differ in their addresses, you could use a table pass out from to any and load the addresses into the table. This would reduce the number of rules and make evaluation much faster. If you have a block of rules which differ more, like block out pass out inet proto tcp from 10.1.2.3 to any port www flags S/SA keep state pass in inet proto tcp from any to 10.2.3.4 flags S/SA keep state pass in inet proto udp from any to 10.2.3.4 port domain you could load them into an anchor (it's a sub-ruleset of the main ruleset). You can branch into the anchor from the main ruleset conditionally: anchor bar on $ext_if which would reduce the number of evaluations, too. And of course you can mix both concepts, use tables in rules inside anchors, etc. :) Daniel
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 09:52:56PM +0100, Cedric Berger wrote: > There is a "table" feature that has just been commited to the kernel. > You can write in pf.conf: > > table persist > block in from to any > > And then, your snort box can do the following: > ssh firewall pfctl -t snortblacklist -Ta 192.168.0.1 Nic. Btw, what's the main difference between tables and anchors? // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
Srebrenko Sehic wrote: On Thu, Jan 09, 2003 at 07:50:09PM +0100, Henning Brauer wrote: pfctl does not support inserting rules on the fly and authpf needs that. On the other hand, the overhead of having that would be too big. h, things changed... authpf uses anchors now, that IS possible with pfctl... hmmm. Didn't know that. So, authpf can insert rules on fly using anchors, but is this possible with arbitrary applications? Say I want my snort box to insert filter rules into pf, by sending a messages (something like 'block 192.168.0.1') There is a "table" feature that has just been commited to the kernel. You can write in pf.conf: table persist block in from to any And then, your snort box can do the following: ssh firewall pfctl -t snortblacklist -Ta 192.168.0.1 Cedric
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 09:27:01PM +0100, Srebrenko Sehic wrote: > Didn't know that. So, authpf can insert rules on fly using anchors, but is > this possible with arbitrary applications? Say I want my snort box to insert > filter rules into pf, by sending a messages (something like > 'block 192.168.0.1') to a daemon running on my pf fw and have the daemon > translate that into a rules which can be added to the filter/anchor. You could just pipe the rules into pfctl -a foo:bar -f -, which then parses them and loads them into the kernel, yes. The command line interface of pfctl doesn't change much (at least not existing switches), so that would cause less adjustments when the ioctl interface to pf changes. As for a library, that would only make sense if it were an additional abstraction layer somewhere between pf(4) ioctls and pfctl command line. Whether you find a level that changes less often than pf(4) but is more generic than pfctl decides how useful it would be. If it changes with each pf(4) change, it will just be another piece in the puzzle to update everytime, increasing the amount of work caused by changes. I don't suggest that userland tools like libdnet, pftop, symon, etc. should immediately adjust to all -current changes in pf. It's probably enough if they just provide one working source for each OpenBSD -release/-stable. If you want an update to -current, mail me, I'll happily adjust your source to -current. It causes me less work to adjust a handful of userland tools than maintaining a library. :) Daniel
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 07:50:09PM +0100, Henning Brauer wrote: > > pfctl does not support inserting rules on the fly and authpf needs that. > > On the other hand, the overhead of having that would be too big. > > h, things changed... authpf uses anchors now, that IS possible with > pfctl... hmmm. Didn't know that. So, authpf can insert rules on fly using anchors, but is this possible with arbitrary applications? Say I want my snort box to insert filter rules into pf, by sending a messages (something like 'block 192.168.0.1') to a daemon running on my pf fw and have the daemon translate that into a rules which can be added to the filter/anchor. I guess the answer is yes. Write an authpf-like daemon (with a remote interface) and let is do the job. Oh, this brings us back to the original issue. It would be hell to maintain. No? Is there a better/nicer way? // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 06:52:40PM +0100, Srebrenko Sehic wrote: > On Thu, Jan 09, 2003 at 06:34:13PM +0100, Daniel Hartmeier wrote: > > > > But it would be worth carefully looking at the currently shared modules, > > and sorting all functions and shared globals to into either shared or > > private modules. Whether you put the shared code into a library or just > > link an object file from pfctl is then just a detail. :) > > If we leave out all the technical challenges involved, the real question > is if the pf developers find this idea useful at all? The only way libpf > whould ever be a hit is if it was developed/maintained in the official tree. > Otherwise, libpf maintainer would need to do spend a lot of time > figuring out the changes happening to pf, pfctl, authpf, etc. > > How often do pf(4) structures changes? 5 times a week? IMHO, it would be > a mission impossible to maintain it externally. Right now things are changing too fast. I had to stop working on pftop or risk losing my sanity ;) (Ouch! it is broken again, I will make a new release in a week). I think we need a 'pf version' incremented with api/structure changes. That would really make maintaining portable code MUCH easier. In pftop I only duplicate state/rule printing functions so I have not needed a general purpose library (yet). Though I believe it would be useful if designed/implemented correctly. Can
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 07:40:52PM +0100, Srebrenko Sehic wrote: > pfctl does not support inserting rules on the fly and authpf needs that. > On the other hand, the overhead of having that would be too big. h, things changed... authpf uses anchors now, that IS possible with pfctl... hmmm. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 07:22:14PM +0100, Cedric Berger wrote: > >If we leave out all the technical challenges involved, the real question > >is if the pf developers find this idea useful at all? > > > A few points, in wrac: > > 1) I kind of like libraries, but they are difficult to get right, > and probably more difficult is to have people agree to use it. In case of pf(4), I don't see why anybody would object to using it. If it is done correctly, of course. E.g. I had to write 500+ lines of code just to get a list of currently loaded filter rules. If we had a library, I bet 20 lines would've been enough. > 2) Theo doesn't like libraries too much. Imagine what would OpenBSD look like if it didn't have any libraries ;) Again, if done properly, I doubt even Theo would have anything against it. > 3) The current way file are shared between pfctl, authpf and > tcpdump is kind of ugly IMHO. Can't really tell, but a library would've been nicer, for sure. > 4) I've never used authpf, but I wonder why authpf does not > call the pfctl binary, to have the benefit of code reuse without > that tricky sharing of files. Combining binaries is usually the > Unix way, I believe. pfctl does not support inserting rules on the fly and authpf needs that. On the other hand, the overhead of having that would be too big. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
If we leave out all the technical challenges involved, the real question is if the pf developers find this idea useful at all? A few points, in wrac: 1) I kind of like libraries, but they are difficult to get right, and probably more difficult is to have people agree to use it. 2) Theo doesn't like libraries too much. 3) The current way file are shared between pfctl, authpf and tcpdump is kind of ugly IMHO. 4) I've never used authpf, but I wonder why authpf does not call the pfctl binary, to have the benefit of code reuse without that tricky sharing of files. Combining binaries is usually the Unix way, I believe. Cedric
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 06:34:13PM +0100, Daniel Hartmeier wrote: > On Thu, Jan 09, 2003 at 06:20:55PM +0100, Srebrenko Sehic wrote: > > > What do you think about this? > > There is some sharing of pfctl code with authpf already, but it's done > by compiling and linking some source modules of pfctl from authpf. > > I guess you could try and move those shared functions into a library, > whether it's a good idea will be visible by how well authpf can use it. > > If the library API is significantly different from the API of the > currently shared source modules (share function prototypes, etc.), that > might be a problem when the pf(4) ioctl interface changes and the > library API would have to be adjusted. > > But it would be worth carefully looking at the currently shared modules, > and sorting all functions and shared globals to into either shared or > private modules. Whether you put the shared code into a library or just > link an object file from pfctl is then just a detail. :) If we leave out all the technical challenges involved, the real question is if the pf developers find this idea useful at all? The only way libpf whould ever be a hit is if it was developed/maintained in the official tree. Otherwise, libpf maintainer would need to do spend a lot of time figuring out the changes happening to pf, pfctl, authpf, etc. How often do pf(4) structures changes? 5 times a week? IMHO, it would be a mission impossible to maintain it externally. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
On Thu, Jan 09, 2003 at 06:20:55PM +0100, Srebrenko Sehic wrote: > What do you think about this? There is some sharing of pfctl code with authpf already, but it's done by compiling and linking some source modules of pfctl from authpf. I guess you could try and move those shared functions into a library, whether it's a good idea will be visible by how well authpf can use it. If the library API is significantly different from the API of the currently shared source modules (share function prototypes, etc.), that might be a problem when the pf(4) ioctl interface changes and the library API would have to be adjusted. But it would be worth carefully looking at the currently shared modules, and sorting all functions and shared globals to into either shared or private modules. Whether you put the shared code into a library or just link an object file from pfctl is then just a detail. :) Daniel
