Matomo kompromittiert?

Was ich nachfolgend von mir lasse, gilt bitte unter Vorbehalt!

Meine Firewall informiert mich immer dann, wenn wieder mal jemand versucht in mein System einzudringen oder sonst irgendwelche “bösen” Sachen versucht werden. In den Logfiles tauchen regelmäßig Angriffsversuche von Arubacloud auf, einem europaweit agierendem Cloud Anbieter. Meine Firewall entscheidet je nach Angriffsart, ob die jeweilige IP nur temporär oder dauerhaft geblockt wird. Nachdem die Angriffsversuche von diesem Netzwerk meine Blocklist zumüllen, bin ich dazu übergegangen gleich die Class C Netzwerke zu blocken, was auch nicht wenige sind, aber deutlich weniger als die zahlreichen IP Adressen.

Nachdem ich die Blocklist gesäubert hatte, stellte ich ein seltsames Phänomen fest und zwar bei jedem Aufruf des Dashboards in Matomo, das nun ewig lange braucht bis alles geladen ist. Größtenteils konnte gar nichts mehr geladen werden werden.

Um der Sache auf den Grund zu gehen, habe ich das SEO Plugin deaktiviert, das mir schon die ganze Zeit nicht ganz koscher vorkam. In jedem Fall als ich das Plugin deaktiviert hatte, ließ sich das Dashboard wieder ganz normal und ohne Verzögerung aufrufen. Nach dem an diesem Plugin Alexa dranhängt, kommt man unweigerlich zu der Schlussfolgerung, ob die Matomo Installation Daten an Alexa schickt?!

Man kann darüber denken, wie man will, aber es wäre dann schon angebracht, wenn man darauf hinweisen würde, dass sich Alexa der Daten aus der Matomo Installation bedient, zumal das auch nicht ganz in Ordnung geht mit der Datenschutzgrundverordnung!

[Update]

Das SEO Plugin ist unschuldig. Daran liegts nicht. Auch alle anderen Plugins von Drittanbietern scheinen sauber zu sein. Das Problem bleibt aber. So wie ich die arubacloud IP Netze in die Blockliste setze, steht das Dashboard förmlich still.

Hallo,

Das kann ich verstehen, aber aus vollkommen anderen Gründen: Es ist extrem simpel. Der Google-Teil davon ruft zum Beispiel nur die Google-Suchergebnis-Seite auf und liest die Anzahl der Seiten aus.

Und das Alexa-plugin ruft nur http://data.alexa.com/data?cli=10&url=matomo.org auf (was anscheinend nicht einmal mehr funktioniert. Ich habe mal ein github issue aufgemacht)

Also zum eigentlichen Problem:

Ich habe keine Ahnung, was genau bei dir auftritt. Ich kenne Arubacloud nicht, aber weiß, dass keine Matomo-Dienst dort laufen (sondern bei alwaysdata).

Daher bräuchte ich mehr Details, was genau passiert (rufen diese Server deinen Matomo-Server auf oder umgekehrt? Über HTTP(S)?) und welche IP-Adressen genau das Problem sind.

Wenn es das SEO Plugin wäre, was es nicht ist (siehe oben), dann erfolgt der Aufruf nicht bei jedem Aufruf des Dashboards, sondern wird ge-cached. Aber das SEO Plugin isses ja nicht.

Ich hab ungefähr ein Dutzend Class C Netzwerk Adressen, die ich grad Stück für Stück durchprobiere. Es sind offenbar nicht alle betroffen. Der Aufruf einer externen Quelle erfolgt in jedem Falle nicht über den Browser/Client, sondern vom Server aus. Wenn ich das/die betreffenen IP Adressen herausgefiltert habe, kann ich den nächsten Schritt machen und kann schauen, woher der Aufruf. Wobei woher weiß ich ja jetzt schon. Es geht darum, welcher Prozess diesen Request macht.

Ein IP Range ist schon mal sicher: 217.61.112.0/21

Wenn Du nach arubacloud google-st, findest Du zahlreiche Treffer, die alle auf einen Abuse hinweisen.

1 Like

Und hier die nächste Range:
185.0.0.0/8

Hallo,

Kannst du herausfinden, was genau aufgerufen wird?

Alle HTTP Anfragen von Matomo an andere Server gehen über die core/Http.php

Du solltest also über diese Funktion herausfinden können, womit sich Matomo verbindet:

Ich glaube aber immer noch nicht, dass eine normale Matomo installation ganze IP-Ranges aufruft.

Hast du schonmal in die Systemüberprüfung in Matomo geschaut, ob vielleicht eine Datei verändert wurde?

Ich bin mit meiner Recherche noch nicht am Ende. Neben dem Austesten der IP Ranges hab ich meinen Provider eingespannt und warte da noch auf Rückantwort. Das PAraodoxe ist, sofern denn einer der Matomo Dateien kompromittiert wären, dann wüsste ich das, weil ich unmittelbar nach der Installation einen MD5 checksum Status erstellt habe. Wenn es da also unautorisierte Änderungen gäbe, dann wüsste ich das.

Deine angehängte Datei hilft mir aber schon mal weiter.

Also es beschränkt sich auf die beiden oben stehenden IP ranges, wobei 1 einzelne IP schon schlimm genug ist. Fakt und derzeit noch unveränderter Status ist, dass wenn immer ich diese beiden Ranges einzeln oder zusammen in der Firewall blocke, kann das Backend nicht mehr aufgerufen werden, bzw. das Laden/die Anzeige beschränkt sich auf den Header und den nebenstehenden Navigationsbereich.

Paradoxerweise findet die Blockierung nicht ständig statt. Nach dem letzten Aufruf des Backends muss manchmal, eber nicht immer, erst eine unbestimmte Zeit vergehen, was ich gerade eben erst wieder festgestellt habe. Wenn die Startseite des Backend schon geladen wurde, ging bei der Seite für die Einstellungen nichts mehr. Dieser Aufruf wird mit dem nachfolgenden Fehler quittiert:

# An error occurred

## curl_exec: Failed to connect to plugins.matomo.org port 443: Die Wartezeit für die Verbindung ist abgelaufen. Hostname requested was: plugins.matomo.org

wobei das nur die Übersichtsseite der Einstellungen und alle Aufrufe betrifft bei denen die Plugins und der Marketplace aufgerufen wird.

Bei der Unterstützung seitens meines Providers bin ich noch nicht weitergekommen. Da steht noch Antwort aus.

Wenn man nun augenscheinlich das Wahrscheinlichste ausschließt, also das irgendwelche Dateien kompromittiert sein könnten, dann liegt es am nächsten, das Matomo abhängig vom Server Standort verschiedene Standorte nutzt, um die Plugins verfügbar zu machen, bzw. abhängig davon auf unterschiedliche Quellen zurückgreift. Wenn dem so ist, würde es erklären, dass nur 1 meiner Server davon betroffen ist und jeder meiner Server einen anderen Standort hat.

Wenn es nun also so ist, wäre das Ganze unkritisch und man könnte die Diskussion darüber für obsolet erklären. Kritisch daran ist aber, dass im Falle dessen ein Service Provider (arubacloud) genutzt wird, dessen Netzwerk regelrecht verseucht ist und der Menge an täglichen Angriffsversuchen nach bei Hackern sehr beliebt sein muss.

Aus meiner Sicht läge es jetzt an Matomo mal zu prüfen, welche Dienste/Anbieter für die Bereitstellung der Plugins genutzt werden. Welche IP Adressen und welche URL davon betroffen ist, wisst Ihr ja jetzt.

Hallo,

Ich habe das Gefühl wir kommen der Lösung schon mal näher.

Ich bin mir ziemlich sicher, dass das nicht der Fall ist. plugins.matomo.org zeigt immer auf 185.31.40.177, denselben Server, der auch api.matomo.org (den Update-Check) und builds.matomo.org (die Download-Seite) beinhaltet.

Und das ist zwar in deinem Range 185.0.0.0/8 aber das ist auch ca. ein 255tel des Internets.

Wie ein dig -x 185.31.40.177 zeigt, liegt dieser Server bei Alwaysdata, einem großen Host aus Paris und hat nichts mit arubacloud zu tun.