You could use iptraf do look after the packets. You can configure it to put all the packet-logs into a file and then take a look at the file.
/Chris Den 07/01/2011 kl. 23.50 skrev Marco Padovan: > I suppose those are all spoofed udp packets as they were the last time I > checked them :( > > I do not have direct access to the upstream links so I cannot trace them and > link them to a specific bw supplier :( > > just increased the limits but still getting the drop rule hit hard... it's > difficult to justify these spikes as legit traffic.. > > check from 23:21 onward > http://pastebin.com/jUjzyKY6 > > I do not think I'm the only one in this situation as I saw many people > discussing these problems recently :/ > > Il 07/01/2011 23:27, Christoffer Pedersen ha scritto: >> No offense, but have you tried to look at where those dos attack comes from? >> You could block the IP-address of the attacker. >> >> /Chris >> >> Den 07/01/2011 kl. 22.32 skrev Marco Padovan: >> >>> I thoutgh about that too... but monitoring the situation closely it appear >>> to be cristal clear: >>> >>> http://pastebin.com/asHm8GkW >>> >>> I getting spikes of 50k packets in very short periods (<60seconds) >>> >>> I'll try to monitor all my servers in HLSW seeing how much time they are >>> going offline... >>> btw... seeing the spikes were that big I think I can increase the limit a >>> lot... maybe 25 :) >>> >>> Il 07/01/2011 22:22, frostschutz ha scritto: >>>> On Fri, Jan 07, 2011 at 08:09:40PM +0100, Marco Padovan wrote: >>>>> 20 minutes later: >>>>> Chain QUERYLIMIT (4 references) >>>>> pkts bytes target prot opt in out source >>>>> destination >>>>> 396253 20611768 ACCEPT all -- * * 0.0.0.0/0 >>>>> 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport >>>>> 50483 2675483 DROP all -- * * 0.0.0.0/0 >>>>> 0.0.0.0/0 >>>> If the number of dropped packets keeps rising slowly here, >>>> you are probably dropping legitimate queries. Maybe the limit >>>> is a bit too low then. Also consider using a larger burst. >>>> The burst will allow short, random spikes, but under actual >>>> and constant DoS, the limit will still be respected, same as >>>> without burst. >>>> >>>> I'd try limit 20 burst 40 here and see how that goes. You can >>>> be generous with burst as it will vanish completely during >>>> a DoS attack anyhow (and it will take 40 below-limit seconds >>>> to recharge). >>>> >>>>> another box of ours that generally suffer a lot of is now reporting: >>>>> >>>>> Chain QUERYLIMIT (4 references) >>>>> pkts bytes target prot opt in out source >>>>> destination >>>>> 333352 16966756 ACCEPT all -- * * 0.0.0.0/0 >>>>> 0.0.0.0/0 limit: avg 15/sec burst 5 mode dstport >>>>> 563098 29844034 DROP all -- * * 0.0.0.0/0 >>>>> 0.0.0.0/0 >>>> drop>> accept is to be expected during a DoS attack. >>>> >>>>> nobody complained yet... so looks like its holding :) >>>> Test it yourself - see if you can get a complete server >>>> list using the standard steam server browser. If half >>>> of your servers are missing there most of the time >>>> (while there is NO DoS going on), chances are your >>>> limit is too low. >>>> >>>> Regards >>>> frostschutz >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
