Fun fact: The premise of the Sucuri Security plugin was almost exclusively for this visibility. Over the years we added more features to accommodate a more robust application security toolset, but that was always a secondary objective. In fact, the premise of the Sucuri plugin was actually built based on the lessons Daniel learned with OSSEC.
One of its key features was always log aggregation. It would collect the logs and pipe it back to the mother station where we'd store it remotely on behalf of the customers; it was designed this way to provide us a mechanism to perform forensics post-compromise.
In 2016 we released a feature inside the plugin that was designed to pull it all together - WordPress Activity and OSSEC. The intent was to integrate the plugin with the WordPress hooks so that the user could gain visibility into the application activity, activity that access logs would not highlight. This activity would be piped into a new log format, and OSSEC's decoder would make sense of the new log format so that as the user you clearly understood what was going on.
This article will use OSSEC and the Sucuri Security WordPress plugin to bring your logs to life.
Configuring Sucuri Security WordPress Plugin to Export Logs
This articles assumes you've already installed the Sucuri Security WordPress plugin (a guide is available). You will find the option to export the logs here: Sucuri Security > Settings Scroll down to the section that reads Log Exporter
A couple of pro tips when selecting your file path:
-
,
- You want to entire the path, and file name. Example: /var/www/logs/blog.log ,
- The path has to be writeable, so be sure to check the user and the associated permissions ,
- It doesn't like it if you try to put it at the root of the site, you need to navigate up a directory or the plugin won't allow you to deploy it. We did this because we didn't want the file to be accessible to the outside world (avoid information leakage).
# tail -f blog.log 2018-12-01 01:59:40 WordPressAudit perezbox.com tony@perezbox.com : Notice: ; User authentication succeeded: administrator 2018-12-01 02:00:00 WordPressAudit perezbox.com tony@perezbox.com : Notice: administrator, ; Post was updated; ID: 80; name: OSSEC FOR WEBSITE SECURITY: PART III – Optimizing for WordPress ActivityYou see that a user logged in, the IP they came from, and it shows a post was updated. This was important because if you think to how SEP attacks work, attacker would update existing articles with SEO Spam. In the process they would update posts, articles, pages and the user would be none the wiser. As the webmaster, seeing updates to posts and pages should be a red flag - especially if they are unexpected (e.g., odd hours, random users, etc...). This is what you'd consider to be an Indicator of Compromise (IoC). If you see these logs proceed to the next step to configure OSSEC.
Configure OSSEC to Consume Sucuri Security Logs
Around the same time that we released the plugin update, we also updated the OSSEC WordPress rules. The updates were designed so that website owners would not have to write new decoders to parse and analyze the new logs. This means all we have to do is add the log you created above to the ossec.conf file. You do this by using the utility shell provided with OSSEC. In your terminal, run the following command:# /var/ossec/bin/util.sh addfile /var/www/logs/blog.log /var/ossec/bin/util.sh: File /var/www/logs/blog.log added.The util.sh shell was created to help you when adding new log files. It will automatically create the appropriate configuration inside your ossec.conf file. Example configuration change applied to the configuration file:
<ossec_config>
<localfile>
<log_format>syslog</log_format>
<location>/var/www/logs/blog.log</location>
</localfile>
</ossec_config>
Pro Tip: If you run your own VPS and manage a bunch of sites on the same server, adding each log file can be really annoying using this process. You could use the following script that was shared in by SimonF in my article in 2013. Update the path to the path you're using for the new WordPress logs.
#!/bin/sh for i in $( find /var/www/logs/ \( -iname "*.log" \) ); do /var/ossec/bin/util.sh addfile $i doneThe final step is to restart the OSSEC server:
# /var/ossec/bin/ossec-control restartMonitoring your alerts.log will show the following alert if you log back into your WordPress site:
2018 Dec 01 01:59:41 (pb.webserver1) any->/var/www/logs/blog.log Rule:9502 (level 3): WordPress authentication succeeded. IP:47.180.59.33 / USA / California 2018-12-01 01:59:40 WordPressAudit perebzox.com tony@perezbox.com : Notice: , User authentication succeeded: administratorFrom here you can tune and create your own alerts.