Thread: [Fwknop-discuss] fwknop and ipfw dynamic rules
Brought to you by:
mbr
From: Julien P. <jul...@ya...> - 2009-01-29 09:23:50
|
Greetings, I understood that this is the mailing list for asking questions/discussing issues about fwknop. Let me know if my message belongs somewhere else :) I am currently in the process of setting up fwknop on my FreeBSD (7.0) server in order to protect myself better against potential attacks on SSH. I have come to the point where everything is working fine, at one exception. As soon as fwknop removes the firewall rule added to allow the connection to be made, the connection itself is dropped. >From the documentation and my research, I understood that this works about like this: 1. fwknop receives a valid authentication packet and adds to ipfw: allow {selected protocol} from {source IP} to any {selected destination port} keep-state This step works fine for me, my ipfw configuration already uses check-state so all is well. 2. I open a connection from the source IP to the newly opened port. The firewall creates a dynamic rule, associated with the rule added by fwknop, in response. 3. When the configured time has elapsed, fwknop removes the rule it added to ipfw. In turn, ipfw removes all dynamic rules associated with the removed rules There is no more rule allowing the packets of the established connection to go through, it ends up being dropped Since the blogpost of 28th June 2008 on cipherdyne website claims that "By using a connection tracking mechanism built into iptables or ipfw, any connection established during the accept window is allowed to remain open but all attempts to create a new connection must first preceeded with a new SPA packet in order to gain access.", I assume I have either misconfigured something or this was not the expected behaviour from the dynamic firewall rules. The manpage of ipfw hints to the fact that, the deletion of dynamic rules when their parent rule is deleted is systematic - they need to have a parent rule to know what action to apply to the packets they match. Looking around the web didn't seem to give me any exemple of someone having a working ipfw+fwknop configuration, so I decided to ask directly. If this problem is just due to an oversight on my part, pointing me to whatever documentation can help me is fine. :) Best regards, Julien Picalausa |
From: Sean G. <sea...@gm...> - 2009-01-29 18:06:30
|
Hi there Julien 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 The reason for this is that, (exactly as you described), ipfw will destroy all dynamic rules, as soon as the keep-state rule is deleted. What I have described will trigger on rule 1, and after the session is established, and the rule is removed, the packet will continue to trigger on the established rule. Hope this helps Regards Sean On Thu, Jan 29, 2009 at 10:50 AM, Julien Picalausa <jul...@ya...> wrote: > Greetings, > > I understood that this is the mailing list for asking questions/discussing > issues about fwknop. Let me know if my message belongs somewhere else :) > > I am currently in the process of setting up fwknop on my FreeBSD (7.0) > server in order to protect myself better against potential attacks on SSH. > I have come to the point where everything is working fine, at one exception. > As soon as fwknop removes the firewall rule added to allow the connection to > be made, the connection itself is dropped. > > >From the documentation and my research, I understood that this works about > like this: > > 1. fwknop receives a valid authentication packet and adds to ipfw: > allow {selected protocol} from {source IP} to any {selected > destination port} keep-state > This step works fine for me, my ipfw configuration already uses > check-state so all is well. > > 2. I open a connection from the source IP to the newly opened port. The > firewall creates a dynamic rule, associated with the rule added by fwknop, > in response. > 3. When the configured time has elapsed, fwknop removes the rule it added to > ipfw. > In turn, ipfw removes all dynamic rules associated with the removed > rules > There is no more rule allowing the packets of the established connection > to go through, it ends up being dropped > > Since the blogpost of 28th June 2008 on cipherdyne website claims that "By > using a connection tracking mechanism built into iptables or ipfw, any > connection established during the accept window is allowed to remain open > but all attempts to create a new connection must first preceeded with a new > SPA packet in order to gain access.", I assume I have either misconfigured > something or this was not the expected behaviour from the dynamic firewall > rules. The manpage of ipfw hints to the fact that, the deletion of dynamic > rules when their parent rule is deleted is systematic - they need to have a > parent rule to know what action to apply to the packets they match. > Looking around the web didn't seem to give me any exemple of someone having > a working ipfw+fwknop configuration, so I decided to ask directly. If this > problem is just due to an oversight on my part, pointing me to whatever > documentation can help me is fine. :) > > Best regards, > Julien Picalausa > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss > |
From: Julien P. <jul...@ya...> - 2009-01-29 20:14:50
|
----- 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" 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. 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. Let me know :) Julien Picalausa > > The reason for this is that, (exactly as you described), ipfw will > destroy all dynamic rules, as soon as the keep-state rule is deleted. > What I have described will trigger on rule 1, and after the session is > established, and the rule is removed, the packet will continue to > trigger on the established rule. > > Hope this helps > > Regards Sean > > On Thu, Jan 29, 2009 at 10:50 AM, Julien Picalausa > <jul...@ya...> wrote: >> Greetings, >> >> I understood that this is the mailing list for asking >> questions/discussing >> issues about fwknop. Let me know if my message belongs somewhere else :) >> >> I am currently in the process of setting up fwknop on my FreeBSD (7.0) >> server in order to protect myself better against potential attacks on >> SSH. >> I have come to the point where everything is working fine, at one >> exception. >> As soon as fwknop removes the firewall rule added to allow the connection >> to >> be made, the connection itself is dropped. >> >> >From the documentation and my research, I understood that this works >> >about >> like this: >> >> 1. fwknop receives a valid authentication packet and adds to ipfw: >> allow {selected protocol} from {source IP} to any {selected >> destination port} keep-state >> This step works fine for me, my ipfw configuration already uses >> check-state so all is well. >> >> 2. I open a connection from the source IP to the newly opened port. The >> firewall creates a dynamic rule, associated with the rule added by >> fwknop, >> in response. >> 3. When the configured time has elapsed, fwknop removes the rule it added >> to >> ipfw. >> In turn, ipfw removes all dynamic rules associated with the removed >> rules >> There is no more rule allowing the packets of the established >> connection >> to go through, it ends up being dropped >> >> Since the blogpost of 28th June 2008 on cipherdyne website claims that >> "By >> using a connection tracking mechanism built into iptables or ipfw, any >> connection established during the accept window is allowed to remain open >> but all attempts to create a new connection must first preceeded with a >> new >> SPA packet in order to gain access.", I assume I have either >> misconfigured >> something or this was not the expected behaviour from the dynamic >> firewall >> rules. The manpage of ipfw hints to the fact that, the deletion of >> dynamic >> rules when their parent rule is deleted is systematic - they need to have >> a >> parent rule to know what action to apply to the packets they match. >> Looking around the web didn't seem to give me any exemple of someone >> having >> a working ipfw+fwknop configuration, so I decided to ask directly. If >> this >> problem is just due to an oversight on my part, pointing me to whatever >> documentation can help me is fine. :) >> >> Best regards, >> Julien Picalausa >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Fwknop-discuss mailing list >> Fwk...@li... >> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss >> |
From: Sean G. <sea...@gm...> - 2009-01-30 03:55:24
|
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 > 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. > > Let me know :) > > Julien Picalausa > Regards Sean |
From: Julien P. <jul...@ya...> - 2009-01-30 11:08:35
|
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. Regards, Julien Picalausa |
From: Sean G. <sea...@gm...> - 2009-01-30 13:29:56
|
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. Regards Sean > Regards, > Julien Picalausa > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss > |
From: Michael R. <mb...@ci...> - 2009-02-01 03:05:57
|
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 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? 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)? 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 Thanks, --Mike > Regards Sean > > > > > Regards, > > Julien Picalausa > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Fwknop-discuss mailing list > > Fwk...@li... > > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |
From: Julien P. <jul...@ya...> - 2009-02-01 12:24:00
|
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. > 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) > 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 > > 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. 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 :) > > Thanks, > > --Mike > Thank you for making this software in the first place :) Julien Picalausa > > >> Regards Sean >> >> >> >> > Regards, >> > Julien Picalausa >> > >> > >> > ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by: >> > SourcForge Community >> > SourceForge wants to tell your story. >> > http://p.sf.net/sfu/sf-spreadtheword >> > _______________________________________________ >> > Fwknop-discuss mailing list >> > Fwk...@li... >> > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss >> > >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Fwknop-discuss mailing list >> Fwk...@li... >> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |
From: Julien P. <jul...@ya...> - 2009-02-07 13:15:53
|
----- Original Message ----- From: "Michael Rash" <mb...@ci...> To: <fwk...@li...> Sent: Thursday, February 05, 2009 5:16 AM Subject: Re: [Fwknop-discuss] fwknop and ipfw dynamic rules > 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/ > Looks like something interesting to attend to. Sadly, it's not exactly close enough from Europe for my budget. > >> > 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. > Well, I have to admit that quite a lot of code is related to IPTables and mingled with the SPA code here and there. Paradoxally, the IPT_*ACCESS variables didn't seem to me like a big issue since I only saw them used for some initialization routine, which would be easy to move as one into a separate script, then we would only need a call from the API to start the initialization script. I think the API should only be used for sending events to external script. If the script needs other data, it can probably obtain it from its own configuration file. The pros being that you don't need to look at configuration options for other firewalls and the cons here being obviously the multiplication of configuration files. The difficult point here is that the script for IPTable would probably need to keep its own status in some way, hopefully without making it yet another demon of its own. Now, about grant_access, it does give some abstraction as you said, but it is also used as an intermediate layer for "external programs". If instead of making internal calls for known firewalls, it would call everything as external program, both layers would be merged into one. About the communication, I do not think it is really an issue. The external script can be started by forking and then it can communicate with the actual firewall via any preferred method. This is more or less what I was thinking. Of course, you have a better overview of what's going on than I do, so I would understand if this is in contradiction with what you plan. libdnet looks like an interesting alternative and it would certainly simplify some things, but it seems like you'd still need some separate support for functionalities specific to some firewalls. > >> 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. > It probably should. > > Either way, the ipfw support in fwknopd itself needs > to be improved to support what you have above (which would be cool). > I can attempt make a patch for this too. Do you have any preference for how the setting should be expressed in access.conf? > > Thanks, > You're welcome :) Julien Picalausa > > --Mike > >> > >> > Thanks, >> > >> > --Mike >> > >> Thank you for making this software in the first place :) >> >> Julien Picalausa >> > >> > >> >> Regards Sean >> >> >> >> >> >> >> >> > Regards, >> >> > Julien Picalausa > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications > today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Fwknop-discuss mailing list > Fwk...@li... > https://lists.sourceforge.net/lists/listinfo/fwknop-discuss |
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 |