1

I am implementing a web service and have a daemon process that notices repeated failed login attempts from any given source. If too many occur the IP address is blocked for a given time.

This is similar to the fail2ban or (now deprecated) denyhosts packages.

My concern is if the bad actor is behind a NAT gateway for a large organization (a university or Fortune 1000 for example) then the ban will affect everyone behind that gateway, not just the one station running dictionary attacks.

Is there any viable method for avoiding that side effect?

UPDATE: I changed the title as per suggestion and it occurs to me that this problem applies to nearly any kind of attack, not just the dictionary attack I outlined.

AlanObject
  • 525
  • 3
  • 8
  • 1
    "how to defend (...) without blocking all other users using the same gateway" would be a more precise title. – Mindwin Apr 26 '17 at 21:11

1 Answers1

1

Your solution is easy to config/code, but not so fair as you stated the ip could be for not only one person.

You could come with following alternatives:
1:
If the attack is for one particular user(let say user a), so after some failed logins disable the account and send an email/notification to the user to activate his/hers user, and/or activate the account after 24 hours of last attack.
Disabling the account means reject both fail and correct authentication for the given user, and instead of saying this account is disable, or wrong password, state it's invalid username or password.

2:
After some attack from the ip, ask for captcha for next login attempts, and always check the captcha first. If the attacker starts to continue attacking with vary IPs to skip the captcha, then act more smart and ask for captcha of every requests(assume it's code-security for your server).
Captcha(if it's good enough really) makes you sure the attacker is not robot(which 99% is).
Even if the attacker could get over the captcha, go back for the plan 1 again, disable the user becasue of too much fail logins.