Daniel Convissor
Forum Replies Created
-
Hi Steve:
Release 0.33.0 includes some new text in the login failure notifications saying that the attacker will be blocked and that the given email will be the last one for the current attack. Both are conditional, being added or not depending on the settings in use at the time.
I’d rather not complicate things with a permanent IP ban listing/UI. At least at this point.
Thanks again,
–Dan
PS: when you get a chance, please give 0.33.0 a “works” vote.
For the email preferences, perhaps I’ll add an option for admins to choose if they want one notification or repeated notifications.
This has been added in the new release, 0.32.0.
There’s also new text in the readme about how this plugin blocks attackers.
Bozz: I’m still curious what you think about enhancements needed, if any, to the notification emails.
Forum: Plugins
In reply to: [Login Security Solution] [Plugin: Login Security Solution] NOT RECOMMENDEDThe FAQ has been updated with a section entitled “Will you provide lock outs / blocks in addition to slow downs?” It explains how this plugin works and how it actually blocks attackers.
The FAQ has been updated with a section entitled “Will you provide lock outs / blocks in addition to slow downs?” based on the “perspective” post, above.
Thanks. If the problem reappears, please reopen this thread and provide a detailed list of steps taken and error messages produced.
Hi:
If this happens again, please reopen the thread with the requested error messages.
–Dan
Hey gwc_wd:
Wow! Thanks for the thoughtful response.
I would have thought that attackers would be shut down quickly by their ISPs
Yeah, tell me about it. 🙁
LLA effecively allows a permanent IP block by setting the time to 9999 hours (2.3 years)
You can jack up the “Match Time” setting in LSS to obtain the same effect.
The blocked IP never gets to the login screen at all. So a blocked IP does not get a chance to the “Check Authentication process.” <–Am I wrong about this?
Attackers use scripts that directly submit POST requests, so WordPress’ authentication actions are called even if the form is hidden.
ZBBlock
Interesting. I downloaded it and will take a look.
Thanks again,
–Dan
The length of time is mentioned at the top of the email. If an attacker gets in, a separate email is sent explaining that they were booted out and the password reset.
Are you suggesting the passage you quoted include some text saying something like “Don’t worry, even if they do get in, they’ll be immediately ejected.”
Hi Andy:
Do you still have any of the attack/intrusion emails laying around? If so, please forward one of them to me at danielc@analysisandsolutions.com.
Please make sure you have the latest version of the plugin (0.31.0 at this point).
Going to wp-admin took me to the login page.
I was asking where the login page redirects you to after you logged in.
That’s now how it’s supposed to work. From your description, it sounds like you’re using an old version and/or have strange user/settings data. Please use the “Yes, delete the damn data” option on the settings page, deactivate the plugin, make sure you have the latest version installed (0.31.0) then activate it.
Please post back here and let me know how that goes.
Hi bbeoj:
You’re very wise to not have a user named “admin.” LSS is very noisy and I have taken steps to reduce that and have plans to reduce it further. Special handling for non-existent users seems like more trouble than it’s worth; an attack is an attack and after exhausting “admin” may turn to actual user names.
Thanks,
–Dan
Hi gwc_cd:
Another perspecitve on the “slow downs vs blocks” debate came to me the other day. It turns out Login Security Solution does indeed block. (Where “block” means “denies access” to attackers.) Below is a comparison of the attack handling logic used by Limit Login Attempts and Login Security Solution.
Limit Login Attempts
Invalid or Valid Credentials by Attacker or Actual User
- Process authentication request (check IP address)
- Error message: “Too many failed login attempts.” (ACCESS DENIED.)
Note, this approach means an actual user can be denied access for 12 hours after making 4 mistakes.
Login Security Solution
Invalid Credentials by Attacker or Actual User
- Process authentication request (check IP, user name, and password)
- Slow down the response
- Error message: “Incorrect username or password.” (ACCESS DENIED.)
Valid Credentials by Attacker
- Process authentication request (check IP, user name, and password)
- Slow down the response
- Set force password change flag for user
- Error message: “Your password must be reset. Please submit this form to reset it.” (ACCESS DENIED.)
Valid Credentials by Actual User
- Process authentication request (check IP, user name, and password)
- (If user is coming from their verified IP address, let them in, END)
- Slow down the response
- Error message: “Your password must be reset. Please submit this form to reset it.” (ACCESS DENIED.)
- On subsequent request… user verifies their identity via password reset process
- User’s IP address is added to their verified IP list for future reference
So both plugins deny access to attackers. But Login Security Solution has the bonuses of letting legitimate users log in and slowing the attacks down. Plus LSS monitors user names, passwords, and IP’s for attacks, while all of the other plugins just watch the IP address.
I’m curious what your thoughts on this perspective are.
Hi Rainydayz:
Please copy the error messages that get produced on the login page in step 4 and paste them here. Similarly, please provide copies of any email messages you received from this plugin.
What other plugins are you using?
What happens if you log in by browsing directly to
<domain>/wp-admin/(which will redirect you towp-login.php) instead of going directly towp-login.php(which renders the home page upon logging in)?Thanks,
–Dan
For the record, it’s not a permanent ban. The length of time is determined by the “Match Time” setting.
For the email preferences, perhaps I’ll add an option for admins to choose if they want one notification or repeated notifications.
The data is stored in the
<prefix>login_security_solution_failtable. The plugin doesn’t have a user interface to view it, but you can run your own queries if you’re curious.As long as the “Breach Email Confirm” is set to a reasonable number, attackers are blocked from actually getting in. In the unlikely event they do get lucky, LSS will force them out and require the actual user to verify their identity via the password reset process.
The plugin’s verbosity freaks people out. I’ve been scaling that back in recent releases. Right now emails are sent each time the attack count is a modulus of “Failure Notification” setting. Maybe I should just have one email go out when the threshold is reached and that’s it. What do you think?