i wasnt able to get this to work on any of my servers. if i read the source file correctly. if the src port isnt 27005/27006 it will drop them aswell? i no some people who dont seem to use that port that is legit traffic would it drop them too?
On Sun, Sep 6, 2009 at 5:29 AM, Donnie Newlove <[email protected]>wrote: > >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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
