archive updated with source gcc -o sudppipe2.exe sudppipe.c -lws2_32
On Sun, Sep 6, 2009 at 10:58 AM, Spencer 'voogru' MacDonald<voo...@voogru.com> wrote: > How about the source so we can compile it on our own? > > I don't know about you but im not into running random exe files. > > -----Original Message----- > From: hlds-boun...@list.valvesoftware.com > [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Claudio Beretta > Sent: Sunday, September 06, 2009 4:35 AM > To: Half-Life dedicated Win32 server mailing list > Subject: Re: [hlds] TF2 DDOS AS2_INFO attack > > 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<beretta.clau...@gmail.com> wrote: >> I'm doing it right now, should be ready tomorrow. >> >> On Sun, Sep 6, 2009 at 12:32 AM, Kenny Loggins<kenny.logg...@clanao.com> > wrote: >>> I'm willing to pay someone to write a windows version of a query proxy. >>> >>> -----Original Message----- >>> From: hlds-boun...@list.valvesoftware.com >>> [mailto:hlds-boun...@list.valvesoftware.com] 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 <inflatablesoulm...@brothersofchaos.com> >>> >>>> 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, jps.sgtr...@gmail.com 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
