WP Shield Security PRO – Release 12.0

ShieldPRO 12.0 for WordPress sees an all-new audit trail and traffic logging system making it a complete system for all your WordPress security logging requirements.

Following feedback and suggestions on the older system, we decided to completely rewrite the security logging subsystem of the Shield plugin to ensure that it properly covered all important WordPress events while ensuring that we’re no longer restricted to on-site database logging.

The following article briefly outlines all the significant changes to the Shield plugin for version 12.0.

#1 Brand-New WordPress Security Logging

ShieldPRO has had an audit trail almost since inception.

We have always maintained that the best approach to WordPress security is not a constant barrage of email alerts.

Instead, far better is a security system that protects your site from threats automatically and without your intervention, wherever possible.

But for this approach to work, the security administrator must have easy access to high quality logs that detail those threats and any mitigating steps taken by the security plugin.

The original security audit trail got us there, mostly. It provided details on important events and made it fairly easy to read the logs and get the information we needed.

But it had some significant gaps and restrictions which we couldn’t solve without a complete overhaul.

The read more about all of these issues and the improvements that have been made, please take a look at our more detailed article here.

#2 All-New WordPres Traffic Log

The traffic log module was added to Shield some time ago, but quite a while after the audit log system. This meant that full integration of the 2 systems was absent.

With this release we’ve not only rebuilt the Security Audit Log but also the Traffic Log system. The reason for this is that the traffic log now informs the Audit Log with information and meta-data about the visitor request behind the audit log entry.

So rather than have 2 separate repositories of data (audit and requests), we now link the 2 together so that reviewing the audit logs is much easier since we can immediately also see the nature of the requests that trigger the events.

The Traffic Log system is still a fully functional subsystem of the Shield Security plugin and you can independently review the traffic and requests.

#3 Revamped Security Log and Traffic Log UI

Earlier we said that an important part of a security plugin is that it handles the threats automatically, logs it, and that the security admin must have easy access to that information.

Until now Shield’s UI for reviewing the logs hasn’t been great and made it difficult to find the information we wanted. The information was there, getting to it was a bit of a UI challenge, however.

With this Shield release, we’ve completely scrapped the old UI and replaced it with a filterable, searchable, dynamic table system. Both Audit logs and Traffic logs benefit from this switch.

#4 All Shield Security Events Available With Severity Levels

The older logging system had a few holes where the audit trail wouldn’t correctly log the events and filtering and searching for certain events didn’t work. These holes have been completely fixed.

We’ve also assigned a default “severity level” to every single event allowing you to filter by severity and event log only certain event levels.

#5 Improved Data Storage

As the Shield Security plugin evolved and more features were added we ran into a problem with how we were storing and sharing data between different subsystems. In particular, IP addresses.

When we track events and store them to the security log, or store requests to the traffic log, or users sessions, or bot signals, we do all this with a referrence against the visitor IP address.

Each database table was storing its own record of the IP address, so we had a large amount of duplicate and unnecessary data storage.

With this release we’ve started the process of implementing much smarter database structures, with a single IP address table which is linked-to from the audit log, request log and bot signals database tables. We’ve added some optimisations to these tables also which should go a long way to improving performance overall.

With subsequent releases, we’ll update the remaining legacy database tables to use the same datastructures and further improve performance throughout the entire plugin.

#6 AntiBot Detection Works Better With Caching Plugins

Our AntiBot Detection Engine relies on a piece of Javascript to be run by normal website visitors.

By running this particular snippet of javascript, we can more easily identify bots and distinguish them from normal visitors.

However, many website run caching and optimisation plugins which while they promise great things in principle, they’re probably the single biggest cause of trouble on WordPress sites. We’ve discussed this many, many times but the problem remains.

Many admins turn on a caching plugin, check all the boxes and believe things are “good to go”.

They’re really not.

Caching plugins require that each time you turn on a setting, change a plugin, upgrade a plugin or theme, you should do some thorough testing of your website. This due diligence, unfortunately, is rare.

And because it’s not often done, Shield runs into problems. The ADE requires this javascript to be loaded reliably for all visitors that need it. If it isn’t, then the ADE runs into trouble can very well flag a legitimate visitor/user as a bot.

With version ShieldPRO 12.0 we’ve decided to force the NotBot JS file to be loaded for all visitors, particularly if certain caching plugins are active. We’ve added a new option to Shield to let you turn this off this “always on” approach, if you’re the type of admin that tests their caching system to make sure it’s running as expected.

We’ll see how things go with this new release, but please do send along your feedback for this if you have any questions.

Questions, Suggestion and Feedback

As with every release, there are bug fixes and code enhancements that don’t really need to be detailed, but we’re always working to ensure that Shield is as bug-free and stable as we can make it.

If you have any questions or suggestions about anything raised in this article, please don’t hesitate to leave us a comment below. Thanks!