|
Notes |
|
|
|
|
|
|
(0002646)
|
|
Konar6
|
|
2012-02-19 16:49
|
|
Note that this attack is immune from server bans. The connection is still processed and logged, which sends the server to a lagging hell and makes the logs tens of megabytes big within seconds.
Possible solution - ban and ignore the offending IP completely. Have the server check whether the client is banned prior to further communicating with it. Currently it checks other stuff before that. Also don't log those "X bad connection attempts in Y amount of time". |
|
|
|
(0002647)
|
|
Dusk
|
2012-02-19 19:54
(edited on: 2012-02-19 19:59) |
|
I whipped up a throttle system to mitigate too quickly reconnecting clients as an afternoon challenge of sorts :P . If a client connects twice every sv_throttlethreshold seconds, they get ignored for 10 seconds.
'https://bitbucket.org/CrimsonDusk/notebola/changeset/12cdaab115bb [^]'
Not sure how well it works in practice or if there's a better way to implement this, I can only test this on my local machine and that's not really good enough, other than that it technically works. If I reconnect too quickly to my server I do get throttled but does it help under a real DDOS?
|
|
|
|
|
|
I don't think that this kind of throttling is better than Skulltag's existing anti-flood mechanism. So I extended the existing mechanism to take care of this by ignoring any further net packet from an IP of a client that was disconnected due to an error for 10 seconds:'https://bitbucket.org/Torr_Samaho/skulltag/changeset/977a8d543834 [^]' |
|
|
|
(0002649)
|
|
Dusk
|
2012-02-19 23:33
(edited on: 2012-02-19 23:34) |
|
Ah damn. How come I never thought of that...? Oh well... still good practice. :)
|
|
|
|
|
> How come I never thought of that...?
Don't worry. Considering that you only have access to the source since one week you're doing pretty well :). |
|
|
|
(0013377)
|
|
Dusk
|
|
2015-09-01 21:00
|
|
Was addressed in Skulltag 98e but never closed for whatever reason.
Man, I look so naive in my posting in this ticket.
|
|