I get locked out of my own server all the time. I send FP reports most of the time, which sometimes result in rule changes and other times result in "If this is normal behavior for your software, disable this rule."

Well, I'm using WordPress, Drupal, and PHPMyAdmin. These generate 100% of the lock-outs I've experienced.

A great way for ASL to work would be for me to visit a certain URL or push a button in the admin, and have ASL automatically whitelist my current IP address. Or use a token system so if my dynamic IP changes I'm still good to go.

What do you guys think?

Neat idea, we'll do some research to determine the feasibility as well as the security implications of such an approach.

Does anyone else have this issue or am I doing it wrong?
What I want to do is try to "fix the system" rather than end up frustrated and chuck the system. I love ASL, but it's frustrating to be locked out of my server with no real way of getting back in except waiting 30 minutes.

Maybe something with portknocking?

Feature request 581 added. You can track it in the support portal under the Bugs tab.

Wouldn't getting a static IP address be a better idea?

I'm assuming you have to use a mobile connection or some other type where getting a static IP is difficult.

You could rent a VPS (static IP), lock it down except for ssh (or OpenVPN if you prefer), then tunnel from there to your own servers, for example.

Faris.

faris,

Yes, getting a static IP address for my home PC, my laptop when I'm at a coffee shop, my office PC, and my wife's laptop just in case, and for my developers offsite wherever they are seems like a silly way to fix the problem.

I do typically just tunnel in from another server any time I need to access the server shunning me. This is too much to ask of other devs though

Good idea. Add this to the ASL 3.1 voting thread:

viewtopic.php?f=3&t=5245

Does it equal #4?

Do you mean this candidate #4:

Atomicorp Candidate #4: Redirect blocked users to a web page that explains why they were blocked and provides options based on the policy set by the system owner (examp,e, give them a captcha and allow for spam, admin password and allow XSS rules, report as false positive, etc.) Also for cases where the system owner does not want them to disable the rule, or allow the event, give them information to reach out the system owner to resolve the issue. (the domain and/or system owner would be able to disable/enable this depending on the type of rule triggered)

Yes - does that cover it in a more global way than just my little suggestion?

I think so, but there is merit to the idea of a "temporary" or personal whitelist too I think. I think the key is to make sure you can either set a timeline for it or maybe someway to easily "disable it"... not sure of the most reliable way to do that. I prefer #4 because I think its more likely to add to a tailored policy for the system, but I'm wide open to ideas about usability.

I think if #4 were live, I'd be happy

So a vote for #4!