just getting a bunch of T request nothing forwarded though. server is actually running on port 27016 so my commandline is -X xx.xx.xx.xx 27016 27015
On Sun, Sep 6, 2009 at 10:10 AM, Claudio Beretta <[email protected]>wrote: > no, the code that filters requests based on the source port is never > executed when launching with the arguments specified on the tool page. > The code that is executed is from line 419 ( if (len > 5) ) to line > 496 ( c = check_sd(&peerl, 0); ). The other if / else branches are > executed with other launch arguments. I just left it in since I'm > lazy. > > Try running it without the -q argument (quiet), you should see something > like > - got a T request FROM 191.83.51.210:17073 (25 bytes) > - forwarding request to 194.177.96.192:27300 (25 bytes) > - done (25 bytes) > - got a I reply FROM 194.177.96.192:27300 (84 bytes) > - got a T request FROM 31.52.173.97:48316 (25 bytes) > - replying from cache to 31.52.173.97:48316 (84 bytes) > - reply from cache done (84 bytes) > - got a T request FROM 89.32.56.194:14628 (25 bytes) > - replying from cache to 89.32.56.194:14628 (84 bytes) > - reply from cache done (84 bytes) > - got a T request FROM 116.108.191.75:20483 (25 bytes) > - replying from cache to 116.108.191.75:20483 (84 bytes) > - reply from cache done (84 bytes) > - got a T request FROM 35.38.228.9:9249 (25 bytes) > - replying from cache to 35.38.228.9:9249 (84 bytes) > - reply from cache done (84 bytes) > > getting something different? > > On Sun, Sep 6, 2009 at 4:38 PM, Shizzle Nizzle<[email protected]> wrote: > > 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. > >> >>>> > > > _______________________________________________ > 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
