Re: [Fwknop-discuss] fwknop and ipfw dynamic rules

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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