Checkpoint IPS

IPSes are like any security technology, they are only as good as their implementor/administrator. I've seen some installations just set up defaults and leave them that way without any maintenance nor much oversight of alarms. I've even seen some that do 0-day implementation of new signatures, and get some legitimate or even ALL traffic blocked by a bad signature (Astaro/Sophos UTM) update back in ~2004.

On the other hand, I've seen some great implementations--some of which did a FANTASTIC job of making a network auditable, some of which made a network less liable legally and financially, and quite a few that made a network more secure.

To me, the big drawback of an IPS is, no matter how well integrated, implemented, and maintained--it's fundamental nature is flawed. Instead of default-deny with white lists, it is default-allow with black lists. It will always lag behind. It will always allow infinitely large holes. That's why I prefer an OSI complete firewall instead, or else an IPS in detect mode only, or in certain cases an IPS used in a specific case, e.g. a WAF or SAF for a server/application/zone that is specifically fuzzy or will not adhere to security principles (vendor demilitarized zones, enclaves, whatever the buzz-word is at the moment).

I understand the whole argument against state, and dismiss it. That's throwing the baby out with the bathwater. It isn't perfect, it can be overcome via DDOS and saturation, so we should get rid of it. Tanks can be destroyed by bazookas, whatever. Tanks are still useful in the battlefield if utilized properly. Firewalls and IPSes are the same way.

--p

Hello,

An IPS doesn't have to be in line.

AFAIK this is basically what defines an IPS.

It can be something watching a tap and scripted to use something else
to block traffic (e.g. hardware filtering options on a router that can
handle it).

You are naming IPS on what is actually an IDS+Active Response as I mentioned before (my #1 option of choice). Not been online won’t for instance prevent the so called single packet attacks and therefore what should be the advantage of an IPS over an IDS is just thrown away. Which, again, I accept what’s missed for what I still have. But I don’t think it can be named IPS acting passively+actively, since it’s not actually not preventing.

An IDS tied into an internal RTBH setup to leverage uRPF filtering in
hardware can be pretty effective at detecting and blocking the typical
UDP attacks out there before they reach systems that don't handle that
as gracefully (e.g. firewalls or host systems).

That’s exactly the point I agree and adopt. Maybe a first packet will pass, but it takes longer anyway to be deterministic whether the traffic is common or attack traffic. It’s an IPs there and exausting/starving won’t cause issues to the network, only to it’s own capability.

Even if you keep it
from being automated and just have it be an IDS that you can have a
human respond to is pretty valuable.

Not a coincidence that Bejtlich’s NSM101and TCP/IP Weapons School courses are usually sold out on Black Hat. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver.

Patching servers protects against >0 Day attacks only.

This does not protect against 0 day attacks, unless you know of an OS
vendor that writes good code without security holes.

What type of device needed depends on risk, what you are protecting, what
attacks are important, etc. It's not a simple matter of "firewall bad" or
"firewall good".

I won't even get into the stateless-vs-stateful debate, because it's more
complex than "stateful bad" (*cough* SIP *cough*). Nor will I mention that
it depends on what your protecting to figure out how much of each of
availability or confidentiality or integrity you need - you might need lots
of integrity but little availability, for instance.

Absolutely.

One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints.

And when your opinion is an acknowledged universal constant, I will tip my hat to you. In the meantime, your argument is extremely soundbitey--sounds great, but stupid.

--p

It's been a constant for the last couple of decades - I can't count the number of times I've been involved in mitigating penny-ante DDoS attacks which succeeded *solely* due to state exhaustion on stateful firewalls, 'IPS' devices, and load-balancers.

I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec spoofed SYN-flood.

I've seen a 10gb/sec commercial load-balancer taken down by 60 second at 6kpps - yes, 6kpps - of HOIC.

And so on, and so forth.

'Dismiss' it all you like, but it's a real issue, as others on this list know from bitter experience.

Thought I would add

Astaro IPS works great, great functionality and does prevent ddos and exploits.

Colin

Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network.

--p

Yes, update can cause problems, same as router code updates as well.
but update is price of progress.

Col

Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized.
--p

yes, using new rules via test ips good best practice as well.

And when your opinion is an acknowledged universal constant, I will tip

my hat to you.

It's been a constant for the last couple of decades - I can't count the
number of times I've been involved in mitigating penny-ante DDoS attacks
which succeeded *solely* due to state exhaustion on stateful firewalls,
'IPS' devices, and load-balancers.

I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec
spoofed SYN-flood.

I've seen a 10gb/sec commercial load-balancer taken down by 60 second at
6kpps - yes, 6kpps - of HOIC.

And so on, and so forth.

'Dismiss' it all you like, but it's a real issue, as others on this list
know from bitter experience.

Hi,

Roland is right. 99% of network based security products are pure snake
oil. Patch you servers, know your base line, statelessly filter unwanted
traffic, rtbh as needed, sleep well at night.

Bye.

>
>
> And when your opinion is an acknowledged universal constant, I will tip
>> my hat to you.
>>
>
> It's been a constant for the last couple of decades - I can't count the
> number of times I've been involved in mitigating penny-ante DDoS attacks
> which succeeded *solely* due to state exhaustion on stateful firewalls,
> 'IPS' devices, and load-balancers.
>
> I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec
> spoofed SYN-flood.
>
> I've seen a 10gb/sec commercial load-balancer taken down by 60 second at
> 6kpps - yes, 6kpps - of HOIC.
>
> And so on, and so forth.
>
> 'Dismiss' it all you like, but it's a real issue, as others on this list
> know from bitter experience.

Hi,

Roland is right. 99% of network based security products are pure snake
oil. Patch you servers, know your base line, statelessly filter unwanted
traffic, rtbh as needed, sleep well at night.

Bye.

Yeah, but Mr Tracanelli has a wider point. A firewall or IDS has its place
near the core, due to exhaustion not taking core routing down and taking
your availability away, while still adding security to it. While stateful
firewall / IPS / proxy belongs somewhere else deeper in the network, closer
to business logic than core/border.
Mr Dobbins' slides/presentation gives an idea that a proxy (waf, whatever)
fits sitting unprotected among routers and application servers, while its
also stateful and fragile enough to deserve previous protection.

from p.16 of the presentation in question:

'If stateful firewalls cannot be immediately removed from the architecture, they must be protected against DDoS via S/RTBH, flowspec, IDMS, et. al., just like servers!'

from p.19 of the presentation in question:

'Load-balancers must be protected against DDoS - stateless ACLs for policy enforcement, S/RTBH, flowspec, IDMS, and so forth.'

from p.28 of the presentation in question:

'Reverse-proxy farms must be protected from DDoS via S/RTBH, flowspec, IDMS, et. al.'