If these attacks are coming from ips that are outside of the range of your standard users' network range, then it's possible you could filter out requests from unallocated ip blocks and ip blocks from areas of the internet that are gnerally too far away to have decent latency on your server. Unfortunately, this would mean building a database of ip blocks that are allocated to networks that are within a reasonable distance of your server's network and checking every A2S_INFO packet that comes in against this database, which would likely eat a decent amount of CPU.
Nephyrin Zey wrote: > The bandwidth involved in this attack is tiny. The issue is srcds chokes > on large numbers of A2S_INFO packets, its not the traffic that's doing > machines in. I'd reckon a single residential connection could take down > a server this way. Once you fix the srcds issue, the problem stops. I > have a daemon that intercepts server queries and handles them itself. > It's currently handling this attacker hammering on two servers without > breaking 1% CPU or making a single-pixel dent in my bandwidth graphs, > and my tf2 servers continue to run just fine. > > And if you actually examine the attack, it's very obviously a single > source with spoofed IPs. I rather doubt someone has a million-strong > botnet containing nearly 30% unallocated IP ranges, that all happen to > have the same exact path length. > > - Neph > > On 09/05/2009 12:50 PM, [email protected] wrote: > >> This... actually isn't a bad idea. It's a pain to implement, though, for a >> couple of reasons. >> >> First, the assumption by most on this thread is that it's a single guy >> operating from a single (or just a handful) of computers. They further >> assume that he's forging the source IP addresses so the requests look like >> they're coming from many many different machines. If this is true, there's >> no way to trace or block him based upon the information included in the >> packets he's creating. I think this assumption is wrong, as I'll explain >> below. >> >> Second, if this assumption is incorrect you need to find a way to identify >> each and every source and block them one at a time. Netblocks are at best a >> crude measure which risks blocking many legitimate clients. Such a process >> needs to be automated as much as possible or it's not effective. >> >> Now, why do I think that this is probably not coming from just a handful of >> sources? Simple. DDoS stands for Distributed Denial of Service, after >> all. Botnets are reaching incredible proportions. It's easy to rent as >> many as a quarter million compromised machines if you want to and you have >> the cash. >> >> Too cheap or too poor to rent someone else's network of infected PCs? No >> problem. Tools exist to build new malware and they're easy to come by if >> you're willing to start looking in the right places. All you have to do is >> build your bot code and figure out a way to get it loaded on 5,000, 10,000, >> or more PCs. After that, DDoS to your heart's content. Script kiddies do >> this _all_ _the_ _time_. >> >> So, when under attack your choices are: >> >> * Wait it out. >> >> * Work with your vendor to figure out a way block the attack in the first >> place. (Valve, obviously, in this case.) >> >> * Automate the process of identifying sources and filtering them out. >> >> * Cry a lot. >> >> Generally, I settle for a combination of the first and second options. If >> an attack gets bad enough, I work with my local ISP to implement the third. >> (My server is co-located in their datacenter and they're really good guys to >> work with.) Generally, some combination of tcpwrapper, netfilter, and >> iptables will do the job on my Linux server. Sometimes we find it easier to >> just block it at one of their routers so they don't have to deal with the >> traffic on their network. >> >> Every now and again, I find myself following the fourth option until I >> figure out what's going on and fall back on some combination of the first >> three options. :-) >> >> HTH. >> >> =JpS=SgtRock >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
