3 ms·

> I can't listen on a different port. And the author insists you shouldn't change ports any way. But seems to have no trouble just saying "use the security in

> I can't listen on a different port. And the author insists you shouldn't change ports any way. But seems to have no trouble just saying "use the security in your applications". Well... what sort of security is there in an IMAP server beyond "validate credentials"? My other thought, reading the author's post, and having seen enough of this type of attitude, is that this type of person would be the one to say "just use... <external mail service>" or similar. "You can't ever do better than them!" Well... I have to suspect that techniques like fail2ban - blocking network access after X suspicious access attempts - get employed at the big service providers too. Possibly not fail2ban specifically, but the same ideas.

22c 3y ago
Several years ago I was part of team managing one of the busiest recursive DNS resolvers in the country. Around the time, DNS reflection attacks were becoming all the rage (I think there might have been a vulnerability in PowerDNS to blame, I don't specifically recall the details). The solution we employed was a "dumb" fail2ban like script to ban any abusive IP address. It worked wonders and practically completely neutralized the attacks. We received zero complaints from any legitimate users of the service. If I recall correctly, even after the attacks subsided (CVEs was patched etc.), we still kept a toned down version of the script in place. > at best, fail2ban: does nothing This is just plain wrong. Even if you're only using key based auth and there's no way an attacker could have your keys, fail2ban will still block the abusive traffic. I have no issues with blocking abusive traffic instead of letting the attackers beat their fists against my armored doors. > at worst, fail2ban: causes you massive inconvinience or total lockout The authors main criticism seem to be that you might lock yourself out of your own server one day. This hardly seems fair because the author is saying "just setup SSH correctly and you won't have any issues" while also saying "if you don't setup fail2ban correctly, you'll have a whole bunch of issues!" OK, so shouldn't we just setup fail2ban correctly as well? Having said all that, my recommendation for people who are going to use an indiscriminate fail2ban setup on SSH access would be to have some out-of-band access in case you do happen to ban yourself, even if it's less convenient to use than SSH.
- red-iron-pine 3y ago
  > The authors main criticism seem to be that you might lock yourself out of your own server one day. I wonder if the author has ever used KVM, iDrac, IPMI, etc., or the log-in consoles on cloud platforms. And if you don't have those then 1) woe be to you, and 2) pay the 150/hr remote hands fees to get someone to console in for you.

22c 3y ago

Several years ago I was part of team managing one of the busiest recursive DNS resolvers in the country. Around the time, DNS reflection attacks were becoming all the rage (I think there might have been a vulnerability in PowerDNS to blame, I don't specifically recall the details). The solution we employed was a "dumb" fail2ban like script to ban any abusive IP address. It worked wonders and practically completely neutralized the attacks. We received zero complaints from any legitimate users of the service. If I recall correctly, even after the attacks subsided (CVEs was patched etc.), we still kept a toned down version of the script in place. > at best, fail2ban: does nothing This is just plain wrong. Even if you're only using key based auth and there's no way an attacker could have your keys, fail2ban will still block the abusive traffic. I have no issues with blocking abusive traffic instead of letting the attackers beat their fists against my armored doors. > at worst, fail2ban: causes you massive inconvinience or total lockout The authors main criticism seem to be that you might lock yourself out of your own server one day. This hardly seems fair because the author is saying "just setup SSH correctly and you won't have any issues" while also saying "if you don't setup fail2ban correctly, you'll have a whole bunch of issues!" OK, so shouldn't we just setup fail2ban correctly as well? Having said all that, my recommendation for people who are going to use an indiscriminate fail2ban setup on SSH access would be to have some out-of-band access in case you do happen to ban yourself, even if it's less convenient to use than SSH.

red-iron-pine 3y ago
> The authors main criticism seem to be that you might lock yourself out of your own server one day. I wonder if the author has ever used KVM, iDrac, IPMI, etc., or the log-in consoles on cloud platforms. And if you don't have those then 1) woe be to you, and 2) pay the 150/hr remote hands fees to get someone to console in for you.