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
