Wenn man in einem Datacenter für die Server ein FI hat läuft sowiso was falsch.
Aber nur wenn a Meute an Feldhamster im Keller a bissi Dauermarathon läuft und Generatoren antreibt
Du weißt schon was ein Fehlerstromschalter ist, und dass der gesetzlich vorgeschrieben ist. 
aber mehr ist da nicht drinnen. das ding braucht immernoch eine externe influxdb und ein grafana.
Hm. true. Aber gut, das ist ein (ggfalls nicht so nötiger) Container. Aber es gibt auch viele viele Container, die sehr komplexe Sachen sehr einfach machen.
Du weißt schon was ein Fehlerstromschalter ist, und dass der gesetzlich vorgeschrieben ist.
Ich glaube du meinst einen Fehlerstrom-Schutzschalter - auch RCD genannt.
Seit 14 Jahren sollte man dazu nicht mehr FI sagen...
Du weißt schon was ein Fehlerstromschalter ist, und dass der gesetzlich vorgeschrieben ist.
Ja bin vom Fach. Gemäss Norm (in der Schweiz) ist der FI (Neu RCD) nur vorgeschrieben wenn die Steckdose frei Zugänglich ist mit handelsüblichen Steckern. Wenn wir jedoch eine Spezialsteckdose/stecker (CEE mit PE auf 7h) verwenden können wir auf einen FI verzichten. Dies machen wir jeweils bei Datencenter. Wenn gewünscht wird stattdessen eine Fehlerstromüberwachung ohne Abschaltung eingebaut.
The results after 7 days running a Honeypot
Current data:
A few weeks ago:
Trends:
SMB and VNC are the top two protocols being attacked followed by RDP then SSH
Quelle:
https://www.reddit.com/r/sysadmin/comments/tahurk/the_results_after_7_days_running_a_honeypot/
P.Se das Ergebnis von sowas haben wir ja in Straßbourg gesehen 
H6G ja Fehlerstromschutzschalter; wobei mittlerweile gibts da auch was integriertes
an Stelle einer einfachen Absicherung macht man einen Brandschutzschalter, der einen FI integriert hat
des Teil sieht bei mir im Sicherungskasten der Wohnung so aus:
welchen Sinn hat es, wenn was ist einfach den Krempel weiter unter Strom zu lassen; 
ist ja wie bei Aufleuchten der Motorkontrollleuchte mit Vollgas weiter
Damals in meiner Ausbildung bin ich zufällig auf das Modern Honey Network (https://github.com/pwnlandia/mhn) gestoßen und habe gefragt, ob ich das mal in unserem AS aufsetzen darf. Dürfte ich dann auch und fand das auch richtig cool in mehr oder weniger Echtzeit zu sehen, was da eigentlich so auf einen geschossen wird. Die Ergebnisse damals haben sich mit den Ergebnissen oben gedeckt, sah nur nicht so schön aus 
FI
Immer noch RCD und nicht FI.
welchen Sinn hat es, wenn was ist einfach den Krempel weiter unter Strom zu lassen;
ist ja wie bei Aufleuchten der Motorkontrollleuchte mit Vollgas weiter
Man nehme ein Rack mit mehreren Phasen (A Feed und B Feed).
Ein Fehlerstromschutzschalter misst den Stromfluss über Erdungseinrichtungen - der idR ungewollt ist, weil gefährlich für Menschen.
Wenn ich einen fehlerhaften Server nun in das Rack anschließe, fliegen mir beide Feeds um die Ohren - das gesamte Rack hat dann Stromausfall - nicht gut.
Außerdem sind an einem Rack alle Metalloberflächen idR geerdet, sodass hier dem menschlichen Körper keinen Schaden zugefügt werden kann, wenn ich nicht gerade absichtlich in eine Phase greife. Hier reicht eine Überwachung.
Korrigiert mich, wenn ich falsch liege.
das Ergebnis von sowas haben wir ja in Straßbourg gesehen
Straßbourg hatte überhaupt gar keine Brandabschnitte.
Das Ding war ein Containerdorf mit Spahnplatten aus dem Baumarkt als Fußboden.
Könnte ich hier z.B. das AAAA-record auf den ipv6-only-Server direkt zeigen lassen und das A-Record auf einen ip4 fähigen Proxyserver, der weiterleitet?
(EDIT: Aber auch da gäbe es wahrscheinlich mit den Zertifikaten Probleme)
Nö, die müssen dann halt nur auf beiden Webservern hinterlegt sein.
Tja, so einfach scheint das doch nicht zu sein.
AAAA zeigt auf den ipv6-only Server, A auf einen mit ipv4 - Das geht
LE-Zertifikat auf dem ipv6-only Server erstellen - Geht auch
LE-Zertifikat auf dem ipv4 Server erstellen - Geht nicht
Da mosert der certbot. Offenbar nimmt er auch da zuerst den AAAA-Record (der hat ja Priorität) und der passt halt nicht.
Hmmm... Mal sehen welchen Workaround ich da machen kann.
Alles anzeigenTja, so einfach scheint das doch nicht zu sein.
AAAA zeigt auf den ipv6-only Server, A auf einen mit ipv4 - Das geht
LE-Zertifikat auf dem ipv6-only Server erstellen - Geht auch
LE-Zertifikat auf dem ipv4 Server erstellen - Geht nicht
Da mosert der certbot. Offenbar nimmt er auch da zuerst den AAAA-Record (der hat ja Priorität) und der passt halt nicht.
Hmmm... Mal sehen welchen Workaround ich da machen kann.
Ein Zertifikat muss auf beiden hinterlegt werden - z.B. durch Kopieren des Zertifikates auf beide Maschinen.
Oder du beantragst das Zertifikat über eine DNS Challenge.
Wenn ich einen fehlerhaften Server nun in das Rack anschließe, fliegen mir beide Feeds um die Ohren
andernfalls schmorrt dir im Worst case irgendwo eine Leitung durch und dann Puff,
122 wird dann nicht mehr viel tun können;
des hat schon seinen Sinn 
andernfalls schmorrt dir im Worst case irgendwo eine Leitung durch und dann Puff,
Eine Leitung schmorrt, wenn sie heiß wird an den Kontaktstellen. Hitze erzeugst du Stromstärke.
Leistungsschutzschalter und Netzteile schützen dich davor - dafür brauche ich kein RCD, da macht es auch nicht Puff.
122 wird dann nicht mehr viel tun können;
Kannst ja mal gucken, ob es bei 122 jemanden interessieren würde...
...z.B. durch Kopieren des Zertifikates auf beide Maschinen....
Ja, danke. Das hat geklappt.
ipv6 führt nun mit Zertifikat zum ipv6-only Server
ipv4 (wenn ich z.B. ipv6 im Browser abschalte) führt mit Zertifikat zum ip4 Server.
Auf letzterem muss ich nun nur noch eine Weiterleitung zum ipv6-Server einrichten. (Ich denke da werde ich eine subdomain nehmen müssen, die dort dann auf die Hautdomain umleitet, sonst gibt es wahrscheinlich eine Endlosschleife )
Geht sicher auch eleganter
Auf letzterem muss ich nun nur noch eine Weiterleitung zum ipv6-Server einrichten. (Ich denke da werde ich eine subdomain nehmen müssen, die dort dann auf die Hautdomain umleitet, sonst gibt es wahrscheinlich eine Endlosschleife
Geht sicher auch eleganter
Welchen Proxy setzt du ein?
Da ich auf beiden Servern Apache laufen habe, dachte ich an simple redirects in den vhosts
(Klappt dann halt nur für den Webserver)
Servern Apache
mod_proxy
SSLProxyEngine On
SSLProxyCheckPeerCN Off #Ignoriere die Adresse, die im Zertifikat des zweiten Servers steht
ProxyPass "/" "https://[2a03:4000::1]/"
ProxyPassReverse "/" "https://[2a03:4000::1]/"
RequestHeader set "Host" "example.net"Leider finde ich nichts dazu, wie man mod_proxy dazu überreden kann, bei einer URL nur IPv6 zu verwenden.
Das mit der Subdomain klingt aber auch nicht schlecht - zumindest für die Namensauflösung.
Dafür kannst du ja eine zweite Domain im Zertifikat hinterlegen und den Host Header im Proxy setzen.
H6G schau mal hier: https://www.schutzschalter-onl…-brandschutzschalter.html
unter 122 meldet sich die Feuerwehr 
Da ich auf beiden Servern Apache laufen habe, dachte ich an simple redirects in den vhosts
Was offenbar nicht geht....
Denn damit habe ich das ursprüngliche Problem nur um eine Ebene verschoben. (Kein Zugriff vom Browser aus, auf dem ipv6 abgeschaltet ist, denn die subdomain auf die ich weiterleiten will hat ja nur ipv6 
)
Klassischer Denkfehler von mir.
Also doch über einen echten Proxy...
Bekommt ihr seit einigen Tagen auch so viel Spam von wewe (dot) global?
Landet zwar alles brav im Junk Ordner, aber bei 50+ Mails pro Tag und Adresse nervt es nur noch…
Ich blocke das Zeug jetzt mal direkt während der SMTP-Session…
