WulfmanGER
Commander
- Registriert
- Juli 2005
- Beiträge
- 2.269
Hallo zusammen,
nach eine unterirdischen Support-Erfahrung möchte hier mal nachfragen, wie so etwas passieren kann...
Ich betreibe zu Hause (IPv4-only, mit 24h Zwangstrennung) einen Webserver. Dieser ist über Port 443 (HTTPS) auch aus dem Internet erreichbar. Port 80 (HTTP) ist nur offen, wenn Zertifikate aktualisiert werden oder bei Neueinrichtung. Allerdings kommuniziere ich die VHosts nicht nach außen (dazu später mehr).
Ich habe mehrere VHosts. Zwei bis fünf davon haben jeweils ein Let's Encrypt-Zertifikat. Das Ganze läuft auf einem Apache unter Windows (nativ, ohne Docker o.Ä.).
1: Kein Hostname
2: cloud.domain.tld
3: ollamawebui.domain.tld
4: malkurznachhausetelefonieren.domain.tld
5: testdomain.domain.tld
Für jeden VHost gibt es ein eigenes Log ({vhost}.log).
Wenn jemand auf meine Internet-IP zugreift, wird er von Konfiguration 1 ("Kein Hostname") abgefangen. Dort gibt es eine große IP-Blockliste (fast alles), und es wird kein Inhalt angezeigt. Wer nicht von der Blockliste betroffen ist, erhält dennoch ein 403-Fehler. Diese Zugriffe werden im "badbot.log" verzeichnet. Wer auf die VHosts 2–5 zugreift, sieht den jeweiligen Inhalt. Allen Domains ist gemeinsam, dass es eine Blockliste gibt (gezielt, nicht global), und bestimmte User Agents (ohne User Agent = Block) werden ebenfalls geblockt. Es passiert nur selten etwas, aber wenn es doch mal vorkommt, greift eigentlich eine der Regeln.
Domain-Konfiguration:
Ich bin Kunde bei All-Inkl. und nutze dort den DynHost (meine Fritz!Box aktualisiert z. B. meinzuhause.domain.tld). Die anderen Domains für den Heim-Webserver habe ich als CNAME zu dieser DynHost-Adresse konfiguriert. Let's Encrypt verwalte ich über WIN-ACME.
Soweit zur Konfiguration.
Vor einigen Monaten habe ich Ollama installiert, da ich das System auch extern nutzen möchte (meist über VPN, aber an einem Standort auch direkt, wo VPN nicht möglich ist). Dafür habe ich mir Open WebUI (ehemals Ollama WebUI) geholt und es über Docker Desktop (Windows) installiert. Ich habe dafür eine Subdomain eingerichtet, ähnlich wie die anderen, die vom Namen her den Content nicht preisgibt. Anschließend habe ich einen VHost im Apache eingerichtet und ProxyPass aktiviert. So kann ich jetzt über HTTPS auf ollamawebui.domain.tld von extern zugreifen.
Das Problem: Nach etwa 10 Minuten hatte ich bereits fremde Zugriffe auf diesen VHost. Klar, ein Webserver im Internet ist immer ein Ziel. Es gibt viele veraltete Webanwendungen, unsichere PHP-Versionen usw. Das lockt Script-Kiddies an, die IP-Ranges scannen und nach offenen Ports (80/443) suchen. Dann starten sie ihre Angriffe auf die IP. Normalerweise landen diese Angriffe in meiner Konfiguration 1 und werden geblockt (nutzung der IP statt eines registrierten VHosts -> 403).
Aber wie kann es sein, dass ich nach nur 10 Minuten erste Zugriffe explizit auf den VHOST hatte, z. B. aus Russland, China, Singapur? Einer der Angriffe hat sogar explizit Open WebUI-Syntax verwendet. Glücklicherweise war wegen der Auth-Digest-Konfiguration (die so gut ist, das gar kein Zugriff mehr möglich ist...) nichts weiter möglich. Die Skripte, auf die zugegriffen wurde, waren durch HTTP/401 geschützt. (auth-digest geht ja leider nicht über proxypass wie ich mittlerweile feststellen durfte)
Ich kenne meine Logs quasi auswendig. VHost 4 existiert seit über 10 Jahren, VHost 5 seit mindestens 5 Jahren, und auch cloud läuft seit etwa 5 Jahren. Hier liefen schon lohnenswerte Ziele wie OwnCloud oder Nextcloud (auf Windows via WSL2). Trotzdem habe ich in all den Jahren nie Open WebUI-spezifische Anfragen gesehen. Jetzt hatte ich auf einmal, nur bei Vhost 3, eine ganze Seite voll davon (+ paar übliche "wir schauen mal was hier sonst so zu holen ist"-Abfragen). Es wirkte, als wüsste jemand, dass Open WebUI dort installiert ist.
Klingt sehr seltsam, oder?
Woher wusste jemand/etwas nach 10 Minuten, dass es diese Domain gibt und dass dort Open WebUI läuft?
Im Support-Discord habe ich gefragt, ob Open WebUI vielleicht damit zu tun hat oder ob Docker eine Rolle spielt. Aber woher soll Docker den Domainnamen kennen? Einer der Supporter hat das sofort abgewiegelt und etwas ganz anderes erzählt. Als ich darauf hinwies, dass zufällige Angriffe auf einen VHost eher unwahrscheinlich sind, wurde er pampig. Insgesamt fand ich das Verhalten verdächtig und frage mich langsam, ob da nicht doch etwas im Hintergrund passiert.
Der Supporter meinte außerdem: Wer mit ACME ein SSL-Zertifikat holt, macht sich der ganzen Welt bekannt, und jeder Bot greift das neue Ziel an. Wir öffentlich gemacht wer gerade ein neues Zertfikat bekommen hat. Komisch nur, dass meine anderen VHosts, selbst einer, der kaum älter als der für Open WebUI ist, noch keine Zugriffe hatten. Auch während der Konfiguration, als Port 80 für Let's Encrypt offen war, gab es keine Zugriffe. Die Angriffe gingen direkt auf HTTPS und exakt auf diesen Domainnamen. Der Supporter tat das jedoch als „normal“ ab: je nach Typ der ACME-Zertifizierung sei quasi eine Einladung (er wollte mir also sagen es gibt sichere und wir informieren auch gleich mal alle-Varianten)
Vielleicht kann hier ja jemand ein wenig Licht ins Dunkel bringen ... wem traue ich nicht mehr? OpenWebUI for Docker? Docker Desktop? OpenWebUI als solches? Oder bekommen Bots wirklich an neue Domains live dran und können, ohne vorher mal eine Testabfrage zu machen (Fehlermeldungen können ja schnell offenbaren was installiert ist), zielgenau abfragen starten?
Also Letsencrypt dann quasi das Problem - aber nur bei einer von 1 Mio Domains oder so - und meine war das gerade? 
Danke schon mal für paar Erklärungen die mir helfen das Problem besser zu verstehen...
PS: Jetzt noch das „Aber“:
VHost 4 ist meine Test-Domain, auf der ich verschiedene Dinge wie Skripte, Zertifikate und CSS-Validatoren ausprobiere. Manchmal vergesse ich, das Häkchen für "privat" zu setzen, wodurch die Domain in öffentlichen Listen auftaucht. Trotzdem ist es auf dieser Domain sehr ruhig, obwohl sie z. B. von Facebook, WhatsApp, Discord und Testseiten bekannt ist.
PPS: das Webinterface so umgestellt das nur noch 2 IP-Ranges drauf zugreifen können - Private und eine Public.
nach eine unterirdischen Support-Erfahrung möchte hier mal nachfragen, wie so etwas passieren kann...
Ich betreibe zu Hause (IPv4-only, mit 24h Zwangstrennung) einen Webserver. Dieser ist über Port 443 (HTTPS) auch aus dem Internet erreichbar. Port 80 (HTTP) ist nur offen, wenn Zertifikate aktualisiert werden oder bei Neueinrichtung. Allerdings kommuniziere ich die VHosts nicht nach außen (dazu später mehr).
Ich habe mehrere VHosts. Zwei bis fünf davon haben jeweils ein Let's Encrypt-Zertifikat. Das Ganze läuft auf einem Apache unter Windows (nativ, ohne Docker o.Ä.).
1: Kein Hostname
2: cloud.domain.tld
3: ollamawebui.domain.tld
4: malkurznachhausetelefonieren.domain.tld
5: testdomain.domain.tld
Für jeden VHost gibt es ein eigenes Log ({vhost}.log).
Wenn jemand auf meine Internet-IP zugreift, wird er von Konfiguration 1 ("Kein Hostname") abgefangen. Dort gibt es eine große IP-Blockliste (fast alles), und es wird kein Inhalt angezeigt. Wer nicht von der Blockliste betroffen ist, erhält dennoch ein 403-Fehler. Diese Zugriffe werden im "badbot.log" verzeichnet. Wer auf die VHosts 2–5 zugreift, sieht den jeweiligen Inhalt. Allen Domains ist gemeinsam, dass es eine Blockliste gibt (gezielt, nicht global), und bestimmte User Agents (ohne User Agent = Block) werden ebenfalls geblockt. Es passiert nur selten etwas, aber wenn es doch mal vorkommt, greift eigentlich eine der Regeln.
Domain-Konfiguration:
Ich bin Kunde bei All-Inkl. und nutze dort den DynHost (meine Fritz!Box aktualisiert z. B. meinzuhause.domain.tld). Die anderen Domains für den Heim-Webserver habe ich als CNAME zu dieser DynHost-Adresse konfiguriert. Let's Encrypt verwalte ich über WIN-ACME.
Soweit zur Konfiguration.
Vor einigen Monaten habe ich Ollama installiert, da ich das System auch extern nutzen möchte (meist über VPN, aber an einem Standort auch direkt, wo VPN nicht möglich ist). Dafür habe ich mir Open WebUI (ehemals Ollama WebUI) geholt und es über Docker Desktop (Windows) installiert. Ich habe dafür eine Subdomain eingerichtet, ähnlich wie die anderen, die vom Namen her den Content nicht preisgibt. Anschließend habe ich einen VHost im Apache eingerichtet und ProxyPass aktiviert. So kann ich jetzt über HTTPS auf ollamawebui.domain.tld von extern zugreifen.
Das Problem: Nach etwa 10 Minuten hatte ich bereits fremde Zugriffe auf diesen VHost. Klar, ein Webserver im Internet ist immer ein Ziel. Es gibt viele veraltete Webanwendungen, unsichere PHP-Versionen usw. Das lockt Script-Kiddies an, die IP-Ranges scannen und nach offenen Ports (80/443) suchen. Dann starten sie ihre Angriffe auf die IP. Normalerweise landen diese Angriffe in meiner Konfiguration 1 und werden geblockt (nutzung der IP statt eines registrierten VHosts -> 403).
Aber wie kann es sein, dass ich nach nur 10 Minuten erste Zugriffe explizit auf den VHOST hatte, z. B. aus Russland, China, Singapur? Einer der Angriffe hat sogar explizit Open WebUI-Syntax verwendet. Glücklicherweise war wegen der Auth-Digest-Konfiguration (die so gut ist, das gar kein Zugriff mehr möglich ist...) nichts weiter möglich. Die Skripte, auf die zugegriffen wurde, waren durch HTTP/401 geschützt. (auth-digest geht ja leider nicht über proxypass wie ich mittlerweile feststellen durfte)
Ich kenne meine Logs quasi auswendig. VHost 4 existiert seit über 10 Jahren, VHost 5 seit mindestens 5 Jahren, und auch cloud läuft seit etwa 5 Jahren. Hier liefen schon lohnenswerte Ziele wie OwnCloud oder Nextcloud (auf Windows via WSL2). Trotzdem habe ich in all den Jahren nie Open WebUI-spezifische Anfragen gesehen. Jetzt hatte ich auf einmal, nur bei Vhost 3, eine ganze Seite voll davon (+ paar übliche "wir schauen mal was hier sonst so zu holen ist"-Abfragen). Es wirkte, als wüsste jemand, dass Open WebUI dort installiert ist.
Klingt sehr seltsam, oder?
Woher wusste jemand/etwas nach 10 Minuten, dass es diese Domain gibt und dass dort Open WebUI läuft?
Im Support-Discord habe ich gefragt, ob Open WebUI vielleicht damit zu tun hat oder ob Docker eine Rolle spielt. Aber woher soll Docker den Domainnamen kennen? Einer der Supporter hat das sofort abgewiegelt und etwas ganz anderes erzählt. Als ich darauf hinwies, dass zufällige Angriffe auf einen VHost eher unwahrscheinlich sind, wurde er pampig. Insgesamt fand ich das Verhalten verdächtig und frage mich langsam, ob da nicht doch etwas im Hintergrund passiert.
Der Supporter meinte außerdem: Wer mit ACME ein SSL-Zertifikat holt, macht sich der ganzen Welt bekannt, und jeder Bot greift das neue Ziel an. Wir öffentlich gemacht wer gerade ein neues Zertfikat bekommen hat. Komisch nur, dass meine anderen VHosts, selbst einer, der kaum älter als der für Open WebUI ist, noch keine Zugriffe hatten. Auch während der Konfiguration, als Port 80 für Let's Encrypt offen war, gab es keine Zugriffe. Die Angriffe gingen direkt auf HTTPS und exakt auf diesen Domainnamen. Der Supporter tat das jedoch als „normal“ ab: je nach Typ der ACME-Zertifizierung sei quasi eine Einladung (er wollte mir also sagen es gibt sichere und wir informieren auch gleich mal alle-Varianten)
Vielleicht kann hier ja jemand ein wenig Licht ins Dunkel bringen ... wem traue ich nicht mehr? OpenWebUI for Docker? Docker Desktop? OpenWebUI als solches? Oder bekommen Bots wirklich an neue Domains live dran und können, ohne vorher mal eine Testabfrage zu machen (Fehlermeldungen können ja schnell offenbaren was installiert ist), zielgenau abfragen starten?
Also Letsencrypt dann quasi das Problem - aber nur bei einer von 1 Mio Domains oder so - und meine war das gerade? Danke schon mal für paar Erklärungen die mir helfen das Problem besser zu verstehen...
PS: Jetzt noch das „Aber“:
VHost 4 ist meine Test-Domain, auf der ich verschiedene Dinge wie Skripte, Zertifikate und CSS-Validatoren ausprobiere. Manchmal vergesse ich, das Häkchen für "privat" zu setzen, wodurch die Domain in öffentlichen Listen auftaucht. Trotzdem ist es auf dieser Domain sehr ruhig, obwohl sie z. B. von Facebook, WhatsApp, Discord und Testseiten bekannt ist.
PPS: das Webinterface so umgestellt das nur noch 2 IP-Ranges drauf zugreifen können - Private und eine Public.