The other high cost of "free" that people sometimes overlook is liability. Many organizations want/need someone to hold the fire to in the event of an issue. I believe in open source and am an advocate of open source computing (this email is from my Debian (NOT UBUNTU) laptop and my BSD workstation is right beside it), but at an organizational level, if I had an open source FW and a vulnerability was allowed to get thru it and compromise customer or confidential data, my management would be looking to the vendor for answers. If I told them "it's open source, there is no "vendor"" it would not go over well. Why? Because the liability is now assumed by my company. So when the customer sues it's on me. Or (and we see these on a regular basis) when the patent troll contacts us about his patent that the open source product is violating and wants compensation the liability stops at my company. IF I am using a vendor supported platform, I can take that to my vendor and discuss options. Many (not all) large businesses have agreements with vendors that go well beyond NDAs. Agreements about liability. Healthcare/Financial/Defense all have these kinds of agreements. I'm not saying it's fair. It's just how the world works. For that reason there are some areas where open source is smart while there are other areas (a firewall you depend on to protect you) where open source may put you and your employer at risk. You have to consider that. Or... Some of us do. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 07:36 AM, Jimmy Hess wrote:
On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard<nick@foobar.org> wrote:
On 09/11/2011 19:07, C. Jon Larsen wrote: As I said, it's not a pf problem. Commercial firewalls will do all this sort of thing off the shelf. It's a pain to have to write scripts to do this manually.
Ah... the high cost of 'free' products, you have to do some scripting, or pay another organization to support it / do scripting work for you. The advantage is... you _can_ do a small amount of scripting or programming to add minor additional required functionality. And a very large number commercial firewalls do not have config synchronization, except, perhaps between a failover pair, anyways.
Anyways... I can see synchronizing blacklists on a firewall, or having a firewall configured to fetch certain 'drop' rules from a HTTPS URL. Otherwise: the thought of mass synchronization of lots of firewalls can be bad in that it creates a single point of system compromise; supposing the synchronization source machine were compromised, one dirty rule inserted by an intruder followed by a kick off of the sync mechanism, and then actions to break it/prevent further syncing, defeats the security of the entire deployment....
-- -JH