Re: Checkpoint IPS

[Patrick Tracanelli <eksffa () freebsdbrasil com br>]

> On 05/02/2015, at 12:31, Terry Baranski 
> <terry.baranski.list () gmail com> wrote:
>
> On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins <rdobbins () arbor net> wrote:
>
> > I've never heard a plausible anecdote, much less seen meaningful
> statistics,
> > of these devices actually 'preventing' anything.
>
> People tend to hear what they want to hear. Surely your claim can't be 
> that
> an IPS has never, in the history of Earth, prevented an attack or exploit.
> So it's unclear to me what you're actually trying to say here.
>
> > And the fact that well-known evasion techniques still work against these
> > devices today, coupled with the undeniable proliferation of compromised
> > hosts residing within networks supposedly 'protected' by these devices,
> > militates against your proposition.
>
> Your tendency of making blanket statements is somewhat baffling given the
> multitude of intricacies, details, and varying circumstances involved in a
> complex topic like this. To me, it's indicative of an overly-simplified
> and/or biased way of looking at things.
>
> In any case, go ahead and stick with your router ACLs and (stateful!)
> proxies. Different strokes.
>
> -Terry

There's room for a good engineered strategy for protection which won't 
turn into a point of failure in the overall networking topology.

For decades, since first rainbow series books were written and military 
“strategy” started to be added to information security, it’s always been 
about defense in depth and layered defense. Today those buzzwords became 
an incredibly “bullshit bingo” on sales force strategy on selling 
magical boxes and people tend to forget the basics. Layers and the 
“depth” is not a theory just to be added to drawings and keynote 
presentations.

Considering a simplistic topology for 3-tier (4 if you count T0) depth 
protection strategy:

(Internet)--[Tier-0]--(Core Router)--[Tier1]--(core 
switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret)

One security layer (tier, whatever) is there to try to fill the gap from 
the previous one.

How deep you have to dig depends on who you are. If you are the end 
organization willing to protect the golden secret, how complex is your 
topology, or if you are the carrier, the telecom the company worried 
only about BGP, PPS, BPS and availability other than the actual value 
for what's the real target for the attack (if not availability)

In summary, in my experience what will (not) work is:

1) Tier 0 & Tier 1
On border, core, (Tier0) or on Tier-1 protection layers (typical 
“firewall/dmz” topological position)

- Memory and CPU exaustion will shut down your operations (increase 
latency and decrease availability) easily, if you have a Protecting 
Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful 
Firewall or IPS.

The thing here is, you are insane or naive if you believe a finite state 
machine with finite resources can protect you from a virtually infinite 
(unlimited) source of attacks. No matter how much RAM you have, how much 
CPU cycles you have, they are finite, and since those “amazing stateful 
w/ deep inspection, scrub, normalization and reassembly” features on a 
firewall will demand at least 4K RAM per session and a couple CPU cycles 
per test, you have a whole “line rate” (1.4Mpps / 14Mpps for 1GbE 10GbE 
ports) attack potential, and come on, if a single or a 3-way packets 
sequence will cost you a state, it’s an easy math count to find out you 
are in a bad position trying to “secure” those Tier0 and Tier1 
topological locations. It's just easier and cheaper for the one 
attacking, than for your amazing firewall or IPS.

So what to do here? Try to get rid of most automated/scripted/simple 
attack you can. You can do ingress filtering, a lot of BCP, protection 
against SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, 
antipsoof, verrevreachability), and many good / effective (but limited) 
protection with ACL, data plane protection mechanisms, BGP blackholing, 
Null Routing (sending stuff to disc0 on BSD, null0 on Cisco, etc) and 
Stateles Firewalling.

Also, an IDS sensor might fit here, because if CPU/Memory starvation 
happens on an IDS sensor, the worst thing will happen is some packets 
getting routed without proper processing. But still, they will get routed.

Always stateles, always simple tests. No Layer7 inspection of any form, 
no load balancer, WAF, whatever.  No regex, hell no! No memory pointers 
that can point to dark processor/memory locations (again, no regex).

2) On Tier 2 protection (A defense depth that comes after core 
protection and after Tier-1):

- Will miserably fail if you use stateful firewall in excess
- Will fail even quicker if you use a WAF or IPS

Many “security engineers” and “security experts” (or worse, security 
tools vendors and developers) excessively use stateful tests on 
transport protocols that are simply… stateles.

What good you have on stateful firewalling… ICMP? UDP? DDP? IGMP? come 
on, all those state timers are worthless and your memory limits will 
reach very soon. Remember, in the average, 4K RAM at least, per stateful 
session. Much more resources are needed for IPS, much much more for 
inbound proxy (WAF), not to mention CPU.

Will you add an IPS here? What for, other than easing putting down and 
making your network and services unavailable?

Proxy? Mod Security? Hell no! Not here. Did you check how many regex and 
rules you have in the “base_rules” collection for a Top 10 OWASP 
protection on Mod Security? What about vendor specifics rules, or Sans 
Top 25 specifics.

This is just not the place.

Also, let’s rationale, what is your real benefit on deep inspection 
stateful filtering on those SSH sessions allowing for your trusted 
locations only? Really, what good will it make? Drop it stateles, allow 
it stateles! If you really believe stateful worths something for 
protocols such as SSH, do it somewhere else (Tier3 or host-based).

Focus on stateful protection only for what really needs some protection 
of this kind. Packets related, fragile services for packets arbitrarily 
assembled. Maybe SIP (SIP, not RTP), HTTPS, HTTP. Layer3/Layer4 fragile 
and public services, after some stateles inspection was already done on 
Tier1, should deserve stateful protection only. Not your whole network! 
Not your whole set of services or services.

And no ICMP, no UDP do deserve stateful.

Also, pick up a good tool for this.

Most sysadmins, security guys or network operators never notice how 
their tools may betray 'em hardly (by deault).

For example one use OpenBSD PF firewall, every rule you make will 
“automagically” become an stateful rule. And this is not good! This is 
terrible! This “auto” behavior makes the security engineer blind, since 
the rules he is writing is not the rules he is adding to kernel.

OpenBSD’s PF has a “no state” option and nobody uses it! It means you 
are doing it wrong… UDP/ICMP/TCP rules always have “keep state” added, 
if you don’t explicitly set “no state”. Beware!

The same is valid for Linux Netfilter, and 9 in 10 commercial firewalls 
(checkpoint, mikrotik, fortinet, whatever…).

FreeBSD’s ipfw on the other hand is stateles by default. It means if you 
don’t explicitly add “keep-state” there, it’s stateles. Which is good, 
unless you explicitly want a rule to be stateful. It’s excellent as a 
default behavior for protection layers not close to your "golden egg 
provider". On the other hand, ipfw by default has a limit of 4096 states 
which is TOO LOW. Beware too!

Regarding IPS/WAF/Proxy or “Next Generation” firewalls, this is not the 
place to add it.

On the other hand you need some level of extra protection firewalls will 
not provide, and some Layer7 inspection on Tier2 will be good.

But not Proxy! Not mod security! and not IPS! (no WAF)

IMHO, an IDS will fit good here.

IDS, not IPS, not IDP. Not a magical solution…

Why, from my past experiences, an IDS approach here will fit? Due it’s 
passive nature. If your IDS (say, Suricata, Bro, keeping on open source, 
or your commercial option of choice) starves on CPU or memory, what’s 
the worst thing to happen?

You will have a high number of PPS on that perimeter port passing 
without getting processed/inspected. Your overall security will 
decrease, but you still have Tier3 (and maybe other tiers) to fulfill 
the gap! Packets that still can be processed should have active response 
in place taking care of a lot of attacks.

What I mean is, if you have limited (and you do have limited) 
processing  and memory power, say you can IDS inspect 400Kpps but a 
1Mpps attack is ongoing, you have 40% inspection power, but packets not 
processed still get routed! Without latency and without packet loss 
because it’s an IDS and not an IPS. It’s not inline. It’s passive, 
sitting there. Limited resources, priority and lower kernel CPU 
scheduler relevance.

And for those 40% (very bad scenario I am drawing here) you still have 
active response in place, rerouting, reconfiguring stateles firewall, 
stateles ACLs and null routes on upper tiers (tier 0, tier 1, routers, 
switches) and lower tiers (tier 3 reconfigured upon tier 2 decision).

What you will do is try to fill the gap on next tiers, or increase your 
filtering capabilities that are still stateles or passive.

For many business, this is the end for added protection layers. A big 
ISP, transport provider, content delivery business... more protection 
from this point is something for the specific end business, and 
completely related to their needs, their business model, process, 
responsibilities and overall evaluated requirements. Not a general model 
to fit.

But for everyone else up to this tier you have relevant security 
mechanisms and tecnology added, and still low starvation/exaustion risks 
due to the stateles and passive nature of the approach.

3) On Tier 3, a protection strategy for your “golden eggs” provider, the 
golden secret, your business secret and intelligence

Usually, this protection level is for the corporate strategy. The 
business, not the carrier, the service provider or the network operator. 
And is a business specific requirement. Meaning it may not exist at all!

Now, for me, here is where you add more stateful inspection (still, only 
what is actually efficient, not that god damn echo reply/request wasting 
memory to be tracked down - useless!).

Here is a good place for a WAF, after firewall and IDS protection took 
place. WAF is a not a panaceia for anything, it's aimed for specific 
attacks against applications and protocols, is not resilient to coward 
attacks (volumetric, L3/L4 exaustion, etc). And a proxy in the end is 
always a web server, so inherits all it's fragility, and therefore it 
must be protected as well, before it can actually protect anything else.

Host Intrusion Detection central servers (receiving information gathered 
from HIDS on the actual hosts) also fits Tier3. As well as other 
host-based controls that may add telemetry information to a central 
location.

Talking about telemetry, it's important everywhere, and while generating 
flows or snmp info grabbing may impact processing usage on critical core 
devices, those extra added boxes should also passively help telemetry, 
with flow generation or minimum capability for snmp servings.

Nothing here is new. I am talking about, again, basic stuff discussed 
for decades on colored cover military books, drafts, discussions and 
BCPs and really old stuff discussed for people who may be already dead, 
sometimes (Itojun and other samurais' missed). I'm only mentioning the 
basic 3 tech domains (firewall, ids, proxy), but the other two basic 
(pen test, vuln scan) that are more process than technology are 
important as well.

For me, and again this is very personal opinion, I never run an IPS 
unless the customer "really wants to" (or a stupid compliance 
requirement really requires to). An IDS+Active Response is as good as 
IPS, and the only extra benefit an IPS will add compared to IDS is 
related to "single packet attacks", that ones that will pass quickly 
enough before the active response blocks it. But "single packet" attacks 
are related to poorly written software (or unpatched / not fixed 
software) since it's not really an attack, it's a trigger to bad code 
misbehavior and should be addressed on the host.

This is a very simple model, and easy to understand. However how many 
situations we've seen big companies getting completely unavailable or 
AAA getting broken because people insist to buy (and sell) "miracle 
boxes" added to core locations, and those miracle boxes will have 
amazing deep inspection firewalls or IPS or DLP (whatever it means, Data 
Loss, Data Leak, it means whatever you want to buy)...

There may be a place for those stuff, but it's not on core. Nor on 
second level protection layers.

In the end, ISO27002, PCI-DSS, CIA and AAA triads, what are they worth 
if you add an IPS to your core? When memory is exausted, processing is 
starved, you will have packet loss, latency, or you will be completely 
offline. And what's CIA if you "security features" are breaking 
Integrity due to missing packets, or breaking full Availability at all? 
What you have from CIA? Only confidentiality? Better take that plug off. 
Same for AAA, if Authorization and Authentication are broken or failed 
due to exaustion/starvation what you get? Accounting/Auditing? So you 
will sit and read the logs to find out what went wrong?

Discouraging firewall/IDS/proxy protection layers is as bad as over 
leveraging it.

Dosage is what distinguishes the poison from the vaccine.

--
Patrick Tracanelli
FreeBSD Brasil
Tel.: (31) 3516-0800
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"