here it is http://www.wantedgov.it/page/62-srcds-query-cache/
more info on that page On Sun, Sep 6, 2009 at 12:44 AM, Claudio Beretta<[email protected]> wrote: > I'm doing it right now, should be ready tomorrow. > > On Sun, Sep 6, 2009 at 12:32 AM, Kenny Loggins<[email protected]> > wrote: >> I'm willing to pay someone to write a windows version of a query proxy. >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Saul Rennison >> Sent: Saturday, September 05, 2009 4:36 PM >> To: Half-Life dedicated Win32 server mailing list >> Subject: Re: [hlds] TF2 DDOS AS2_INFO attack >> >> This is why A2S_INFO requires a challenge :| >> >> Thanks, >> - Saul. >> >> >> 2009/9/5 Matt Stanton <[email protected]> >> >>> 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 >>> >> _______________________________________________ >> 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 >> > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
