Genau deswegen habe ich ja die Skepsis über die Zukunft. Ausfälle kann man auf wenige Minuten beschränken, dazu ist nicht viel Aufwand nötig. Dann die sehr lange gestörte PN Funktion und die immernoch fehlerhafte TLS Konfiguration des Webservers. Keine Information über Arbeiten am Forum, es muss ja nicht das phpBB laufen, sondern eine einfache statische html mit der Info reicht vollkommen aus, statt nicht auflösbare Server, merkwürdige Backend Fehlermeldungen, keine Antwort der Server etc.
Gerne kann ich auch Hilfe in dem Bereich anbieten, dazu ist eben Kommunikation notwendig, die bisher einseitig ist. Falls dies nicht gewollt ist, hier wenigstens ein paar Tipps.
- Umzug auf anderen Provider mit anderen IP Adressen
- Aktuelle TTL der DNS Einträge (A/AAAA) checken, wenn diese auf zum Bsp eine Woche stehen, in einer Woche den Umzug planen
- TTL der DNS Einträge auf 60 Sekunden setzen, damit der IP Umzug schnell erledigt ist und der neue Server aktiv werden kann
- In der Wartezeit per rsync die Files auf den neuen Server ziehen
- Die DB dumpen und ebenfalls auf dem neuen Server deployen
- In der lokalen Hosts-File die Adresse auf den neuen Server zeigen lassen
- Konfiguration prüfen ggf. anpassen, diverse Threads ansurfen und schauen ob Anhänge etc. funktionieren
- Am Umzugstag auf dem alten Server eine Meldung per html oder eben den Wartungsmodus aktivieren, damit keine weiteren Änderungen passieren
- Erneut per rsync die Files auf den neuen Server ziehen (sollte schneller gehen da nur Änderungen übertragen werden)
- DB Dump erneut erstellen und auf dem neuen einspielen, die DB wird nicht extrem groß sein und sollte schnell gehen, ansonsten auch per Timestamps nur die änderungen dumpen und einspielen
- Forum auf dem neuen Server erneut per mod. Hostsfile kontrollieren und anpassen (oder Wartungsmodus aktivieren und später prüfen)
- Alle DNS Einträge auf die neuen IPs ändern (TTL ggf. noch auf 60 Sec belassen, falls man zurück gehen muss)
- Wartungsmodus nach Fixen der restlichen Anpassung deaktivieren
- --> Umzug erledigt
- DNS TTL Einträge auf 24h bis 1 Woche einstellen
Ich sehe hier wird der Apache Webserver in einer halbwegs aktuellen Version benutzt und die Version verschleiert wird, was schonmal gut ist, zumindest werden die gängigen TLS Attacken abgewehrt. Einige passende XSS/CORS Header meine ich auch gesehen zu haben. Der aktuelle Server web18.step-byte-step.com hat unnötig alte TLS Versionen aktiv und die Zertifikatskette ist fehlerhaft konfiguriert. Zudem werden Alternative Names von anderen Domains verwendet (volkerschulz.de) was ebenfalls nicht ideal ist.
Habe hier auch mal gelesen es gibt ein Mirror / Testforum unter rollerforum.volkerschulz.de.... sorry sowas macht man nicht. Entweder man macht dies durch lokale Hostsfile Anpassungen / Firewalleinträge (IP Whitelisting o.ä.) / VPN oder mit irgendeiner Forum von (externer) Auth (Apache/nginx eingebauter völlig ausreichend), sodass Normalsterbliche da nicht drauf können. Dadurch gibt es, wie man ja oft hier ließt, Verwirrungen genau dadurch. Vor allem da auch manche Googleeinträge mit diesen Link versehen sind, ist echt kontraproduktiv wenn diese Version aufgrund irgendwelche Arbeiten zurückgesetzt, eine anfällige Serverkonfig zwecks Debugging oder anderweitig angepasst werden. Würde jetzt empfehlen eine robots.txt oder neumodig den X-Robots-Tag Header zu setzen, aber daran hält sich eh keiner.
Ich zum Beispiel habe einen Wireguard-VPN Tunnel zu meinem Cluster, ich route die Public IPs der VMs und Container durch den Tunnel via BGP (private ASNs) und habe die Firewallregeln so angepasst das ich erweiterten Zugriff von daheim aus habe, als das "böse" Internet. So kann man in Ruhe arbeiten, Debuggen etc. und von außen können nur bestimmte Dienste wie der nginx angefahren werden. Hier mal einfach beispielhaft dargestellt:
Interessant ist das die DNS Server der Elektroroller-Domain selbst bei Hetzner liegt, vermute der Umzug geht in diese Richtung. Gute Entscheidung war ich früher auch und war sehr zufrieden. Die TTL der A Einträge liegt bei 5 Minunten, hoffe das ist dem Umzug geschuldet s.o. und nicht by-design.
Die TLS Konfiguration des Servers kann einfach mit https://www.ssllabs.com/ssltest/analyze.html geprüft werden.
Empfehlungen:
- Zertifikate pro Domain erzeugen, mit DNS ACME ist auch Wildcard möglich
- Zertifikats Chain korrekt einbinden (Domain Cert -> Intermediate -> CA) acme.sh / certbot und Co. erstellen alle benötigten Files automatisch
- Alle TLS Versionen bis auf TLS v1.2 und 1.3 deaktivieren
- Diese oder ähnliche sichere Ciphers aktivieren, die funktionieren auch noch auf Geräten mit rund 10 Jahren auf dem Buckel also genug Backwards-Kompatibilität mMn vorhanden (kann ebenfalls mit ssllabs geprüft werden)
- DNS CAA Einträge für letsencrypt (das warscheins weiter benutzt werden soll) einfügen
- HSTS Header mit Preloading hinzufügen
- Ältere ECDH Curves für DHParams entfernen
- OCSP Stpaling / Must-staple brauch man nicht mehr zu aktivieren ( https://letsencrypt.org/2024/12/05/ending-ocsp/ )
- DH Parameter mit 4096bit neu erzeugen und nicht mitnehmen
Code: Alles auswählen
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:EECDH+AESGCM:EECDH+CHACHA20';
ssl_ecdh_curve X25519:secp384r1:secp256r1;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;Code: Alles auswählen
ssl_session_timeout 10h;
ssl_session_cache shared:SSL:32m;
ssl_session_tickets on;https://www.ssllabs.com/ssltest/analyze ... ade%3aaffe
Bester Kompromiss aus sicheren und aktuellen Verschlüsselungsmethoden und Client Kompabtibilität.
meiner wenige Jahre alter neuer Nick "Crash_Override" trifft es noch mehr.
