When cleaning up a hacked website there are three main components to doing that properly. We often find that security companies don’t do two of those. One of them being trying to determine how the website was hacked. The other being getting the website secure as possible, which usually involves getting the software on the website up to date. If a company isn’t able to make sure the software is up to date, it seems likely they also are not familiar enough with the software that they should be dealing with hacked websites running it.
One well known company that usually skips doing those things is Sucuri. They promote as alternative to doing that securing, that you can rely on the virtual patching provided by their website application firewall (WAF). There are a number of reasons why that is bad idea, including that they don’t present any evidence, much less from independent testing, that their virtual patching is effective (they also don’t present any evidence that their service is effective at protecting websites in general). Probably the largest problem with relying on that though, is that it can be incredibly easy to go completely around their WAF, leaving websites that haven’t been properly secured wide open to being hacked.
Before we get in to that, what lead to us writing this post was our recent experience with their WAF making it harder to get a website secured.
We were recently brought in to upgrade a Joomla installation on a website that Sucuri cleaned but had failed to upgrade the software on it. When we went to do that upgrade we ran into an error, “ERROR: AJAX Loading Error: Forbidden”:
That error message doesn’t provide much information on what was going wrong and we would guess that others that run into it might get stuck at that point. In debugging that we found that when an AJAX request was made to /administrator/components/com_joomlaupdate/restore.php the response being received was this page:
At that point we could have contacted the person we were dealing with from the website and get them to try to whitelist our IP address, but there was a far quicker solution, simply bypassing Sucuri’s WAF, which can be incredibly easy to do.
Here’s is how Sucuri explains how their WAF works:
The reality is that all HTTP/HTTPS traffic does not have to begin where they show it beginning in that graphic, instead, if you know the IP address of the Original Host you can connect directly to it, bypassing the WAF entirely.
While in something we will get to in a moment, Sucuri refers to this IP address as being “hidden”, in reality it often isn’t hidden at all. In the case of the website we dealing with we just pulled up the DNS records for the website and the second IP address (after the Sucuri one) was the Original Host’s IP address (there was another equally easy method available as well). By simply associating that IP address with the domain name in a computer’s host file the Sucuri WAF can be bypassed.
From previous real world experience we can say that people will in fact rely on Sucuri’s WAF to keep them safe instead of keeping software up to date, which can leave people wide open to attack if someone just takes time to bypass the WAF. What makes that particularly problematic is that a website could appear to be secure for a long time, leading to people claiming that Sucuri’s solution is effective, and only later it becomes clear that things were not as how they seemed.
Here’s what makes this even more troubling, Sucuri is aware of the ability to bypass their WAF, but they either don’t understand that their attempt solution to stop that doesn’t resolve the issue or they don’t care that that what they are providing is fundamentally insecure.
The page Prevent Sucuri Firewall Bypass on Sucuri’s website begins:
If someone knows your hidden Hosting IP address, they can bypass our Firewall and try to access your site directly. It is not common or easy to do so, but for additional extra security, we recommend only allowing HTTP access from our Firewall.
The best way to prevent hackers from bypassing our Firewall is limiting their access to your web server. To do this, all you have to do is add restrictions to your
.htaccessfile so that only our Firewall’s IP will be able to access your web server.
As we already noted, the IP address isn’t necessarily hidden at all. Calling attempting to prevent the easy bypass as “additional extra security” as opposed to being essential, doesn’t provide much assurance that they actual are concerned about the security of websites using their service.
The larger issue here is that trying to restrict what IP address can access the Original Host directly isn’t very effective. That is because all someone has to bypass that restriction is to spoof a permitted IP address, which involves making it seem a request came from a different IP address than it really did. Either Sucuri doesn’t understand that or doesn’t care that their WAF is fundamentally insecure, neither of which should be true about a security company.
Their a major limitation with spoofing an IP address that is important to note though, which is that any response would not be sent back to the system sending the spoofed requests since the response would be sent back to the spoofed IP address. But with the kind of vulnerabilities we see actually being exploited on websites that often wouldn’t be an issue since the hacker doesn’t need to receive a response to gain further access to the website. Oncee they have access they could remove the IP address restriction or send any responses they need in way they can still access (say writing them to a file accessible through the website).
While we wouldn’t recommend using Sucuri’s WAF (or their services in general), if you are using it, restricting IP addresses as suggested in that previously mentioned article would provide better security when using their WAF.
A Better Alternative to Sucuri
If you have a website that needs to be cleaned up from malware or another type of hack, we provide a better alternative to using Sucuri, where we actually fully and properly clean up the website.
What you have basically said is that Sucuri sucks because it did what it is supposed to do, and blocked you, thus making it harder for you to do your job. That is what is known as an oxymoron.
No company is perfect, they all make mistakes, they all provide shitty support every so often and get bad review. But I have been reading a few articles on your blog today, and as someone who does have a bit of a clue about security, i’m afraid it just comes across as “I hate Sucuri and WordFence and think I am so much smarter than them, so I am going to bash them for every petty, nit-picking reason I can think of”. And I can see from other people’s comments on other posts that I am not the first one to notice this.
Your articles would be far more productive and digestible without that bitterness.
While what you say about being able to bypass the WAF is true, this is how any remote WAF service is going to work because they are remote, they have to accept all the incoming traffic and then proxy the request to your hosting provider over the Internet. CloudFlare works the same way.
The only way to avoid this is to run your WAF locally so that traffic is proxied over a private IP and cannot be bypassed. Obviously, it is not possible to do this with the type of service Sucuri provide, and most people with a website on shared hosting do not have the necessary skills to do that and probably cannot afford to pay for a dedicated solution and someone to manage it, which is why they use the likes of CloudFlare or Sucuri. So bashing Sucuri for this is rather pointless and quite petty.
IT is rather like bashing a taxi driver because he cannot get you to your destination as fast as a plane.
If the real IP address is that easily found, then someone has not done their job properly when setting up Sucuri to begin with. As there should not be any records showing the real IP, that is the whole point in hiding it. So the real fault here lay with the person who set it up.
So this failure was the only reason you were able to so easily bypass the WAF. Otherwise, you would have had to contact your client and ask them to whitelist your IP or get the REAL IP from them.
Without that information, you would first need to find out who the hosting provider is, then find out the IP’s for their shared hosting servers, and then test each one to find out where your target site is hosted. Yes this is trivial to someone who knows how to do it, but it is a manual and time-consuming task.
So while the remote WAF proxy solution may not be perfect, the service does thwart those common every day automated attacks and the unskilled script kiddies that are not going to be able to find out the real IP and bypass the WAF. This is sufficient for most small websites. Such a service would not thwart a determined hacker, but then a determined hacker is probably not going to be wasting his time on $10 shared hosting sites anyway.
Any enterprise organisation with money to spend on a dedicated solution, really should not be using the likes of Sucuri anyway and should have a dedicated WAF and IDS proxied in front of their website, such as a Sophos UTM appliance.
No where in your comment did you quote what we actually said (while presenting something that we are supposed to believe in quote marks) and it seem the reason for that is that you want to criticize us for things we didn’t actually say. That starts in the first sentence where you state that we “basically said” “that Sucuri sucks because it did what it is supposed to do, and blocked you, thus making it harder for you to do your job. That is what is known as an oxymoron.” We have no idea why Sucuri’s WAF blocked us from updating the software, so we don’t know whether it was supposed to do that or not. Since we were not trying attack the website it was not stopping an attack, which is what it is supposed to do. Instead, it was stopping something that would have made the website more secure. Our point here isn’t that we are smarter than someone else (it isn’t clear what being smarter would even have to do with have better understanding of real world security), but that security solutions are being sold that don’t produce good results for the public, which it sounds like might be your real problem with what we wrote (and the reason for other negative comments we have received). The security industry makes a lot of money selling ineffective, at best, solutions, so anything that exposes that would be bad for them and would be an obvious reason for criticism of those pointing it out.
As for the other company you mentioned, Wordfence, they blatantly lie about the level of protection that their product provides. If you cared about security, as we do, it isn’t hard to see why you we would have a problem with that that has nothing to do with us believing that we are “smarter than them”.
Overall, your comment come across as projection as you are criticizing each part of our post, while claiming that we “bash them for every petty, nit-picking reason I can think of” even though the different pieces of your criticism contradict each other.
For example, here you claim that Sucuri’s service is for those that on “shared hosting” that “do not have the necessary skills” to set up a more advanced solution:
But then you claim that Sucuri shouldn’t be at fault because the person setting things up didn’t set things up right:
This website is on shared hosting and the maintainer wouldn’t have necessary skills to set up a more advanced solution, so Sucuri’s solution isn’t a good option for what you are claiming it is useful for, based on your own claims.
Another important issue is that you claim without any evidence Sucuri’s service will “thwart those common every day automated attacks and the unskilled script kiddies that are not going to be able to find out the real IP and bypass the WAF” and that it is “sufficient for most small websites”. As we recently discussed, not even Sucuri provides any evidence that their service provides real security. If you actually have some evidence we would love to see it. Websites would be able to “thwart” many of those “common every day automated attacks” by doing the basics, which includes keeping software like Joomla up to date, which Sucuri actually made harder here.
It would be rather easy for an attacker to automate bypassing Sucuri’s WAF, so even if currently low skill hackers are not doing that, that could change at any time. If it hasn’t happened, it would mean that currently Sucuri customers are getting a false sense of security that could lead them to not doing the security basics and then at a point down the road this could lead to many websites being hacked.
If you think that trying to help protect people from security companies trying to take advantage of them is “rather pointless and quite petty”, that says more about you than us.
I’ve seen a lot of posts on this site pointing out the weaknesses of other security software/services.
Ok, that’s fine.
But what about offering a recommendation of what security software to use?
Or perhaps some htaccess security?
You recommend keeping plugins updated and using a strong password, but surely there’s more that can be done to secure a website?
I would like to hear some proactive solutions!
Future post?
When so many people are not doing the basics, it doesn’t make a lot of sense to suggesting people do more, especially when those basics would actually easily prevent so many of the hacks happening now. For example, there are currently a lot attempts to exploit a vulnerability in outdated versions of Drupal and those attempts would be fully prevented by simply keeping the software up to date. But if someone were to look to suggest additional measures there is the problem that there doesn’t appear to be evidence presented that security software/services that claim to protect website are effective at that (and plenty that they are not), without that there doesn’t seem to be a point of using them. So if you want something more you should look for evidence, preferably from independent testing, that it is effective.
What about something that protects a site against known bad ips?
Wordfence makes a big deal about its real time ip blacklist.
Do you think that’s useful?
Or do you have a better suggestion for blocking access to a website for known bad agents?
First we should note that Wordfence blatantly lies about the level of security they provide, which seems like it should be the end of discussion about a security company, but we have seen no evidence that blocking IP addresses is an effective strategy. There should be evidence that supports a claim from a security company that something will help protect websites, otherwise the company making the claim, at best, likely, don’t know if it is effective.
There are some obvious problems with it as well. First, all someone has to do to get around it is to use an IP address that isn’t blocked. Also, whoever is providing the IP addresses blacklist would have to know what IP addresses to block. Since companies, including Wordfence, are not even aware that many vulnerabilities are being exploited, it would follow that there is good chance they wouldn’t know what IP addresses are being used to exploit those if they are not also used for vulnerabilities they are aware of. If you instead focused on doing the basics, in most instances it wouldn’t matter if a hacker’s IP address is blocked or not since even if they can access the website they can’t exploit it.
When so many websites are not doing the basics, it really doesn’t make sense to focus on things that are being pushed to sell security services, instead of focusing on what is guaranteed to help protect websites.
“First, all someone has to do to get around it is to use an IP address that isn’t blocked”
Wordfence say that’s why their blacklist is updated in realtime for premium users. They discuss this very point here : https://www.wordfence.com/blog/2017/11/should-permantly-block-ips/
“whoever is providing the IP addresses blacklist would have to know what IP addresses to block”
Wordfence, and Cloudflare also, state that due to the large size of their network they can monitor what ips are behaving badly and add them to the blacklist.
What Wordfence is saying makes sense to me. Have a blacklist of bad ips that is dynamic and constantly changing.
Do you still not agree?
I don’t expect it to be perfect, but surely it can help in reducing bot traffic to a site.
You don’t address that last issue on your site.
Websites often have a large percentage of traffic which is due to bots and not humans. And some website owners would like to avoid this for various reasons, e.g., analytics, server performance, host limitations etc…
Covering the “basics” as you say might be effective for security, but it does little to block bot traffic.
There are also many website owners who ARE doing the basics, yet want to know what else they can do to improve security.
It would be helpful if you offered suggestions for them also rather than dismissing things which could potentially offer another layer of protection, such as a dynamic blacklist.
I don’t use Wordfence, and i don’t really like them or Sucuri, that much after reading what you say about them.
But i suspect they do help to make a site more secure, so they might be worth a go regardless of my personal opinion about them.
Another option i’m considering is the premium Cloudflare WAF.
You are not presenting any evidence here, which is what should be the basis for any security claims. That is what you should be looking for with any additional security, instead you are focused on meaningless marketing claims. Considering that security companies lie all the time that isn’t useful information.
Updating something in realtime doesn’t mean in any way that it is going to have complete data, just that there isn’t a delay in getting new data, but that data could be of extremely low quality.
Claiming that “due to the large size of their network they can monitor what ips are behaving badly and add them to the blacklist” isn’t evidence that they actually are effective at doing that. When it comes to Wordfence though there is evidence that there claims like that are not true. They for example, market their paid service on a claim that they have “unmatched access to information about how hackers compromise sites”, but the reality we have seen for years is that isn’t true (we also are not aware of Cloudflare being any different in terms of catching vulnerabilities). If you are bad at that, it would follow that you wouldn’t have a good idea of what IP addresses are being used for malicious behavior
We are not in the business of dealing with bot traffic, we deal with hacked websites, so it wouldn’t make sense that we would be talking about that.
In dealing with hacked websites what we have seen over and over is that the basics are not being done and that is leading to websites being hacked. Spending our time to telling people to use additional layers of security where the isn’t evidence being presented that they are effective doesn’t make sense, especially since we see that those additional layers are not being used as additional layers, but instead of the basics, which has even lead to a security company’s website being hacked when it shouldn’t have been. Our focus is on keeping websites secure, not getting people to unnecessarily spend money on security products and services that can leave them vulnerable instead.
While we suggest you just understand that you don’t need additional layers to actually secure your website as the basics will take care of the things that need to be taken care of, if you want help with this you should hire a company focused on that, which will provide unbiased evidence based advice on something like that. The comments section of our blog isn’t going to be a replacement for that since we take a very different view to security.