Bug #3246
closed
automatic lockout rule too general and cannot be unarmed
0%
Description
Hello all,
There is a rule that generates lockout for HTTPS clients that fail too many attempts on the pfsense web interface.
However that lockout is badly broken:
- It is not show anywhere on the webinterface, and cannot be reset without SSH'ing
- The source IP address is correctly set but the pf rule basically blocks HTTPS on all destinations, including those protected by the firewall
This issue made me lose 2 hours at home the first time, trying to understand why a device wouldn't go on the internet, and half an hour during a customer training, because a smartass tried to guess the admin password. I fixed it quickly because I already lost 2 hours on the exact same issue an other day.
My suggestions:
- Disable this functionnality by default until it is fixed. Implement a recovery time so the admin can't get locked out. Issue an alert in the panel when a source address has been locked out.
Thanks for considering this report and keep up with the good work.
Thanks,
Aris
Updated by Ermal Luçi about 11 years ago
- Status changed from New to Rejected
WHat do you expect it to do, its protecting the system!
BTW, it has an antilockout by default as well.
Updated by Aris Adamantiadis about 11 years ago
Is that a joke ? The lockout system is bugged (I explained how) and the antilockout cannot be used to reset that lockout.
Please read my bug report.
Aris
Updated by Chris Buechler about 11 years ago
- Status changed from Rejected to Resolved
- Target version set to 2.1.1
changed destination to (self) rather than any. The rest of the complaints aren't true or aren't valid. It's logged in the system log, and it's editable via Diag>Tables.
Updated by Aris Adamantiadis about 11 years ago
Thanks, that resolves my main concern.
Updated by Doktor Notor about 11 years ago
Afraid I don't understand what's been committed. This bug is about HTTPS, you changed this for SSH? What's the point of blocking all outgoing HTTPS traffic???