I've got a report that my tool doesn't work on multihomed machines where there is more then one server running on the same port but on different IPs.To fix add the -b IPAddress argument to sudppipe2
I've updated the tool description page to reflect this. http://www.wantedgov.it/page/62-srcds-query-cache/ On Sun, Sep 6, 2009 at 5:56 PM, Claudio Beretta <[email protected]>wrote: > try with this one > http://www.wantedgov.it/gov/SrcdsQueryCache.7z?v2.1 > in the previous version i left uninitialized a variable that tracks > time, so that might be the cause of you not seeing any forwarding. > This version also fixes a minor logic bug, which could prevent the > tool to reply to some T requests. > > On Sun, Sep 6, 2009 at 5:22 PM, Shizzle Nizzle<[email protected]> wrote: > > 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 > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
