Patching Firewalls
I'm curious, How does everyone maintain their firewalls when patching them? Do you use cvs or a manual patch? Or do you compile things on a separate system and do binary patch on the firewall? It would seem that CVS (tracking -stable) is the best way. The problem with this though is you have to put the compiler on the firewall. Ideally you want your firewall stripped down. But since you need to compile patches, it seems hard to avoid. Comments? Apologies as I realize this is not technically a pf question, but I am interested in the case of a firewall, not a general purpose machine. Jim
Re: Patching Firewalls
On Thu, Jan 09, 2003 at 09:42:35AM -0500, Small, Jim wrote: How does everyone maintain their firewalls when patching them? Do you use cvs or a manual patch? Or do you compile things on a separate system and do binary patch on the firewall? It would seem that CVS (tracking -stable) is the best way. The problem with this though is you have to put the compiler on the firewall. Ideally you want your firewall stripped down. But since you need to compile patches, it seems hard to avoid. I usually have a separate system that tracks -stable and when there is a patch that will affect the firewall, I create a release[1] and simply untar the files on the firewall[2] using the proper arguments. Of course, I take extra care when dealing with etc32.tgz. If there any changes to /etc, I do them by hand if there are a few of them. Otherwise, I just backup my few local etc files (pf.conf, rc.conf, rc.local, master.passwd, ...etc), untar the new etc32.tgz and restore back my local files. After rebooting, the firewall will have the necessary patches installed. hth. -- [1] man release(8) [2] either via a NFS mount or by burning a cd-rw that I will use on other, offsite systems. Of course, you can also scp/sftp them over etc. -- 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] ---
RFC: libpf, simplifying pf(4) access to userland apps
I've sent this some time ago to misc@, but didn't get much response. I thought I might try the pf specific list. While working on my own tool, rpfcd (remote pf control dameon, http://www.insecure.dk/rpfcd/) I found myself reusing a lot of code from pfctl for pf(4) related routines. While some of stuff is rather straighforward, some other (like printing filter rules, i.e. pfctl -sr) is quite hard. A library implementing these commonly used routines, integrated/developed in the official tree, would help a lot. Userland tools would have a common framework for manipulating pf(4). Eg. pfctl would be much smaller, including other tools like newly introduced pftop and my own utility rpfcd. And yes, I'm aware of libdnet. However, this is not pf specific and is lacking a lot of features and is broken most of the time, since a lot changes are happening to pf(4) code. What do you think about this? // haver
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
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 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
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 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 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
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 snortblacklist persist block in from snortblacklist 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: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 snortblacklist persist block in from snortblacklist 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
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 foo 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: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 libpf.h 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 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: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, 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 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
...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 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] ---
