thanks a lot claudio if this fixes the problem. you will be for sure handsomely rewarded :)
On Sat, Sep 5, 2009 at 5:44 PM, 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
