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
-Original Message-
From: Hank Nussbacher [mailto:h...@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
-Original Message-
From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul jul_...@yahoo.fr wrote:
Martin Hannigan wrote on 05/01/10 16:50:
Outsourced services have higher cost than Arbor but can
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
-Original Message-
From: Rick Ernst [mailto:na...@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
On Mon, Jan 11, 2010 at 9:33 AM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
Sent: Monday, January 11, 2010 2:05 AM
On Mon, Jan 11, 2010 at 12:26 AM, jul jul_...@yahoo.fr wrote:
Martin Hannigan wrote
] 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
sfou...@shortestpathfirst.net wrote:
-Original Message-
From: Christopher
On Mon, Jan 11, 2010 at 1:12 PM, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
Precisely - I was saying that in order to add more point to your argument.
I wasn't disagreeing with you :)
i need more coffee :( thanks!
-Chris
[mailto:na...@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
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.
[mailto:jul_...@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
Firewalls do a good job of protecting servers, when properly configured,
because they are designed exclusively for the task. Their CAM tables,
realtime ASICs and low latencies are very much unlike the CPU-driven,
interrupt-bound hardware and kernel-locking, multi-tasking software on a
Then you need to get rid of that '90's antique web server and get
something modern. When you say interrupt-bound hardware, all you
are doing is showing that you're not familiar with modern servers
and quality operating systems that are designed to mitigate things
like DDoS attacks.
Modern
Dobbins, Roland wrote:
My employer's products don't compete with firewalls, they *protect* them;
if anything, it's in my pecuniary interest to *encourage* firewall
deployments, so said firewalls will fall down and need protection, heh.
Nobody's disputing that Roland, or the fact that different
Then you need to get rid of that '90's antique web server and get
something modern. When you say interrupt-bound hardware, all you
are doing is showing that you're not familiar with modern servers
and quality operating systems that are designed to mitigate things
like DDoS attacks.
2010 08:55:13
To: nanog@nanog.org
Subject: Re: D/DoS mitigation hardware/software needed.
Dobbins, Roland wrote:
My employer's products don't compete with firewalls, they *protect* them;
if anything, it's in my pecuniary interest to *encourage* firewall
deployments, so said firewalls will fall
On Sun, 10 Jan 2010 08:19:27 PST, Roger Marquis said:
Then you need to get rid of that '90's antique web server and get
something modern. When you say interrupt-bound hardware, all you
are doing is showing that you're not familiar with modern servers
and quality operating systems that are
On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote:
The only thing you've said that is being disputed is the the claim that a
firewall
under a DDoS type of attack will fail before a server under the same type
of attack.
It's so obvious that well-crafted programmatically-generated attack
From: Dobbins, Roland rdobb...@arbor.net
Date: Sun, 10 Jan 2010 21:56:38 +
On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote:
The only thing you've said that is being disputed is the the claim
that a firewall under a DDoS type of attack will fail before a
server under the same
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
On Mon, Jan 11, 2010 at 12:26 AM, jul jul_...@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
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
-Original Message-
From: Łukasz Bromirski [mailto:luk...@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
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
-Original Message-
From: Dobbins, Roland [mailto:rdobb...@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
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 rdobb...@arbor.net wrote:
In my
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 rdobb...@arbor.net
Dobbins, Roland 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.
That hasn't been my experience but then I'm not selling anything that
On Jan 10, 2010, at 9:03 AM, Roger Marquis wrote:
That hasn't been my experience but then I'm not selling anything that might
have a lower ROI than firewalls, in small to mid-sized installations.
I loudly evinced this position when I worked for the world's largest firewall
vendor, so that
Dobbins, Roland wrote:
Firewalls are not designed to mitigate large scale DDoS, unlike
Arbors, but they do a damn good job of mitigating small scale
attacks of all kinds including DDoS.
Not been my experience at all - quite the opposite.
Ok, I'll bite. What firewalls are you referring to?
On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote:
Ok, I'll bite. What firewalls are you referring to?
Hardware-based commercial firewalls from the major vendors, open-source/DIY,
and anything in between. All stateful firewalls ever made, period (as
discussed previously in the thread).
On Sat, Jan 9, 2010 at 10:21 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote:
Have you noticed how easily Drupal servers go down with corrupt MyISAM
tables? How would S/RTBH and/or flow-spec protect against that?
We're talking about DDoS
On Jan 10, 2010, at 10:33 AM, Christopher Morrow wrote:
separate the portions of the pie... only let the attack break the minimal
portion of your deployment. Use the right tool in the right place.
An excellent point. A Web front-end server should be that - merely the
front-end.
Dobbins, Roland wrote:
See here for a high-profile example:
http://files.me.com/roland.dobbins/k54qkv
Reads like a sales pitch to me. No apples to apples comparisons, nothing
like an ANOVA of PPS, payload sizes, and other vectors across different
types of border defenses. Your presentation
Firewalls are not designed to mitigate large scale DDoS,
Generally speaking, if it didn't being the firewall to its knees, it
wasn't a DoS. It was just sort of an annoying attempt at a DoS.
I think that more or less the definition of a DoS is one that exploits
the resource limitations of
On Jan 10, 2010, at 1:27 PM, Roger Marquis wrote:
Reads like a sales pitch to me.
My employer's products don't compete with firewalls, they *protect* them; if
anything, it's in my pecuniary interest to *encourage* firewall deployments, so
said firewalls will fall down and need protection,
At 13:19 05/01/2010 +, 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
On Wed, 2010-01-06 at 17:00 +0200, Hank Nussbacher wrote:
In that case, how do you run your current service:
http://www.vialtus.com/en/Solutions/Hosting-and-Datacentre-Services/Security-Solutions/Distributed-Denial-of-Service-Protection.aspx
It says how, right on that page. Not Arbor.
Graeme
* Adrian Chadd:
Has anyone deployed a DDoS distributed enough to inject ETOOMANY routes into
the hardware forwarding tables of routers?
I think this is called injecting the BGP table into your IGP, and
quite a few folks have done it. Nobody claimed that it was an act of
sabotage, though.
--
I know of several companies, with large websites, that used code reviews as
at least one way they met this DSS requirement. So, erm, empirically
denied.
The PCI DSS does not require code review of the software running in COTS
equipment, nor of underlying OS's or applications. It requires a code
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
Comments inline.
To reiterate- my entire point is that stateful firewalls are at least
sometimes useful in front of large websites. Something of a veer off of the
original topic, but not an at all useless exercise IMHO.
On Mon, Jan 4, 2010 at 11:47 PM, Dobbins, Roland rdobb...@arbor.net wrote:
My basis for this is discussions with PCI assessors from multiple firms that
perform large numbers of assessments per year.
Next time I run into some, I'll ask to see if the usage has increased, its
been a few months since I asked this of any of them.
--D
On Tue, Jan 5, 2010 at 1:02 AM,
On Jan 5, 2010, at 5:04 PM, Darren Bolding wrote:
To reiterate- my entire point is that stateful firewalls are at least
sometimes useful in front of large websites.
I understand completely; I simply disagree, stating my reasons for doing so in
detail inline. It's my contention that under
(Resent, sorry for multiple copies -- I messed up from From: address)
On 5 Jan 2010, at 06:16, Stefan Fouant wrote:
That said, what are all those ISPs doing now that Cisco has stopped
developing the Guard?
Well of course, moving to Arbor haha... eased in part by a little Cisco
initiative
My somewhat educated opinion on the matter is that appliance developers want
to sit on the edge and see all your traffic merely to protect their own
interests and market share.
NS-5000s have been good to us for bulk filtering and we rely on appliances
for more intelligent inspection. Dollar for
On Jan 5, 2010, at 9:59 PM, Jeffrey Lyon wrote:
My somewhat educated opinion on the matter is that appliance developers want
to sit on the edge and see all your traffic merely to protect their own
interests and market share.
This isn't generally a smart approach; the value of providing
On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst na...@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
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
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
On Tue, 5 Jan 2010 04:20:51 +
Dobbins, Roland rdobb...@arbor.net wrote:
S/RTBH and/or flow-spec are great DDoS mitigation tools which don't
require any further investment beyond the network infrastructure an
operator has already purchased and deployed. These should be the
first
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
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
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
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 na...@shreddedmail.com wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned
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 na...@shreddedmail.com wrote:
Several responses already, and Arbor has poked their head up.
I'm
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
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
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 rdobb...@arbor.net wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a
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 na...@shreddedmail.com wrote:
Looking for D/DoS
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
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
We have such a configuration in progress, it works great without any of the
issues you're proposing.
Jeff
On Jan 4, 2010 9:09 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: Use a robust firewall such
as a Netscreen in fro...
Absolutely not - the
On Tue, Jan 5, 2010 at 8:36 AM, Jeffrey Lyon
jeffrey.l...@blacklotus.net wrote:
We have such a configuration in progress, it works great without any of the
issues you're proposing.
So .. this is interesting.
The firewall would have to frontend your mail / web / whatever
application .. and if
On Jan 5, 2010, at 10:14 AM, Dobbins, Roland wrote:
If it's a stateful firewall, and state-tracking is turned on, it's quite
possible to craft sufficient pathological traffic which conforms to the
firewall policies and yet which leads to state-table inspection.
That should read
On Jan 5, 2010, at 10:06 AM, Jeffrey Lyon wrote:
We have such a configuration in progress, it works great without any of the
issues you're proposing.
Then you aren't testing it to destruction, heh.
;
If it's a stateful firewall, and state-tracking is turned on, it's quite
possible to
Two more options. And for Netflow device - read that to mean Arbor or
its competitors.
5 Ditch the stateful firewall and exclusively use a netflow device
6. Outsource to a hosted DDoS mitigation service (Prolexic etc)
On Tue, Jan 5, 2010 at 8:43 AM, Suresh Ramasubramanian
ops.li...@gmail.com
On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote:
5 Ditch the stateful firewall and exclusively use a netflow device
NetFlow analysis is very useful for network visibility, and
detection/classification/traceback. There are both open-source and commercial
NetFlow collection and
On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie deles...@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
1. We have multiple nodes conducting DDoS scrubbing, one failing would not
be catastrophic.
2. Indeed.
3. Sort of, such devices are downstream for extremely valid reasons I won't
get into now.
4. Indeed, were equipped to handle substantially higher than 150kpps.
I'm sure Arbor is really neat
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,
With these safeguards in place - and with flow devices being part of
the mix somewhere .. what you propose is quite reasonable.
There's still the question of whether an application that receives a
lot of new / untrusted traffic - a mail or web server - would benefit
from having a stateful
On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote:
I'm sure Arbor is really neat but I disagree that any DDoS appliance is a
standalone solution.
I disagree with this proposition, too.
S/RTBH and/or flow-spec are great DDoS mitigation tools which don't require any
further investment beyond
On Mon, Jan 4, 2010 at 11:20 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote:
I'm sure Arbor is really neat but I disagree that any DDoS appliance is a
standalone solution.
I disagree with this proposition, too.
S/RTBH and/or flow-spec are
On Jan 5, 2010, at 11:41 AM, Christopher Morrow wrote:
(note I think Roland may have been party to some of the presenations I linked
in this...
Yes, sir, and thanks for posting those links! You and Barry and Tim Battles
and Sean Donelan and Danny McPherson and Don Smith and Steve Bellovin
On Tue, Jan 5, 2010 at 10:35 AM, Rick Ernst na...@shreddedmail.com wrote:
I'm interested in seeing products (including software) that already have the
development (anomaly detection, trends/reports, etc.) work done so I can
spend my cycles elsewhere.
This might fit the bill -
On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote:
A solution preferably that integrates with NetFlow and RTBH. An in-line
solution obviously requires an appliance, or at least special/additional
hardware.
The key is to not be inline all the time, but only inline *when needed*. This
On Mon, Jan 4, 2010 at 9:08 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote:
A solution preferably that integrates with NetFlow and RTBH. An in-line
solution obviously requires an appliance, or at least special/additional
hardware.
The key
On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland rdobb...@arbor.net wrote:
Additional mitigation would be via manual or automatic RTBH or
security/abuse@ involvement with upstreams.
Automagic is generally bad, as it can be gamed.
... and manual wont scale in ddos
--
Suresh
-Original Message-
From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
Sent: Monday, January 04, 2010 11:41 PM
The original poster seemed to be asking about appliance based
solutions, so your pointed remarks about Roland aside he was actually
answering the question. I wonder
On Jan 5, 2010, at 12:19 PM, Suresh Ramasubramanian wrote:
... and manual wont scale in ddos
Actually, it can and does.
;
I'm referring to the employment and selection of situationally-appropriate
tools, mind. The tools themselves must of necessity perform their work in a
largely
On Jan 5, 2010, at 12:19 PM, Rick Ernst wrote:
I'd argue just the opposite. If your monitoring/mitigation system changes
dependent on the situation (normal vs under attack), you are adding
complexity to the system.
What mode is the system in right now? Is this customer having
-Original Message-
From: Rick Ernst [mailto:na...@shreddedmail.com]
Sent: Tuesday, January 05, 2010 12:19 AM
I'd argue just the opposite. If your monitoring/mitigation system
changes
dependent on the situation (normal vs under attack), you are adding
complexity to the system.
On Tue, Jan 5, 2010 at 10:52 AM, Dobbins, Roland rdobb...@arbor.net wrote:
I'm referring to the employment and selection of situationally-appropriate
tools, mind. The tools themselves must of necessity perform their work in a
largely automated fashion once they're employed, which is what I
On Tue, Jan 05, 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an offramp method.
These devices perform a lot better when you can forward just the subset of
the traffic through as opposed to
I think you, Roland, and I are all agreeing on the same argument.
The (my) confusion entered with the statement of, The key is to not be
inline all the time, but only inline *when needed*.
I inferred a topological or physical path change from that.
Redirecting traffic (which is really just an
-Original Message-
From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com]
Sent: Tuesday, January 05, 2010 12:19 AM
On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland rdobb...@arbor.net
wrote:
Additional mitigation would be via manual or automatic RTBH or
security/abuse@
On Jan 5, 2010, at 12:39 PM, Adrian Chadd wrote:
I mean, I assume that there's checks and balances in place to limit
then number of routes being injected into the network so one doesn't
overload the tables, but what's the behaviour if/when this limit is
reached? Does mitigation cease being
On Jan 5, 2010, at 12:39 PM, Stefan Fouant wrote:
The trick is to try to automate as much around the process as possible - I've
worked in environments where just making little changes to incident handling
response methods reduced the time to mitigate an attack from hours to
minutes, all
On Jan 5, 2010, at 12:39 PM, Rick Ernst wrote:
I think you, Roland, and I are all agreeing on the same argument.
GMTA.
;
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
Injustice is relatively easy
On Jan 5, 2010, at 11:57 AM, Dobbins, Roland wrote:
You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don
Smith and Steve Bellovin and Jared Mauch and John Kristoff and a lot of other
folks too numerous to mention
. . . including Paul Vixie, Darrel Lewis, Ryan
On Tue, 5 Jan 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an offramp method.
These devices perform a lot better when you can forward just the subset of
the traffic through as opposed to
-Original Message-
From: Hank Nussbacher [mailto:h...@efes.iucc.ac.il]
Sent: Tuesday, January 05, 2010 1:02 AM
On Tue, 5 Jan 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an
I actually agree with most of this, but want to correct a clearly
inadvertent error below, and make a couple of points.
PCI DSS does not require a Web application firewall. It requires that OR
an independent audit of all code within PCI scope by a third party. If a
WAF is used, it only need be
On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
* Defense in depth. You've never had a host that received external traffic
ever accidentally have iptables or windows firewall turned off? Even when
debugging a production outage or on accident?
Again, policy should be enforced via
On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
PCI DSS does not require a Web application firewall.
http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1313797,00.html
Since no business is going to allow an external 'code review' (if it's even
possible, given that
96 matches
Mail list logo
