Wow, lots of things to think about....
I see "J"'s point of putting a DoS stopper at my upstream provider. We're
running a pair of T1's right now, with another pair for failover. From one
perspective, all it would take to effectively DoS us is 3Mbits/sec of
traffic. I generate that when I fart.
But seriously, while the Captus box may keep that from making the leap from
my CSU to network, what good is it if my T1's are saturated? I'm running
GigE internally; why do I care about 3 or 4 Mbits of traffic, DoS or not?
Yes, we definetely require an upstream solution of some kind. If I could
just shut off traffic *floods* before they reach my T1's.....
RB
On Sat, 9 Jun 2001 02:59:14 -0400, [EMAIL PROTECTED] wrote:
> DDoS....Distributed Denial of Service. Keyword - Distributed. I am
wary
> of any company that claims they have a device that can combat a DDOS.
You
> would need a distributed solution to combat a distributed attack. On top
of
> that, how do you fight an attack on someone else's network? You can put
> devices all over your network, but at some point you connect to someone
> else's network. If that connection is flooded, you are still knocked off
> the net.
>
> While you may have successfully kept the DDOS off your network, you
haven't
> stopped it. At this point, I don't think DDOS can be stopped. The DDOS
can
> be managed, but the solutions aren't clean.
>
> Jason Lewis
> http://www.packetnexus.com
> It's not secure "Because they told me it was secure". The people at the
> other end of the link know less about security than you do. And that's
> scary.
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonas Luster
> Sent: Friday, June 08, 2001 9: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.]
_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
