On 05/02/2015, at 12:31, Terry Baranski
<terry.baranski.l...@gmail.com> wrote:
On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins <rdobb...@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!"
