Firewalls - Ease of Use and Maintenance?
-Hammer-
bhmccie at gmail.com
Thu Nov 10 14:52:22 UTC 2011
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 at 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
>
>
More information about the NANOG
mailing list