One of my friend has an eLearning website based on Claroline. Two days ago, only Switzerland users started to get redirect "randomly" on another IP address when accessing the website domain.

If I force the DNS server to 8.8.8.8 or 9.9.9.9 on the students' PC, the domain is resolved correctly. But if I stay with the local Swiss DNS Server, it resolves to a bad (blacklisted) IP address.

The strange part is: It's not only this one customer and his own computer. Every student based in Switzerland is affected as well. But not French ones.

The second strange part is: Some page responds from this false IP address with the correct content. Like the eLearning was duplicated on another server OR cached somewhere.

The server is an old Ubuntu 10.04.4 LTS, and it is probably not correctly protected / configured. I have full access on this server, but I didn't manage it, so I'm not sure what to look for or even what to do.

Here is what I looked at/ tried so far:

  • Checked all Apache 2 vhost conf.
  • Checked iptables (empty) and /etc/hosts and /etc/resolv.conf (safe)
  • Asked Swisscom (main Swiss telecom) if they blacklisted the domain or something: Nope Checked claroline code base: it look safe, but it's huge. I can't check all files.

Here is a nslookup on one of the student Windows computers:

C:\WINDOWS\system32>nslookup
Serveur par défaut :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

> elearning.redacted-domain.ch
Serveur :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

Réponse ne faisant pas autorité :
Nom :    elearning.redacted-domain.ch
Address:  195.186.210.161

And of course, 195.186.210.161 is not the correct IP address of the server.

I'm not a system administrator. I'm just helping a friend, so I'm not sure on what to look next.

  • 1
    Perhaps it's possible the ISP of those students are attempting to perform some smart caching and so are interfering with the DNS. Are they all at the same university for example? If you utilise HTTPS for your server, then they can still modify the DNS, but the end user would see a certificate error if the DNS result is pointing to a server other than your own as they would not be in possession of the private key. – David Goate Oct 11 at 11:57
  • 1
    Also, are you sure the IP address of the server is static? For example if frequently changing or recently changed within the TTL of the DNS record then it's possible that the DNS is being resolved to an old (once valid IP) - although that wouldn't perfectly explain why they do see mirrored content. If you use a tool such as mxtoolbox.com/DNSLookup.aspx you might be able to see the TTL of the A record or CNAME record attached to the domain. – David Goate Oct 11 at 12:00
  • 1
    @DavidGoate That's the fun part, students are at home, all over France and Switzerland. The French one doesn't have any problem. – iizno Oct 11 at 12:03
  • 1
    @DavidGoate Server IP is fix and never changed. dnschecker.org/#A/elearning.affis.ch doesn't show any errors. – iizno Oct 11 at 12:08
  • 1
    Hi, another thing that can happen, as I seen some error like that in the past, it can be a badly maintained DNS server by the ISP. I seen DNS zone that was transfered but never erased at the ISP level, thus leading to strange error. – yagmoth555 Oct 11 at 12:33
up vote 11 down vote accepted

As MadHatter wrote, this is the end-users' ISP (Swisscom) re-routing your site through a filtering proxy. It is quite probably that all users subscribing to their Internet Guard service are actually proxied through there, not just your site.

They say that the filter is against malware, phishing and viruses, so it shouldn't be an issue of "classification", but one of security.

Your first step should thus be to check that the site has not been infected. PHP sites tend to be quite vulnerable (if someone finds a way to upload a .php file somewhere in the visible hierarchy, it can then be executed remotely to do anything they want). There are also many other ways to do harm (SQL injections, stored XSS...).

Your home page is not blocked, or at least not all the time, so either:

  • only some of the pages are infected
  • the infection only shows up a fraction of the time on user requests (a common strategy to fly under the radar)
  • or there is something else on some pages that triggers a false positive

You can see the result yourself by pointing the website's address to the IP address of the proxy. You can do that by editing your /etc/hosts file (details vary based on platform) and adding a line:

195.186.210.161        elearning.affis.ch

You can then visit the site as one of those users, and see which pages are blocked or not.

Once you have a better feel of what pages are blocked or not, it might be easier to pinpoint the actual issue. Then fix it, and either it will suddenly go through right away, or you may have to report a false positive (there's a link for that at the bottom of the "blocked" page).

Note that trying to report a false positive before checking for infection would probably be counterproductive. Try very hard to find and fix the issue first.

Edit

Note that the version of Claroline you run (1.11.9) has multiple XSS vulnerabilities known since 2014:

Multiple cross-site scripting (XSS) vulnerabilities in Claroline 1.11.9 and earlier allow remote authenticated users to inject arbitrary web script or HTML via (1) the Search field in an inbox action to messaging/messagebox.php, (2) the "First name" field to auth/profile.php, or (3) the Speakers field in an rqAdd action to calendar/agenda.php

If the issue is indeed a stored XSS attack, take the latest dump of your database and check if it contains anything like a <script tag (don't forget to search case-insensitively).

If you point a browser at the IP address returned, http://195.186.210.161/, you get Swisscom's "dangerous website blocked" message. My guess is that their "safe internet" content-blocking system works, at least in part, by lying in response to DNS requests, and that your website is falling foul of them, for some reason.

I understand that you asked them if they were blocking you, but in my experience even medium-sized ISPs' front-line tech support don't have the slightest idea what's going on out back. It's quite possible that the whole nanny system is outsourced (or done by a third-party commercial product) and that nobody at Swisscom has any idea which sites are blocked at any given time. Asking your student if (s)he has any kind of "nanny internet" settings on may be more productive.

At the end of the day, this may not be a problem you can solve, since you're not that ISP's customer, and they owe you nothing. Having the student's parent call their ISP support, complain loudly about wrong DNS resolution, and threaten to change ISP if it's not resolved, is likely to be the only thing that has any effect.

Edit: this thread suggests that Swisscom's site blocking engine can be a bit over-enthusiastic, and that it's not always easy to get any kind of positive resolution from them. It also suggests that this isn't an opt-in filter, but that it applies to all Swisscom customers whether they like it or not, so opting out of it may prove to be difficult.

  • 1
    That's why I think too but, why are some pages displaying the correct content and other just timed out. ? It's like they duplicate some pages. – iizno Oct 11 at 12:28
  • 7
    We don't know what they're using, so we can't know how it works. Maybe the first-line decision is taken at DNS resolution time, but the system at 195.186.201.161 implements a second-line decision based on what URL is requested, proxying through to the real server if and only if it decide the content is "safe". Once people start trying to bend internet protocols in pursuit of some (unattainable) vision of a "safe" internet, nearly anything can go wrong. – MadHatter Oct 11 at 12:31
  • 2
    It seems like a problem that could be solved with a lawyer in the right jurisdiction... – R.. Oct 11 at 14:15
  • 4
    If it is actually being proxied and scanned, forcing HTTPS could help (or hurt). The ISP would at least only have the choice of blocking the entire site or none at all rather than blocking some pages and not others. This may make things less confusing for users. – Joshua Dwire Oct 11 at 15:55
  • 3
    It's quite possible that the whole nanny system is outsourced (or done by a third-party commercial product) and that nobody at Swisscom has any idea which sites are blocked at any given time. I worked with a big telco that does exactly this, so can confirm. The ISP tech support probably has simply no way of knowing, however they should be able to open a ticket to whoever is actually running the classification system if there is any problem. – Bakuriu Oct 11 at 20:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.