The DoS from sslyze would have been thc-ssl-dos apparently. But it
seems that is (simply?) a processor overload. It sounds like imap-uw
POP server continued to fail after the attack terminated. This sounds
like a bug in imap-uw, but I'm not sure what it is. It would be good
to get rid of that bug. Did you chase this down further?
Blocking the testing site is proper for an operational solution, but you
(and we) are still vulnerable to such an attack from elsewhere.
Did you follow the documentation from sslyze to
https://www.thc.org/thc-ssl-dos/
and then to
http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html
Specifically, this discusses an iptables approach to rate limiting
(after blocking renegotiation) as a way to avoid such an attack. As
discussed near the end, the rate-limiting may be a problem if lots of
users share the same IP due to proxies, NAT, etc. If you don't have
lots of near-simultaneous SSL connections from any particular IP, then
this would be a more general solution than blocking one particular IP
address.
On 4/29/15 12:07 PM, Ken Johnson wrote:
FYI:
My server running imap-uw (Debian 7) has recently been hit twice (that I
know of, I will be scanning the logs for other events) by a research project
run by sba-research.org. Their scanning machine is scan.sba-research.org at
93.189.25.174. According to their Senior Researcher Marin Mulazzani, they
use the software "sslyze" to learn about encryption usage at online mail
servers.
The first time my server was scanned it disrupted POP access from legitimate
users during and shortly after the scan. I contacted sba-research, and they
committed to not scan my servers again. The second time they scanned my
system manual intervention was required on my part to restore service to
legitimate POP users.
...
Ken
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
