Hi, Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers? Cheers, mh
On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren <m.hallgren@free.fr> wrote:
Hi,
Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers?
You can do "stretched" with Check Point as long as the network delay is less than around 70-100 msec RTT or so. If you do this, run your firewalls in Active/Standby modes.
Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren <m.hallgren@free.fr <mailto:m.hallgren@free.fr>> wrote:
Hi,
Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers?
You can do "stretched" with Check Point as long as the network delay is less than around 70-100 msec RTT or so. If you do this, run your firewalls in Active/Standby modes.
Thanks Eugeniu, I see what you mean. The specific case I'm looking at is about asymmetric routing, though. Cheers, mh
On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren <m.hallgren@free.fr> wrote:
Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren <m.hallgren@free.fr> wrote:
Hi,
Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers?
You can do "stretched" with Check Point as long as the network delay is less than around 70-100 msec RTT or so. If you do this, run your firewalls in Active/Standby modes.
Thanks Eugeniu, I see what you mean. The specific case I'm looking at is about asymmetric routing, though.
Firewalls/IPS and asymmetric routing don't play nice. Try to change your setup/design so that traffic enters/leaves your network segments through the same security device.
Le 04/02/2015 17:07, Eugeniu Patrascu a écrit :
On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren <m.hallgren@free.fr <mailto:m.hallgren@free.fr>> wrote:
Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren <m.hallgren@free.fr <mailto:m.hallgren@free.fr>> wrote:
Hi,
Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers?
You can do "stretched" with Check Point as long as the network delay is less than around 70-100 msec RTT or so. If you do this, run your firewalls in Active/Standby modes.
Thanks Eugeniu, I see what you mean. The specific case I'm looking at is about asymmetric routing, though.
Firewalls/IPS and asymmetric routing don't play nice. Try to change your setup/design so that traffic enters/leaves your network segments through the same security device.
I know. However, I fail to see symmetric traffic flow as ``natural'', apart from maybe at the extreme edge of a network. So, need another inspection strategy I think. Thanks, mh
Le 05/02/2015 08:01, Roland Dobbins a écrit :
On 5 Feb 2015, at 13:51, Michael Hallgren wrote:
So, need another inspection strategy I think. The real question is, why 'inspect', at all?
Yes, that's an even more interesting discussion! mh
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Thu, 05 Feb 2015 07:51:56 +0100, Michael Hallgren said:
I know. However, I fail to see symmetric traffic flow as ``natural'', apart from maybe at the extreme edge of a network. So, need another inspection strategy I think.
Firewalls aren't much help except at that extreme edge, anyhow.
On 2 Feb 2015, at 19:53, Michael Hallgren wrote:
Real life limitations?
<https://app.box.com/s/a3oqqlgwe15j8svojvzl> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
Le 04/02/2015 17:19, Roland Dobbins a écrit :
On 2 Feb 2015, at 19:53, Michael Hallgren wrote:
Real life limitations? <https://app.box.com/s/a3oqqlgwe15j8svojvzl>
Right ;-) Among many other nice ones, I like: `` ‘IPS’ devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.'' Cheers, mh
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 5 Feb 2015, at 01:56, Michael Hallgren wrote:
Le 04/02/2015 17:19, Roland Dobbins a écrit :
Real life limitations? https://app.box.com/s/a3oqqlgwe15j8svojvzl
Right ;-) Among many other nice ones, I like:
`` IPS devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.''
Dang, I thought this quote was from an April 1st RFC when I first read it. I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition. So when you're configuring artificially-engineered protocols on your artificially-engineered router so that your artificially-engineered network can transmit artificially-engineered packets, adding some extra artificially-engineered logic to enforce symmetry won't break the bank, I promise. And when done properly it has absolutely no impact on resilience and path diversity, and will do you all the good in the world from a troubleshooting perspective (those of you who operate networks). The whole presentation is frankly just odd to me. It looks at one specific CND thread (DDoS), and attempts to address it by throwing out the baby with the bathwater. It says to eliminate state at all costs, but then at the end advocates for reverse proxies -- which are stateful, and which therefore create the same "problems" as firewalls and IPSs. The idea of ripping out firewall/IPS devices and replacing them with router ACLs is something that, if I were an attacker, I would definitely encourage all of my targets to do. Firewalls aren't so much the big issue -- one can theoretically use router ACLs for basic L3/L4 blocks, though they scale horribly from an O&M perspective, are more prone to configuration errors, and their manageability is poor. But there's no overstating the usefulness of a properly-tuned IPS for attack prevention, and the comment in the brief comparing an IPS to "[Having] your email client set to alert you to incoming mail" is so bizarre that I wouldn't even know how to counter it. (I know you're out there Roland and my intention isn't to get into a big thing with you. But the artificial-engineering thing gave me a chuckle.) On 5 Feb 2015, at 02:49, Michael Hallgren wrote:
Le 05/02/2015 08:01, Roland Dobbins a écrit :
The real question is, why 'inspect', at all?
Yes, that's an even more interesting discussion!
Only if your assets aren't targets. :-) -Terry
`` ‘IPS’ devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.''
Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
You're forgetting that such things are rarely read (in time) by the people that actually implement and use such a product .. that language is targeted at the pointy-haired crowd. Salespeople *hate* it when they get a technical resource instead of a management one because "it's magic, it's artificial intelligence, etc." just doesn't fly with us. Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. My 0.02. Michael Holstein Cleveland State University 2
On 5 Feb 2015, at 20:13, Michael O Holstein wrote:
Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form.
Concur 100%. Securing hosts/applications/services themselves is the way to protect them from compromise. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
" Securing hosts/applications/services themselves is the way to protect them from compromise." Can't go wrong with defense in depth. I'd definitely throw securing routers in there, throw in firewalls, periodic internal scanning for idiot mistakes, audits, etc. I still think IPS/IDSes can be wielded to good effect in several different scenarios--e.g. just before the core switch (or spanning the core switch) of a PCN network, alerting to anything going on intra vs. inter. --p -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 05, 2015 7:20 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS On 5 Feb 2015, at 20:13, Michael O Holstein wrote:
Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form.
Concur 100%. Securing hosts/applications/services themselves is the way to protect them from compromise. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
+100% agree. ...Skeeve *Skeeve Stevens - Founder & Chief Network Architect* eintellego Networks Pty Ltd Email: skeeve@eintellegonetworks.com ; Web: eintellegonetworks.com Phone: 1300 239 038 ; Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> The Experts Who The Experts Call Juniper - Cisco - Cumulus Linux - Cloud - Consulting - IPv4 Brokering On Fri, Feb 6, 2015 at 12:19 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 5 Feb 2015, at 20:13, Michael O Holstein wrote:
Personally I'm of the belief that *all* IPS systems are equally
worthless, unless the goal is to just check a box on a form.
Concur 100%.
Securing hosts/applications/services themselves is the way to protect them from compromise.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
Like most tools, IPSes are only as good as the people using them. +10 "you can't just plug the "magic box" inline and expect to relax" IPSes can't replace a well administered modern firewall, with default deny, well defined protocols with sanity checking, etc. But imho they can help--e.g. with an internal well-protected network that shouldn't even be able to be attacked, but some dude picked up a usb key in the parking lot and plugged it into his PC to see what was on it. No firewall will help with this--but an IDS/IPS will. And no box is magic (another +10), despite the marketing droids' nebulous talk of clouds and AI and harnessing the power of the nuclear-nano-crowd-source. They all need active attention by knowledgeable and intelligent people. --p -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Michael O Holstein Sent: Thursday, February 05, 2015 7:13 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS <clip> Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. <clip> Michael Holstein Cleveland State University 2
On 5 Feb 2015, at 08:13, Michael Hallgren wrote:
Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost.
Sorry but this is not even in the neighborhood of what a properly-implemented IPS does. I can certainly see why you think they're worthless though. :-) -Terry -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Michael O Holstein Sent: Thursday, February 05, 2015 8:13 AM To: nanog@nanog.org Subject: Re: Checkpoint IPS
`` 'IPS' devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.''
Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
You're forgetting that such things are rarely read (in time) by the people that actually implement and use such a product .. that language is targeted at the pointy-haired crowd. Salespeople *hate* it when they get a technical resource instead of a management one because "it's magic, it's artificial intelligence, etc." just doesn't fly with us. Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax. My 0.02. Michael Holstein Cleveland State University 2=
Le 05/02/2015 14:28, Terry Baranski a écrit :
On 5 Feb 2015, at 08:13, Michael Hallgren wrote:
Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost.
No, Terry, I didn't write that ! :-) Cheers, mh
Sorry but this is not even in the neighborhood of what a properly-implemented IPS does.
I can certainly see why you think they're worthless though. :-)
-Terry
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Michael O Holstein Sent: Thursday, February 05, 2015 8:13 AM To: nanog@nanog.org Subject: Re: Checkpoint IPS
`` 'IPS' devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.'' Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition. You're forgetting that such things are rarely read (in time) by the people that actually implement and use such a product .. that language is targeted at the pointy-haired crowd. Salespeople *hate* it when they get a technical resource instead of a management one because "it's magic, it's artificial intelligence, etc." just doesn't fly with us.
Personally I'm of the belief that *all* IPS systems are equally worthless, unless the goal is to just check a box on a form. Sure they will give you pretty graphs of script-kiddie attempts but that's just the noise in which the skilled attack will get lost. You have to do everything else right, you can't just plug the "magic box" inline and expect to relax.
My 0.02.
Michael Holstein Cleveland State University 2=
mh, you know that forcing traffic to be symmetrical is evil, and while backbone traffic and inspection don't play nice, there are very legit reasons why, in many cases edge traffic must be open for inspection. I'm on my way to the office, feel free to ping me if you want to discuss. Or maybe I could use it as a reason to come visit its been a while since we've had a chance to vis-a-vis :) -jim On Thu, Feb 5, 2015 at 8:57 AM, Terry Baranski < terry.baranski.list@gmail.com> wrote:
On 5 Feb 2015, at 01:56, Michael Hallgren wrote:
Le 04/02/2015 17:19, Roland Dobbins a écrit :
Real life limitations? https://app.box.com/s/a3oqqlgwe15j8svojvzl
Right ;-) Among many other nice ones, I like:
`` ‘IPS’ devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.''
Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
So when you're configuring artificially-engineered protocols on your artificially-engineered router so that your artificially-engineered network can transmit artificially-engineered packets, adding some extra artificially-engineered logic to enforce symmetry won't break the bank, I promise. And when done properly it has absolutely no impact on resilience and path diversity, and will do you all the good in the world from a troubleshooting perspective (those of you who operate networks).
The whole presentation is frankly just odd to me. It looks at one specific CND thread (DDoS), and attempts to address it by throwing out the baby with the bathwater. It says to eliminate state at all costs, but then at the end advocates for reverse proxies -- which are stateful, and which therefore create the same "problems" as firewalls and IPSs.
The idea of ripping out firewall/IPS devices and replacing them with router ACLs is something that, if I were an attacker, I would definitely encourage all of my targets to do. Firewalls aren't so much the big issue -- one can theoretically use router ACLs for basic L3/L4 blocks, though they scale horribly from an O&M perspective, are more prone to configuration errors, and their manageability is poor. But there's no overstating the usefulness of a properly-tuned IPS for attack prevention, and the comment in the brief comparing an IPS to "[Having] your email client set to alert you to incoming mail" is so bizarre that I wouldn't even know how to counter it.
(I know you're out there Roland and my intention isn't to get into a big thing with you. But the artificial-engineering thing gave me a chuckle.)
On 5 Feb 2015, at 02:49, Michael Hallgren wrote:
Le 05/02/2015 08:01, Roland Dobbins a écrit :
The real question is, why 'inspect', at all?
Yes, that's an even more interesting discussion!
Only if your assets aren't targets. :-)
-Terry
Le 05/02/2015 14:15, jim deleskie a écrit :
mh,
Hi there Jim :-)
you know that forcing traffic to be symmetrical is evil,
Voilà !
and while backbone traffic and inspection don't play nice, there are very legit reasons why, in many cases edge traffic must be open for inspection.
Yes, right, often some such `control' is on wish-lists.
I'm on my way to the office, feel free to ping me if you want to discuss. Or maybe I could use it as a reason to come visit its been a while since we've had a chance to vis-a-vis :)
With pleasure! Yes, too long time... TTYS, mh
-jim
On Thu, Feb 5, 2015 at 8:57 AM, Terry Baranski <terry.baranski.list@gmail.com <mailto:terry.baranski.list@gmail.com>> wrote:
On 5 Feb 2015, at 01:56, Michael Hallgren wrote: > Le 04/02/2015 17:19, Roland Dobbins a écrit : >> >> Real life limitations? >> https://app.box.com/s/a3oqqlgwe15j8svojvzl > > Right ;-) Among many other nice ones, I like: > > `` ‘IPS’ devices require artificially-engineered topological symmetry- > can have a negative impact on resiliency via path diversity.''
Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
So when you're configuring artificially-engineered protocols on your artificially-engineered router so that your artificially-engineered network can transmit artificially-engineered packets, adding some extra artificially-engineered logic to enforce symmetry won't break the bank, I promise. And when done properly it has absolutely no impact on resilience and path diversity, and will do you all the good in the world from a troubleshooting perspective (those of you who operate networks).
The whole presentation is frankly just odd to me. It looks at one specific CND thread (DDoS), and attempts to address it by throwing out the baby with the bathwater. It says to eliminate state at all costs, but then at the end advocates for reverse proxies -- which are stateful, and which therefore create the same "problems" as firewalls and IPSs.
The idea of ripping out firewall/IPS devices and replacing them with router ACLs is something that, if I were an attacker, I would definitely encourage all of my targets to do. Firewalls aren't so much the big issue -- one can theoretically use router ACLs for basic L3/L4 blocks, though they scale horribly from an O&M perspective, are more prone to configuration errors, and their manageability is poor. But there's no overstating the usefulness of a properly-tuned IPS for attack prevention, and the comment in the brief comparing an IPS to "[Having] your email client set to alert you to incoming mail" is so bizarre that I wouldn't even know how to counter it.
(I know you're out there Roland and my intention isn't to get into a big thing with you. But the artificial-engineering thing gave me a chuckle.)
On 5 Feb 2015, at 02:49, Michael Hallgren wrote: > Le 05/02/2015 08:01, Roland Dobbins a écrit : >> >> The real question is, why 'inspect', at all? > > Yes, that's an even more interesting discussion!
Only if your assets aren't targets. :-)
-Terry
On 5 Feb 2015, at 19:57, Terry Baranski wrote:
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
This isn't even worthy of comment, so I won't.
But there's no overstating the usefulness of a properly-tuned IPS for attack prevention
I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. I have, however, run into many, many situations in which these devices demonstrably degraded the security posture of network operators, particularly when placed in front of servers or broadband access networks. For example, they're laughably easy to DDoS due to state exhaustion - which is what is the main point of the presentation you reference. 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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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
On Thu, 05 Feb 2015 09:31:49 -0500, Terry Baranski said:
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.
Count up the number of *actual* attacks they have stopped that wouldn't have been stopped otherwise, and contrast it to the number of times they've been used as the *basis* for an attack (DDoS via state exhaustion, for starters) or their failure has caused operational issues. Remember that one of the three security pillars is "Availability". Still think they're a good idea?
On 6 Feb 2015, at 11:46, Valdis Kletnieks wrote:
Count up the number of *actual* attacks they have stopped that wouldn't have been stopped otherwise
Many.
and contrast it to the number of times they've been used as the *basis* for an attack (DDoS via state exhaustion, for starters)
Zero, on my networks.
or their failure has caused operational issues.
Zero, on my networks. Unless "operation issues" means traffic fails over without a hitch.
Still think they're a good idea?
Yep. And thanks for asking. If you can't deploy IPS's in such a way that they don't make your network less secure via DDoS susceptibility, or reduce availability due to non-existent or subpar redundancy/survivability engineering, then you shouldn't deploy IPS's. -Terry On Thu, Feb 5, 2015 at 11:46 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 05 Feb 2015 09:31:49 -0500, Terry Baranski said:
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.
Count up the number of *actual* attacks they have stopped that wouldn't have been stopped otherwise, and contrast it to the number of times they've been used as the *basis* for an attack (DDoS via state exhaustion, for starters) or their failure has caused operational issues. Remember that one of the three security pillars is "Availability".
Still think they're a good idea?
On 6 Feb 2015, at 2:26, Terry Baranski wrote:
Zero, on my networks.
Which highlights the importance of broadness of experience, of knowledge and understanding of the experiences of others, and understanding of the implications of scale.
If you can't deploy IPS's in such a way that they don't make your network less secure via DDoS susceptibility, or reduce availability due to non-existent or subpar redundancy/survivability engineering, then you shouldn't deploy IPS's.
By their very nature, it's impossible to do so. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 6 Feb 2015, at 3:01, Roland Dobbins wrote:
Which highlights the importance of broadness of experience, of knowledge and understanding of the experiences of others, and understanding of the implications of scale.
It highlights the importance of knowing what you're doing in the real world, on networks that exist and which you actually understand intimately, end-to-end. And maybe also of not working for vendors, since these two things are often mutually exclusive.
By their very nature, it's impossible to do so.
Nope. But in any case, I've violated what I said this morning about not turning this into a big back-and-forth. (Sorry.) -Terry
On 6 Feb 2015, at 4:24, Terry Baranski wrote:
It highlights the importance of knowing what you're doing in the real world, on networks that exist and which you actually understand intimately, end-to-end.
Absolutely. At least one of the parties in this discussion has such knowledge of and experience on real-world networks of considerable scale, and is not infrequently engaged hands-on in the preservation of availability on said networks in fraught circumstances.
And maybe also of not working for vendors, since these two things are often mutually exclusive.
Again, absolutely. At least one of the parties has seen firsthand the extremely negative impact of the devices in question on a broad array of large-scale production networks ever since said devices were first introduced in the 1990s, having been awakened at 0Dark30 on numerous occasions with pleas for assistance because 'the network is down', 'the data center is offline', 'our entire wireless broadband network is down', et. al., due to the manifest failings of such devices. Anyways, enough. This topic has been thoroughly discussed multiple times on this list and on others of an operational nature; if you believe it wise to discount the well-understood negative impact of such devices on availability, that is your choice. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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!"
An IPS doesn't have to be in line. 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). 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). 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. On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli <eksffa@freebsdbrasil.com.br> wrote:
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!"
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
On 6 Feb 2015, at 20:08, Ray Soucy wrote:
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).
Using flow telemetry for this scales much, much better. One could easily set something like this up using open source flow telemetry collection/analysis tools. Of course, giving attackers the ability to spoof the IP addresses of their choice and then induce your network infrastructure into blocking said IP addresses isn't necessarily optimal, IMHO. I'm not a big fan of any kind of auto-mitigation for this reason - it's best to have a human operator in the loop. If one is determined to do this kind of auto-mitigation, it's probably a good idea to whitelist certain things which ought never to be S/RTBHed via appropriate route filtering on the trigger and/or edge devices where traffic will be dropped. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
Hello,
On 06/02/2015, at 11:08, Ray Soucy <rps@maine.edu> wrote:
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.
On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli <eksffa@freebsdbrasil.com.br> wrote:
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!"
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
-- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"
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
On 6 Feb 2015, at 21:27, Darden, Patrick wrote:
I understand the whole argument against state, and dismiss it.
One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Roland Dobbins Sent: Friday, February 06, 2015 10:09 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS On 6 Feb 2015, at 21:27, Darden, Patrick wrote:
I understand the whole argument against state, and dismiss it.
One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 6 Feb 2015, at 23:23, Darden, Patrick wrote:
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. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Friday, February 6, 2015, Roland Dobbins <rdobbins@arbor.net> wrote:
On 6 Feb 2015, at 23:23, Darden, Patrick wrote:
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.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Sun, Feb 8, 2015 at 2:05 AM, Ca By <cb.list6@gmail.com> wrote:
On Friday, February 6, 2015, Roland Dobbins <rdobbins@arbor.net> wrote:
On 6 Feb 2015, at 23:23, Darden, Patrick wrote:
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.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 8 Feb 2015, at 23:00, BPNoC Group wrote:
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.' ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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 -----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col
On 6 Feb 2015, at 16:44, Darden, Patrick <Patrick.Darden@p66.com> wrote:
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
-----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS
Thought I would add
Astaro IPS works great, great functionality and does prevent ddos and exploits.
Colin
Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. --p -----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:46 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col
On 6 Feb 2015, at 16:44, Darden, Patrick <Patrick.Darden@p66.com> wrote:
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
-----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS
Thought I would add
Astaro IPS works great, great functionality and does prevent ddos and exploits.
Colin
yes, using new rules via test ips good best practice as well.
On 6 Feb 2015, at 16:47, Darden, Patrick <Patrick.Darden@p66.com> wrote:
Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. --p
-----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:46 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS
Yes, update can cause problems, same as router code updates as well. but update is price of progress.
Col
On 6 Feb 2015, at 16:44, Darden, Patrick <Patrick.Darden@p66.com> wrote:
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
-----Original Message----- From: Colin Johnston [mailto:colinj@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS
Thought I would add
Astaro IPS works great, great functionality and does prevent ddos and exploits.
Colin
But there's no overstating the usefulness of a properly-tuned IPS for attack prevention
I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything.
I think it depends upon where you put them, and whether or not you have skilled people involved. Given good placement, and experienced management, I have seen the usefulness of these devices ... by personally reviewing the logs and being the recipient of drop alerts of the devices in terms of what they can reject.
I have, however, run into many, many situations in which these devices demonstrably degraded the security posture of network operators, particularly when placed in front of servers or broadband access networks. For example, they're laughably easy to DDoS due to state exhaustion -
which
is what is the main point of the presentation you reference.
Sometimes we get in to corner cases too easily where the negative is easily applied. Yes, they can be DDoS'd. Yes they can be useless in the hands of the unskilled and unknowing. On the other hand, given good placement in strategic places, and maintained appropriately, they can live up the their expectations.
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.
Well.... again, yes, they may not get all zero-day exploits. That is another corner case. But they can certainly prevent getting hit by the same old stuff over and over again. I've seen drop rules for the Bash issue, and the openssl issue put in place, and when implemented, prevent the further spread of the malicious payloads. There must some sort of value in that? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
What if you are a hosting company and those aren't your servers to patch? What about the time to patch 200+ servers versus configuring one location? What if you have to schedule the staff and maintenance window to patch the servers? What if you have legacy equipment that you must continue using, but the vendor is slow to provide the patch. There is a huge difference in what is good network/security designs between content providers, transit networks, eyeball networks, corporate networks, universities, etc... One size doesn't fit all. ---- 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@nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 5, 2015 12:48 PM To: nanog@nanog.org Subject: Re: Checkpoint IPS On 6 Feb 2015, at 0:38, Raymond Burkholder wrote:
There must some sort of value in that?
No - patch the servers. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
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@arbor.net>
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@nanog.org] On Behalf Of Roland Dobbins Sent: Thursday, February 5, 2015 1:11 PM To: nanog@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@arbor.net>
On 6 Feb 2015, at 1:26, Matthew Huff wrote:
Like it's been said before, I strongly support my competitors following your advice.
Sorry - I've done the jobs, all of them. They can be done properly, and are done properly by clueful operators. Oh, and what are operators who deploy these things supposed to do about *vulnerabilities in these devices themselves*? That's a huge problem, they present a juicy attack surface, and exploits are discovered regularly. That's in the presentation, as well. I've heard these same tired arguments over and over again. Folks tend to change their tune when their entire production infrastructure is rendered unavailable by a tiny DDoS which could be sourced from a single smartphone; it's just sad that so many are only ready to listen and learn after they've suffered serious production-impacting outages. If all it took to achieve *real* security - as opposed to 'compliance' or vendor marketing 'security' - were to write a check or cut a P.O. and drop some middlebox/middleblade in the network, we wouldn't be in the permanent state of security emergency in which we find ourselves. *Real* security mostly consists of *doing things*. It requires skilled, experienced people who have both broad and deep expertise across the entire OSI model, are well-versed in architecture and the operational arts, and who understand all the implications of scale. Unfortunately, such people are relatively rare, even within the self-selected ranks of network operators - as several posts on this thread clearly demonstrate. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 6 Feb 2015, at 1:40pm, Roland Dobbins wrote:
*Real* security mostly consists of *doing things*. It requires skilled, experienced people who have both broad and deep expertise across the entire OSI model, are well-versed in architecture and the operational arts, and who understand all the implications of scale.
And if there's one person qualified to comment on what "real security" is, it's a person who has "never heard a plausible anecdote of [IPS] devices actually 'preventing' anything." :-) -Terry On Thu, Feb 5, 2015 at 1:40 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 6 Feb 2015, at 1:26, Matthew Huff wrote:
Like it's been said before, I strongly support my competitors following
your advice.
Sorry - I've done the jobs, all of them. They can be done properly, and are done properly by clueful operators.
Oh, and what are operators who deploy these things supposed to do about *vulnerabilities in these devices themselves*? That's a huge problem, they present a juicy attack surface, and exploits are discovered regularly. That's in the presentation, as well.
I've heard these same tired arguments over and over again. Folks tend to change their tune when their entire production infrastructure is rendered unavailable by a tiny DDoS which could be sourced from a single smartphone; it's just sad that so many are only ready to listen and learn after they've suffered serious production-impacting outages.
If all it took to achieve *real* security - as opposed to 'compliance' or vendor marketing 'security' - were to write a check or cut a P.O. and drop some middlebox/middleblade in the network, we wouldn't be in the permanent state of security emergency in which we find ourselves.
*Real* security mostly consists of *doing things*. It requires skilled, experienced people who have both broad and deep expertise across the entire OSI model, are well-versed in architecture and the operational arts, and who understand all the implications of scale.
Unfortunately, such people are relatively rare, even within the self-selected ranks of network operators - as several posts on this thread clearly demonstrate.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On 6 Feb 2015, at 2:29, Terry Baranski wrote:
And if there's one person qualified to comment on what "real security" is, it's a person who has "never heard a plausible anecdote of [IPS] devices actually 'preventing' anything." :-)
That's right - especially if such a person spent a not-inconsiderable amount of time working for the world's largest manufacturer of such devices, and heard no such plausible anecdote during his time there, even though he asked repeatedly for same. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 6 Feb 2015, at 0:38, Raymond Burkholder wrote:
There must some sort of value in that?
No - patch the servers.
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.
Le 05/02/2015 13:57, Terry Baranski a écrit :
On 5 Feb 2015, at 01:56, Michael Hallgren wrote:
Le 04/02/2015 17:19, Roland Dobbins a écrit :
Real life limitations? https://app.box.com/s/a3oqqlgwe15j8svojvzl Right ;-) Among many other nice ones, I like:
`` ‘IPS’ devices require artificially-engineered topological symmetry- can have a negative impact on resiliency via path diversity.'' Dang, I thought this quote was from an April 1st RFC when I first read it.
I hate to be the bearer of bad news, but everything we do is "artificial". There are no routers in nature, no IP packets, no fiber optics. There is no such thing as "natural engineering" -- engineering is "artificial" by definition.
So when you're configuring artificially-engineered protocols on your artificially-engineered router so that your artificially-engineered network can transmit artificially-engineered packets, adding some extra artificially-engineered logic to enforce symmetry won't break the bank, I promise. And when done properly it has absolutely no impact on resilience and path diversity, and will do you all the good in the world from a troubleshooting perspective (those of you who operate networks).
Depends on the underlying physical network... (which may be quite costly to ``fix''). mh
The whole presentation is frankly just odd to me. It looks at one specific CND thread (DDoS), and attempts to address it by throwing out the baby with the bathwater. It says to eliminate state at all costs, but then at the end advocates for reverse proxies -- which are stateful, and which therefore create the same "problems" as firewalls and IPSs.
The idea of ripping out firewall/IPS devices and replacing them with router ACLs is something that, if I were an attacker, I would definitely encourage all of my targets to do. Firewalls aren't so much the big issue -- one can theoretically use router ACLs for basic L3/L4 blocks, though they scale horribly from an O&M perspective, are more prone to configuration errors, and their manageability is poor. But there's no overstating the usefulness of a properly-tuned IPS for attack prevention, and the comment in the brief comparing an IPS to "[Having] your email client set to alert you to incoming mail" is so bizarre that I wouldn't even know how to counter it.
(I know you're out there Roland and my intention isn't to get into a big thing with you. But the artificial-engineering thing gave me a chuckle.)
On 5 Feb 2015, at 02:49, Michael Hallgren wrote:
Le 05/02/2015 08:01, Roland Dobbins a écrit :
The real question is, why 'inspect', at all? Yes, that's an even more interesting discussion! Only if your assets aren't targets. :-)
-Terry
participants (18)
-
BPNoC Group
-
Ca By
-
Colin Johnston
-
Darden, Patrick
-
Eugeniu Patrascu
-
jim deleskie
-
Joel Maslak
-
Matthew Huff
-
Michael Hallgren
-
Michael O Holstein
-
Nick Hilliard
-
Patrick Tracanelli
-
Ray Soucy
-
Raymond Burkholder
-
Roland Dobbins
-
Skeeve Stevens
-
Terry Baranski
-
Valdis.Kletnieks@vt.edu