>I know this isn't the most elegant solution, but windows firewall sucks, ipsec >doesn't seem to allow fine grained filtering and I never coded MMS plugins >before. This tool should be used only during attacks (since new players might >add the server running on the new port to their favorites).
Well, you could just change the port of the server and then let the query cache listen on that port and it would make no difference except you would have to take the server offline for a moment, but after that it would be business as usual. On Sun, Sep 6, 2009 at 10:35 AM, Claudio Beretta<[email protected]> wrote: > 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
