Tag: Incapsula

Back in November we discussed evidence we had found that indicated that the web security company SiteLock’s TrueSpeed CDN and TrueShield Web Application Firewall services were actually provided by another company Incapsula, while SiteLock made it sound like they are providing them directly. At the time we mentioned that is “troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved”. It is also troubling to think that a security company would be lying to their customers like that, since a big part of security is trust. If they are lying about something like this, where we don’t see why they even would need to, you reasonably have to wonder if there is something they wouldn’t be willing to lie about.

A recent post on SiteLock’s blog provided further confirmation that these services are actually provided by Incapsula while at the same time making it sound like SiteLock is providing them directly. In the December 18 post SiteLock TrueShield Updates they let their customers know of new IP addresses being used by those services that some of their customers would need to whitelist. Those IP addresses are

107.154.129.0-107.154.129.255
107.154.192.0-107.154.192.255
107.154.193.0-107.154.193.255
107.154.194.0-107.154.194.255
107.154.195.0-107.154.195.255
107.154.196.0-107.154.196.255

If you look up who those belong to it is Incapsula: example 1, example 2, and example 3.

In the post there is no mention of Incapsula, but they is plenty that would make you think that SiteLock is actually providing the services. In a large font they refer to the IP addresses being used by the services as “ours”:

If you are adding our IP addresses for the *FIRST TIME* 

In explaining why the new IP addresses are being added they mention their servers and IP address, despite those pretty clearly being Incapsula’s instead (emphasis ours):

The SiteLock servers periodically make requests for updated content from your website’s hosting server. This ensures that we are delivering the freshest content to your visitors. During periods of high traffic, we may make more frequent requests for content than during off-peak periods. Cloud technology of this kind uses a finite number of unique IP addresses to fulfill these requests, making this behavior appear as a security threat to some firewall services. This can be due to the large number of requests from a disproportionately low number of perceived unique visitors. Whitelisting or creating firewall exceptions for our servers’ IP addresses prevents your other security systems from blocking legitimate traffic relayed through our servers.

If we were not already familiar with a litany issues with SiteLock (you can see some of those by looking over our previous post about them) we would say this would be a good reason to avoid them, but with all the others you should have more reasons to avoid them then you should possibly need.

In looking in to some things for recent posts about SiteLock, their web application firewall (WAF) had come up a number of times and that then made us recall that previously it seemed that service was actually provided by the company Incapsula. Looking at the page for the service there was no mention of that or anything that might indicate that SiteLock was not providing the service themselves. The only mention of Incapsula on SiteLock’s website according to Google is them being cited in a couple of blog posts. The same holds true for mentions of SiteLock on Incapsula’s website.

So were we confused in thinking that there was connection between the two companies or have they just hidden it away from the public (like how one of their hosting partners wouldn’t admit to the ownership connection between SiteLock and them)? A little more looking showed the connection actually existed.

The True Provider of TrueSpeed CDN

Doing a traceroute for www.sitelock.com showed their IP address to be 199.83.134.143, for the which the canonical name is 199.83.134.143.ip.incapdns.net. Incapdns.net as in Incapsula, which you wouldn’t expect since you expect that SiteLock would be using their own TrueSpeed content delivery network (CDN) to serve their website. Next up we did a traceroute on their WordPress focused sub-domain wpdistrict.sitelock.com, which showed a canonical name of iasx4.sitelockcdn.net and an IP address of 192.230.66.155, which in turn has a canonical name of 192.230.66.155.ip.incapdns.net. We then looked at several of their customers websites listed in case studies on wpdistrict.sitelock.com and found they were running through Incapsula as well.

From all that it is clear that the TrueSpeed CDN is actually being provided by Incapsula, which you wouldn’t have any clue if you looked at how SiteLock describes the service. One part of the description that stood out for us was this:

Dynamic Content Caching

SiteLock patent-pending technology continuously profiles website resources, gathering information on how content is displayed. Static content can be safely cached. Some dynamic content might change continuously, while other content might rarely change or change only for specific users. This information enables truly optimized caching, and ensures content that is rendered is accurate—a premium feature you won’t get with most content delivery networks.

To claim you have a patent pending certainly makes it sounds like you provide the service yourself. But a quick search pulled up a PDF datasheet for Incapsula’s Content Delivery Network, which pretty clearly is the source of material on SiteLock’s page, with some rewriting of the text having been done. Here is relevant section from Incapsula’s document:

Dynamic Content Caching

Patent-pending advanced learning algorithms continuously profile website resources, gathering intelligence on each resource. Some of these resources, which may be dynamically generated, rarely change over time and for different users. This intelligence allows for optimized caching and ensures resource accuracy.

SiteLock’s lack of truthfulness to their customers about this is pretty troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved. Even if there is no concern about Incapsula, SiteLock could always switch to some other provider without notice, that isn’t as trustworthy and their customer could find that out too late.

This definitely is something that should make people avoid SiteLock, as trust is so important when it comes to security companies.

What About TrueShield Web Application Firewall?

Our looking into a connection between Incapsula and SiteLock started with looking for a connection with SiteLock’s web application firewall (WAF), so is that also provided by Incapsula as well? The circumstantial evidence points in that direction, but there was no smoking gun that we have found so far.

From a practical stand point if you are already running the website’s traffic through Incapsula it would seem to be easier to use their existing WAF in their systems than creating your own and then integrating that in to their systems, if they would even allow it. SiteLock’s CDN and WAF were introduced at the same time, so that would certainly fall in line with the possibility of them having the same source.

Here is the screenshot of a report from SiteLock’s WAF from the service’s page on SiteLock’s website:

And here is a screenshot of a report form Incapsula, also related to “Bot Access Control”:

The data presentation is quite similar between the two of those, which we have hard time believing could have been coincidental.

Know Something More About The Connection Between The Companies?

If you are aware of additional details related to the connection between SiteLock and Incapsula please leave a comment.