Secrets Not Included: SSH Sicherheit

Willkommen zu Secrets Not Included im Podcast mit Daniel und Ole. Diesmal schon die Folge 4. Und wir möchten heute mal darüber reden, wie sichern wir denn mal so Server ein bisschen ab? Was machen wir da so mit dem SSH-Zugang? Und was sind unsere Lieblingspasswörter für den Hut-Zugang? Daniel.

Genau. Ja, wir hatten in der Vorbereitung uns das Thema rausgesucht, einfach weil das so selbstverständlich ist oder so alltäglich ist, dass man das gerne vergisst, dass man einfach... Irgendwie ist jeder irgendwo mal auf dem Server gewesen und irgendwie funktioniert das. Und gerade so in kleineren Projekten. Also das Thema wird auch eher so in Richtung kleinere Teams gehen. Also jeder, der Ops hat, muss sich um solche Themen gar nicht kümmern, weil da sitzen Experten, die machen das und die können das besser als ich. Und die machen den ganzen Tag nichts anderes. Aber wenn man in einem Projekt ist, zwei, drei Entwickler vielleicht irgendwo in einem V-Server mal schnell hingestellt und Testsystem für den Kunden, damit er irgendwas abnehmen kann, Und dann bleibt das Ding einfach stehen, weil man im Gefecht, im Alltagsgeschäft einfach das vergisst und dann bleibt er da stehen.

Du meinst, mein Lieblingspasswort, Route1234.

Und auf einmal läuft ein halbes Jahr lang, ein Jahr lang ein Server, wo sich keiner drum kümmert. Am besten noch ein ganz schlechtes Passwort irgendwo mit drin. So das Übliche. Genau, genau.

Das merkt man sich halt so schön einfach. Das ist ja auch, dann vergisst man das nicht. Man braucht auch gar nicht so einen Passwortmanager und so. Ich finde das eigentlich ziemlich super, wenn das so einfach ist.

Ja, genau. Die bösen Jungs finden das auch super. Da brauchst du dann... Genau.

Ja, schau mal, das ist Shared Use. Umweltschutz vielleicht.

Also Hintergrund ist natürlich, wer kennt es nicht, sobald man sich einen V-Server nimmt, den anschaltet und einfach nur das Log aufmacht, sieht man eigentlich spätestens nach fünf Minuten, dass irgendwelche Skripte langlaufen und versuchen, sich mit allen möglichen Passwörtern anzumelden. Also wirklich die einfach nur noch durchlaufen und ausprobieren, ausprobieren, ausprobieren, um irgendwelche Zufalls- oder Glückstreffer zu landen. Und das Ziel ist es ja meistens gar nicht, deinen Server zu übernehmen oder dir zu schaden, sondern entweder Bot-Netzwerke aufzubauen, heißt zum Beispiel etwas zu installieren und dein unbemerkt, deinen Server weiter zu nutzen und die Rechenleistung einfach zu nutzen oder also Bot-Netzwerke, Coin-Mining war auch oder ist, weiß ich gar nicht, ob das noch interessant ist oder ob die jetzt andere Sachen machen.

Ich glaube, solange du den Strom nicht bezahlen musst, ist das durchaus noch interessant. Also

Und sonst rumspammen geht auch immer ganz gut über fremde Server. Deswegen ist es definitiv sinnvoll, da so ein bisschen für Sicherheit zu sorgen und es den Leuten nicht zu leicht zu machen. Und das ist manchmal leichter, als man denkt. Gerade in der Vorbereitung haben Oda und ich gemerkt, als wir darüber gesprochen haben, was es für Möglichkeiten gibt, was wir automatisch machen, ohne dass man da groß drüber nachdenkt und wie groß das Thema ist. Weil wir waren beide der Meinung, dass wir es nicht schaffen, lang genug darüber zu reden. Nachdem wir geguckt haben, was uns alles einfällt, gehe ich davon aus, schaffen wir das heute.

Ja, wir werden mal sehen. Also eigentlich ist das ja auch nicht schwierig. Also ich sage jetzt mal, die automatisierten Angriffe, die man ja natürlich sofort sieht, auch auf den SSH-Port, testen natürlich erstmal ganz grundsätzlich, gibt es denn diese User? Kann ich mich mit irgendeinem der bekannten Standard-User, Admin, Root und so weiter, die es da alle gibt, MySQL übrigens auch sehr beliebt, anmelden oder geht das nicht? Oder welches Feedback kommt auch von dem System? Das ist ja alles hochautomatisiert. Man muss sich ja da ja gar nicht die Illusion machen, dass sich da jemand hinsetzt und sagt, ich probiere mal aus, sondern das sind ja kontinuierliche Botnetze, die da mehr oder weniger selbstständig laufen, suchen und halt probieren, wo funktioniert denn jetzt das einfach? Und ich sage jetzt mal, die einfachste Maßnahme ist, Für SSH ganz grundsätzlich den Login mit Passwörtern nicht zuzulassen, ja, nur mit Zertifikaten den Login zuzulassen und dann musst du ja immerhin schon mal jemand das Zertifikat geklaut haben, damit du reinkommst.

Also grundlegend ist es ja so, Passwörter, Menschen sind einfach schlecht. Und da zähle ich mich besonders zu, ich kann mir Passwörter nicht merken. Die meisten nutzen ja Passwortmanager mittlerweile, das ist gut. Und Zertifikate sind... Also da steht wirklich mathematisch viel hinter. Also das früher hat man Primzahlen genutzt mit RDS zum Beispiel als Verschlüsselung. Mittlerweile nimmt man Kurvenberechnung, also ganz cooles mathematisches Zeug, was ich nie verstehe. Aber ich weiß, dass es für den Computer aufwendig ist, solche Sachen zu berechnen. Und mit aufwendig meine ich sehr aufwendig, also mehrere Tage, Jahre, je nachdem. Und solche Dateien kann ich bei mir auf dem Server liegen haben als privaten Schlüssel und kann mich dann gegen Systeme authentifizieren. Das Schöne ist dann auch, es gibt einen öffentlichen Schlüssel, der, wie der Name schon sagt, den darf jeder haben und kennen. Da muss ich mir keine Sorgen machen. Und gerade da kann man sagen, wenn man zum Beispiel ein kleines Team hat, jeder gibt seinen öffentlichen Schlüssel und kann dann auf dem Server einfach sagen, diese Schlüssel dürfen auf den Server zugreifen. Dieser Benutzer gehört, diesem Benutzer gehört dieser Schlüssel. Und schon hat man keine Credentials mehr in einem Repository, wo man vielleicht mit Ansible oder anderen Sachen einen Server einrichtet, weil öffentliche Schlüssel-Committen ist vollkommen bedenkenlos, kein Sicherheitsrisiko. Und das kann man wirklich ausrollen und die Benutzer oder die Entwickler können sich dann gegen das System authentifizieren. Und der private Schlüssel ist wirklich der und das Secret, was man wirklich schützen muss und auch schützen sollte.

Ja, das ist natürlich wie immer mit privaten Schlüsseln. Das ist wie der Hausschlüssel, den sollte man auch nicht einfach mal irgendwo weggeben.

Ja.

Also ich glaube, der Private Key an noch viel weniger Leute als an den Hausschlüssel mal. Ja, definitiv.

Niemand, niemand. Also es gibt wirklich Sachen, dass man sagt, man schränkt Zugriffsrechte ein, Leserechte ist auch so ein Thema. Ich glaube, da beschweren sich auch alle Systeme, wenn die Rechte zu weit eingestellt sind. Also ich meine, unter Ubuntu und anderen kriegt man sogar Fehlermeldungen, wenn andere Nutzer den lesen könnten. Und

Ja, definitiv. Der Schlüssel, der Profit Key darf grundsätzlich und ausschließlich nur durch den eigenen Nutzer gelesen und geschrieben werden und sollte, glaube ich, sogar auch nicht ausführbar sein, wenn ich mich jetzt nicht völlig irre.

Ich müsste auch nachgucken. Weil das einfach so alltägliche Sachen sind, vergisst man den Großteil oder hakt das ab und macht es einfach, ohne sich groß Gedanken darüber zu machen.

Genau, und was man auch immer grundsätzlich bedenken sollte, ist, es macht auch gar nichts, mal die eigenen Private Keys zu erneuern, mit neuen Verschlüsselungsstandards zu arbeiten. Also wer noch R als A-Keys einsetzt, ist langsam wirklich gut an der Zeit, die mal gegen ED522, schieß mich tot, auszutauschen.

Ja.

Hier kommt wieder Autocomplete ins Spiel. Und was ich eigentlich mittlerweile wirklich bevorzuge und die und überall anwende es, ich setze meinen YubiKey dafür ein. Also sprich, noch mit K am Ende den Key erstellen, weil dann brauchst du einen zweiten Faktor dafür und dafür bietet sich halt so oft ein Hardware-Token an und der YubiKey ist da ganz hervorragend für. Dann musst du dich im Login-Vorgang nochmal authentifizieren, dass der Key da ist und als dann funktioniert es, das heißt, wenn dein Private Key doch mal wegkommen sollte, weil du den deine Haushaltshilfe ausgeliehen hast, deine E-Mail verschickt hast, oha Daniel, da kommen wir in tiefe Abgründe, aber falls er dir abhandengekommen sein sollte, weil du Bahn gefahren bist und deinen USB-Stick mal wieder hast rumliegen lassen und da war dein Private Key drauf aus irgendwelchen Gründen,

per E-Mail verschickt hast. Oh mein Gott. Ja, genau.

dann schützt halt so ein zweiter Faktor auch unfassbar gut diesen Private Key, weil hey, wenn du den nicht zufällig daneben liegen gelassen hast, beim Hardware-Token, ist es natürlich erstmal so, dass selbst wenn du den Private Key verloren haben solltest oder jemand anderes den gefunden hat, sagen wir es mal so, dass der nicht nutzbar ist.

Gab es da nicht mal irgendwas mit einem NPM-Paket, was Private Keys, also der Use Case war NPM-Pakete, die du installiert hast, lokal bei dir auf der Maschine, die gekapert wurden und die haben, glaube ich, bei dir auf dem Rechner nach Private Keys gesucht und die irgendwo hochgeladen.

Das kann gut sein, ja, da ich ja NPM selber ausschließlich im Container erlaube.

Also das ist ein realerer Use Case, als dass man seinen Key in der Bahn verliert oder so.

Kann das sein, dass es da mal Themen gab?

Da muss man echt vorsichtig sein.

Ja, ich meine jetzt, auch wenn wir an solche Netze denken wie Open Call, wo massenhaft hingegangen wird und KI-Agenten lokal auf System installiert werden, auch das ist ein Sicherheitsrisiko. Wenn man auf das gleiche System aufspielt, wie das Arbeitssystem ist und auch weitreichenden Zugriff gibt, dann ist halt auch der Private Key ganz schnell gefährdet.

Ja.

Aber zweiter Faktor schützt einen davor, dass dieser komplementierte Key dann genutzt werden kann. Nichtsdestotrotz musst du ihn de facto austauschen. Sobald der Eimer irgendwie verloren gegangen ist, ist er ja nicht mehr sicher. Dann musst du ihn austauschen. Dann hilft dir halt auch nichts anderes. Also wenn du deinen Hausschlüssel verlierst, tauchst du ja auch das Schloss. Es sei denn, du bist dir unfassbar sicher, dass du mal wieder so schusselig warst oder so wie ich immer schusselig bin und dann irgendwann ins Auto lege oder so.

Ja, kenn ich. Auch gut.

Es ist übrigens auch sehr geschickt, den Autoschlüssel vom anderen Auto in das eine Auto zu legen und dann zu suchen. Ja. Ja, ich sage ja, Keys sind, also Schlüssel an sich sind bei mir nicht sicher. Da braucht es weitere Sicherheitsmaßnahmen, dass es sicher wird. Erstaunlicherweise bin ich mit meinen Private Keys deutlich vorsichtiger als mit physischen Schlüsseln. Aber es gibt natürlich noch viel mehr Punkte, wie man so einen SSH-Zugang grundsätzlich absichert. Also ich sage jetzt mal, der sichere Login ist ja das eine Nette, den hast du aber trotzdem immer noch alle paar Sekunden jemand, der an der Tür klopft und sagt, ey, lass mich rein.

Genau. Genau. Spätestens jetzt.

Und ja, ich glaube, den guten alten Türsteher Fail2Ban kennt jeder von uns. hoffe ich, wenn nicht. Spätestens jetzt sollte man sich den mal anschauen. Was macht Fail2Ban? Der schaut letztendlich in deine Logs rein die ganze Zeit. Und wenn du zu oft vor der Tür standst und nicht reingekommen bist, dann sagt er, naja, jetzt ist es vorbei und sperrt halt deine IP-Adresse. Das ist quasi der Türsteher 2.0 vor der Disco. Also,

Genau, der trägt

Selbst wenn du fünfmal am Abend da warst, irgendwann sagt er, nee, jetzt kommt es hier gar nicht mehr rein für die nächsten 14 Tage. Du brauchst nicht wiederkommen.

Genau, also der trägt deine IP oder die IP-Adresse des Angreifers dann in die Firewall ein. Und was ich gerne genutzt habe und auch sehr interessant fand, war zum Beispiel, was ich gerne gemacht habe, ist, ich habe Feldtürbarn lauschen lassen, zum Beispiel auf dem Port 22 und nach fünf fehlerhaften Loginversuchen oder Honeypods kann man ja auch machen, dass man zum Beispiel... gewisse Accounts einfach sagt, alle, die sich da versuchen anzumelden, werden direkt gebannt, weil ich werde mich nicht als Tanja an dem System anmelden, sondern ich heiße immer anders eigentlich. Und dementsprechend habe ich die direkt gebannt und habe die auch komplett gebannt, weil du kannst zum Beispiel auch mit Fail2Bun von HT, also das war ein nettes Neben- oder ein nettes Gimmick mit HTXs irgendwo eingerichtet.

All right.

Und Fade to Bun auch auf dem Apache-Log. Damals war es ein Apache, heute wäre es ein Nginx. Oder weiß ich nicht, irgendwas anderes, was dann gerade wieder aktuell ist. Einfach mal drüber laufen lassen und da auch mit scannen lassen. Und so haben die Leute sich dann selber ausgesperrt, weil die haben dann erstmal HT-Access versucht. Ach, geht nicht, dann versuche ich mich über SSH anzumelden und sind dann schon direkt gegen die Firewall gelaufen. Und nebenbei war auch HT-Access dann abgesichert mit zum Beispiel fünf Versuchen und dann bist du einfach eine halbe Stunde gebannt.

Ja, tatsächlich, dass ich das auch ganz, oder habe das, ich mache es mittlerweile heute ein bisschen anders, aber habe das zum Beispiel auch gerne gegen Web-Oberflächen-Logins laufen lassen, wobei man da sagen muss, da ist es ein bisschen schwierig manchmal, die richtige Fehlermeldung sich aus dem Log zu fischen, um das mitzubekommen. Ich bin mittlerweile dazu übergegangen und erlaube SSH-Zugang nur noch über das VPN. Sprich, auf dem Server läuft zum Beispiel ein WireGuard und dann musst du dich beim WireGuard anmelden und nur wenn du beim WireGuard erfolgreich angemeldet bist, dann darfst du überhaupt auf das SSH zugreifen und sonst gar nicht.

Mhm.

Also sprich, ja, jetzt läuft ein weiterer Dienst, okay, auf einem weiteren Port, der offen ist, aber der SSH an sich ist nicht mehr exposed nach außen. Und du hast dann quasi zwei Schritte, zwei Authentifikationsschritte, um weiterzukommen. Dann vielleicht sogar noch den Zwei-Faktor als Sicherheit mit drin. Das ist irgendwie netter. Ja, dann spammen auch nicht immer die Logs so unfassbar zu. Das nervt mich halt unfassbar.

Mhm.

Dann suchst du mal was in den Outlocks, ganz berechtigterweise, weil irgendwie funktioniert irgendwas nicht. Und dann suchst du dich ja immer dumm und dämlich, wenn du alle auf den Port 22 drauf lässt. Ich bin aber auch überhaupt kein Fan, zum Beispiel den SSH-Port zu verschieben. Also dieses Verstecken, finde ich, macht es nur umständlich, die automatisierten Angriffe laufen weiter da drauf. Dann lieber so absichern, dass es quasi nicht von außen erreichbar ist. So ein Wireguard aufzusetzen, ist jetzt auch irgendwie keine Kunst. Das ist echt schnell gemacht und dann hast du halt einen sicheren Tunnel dahin, Nicht, dass SSH nicht grundsätzlich auch verschlüsselt wäre, aber du hast halt den Tunnel und dann deine SSH-Verbindung darüber. Und der Vorteil ist natürlich, egal wo du bist, du kannst halt immer wieder sagen, okay, jetzt mache ich das VPN auf da hin und dann logge ich mich auch über eine private IP-Adresse ein. Also du hast halt ein eigenes privates Netzwerk, dann... Das macht das auch irgendwie sehr bequem und fühlt sich sehr sicher an an der Stelle.

Die wissen, dass das da schwerer ist.

Wie gesagt, die Loks sind erstaunlich leer. Das ist das wirklich Schöne, weil beim Voyager versucht sich halt nicht jeder anzumelden, komischerweise.

Also das ist ja, hundertprozentige Sicherheit gibt es nicht, aber man redet auch von einbruchhemmenden Türen und Je mehr Technologien du sozusagen vorschaltest und es anstrengender wird, ist es einfach irgendwann uninteressant. Es gibt genug andere Leute daneben, die halt immer noch einen Port offen haben. Der Root-Benutzer zum Beispiel auch noch sich anmelden darf. Das ist auch so ein Ding, was man eigentlich direkt am Anfang ausschalten sollte. Root sollte sich einfach gar nicht per SSH verbinden dürfen, sondern

Ja, definitiv.

mit einem Nutzer, den ich mir anlege natürlich, wo ich auch vielleicht dann noch in der Sudo-Gruppe bin, aber selbst das natürlich mit Passwort geschützt nochmal, dass man gar nicht so leicht an die Root-Rechte kommt. Und das ist dann einfach mehrstufig, was man da aufbaut.

Ja. Also es ist, je länger es dauert, um an etwas ranzukommen, je unwahrscheinlicher ist nachher der der erfolgreicher Angriff, aber nicht, desto trotzdem, man muss diese Dinge monitoren, die man laufen hat, ich finde, das ist die, das, das wichtige Ding und da ist halt so etwas, wenn ich den Fade-to-Band halt monitoren muss, ob er funktioniert, ähm, dann muss ich natürlich auch immer wieder schauen, dass ich mich selber nicht aussperre, ne? Also ich kenne genug Menschen, die es geschafft haben, auch statische IP-Adressen von ganzen Unternehmen da zu sperren, weil sie der Überzeugung waren, nein, das ist richtig, wie ich mich anmelde. Dann war es aber gar nicht der richtige User oder es war nicht das richtige Zertifikat. Und dann wurde halt nicht auf fünf Minuten geschaut, sondern länger in die Loks rein, irgendwie ein paar Stunden und dann sitzt man da auf einmal und ist für 14 Tage sind alle gebannt.

Aber wo du das sagst, also ja, ein Tipp wäre, irgendwie mehrstufig zu arbeiten. Also ich habe mich auch schon mehrfach ausgeschlossen aus Systemen und bis jetzt habe ich immer Glück gehabt, dass ich gesagt habe, das erste Mal irgendwie, eine erste Stufe sind so fünf Minuten, dann darfst du nochmal und dann war ich halt gewarnt. Dann habe ich einen Kaffee geholt, einmal tief durchgeatmet, mich geschämt und dann habe ich es richtig gemacht. Aber ja, das ist ein guter Tipp. Also da

Ja, definitiv. Also je mehr Leute von der gleichen IP-Adresse kommen, je sensibler muss man damit sein, weil es kann immer sein, dass man aus irgendwelchen Gründen gerade auf die Idee kommt, einen anderen Nutzer einzutippen, als man gerade hat auf dem System.

Alleine schon nach dem Urlaub?

Ja, gerade wenn die nicht automatisiert deployed werden und sich Nutzernamen zum Beispiel unterscheiden, der eine legt die Nutzer immer mit Punkt im Namen an, der andere ohne oder so. Ja, das gibt es ja gerade in gewachsenen Systemen, gerade wenn es kleinere Setups sind, wo es halt nicht so feste Regeln gibt, die irgendwie durchgesetzt werden, ist das halt ein reales Risiko, dass du halt durch Versehen dafür sorgst, dass du halt selber nicht mehr an die Systeme rankommst. Ich meine, gut, heute... kann man sich relativ gut über, ich nehme jetzt mal mein Handy, mache da ein WLAN und dann verbinde ich mich darüber, irgendwie nochmal zu einer anderen IP-Adresse kommen, aber wenn das natürlich die statische IP-Adresse ist, von der ganzen Agentur oder so ist, dann hast du natürlich irgendwie nicht so viel Spaß damit in dem Moment, wenn dann 20 Leute da stehen und sagen, oh, es geht nichts mehr, ich komme nirgendwo mehr drauf. Vor allem bei dem Ansatz zu sagen, naja, wenn das auf dem einen Port gesperrt ist, dann sperre ich jetzt auch den anderen Port und auf einmal gehen diverse Systeme nicht.

Ja, und dann hast du einen Kollegen als Spaßvogel, der das auch noch durchschaut und dann Montagmorgen irgendwie Quatsch macht. Kannst du nicht Feierabend machen.

Ja, perfekt. Und alle stehen dann da und sagen, es funktioniert wieder nichts. Und dann werden Mundhau-Server neu gestartet und es funktioniert immer noch nicht.

Ja.

Aber genau, das ist halt ein Ding, das finde ich tricky bei Fail2Ban, auch wenn ich Fail2Ban absolut cool finde und gut finde und gerne eingesetzt habe. Wie gesagt, ich bin halt jetzt vor, ich glaube, etwas über ein Jahr halt weggegangen von Fail2Ban hin zu, okay, wir wir sorgen eigentlich dafür, dass der SSH-Port nicht mehr erreichbar ist.

Hmm.

Und dann gleichzeitig jetzt andere Möglichkeiten, zum Beispiel auch die Anmeldung zu den CNS-Systemen über eine andere Domain und diese Domain ist dann auch nur zugänglich, wenn man im VPN ist oder ähnliches. Das ein bisschen abzusichern und zu sagen, okay, die Oberflächen, wo man Dinge kaputt machen kann, dafür musst du erstmal in einem speziellen über ein spezielles Netz kommen, über eine spezielle Verbindung kommen, damit alles, was schädlich ist, über dieses Netz kommen muss.

Mhm.

Entwickler zu überwachen ist ja immer so ein, also automatisiert zu überwachen im Sinne von Anomalieerkennung ist halt immer so ein bisschen schwierig, weil Entwickler dürfen halt unfassbar viele Sachen, die normalerweise immer anschlagen. SSH-Verbindungen zum Beispiel oder SQL-Befehle und all so Sachen. Es gibt ja unfassbar viele Dinge, die Entwickler jeden Tag tun, die berechtigterweise für einen normalen Nutzer als echt gefährlich eingestuft werden. Und ähm ja

Genau das. Wir werden dafür bezahlt, das System zu verändern und wir versuchen zu verhindern, dass andere das machen.

So, und das ist halt nachher das Gefährliche. Nutzer mit vielen Rechten, die viel dürfen, viele Anomalien erzeugen, kannst du schlecht automatisiert absichern, weil du halt im Prinzip ja nur sagen kannst, okay, wenn jetzt der Rechner es auf einmal morgens um vier macht, dann ist das vielleicht sketchy. Aber vielleicht ist das auch richtig, weil dieser Server ausgefallen ist. Ja, also selbstzeitliche Beschränkungen in Regeln greifen halt nicht gut und nicht sinnvoll.

Lass einen Kollegen aus einer anderen Zeitzone arbeiten. Dann ist für ihn nicht 4 Uhr nachts. dann hast du ja auch wieder das Problem, dass Leute zu unterschiedlichen Zeiten arbeiten. Oder dass auch gerade zum Beispiel aus dem Ausland, also IP-Sperren im Sinne von, dass man sagt, aus dem Ausland darf keiner zugreifen. Du bist aber ganz schnell offiziell im Ausland, wenn du zum Beispiel in der Nähe der Grenze wohnst. Also bei uns ist es nicht weit nach Holland, wenn ich nicht aufpasse oder mal sage, ich mache mal Urlaub und arbeite mal einen Tag von woanders, schon kann ich eigentlich nicht mehr arbeiten.

Ja, das Spannende ist, ich habe deinen Wohnort nie als nah zu Holland empfunden. Aber das ist vielleicht ein anderes Thema.

Nah genug, es ist nah genug.

Ja, das stimmt. Ja, definitiv. So etwas wie IP-Sperren ist halt auch nie so richtig sicher. Das muss man auch einfach bedenken. Da ist halt häufig... Also Landesebene klappt ja immer noch ganz gut. Aber alles darunter kannst du halt eigentlich vergessen, kannst du nicht einsetzen oder so. Und ja, wie schnell fährt man einfach mal irgendwo anders hin und hat eine andere IP-Adresse und dann ist die auf einmal nicht Deutschland zugeordnet. Passiert schnell. Es gibt aber ja noch

Und dann sitzt du im Ausland, willst dem Team helfen, weil gerade eh ein Inzident passiert ist oder was und du kommst auf kein System.

Ja gut, also was wir tatsächlich machen, ist so etwas, wir sagen, okay,

Also du schließt dich dann genau zu den Situationen aus, wo du es nicht brauchen kannst meistens. Das ist dann auch noch...

Bei uns ist es nicht üblich, dass jemand aus Russland, Nordkorea und Weißrussland und ähnlichen Gebieten auf die Systeme zugreift und das verbieten wir schon, aber wir arbeiten quasi mit einer Denialiste, nicht mit einer Allow-Liste an der Stelle und da stehen natürlich dann wesentlich weniger Regionen drauf, als wenn man jetzt sagt, okay, ich verbiete alles,

Ja.

und erlaube nur das, was tatsächlich gebraucht wird. Wobei wir da ja schon wieder bei einem nächsten passenden Thema sind, nämlich einer schön konfigurierten Firewall. Ja, weil bei der Firewall sollte es nämlich genau andersherum sein. Da sollte nur das erlaubt sein, was man tatsächlich braucht und per Default alles verboten sein, was nicht erlaubt ist.

Genau das. Grundeinstellung ist ja meistens Port 22, damit man überhaupt irgendwas machen kann. Und da kommt dann eigentlich nur noch oft HTTP, HTTPS dazu. Und für 90% der Fälle hat das gereicht bis jetzt.

Ich habe da noch mehr Ports zum Angebot, die ich gerne offen habe.

Und zwar...

Ich finde so etwas wie die SMTP-Verbindung ist ganz nett, dass man mir das System auch e-mails schicken kann.

Ja. Also ausgehender SMTP, ja. Ja.

also beim externen E-Mail-Server einloggen, weil ich möchte nicht, dass der Server an sich E-Mails schickt, sondern dass die Software sich beim SMTP-Server authentifizieren darf, kann und dann verschickt Ich glaube, beim Stateless musst du auch eingehend Verbindungen dann erlauben. Da muss man nämlich aufpassen mit der Firewall. Es gibt Stateless und Stateless. Das heißt, wenn du eine Stateless-Firewall hast, musst du sehr viel mehr freigeben, weil sie halt nicht weiß, dass das die Rückverbindung ist. Das ist ein bisschen unpraktisch. Da hat man sehr viel offen gefühlt von einem dynamischen Port-Range. Ähm... So, was habe ich noch gerne auf? Ein eingehend WireGuard. Dafür mache ich den Pod 22 aber dichter. Das ist mein Angebot quasi, ja? Den WireGuard auf, den SSH zu. So, das ist eigentlich das. Lass mal überlegen, was könnte ich noch aufhaben. Je nach Setup hast du natürlich noch andere fancy Sachen. Also ich sage jetzt mal, wenn du Sprachverbindungen erlaubst, dann musst du natürlich auch entsprechende Ports aufmachen. So, jetzt kommt es natürlich wieder sehr auf Setup an, aber ich glaube, man kann gut sagen, in einem normalen CMS-E-Commerce-Setup sollte nicht mehr offen sein als Port 80 und der 443 und meinetwegen dann halt noch ein weiterer für die Verwaltung von was auch immer.

Ja, also dann kommen natürlich, wie du sagst, externe Dienste hinzu. Manchmal hast du dann, gerade im E-Commerce, hast du Commerce-Tools oder andere Dienstleister, die du anpingen willst, ERP-Systeme, CRM. Aber das ist nicht so kritisch, weil oft sind die entweder... auch im ähnlichen Netzwerk betrieben, also Firmen intern, dass du sagen kannst, ich erlaube zum Beispiel nur lokale Netze, also ausgehenden Traffic auf dem Port in lokale Netze oder es gibt wirklich fest definierte IP-Adressen, wo du sagen kannst, dieser Dienst ist nur unter dieser IP-Adresse verfügbar und dann grenzt man das natürlich so stark ein, dass nur auf diese IP-Adresse mit diesem Port zugegriffen werden kann und das ist ja dann auch fast geschlossen, sage ich mal.

Ja, wobei das ja fast schon netzwerkseitig reglementiert wird. Also es ist dann ja nur ein, okay, die Ports sind auch ausgehend in Ordnung.

Aus Faulheit. Mhm.

Ausgehende Ports sind ja meistens auch gar nicht so stark reglementiert. Die meisten arbeiten mit sehr offenen Einstellungen, weil du natürlich sehr viel einstellen musst. Du rennst halt schnell in dieses Thema mit, naja, gut, jetzt habe ich den Port 80 auf, jetzt brauche ich 4.4.3 auf, auch noch und dann muss ich noch alle dynamischen Ports aufmachen und 8 an den SMTPS und den was haben wir denn noch? DNS, 53 aufmachen, dann noch Zeiten und so weiter und so fort.

Mhm.

Also ausgehend konfiguriert man meistens ja sehr viel länger an Fireball-Regeln als an eingehenden. Und Ich glaube, das machen die wenigsten tatsächlich so. So ganz konsequent. Gerade weil es halt auch immer ist, jetzt funktioniert das auf einmal nicht und dieses funktioniert nicht. Und man hat meistens gar nicht so eine gute Liste irgendwo, wo man nachschauen kann und sagen kann, naja gut, die Software braucht jetzt diese ausgehenden Ports.

Ja, also es muss auch die Kirche im Dorf lassen. Also unsere Ausgangslage war ja, dass wir gesagt haben, es ist ein Testsystem, was hoffentlich nicht lange lebt und wo man einfach sagt, es gibt Tools, die man schnell installieren kann. Auch eine Firewall ist eigentlich schnell eingerichtet und es ist besser, minimalste Konfiguration zu haben, als zu sagen, oh mein Gott, ich konfiguriere mich tot, ich mache jetzt mal gar nichts. Also das wäre das Schlechteste von allem. Deswegen finde ich das auch nicht falsch oder verwerflich zu sagen, man kontrolliert den eingehenden Verkehr, macht sich ein Regelset, vielleicht schafft man das ja sogar wirklich auch ausgehenden grob offen zu lassen, ohne dass man sich kaputt konfiguriert und einfach ein paar Port-Bereiche offen lässt.

Ja, genau, das reicht ja meistens.

Das reicht ja auch schon oft.

Gerade an der Stelle muss man ja sagen, dass die meisten Sachen auch über Standard-Ports laufen. Und wenn jemand im Server drin ist und dann raus kann, dann ist es auch fast schon egal, was man auf dem Server selber konfiguriert hat.

Hm.

Deswegen sage ich ja, dass das eigentlich schon auf Netzwerkebene muss man da Firewall-mäßig regeln. Das ist auch, wo ich eigentlich gerne eine Firewall sehe. Muss ich ganz ehrlich sagen. Ich sehe gerne, dass die grundsätzlich eine Firewall auch im Netzwerk unterwegs ist und da schon entsprechend vorfüllt hat. Vielleicht ein bisschen gröber. und dann nicht sagt, okay, SSH darf nur aus dem Netzsegment kommen, aber dass grundsätzlich mal nicht jeder Unsinn zugelassen wird, dass man da schon vorfiltert und gar nicht so viel Traffic auf das System selber bekommt, weil alles, was wir vorher wegfiltern können,

Mhm.

müssen wir halt nicht mehr auf dem Server uns anschauen, analysieren und da abwehren, sondern können halt ganz konkret sagen, das ist halt nicht da, brauche ich nicht. Wir hatten, glaube ich, beim vorletzten Mal irgendwie das Beispiel mit dem Eimental der Käse. Das funktioniert natürlich genauso hier bei Serversicherheit und Absicherung auf Netzwerkebene, dass wir halt sagen, okay, wir bauen uns halt diese unterschiedlichen Layer aus. Die Netzwerk-Firewall nimmt uns einen Teil an Traffic weg, dann rennt unser Freund halt entweder ins Fato-Ban oder scheitert daran, dass er nicht weiß, dass WireGuard dort läuft und Dann sind die nächsten weg und dann habe ich erst meinen SSH-Login, wo dann mein persönlicher Nutzer sich mit meinem Key anmelden muss, der im besten Fall noch einen zweiten Faktor benutzt.

Und da gibt es Applikationsseite ja auch mittlerweile echt viel. Also wenn ich überlege, was bei Symphonie mittlerweile möglich ist, also auch solche Sachen, dass du Blacklists aufbauen kannst mit Fehlversuchen und, und, und. Also das ist dann nochmal eine Schicht, auch auf Applikationsseite ja auch nochmal. Na, das ist ja auch.

Genau, wir rennen dann ja mit diesen Dener und Allow-Lists halt in, genau in diese Themen rein, wo man dann nochmal sehr spezifisch filtern kann mit halt den Risiken, okay, wir sperren uns vielleicht auch selber aus an einem Montagmorgen, weil wir noch nicht genug Kaffee hatten.

Mhm. Ja, bestimmt sogar. Was ich aber auch noch interessant finde bei dem Thema ist, wir sind jetzt von einem V-Host ausgegangen und zumindest so die letzten Setups, die ich hatte, waren alle bei AWS zum Beispiel. Also mit ECS und Fargate und das Fazit wäre von dem, so wenig wie möglich installieren, was man braucht.

Ja.

Bei AWS ist es halt auch schön, dass du hingehst und Netze definierst und genau das, was du besprochen hast mit der Netzwerk-Firewall, Da definierst du ja auch Regeln, welche Netze wohin kommunizieren dürfen. Und das macht man da ja auch über solche Regeln. Und deswegen habe ich mittlerweile nur noch Port 80 im Kopf, weil der Load Balancer davor HTTPS, also 443 macht intern in dem Netz, dürfen die Container nur noch mit dem Load Balancer und der Datenbank kommunizieren. Und ansonsten gibt es da gar nicht mehr viel, was da eigentlich noch nach außen darf.

Ja, und da, also tatsächlich mag ich ja auch bei, ich glaube, das geht bei allen Hyperscalern auf dem Markt, dass du eigentlich gar kein SSH-Login mehr benötigst, sondern dich dann da über die Webkonsole anmelden kannst und das machen kannst, ne, das heißt, du exposest gar nicht mehr außerhalb des Netzwerks, es gibt da entsprechende Mechanismen, die aber ja im Prinzip funktionieren wie ein Jump-Host, ja, das muss man auch so sagen, ja, so, ähm,

Ja, genau. Bastion Server.

Wobei ich auch nicht unbedingt der größte Fan davon bin, zu sagen, okay, ich terminiere mein TLS vollständig am Load Balancer. Aus dem Hintergrund, weil wenn ich dann halt doch in die Systeme reinkomme, dann habe ich da alles unverschlüsselt laufen, also da bin ich ein großer Fan von MTLS tatsächlich auch hinter dem Loadbalancer zu haben, ja, ist ein anderes Zertifikat, aber wo geht es, ja, das wird ausgetauscht, also nicht wo geht es, aber es ist halt abgesichert und zwischen den Punkten läuft dann halt eine verschlüsselte Verbindung, so dass da dann theoretisch nur 4,4,3 offen wäre bei mir.

Mhm. Mhm.

Bin ich in der Ecke sympathischer, Ich weiß, ist im BSI Grundschutz zum Beispiel gar nicht gefordert, ja, dass da nur für Systeme gefordert, die erhöhte Sicherheit benötigen. Also vielleicht fällt das in die Kategorie Ja, nice to have.

Genau das war das.

Es fühlt sich aber auch besser an und ich bin ein großer Fan von standardisierten Setups insgesamt und Wenn man das halt einmal alles gebaut hat, dann kann man das halt für jedes Setup auch ausrollen. Das ist mein Gedanke dahinter, gerade weil, ich sag jetzt mal, die Rechenleistung, die dafür benötigt wird, ist heute auch verschwindend gering. Das ist jetzt nicht mehr so das Argument zu sagen, wir machen kein HTTPS, weil dann brauchen wir so viel mehr an Serverkapazitäten. Und ich bin auch ehrlicherweise mittlerweile so ein bisschen Fan von diesen Web-Command-Line-Tools, wo ich dann halt wirklich gar nicht den SSH-Zugang mehr brauche, wenn ich bei einem Hyperscaler bin, wenn ich natürlich sagen muss, okay, ich habe halt irgendwo einen V-Server-Server rumstehen und da muss ich jetzt per SSH drauf, weil es gibt halt nicht diese fancy Technik, die mir über einen Jump-Post automatisch erlaubt, dass ich da draufkomme, dann ist, glaube ich, das Absichern, so wie wir das jetzt besprochen hatten, eigentlich ein guter Standard und ein guter Weg. Und bei unseren geliebten Hyperscalern Ich weiß zum Beispiel auch gar nicht, wie das bei europäischen Cloud-Anbietern ist, muss ich gestehen, weil ich diese selten benutze. Und weil wir keine Kunden haben, die das nutzen. Das ist ein bisschen schade. Da ist halt entweder, ich habe den europäischen Server oder den US-Hyperscaler. Dazwischen gibt es nicht. Bisschen schade.

Ich muss aber sagen, ich nutze gerne Hyperscaler gerade für kleinere Projekte, weil genauso wie du das beschrieben hast, dieses, dass ich die Konfiguration in zum Beispiel Terraform oder einer anderen Form vorbereiten kann und auch kopieren kann, sorgt dafür, dass ich halt schon ein halbwegs fertiges Setup habe.

Ja.

Dadurch, dass ich nur Sachen nutze, die ich brauche, habe ich zum Beispiel auch keinen SSH-Zugang auf einen Container. Zu 99 Prozent brauche ich das gar nicht mehr. Also ist auch da ein Einfallstor einfach weg. Ich kann das Ganze viel besser konfigurieren mit einem Bastion Host zum Beispiel, also ein EC2 Container, der in dem Netzwerk startet und dann genau das Gleiche macht, was du vorher beschrieben hast, mit einem VPN theoretisch, mit meinen privaten Zugangsdaten nur da rein und den baue ich sogar wieder ab, wenn ich den nicht mehr brauche. Also ist der auch nur kurzzeitig da.

Jetzt muss man auch aber auch fairerweise sagen, Terraform läuft ja nicht nur beim Hyperscaler. Das kannst du ja mit fast jedem Anbieter machen.

Ja, genau. Ja.

Also da scheitert das dann wirklich nicht dran. Ich muss ehrlicherweise mal sowas ausprobieren wie Deck-IT und so. Also es gibt ja mittlerweile europäische Alternativen, das würde ich einfach gerne mal mir anschauen und ausprobieren und schauen, was gibt es denn da, wie funktioniert dort das Tooling. Und Containersicherheit ist ja nochmal ein ganz anderes Ding. Also ich finde, Container leben ja vor allem davon, dass sie halt minimalst aufgebaut sind. Und Container kann man auch wirklich gut dadurch härten, dass du dann zum Beispiel auch keinen Paketmanager mehr im fertigen Container drin hast.

Ja, kann nichts mehr nachinstalliert werden.

Ja, dann meinetwegen sei halt auf dem Ding drauf, dann kannst du dir halt mit LLS noch die Container-Inhalte anschauen. Wenn es ein Read-Only-Filesystem ist, dann find mal lustig erstmal die paar Stellen, wo überhaupt geschrieben werden darf. also Container absichern, auch in kleinen Setups, geht ja durch die Standardisierung, durch die Deklaration in Files deutlich einfacher und schneller als jetzt V-Hosts abzusichern. Also ich finde V-Hosts abzusichern, wenn man sagt, okay, ich baue mein Terraform oder Ansible oder meinetwegen auch ein Nix-OS-Setup auf, finde ich, ist das immer noch mehr Arbeit bis zu einem gewissen Punkt, die du gerade in kleinen Teams halt nicht so hast. Also in kleinen Teams siehst du halt eher weniger jemand, der sich hinsetzt und jetzt sagt, ich lerne jetzt Ansible, um unsere fünf Server zu verwalten. So, da muss man ja auch ehrlich sagen.

Kann ich nur empfehlen. Also wenn er es nicht kann, es macht nicht nur, dass es Spaß macht, es macht einem das Leben leichter.

Ja, man muss ja auch sagen, die Einstiegshürde ist ja vorhanden und das, was ich häufig sehe, ist, dass gerade halt in kleinen Teams diese Sachen gar nicht so stark automatisiert werden.

Ja.

Nicht, dass ich befürworte, dass man das nicht automatisieren sollte, ja, ganz im Gegenteil, ich bin ja ein großer Fan davon, alles möglichst weitgehend zu automatisieren und zu standardisieren, aber meistens fehlt die bisschen die Erkenntnis oder wenn die Erkenntnis dann da ist, dann sagt man, ja, uns fehlt die Zeit, solche Dinge zu machen. Und das ist, finde ich, so ein bisschen so eine Fehlannahme. An dem Zeitpunkt, wo ich das dann einmal automatisiert habe, spare ich, wenn ich ganz ehrlich bin, nämlich viel Zeit, weil ich Dinge nicht fünfmal tue oder x-mal tue, sondern halt einmal mache, deploye, okay, und dann muss ich ehrlicherweise das Tool noch warten,

Ja, versuch mal die Unterschiede zu finden.

Toolwartung aus meiner Erfahrung ist immer weniger, als wenn ich sagen muss, okay, ich mache diese ganzen Sachen x-mal und das Verrückte ist ja auch, dann macht man das 5-6-mal oder so und bei einem System vertut man sich immer. dann kommt da irgendwas dazwischen und dann hat man auf einmal Unterschiede oder der eine Server ist dann doch irgendwie älter, da hat man sich dann nicht getraut, die Distribution hochzuziehen und so.

Ja.

Das sind dann ja so Fallschricke, in die man reinrennt und dann hat man so ein Legacy-System da auf einmal stehen mit einer alten PHP-Version oder einer alten Apache-Version oder beides und Eigentlich sollte die Applikation aber auch auf der neuen PHP-Version laufen und das traut sich dann keiner. Und mit Automatisierung tendiert man ja eher dazu zu sagen, okay, jetzt ist auch wirklich alles gleich und wir versuchen diesen Standard überall drin zu halten, damit wir eben diese Probleme nicht haben.

Also als Beispiel mit Ansible, es muss nicht jeder im Team Ansible können, aber wenn Ansible so konfiguriert ist, dass es zum Beispiel auf fünf Servern einfach den Public Key verteilt von allen Entwicklern, die im Team sind. Es gibt in dem Repo einen Ordner, da liegen alle Public Keys drin. Ich glaube, da muss kein Entwickler Ansible für können, um zu verstehen, wo er sein Public Key reinpackt in dem Repo, das pushen kann und sagen kann, hier, es gibt einen, der kennt sich besser damit aus oder der ist dafür zuständig. Und dann kann er dem Bescheid sagen, hier, roll den mal bitte aus. Oder vielleicht ist das sogar automatisiert in einer Pipeline so weit drin, dass er das sogar selber pushen kann und selber dann Zugang ausrollen könnte.

Mhm.

je nachdem, wie da das Vertrauensverhältnis ist und wie man das aufsetzt. Und das ist dann ein nettes Gimmick, wo dann auf einmal auf fünf Rechnern eine neue Key da ist. Oder wenn der Mitarbeiter ausscheidet, ist es genauso schnell, den Key dann rauszunehmen, draufzudrücken und auf einmal ist innerhalb von maximal einer Minute der Zugang zu fünf Servern entzogen. Wenn du per SSH da irgendwo rein musst und Copy-Pasten, da kriegst du hin, aber je mehr Server das sind, umso mehr wirst du genervt, weil das einfach langweilige Arbeit ist und die muss ja keiner machen.

Ja, definitiv. Zum Beispiel, das ist bei uns auch automatisiert. Das hängt bei uns tatsächlich an den Projektzugriffsrechten im GitLab. Wenn du darauf zugefasst, mit einer bestimmten Berechtigungsstufe, dann schreiben wir deinen Public Key, den das GitLab über API übrigens ausspuckt, auf den Server drauf.

Ja.

alle Keys, mit denen du dich ins GitLab einloggen kannst, oder wer ist es? Es können nämlich mehrere sein, werden dann nämlich tatsächlich deployed bei uns. Ist ganz smart, und in dem Moment, wo halt jemand die Berechtigung entzogen bekommt, ja, dann ziehen wir die halt auch auf den Server, ne, und das bedeutet halt, sobald ein Nutzer irgendwie gesperrt wird, gebannt wird, oder sonst irgendwas, aus vielleicht auch automatisierten Gründen,

Es wiegt das einfach auf. Also...

falsch angemeldet, sind auch direkt die Zugänge zum Server weg. Natürlich birgt auch hier Automatisierung ein gewisses Risiko. Aber der Nutzen überwiegt einfach. Ja, es macht ja wie bei allen Sicherheitsmaßnahmen immer Sinn, einen Backup-Weg zu haben, wie noch jemand reinkommt, falls alles katastrophal schiefläuft.

Oder die Firewall-Regeln falsch eingestellt sind.

Quasi einen gesicherten User mit einem speziellen SSH-Key.

Oh ja.

So wäre dann halt quasi der Backup-Weg, wie dann der Zugang für alle anderen wiederhergestellt werden könnte, falls zum Beispiel dieser Deploy-Prozess katastrophal schiefläuft und auf einmal die Authorized Key korrupt wird. Ja gut, Firewall-Regeln, jetzt, naja.

Ja, also habe ich auch schon automatisiert, deployed und durfte danach neu anfangen.

Ja, ja.

Aber ja, das automatisierte Deployment ist super interessant.

Das ist natürlich... Es ist ja auch häufig so, zum Beispiel in der Runner steht natürlich jetzt nicht bei mir unterm Schreibtisch.

Also ich habe keine Zahlen, aber man spart einfach Zeit. Zeit, die man für wichtigere Sachen gebrauchen kann oder nutzen kann. Und dafür sind Leute einfach zu teuer, als dass sie irgendwie zwei Stunden lang irgendwo Copy-Paste von Dateien machen und auf irgendwie x-Servern an Sachen austauschen. Mhm.

Das heißt, er ist in einem Rechenzentrum, hat eine viel geilere Anbindung an dieses Internet, als das DSL, worüber ich hier gerade drinnen hänge. Und verschiebt halt die Daten auch viel schneller. Also ganz real, wenn der Runner im Rechenzentrum läuft, ist er viel schneller fertig mit dem Shit, als wenn er bei mir läuft. Allein wegen den Übertragungsgeschwindigkeiten. Und das ist etwas, das man gar nicht unterschätzen darf, dass so ein Runner vernünftig ausgestattet ist und natürlich gesichert und alles, was dazu gehört. Und Aber das ist vielleicht auch nochmal ein Thema für eine andere Folge.

Das oder wie ich es geschafft habe, Montagabend um 8 Uhr nicht das System abzuschießen.

Automatisiertes Deployment, ja. Warum ich zwischendrin Kaffee trinken gehe und dann überrascht bin, dass es deployed ist.

Genau.

Ja, nur weil der Test gefällt ist und die Pipeline blockiert war. Warum kann ich denn nicht auf Protsch? Weil da leuchtet was rot. Was soll das denn? Ja, ich... Noch besser ist natürlich Freitagsnachmittags.

Genau.

Eigentlich schon im Feierabend und nur kurz ausrollen.

Ja, aber auch die wiederholen, also gleiche Beispiel, sich wiederholende Schritte, die einfach viel Zeit in Anspruch nehmen, wo der Entwickler sinnvoller eingesetzt ist. Also je nachdem, was du machst, musst du Tests hintereinander ausführen und, und, und. Und das dauert einfach seine Zeit. 10, 15, 20, 30 Minuten, je nach Projekt. Ich habe Projekte gehabt, da hat das eine Stunde gedauert, bis wirklich alles fertig war. Mit Container bauen, mit Tests. Also,

Das ist automatisierte oder das manuelle?

Das automatisierte. Da waren End-to-End-Tests und, und, und. Also es ist viel mehr passiert, war ein großes Team. Aber da wärst du verrückt geworden, wenn du das jedes Mal von Hand machen müsstest.

Ja, also ich hatte auch Projekte, wo ich vier Stunden von Hand deployed habe. So ein totaler Wahnsinn. Das ist das beste Beispiel dafür, dass man Dinge automatisiert, weil danach ist das in 15 Minuten gelaufen.

Hm, okay.

Entweder war ich unfassbar schlecht und langsam beim Kopieren von diesen Dingen oder es hat sich ganz ernsthaft direkt gelohnt, die Automatisierung dafür zu bauen.

Ja. Ja. Das war eine gute Tat für heute. Feierabend.

Anyway, jetzt hast du mir ja ausgeredet, dass ich mich mit Root unter IP-Adresse oder Root1234 auf meinem Server anmelde. Tja, was mache ich denn jetzt, Daniel? Ja, deine gute Tat für heute. Und sagst, Ansible ist total super und muss überall laufen. Das lassen wir jetzt mal so stehen, glaube ich.

ich liebe so endgültige Aussagen, die sind so falsch und so fehl am Platz. Aber ja, es kann vieles besser machen oder es macht vieles besser. Kein Root-Zugriff, SSH vernünftig absichern, vernünftigen Key nutzen. Mit dem YubiKey zum Beispiel, das kannte ich vorher gar nicht oder habe ich gelesen, habe ich nur nicht genutzt, werde ich jetzt die Tage nachholen, weil das triggert mich sehr.

Ja, also fassen wir mal zusammen, automatisierte Regeln zur Konfiguration machen das Leben besser, um das ein bisschen toolneutral zu halten.

Und dann hat man schon was. Ach, das hört sich voll klug an. Ja, definitiv. Ja. Genau.

Ja. Gut, ich glaube, da sind wir uns einig und können dann unsere Folge für diesmal dafür schließen und sehen uns, hören uns wieder in zwei Wochen. zur nächsten Folge Secrets Not Included.