KI Scraping Bots sind ein immer größeres Ärgernis und entwickeln sich zu einem echten Problem. In diesem Artikel möchten wir euch ein paar Hintergründe zu unseren Maßnahmen und dem Problem selber liefern.

Wir informieren heute über ein Security-Problem auf unseren Servern, das wir am Mittwoch, dem 08.11.2023 entdeckt haben. Das Problem haben wir gleich am selben Tag behoben. Die direkt betroffenen User haben wir schon einen Tag später am Donnerstag informiert.

Neulich ist ja nun ein altes Root-Zertifikat von Let’s Encrypt abgelaufen und sehr zur Überraschung Vieler hat das zu einigen mehr - lösbaren - Problemen geführt als erwartet, auch bei uns. Eine der Ursachen ist, dass sich Listen vertrauenswürdiger Zertifizierungsstellen an viel mehr Stellen finden als man so gemeinhin annehmen würde. Hintergrund Kurz und knapp vorweg: Eine Liste vertrauenswürdiger Zertifizierungsstellen legt fest, welchen Zertifikaten vertraut wird und welchen nicht. Und wenn das jetzt irgendwie nach einer doch ziemlich wichtigen Geschichte klingt, dann, weil das eben auch wirklich so ist.

Heute haben ein paar Dinge ganz schön geknarzt, die mit Let’s Encrypt, OpenSSL und CentOS zu tun haben und deren Aufarbeitung vielleicht auch im Detail für euch interessant ist. Direkt vorweg: Die Erreichbarkeit deiner bei uns gehosteten Dinge per HTTPS war davon nicht beeinträchtigt.

Am 26.01.2021 war es soweit: Eine bereits seit 2011 bestehende Schwachstelle im Tool sudo, das auf so ziemlich jedem Linux-System residiert, wurde in einer koordinierten Aktion geschlossen - und das hieß damit dann auch: Nachtschicht für uns. Denn die fragliche Schwachstelle war gravierend und erlaubte jedem lokalen Benutzer des Systems, sich mit etwas Trickserei root-Privilegen zu verschaffen. Es war also Tempo angesagt! Bekannt wurde die Lücke unter der Bezeichnung Baron Samedit, eine Anspielung auf Baron Samedi und die Komponente sudoedit, über die die Schwachstelle ausgenutzt werden konnte.

TLSv1.0 und v1.1 ist ab 01.05.2019 für U6 und U7 Geschichte.

Wie ihr im aktuellen Blogpost der Uberspace-7-Reihe lesen könnt, ändert sich im Bereich unserer Shellscripts gerade eine ganze Menge. Aus Config-Dateien werden Ansible-Facts, aus Bash werden Playbooks oder Python-Skripte. Um all diese Teile wieder unter einen Hut zu bekommen, müssten wir einen Ausflug in die Softwareentwicklung machen. Viele unserer Features - wie das allseits beliebte uberspace-add-domain - erfordern, dass wir euch mehr Rechte einräumen, als ihr eigentlich haben dürft. Auf diesem Weg könnt ihr beispielsweise mit uberspace-add-domain auf die Konfiguration unseres Webservers oder mit uberspace-add-port auf das iptables-Ruleset in engen Grenzen und indirekt, aber dennoch schreibend, zugreifen.

Wie ihr sicherlich schon auf Hackernews oder anders wo gelesen habt, kursiert gerade eine “neue” Lücke für diverse GCI-Applikationen im Netz: httpoxy. Konkret geht es darum, dass der Proxy-HTTP-Header des Clients aufgrund der CGI-Spezifikation in der Umgebungsvariable $HTTP_PROXY landet. Diese wird von unzähligen Applikationen dazu benutzt, Verbindungen nach außen aufzubauen. Somit hätte ein potentieller Angreifer die volle Kontrolle über diese Aufrufe, die zum Beispiel die API eines Zahlungsanbieters als Ziel haben können.

Wir werden in den nächsten Tagen ein Update von OpenSSH auf Port 22 auf Version 7.1 vornehmen. In den aktuellen Versionen von OpenSSH ist DSA standardmäßig deaktiviert und wir werden diese Konfiguration übernehmen, da DSA schon lange als unsicher gilt und uns daher ein Dorn im Auge ist. Solltest du also (immer noch) DSA-Schlüssel für den SSH-Login verwenden, ist es jetzt an der Zeit, diese schnellstmöglich austauschen. Im Wiki beschreiben wir, wie du dir einen RSA-Schlüssel mit 4096 Bit generieren kannst.

Nachdem wir nun drei Monate lang OpenSSH 6.7 getestet haben, sind wir jetzt so mutig und tauschen sshd, der auf Port 22 lauscht, gegen eine aktuelle Version aus: OpenSSH 6.8. Wir verwenden dabei die folgende Konfiguration: KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com Netter Nebeneffekt: Wir unterstützten nun ed25519. Alle Hosts haben bereits entsprechende Keys: HostKey /etc/ssh/ssh_host_ed25519_key Weiterhin unterstützen wir natürlich noch RSA: HostKey /etc/ssh/ssh_host_rsa_key Wir unterstützen kein DSA (mehr) und kein ECDSA.