Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
On Sun, Feb 8, 2015 at 2:05 AM, Ca By cb.li...@gmail.com wrote: On Friday, February 6, 2015, Roland Dobbins rdobb...@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 rdobb...@arbor.net
Re: Checkpoint IPS
On Friday, February 6, 2015, Roland Dobbins rdobb...@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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
RE: Re: Checkpoint IPS
IPSes are like any security technology, they are only as good as their implementor/administrator. I've seen some installations just set up defaults and leave them that way without any maintenance nor much oversight of alarms. I've even seen some that do 0-day implementation of new signatures, and get some legitimate or even ALL traffic blocked by a bad signature (Astaro/Sophos UTM) update back in ~2004. On the other hand, I've seen some great implementations--some of which did a FANTASTIC job of making a network auditable, some of which made a network less liable legally and financially, and quite a few that made a network more secure. To me, the big drawback of an IPS is, no matter how well integrated, implemented, and maintained--it's fundamental nature is flawed. Instead of default-deny with white lists, it is default-allow with black lists. It will always lag behind. It will always allow infinitely large holes. That's why I prefer an OSI complete firewall instead, or else an IPS in detect mode only, or in certain cases an IPS used in a specific case, e.g. a WAF or SAF for a server/application/zone that is specifically fuzzy or will not adhere to security principles (vendor demilitarized zones, enclaves, whatever the buzz-word is at the moment). I understand the whole argument against state, and dismiss it. That's throwing the baby out with the bathwater. It isn't perfect, it can be overcome via DDOS and saturation, so we should get rid of it. Tanks can be destroyed by bazookas, whatever. Tanks are still useful in the battlefield if utilized properly. Firewalls and IPSes are the same way. --p
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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
RE: Re: Checkpoint IPS
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:col...@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.dar...@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:col...@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
Re: Checkpoint IPS
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 eks...@freebsdbrasil.com.br wrote: On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military strategy started to be added to information security, it's always been about defense in depth and layered defense. Today those buzzwords became an incredibly bullshit bingo on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the depth is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical firewall/dmz topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those amazing stateful w/ deep inspection, scrub, normalization and reassembly features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a whole line rate (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack potential, and come on, if a single or a 3-way packets sequence will cost you a state, it's an easy math count to find out you are in a bad position trying to secure those Tier0 and Tier1 topological locations. It's just easier and cheaper for the one attacking, than for your amazing firewall or IPS. So what to do here? Try to get rid of most automated/scripted/simple attack you can. You can do ingress filtering, a lot of BCP, protection against SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, verrevreachability), and many good / effective (but limited) protection with ACL, data plane protection mechanisms, BGP blackholing, Null Routing (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles Firewalling. Also, an IDS sensor might fit here, because if CPU/Memory starvation happens on an IDS sensor, the worst thing will happen is some packets getting routed without proper processing. But still, they will get routed. Always stateles, always simple tests. No Layer7 inspection of any
Re: Checkpoint IPS
On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins rdobb...@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.
Re: Checkpoint IPS
Hello, On 06/02/2015, at 11:08, Ray Soucy r...@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 eks...@freebsdbrasil.com.br wrote: On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military strategy started to be added to information security, it's always been about defense in depth and layered defense. Today those buzzwords became an incredibly bullshit bingo on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the depth is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical firewall/dmz topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those amazing stateful w/ deep inspection, scrub, normalization and reassembly features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a
RE: Re: Checkpoint IPS
Absolutely. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver.
RE: Re: Checkpoint IPS
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-boun...@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 rdobb...@arbor.net
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.dar...@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:col...@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
RE: Re: Checkpoint IPS
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:col...@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
Re: Checkpoint IPS
yes, using new rules via test ips good best practice as well. On 6 Feb 2015, at 16:47, Darden, Patrick patrick.dar...@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:col...@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.dar...@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:col...@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
RE: Re: Checkpoint IPS
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-boun...@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 rdobb...@arbor.net
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 rdobb...@arbor.net
RE: Checkpoint IPS
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 OM 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
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
Re: Checkpoint IPS
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 OM 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
RE: Checkpoint IPS
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-boun...@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=
Re: Checkpoint IPS
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.l...@gmail.com mailto:terry.baranski.l...@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 OM 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
Re: Checkpoint IPS
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-boun...@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=
Re: Checkpoint IPS
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.l...@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 OM 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
RE: Checkpoint IPS
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-boun...@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
Re: Checkpoint IPS
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 rdobb...@arbor.net
RE: Checkpoint IPS
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
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
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.kletni...@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?
Re: Checkpoint IPS
On 05/02/2015 13:15, jim deleskie wrote: you know that forcing traffic to be symmetrical is evil it's not evil; it's stupid because enforcing symmetry creates a potentially unnatural stress in a network which will revert to asymmetry, given half a chance. Nick
Re: Checkpoint IPS
On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry
Re: Checkpoint IPS
+100% agree. ...Skeeve *Skeeve Stevens - Founder Chief Network Architect* eintellego Networks Pty Ltd Email: ske...@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 rdobb...@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 rdobb...@arbor.net
Re: Checkpoint IPS
On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military “strategy” started to be added to information security, it’s always been about defense in depth and layered defense. Today those buzzwords became an incredibly “bullshit bingo” on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the “depth” is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical “firewall/dmz” topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those “amazing stateful w/ deep inspection, scrub, normalization and reassembly” features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a whole “line rate” (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack potential, and come on, if a single or a 3-way packets sequence will cost you a state, it’s an easy math count to find out you are in a bad position trying to “secure” those Tier0 and Tier1 topological locations. It's just easier and cheaper for the one attacking, than for your amazing firewall or IPS. So what to do here? Try to get rid of most automated/scripted/simple attack you can. You can do ingress filtering, a lot of BCP, protection against SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, verrevreachability), and many good / effective (but limited) protection with ACL, data plane protection mechanisms, BGP blackholing, Null Routing (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles Firewalling. Also, an IDS sensor might fit here, because if CPU/Memory starvation happens on an IDS sensor, the worst thing will happen is some packets getting routed without proper processing. But still, they will get routed. Always stateles, always simple tests. No Layer7 inspection of any form, no load balancer, WAF, whatever. No regex, hell no! No memory pointers that can point to dark processor/memory locations (again, no regex). 2) On Tier 2 protection (A defense depth that comes after core protection and after Tier-1): - Will miserably fail if you use stateful firewall in excess - Will fail even quicker if you use a WAF or IPS Many “security engineers” and “security experts” (or worse, security tools vendors and developers) excessively use stateful tests on transport protocols that are simply… stateles. What good you have on stateful firewalling… ICMP? UDP? DDP? IGMP? come on, all those state timers are worthless and your
RE: Checkpoint IPS
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.
Re: Checkpoint IPS
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. pgpEJIriJW2ho.pgp Description: PGP signature
Re: Checkpoint IPS
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? pgp4ATJw4VO19.pgp Description: PGP signature
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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
RE: Checkpoint IPS
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-boun...@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 rdobb...@arbor.net
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 rdobb...@arbor.net
RE: Checkpoint IPS
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-boun...@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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
On 2 Feb 2015, at 19:53, Michael Hallgren wrote: Real life limitations? https://app.box.com/s/a3oqqlgwe15j8svojvzl --- Roland Dobbins rdobb...@arbor.net
Re: Checkpoint IPS
On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren m.hallg...@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.hallg...@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.
Re: Checkpoint IPS
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? --- Roland Dobbins rdobb...@arbor.net
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
Le 04/02/2015 17:07, Eugeniu Patrascu a écrit : On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren m.hallg...@free.fr mailto:m.hallg...@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.hallg...@free.fr mailto:m.hallg...@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
Re: Checkpoint IPS
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 rdobb...@arbor.net
Re: Checkpoint IPS
On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren m.hallg...@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.
Re: Checkpoint IPS
Le 03/02/2015 16:21, Eugeniu Patrascu a écrit : On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren m.hallg...@free.fr mailto:m.hallg...@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
Checkpoint IPS
Hi, Someone has positive or negative experience running Checkpoint IPS cluster over ``long distance'' synch. network? Real life limitations? Alternatives? Timers? Cheers, mh
