Logs: Understanding Them to Better Manage Your WordPress Site

Robert :    I’m Robert Abela, a CEO and founder of WP White Security. A bit about myself, I started working with WordPress in 2012. I found out what about WordPress, through previous job, we needed a blog for our website and we found out about WordPress and I’ve been hooked since then. I founded the WP White Security and 2013 because back then security… There wasn’t much security awareness and in records. In fact, as I was telling Aisha, I remember actually Tony and then starting securely. I spoke to them in the very first, it was their first year together. We develop a number of niche WordPress security and admin plugins. Our flagship product is WP security or this lock, which is a plugin that keeps an activity lock on WordPress. This is what we’ll be talking mostly about today. We also have a website’s called. WP security vloggers dot com it’s a curated aggregate of WordPress security news, and from there’s our websites on it. There’s several other WordPress security publishers and the idea is to have all the news concentrated in one place.

    Today, in this webinar we’re going to talk a bit about logs. We’re going to explain what logs are, the different types of logs WordPress website administrators have access to and can use, and how logs can help us better manage the WordPress website and its security.

    Let’s start with an introduction. What are logs? Basically logs are a chronological record of events that happened on our software or hardware. Anything you use nowadays, which is smart, your smartphone, your laptop, the server on which records run on the apps, on your smartphone. Most of them have logs, even the operating system on your laptop at church. Even smart devices like smart fridges, your wifi router, they all have logs. Even the websites you access like Facebook, Google and any other websites. They all keep logs to see what’s happening on their website.

    Why do we keep logs? There are a few uses for logs. Most commonly, logs are used for marketing. As I was just saying, a marketing teams use logs to see how users are using a website or a particular software, and they learn how users are using it so they improve the website or products. We use them for user accountability. To keep a record. For example, on an eCommerce website, you need to keep track of what shop managers are doing, when orders are placed, who’s handling orders, activities. We use them for compliance, many compliance regulations require actual businesses. So keep a log of what’s happening on their network, on their websites, on all of their IT systems.

    We use them for troubleshooting. Many administrators and also developers use them for troubleshooting. For example, if you ever had a problem with a plugin, most probably end up contacting support department, they typically ask you for logs because from the logs they can see actually what went wrong with the application.

    And of course we use them for security and this is what we’re going to focus most on today. In fact, to highlight how important logs are in security. I like to use a quote from the PCI DSS security compliance, which says “logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of the data compromise,” or a hacker. To me highlights how important logs are.

    So now that we know what logs are, let’s see what logs you have access to, what logs you can use as a WordPress administrator. We have the web server service logs, so basically WordPress is our web application and this hosted on apply shore and engine X web servers. There are more web servers but mostly it’s hosted on engine X and APUSH, and both these web servers have the access log and the error log.

    The access log, you can find information like who’s accessing your website. You can find information like the source IP address, the date and time on the accesses, to the request they are sending, the page they are requesting, how long it took the website to reply, et cetera. In their log file, you’ll find all the errors that the web server encounters, you’ll find the record of errors the website encountered while logging the configuration, errors the website encountered while trying to access the application or execute something et cetera. So we’re going to see later on how we can use this information.

    We also have access to the FTP and SFTP logs. The format of these logs vary depending on which service or vendor use, but typically these logs are pretty straightforward. From here you can see who logged into your website via FTP or SFTP, and from where, which IP address, the date and time, and which files they edit, modified or deleted. There are also the firewall logs, it depends on which firewall you use and what type of firewall. But typically, in all firewall logs, you can find out information about which requests were allowed and which requests are blocked and why they were blocked.Last but not least, we have the WordPress or the flux, also known as activity logs or auditorius, there are several names to it. It’s important to point out that by default, WordPress does not have any other flux. So you need to start with the plugin, like WP security or the which is a plugin we develop. Also securely have some logging as well in their plugin.

    What’s the role of logs in security? It has to be grows, so logs can be used and proactive security and reactive security. Proactive security, is being proactive, is basically studying the logs, analyzing all the logs and learning how attackers or hackers or even your users are using your website. You can see for example, if there’s currently a vulnerability being escorted in the wild, you can see that in the logs and your website is vulnerable or you have some issues. So basically while you’re analyzing the logs, you learn from the logs and you improve your defenses. So if you don’t spot a specific, for example, pattern or specific someone’s trying to exploit that specific vulnerability. You can update your defenses, your firewall to pro X to improve the security of your website.

    Reactive security from the other way around. In the unfortunate case of a hacked website, it’s about forensics basically. You’re using blogs, so try to learn, basically, try to understand what happened, how the attackers, what vulnerability, they exploited, how they made it in to the websites, how they hacked. What files they changed, maybe what they injected, etcetera. It’s very important because from here you can find out what happened exactly. You can find out what was the security hole, which you can close, of course and restore your website. Another important, quote about logs, “logs are a great asset as long as you know what you’re looking for”, which means you can have gigabytes of data, unless you know what you’re looking for, you won’t get good results. You really need to understand your logs, so you can extract as much information as you can from them.

    Let’s start now, what’s can we find in the logs, what information can find in the logs and how can we use it and what to look for in the logs. So let’s start with the WordPress audit logs. In the audit logs, it depends on which plugin you use, but in general it’s about the record, they keep a record of what logged in users are doing. When someone logs into your dashboard or if it’s a customer, for example, on Ecommerce sites looks into the portal. They keep a log exactly of what users are doing there.

    They usually have, depends on the plugin again, but you can find information about user sessions, who logged in from where and what time, and the IP address firmware. You can find some plugins also, apart from keeping a log of logged in users, they also keep logs of other extra information. If there are any request or non- existing pages etcetera.

    What should we look out for in WordPress? Audit logs, We should look out for failed logins and requests on non-existing pages, which results in 404 errors. Basically these two can be assigned…Failed logins can be assigned of brute force at tech and requests from existing pages can be assigned, of an automated scan. It’s very important to point out not every failed login or not every request, or non-existing page is a sign of an automated scan or a brute force attack, actually they aren’t, in fact, it’s very normal. When you have a website you’ll see a few failed logins everyday. You will see a few scans every day or every week. There are lots of automated bots on the internet, which are just scanning websites randomly trying to find security issues on these websites, on an unidentifiable website, so don’t panic. Don’t alarm yourself if you see a failed login or a few requests from non-existing pages.

    It becomes a problem when you see thousands of requests within a short span of time. For example, you see thousands of requests within a minute from the same IP address or from a range of IP addresses, then yes. Then that’s a sign that most likely there’s someone specifically targeting your website.

    Other things you should look out for in the logs? Abnormal user activity, login outside office hours, activity from unusual IP addresses or regions. For example, if all your employees are based in the U.S and in the UK, if someone is logging in your websites from any other country, then that might be a… that’s something you should check.

    Changes to the site structure or site settings. By size structure I mean, installing new plugins or updating something or the our changes in the team. That’s very important, that those could be signs that something is happening there, something malicious. But it’s not always malicious. It can either be an authorized change, so it’s cause something that you authorized but there will be a log of it. But if it’s something you did not authorize, then of course you should look into it. Content changes are very important, especially when malware’s injected. The first thing they do is, they either inject it in the team, find the actual code, PHP or a file. Or if they manage to gain access to the dashboard, they can change the content.

    When they inject malware content, usually it’s injected and the

Robert :    The top layer of pages, like the homepage or a first layer page. It’s very rare, but you see more injections, like in some forgotten page because of course they want- they want to inject [inaudible 00:12:14] on your most popular page. So that’s about it, about WordPress or the clogs. And now we’re going to look why we also need to look into do observer look phase. So basically as I was saying, WordPress is a web application and it’s run as one web server. So every request that is sent towards your website, it’s first received and parsed by your web server. The website sends it to WordPress, WordPress sends it to the database and sends the query to the database. And once the, once WordPress has the response from the database, its forms the HTML, sends it to the web server and web server sends it back to the- to the user who’s requesting the page.

    So basically the web server is the point of contact between your WordPress website and the visitor. So anything that goes through the web server, there’s a log of it. And that’s why the observer logs are very important. So in the access lock file, you going to see every log, every parse, HTTP requests, the observer. So, anything that is being requested from your website, there’s a record of it in the access log file as well. Of course the access log file is not aware of if a users locked in or no in WordPress. So that’s why there’s the WordPress audit logs. These are specifically the HTTP requests, like the anonymous data would say. And there is also the error log files and the error log files we’re going to find configuration errors. So basically if there’s something wrong with the configuration of the website, of the web server, parsing requests errors. So if someone is trying to send some malicious requests to your websites, those won’t, especially if the websites responds with an error or it generates an error, then of course you’re going to see that in your log files.

    And in most cases the PHP and application errors are logged in the web servers or log file. So what should we look for in the website for log files? Similar to the WordPress or this logs, they’re kind of like work hand in hand, signs of automated scans and requests to non-existing pages. As I said before, don’t alarm yourself. You will always see a few requests of these type of requests. So not every scan as something to align yourself with. The problem is when you see like thousands of requests, that’s when it becomes a big problem. Exploitation of specific vulnerabilities, which is very interesting. So for example, when there was the symptom vulnerability, a widespread, you could- the the way the attackers approach, they use automated tools, they send specific query, specific requests to our website. And depending on the response, they can determine if it’s vulnerable or not.

    So basically- so from the logs you can actually see some patterns. You can see, you can notice some patterns say, OK, you can notice that someone is trying to exploit a particular vulnerability. You can find a lot of information online. Even white papers with examples like of what type of payrolls are used, what type of requests are being sent to explore specific vulnerabilities. So, so yes, you can learn a lot from the logs actually and you can understand how they’re trying- how someone is trying to break into your website or use your website, and the application at PHP errors go hand in hand with specific vulnerabilities because usually, not always, but when you’re trying to exploit a vulnerability, the type of error you receive back from the web application kind of indicates if a web application is vulnerable or no. So basically from the error log files you can see maybe the request doesn’t seem malicious but then it creates- it generates an error, so of course from the error logs you can see if the application itself is generating any errors or if there are any PHP errors.

    So the audit- the WordPress audit logs and the web server log files are I think two of the most valuable log files you can have access to. And there’s a lot to learn, both in terms of proactive security and also reactive security. Then there is the FTP SFTP log files. These are pretty straight forward usually. And the format of the logs depends a lot on the vendor, but the information is pretty straight forward. You find the date and time, IP address, username which was used and the files, which they edit, modified or deleted. And then there are the firewall logs, similar to FTP logs, it all depends on the vendor and also what type of firewall used. But from here you can see the list of blocked fi- of blocked connections and list of allowed connections. It’s very important because- they are both very important because from the list of block connections you can see why they are being blocked and what trends they are and maybe being proactive, learning what type of signatures are being used, what type of requests are being sent so you can improve your firewall configuration.

    And list of allowed connections is also very important because there are some cases, for example, where a legitimate user is accessing a page which he’s not supposed to, which he shouldn’t have access to. So, through the logs actually you can find out, even through the WordPress audit log, plus firewall logs, like for example that’s- there is an admin area for example, or a business or service area that anonymous users are accessing. So it’s important to use not just to improve our defenses but to also learn about your applications configuration, that it’s configured correctly. And of course it helps you harden your setup. I’ve used Sucuri myself and I still use it for some websites and yes, actually if you go to the Sucuri dashboard they have a very interesting- their firewall logs are very interesting. You can actually see request by request, why are they blocked and you can actually see the details like the requests, what they’re trying to do and they also have [inaudible 00:18:23] like links to learn more about that specific request. So those are the logs you have access to which are the WordPress audit logs, the firewall, the FTP/SFTP and also the firewall logs.

    On the web server on which WordPress is running, there are many other logs. It depends if you have the dedicated server, you have access to these logs. If you’re using a managed WordPress hosting, most probably you don’t have access to, but if you have your own web server or FAPS, there is also the syslog which is the operating system logs, or like where the core services keep a log. The SMTP/mail server logs, database server logs, authentication logs, there are quite a long- there’s quite a long list of logs as such. You don’t need- as a WordPress site admin, you don’t need to really refer to these logs, but if you have your own server or FAPS, it’s- if you have time it’s interesting to take a look at it. You can learn a lot from this, from these logs. For example, how you can use them for the hardening of the web server. You can use the logs, the syslog, and the service officers to understand and learn which ports are open, which services are running.

    Maybe there are some services which you don’t need because it’s a default. A default operating system install is just a default and you might, you might not need, for example, the FTP server or you might not need the SMTP servers in this case ID and you should just shut it down. So that’s why it’s important to analyze all the logs because you learn a lot about the server itself. But then again, that’s server hardening and it’s a totally different subject. So now, that’s when I’ll know what information to look for in the logs or basically where to find some information. Let’s see how we can make sense of all the data. So what should we do? Ideally we should review the logs often or for you? It depends how much you have time. But ideally, yes, we should review the logs and act on what we see.

    So basically for example, if in the audit, in the WordPress audit logs, you want to see all the failed logins for a specific user name. It might be a sign that that user is targeted, it might be a sign- check with the owner of that user, scan his computer for viruses to reset the password, change the username if need be, and keep an eye on the activity specifically of that user. Maybe there’s something wrong with the computer, which the owner of the [inaudible 00:20:58] is to access the website. Unauthorized access as I was saying before, maybe you have an eCommerce websites and someone, some shop managers or some managers shouldn’t have access to specific products or specific settings of the eCommerce solution. So it’s important to analyze these logs and basically keep on tightening the security of your website and making sure, of course, everyone has access to what he needs to. It’s important to use the principal office privileges, so basically just ideally you should always close everything and then start allowing access rather than giving access- rather than giving a user access to everything and then start shutting it down.

    Brute force attacks- in case of brute force attacks as such, there isn’t much to do as, it depends if you have an online firewall like Sucuri, I mean I’m sure Sucuri handle these things, but if you have your own firewall or your own firewall team, speak to the firewall team to take care of the brute force attack. Unauthorized site changes- whenever you notice unauthorized site changes, take a look, make sure, verify that they, maybe someone updates the plugin or someone who saw the plugin and they didn’t tell you about. Maybe it’s legitimate. So that’s why it’s very important to always, when you spot these things, always double check with user. We’re looking- now looking at the other aspect of logs, hacked websites, what should you do when a website is hacked? The theory is very easy. Study the logs, trace back the activity, find the source of the hack and fix the security hole. And in reality it’s quite, it’s quite difficult. Although if you get used to the logs, it’s not that diff- it’s forensic work.

    So basically first of all, I work with a tech. Usually it doesn’t consist of one vector. There are a lot of vectors, a lot of things happening. So no one just hacks the website straight away. So for example, first day they scan the website, then they identify a vulnerable login like for example, a plugin which is vulnerable to SQL injection. Then they exploit that SQL injection. Maybe they managed to by exporting the SQL injection they managed to create a user directly in your WordPress database. Then they use that user to log to your websites, access the files, change the content in [inaudible 00:11:23].

    So how do I find all this information in the logs? This scan and the exploitation SQL injection, that’s where the web server logs come in, both the error and access log files. You find out information there. Like which vulnerability was exploited, what requests they sent. Maybe it depends on the verbosity of the logs cause that’s configurable, but you can find maybe information even about the requests, the payload and what they sent, et cetera. And then of course, once you find that you’re going- you find out that for example, they are [inaudible 00:23:56] and SQL injection vulnerability and they created a user, then of course go to

Robert :    So this is where I press on this box to find out when they they did log in with that user and what changes they’ve done.

    So, it’s important… one log is not enough, the audit logs alone are not enough, especially in forensics. The web server logs alone aren’t enough, the FTP logs alone aren’t enough. But if you use them all together, and draw a picture through them, like study the logs and draw a picture exactly of what happened, you can get very good results in identifying actually what happened, which issue what exploited. Which helps you basically to close the security issue and restore the website.

    One of the most common questions we get… Okay, I installed the logs plugin, or I’ve been reviewing the logs of the web server, how do I identify abnormal activity? And, as such, there are no blueprints, because every business is different, every website is different, they have different users and… So there’s no blueprint, there’s no rule on what to look for.

    However, you know your website, as an administrator, and you know best. So the more you know about your website, you know what versions of software you’re using, you know what versions of plugins, which team, what functionality, maybe you have a custom application. You also know what time users simply log in, whatever the user is supposed to do, from where they log in, what’s their typically day at work on the website. So the more you learn, the more you understand what’s the norm on your website, the easier it is to identify abnormal activity.

    If you don’t understand what’s on your website, who should have access to or who should log in from where, then of course you cannot identify abnormal activity. So, this kind of somehow work when you review the logs, you should of course learn a lot about how your website is actually used.

    It’s very important, when in doubt, always ask the user. That’s the [inaudible 00:26:05]. One thing I’d like to point out is, I’ve pointed out a couple of times, that ideally you should review the logs. Having said that, I understand that most of us are busy with a lot of things. So, even though reviewing logs is one of the most recommended security based practices, not everyone does it or not everyone has the time.

    And that’s where automation is a must. So basically it’s important to use a firewall. By the way, when you use a firewall, it doesn’t mean you shouldn’t update your software or just ignore all the security best practices. But it helps to use a firewall to protect your website.

    And of course, enable logs, enable the WordPress logs, enable the firewall logs, make sure that any service you run, if you have your own web server or GPS, enable the SMTP server logs, if you have an SMTP server, FTP. It’s very important to have all the logs. Set up notifications, that’s where the logs, firewall logs come in handy. So if they spot if something is irregularity, they alert you.

    For example, if usually all your users login from a specific IP address, from the office IP address, no one works from home, then yes, you can set up alerts. So if there’s a login which is not from the IP address or is not showing a specific time of the day, then you should get alerts and you should just check. It might be legitimate, but it’s good to check and confirm that it was a legitimate activity.

    And last but not least, of course, a good backup plan always saves the day. Besides privacy, a good backup plan, if something goes wrong, even the website is hacked, rather than trying to manually reverse engineer the codes… Of course you should do it just to learn what happened… but a restore a security issue is a much faster way to get your website online.

    From my end, that was it. Thank you very much for tuning in and I’m handing over to Alicia.

Alicia:    Awesome, that was really really great. Honestly there was so many awesome things there that I can’t really point out one specific thing that I loved.

Robert :    Thank you.

Alicia:    We did get some questions from the audience here.

    So we have one from David here, and he’s curious to know where are these WordPress audit logs found, are they in with the public HTML holder, or do you need to use a plugin to access them?

Robert :    Yes, so by default WordPress does not generate activity logs. So you need a third party plugin. So for example if you install the WPWhiteSecurity log or you install the Sucuri plugin, you can see the plugin interface, both for Sucuri and our plugin, and also other plugins. Usually it’s in the WordPress dashboard.

    Typically, logs in WordPress, they are written in the database. There’s a reason for that of course, performance and all these things. So typically you need to access the WordPress dashboard and then use the application like the Sucuri plugin interface or our plugin interface to give you those logs.

Alicia:    Awesome, yeah, that seems like an easier way to go about it anyway.

    Another question we had was how long should we be keeping these logs? Should we be clearing them, is a year’s worth of logs decent enough?

Robert :    Very interesting. It depends on what your requirements are. If it’s not an issue, if it’s not an overhead for you, keep as much logs as you can.

    It depends on the business. I know a lot of businesses, especially in the finance industry, they are… because of regulations, they have to keep logs, especially the banks, I think up to eight years or something. Ecommerce websites, they have to keep logs… I’m not sure exactly about the numbers, but GPTR states that you have to keep a log.

    I don’t know, the extent. But you have to keep a log who is accessing records, so then of course if something happens, if someone complains one year later, if you have the logs you can save the day. If you don’t have the logs…

    So, the more you can keep, if it’s not an overhead for you. The more you can keep, the better it is.

Alicia:    Awesome. Is there any impact of having these logs on the web server? Does it impact the web server or any other software?

Robert :    Not really. Logs typically are considered as a core [inaudible 00:30:13] servers, hardware engineers it’s pretty powerful. So they don’t.

    So if you look at WordPress for example, the audit logs, 99.9% of the audit functionality focused on what logged in users are doing, when they are logged into their website. So even if let’s say they slow down by… they don’t, because we will have tests. But let’s say they slow down by a few milliseconds. It’s not noticeable by the user.

    Again, it’s working on the dashboard, writing an article on schedule. It doesn’t affect the front end.

    The web servers, again, it’s built in functionality, it’s been there from day one so it doesn’t. But you can, of course, go in the audit logs or the WordPress audit logs. Also, the web server, you can configure the verbosity. Of course, the more verbosity you want, especially with the web server… if you want the web server to keep a copy of the requests… especially with web servers there are writing to a locked file, not a database.

    When we say it slows down, especially if we have caching [gadget 00:31:13], these are non-noticeable things. Actually, you won’t notice them with your own eyes. But, if you look at the actual numbers and milliseconds, it might make a minor difference. But it’s not something that should actually affect the usability of the website.

Alicia:    Awesome. I got a really interesting question here, actually about compliance. So if you’re keeping a log of users and what they’re doing, does that have any impact on GDPR compliance or anything like PCI?

Robert :    Yeah, we’ve been asked a lot because GDPR is, especially in Europe, is all about privacy. So there was a bit of misunderstanding, like what if I keep the IP address because… I think in Europe it’s considered as an identifiable piece of information.

    No, to actually affect GDPR, and even like PCIDS tests and all others, require you to keep the logs of what’s happening on your website. Because if something happens, of course you have to prove that you were taking the necessary precautions, that no one was accessing the sensitive data.

    What’s very important of course, it’s in the privacy policy. If you’re keeping logs, especially the WordPress audit logs, you’re keeping logs of your own employees and your own users, not the actual person who is visiting the website. So you’re not keeping a log of www.security.com, that’s anonymous. But if you’re keeping a log of who logged into the firewall, and who is seeing that, then of course there’s a username there.

    What’s important is in the privacy policy you specify that you are actually… there is a log being kept, and it’s only being used in case the information is needed.

Alicia:    Awesome, that’s amazing. Quite the opposite than what you’d think. Yeah, it’s actually important to be complaint to keep those logs.

Robert :    Exactly, yeah. You have to be complaint, you have to keep the logs. What’s important of course, especially with employees, is that you advise everyone what’s happening. It’s very common, you see it even with the CCTV cameras, if you go into an office usually, you see CCTV in operation. That’s the most important, though, that people know what you are doing.

Alicia:    Awesome. Great, well I think that’s it for questions. Thank you again, Robert, so much for joining us. We hope to have you back on the webinar series again. And if you have any other questions, feel free to tweet @robertabela or @wpwhitesecurity, or to us @SucuriSecurity, and stay tuned. We will be sending you guys an email with all of this later, and thank you again Robert.

Robert :    Thank you very much, thank you Alicia. Have a good day.