Checkpoint IPS

Thu Feb 5 18:26:18 UTC 2015

You make so many assumptions, it completely negates any reasonable point you are trying to make:

> There are other ways (reverse proxies, on-box systems like ModSecurity, 
> et. al.); or take them offline.

What if the box isn't Linux? What if it isn't a web server. What if proxies don't work well with the protocol the boxes uses. What if it's an appliance a business unit made you setup. There a thousands of permutations like that. Many times you don't get to make the correct choices, you have to work with what you have. Any IPS, statefull firewall, application level gateways, proxies, etc. have their places.

In a content provider network (facebook, etc...) only using stateless protection because of massive DDOS is a reasonable argument. But like I said, one size doesn't fit all, or in this case, many.

Like it's been said before, I strongly support my competitors following your advice.

----
Matthew Huff             | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff        | Fax:   914-694-5669

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins
Sent: Thursday, February 5, 2015 1:11 PM
To: nanog at nanog.org
Subject: Re: Checkpoint IPS

On 6 Feb 2015, at 0:55, Matthew Huff wrote:

> What if you are a hosting company and those aren't your servers to 
> patch?

Then it isn't the operator's problem.

> What about the time to patch 200+ servers versus configuring one 
> location?

Operators should have sufficient automation to do this quickly.  If not, 
they're Doing It Wrong.

> What if you have to schedule the staff and maintenance window to patch 
> the servers?

See above.

> What if you have legacy equipment that you must continue using, but 
> the vendor is slow to provide the patch.

There are other ways (reverse proxies, on-box systems like ModSecurity, 
et. al.); or take them offline.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>