Ein Blog-Leser hat mich gestern per Mail auf eine sehr ungewöhnliche Beobachtung aufmerksam gemacht, die ich hier zur Information mal im Blog einstelle. Die Administratoren haben, nach einer Meldung im Security Center von Microsoft, ein etwas seltsames Verhalten festgestellt. Es gibt plötzlich sehr ungewöhnliche Aktivitäten von Clients, die Kontakt zu Domains und IP-Adressen, die zu Cloudflare gehören, aufnehmen wollen, ohne dass klar ist, was genau dahinter steckt.
Anzeige
Wenn Clients plötzlich aus einer Unternehmensumgebung zu ungewohnten IP-Adressen kommunizieren, sollte dies schon einen Alarm auslösen. Es könnte ja Schadsoftware im System eingenistet sein, die dort dann über DNS-Anfragen oder direkt per IP-Adresse ihre C&C-Server kontaktiert. Aber so richtig fällt die folgende Beobachtung des Lesers nicht in diese Kategorie. Hier die Schilderung des Blog-Lesers, der mit schrieb "aktuell bin ich etwas ratlos bei einem, für mich, seltsamen Verhaltens, welches sich wie folgt darstellt":
Gestern hatten wir im Security Center von Microsoft eine Meldung (worum es hier genau ging, spielt so wie ich es mittlerweile einschätze, nur noch eine untergeordnete Rolle) die uns etwas Nervosität in die Adern trieb.
Aus der Analyse wurde eine Maßnahme, und zwar das Blocken von Domain und einer IP Adresse. Wie wir heute wissen, gehört die IP zu Cloudflare.
Hieran ist grundsätzlich nichts auszusetzen, wenn wir heute nicht das Problem gehabt hätten, dass diverse Clientkommunikation mit dem Ziel der IP 188.114.96.0 blockiert wurden. Bei weiterer Betrachtung stellten wir fest, dass die Kommunikation von unterschiedlichen Clients, unterschiedlicher User mit unterschiedlichen Zieldomains stattfand. Auch wissen wir nun, das alle Zieldomains im DNS der Cloudflare gehostet sind.
Alles eigentlich kein Problem. Allerdings stellt man sich dann irgendwann die Frage weshalb die Domains (Beispiele: online-reservations.com, diecknet.de, und viele andere mehr, per Ping auf immer die gleiche IP Adresse 188.114.96.0 auflösen. Bei einem nslookup auch alle als DNS die 188.114.96.0 und 188.114.97.0 zurückgeben).
Nun widersprechen die Werte bei einer Überprüfung per DNS Lookup allerdings den DNS Zonen der Domains. Also habt der Leser weiter geprüft und musste nun feststellen, dass dieses Verhalten immer nur dann auftritt, wenn als DNS-Server die Google DNS Server (8.8.8.8 und 8.8.4.4) angegeben sind. So erhalte ich je nach Situation folgende Antworten:
nsloopup über Provider DNS (in meinem Fall O2)
Nicht autorisierende Antwort:
Name: diecknet.de
Addresses: 172.67.170.21
104.21.39.84
Diese Werte entsprechen auch der DNS Zone der Domain.
nslookup über google dns (8.8.8.8 und 8.8.4.4)
Nicht autorisierende Antwort:
Name: diecknet.de
Addresses: 188.114.96.0
188.114.97.0
Jeglicher Traffic mit den Hosts erfolgt auch auf Proxy-Manier über die zurückgegebenen Adressen.
nslookup über cloudflare dns (1.1.1.1)
Nicht autorisierende Antwort:
Name: diecknet.de
Addresses: 172.67.170.21
104.21.39.84
Diese Werte entsprechen auch der DNS Zone der Domain.
Nun bilde ich mir ein, dass ich in meiner bisherigen IT-Laufbahn immer ein gutes Verständnis für DNS und IP Kommunikation hatte, aber hier bin ich aktuell echt ein bisschen überrascht, beunruhigt und ratlos und frage mich ob ich in den letzten Monaten oder Jahren irgendwas nicht mitbekommen habe, meint der Leser.
Anzeige
Aber das Ändern von Zonenwerten bei einer profanen DNS-Abfrage treibt mir etwas Angst in den Nacken. Vor allem, wenn dies durch Google passiert.
Oder haben Sie eine andere Erklärung für mich?
Ich selbst habe da keine wirkliche Erklärung für – bin aber auch nicht wirklich im Thema drin – eine kurze Suche hat mir nichts wirklich brauchbares geliefert. Hat jemand aus der Leserschaft eine Erklärung?
Anzeige
ich hoffe dies hat nichts damit zu tun, daß manche Browser selbst DNS-Abfragen tätigen und zwar dort, wo sie meinen, daß es korrekt oder besser wäre; das Blöde dabei ist, das der Admin hier nicht einschreiten kann, außer diese Features im Firefox etc. abzuschalten
Bei diesen "eingebauten DNS-Abfragen" werden sämtliche DNS-Server zuhause und auch die Provider-Server bzw. die per DHCP an den Client übermittelten außer Acht gelassen.
Das Verhalten ist Browserunabhängig und kann mit einem einfachen nslookup in der Console nachgestellt werden.
Ein Scan mit "UrlScan.io" zeigte keine Auffällgkeiten:
https://urlscan.io/result/7d211a89-7a77-4026-9dab-c058ffa9e824/#summary
https://urlscan.io/result/7090c375-f5f1-473e-b91d-1e6ebe73d459/#summary
Bei Malware muss man aber immer mit "Ablenkungs-Manöver" rechnen.
Gesucht wäre links zu dubiosen Servern.
Hat eventuell google noch alte Einträge im Cache (TTL)?
Nein, denn die Ziele werden immer alle erreicht. Im Übrigen passen die TTLs auch mit denen der Zone überein. Seltsam auch, das betrifft halt wirlich sehr viele Domains nach unserer bisherigen Kenntniss,
bei dei reports zu der ip wäre ich auch etwas besorgt:
Die wechselnden IP-Adressen für die selbe Domain ist (vermutlich) begründet in Cloudflares "Load-Balancer".
Aber warum nur dann, wenn die Google DNS genutzt werden? Und der LoadBalancer kann ja nicht einfach die DNS Zonenwerte ändern.
naja aber CF kann das z.B. per "view" auf deren DNS
Wenn ich die DNS Server von Cloudflare (1.1.1.1) nutze ist das Verhalten jedoch nicht nachstellbar. Hier wird dann sauber entsprechend der Zone der Domain aufgelöst. Das ergibt also keinen Sinn.
google ist doch nur ein rekursive DNS und wenn aus dem IP Netz eine Anfrage kommt kann ich doch per VIEW eine andere IP rausgeben.
https://docs.infoblox.com/space/NAG8/22280613/Chapter+18+DNS+Views
somit kann CF alle google-Kunden "umleiten" wenn die zone bei denen liegt.
https://docs.infoblox.com/space/NAG8/22280613/Chapter+18+DNS+Views
Googel ist doch nur ein rekursiver DNS und wenn Cloudflare die Zone hat können die allen Google-"Kunden" eine altenative IP ausliefern lassen
Das war auch mein erster Gedanke aber warum von Google aus eine andere IP als vom "Rest der Welt"?
https://web.archive.org/web/20230320004008/https://www.abuseipdb.com/check/188.114.97.3
https://www.virustotal.com/gui/ip-address/188.114.97.3
https://www.borncity.com/blog/2022/12/12/sophos-atp-stuft-cloudflare-188-114-97-3-als-c2-generic-a-ein-false-positive-dez-2022/#:~:text=Dezember%202022&text=Aktuell%20sieht%20es%20so%20aus,was%20ich%20bisher%20herausgefunden%20habe.
Frag mich gerade, ob Firefox schon sowas wie DNS over HTTPS einsetzt.
Sollte das nicht mal zum Standard werden , dass dies über Cloudflare läuft statts über den DNS-Server der vom System vorgegeben ist?
Ich kann schon Mal die unterschiedlichen DNS Auflösungen nach voll ziehen. Allerdings werden in den weltweiten Nameservern auch weitere andere zusätzlich angezeigt.
Ich würde Mal versuchen einen tracert durch zu führen, ob am Ende der gleiche Server oder zumindest das gleiche Netz getroffen wird. Aus Krankheitsgründen kann ich das leider selbst nicht machen. Auch Mal versuchen, die hosts – Datei selbst zu verändern (Unterschiede der IPs) und schauen, wie das auflöst und ob https noch sauber funktioniert und gleiche Informationen zum Zertifikat kommen.
Dann würde ich schauen, ob ich was finde, wo ich garantiert keine gemachte Seite bekomme, z.b. einer Seite mit einem aktiven Dialog.
Ansonsten hört sich das Ganze an, wie einen geschickten Man-in-the-Middle an! Ich hatte Mal solch einen bei SMTP zu einem österreichischen Provider aufgedeckt.
Wenn so was passiert, dann wird die Sicherheit ausgehebelt!
Dass unterschiedliche DNS unterschiedliche Antworten für die gleiche Domain zurückgeben ist nicht ungewöhnlich – zumindest nicht im Enterprise-Kontext von Cloudflare, wo potenziell tausende Domains über eine IP gerouted werden können. DNS großer hyperscaler wie AWS oder Azure können zeitbasiert oder regionbasiert völlig unterschiedliche Antworten liefern. Je nach TTLs der einzelnen Zoneneinträge können relay-DNS dann natürlich völlig unterschiedliche Antworten liefern. Beispiel für so eine Technik https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/dns-tod-intelligent
Das kann Firefox schon lange.
Man muß es nur aktivieren: https://support.mozilla.org/de/kb/firefox-dns-%C3%BCber-https
aber CF kann das per "view" in deren DNS regeln das google eine andere IP ausliefern muss
Im Zweifel wird es am erfolgversprechendsten sein, wenn der Threadöffner Herrn Andreas Dieckmann (diecknet.de) mal anschreibt, dass er als Kunde bei cloudflare mal nachfrägt.
Die Antwort ist eigentlich recht simpel: Anhand der Herkunft der Dns Abfrage werden Server aus entsprechenden Regionen ausgewählt.
Das kann man unter Tier Einstellungen bei Cloudflare deaktivieren.
Die IP des Clients ist für Cloudflare hier noch nicht sichtbar, nur die des Dns Servers.
o2 dns server oder auch Telekom liefern eine deutsche IP, weshalb auch die richtigen IPs zurückgegeben werden.
Anders sieht es bei Google aus.
Hier werden die entsprechenden IPs nicht in Deutschland zugeordnet sein.
Ausserdem cached Google anscheinend Dns Anfragen länderübergreifend.
wenn es sich bei allen Ziel IPs um CDN Content-Delivery-Network handelt, ja. Aber dann müsste die Ziel IP fast immer einem CDN Provider gehören, z.b Cloudflarr, OVH oder AWS.
Was der Artikel vollkommen offen lässt: Konnte die Signatur des betreffenden DNS RR geprüft werden?
Falls ja, könnte wirklich ein Problem vorliegen. Wenn die Prüfung ein ungültige Prüfergebnis liefert, dürfte kein signifikantes Problem vorliegen, da diese Ergebnisse schlicht ignoriert werden (sollten).
Fehlt dagegen der valide RRSIG RR, muss zunächst erst einmal der Domain-Inhaber die Hausaufgaben machen, bevor andere ihre Probleme lösen.
Es wurde bereits im Hauptartikel erwähnt, das das Phänomen auf viele Domains zutrifft und somit hat nicht erst ein Domain-Inhaber Hausaufgaben zu machen, sondern ist höchst interessant, die Ursache zu erforschen ob unser Internet nicht seit kurzem durch einen MIM geht! Normal ist es so, dass bei CDN Netzen bereits die Zone schon z.b beim CDN Provider liegt, z.b. Cloudflarr. Oder man arbeitet mit cname Auflösungen. Das aber die DNS Server unterschiedliche Ziel-IPs ausgeben, die der Original DNS nicht entsprechen, ist mir auch komplett neu!
Das klingt fast so, als würde die Internetverbindung z.B. durch so einen Dienst wie ZScaler geroutet.
Genau die Tatsache, ob alles durch einen MIM verändert wird, erkennst Du mit RRSIG, bei einer Domain, bei vielen Domains, immer…
DNS Server werden heute oft mit Unicast Adressen eingesetzt, vielleicht war das Routing zu der eigentlich richtigen Instanz gestört und deshalb hat vielleicht eine andere Instanz als die lokal nächste geantwortet. Ich habe öfters erlebt das man das man bei der Anfrage über Goolge DNS Server völlig andere IP-Adressen zurück erhält als wenn man den DNS Server des Providers nutzt. Vor Jahren hatte ich z.B. immer wieder Probleme mit den Google DNS und Telekom Anschlüssen. So funktionierten Hotmail oder selbst die Tagesschau nicht ordentlich. Man versucht wohl über die DNS Server den Clients bei CDNs zu den nächstgelegenen Servern umzuleiten. Dumm nur wenn gerade die US Instanz eines DNS Servers antwortet und man auf die US Akamei Server umgeleitet wird.
So richtig verstehe ich die ganze Aufregung nicht. Der Betreiber von "diecknet.de" setzt Cludflare ein – na und? Das ist seine Entscheidung, möglicherweise nutzt er ja sogar das kostenlose Basisangebot.
Wenn ich "diecknet.de" rekursiv über den Eintrag bei der DENIC und die beiden eingetragenen Nameserver april.ns.cloudflare.com. und bob.ns.cloudflare.com. auflösen lasse bekomme ich
diecknet.de has address 172.67.170.21
diecknet.de has address 104.21.39.84
diecknet.de has IPv6 address 2606:4700:3034::6815:2754
diecknet.de has IPv6 address 2606:4700:3037::ac43:aa15
diecknet.de mail is handled by 1 diecknet-de.mail.protection.outlook.com.
Beide IPv4 und beide IPv6-Adressen gehören zu Cloudflare in San Francisco, der Mail Exchanger (um den es hier nicht geht) zu Microsoft.
Die gleiche Antwort bekomme ich auch bei Cloudflares eigenem DNS (1.1.1.1) und z.B. 9.9.9.9
Wenn ich "diecknet.de" dagegen über den DNS der Deutsce Telekom auflösen lasse bekomme ich
diecknet.de has address 188.114.96.3
diecknet.de has address 188.114.97.3
diecknet.de has IPv6 address 2a06:98c1:3120::3
diecknet.de has IPv6 address 2a06:98c1:3121::3
diecknet.de mail is handled by 1 diecknet-de.mail.protection.outlook.com.
Beide IPv4- und IPv6-Adressen gehören zu "CLOUDFLARENET-EU" mit einer registrierten Adresse von Cloudflares deutscher Niederlassung in München.
Das ist letztendlich auch die Antwort, welche Google z.B. auf der 8.8.8.8 gibt.
Cloudflare setzt nach eigenen Angaben Anycast-DNS ein so ist es nicht verwunderlich, daß je nach Identität des Anfragenden unterschiedliche Antworten gegeben werden.
Offensichtlich sind sowohl die Telekom als auch Google groß genug um eigene Cloudflare-Server in ihrem Netzwerk zu betreiben während kleinere provider das nicht tun, sondern die internationale Infrastruktur nutzen.
Ich hoffe, das hilft euch weiter: Ich habe mehrere Gmail-Adressen und seit kurzem bekomme ich, wenn ich von der einen zur anderen Adresse eine E-Mail schreibe, die Antwort, dass der Empfängerserver nicht antwortet. Da bekomm ich als Ziel auch die 188.114.96.0 zurück. da hab ich mir noch nichts dabei gedacht, aber mit dem Bericht hier glaube ich langsam, das Googles DNS Einstellungen falsch sind.
Sehr interessant was ChatGPT dazu sagt:
Es gibt eine mögliche Erklärung für das beobachtete Verhalten des Lesers. Cloudflare betreibt ein Feature namens "1.1.1.1 for Families", das einen Family-friendly DNS-Resolver bereitstellt. Dieser Dienst blockiert bestimmte Inhalte, die als unangemessen für Familien angesehen werden. Es könnte sein, dass die von Google DNS zurückgegebenen IP-Adressen von Cloudflare als Teil dieses Dienstes blockiert werden.
Es ist auch möglich, dass die von Cloudflare verwendete Technologie zur Lastverteilung von DNS-Anfragen dazu führt, dass verschiedene IP-Adressen zurückgegeben werden, je nachdem, woher die Anfrage stammt. In diesem Fall könnte es sein, dass der Google DNS-Resolver von Cloudflare als weniger vertrauenswürdig angesehen wird und daher andere IP-Adressen zurückgibt.
Es ist jedoch schwierig, ohne weitere Informationen eine genaue Ursache zu identifizieren. Eine gründliche Analyse des Netzwerkverkehrs und der DNS-Antworten ist erforderlich, um die genaue Ursache des beobachteten Verhaltens zu ermitteln. Es ist empfehlenswert, dass der Blog-Leser dies mit Hilfe von erfahrenen Netzwerk- und Sicherheitsexperten tut, um sicherzustellen, dass keine bösartige Aktivität vorliegt.
Schade, dass das Blog jetzt als Debug-Forum für einen Leser missbraucht wird.
ich will hier eigentlich Nachrichten lesen und nicht einzelne, unbestätigte Probleme….
Das ist doch glasklar..
CF macht geocaching / geodns und versucht auch für reverse Proxy configs die beste Route zum Client zu geben.
die IP ist vermutlich ähnlich wie 1.1.1.1 selbst, eine IP, die in mehreren Rechenzentren auf der Welt existiert, und im routing recht flott erreicht wird.
von da aus Router CF höchstwahrscheinlich dann weiter zum Ziel.
Grund:
woher soll CF wissen ob du in Amerika oder Europa bist, wenn du 8.8.8.8 nutzt? deine IP der Anfrage kennt nur Google und so lange die TTL nicht ausgelaufen ist, wird Google sich am Cache bedienen.
für effizientes Routing nimmt man dann halt ne Geo ip.
Das ist einfach eine Dimension, die man als kleine Firma nicht kennt.
Das hatte ich oben schon versucht darzustellen.
Das Cloudflare-EU-Netz, welches Telekom und Google liefern terminiert in Frankfurt, das internationale in Amsterdam (vermutlich in einem von Cloudflare betriebenen Rechenzentrum).
Hi, Benedikt from Cloudflare here, the behavior is explained here
https://blog.cloudflare.com/addressing-agility/
Ich habe mich die DNS 206.223.118.145 (equinix) unter die Lupe genommen. Daten werden in den Staaten ohne wenn und aber zugeschickt. Mehr? https://tools.keycdn.com/geo?host=206.223.118.145
Meine Tipps: about:config
– dom.event.clipboardevents.enabled, von True auf False setzen
– dom.storage.default_quota, von 0 auf 5120 setzen
– dom.storage.enabled, von True auf False setzen
vermutlich hat das mit dem anycast IP netzwerk von Cloudflare zu tun. Damit CDNs funktionieren muss anhand des Standorts des/der Nutzer:in der bestmögliche Server ausgewählt werden. Typischerweise ist das die Distanz. Cloudflare und andere CDN Anbieter haben dafür mehrere DNS Server mit der selben IP Adresse (IP Anycast) aufgestellt, welche per BGP veröffentlicht werden. BGP nimmt den bestmöglichen Pfad zur IP (Autonomous System von der IP) und liefert so die bestmögliche Kommunikation zwischen Server und Client. So gibt es 1.1.1.1 und 8.8.8.8 nicht nur einmal in den USA sondern quasi in mehreren AS rund um die Welt.
Ich würde jetzt schätzen, dass einer der DNS Server (8.8.8.8) von Google jetzt nicht den Standort von dir repräsentiert, sprich Cloudflare z.B. denkt, dass du in den USA bist.
Könnte in etwa so aussehen:
Du —–> 8.8.8.8 (Google Resolver DNS Server USA) ——-> (Cloudflare Authoritve DNS in USA)
Daher gibt dir der Google Resolver DNS (8.8.8.8) andere Ergebnisse als wenn du Cloudflare oder O2 DNS Resolver Server nutzt:
Du ——> 1.1.1.1 (Cloudflare Resolver in Frankfurt) —–> Cloudflare Authoritve DNS in Frankfurt
Könnte also ein Peering Ding zwischen deinem Provider und Google sein.