10 ms·

None of these options will solve your issues. Your attackers will simply re-adjust the mechanism as soon as they figure out your heuristics. You'll need to focu

None of these options will solve your issues. Your attackers will simply re-adjust the mechanism as soon as they figure out your heuristics. You'll need to focus on two efforts: (1) Being able to identify the IPs from which attacks originate, in real time. You will need to blacklist those hosts (for a limited period of time). (2) Minimizing and limiting the impact of traffic you previously flagged, on your infrastructure. Ideally, as hostile traffic is flagged, a response is never sent (at the TCP/UDP level). You absolutely do not want to serve any flagged requests. Block traffic as early as possible.

spydum 8y ago
so, I tend to disagree: your solutions were the old approach, where you keep trying to block, and hope they dont have a wealth of new source IP's to spawn their attacks from. I think what we find is, this doesn't work any longer. The new approach I would advise is along your very first point: don't let the attackers know you are on to them: silently sink their traffic into a dead service that doesnt even attempt a password login, but don't let them know. You continue to handle their password bruteforces, but you DONT ever return a success. This could be a straight up static page. This kind of approach only works if you are happy to pay the bandwidth price.. but the nice part is: you keep the attacker occupied, they have no idea they aren't making progress, and the users accounts are safe.
- xtrapolate 8y ago
  > "hope they dont have a wealth of new source IP's to spawn their attacks from" You'd still be able to detect new addresses and block as necessary. I don't see your point, of course the solution proposed isn't entirely hermetic, but how does your suggestion overcome this exact issue? > "This kind of approach only works if you are happy to pay the bandwidth price" Precisely the reason why most people would rather opt-out of serving malicious requests.

spydum 8y ago

so, I tend to disagree: your solutions were the old approach, where you keep trying to block, and hope they dont have a wealth of new source IP's to spawn their attacks from. I think what we find is, this doesn't work any longer. The new approach I would advise is along your very first point: don't let the attackers know you are on to them: silently sink their traffic into a dead service that doesnt even attempt a password login, but don't let them know. You continue to handle their password bruteforces, but you DONT ever return a success. This could be a straight up static page. This kind of approach only works if you are happy to pay the bandwidth price.. but the nice part is: you keep the attacker occupied, they have no idea they aren't making progress, and the users accounts are safe.

xtrapolate 8y ago
> "hope they dont have a wealth of new source IP's to spawn their attacks from" You'd still be able to detect new addresses and block as necessary. I don't see your point, of course the solution proposed isn't entirely hermetic, but how does your suggestion overcome this exact issue? > "This kind of approach only works if you are happy to pay the bandwidth price" Precisely the reason why most people would rather opt-out of serving malicious requests.