Firewall Wizards mailing list archives
Re: a cutting-edge open-source network security project
From: travis+ml-firewalls () subspacefield org
Date: Thu, 19 Aug 2010 11:48:33 -0700
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 john () subspacefield org to get blacklisted.
Attachment:
_bin
Description:
_______________________________________________ firewall-wizards mailing list firewall-wizards () listserv icsalabs com https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: a cutting-edge open-source network security project travis+ml-firewalls (Aug 21)