D/DoS mitigation hardware/software needed.
rdobbins at arbor.net
Tue Jan 5 15:55:22 UTC 2010
On Jan 5, 2010, at 9:44 PM, Rob Shakir wrote:
> If you're an SP who has some existing NetFlow solution, and don't really justify a spend for traffic intelligence within your network (or have something home-grown), is there an alternative scrubber that one might be able to use in a more standalone deployment that can approach the filtering levels of the Arbor kit?
One thing folks can do is to implement S/RTBH and/or flow-spec at the edges, then take some Intel boxes, throw some high-performance network cards in them, along with Snort-inline, and put them in a scrubbing center, making use of BGP diversion/re-injection to get traffic into them on an as-needed basis. Don't make use of the useless bidirectional/stateful 'IPS' signatures, but do manual filtering on a case-by-case basis, unidirectionally.
Below that, put a layer of WCCPv2-clustered Squid proxies to provide additional layer-7 filtering capabilities for Web-based traffic.
Below that, re-inject the scrubbed traffic and send it on its way via one's redirection mechanism of choice to the destination servers.
Does this 'poor man's IDMS' do everything and scale to the degree of the various commercial systems? No, of course not. But it's a way to get into layer-4-plus dynamic DDoS mitigation in a relatively economical way (at least from a capex perspective); for some folks, this type of solution may prove sufficient to needs, keeping in mind the limitations of this approach and the systems integration/support burden involved, of course.
And even if/when it's clear more advanced capabilities are needed, starting out this way, even in a limited PoC, provides valuable operational experience with the diversion/re-injection model which will prove useful in evaluating more advanced commercial systems an an appropriate juncture.
> I should probably point out that we only really started our conversation with Arbor within the last month or so, so there are perhaps details relating to this that I've missed. I'd be happy to be corrected!
There's actually quite a bit more, but short of answering specific questions in an operational context, this kind of vendor-specific discussion is probably well beyond what vendor employees like me (these strictures don't apply to anyone else, mind) can and should in all propriety participate in on nanog-l; please feel free to reach out 1:1 to the Arbor folks you've already been talking with to discuss further, and I'm happy to help out 1:1, as well.
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
More information about the NANOG