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

Let the heresy begin! ;-)

On Thu, May 20, 2010 at 04:57:04PM -0700, Darren Reed wrote:
>    * 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.)

Well, I was thinking of packet scrubbing in particular, with min-ttl
restrictions, because that can wreak havoc with traceroute.  Being
able to easily turn it off for an IP for a quick traceroute is handy.

>    * Have you ever wanted to block attackers from communicating with
>      you at all?
> Any good IPS software should do this..

Any good Boeing 747 can already get you where you need; why would
anyone be interested in a free solar-powered engine?

Also, not all adversaries are conducting network attacks; perhaps you
want to block people who are crawling your web site based on some
weblog parser's threshhold rules, or block spammers from talking to
you based on some UBE-detection software, or redirect a user with a
given User-Agent field to a special web site that tells them they've
been infected by some spyware.

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

Please first read these, so you'll understand my position, then feel free to
present your argument:
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc11.9 (para 1)
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc7.5 (para 3)
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc35.4
http://www.cipherdyne.com/fwknop/

> Running peer-to-peer from behind a NAT usually requires something that
> does UPnP.

I already posted (to the DFD list) a simple python sniffer that
detects bittorent and makes the appropriate rule changes.  It could be
done a lot better, but it's < 100 lines of python.

> 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.)

I honestly haven't looked into UPnP... I should, especially if there's
open-source software for it (as I assume miniupnpd is).  Is it defined
by an RFC?

>    * 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.)

Perhaps, but I find it easy to do with any firewall.

>    * 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.

I won't go into details here, but you end up writing a script that
defines the allowable changes to the rulesets - that is, you define
what rule changes are allowed within your security policy.

It doesn't, generally, allow arbitrary rule changes - if you have
that, you're right, you might as well log in and run firewall commands
directly, or edit firewall config files directly.

I really need to put up a better transcript; I think this would clear
up a lot of confusion for people who don't have the time to go play with
it.

If you're on an OpenBSD system, there's an example script that you can
run in test mode as non-root:

$ ./keeper_example.py --test --port 8008 &
$ nc -v -v localhost 8008
nc: connect to localhost port 8008 (tcp) failed: Connection refused # IPv6
Connection to localhost 8008 port [tcp/*] succeeded!
Your wish is my command.
dfd_keeper>

The program should be self-explanatory (start with help).  Perhaps
I'll post a transcript online.  I'd include one here, but with the 30+
line example ruleset it quickly get tedious.  Also I really need HTML
markup to emphasize what has changed, and distinguish user input,
prompts, and output.  My actual production systems tend to have
200-300 line rulesets.

This feedback certainly helps me understand where I'm doing a bad job
of explaining things.

> 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.

Yes, that is exactly the problem I attempted to address.  And if you
have several things attempting to change rules at once, things get
really hairy.

DFD provides a central choke point, where we define allowable changes
(ones that do not break our security policy), and its single-threaded,
single-process nature also provides locking so that each change is
atomic, even with multiple concurrent clients.

>    * 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.)

But DFD does it now, and the concept applies to any firewall, and it doesn't
involve lots of additional kernel level code.

>    * 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.

Hmm... how would you coordinate that among the various IDS, sniffers,
and other components?  Would they all have root level access to your
firewall, and synchronized copies of your ruleset?

> 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.

I do have set-like variables which contain IP addresses, but at
current none of them are anything but pf lists.

What is cool about them is if you remove all the IPs, the rule
automagically disappears from the ruleset.  If you add one, the rule
reappears and the set of IPs appears as an IP address, and if you add
more it uses the { IP1, IP2 } list syntax.  Over time pf has made the
syntax more flexible, so I believe you can now have singleton lists
without problem, but at the time I wrote it, that was not the case.

Also, when I started this project, I found most tools adding rules to
block individual IPs, and of course then you want to trim your
ruleset.  But at least with pf, it seems that you can add and remove
to sets quite easily, and the penalty is not nearly as severe as if
you were adding large amounts of rules.

I need to revisit the lists vs. tables issue.  Table support isn't
quite what it could be in dfd_keeper.
-- 
A Weapon of Mass Construction
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email [email protected] to get blacklisted.

_______________________________________________
firewall-wizards mailing list
[email protected]
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (OpenBSD)

iQIcBAEBAgAGBQJMbXyAAAoJEGQVZZEDJt9HW1cP/RO52Syd5NNtgvZMEJuJK/2o
ujUzqPsdICU1cZ8huqIb1xYpUazwjExEOzUyMUk6baPRVjsmZ+BOdeJq6R9HNPEh
WEk6l7cJVsYPnCRPLCVom7s1yq96EQZy2WnHVem/y7dFTRpMq6LaiyWa0PV1ksC2
R7NG8uemDrBzzeqcDPFg7fj5IOcN2U6nQb2+ug9vFyhGdBcGhUZug6jLljIVfWPf
GHPp/cLvHkTKTJut4gL0yKYsUNnzqaqYg80M8gfUxsuNOe5JdmlSrs6Zs3VhmrCN
e9bC2zCiWq9OVausBAZsMuqVIES9vrnrjAWvuJM8F91MsFqeqtloK7iwI81HW7dl
CYPtxjSjhAfGF11LriFTtM2BSqYCNJEmTI9MpjrgYkILrHW2Uj0zJ/DY2iMG0aKl
doR7vaUuBF4uPHxbc6WW3UNcCll4l9fHgulzuaOS+aDhDI+OHPmGA3qZ6XR9u3+0
EDGeLLzJh0iwVABgzLBlIasU1Tpq1JHO7RFHY3xn3zYhAO9WdZsFriMVkNWrNDHb
dRk7mvMYlQO5A0ftNVf5SJmpez48/ZDTeQNTBZKfBSf4XyYVr+mVJKYB214MjIDS
sPStv31kMmsN75gBGKzF6VYl//K6n/Xqzfrz0Q7EF7YTL8S1ACiyvp/CkgwxqzrP
WIegxvssAj7/dHzEt3Vx
=Dnzl
-----END PGP SIGNATURE-----