RE: DoS/DDoS Attack

• Previous message: miguel.dilaj_at_pharma.novartis.com: "Re: priviledge escalation techniques"
• In reply to: Steven: "Re: DoS/DDoS Attack"
• Next in thread: Barrie Dempster: "Re: DoS/DDoS Attack"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: "'Steven'" <steven@lovebug.org>, <pen-test@securityfocus.com>
Date: Tue, 18 Jan 2005 13:07:33 -0500

For sure, some could! I have a client who has been regularly getting
packets from 127.0.0.1.....uh, Mr. ISP, we shouldn't be getting them.
The ISP is hesitant to block that traffic because of unknown
ramifications. I really should push the idea. When they first told me
that, I understood them to be saying that they didn't want to just
rashly throw and ACL on their core equipment because they didn't want to
jeopardize up-time. Well, that's well over 6 months ago.

-----Original Message-----
From: Steven [mailto:steven@lovebug.org]
Sent: Saturday, January 15, 2005 12:03 PM
To: pen-test@securityfocus.com
Subject: Re: DoS/DDoS Attack

Would it not be safe to say that a large amount of this issue could be
mitigated if ISPs and/or those links above them took a more responsible
approach to packet handling? Wouldn't the whole issue (problem) of
spoofed
packets be handled if they were quashed at the start instead of the end?

Perhaps I don't understand enough here, but it seems that initially
routers/switches should have the capability to drop packets that could
not
have originated from their own network. If new equipment had the option
to
enforce this or had it automatically built in, would this not severely
mitigate some of this issue? Is there a reason why spoofed packets
should
be able to make their way off a LAN and across the world?

Perhaps this would only hold up so long until someone decided to make
all
DDoS spoof the packet from the same network but just a different host
address. Then maybe it would be possible to have the first router check
if
the source address of the packet exactly matches where it is actually
coming
from some how and not just that the network is valid.

Perhaps I just have a weak understanding of how this works and it cannot
be
solved so easily, but it appears that if that "some" of this is not so
hard
to stop. If what I have proposed is possibly and not being implemented
on a
wide scale, then why isn't it?

Steven

----- Original Message -----
From: "Faisal Khan" <faisal@netxs.com.pk>
To: <pen-test@securityfocus.com>
Sent: Friday, January 14, 2005 3:27 PM
Subject: RE: DoS/DDoS Attack

>
> Well I agree we are not helpless, we personally use the Top Layer box
and
> its worked wonders.....have a half a dozen of them deployed (the IPS
100
> that is). We are now looking into a HA/LB setup of the IPS 5500.
>
> The only thing that gets to me is when large DDoS attacks come in -
even
> with GigaE connectivity, sometimes the setup rates are so high - the
boxes
> have a hard time keeping up with it. In this respect the Foundry's
> ServerIron 850 is amazing. It has something called the Transaction
Rate
> Limiting, which we have configured for Port 80. If too many
transactions
> from a specific IP happen in a defined period (all parameters are set
by
> us), the device will instantly block the IP. For inquiring minds - the

> maximum we've experienced in a DDoS attack was about 240Mbps sustained

> coming in from what seemed to be a gazillion IPs. The attack lasted
about
> 2-3 days. Thank God for Foundry, which saved the day.
>
> What is truly frustrating is that the defences are at our perimeter -
> getting to the source I guess is just a Herculean task - I read
somewhere
> that there are between 60 Million to 120 Million zombies out there -
> cannot recall the source, but that's what I read.
>
> There are still many features that all the DDoS mitigation OEM have
not
> applied, that we have experienced and passed on as comments or as
> "wish-list" to the OEMs - I guess sooner or later someone will take
care
> of them.
>
> My 2 cents added to yours! :)
>
>
> FK
>
>
>
>
> At 11:46 PM 1/14/2005, you wrote:
>>I would agree with most of what's been said so far. However,
"helpless"
>>is
>>such a strong word. I don't know exactly what you're referring to,
but
>>you
>>are definitely not "helpless" from a security standpoint. There are a

>>host
>>of great DDoS/IPS appliances out there. I had a customer under a syn
>>flood
>>attack a while back, and they plopped down six figures on the spot to
buy
>>mitigation equipment. Since then, they have not experienced another
>>attack,
>>though we can see the device blocking several such occurences (albeit
>>smaller ones).
>>
>>FYI, my favorite rate-based IPS box is Top Layer. It works great, and
can
>>block gig speeds of bandwidth attacks. I've tested both the newest
Top
>>Layer and Tipping Point boxes and I have to say Top Layer takes the
cake.
>>The industry is constantly changing in this market, so you're bound to
see
>>new leaders all the time.
>>
>>My $.02,
>>
>>Ed
>>
>>-----Original Message-----
>>From: nvfeito@advancedsl.com.ar [mailto:nvfeito@advancedsl.com.ar]
>>Sent: Friday, January 14, 2005 6:10 AM
>>To: pen-test@securityfocus.com
>>Subject: Re: DoS/DDoS Attack
>>
>>On Friday 14 January 2005 06:06 am, Faisal Khan wrote:
>> > Folks,
>> >
>> > Two quick questions.
>> >
>> > When IP (Source) addresses are spoofed, is there no way of
determining
>> > (a) that the IP Source Addresses is spoofed and not the genuine one
>> > (b) to be able to determine the actual IP address that is sending
DoS
>>packets?
>> >
>> > Somehow I get the feeling I'm SOL when trying to find out the
>> > "genuine/actual" source IP address.
>> >
>> > If this is the case, then pretty much we all are helpless with
>> > DoS/DDoS attacks - considering one can write a script/program to
keep
>> > incrementing or randomly assigning spoofed source addresses in the
DoS
>> > packets being sent out.
>> >
>> > Faisal
>>
>>I can't think of a way of reversing the process, the experiments I've
done
>>with spoofed ip's have been done in C using raw sockets, some folks
tried
>>with python, the language is indiferent, but what you do is alter the
>>header
>>of the packet, and tell the kernel of the OS that there's no need to
add a
>>header to the packet you're sending, then the kernel just place the
packet
>>on the net with the data you filled in.
>>The main thing of a spoofed ip packet it's that you can fill the
fields
>>with
>>any info you want (of course it's important the checksum matches, this
is
>>one way you could know if the packet is spoofed, and if it's not and
the
>>checksum does not match, there's an error, so one way or another you
>>should
>>get rid of the packet), check this with ethereal or another protocol
>>analyzer.
>>In theory it should be no way of knowing what's the real source
address
>>(It's not like an smtp 'spoof' that you play with some rcpt to/mail
from
>>commands and you have the email headers added by the MTA), if you
think
>>about it a little bit, we're indeed helpless with DoS/DDoS attacks, if
by
>>that you mean syn floods and that kind of stuff, and if you dig
deeper,
>>you'll find out that if the operating system is in charge of stamping
the
>>ip
>>address to a packet and the OS itself it's sufficiently flexible to
let
>>you
>>do that from userspace, this is not considered a flaw, but a gift, the

>>main
>>problem is that not all people is this gift the way they should.
>>
>>
>>--
>>
>>Saludos.
>>Nazareno Vicente Feito
>
>
>
> Faisal Khan, CEO
> Net Access Communication
> Systems (Private) Limited
> ________________________________
>
> Network Security - Secure Web Hosting
> Managed Internet Services - Secure Email
> Dedicated Servers - Reseller Hosting
>
> Visit www.netxs.com.pk for more information.
>
>
>

• Previous message: miguel.dilaj_at_pharma.novartis.com: "Re: priviledge escalation techniques"
• In reply to: Steven: "Re: DoS/DDoS Attack"
• Next in thread: Barrie Dempster: "Re: DoS/DDoS Attack"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]