Project

General

Profile

Actions

Bug #3246

closed

automatic lockout rule too general and cannot be unarmed

Added by Aris Adamantiadis about 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
09/29/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

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

Actions #1

Updated by Ermal Luçi about 8 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.

Actions #2

Updated by Aris Adamantiadis about 8 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

Actions #3

Updated by Chris Buechler about 8 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.

Actions #4

Updated by Aris Adamantiadis about 8 years ago

Thanks, that resolves my main concern.

Actions #5

Updated by Doktor Notor about 8 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???

Actions #6

Updated by Chris Buechler about 8 years ago

both have been changed

Actions

Also available in: Atom PDF