D/DoS mitigation hardware/software needed.
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core. I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives. My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH. Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed. I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases. Thanks, Rick
We have substantial direct experience with both RioRey and IntruGuard. RR is more plug and play while IG is more robust but both are great. Use a robust firewall such as a Netscreen in front of your mitigation tool. Best regards, Jeff On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH.
Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed.
I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases.
Thanks, Rick
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation tool.
Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Kinda funny you state that Roland. I know of at least two very large carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS mitigation. State table exhaustion on the netscreen platform is something that is very easy to protect against with some protections and hasn't been a problem for years. If you can fill up a session table on a higher end SRX then I would be very very impressed. I would argue that firewalls place is in fact directly infront of servers and load balancers to protect them. On Mon, Jan 4, 2010 at 8:04 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation tool.
Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
On Jan 5, 2010, at 9:17 AM, Tim Eberhard wrote:
I would argue that firewalls place is in fact directly infront of servers and load balancers to protect them.
The very idea of placing a stateful firewall in front of a Web/DNS/email/etc. server, in which *every single incoming packet is unsolicited, and therefore, leaves no state to be inspected in the first place*, is absurd. There is simply no valid argument for doing so. Hardening the OS/apps/services, combined with stateless ACLs in hardware which can handle mpps, is the way to enforce policy. In fact, the idea is such a poor one that one of the major firewall vendors came out with a 'stateful inspection bypass' feature - the idea being that, you buy their 10gb/sec, $100K-plus stateful firewall, stick it in front of servers, and then . . . disable the stateful inspection, heh. ;> None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Tue, Jan 05, 2010, Dobbins, Roland wrote:
None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions.
But as you said, they're willing to sell them to you. Then claim that the traffic you're receiving is out of profile. :) (I'm not jaded about this, oh no..) Adrian
Adrian Chadd wrote:
On Tue, Jan 05, 2010, Dobbins, Roland wrote:
None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions.
But as you said, they're willing to sell them to you. Then claim that the traffic you're receiving is out of profile. :)
(I'm not jaded about this, oh no..)
...so, out of curiosity, which one did you buy? ;) Steve
On 2010-01-05 03:17, Tim Eberhard wrote:
Kinda funny you state that Roland. I know of at least two very large carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS mitigation.
You mean Juniper SRX? The biggest box is a 5800, and it can handle up to 350k new sessions each second, up to maximum of 10 million (let's skip the fact that it's not that simple as it would look from the data sheet and there are major obstacles from reaching the numbers). 350kpps of TCP SYNs or whatever more wiser your botnet controller will generate, coming to your Internet pipe is really a small, very small DDoS. In terms of short packets like TCP SYN it's only around 179Mbit/s worth of bandwidth. Roland is right. Given finite resources to hold and process stateful information, the stateful device on a packet way to protected device is always vulnerable itself to become DDoSed. You can't discuss the logic of that, you can only throw more capable boxes and of course fail at some point. -- "Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net
-----Original Message----- From: Łukasz Bromirski [mailto:lukasz@bromirski.net] Sent: Saturday, January 09, 2010 6:11 AM
You mean Juniper SRX? The biggest box is a 5800, and it can handle up to 350k new sessions each second, up to maximum of 10 million (let's skip the fact that it's not that simple as it would look from the data sheet and there are major obstacles from reaching the numbers).
With all due respect, I've been playing with the high end SRXs lately and I have to say I've been incredibly impressed with the performance... I recently did some performance testing on the SRX 5600s and I was able to consistently observe it instantiating upwards of 150k new TCP sessions per second. Does the SRX have some bugs... sure... that is to be expected with a box which by all means is still relatively bleeding edge. I'm fairly confident given a little time to stabilize the code, they will be able to fix some of the obstacles you are describing above... Having said that, I always laugh when I'm working with customers who have been DoSed and their response is "Well, our firewall/load balancer has DDoS mitigation capabilities...". Almost every firewall or load balancer device I've worked with (Netscreen, SRX, Brocade, Fortinet) that had any sort of DoS mitigation features was extremely limited in its capability. Most only do session-based limiting towards a given destination IP, with the ultimate result being that they simply rate-limit the traffic towards that destination. This in itself ends up completing the attackers goal of denying service (even if just a subset) towards a given IP. And these types of features do nothing to assist with low-level attack traffic which require surgical mitigation, not to mention a host of other attack vectors. Firewalls do have their place in DDoS mitigation scenarios, but if used as the "ultimate" solution you're asking for trouble. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
On Jan 9, 2010, at 9:57 PM, Stefan Fouant wrote:
Firewalls do have their place in DDoS mitigation scenarios, but if used as the "ultimate" solution you're asking for trouble.
In my experience, their role is to fall over and die, without exception. I can't imagine what possible use a stateful firewall has being placed in front of servers under normal conditions, much less during a DDoS attack; it just doesn't make sense. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
-----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Saturday, January 09, 2010 10:03 AM
On Jan 9, 2010, at 9:57 PM, Stefan Fouant wrote:
Firewalls do have their place in DDoS mitigation scenarios, but if used as the "ultimate" solution you're asking for trouble.
In my experience, their role is to fall over and die, without exception. I can't imagine what possible use a stateful firewall has being placed in front of servers under normal conditions, much less during a DDoS attack; it just doesn't make sense.
See the earlier post - what I'm referring to here is more along the lines of stateless packet filters on upstream routers which can be triggered via Flowspec or similar mechanisms... I'm not disagreeing with you here on the other points and largely concur. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
We should circle up one day, I would love to provide you with some new experiences. There is no sense in chalk talking it, too often I also disagree with new ideas until I see them in action. Best regards, Jeff On Sat, Jan 9, 2010 at 10:03 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
In my experience, their role is to fall over and die, without exception. I can't imagine what possible use a stateful firewall has being placed in front of servers under normal conditions, much less during a DDoS attack; it just doesn't make sense.
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."
On Jan 10, 2010, at 12:57 AM, Jeffrey Lyon wrote:
I would love to provide you with some new experiences.
I get new experiences of this type and plenty of new ideas every day, thanks. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
What Roland said, I've seen people do this, no rules in place, still was able to kill the box (firewall) with a single CPU server. -jim On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation tool.
Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie <deleskie@gmail.com> wrote:
What Roland said, I've seen people do this, no rules in place, still was able to kill the box (firewall) with a single CPU server.
not to pile on, but... +1 to roland here as well. I've seen more than enough folks put in a 'firewall' in front of their 'server' (say a mail server) and then watch that die long before the rest of the system did. Now, if you have equipment capable today of doing a few million session creates/second and you feel comfortable that you can keep track of how attacks grow vs your capacity stays the same and move ahead of the curve well enough, then... by all means do as you want :) There's a cost analysis which Roland sidestepped here as well, state-tracking at the rates required is expensive, as compared to relatively simple acls in hardware with no state on the upstream router. Spend where it matters, and make sure you understand where the failure points are that you place into your network. -chris
-jim
On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation tool.
Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
A lot of this has to do with scaling the environment. I've had plenty of asa's and even netscreens fall over from state-table and session limitations. I've also seen a hosts fill up the connection table prior to a firewall being affected. I'm not familiar with the specs and anyone can chime in, but the newer variety of SRX's, I believe implement more in hardware as line-rate routers do. A layered approach is useful as well. If the source can be identified via netflow and null routed before it gets to the firewall and content layer, then all the better. This is much more tricky with DDOS so having robust firewall that can eat traffic is helpful. My 3 cents -b On Mon, Jan 4, 2010 at 7:35 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie <deleskie@gmail.com> wrote:
What Roland said, I've seen people do this, no rules in place, still was able to kill the box (firewall) with a single CPU server.
not to pile on, but... +1 to roland here as well. I've seen more than enough folks put in a 'firewall' in front of their 'server' (say a mail server) and then watch that die long before the rest of the system did.
Now, if you have equipment capable today of doing a few million session creates/second and you feel comfortable that you can keep track of how attacks grow vs your capacity stays the same and move ahead of the curve well enough, then... by all means do as you want :)
There's a cost analysis which Roland sidestepped here as well, state-tracking at the rates required is expensive, as compared to relatively simple acls in hardware with no state on the upstream router.
Spend where it matters, and make sure you understand where the failure points are that you place into your network.
-chris
-jim
On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation tool.
Absolutely not - the firewall will fall over due to state-table
exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
-- Bill Blackford Network Engineer
Rick, If you pass me your contact info I can forward it to our Arbor Sales guy who can get in touch with you. I been pretty impressed by Arbor so far. Thanks, Raj Singh -----Original Message----- From: Rick Ernst [mailto:nanog@shreddedmail.com] Sent: Monday, January 04, 2010 1:20 PM To: NANOG Subject: D/DoS mitigation hardware/software needed. Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core. I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives. My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH. Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed. I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases. Thanks, Rick
Several responses already, and Arbor has poked their head up. I'm going to start there and keep the other suggestions at-hand. Thanks, On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH.
Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed.
I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases.
Thanks, Rick
Ask them if they'd come down to $10 - 20k for a full featured model and they might make two sales, although I doubt it unfortunately. Best regards, Jeff On Mon, Jan 4, 2010 at 4:59 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Several responses already, and Arbor has poked their head up.
I'm going to start there and keep the other suggestions at-hand.
Thanks,
On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH.
Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed.
I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases.
Thanks, Rick
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."
If you want to recreate D/DoS from captures (for testing purposes) you might want to check out: http://www.pcapr.net/dos This lets you validate how your mitigation solutions are holding up. K. On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH.
Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed.
I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases.
Thanks, Rick
On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
- Outsource to service provider Netflow can lag a bit in detection. I'd be concerned that inline devices
add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
How often are you getting DDoS'd? The financials of using a managed service provider vs. buy-all-your-own-grrovy-stuff can be fairly compelling especially if the amount of DDoS you experience is almost nil. Re: Arbor. I don't have any recent experience, but they've been around for a long time, have a very experienced team that understands ISP and enterprise and the product is mature. Hard to go wrong if you can justify the costs. YMMV. Best, -M< -- Martin Hannigan martin@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
I looked at one of the suggested out-sourced providers. Based on a sample size of 1, the mitigating mechanisms are DNS redirection and BGP/tunneling. While both of these solutions may be useful for an end-user (even large ones), I don't see them fitting in an SP environment. "If something goes wrong, I want my own, local, big-red button." Rick On Tue, Jan 5, 2010 at 7:50 AM, Martin Hannigan <martin@theicelandguy.com>wrote:
On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst <nanog@shreddedmail.com> wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core.
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
- Outsource to service provider
Netflow can lag a bit in detection. I'd be concerned that inline devices
add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives.
How often are you getting DDoS'd?
The financials of using a managed service provider vs. buy-all-your-own-grrovy-stuff can be fairly compelling especially if the amount of DDoS you experience is almost nil.
Re: Arbor. I don't have any recent experience, but they've been around for a long time, have a very experienced team that understands ISP and enterprise and the product is mature. Hard to go wrong if you can justify the costs. YMMV.
Best,
-M<
-- Martin Hannigan martin@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Martin Hannigan wrote on 05/01/10 16:50:
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
- Outsource to service provider
I want to add some stuff on this as I didn't see them with a quick check on the thread. Local solution always have a limit as bandwith will be exhausted before goin into your solution/network. Outsourced services have higher cost than Arbor but can handled more. Known leader of the clean-pipe solution is Prolexic http://www.prolexic.com/ Akamai and Verisign also tries to go on this market http://www.akamai.com/security (through CDN) http://www.verisign.com/internet-defense-network/index.html Best regards, Julien
On Mon, Jan 11, 2010 at 12:26 AM, jul <jul_bsd@yahoo.fr> wrote:
Martin Hannigan wrote on 05/01/10 16:50:
I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device
- Outsource to service provider
I want to add some stuff on this as I didn't see them with a quick check on the thread. Local solution always have a limit as bandwith will be exhausted before goin into your solution/network.
Outsourced services have higher cost than Arbor but can handled more.
Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k. There are decent outsourced solutions, that move the problem out of your network, scrub traffic as requested, give you the ability to send traffic there on-demand (without calling the provider) and actually do work. All at a cost that's more than reasonable if your business depends upon the Internets. -chris
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul <jul_bsd@yahoo.fr> wrote:
Martin Hannigan wrote on 05/01/10 16:50:
Outsourced services have higher cost than Arbor but can handled more.
Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k.
Don't forget to factor in OpEx. This can often tilt the scales in favor of one vs. the other. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
I thought I had mentioned outsourcing earlier, but I don't see it in the thread... The two mechanisms I've seen for outsources D/DoS are DNS manipulation, or essentially remote BGP peering with an tunnel back to the local presence. Even if we are purely hosting, DNS manipulation doesn't do anything for attacks against an IP. For remote BGP peering/tunneling, you are are adding additional complexity and moving control outside your network. As a service-provider/data-center, it seems like outsourcing would be either ineffective and/or removes the "big red button" in case of trouble. Am I missing something, overly paranoid, or are there other mechanisms for outsourced protection? Rick On Mon, Jan 11, 2010 at 6:33 AM, Stefan Fouant < sfouant@shortestpathfirst.net> wrote:
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul <jul_bsd@yahoo.fr> wrote:
Martin Hannigan wrote on 05/01/10 16:50:
Outsourced services have higher cost than Arbor but can handled more.
Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k.
Don't forget to factor in OpEx. This can often tilt the scales in favor of one vs. the other.
Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
-----Original Message----- From: Rick Ernst [mailto:nanog@shreddedmail.com] Sent: Monday, January 11, 2010 10:39 AM To: NANOG Subject: Re: D/DoS mitigation hardware/software needed.
As a service-provider/data-center, it seems like outsourcing would be either ineffective and/or removes the "big red button" in case of trouble.
Am I missing something, overly paranoid, or are there other mechanisms for outsourced protection?
In fact, quite the opposite. Those providers who do offer DDoS mitigation services usually allow the customer to trigger the redirect in a manner similar to RTBHs by substituting the blackhole community for some type of mitigation community. This causes the Provider's edge router (or Route Server) to advertise the affected route within the Service Provider's network with a next-hop of the scrubbers. There are some providers who do auto-mitigation on behalf of the customer, but IMO this approach is asking for trouble. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Right. Some providers allow you to BGP community trigger RTBH. There was a separate mention of D/DoS-mitigation-providers using DNS and BGP tunneling. Rick On Mon, Jan 11, 2010 at 8:14 AM, Stefan Fouant < sfouant@shortestpathfirst.net> wrote:
-----Original Message----- From: Rick Ernst [mailto:nanog@shreddedmail.com] Sent: Monday, January 11, 2010 10:39 AM To: NANOG Subject: Re: D/DoS mitigation hardware/software needed.
As a service-provider/data-center, it seems like outsourcing would be either ineffective and/or removes the "big red button" in case of trouble.
Am I missing something, overly paranoid, or are there other mechanisms for outsourced protection?
In fact, quite the opposite. Those providers who do offer DDoS mitigation services usually allow the customer to trigger the redirect in a manner similar to RTBHs by substituting the blackhole community for some type of mitigation community. This causes the Provider's edge router (or Route Server) to advertise the affected route within the Service Provider's network with a next-hop of the scrubbers.
There are some providers who do auto-mitigation on behalf of the customer, but IMO this approach is asking for trouble.
Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
On Mon, Jan 11, 2010 at 9:33 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul <jul_bsd@yahoo.fr> wrote:
Martin Hannigan wrote on 05/01/10 16:50:
Outsourced services have higher cost than Arbor but can handled more.
Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k.
Don't forget to factor in OpEx. This can often tilt the scales in favor of one vs. the other.
sure, but just capex alone the 'make vzb do this' option wins. (I think at least, I'm not a math guy though...)
Precisely - I was saying that in order to add more point to your argument. I wasn't disagreeing with you :) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
-----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow Sent: Monday, January 11, 2010 12:49 PM To: Stefan Fouant Cc: jul; NANOG Subject: Re: D/DoS mitigation hardware/software needed.
On Mon, Jan 11, 2010 at 9:33 AM, Stefan Fouant <sfouant@shortestpathfirst.net> wrote:
-----Original Message----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul <jul_bsd@yahoo.fr> wrote:
Martin Hannigan wrote on 05/01/10 16:50:
Outsourced services have higher cost than Arbor but can handled more.
Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k.
Don't forget to factor in OpEx. This can often tilt the scales in favor of one vs. the other.
sure, but just capex alone the 'make vzb do this' option wins. (I think at least, I'm not a math guy though...)
On Mon, 11 Jan 2010, jul wrote:
Known leader of the clean-pipe solution is Prolexic http://www.prolexic.com/
Akamai and Verisign also tries to go on this market http://www.akamai.com/security (through CDN) http://www.verisign.com/internet-defense-network/index.html
Indeed, these 3 also ended up on my shortlist after much research. Each has areas they are weaker in than their competitors but they are all worthy. -Hank
-----Original Message----- From: Hank Nussbacher [mailto:hank@efes.iucc.ac.il] Sent: Monday, January 11, 2010 4:40 AM To: jul Cc: NANOG Subject: Re: D/DoS mitigation hardware/software needed.
On Mon, 11 Jan 2010, jul wrote:
Known leader of the clean-pipe solution is Prolexic http://www.prolexic.com/
Akamai and Verisign also tries to go on this market http://www.akamai.com/security (through CDN) http://www.verisign.com/internet-defense-network/index.html
Indeed, these 3 also ended up on my shortlist after much research. Each has areas they are weaker in than their competitors but they are all worthy.
If you're connected to Level 3 in any capacity, they have a reseller agreement with Prolexic and can offer REALLY aggressive pricing. I really liked their offering. If anyone is interested, I did pretty exhaustive research into the Service Provider marketplace last summer (before Verisign came out with their VIDN). I've got some slides which outline the costs, mitigation capacity, etc. of many different providers. The provider option isn't always the cheapest when compared to DIY factored in over a 3-5 year lifespan. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Stefan Fouant wrote on 11/01/10 14:45:
If anyone is interested, I did pretty exhaustive research into the Service Provider marketplace last summer (before Verisign came out with their VIDN). I've got some slides which outline the costs, mitigation capacity, etc. of many different providers. The provider option isn't always the cheapest when compared to DIY factored in over a 3-5 year lifespan.
If you can share, I think everyone would be interested. I am :)
Ummm... there is some proprietary information I would have to remove first. Will NANOG accept a message to the forum with an attachment? If not I can put it up on my site. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
-----Original Message----- From: jul [mailto:jul_bsd@yahoo.fr] Sent: Monday, January 11, 2010 4:58 PM To: Stefan Fouant Cc: 'Hank Nussbacher'; 'NANOG' Subject: Re: D/DoS mitigation hardware/software needed.
Stefan Fouant wrote on 11/01/10 14:45:
If anyone is interested, I did pretty exhaustive research into the Service Provider marketplace last summer (before Verisign came out with their VIDN). I've got some slides which outline the costs, mitigation capacity, etc. of many different providers. The provider option isn't always the cheapest when compared to DIY factored in over a 3-5 year lifespan.
If you can share, I think everyone would be interested. I am :)
participants (16)
-
Adrian Chadd -
Bill Blackford -
Christopher Morrow -
Dobbins, Roland -
Hank Nussbacher -
Jeffrey Lyon -
jim deleskie -
jul -
kowsik -
Martin Hannigan -
Raj Singh -
Rick Ernst -
Stefan Fouant -
Steve Bertrand -
Tim Eberhard -
Łukasz Bromirski