Aaron D. Campbell

@RealEstateTechCoachGuy – Please check out the FAQs in the release post:
https://ithemes.com/security/new-ithemes-security-dashboard/#faq

Basically though, the temporary whitelist feature has been drastically overhauled, and is now completely automatic. After successfully logging in as an admin, your IP will be automatically whitelisted. It’s as easy as that, and all happens behind the scenes ??

Hey @internalerror503,

I’m glad we found the issue! The 3rd party script is from a widely trusted source (MailChimp), but the fact that their local (inline) JS breaks if the remote JS doesn’t load is clearly and issue. I’ve just committed a fix to our internal repo that pulls that file into the plugin. The next release (I would expect it today some time) should include this fix.

Thank you very much for finding this and brining it to our attention.

Hey fluencyNEWS, Maintenance Mode is actually something built into WordPress Core. Please see the Maintenance Mode Following Upgrade section of the Common WordPress Errors page in the codex and see if that helps.

Hey 3Lancer, thank you very much for your concise report. Is there any way I could get you to run a database query to pull out the settings for the plugin and send it to me as [email protected]?

Any options with the string ‘itsec’ in the name are from this plugin, so a query like this should get them all:
SELECT * FROM wp_options WHERE option_name LIKE '%itsec%'
Please note that you will need to replace wp_ with your table prefix if it is non-standard. Also, if you are on a multisite install the query is different…so ask me for it if needed.

Hey @internalerror503, thanks for reaching out. First, let me say that if you have the paid version (even on another site), you should really open support ticket (https://ithemes.com/member/support.php). You definitely get priority support over there and it’s also far easier for us to track what’s going on with the ticket, get additional information, etc.

As for your issue, could you check your PHP logs and see if you can see where the failure is (or open a ticket with priority support and give access to your logs there)?

I understand how frustrating it is when you have a problem like this. I can assure you that we definitely did a lot of testing around this before releasing it, and while we are seeing a chunk of people with issues, with more than 50,000 sites already updated, it’s a very small fraction that are actually having issues. Please bear with us as we try to resolve the issues for those that have them.

Hey @maze27, could you post the entirety of the .htaccess (split up like that, it’s hard to tell what’s what) and the IPs you currently have in the ban users section? I’ll take a look and see if I can figure out what might be happening. Also, if you know what version of Apache you’re on, that might be helpful.

Hey Jason,
Thanks for your report.

The “pretty screens” definitely don’t cause any additional server load. Actually they tend to make smaller, lighter-weight server requests, with most of the work being done by JavaScript in your browser. Additionally, they definitely don’t cause any extra load on any pages other than the iThemes Security settings page.

Also, in our testing the actual memory load is lower for the 5.4 release than any recent release. Especially for certain features.

If a user gets a “flash of the dashboard” then it’s likely the server has already done it’s job and spit out the page. Possibly there’s a JavaScript conflict somewhere? Overall, it’s very tough to tell what might be happening without some actual errors to look at. If you can get the relevant log entries, I’ll certainly take a look.

Hey guys, I’m Aaron, one of the lead devs on the plugin. I’m hoping that I can address some of the concerns and maybe elicit some help in tracking down what ails you.

First, @dwindon was right about the comment in the changelog. We did have some problems with modules not being properly activated during an update to the new version, but it was fixed prior to release (well, it was released to a subset of our Pro users, who got the update first, but the bug was never released in the Free version here on www.ads-software.com).

That’s not to say there couldn’t possibly be a different, as yet unnoticed, bug that causes similar issues, but we have had tens of thousands of upgrades with this new code, and only a few people are having this problem. Unfortunately, while that’s good for the majority, it doesn’t make it easy to track down the problem. It’s possible that this is an issue with a very specific setup, a plugin conflict, or even some specific server setup. Right now, we need more information to attempt to track this down.

If those of you who have had this problem could provide us some information, it could be really helpful:

1. What specific modules were configured the same (including enabled or disabled when they shouldn’t be) post-upgrade?
2. If you could send us your settings, that would be amazing. You can send them to [email protected] or [email protected]. Any options with the string ‘itsec’ in the name are from this plugin, so a query like this should get them all:
   SELECT * FROM wp_options WHERE option_name LIKE '%itsec%'
   Please note that you will need to replace wp_ with your table prefix if it is non-standard. Also, if you are on a multisite install the query is different…so ask me for it if needed.
3. If you could give us a list of plugins you use, that would be helpful as well.

None of your old settings were removed as part of the upgrade. Running the queries that @gerroald provided earlier will remove the new settings, and trigger the upgrade to run again on the next page load. If you think there’s a reason the upgrade issue may have been a one-time issue, you can use those to simply run it again. *It will undo any changes you’ve made since the upgrade though!*

Lastly, if we can keep this thread focused on this specific issue, it would be incredibly helpful. (@jefflloyd11, whether @dwindon is a moderator or not, those are the forum guidelines, and a moderator can and will lock this thread if it get off topic)

Thanks for your help

I have responded over on the github issue with more details, so we can try to resolve this there for you.

The basics though, are that the rule above is taken out of context here. It has a bunch of rewrite conditions chained before it, so that rule is only executed if one of the conditions is matched (in this case, if any known bad user agents or referrers are found).

Hey John,

Just to try to clarify things, IPv4 and IPv6 IPs are treated separately by the plugin. The plugin will only write an IPv6 IP to the .htaccess if it is given an IPv6 IP (which it shouldn’t get if your server doesn’t support IPv6).

The only other reason it would attempt to write an IPv6 address to the htaccess would be if you manually banned an IPv6 address on the settings page.

Would you be able to get us a copy of the htaccess that caused the problem (maybe hostgator would be able to get it for you) as well as what version of Apache you are running?

Hey Mike, Presenter doesn’t actually eliminate the admin toolbar from any pages (including on the front end) except slideshows. On those, it’s removed because the slideshow template doesn’t call wp_header() and wp_footer() in order to avoid loading JS and CSS that conflict with Reveal.js.

It’s definitely not a Powerpoint extension. It lets you use WordPress to make a slideshow, each slide being made with TinyMCE (WYSIWYG) inside a post type.

It’s not security through obscurity so much as it is giving as much time as possible for sites to update before releasing more specifics than we have to.

Honestly, I have to disagree with you on one part. No matter how many sites break (which I think we actually broke an especially small percentage of sites), I don’t think WordPress should have a core method for making something insecure.

Hey @distinct, I see that you placed a similar comment on the ticket itself. I think it makes sense to keep conversation all in one place, and since that ticket is closed and unlikely to reopen, lets go ahead and try to keep it here.

You’re probably not going to find a lot of actual code detailing the security issue, for obvious reasons. Having said that, we do in fact have security concerns. You are right that it might not affect all sites (such as a site with all trusted users that all know exactly what they are doing and have a good grasp of HTML in general), but that doesn’t change the fact that we need to keep this security hardening in core for all other sites.

Since shortcodes won’t work inside HTML tags or comments, if you need something to function in those areas you’ll have to find another option.

I apologize if you got the impression this is abandoned. Due to personal reasons I haven’t had much time to sink into it, but I’m certainly around to keep it up. It has continued to work all along, it simply hasn’t been getting much in the way of new features.