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. -- Mike Hyde <mhyde@escape.ca>
On 30 Dec 2002, Mike Hyde wrote:
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
On Mon, 30 Dec 2002, Randy Bush wrote:
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>.
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 :( )
randy
On Mon, 30 Dec 2002, Christopher L. Morrow wrote:
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.
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 --- <zerocool@netpath.net> http://www.andrewsworld.net/ ICQ: 2895251 Cisco Certified Network Associate "Learn from the mistakes of others. You won't live long enough to make all of them yourself."
On Mon, Dec 30, 2002 at 08:09:17AM -0800, Randy Bush wrote:
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.
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
On Mon, 30 Dec 2002, Chris Wedgwood wrote:
On Mon, Dec 30, 2002 at 08:09:17AM -0800, Randy Bush wrote:
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.
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...
wow, break bind in a new and horrid way to accomplish this task :) Nice... perhaps mr. vixie will add this functionality for us?
On Mon, 30 Dec 2002, Chris Wedgwood wrote:
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...
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.
AV> Date: Wed, 1 Jan 2003 19:30:00 -0800 (PST) AV> From: Avleen Vig AV> Tracing back an IP from bind logs to see which name servers AV> looked up an attacked address immediately before the attack AV> started. This at leads to the offender's ISP which is a good AV> 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 -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
On Wed, 1 Jan 2003, Avleen Vig wrote:
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.
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.
participants (9)
-
Andrew Dorsett -
Avleen Vig -
Chris Wedgwood -
Christopher L. Morrow -
E.B. Dreger -
Mike Hyde -
Paul Vixie -
Randy Bush -
Sean Donelan