Re: a cutting-edge open-source network security project

[Darren Reed <darren.reed () oracle com>]

Ok, since you've asked...


Lets look at the list of reasons why to use it:

   * Have you ever wanted to troubleshoot some networking problems,
     only to realize that your own firewall prevents your test packets
     from getting through?


I don't need DFD for this and if I'm using un*x software as my firewall, 
I probably need to be looking at a whole lot of things to understand 
what's going wrong (or right.)

   * Have you ever wanted to block attackers from communicating with
     you at all?


Any good IPS software should do this..

   * Have you ever wanted to implement port-knocking
     (http://www.port-knocking.org/)?


I think port-knocking, as a security mechanism, has already been debunked.

   * Have you ever wanted to run peer-to-peer programs from behind NAT?
     What if you decide to switch internal computers? Wouldn't you want
     a tool that could detect use on the other computer and redo your
     port forwarding automagically, and close (de-forward) the port
     when it was no longer being used?


Running peer-to-peer from behind a NAT usually requires something that 
does UPnP. There are tools out there (like miniupnpd) that already do 
this. Using DFD for this is a not likely to go anywhere because support 
for it isn't already built into bit-torrent tools (unlike UPnP.)

   * Have you ever just wanted to make a temporary rule that expires
     after a certain amount of time?


If there is really a desire to do this, then it should be natively 
supported by the firewall software. (I've recently added this to ipfilter.)

   * Have you wanted to make a simple change to the firewall rules and
     easily revert it, without logging in an editing a file?


I think every un*x firewall allows you to do this. If the current 
thought is that it is "too hard" to do right, then I'd like to know how 
DFD thinks it can make it easier. For example, if you want to insert a 
rule at a specific point, you somehow need to convey that regardless of 
whether or not DFD is used. For very simple rule sets, making a change 
is simple. But as firewall rules grow, making a simple change becomes 
more fraught.

   * Have you ever wanted to have a queue of the last N blocked hosts,
     so that you don't end up with a ton of outdated perjorative rules?


Again, that sounds like something that should be supported natively by 
the firewall. (I've added it as something to add to ipfilter in the future.)

   * Have you ever wanted to do all this with open-source software alone?


We do already most of this today, so yes...

   * Have you ever wanted to do all of these at one time without the
     different systems stepping on each other's changes?


That's the only real bit of value here. But use of rsync over ssh can be 
just as effective.

When I first read about DFD, I thought there was something to be excited 
about.. but the more I think about it, the more I realise not really. Or 
perhaps a better thing to say is, not along the lines that are being 
considered here.

For example, above it says "have you ever wanted to have a queue of the 
last N blocked hosts" but it seems to provide nothing to support adding 
a host to that queue. For some reason, the thought is that 
adding/removing rules is the thing to do. au contraire. The rules define 
my security policy, what changes is the set of IP#'s that I want to 
apply segments of my security policy to.

Darren


On 19/05/10 10:00 AM, Thomas Ptacek wrote:
> You're right, but that's kind of a straightforwardly-solved problem, isn't it? Just park it behind SSH.
>
> The heresies involved in Travis' project are much more violent than the command/control channel. Interested in your 
> real thoughts.
>
> On May 18, 2010, at 7:49 PM, Darren Reed wrote:
>
> > On  2/05/10 03:48 PM, travis+ml-firewalls () subspacefield org wrote:
> > > Quoting:
> > > http://www.subspacefield.org/security/dfd/
> > ...
> >
> > How do you authenticate connections to the dfd daemon?
> >
> > If all I need is netcat (as per the example in your web
> > page above), then that doesn't speak too highly of the
> > security of the daemon itself.
> >
> > Are you effectively giving all users that can connect
> > to it root level privilege on the firewall?
> >
> > Darren
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () listserv icsalabs com
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>
> ---
> Thomas Ptacek // matasano security // founder, product manager
> read us on the web: http://chargen.matasano.com
> check out playbook: http://runplaybook.com
> reach me direct: 888-677-0666 x7805
>
> "The truth will set you free. But not until it is finished with you."
>
>
>
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards