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: firewalls-owner@Lists.GNAC.NET > [mailto:firewalls-owner@Lists.GNAC.NET]On Behalf Of Jonas Luster > Sent: Friday, June 08, 2001 6:24 PM > To: Firewalls@Lists.GNAC.NET > 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 majordomo@lists.gnac.net 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 majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.]