Jonas and group:
I encourage you to examine Captus Networks' solution. Their box stops DoS
attacks (from passing their box to your network.) I/We've been testing it
for about two weeks now. It really does what they say.
Yes, if your upstream provider (say, Pac Bell) isnt' protecting you, your T1
can saturate, effectively DoS'ng you. The traffic will not traverse their
box and make it to your network, however.
Best,
J
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jonas Luster
Sent: Friday, June 08, 2001 6:24 PM
To: [EMAIL PROTECTED]
Subject: Re: DDos Defenses
* R B sez:
: I'm an admin for ISP in California (yes, our lights are on, thank you!)
: looking for a DDoS protection device of some kind to offer our customers
(we
: specialize in infosec for financial institutions).
So, hold on! You deal in _infosec_ and still believe that dDoS can be
stopped by a _Device_?
I guess it has been said about a thousand times on this list and others,
but let me just re-iterate:
* dDoS - if packet based - comes along with link-saturation and CPU
problems. A device to stop this kind of attack is known to the world
as router and should be used accordingly. Of course it needs to be the
router between the part of the network that is unfaced by such attacks
and the part of the 'net that is, so I suggest putting it on the
borders of your network (or your ISPs network if all you got is
smaller than an OC3). There is no device you can plug in on a T1 and
'zwapp! saturation in front of device be gone'.
* dDos that is packet-content based can be filtered by firewalls and
routers. If you use Cisco as your router be sure to spread your ACLs
between two routers since Cisco can only fo IP or Port based
filtering, not both on the same ACL.
This kind of inspection is kinda resource intensive, tho, so it might
be a point for DoS in its own.
* DoS that is application based can be filtered on Application Layer
Firewalls. Same caveats than for packet-content attacks apply, it's
pretty easy to DoS a Raptor-FW, for example, if you know how to. Best
bet here would be a change in application strategies or extra layers
of protection between the application and the border.
This one's not a 'distributed' DoS attack per se but could be (and has
been) executed via distributed clients/agents.
It's actually pretty simple:
Keep your own lines clean by imposing rate limits and pre-filtering on
the borders. Multihome and make sure you're sufficiently backed by your
upstreams. Add layers of protection between applications that are
DoSeable (such as IIS, Exchange, some Unix-Servers, etc.).
None of those can be possible done one a ``Device'', I'm sorry to say.
: Anyone aware of a product that's available NOW? I know Mazu doesn't have a
: product shipping, and neither does Asta. Any ideas?
Mazu has the right approach, but unless I've seen more than the Exodus
labtests, I am sceptic:
| Mazu protects against distributed denial-of-service attacks via
| intelligent traffic analysis and filtering distributed throughout the
| network. Mazu devices constantly analyze traffic, looking for network
| behavior that indicates the onset of a DDoS attack. The devices
| collaborate to obtain a broad picture of network traffic patterns: they
| can detect an attack, help to identify its source, and stop it as near
| its origin as possible. Mazu's distributed analysis dramatically
| improves the speed and accuracy with which attacks are detected and
| stopped. Emphasis on the underlying characteristics of a DoS attack
| results in a robust and comprehensive solution, one that differs
| significantly from a virus-protection-like approach that only stops
| previously seen attacks.
So, you actually need to own parts of the infrastructure to not only
notice but also fight this kind of attack. If you own the
infrastructure, you don't need an appliance since your standard
reporting will already include CPU spikes, link saturation and IDS
alerts. Mazu makes it easier for ISPs the size of Exodus to track
attacks and stop them as well as serve data to legal authorities. This
is being done today by engineers who do all that stuff Mazu does by
hand. The big Mazu advantage will be that it works much faster than an
Engineer setting Access-Lists. This solution is not for some
joe-random-T1 user without enable on the upstream router.
Asta does about the same, at least the approaches seem awfully similar.
In the end the fight will be decided by who drawas faster, e.g. who has
the more sophisticated detection engine and distributed tools.
Asta writes:
| To detect an attack, Asta Networks combines both misuse detection
| (signature analysis) and anomaly detection (statistical analysis).
| Signature analysis is used to look for the telltale signs of a known
| attack tool. To be robust against new attacks and prevent false
| positives, the coordinator also uses a variety of anomaly detection
| algorithms to confirm that an attack is taking place. These analyses
| compare observed behavior to models of acceptable network behavior to
| identify potential traffic anomalies or DoS attacks.
For the time being, you might find a similar solution by adding SNORT,
snmp-queries and standard router stat-tools together. Marry this
solution to a reporting and escalation tool, voila.
Asta further says:
| Having detected an attack, Asta Networks' technology computes a concise
| description of the attack and communicates this information to other
| sensors. Each sensor filters the traffic data according to dynamic
| criteria provided by the coordinator and periodically returns summaries
| to its coordinator describing the current traffic matrix. In a simple
| network, the coordinator may employ a process called traceback - a
| detection step repeated at all routers so that the path(s) used by the
| attack can be determined. At the same time, the coordinator also creates
| a picture of all the network devices that are participating in the
| attack, and the path it is taking through the network. Should the
| coordinator demand more detailed information, the Sensor also maintains
| important information about recent traffic flows in a data structure
| designed to allow efficient multi-dimensional queries.
This is - again - the equivalent to some Engineer doing his job. It's
definitely doing this job better than the engineer, but a similar
solution has been proposed by me and Aaron Jackobs at the 1998 SecCon in
NY, at that time based on snmp, a self-written anomaly detector and
Python/Expect to set Access-Lists and read the results. That way a
system is able to trace an attack from the point it hits (or shows up as
an anomaly) to the border router/peering session it comes in from. After
the sensors reach this point it's literally over. Asta and Mazu will
face the same problem.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
