But, will anything make it past your network and their box when you are
under attack? If not, it's no better and at best only slightly different
then the router/FW solutions already suggested.
The point being; once the pipe is full, where are packets to go?
Thanks,
Ron Dufresne
On Sat, 9 Jun 2001, "J" wrote:
> 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.]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***
OK, so you're a Ph.D. Just don't touch anything.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
