Re: [Fwknop-discuss] fwknop and ipfw dynamic rules
Brought to you by:
mbr
From: Michael R. <mb...@ci...> - 2009-02-05 04:16:08
|
On Feb 01, 2009, Julien Picalausa wrote: > Hello, Mike > > ----- Original Message ----- > From: "Michael Rash" <mb...@ci...> > To: <fwk...@li...> > Sent: Sunday, February 01, 2009 4:05 AM > Subject: Re: [Fwknop-discuss] fwknop and ipfw dynamic rules > > > > On Jan 30, 2009, Sean Greven wrote: > > > >> Heya Julien > >> > >> On Fri, Jan 30, 2009 at 1:07 PM, Julien Picalausa > >> <jul...@ya...> wrote: > >> > Hi again, Sean > >> > > >> > ----- Original Message ----- > >> > From: "Sean Greven" <sea...@gm...> > >> > To: "Julien Picalausa" <jul...@ya...> > >> > Cc: <fwk...@li...> > >> > Sent: Friday, January 30, 2009 4:55 AM > >> > Subject: Re: [Fwknop-discuss] fwknop and ipfw dynamic rules > >> > > >> > > >> >> Hi Julien > >> >> > >> >> On Thu, Jan 29, 2009 at 9:40 PM, Julien Picalausa > >> >> <jul...@ya...> wrote: > >> >>> ----- Original Message ----- > >> >>> From: "Sean Greven" <sea...@gm...> > >> >>> To: "Julien Picalausa" <jul...@ya...> > >> >>> Cc: <fwk...@li...> > >> >>> Sent: Thursday, January 29, 2009 7:06 PM > >> >>> Subject: Re: [Fwknop-discuss] fwknop and ipfw dynamic rules > >> >>> > >> >>> > >> >>>> Hi there Julien > >> >>> > >> >>> Hello, > >> >>>> > >> >>>> The trick is to add a rull permitting established connections to > >> >>>> port > >> >>>> 22. > >> >>>> > >> >>>> assuming you have rule 1 as the rule fwknop adds as the dynamic > >> >>>> rule, > >> >>>> you would need something like > >> >>>> > >> >>>> ipfw add 100 deny tcp from any to any eq 22 setup > >> >>>> ipfw add 200 permit tcp from any to any 22 esablished > >> >>>> ipfw add 65535 deny ip from any to any > >> >>>> > >> >>> Yes, this would make it work. Thanks for your help :) > >> >>> > >> >>> I would like however to voice one concern regarding that setup: It > >> >>> goes > >> >>> against the recommandation written in the ipfw manpage: > >> >>> "In order to protect a site from flood attacks involving fake TCP > >> >>> packets, > >> >>> it is safer to use dynamic rules: > >> >>> > >> >>> ipfw add check-state > >> >>> ipfw add deny tcp from any to any established > >> >>> ipfw add allow tcp from my-net to any setup keep-state" > >> >>> > >> >> > >> >> There are a number of factors which affect this, and it very much > >> >> depends on where and for what reson you have deployed fwknop, and your > >> >> gateway. Having used FreeBSD from version 1.7, I was very excited > >> >> when ipfw started using statefull rules, however in a very large > >> >> environment I have found that in practice that the second piece of the > >> >> man page section becomes a real reality often quite quickly: > >> >> BEWARE: stateful rules can be subject to denial-of-service attacks > >> >> by > >> >> a > >> >> SYN-flood which opens a huge number of dynamic rules. The effects > >> >> of > >> >> such attacks can be partially limited by acting on a set of > >> >> sysctl(8) > >> >> variables which control the operation of the firewall > >> >> > >> > > >> > Right, I had never actually made the link between those two warnings. I > >> > can > >> > imagine how you'd prefer to deal with spoofed established connections > >> > than > >> > to deal with the firewall not letting anyone in after a SYN-flood. I'll > >> > keep > >> > that in mind for the future :) > >> > > >> >>> I have been following that recommandation until now and I find it > >> >>> sensible. > >> >>> (besides, I guess that if there is any vulnerability that can be > >> >>> triggered > >> >>> by spoofed established connections, it would make fwknop useles > >> >>> against > >> >>> those, but I am no security expert so I don't know if it's such a big > >> >>> concern.). Additionally, that strategy cannot work for UDP. > >> >>> > >> >>> > >> >>> Maybe a better way to fix it would be to change fwknop so that it > >> >>> uses a > >> >>> set > >> >>> to store rules that have expired but for which dynamic rules still > >> >>> exist. > >> >>> > >> >> I thought about this for a while, and even mentioned it to Mike at one > >> >> stage, however I never quite got round to it. I have never used the > >> >> sets before, and have never found the time to experiment properly with > >> >> it. The trick obviously being that the set must be disabled, not > >> >> deleted, otherwise the associated dynamic rules will be deleted as > >> >> well. > >> >> > >> >>> The manpage of ipfw states: > >> >>> " When you disable a set, its rules behave as if they do not exist in > >> >>> the > >> >>> firewall configuration, with only one exception: > >> >>> > >> >>> dynamic rules created from a rule before it had been disabled > >> >>> will > >> >>> still be active until they expire. In order to delete dynamic > >> >>> rules you have to explicitly delete the parent rule which > >> >>> generated > >> >>> them." > >> >>> > >> >>> Moving expired rules to a disabled set makes them effectively removed > >> >>> from > >> >>> the ipfw rule stack but the dynamic rules associated to them stay > >> >>> active. > >> >>> (tested) > >> >>> Then, at a regular interval, fwknop should check for rules existing > >> >>> in > >> >>> the > >> >>> disabled set with `ipfw -S set {n} list` and check if any dynamic > >> >>> rule > >> >>> has > >> >>> the same number, then delete them if there is no matching dynamic > >> >>> rule. > >> >>> > >> >>> If this seems like a good idea, I can try to put my knowledge of Perl > >> >>> to > >> >>> some use and offer a patch. > >> >>> > >> >> I personally think this is a great idea, and welcome such a patch. > >> >> > >> > > >> > I've had a look through the code. I noticed that the current version of > >> > the > >> > port on FreeBSD is actually a bit old, for some reason, so I got latest > >> > source package from the site. It seems like it will be a relatively > >> > easy > >> > fix. I'll work on it when I've figured out how to install that package > >> > manually (so I can test). If it goes as planned, I might have something > >> > after the weekend. > >> > > >> > >> *blush* yes I know the port is old. There is of course a reason for > >> it, I actually can't keep up, Mike had released two versions before I > >> got the PR through the port maintainers submission process, I am > >> afraid that the process to get ports submitted is taking longer and > >> longer these days. </end rant mode> > >> > >> Make made some changes to the package, so that the paths can be > >> modified via a command line switch, makes the port much easier to > >> install (you'll notice that the patches are mainly for path names). > >> > >> I'll be more than willing to test out your patches, once you complete > >> this, I think this will be a very nice addition, I am sure Mike will > >> commit it for the next version, but of course that is up to him. > > > > Yes indeed I would definitely include these patches once they are ready, > > and please let me know if there is anything > > I have sent a first (not tested yet) version of the patch to Sean, off-list. > I can send it to you as well if you wish. I'll try to test it myself today. Sure, I would be happy to take a look as well, but I probably won't be able to provide feedback until next week. Btw, if anyone is attending Shmoocon this weekend, perhaps we could meet up: http://www.shmoocon.org/ > > I can do to help. Perhaps a > > new config variable that would tell fwknopd to use ipfw sets instead of > > the current strategy (just so that the user has the option of using the > > stateful strategy that you described earlier Sean)? Or would it always > > be better to use ipfw sets? > > I have made it so that fwknop determines whether it should use sets or not. > Basically, if there are dynamic rules found, using sets is always better. If > the stateful strategy described by Sean is found or if no stateful rule is > found at all, it will not use sets, because then it would not work anyway > (no keep-state rule remaining active if all of them are disabled, so dynamic > rules would be ignored anyway) Ok, that sounds like a good strategy. > > If a system is running ipfw, is it > > necessarily the case the sets are offered, or can they be configured by > > changing how the kernel is compiled (similarly to iptables)? > > > Sets are always present with ipfw, AFAIK Understood. > > At some point, it might be interesting to write a perl module for > > controlling ipfw policies - it could similar to the IPTables::ChainMgr > > module that fwknop uses. Incidentally, the latest release of > > PacketFence is using IPTables::ChainMgr now: > > > > http://www.packetfence.org/en/home.html > > > > Actually, I noticed that you have external commands in the latest version. > So, it would always a good idea to split the code needed for controlling > ipfw (and iptables) to be predefined external scripts that can be a possible > choice of external commands rather than being built-in. You might need to > extend the external command interface a bit to allow some initialization > phase to take place and maybe other things, but in general it should make it > easier to make changes related to one particular firewall and make it easier > to add support for other firewalls. > When you have that separation made, splitting further and make a library to > control ipfw should be easy. I do agree that building in more separation in fwknopd for firewall control would be a good thing, but the external commands API would need to be substantially enhanced to accomplish this (as you suggest). Everything that is in the current iptables implementation would need to be expressed via the API - see the IPT_*_ACCESS variables in fwknop.conf. At some level, there should be a set of code that implements encryption/decryption of SPA data, with separation layers for packet sniffing and doing things like manipulating firewall rules after valid SPA data is received. Significant work has started in this direction, and I will have more information soon about this. However, it's not clear to me that "external script" is necessarily the right abstraction. That is, should fork() and exec() be used instead of communicating with an external program via a domain socket? How about linking against a library like libdnet? Also, _some_ abstraction is achieved via the grant_access() function already in fwknopd. So, what is the best abstraction? Please note that I'm playing Devil's Advocate a bit here because I'm interested in what your thoughts are on this. > After that, it could also be a good idea to add to the access file the > ability to add some keyword(s) to be passed to the command in addition of > the other information. This would allow, in the case of ipfw to specify an > action other than 'allow' (like 'divert' or 'forward'), for exemple. Then > you could have something like this: > OPEN_PORTS: tcp/22/allow, tcp/1356/divert 4569 > or something like this: > SOURCE:... > OPEN_PORTS:... > ACTION: allow > depending on what you prefer. > > Anyway, just some ideas :) I suppose one of the main benefits for an external program handling the firewall access is that it is more easy to implement a more sophisticated interface to the firewall without having to necessarily alter fwknopd itself. But, then I think there is a question about whether fwknopd needs to be able to express this to the external program via some API too. Either way, the ipfw support in fwknopd itself needs to be improved to support what you have above (which would be cool). Thanks, --Mike > > > > Thanks, > > > > --Mike > > > Thank you for making this software in the first place :) > > Julien Picalausa > > > > > >> Regards Sean > >> > >> > >> > >> > Regards, > >> > Julien Picalausa |