At the time I was in a hurry to restore service. I killed 20+ imapd processes running as root, and that didn't help. What did help was to restart inetd, which had apparently stopped listening on port 995; port 995 no longer was visible in output from netstat -t -l -n.
Thanks for the pointers. I'll have to look into those. The other thing I have done since then is to add fail2ban filters (a similar effect to iptables rate-limiting, I suppose) as described here: http://sourceforge.net/p/fail2ban/mailman/message/34070114/ fail2ban is a pretty flexible tool; I recommend it. iptables rate-limiting is probably more elegant and more efficient. While inspecting logs prior to creating the fail2ban filter, I found evidence of other scanning projects including eecs.umich.edu and shodan.io. Those appeared to be a single connection at a time, while sba-research.org attempted >400 connections in a span of 10 seconds. (this server typically has 700 non-spam messages per day -- even assuming all arrive during working hours, that's only about 90/hour, vs the 144000/hour rate of sba-research.org) Ken -----Original Message----- From: Imap-uw [mailto:imap-uw-boun...@mailman13.u.washington.edu] On Behalf Of Mabry Tyson Sent: Wednesday, April 29, 2015 10:35 PM To: imap-uw@u.washington.edu Subject: Re: [Imap-uw] Research project with DoS side-effects 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 Martin 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 Imap-uw@u.washington.edu http://mailman13.u.washington.edu/mailman/listinfo/imap-uw _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman13.u.washington.edu/mailman/listinfo/imap-uw
