On Fri, 10 Dec 2004, Ben Beuchler wrote:
On Fri, Dec 10, 2004 at 11:29:42AM -0600, Ben Beuchler wrote:
- If you get a good auth, you're in
- If you get a bad auth, or the response takes more than n milliseconds/seconds, try the next password
Is there any reason to make tarpitting logic non-persistent? It seems a robust implementation would keep track of IPs that have failed logins. Removing the record, of course, at the first successful login.
This would, of course, be potentially vulnerable to a distributed attack...
That depends on how smart the tarpit routine is. And I think you already need many thousands of machines before you can fill up a simple buffer with ips, in case of a very dumb tarpit algorithm. IPs don't take up so much space. IMHO, it's still better to try and slow them down (and perhaps protect the other services on the machine with the delays, so you can e.g. still receive email). Perhaps persistent caching would make things too complicated, the point is to slow them down, even if they have to do only 2/3 of their attempts with tarpit delay, you already succeeded.
It does look quite difficult to brute force over the internet, without any capable admin noticing millions of failed logins. Over an intranet it would probably be faster though, and they might be in before it's noticed.
My experience tells me at least SMTP tarpitting does help protect the servers when "#&%@! spammers visit your MTA instead of your baseball bat.