Just wondering how people have delt with DDOS syn attacks on port 80 of
a customers server? We had an attack a couple of days ago, and it
overwelmed both the customers firewall and, when we tried to turn up
filtering on a 7600 cisco router, the router also. We ended up having
the customer change his IP for the site under attack. We were lucky in
that the attack was against an IP and not the DNS name.
Just wondering how people have delt with DDOS syn attacks on port 80 of
a customers server? We had an attack a couple of days ago, and it
1) acl the traffic (Stop immediate pain)
2) blackhole ip in question
3) track via: http://www.secsup.org/Tracking/ to ingress points on your
network
4) acl traffic inbound there
5) remove blackhole and acl toward customer
Finish in ~10 mins... customer is back online and happy.
overwelmed both the customers firewall and, when we tried to turn up
filtering on a 7600 cisco router, the router also. We ended up having
the customer change his IP for the site under attack. We were lucky in
that the attack was against an IP and not the DNS name.
--
This is also a very viable solution, provided the customer has provisioned
for this with lower ttls on their DNS records, which ALOT of people
(thankfully) don't do... also, sometimes customers don't know how to do
this, eh? 
This is also a very viable solution, provided the customer has
provisioned for this with lower ttls on their DNS records, which
ALOT of people (thankfully) don't do
actually, a bunch of research now shows that low ttls on A RRs
(that are not the A RRs of NS RRs) has little effect.
in the case a dns lookup is being done in a ddos, of course one
would prefer if the attacking zombies cached the lookup <grin>.
randy
> This is also a very viable solution, provided the customer has
> provisioned for this with lower ttls on their DNS records, which
> ALOT of people (thankfully) don't doactually, a bunch of research now shows that low ttls on A RRs
(that are not the A RRs of NS RRs) has little effect.in the case a dns lookup is being done in a ddos, of course one
would prefer if the attacking zombies cached the lookup <grin>.
wouldn't dns lookups be a bit time consuming and introduce a dos on the
dos ?? if you had to look up each time you crafted a packet it'd take alot
more effort to pound out 100kpps, no? Most of the flooders I've seen (I'm
no programmer so I may be wrong on this) actually do a lookup to ip for
the dest and just start making packets, never rechecking the name->ip
mapping once its done the first time.
On the other hand, writing something for 100,000 codered clients to use is
another story, if you have 100,000 hosts you can afford a dns lookup 
though most of them just do: ping -t www.psg.com 65000
or some msdos flavor of this... (I don't actually know the right flags for
dos's ping program )
I remember a long time ago I wrote an app to reverse IP's and there
definately is a delay looking up addresses. And you're right it would
kill performance of the attack if they looked up the addresses each time,
so they do cache the entries. But lucky for us none of the coders have
thought to do lookups at regular intervals or better yet that with
threading they can use one thread for the attack and one thread to monitor
the DNS entry.
Andrew
maybe this could help find the attacking nwtwork? assuming people are
using local DNS servers?
under attack you could sporadically 'lie' about the result... and log
to whom you lied to... all the time looking for changes in the DDoS
target
a fair amount work perhaps...
--cw
wow, break bind in a new and horrid way to accomplish this task Nice...
perhaps mr. vixie will add this functionality for us?
wow, break bind in a new and horrid way to accomplish this task
perhaps mr. vixie will add this functionality for us?
patches welcomed.
This would be nice. Sort of like using different email addresses for each
site you hand them to and watching to see where the spam comes in from
Tracing back an IP from bind logs to see which name servers looked up an
attacked address immediately before the attack started. This at leads to
the offender's ISP which is a good start.
Date: Wed, 1 Jan 2003 19:30:00 -0800 (PST)
From: Avleen Vig
Tracing back an IP from bind logs to see which name servers
looked up an attacked address immediately before the attack
started. This at leads to the offender's ISP which is a good
start.
1) <x> compromised hosts form a botnet via IRC
2) A human gives the command to start the attack
3) One of the compromised hosts performs the DNS lookups
4) Destination IP is returned to the channel
5) Random delay
6) Attack begins
7) Repeat steps 3-6
I don't see how "tagging" or changing IP addresses does much to
mitigate a botnet (a DDoS has to be coordinated somehow) attack.
<wolkenkuckucksheim>
Let DNS return a token that expires after <x> seconds, a la KRB
tickets or SSH. When requesting a connection, the ticket is
presented as one of the IP options. The ticket space should be
sparse enough to expose brute-force guessing attempts.
Those of us who like typing IP addresses would need an alternate
mechanism and/or to change our behavior. One paragraph of random
rambling can't solve all the Internet's problems. 
</wolkenkuckucksheim>
Anyone interested in website or email that can only be viewed by
people who have installed a new, improved IP stack? (Looking at
the number of Codered/Nimda/etc. scans in logs, something tells
me protocol modifications are out...)
#include <technical-vs-social.h>
#include <how-much-of-the-internet-are-we-willing-to-ignore.h>
Is the problem technical or social? If it were mostly the
former, I think we'd have made much more progress by now.
I hope IPv6 is has the right features and works well. IPv4 is
badly entrenched; IPv6 will be worse. (And, please, I don't need
any kooky messages about IPv8 or IPv16 like the ones I sometimes
get after posting.)
Eddy
Relatively few people restrict the use of their name servers to only
local users. More folks have been getting DNS servers from DHCP/Radius,
but there are still a lot of users with hard-coded resolvers. There may
be a few DNS resolvers which keep track of query sources, but more than
likely you'll end up at another dead-end because the true source will be
somewhere else.
Let's add port 53 to the every growing list of ports to block.