Transcript
Kai Ole Hartwig: Willkommen zu Secrets Not Included im Podcast mit Daniel und Ole.
Kai Ole Hartwig: Diesmal schon die Folge 4.
Kai Ole Hartwig: Und wir möchten heute mal darüber reden, wie sichern wir denn mal so Server ein bisschen ab?
Kai Ole Hartwig: Was machen wir da so mit dem SSH-Zugang?
Kai Ole Hartwig: Und was sind unsere Lieblingspasswörter für den Hut-Zugang?
Kai Ole Hartwig: Daniel.
Daniel Langemann: Genau.
Daniel Langemann: 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...
Daniel Langemann: Irgendwie ist jeder irgendwo mal auf dem Server gewesen und irgendwie funktioniert das.
Daniel Langemann: Und gerade so in kleineren Projekten.
Daniel Langemann: Also das Thema wird auch eher so in Richtung kleinere Teams gehen.
Daniel Langemann: 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.
Daniel Langemann: Und die machen den ganzen Tag nichts anderes.
Daniel Langemann: 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,
Daniel Langemann: Und dann bleibt das Ding einfach stehen, weil man im Gefecht, im Alltagsgeschäft einfach das vergisst und dann bleibt er da stehen.
Kai Ole Hartwig: Du meinst, mein Lieblingspasswort, Route1234.
Daniel Langemann: Und auf einmal läuft ein halbes Jahr lang, ein Jahr lang ein Server, wo sich keiner drum kümmert.
Daniel Langemann: Am besten noch ein ganz schlechtes Passwort irgendwo mit drin.
Daniel Langemann: So das Übliche.
Daniel Langemann: Genau, genau.
Kai Ole Hartwig: Das merkt man sich halt so schön einfach.
Kai Ole Hartwig: Das ist ja auch, dann vergisst man das nicht.
Kai Ole Hartwig: Man braucht auch gar nicht so einen Passwortmanager und so.
Kai Ole Hartwig: Ich finde das eigentlich ziemlich super, wenn das so einfach ist.
Daniel Langemann: Ja, genau.
Daniel Langemann: Die bösen Jungs finden das auch super.
Daniel Langemann: Da brauchst du dann... Genau.
Kai Ole Hartwig: Ja, schau mal, das ist Shared Use.
Kai Ole Hartwig: Umweltschutz vielleicht.
Daniel Langemann: 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
Daniel Langemann: versuchen, sich mit allen möglichen Passwörtern anzumelden.
Daniel Langemann: Also wirklich die einfach nur noch durchlaufen und ausprobieren, ausprobieren, ausprobieren, um irgendwelche Zufalls- oder Glückstreffer zu landen.
Daniel Langemann: 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
Daniel Langemann: 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.
Kai Ole Hartwig: Ich glaube, solange du den Strom nicht bezahlen musst, ist das durchaus noch interessant.
Kai Ole Hartwig: Also
Daniel Langemann: Und sonst rumspammen geht auch immer ganz gut über fremde Server.
Daniel Langemann: Deswegen ist es definitiv sinnvoll, da so ein bisschen für Sicherheit zu sorgen und es den Leuten nicht zu leicht zu machen.
Daniel Langemann: Und das ist manchmal leichter, als man denkt.
Daniel Langemann: 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.
Daniel Langemann: Weil wir waren beide der Meinung, dass wir es nicht schaffen, lang genug darüber zu reden.
Daniel Langemann: Nachdem wir geguckt haben, was uns alles einfällt, gehe ich davon aus, schaffen wir das heute.
Kai Ole Hartwig: Ja, wir werden mal sehen.
Kai Ole Hartwig: Also eigentlich ist das ja auch nicht schwierig.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: gibt es denn diese User?
Kai Ole Hartwig: 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?
Kai Ole Hartwig: Oder welches Feedback kommt auch von dem System?
Kai Ole Hartwig: Das ist ja alles hochautomatisiert.
Kai Ole Hartwig: 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?
Kai Ole Hartwig: Und ich sage jetzt mal, die einfachste Maßnahme ist,
Kai Ole Hartwig: 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.
Daniel Langemann: Also grundlegend ist es ja so, Passwörter, Menschen sind einfach schlecht.
Daniel Langemann: Und da zähle ich mich besonders zu, ich kann mir Passwörter nicht merken.
Daniel Langemann: Die meisten nutzen ja Passwortmanager mittlerweile, das ist gut.
Daniel Langemann: Und Zertifikate sind...
Daniel Langemann: Also da steht wirklich mathematisch viel hinter.
Daniel Langemann: Also das früher hat man Primzahlen genutzt mit RDS zum Beispiel als Verschlüsselung.
Daniel Langemann: Mittlerweile nimmt man Kurvenberechnung, also ganz cooles mathematisches Zeug, was ich nie verstehe.
Daniel Langemann: Aber ich weiß, dass es für den Computer aufwendig ist, solche Sachen zu berechnen.
Daniel Langemann: Und mit aufwendig meine ich sehr aufwendig, also mehrere Tage, Jahre, je nachdem.
Daniel Langemann: Und solche Dateien kann ich bei mir auf dem Server liegen haben als privaten Schlüssel und kann mich dann gegen Systeme authentifizieren.
Daniel Langemann: Das Schöne ist dann auch, es gibt einen öffentlichen Schlüssel, der, wie der Name schon sagt, den darf jeder haben und kennen.
Daniel Langemann: Da muss ich mir keine Sorgen machen.
Daniel Langemann: 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.
Daniel Langemann: Dieser Benutzer gehört, diesem Benutzer gehört dieser Schlüssel.
Daniel Langemann: Und schon
Daniel Langemann: 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.
Daniel Langemann: Und das kann man wirklich ausrollen und die Benutzer oder die Entwickler können sich dann gegen das System authentifizieren.
Daniel Langemann: Und der private Schlüssel ist wirklich der und das Secret, was man wirklich schützen muss und auch schützen sollte.
Kai Ole Hartwig: Ja, das ist natürlich wie immer mit privaten Schlüsseln.
Kai Ole Hartwig: Das ist wie der Hausschlüssel, den sollte man auch nicht einfach mal irgendwo weggeben.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also ich glaube, der Private Key an noch viel weniger Leute als an den Hausschlüssel mal.
Kai Ole Hartwig: Ja, definitiv.
Daniel Langemann: Niemand, niemand.
Daniel Langemann: Also es gibt wirklich Sachen, dass man sagt, man schränkt Zugriffsrechte ein, Leserechte ist auch so ein Thema.
Daniel Langemann: Ich glaube, da beschweren sich auch alle Systeme, wenn die Rechte zu weit eingestellt sind.
Daniel Langemann: Also ich meine, unter Ubuntu und anderen kriegt man sogar Fehlermeldungen, wenn andere Nutzer den lesen könnten.
Daniel Langemann: Und
Kai Ole Hartwig: Ja, definitiv.
Kai Ole Hartwig: 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.
Daniel Langemann: Ich müsste auch nachgucken.
Daniel Langemann: 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.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also wer noch R als A-Keys einsetzt, ist langsam wirklich gut an der Zeit, die mal gegen ED522, schieß mich tot, auszutauschen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Hier kommt wieder Autocomplete ins Spiel.
Kai Ole Hartwig: Und was ich eigentlich mittlerweile wirklich bevorzuge und die
Kai Ole Hartwig: und überall anwende es, ich setze meinen YubiKey dafür ein.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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
Kai Ole Hartwig: 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,
Daniel Langemann: per E-Mail verschickt hast.
Daniel Langemann: Oh mein Gott.
Daniel Langemann: Ja, genau.
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Kai Ole Hartwig: Das kann gut sein, ja, da ich ja NPM selber ausschließlich im Container erlaube.
Daniel Langemann: Also das ist ein realerer Use Case, als dass man seinen Key in der Bahn verliert oder so.
Kai Ole Hartwig: Kann das sein, dass es da mal Themen gab?
Daniel Langemann: Da muss man echt vorsichtig sein.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: Aber zweiter Faktor schützt einen davor, dass dieser komplementierte Key dann genutzt werden kann.
Kai Ole Hartwig: Nichtsdestotrotz musst du ihn de facto austauschen.
Kai Ole Hartwig: Sobald der Eimer irgendwie verloren gegangen ist, ist er ja nicht mehr sicher.
Kai Ole Hartwig: Dann musst du ihn austauschen.
Kai Ole Hartwig: Dann hilft dir halt auch nichts anderes.
Kai Ole Hartwig: Also wenn du deinen Hausschlüssel verlierst, tauchst du ja auch das Schloss.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, kenn ich.
Daniel Langemann: Auch gut.
Kai Ole Hartwig: Es ist übrigens auch sehr geschickt, den Autoschlüssel vom anderen Auto in das eine Auto zu legen und dann zu suchen.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, ich sage ja, Keys sind, also Schlüssel an sich sind bei mir nicht sicher.
Kai Ole Hartwig: Da braucht es weitere Sicherheitsmaßnahmen, dass es sicher wird.
Kai Ole Hartwig: Erstaunlicherweise bin ich mit meinen Private Keys deutlich vorsichtiger als mit physischen Schlüsseln.
Kai Ole Hartwig: Aber es gibt natürlich noch viel mehr Punkte, wie man so einen SSH-Zugang grundsätzlich absichert.
Kai Ole Hartwig: 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.
Daniel Langemann: Genau.
Daniel Langemann: Genau.
Daniel Langemann: Spätestens jetzt.
Kai Ole Hartwig: Und ja, ich glaube, den guten alten Türsteher Fail2Ban kennt jeder von uns.
Kai Ole Hartwig: hoffe ich, wenn nicht.
Kai Ole Hartwig: Spätestens jetzt sollte man sich den mal anschauen.
Kai Ole Hartwig: Was macht Fail2Ban?
Kai Ole Hartwig: Der schaut letztendlich in deine Logs rein die ganze Zeit.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das ist quasi der Türsteher 2.0 vor der Disco.
Kai Ole Hartwig: Also,
Daniel Langemann: Genau, der trägt
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Du brauchst nicht wiederkommen.
Daniel Langemann: Genau, also der trägt deine IP oder die IP-Adresse des Angreifers dann in die Firewall ein.
Daniel Langemann: 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...
Daniel Langemann: 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.
Daniel Langemann: 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.
Kai Ole Hartwig: All right.
Daniel Langemann: Und Fade to Bun auch auf dem Apache-Log.
Daniel Langemann: Damals war es ein Apache, heute wäre es ein Nginx.
Daniel Langemann: Oder weiß ich nicht, irgendwas anderes, was dann gerade wieder aktuell ist.
Daniel Langemann: Einfach mal drüber laufen lassen und da auch mit scannen lassen.
Daniel Langemann: Und so haben die Leute sich dann selber ausgesperrt, weil die haben dann erstmal HT-Access versucht.
Daniel Langemann: Ach, geht nicht, dann versuche ich mich über SSH anzumelden und sind dann schon direkt gegen die Firewall gelaufen.
Daniel Langemann: Und nebenbei war auch HT-Access dann abgesichert mit zum Beispiel fünf Versuchen und dann bist du einfach eine halbe Stunde gebannt.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich bin mittlerweile dazu übergegangen und erlaube SSH-Zugang nur noch über das VPN.
Kai Ole Hartwig: 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.
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und du hast dann quasi zwei Schritte, zwei Authentifikationsschritte, um weiterzukommen.
Kai Ole Hartwig: Dann vielleicht sogar noch den Zwei-Faktor als Sicherheit mit drin.
Kai Ole Hartwig: Das ist irgendwie netter.
Kai Ole Hartwig: Ja, dann spammen auch nicht immer die Logs so unfassbar zu.
Kai Ole Hartwig: Das nervt mich halt unfassbar.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Dann suchst du mal was in den Outlocks, ganz berechtigterweise, weil irgendwie funktioniert irgendwas nicht.
Kai Ole Hartwig: Und dann suchst du dich ja immer dumm und dämlich, wenn du alle auf den Port 22 drauf lässt.
Kai Ole Hartwig: Ich bin aber auch überhaupt kein Fan, zum Beispiel den SSH-Port zu verschieben.
Kai Ole Hartwig: Also dieses Verstecken,
Kai Ole Hartwig: finde ich, macht es nur umständlich, die automatisierten Angriffe laufen weiter da drauf.
Kai Ole Hartwig: Dann lieber so absichern, dass es quasi nicht von außen erreichbar ist.
Kai Ole Hartwig: So ein Wireguard aufzusetzen, ist jetzt auch irgendwie keine Kunst.
Kai Ole Hartwig: Das ist echt schnell gemacht und dann hast du halt einen sicheren Tunnel dahin,
Kai Ole Hartwig: Nicht, dass SSH nicht grundsätzlich auch verschlüsselt wäre, aber du hast halt den Tunnel und dann deine SSH-Verbindung darüber.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also du hast halt ein eigenes privates Netzwerk, dann...
Kai Ole Hartwig: Das macht das auch irgendwie sehr bequem und fühlt sich sehr sicher an an der Stelle.
Daniel Langemann: Die wissen, dass das da schwerer ist.
Kai Ole Hartwig: Wie gesagt, die Loks sind erstaunlich leer.
Kai Ole Hartwig: Das ist das wirklich Schöne, weil beim Voyager versucht sich halt nicht jeder anzumelden, komischerweise.
Daniel Langemann: Also das ist ja, hundertprozentige Sicherheit gibt es nicht, aber man redet auch von einbruchhemmenden Türen und
Daniel Langemann: Je mehr Technologien du sozusagen vorschaltest und es anstrengender wird, ist es einfach irgendwann uninteressant.
Daniel Langemann: Es gibt genug andere Leute daneben, die halt immer noch einen Port offen haben.
Daniel Langemann: Der Root-Benutzer zum Beispiel auch noch sich anmelden darf.
Daniel Langemann: Das ist auch so ein Ding, was man eigentlich direkt am Anfang ausschalten sollte.
Daniel Langemann: Root sollte sich einfach gar nicht per SSH verbinden dürfen, sondern
Kai Ole Hartwig: Ja, definitiv.
Daniel Langemann: 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.
Daniel Langemann: Und das ist dann einfach mehrstufig, was man da aufbaut.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Also es ist, je länger es dauert, um an etwas ranzukommen, je unwahrscheinlicher ist nachher der
Kai Ole Hartwig: 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?
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Dann war es aber gar nicht der richtige User oder es war nicht das richtige Zertifikat.
Kai Ole Hartwig: 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.
Daniel Langemann: Aber wo du das sagst, also ja, ein Tipp wäre, irgendwie mehrstufig zu arbeiten.
Daniel Langemann: 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.
Daniel Langemann: Dann habe ich einen Kaffee geholt, einmal tief durchgeatmet, mich geschämt und dann habe ich es richtig gemacht.
Daniel Langemann: Aber ja, das ist ein guter Tipp.
Daniel Langemann: Also da
Kai Ole Hartwig: Ja, definitiv.
Kai Ole Hartwig: 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.
Daniel Langemann: Alleine schon nach dem Urlaub?
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich meine, gut, heute...
Kai Ole Hartwig: 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,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, und dann hast du einen Kollegen als Spaßvogel, der das auch noch durchschaut und dann Montagmorgen irgendwie Quatsch macht.
Daniel Langemann: Kannst du nicht Feierabend machen.
Kai Ole Hartwig: Ja, perfekt.
Kai Ole Hartwig: Und alle stehen dann da und sagen, es funktioniert wieder nichts.
Kai Ole Hartwig: Und dann werden Mundhau-Server neu gestartet und es funktioniert immer noch nicht.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Wie gesagt, ich bin halt jetzt vor, ich glaube, etwas über ein Jahr halt weggegangen von Fail2Ban hin zu, okay, wir
Kai Ole Hartwig: wir sorgen eigentlich dafür, dass der SSH-Port nicht mehr erreichbar ist.
Daniel Langemann: Hmm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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
Kai Ole Hartwig: über ein spezielles Netz kommen, über eine spezielle Verbindung kommen, damit alles, was schädlich ist, über dieses Netz kommen muss.
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: SSH-Verbindungen zum Beispiel oder SQL-Befehle und all so Sachen.
Kai Ole Hartwig: Es gibt ja unfassbar viele Dinge, die Entwickler jeden Tag tun, die
Kai Ole Hartwig: berechtigterweise für einen normalen Nutzer als echt gefährlich eingestuft werden.
Kai Ole Hartwig: Und ähm ja
Daniel Langemann: Genau das.
Daniel Langemann: Wir werden dafür bezahlt, das System zu verändern und wir versuchen zu verhindern, dass andere das machen.
Kai Ole Hartwig: So, und das ist halt nachher das Gefährliche.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Aber vielleicht ist das auch richtig, weil dieser Server ausgefallen ist.
Kai Ole Hartwig: Ja, also selbstzeitliche Beschränkungen in Regeln greifen halt nicht gut und nicht sinnvoll.
Daniel Langemann: Lass einen Kollegen aus einer anderen Zeitzone arbeiten.
Daniel Langemann: Dann ist für ihn nicht 4 Uhr nachts.
Daniel Langemann: dann hast du ja auch wieder das Problem, dass Leute zu unterschiedlichen Zeiten arbeiten.
Daniel Langemann: Oder dass auch gerade zum Beispiel aus dem Ausland, also IP-Sperren im Sinne von, dass man sagt, aus dem Ausland darf keiner zugreifen.
Daniel Langemann: Du bist aber ganz schnell offiziell im Ausland, wenn du zum Beispiel in der Nähe der Grenze wohnst.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, das Spannende ist, ich habe deinen Wohnort nie als nah zu Holland empfunden.
Kai Ole Hartwig: Aber das ist vielleicht ein anderes Thema.
Daniel Langemann: Nah genug, es ist nah genug.
Kai Ole Hartwig: Ja, das stimmt.
Kai Ole Hartwig: Ja, definitiv.
Kai Ole Hartwig: So etwas wie IP-Sperren ist halt auch nie so richtig sicher.
Kai Ole Hartwig: Das muss man auch einfach bedenken.
Kai Ole Hartwig: Da ist halt häufig...
Kai Ole Hartwig: Also Landesebene klappt ja immer noch ganz gut.
Kai Ole Hartwig: Aber alles darunter kannst du halt eigentlich vergessen, kannst du nicht einsetzen oder so.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Passiert schnell.
Kai Ole Hartwig: Es gibt aber ja noch
Daniel Langemann: 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.
Kai Ole Hartwig: Ja gut, also was wir tatsächlich machen, ist so etwas, wir sagen, okay,
Daniel Langemann: Also du schließt dich dann genau zu den Situationen aus, wo du es nicht brauchen kannst meistens.
Daniel Langemann: Das ist dann auch noch...
Kai Ole Hartwig: 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,
Daniel Langemann: Ja.
Kai Ole Hartwig: und erlaube nur das, was tatsächlich gebraucht wird.
Kai Ole Hartwig: Wobei wir da ja schon wieder bei einem nächsten passenden Thema sind, nämlich einer schön konfigurierten Firewall.
Kai Ole Hartwig: Ja, weil bei der Firewall sollte es nämlich genau andersherum sein.
Kai Ole Hartwig: Da sollte nur das erlaubt sein, was man tatsächlich braucht und per Default alles verboten sein, was nicht erlaubt ist.
Daniel Langemann: Genau das.
Daniel Langemann: Grundeinstellung ist ja meistens Port 22, damit man überhaupt irgendwas machen kann.
Daniel Langemann: Und da kommt dann eigentlich nur noch oft HTTP, HTTPS dazu.
Daniel Langemann: Und für 90% der Fälle hat das gereicht bis jetzt.
Kai Ole Hartwig: Ich habe da noch mehr Ports zum Angebot, die ich gerne offen habe.
Daniel Langemann: Und zwar...
Kai Ole Hartwig: Ich finde so etwas wie die SMTP-Verbindung ist ganz nett, dass man mir das System auch e-mails schicken kann.
Daniel Langemann: Ja.
Daniel Langemann: Also ausgehender SMTP, ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: Ich glaube, beim Stateless musst du auch eingehend Verbindungen dann erlauben.
Kai Ole Hartwig: Da muss man nämlich aufpassen mit der Firewall.
Kai Ole Hartwig: Es gibt Stateless und Stateless.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das ist ein bisschen unpraktisch.
Kai Ole Hartwig: Da hat man sehr viel offen gefühlt von einem dynamischen Port-Range.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: So, was habe ich noch gerne auf?
Kai Ole Hartwig: Ein eingehend WireGuard.
Kai Ole Hartwig: Dafür mache ich den Pod 22 aber dichter.
Kai Ole Hartwig: Das ist mein Angebot quasi, ja?
Kai Ole Hartwig: Den WireGuard auf, den SSH zu.
Kai Ole Hartwig: So, das ist eigentlich das.
Kai Ole Hartwig: Lass mal überlegen, was könnte ich noch aufhaben.
Kai Ole Hartwig: Je nach Setup hast du natürlich noch andere fancy Sachen.
Kai Ole Hartwig: Also ich sage jetzt mal, wenn du Sprachverbindungen erlaubst, dann musst du natürlich auch entsprechende Ports aufmachen.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, also dann kommen natürlich, wie du sagst, externe Dienste hinzu.
Daniel Langemann: Manchmal hast du dann, gerade im E-Commerce, hast du Commerce-Tools oder andere Dienstleister, die du anpingen willst, ERP-Systeme, CRM.
Daniel Langemann: Aber das ist nicht so kritisch, weil oft sind die entweder...
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, wobei das ja fast schon netzwerkseitig
Kai Ole Hartwig: reglementiert wird.
Kai Ole Hartwig: Also es ist dann ja nur ein, okay, die Ports sind auch ausgehend in Ordnung.
Daniel Langemann: Aus Faulheit.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ausgehende Ports sind ja meistens auch gar nicht so stark reglementiert.
Kai Ole Hartwig: Die meisten arbeiten mit sehr offenen Einstellungen, weil du natürlich sehr viel einstellen musst.
Kai Ole Hartwig: 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
Kai Ole Hartwig: was haben wir denn noch?
Kai Ole Hartwig: DNS, 53 aufmachen, dann noch Zeiten und so weiter und so fort.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Also ausgehend konfiguriert man meistens ja sehr viel länger an Fireball-Regeln als an eingehenden.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Ich glaube, das machen die wenigsten tatsächlich so.
Kai Ole Hartwig: So ganz konsequent.
Kai Ole Hartwig: Gerade weil es halt auch immer ist, jetzt funktioniert das auf einmal nicht und dieses funktioniert nicht.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, also es muss auch die Kirche im Dorf lassen.
Daniel Langemann: 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.
Daniel Langemann: 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.
Daniel Langemann: Also das wäre das Schlechteste von allem.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, genau, das reicht ja meistens.
Daniel Langemann: Das reicht ja auch schon oft.
Kai Ole Hartwig: Gerade an der Stelle muss man ja sagen, dass die meisten Sachen auch über Standard-Ports laufen.
Kai Ole Hartwig: 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.
Daniel Langemann: Hm.
Kai Ole Hartwig: Deswegen sage ich ja, dass das eigentlich schon auf Netzwerkebene muss man da Firewall-mäßig regeln.
Kai Ole Hartwig: Das ist auch, wo ich eigentlich gerne eine Firewall sehe.
Kai Ole Hartwig: Muss ich ganz ehrlich sagen.
Kai Ole Hartwig: Ich sehe gerne, dass die grundsätzlich eine Firewall auch im Netzwerk unterwegs ist und da schon entsprechend vorfüllt hat.
Kai Ole Hartwig: Vielleicht ein bisschen gröber.
Kai Ole Hartwig: 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,
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Wir hatten, glaube ich, beim vorletzten Mal irgendwie das Beispiel mit dem Eimental der Käse.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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
Kai Ole Hartwig: 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.
Daniel Langemann: Und da gibt es Applikationsseite ja auch mittlerweile echt viel.
Daniel Langemann: 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.
Daniel Langemann: Also das ist dann nochmal eine Schicht, auch auf Applikationsseite ja auch nochmal.
Daniel Langemann: Na, das ist ja auch.
Kai Ole Hartwig: 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.
Daniel Langemann: Mhm.
Daniel Langemann: Ja, bestimmt sogar.
Daniel Langemann: 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.
Daniel Langemann: Also mit ECS und Fargate und das Fazit wäre von dem, so wenig wie möglich installieren, was man braucht.
Kai Ole Hartwig: Ja.
Daniel Langemann: 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,
Daniel Langemann: Da definierst du ja auch Regeln, welche Netze wohin kommunizieren dürfen.
Daniel Langemann: Und das macht man da ja auch über solche Regeln.
Daniel Langemann: 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.
Daniel Langemann: Und ansonsten gibt es da gar nicht mehr viel, was da eigentlich noch nach außen darf.
Kai Ole Hartwig: 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,
Daniel Langemann: Ja, genau.
Daniel Langemann: Bastion Server.
Kai Ole Hartwig: Wobei ich auch nicht unbedingt der größte Fan davon bin, zu sagen, okay, ich terminiere mein TLS vollständig am Load Balancer.
Kai Ole Hartwig: Aus dem Hintergrund, weil wenn ich dann halt doch in die Systeme reinkomme,
Kai Ole Hartwig: 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.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Bin ich in der Ecke sympathischer,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also vielleicht fällt das in die Kategorie Ja, nice to have.
Daniel Langemann: Genau das war das.
Kai Ole Hartwig: Es fühlt sich aber auch besser an und ich bin ein großer Fan von standardisierten Setups insgesamt und
Kai Ole Hartwig: Wenn man das halt einmal alles gebaut hat, dann kann man das halt für jedes Setup auch ausrollen.
Kai Ole Hartwig: Das ist mein Gedanke dahinter, gerade weil, ich sag jetzt mal, die Rechenleistung, die dafür benötigt wird, ist heute auch verschwindend gering.
Kai Ole Hartwig: Das ist jetzt nicht mehr so das Argument zu sagen, wir machen kein HTTPS, weil dann brauchen wir so viel mehr an Serverkapazitäten.
Kai Ole Hartwig: 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
Kai Ole Hartwig: draufkomme, dann ist, glaube ich, das Absichern, so wie wir das jetzt besprochen hatten, eigentlich ein guter Standard und ein guter Weg.
Kai Ole Hartwig: Und bei unseren geliebten Hyperscalern
Kai Ole Hartwig: Ich weiß zum Beispiel auch gar nicht, wie das bei europäischen Cloud-Anbietern ist, muss ich gestehen, weil ich diese selten benutze.
Kai Ole Hartwig: Und weil wir keine Kunden haben, die das nutzen.
Kai Ole Hartwig: Das ist ein bisschen schade.
Kai Ole Hartwig: Da ist halt entweder, ich habe den europäischen Server oder den US-Hyperscaler.
Kai Ole Hartwig: Dazwischen gibt es nicht.
Kai Ole Hartwig: Bisschen schade.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja.
Daniel Langemann: Dadurch, dass ich nur Sachen nutze, die ich brauche, habe ich zum Beispiel auch keinen SSH-Zugang auf einen Container.
Daniel Langemann: Zu 99 Prozent brauche ich das gar nicht mehr.
Daniel Langemann: Also ist auch da ein Einfallstor einfach weg.
Daniel Langemann: 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.
Daniel Langemann: Also ist der auch nur kurzzeitig da.
Kai Ole Hartwig: Jetzt muss man auch aber auch fairerweise sagen, Terraform läuft ja nicht nur beim Hyperscaler.
Kai Ole Hartwig: Das kannst du ja mit fast jedem Anbieter machen.
Daniel Langemann: Ja, genau.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also da scheitert das dann wirklich nicht dran.
Kai Ole Hartwig: Ich
Kai Ole Hartwig: muss ehrlicherweise mal sowas ausprobieren wie Deck-IT und so.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und Containersicherheit ist ja nochmal ein ganz anderes Ding.
Kai Ole Hartwig: Also ich finde, Container leben ja vor allem davon, dass sie halt
Kai Ole Hartwig: minimalst aufgebaut sind.
Kai Ole Hartwig: Und Container kann man auch wirklich gut dadurch härten, dass du dann zum Beispiel auch keinen Paketmanager mehr im fertigen Container drin hast.
Daniel Langemann: Ja, kann nichts mehr nachinstalliert werden.
Kai Ole Hartwig: Ja, dann meinetwegen sei halt auf dem Ding drauf, dann kannst du dir halt mit LLS noch die Container-Inhalte anschauen.
Kai Ole Hartwig: Wenn es ein Read-Only-Filesystem ist, dann find mal lustig erstmal die paar Stellen, wo überhaupt geschrieben werden darf.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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
Kai Ole Hartwig: mehr Arbeit bis zu einem gewissen Punkt, die du gerade in kleinen Teams halt nicht so hast.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: So, da muss man ja auch ehrlich sagen.
Daniel Langemann: Kann ich nur empfehlen.
Daniel Langemann: Also wenn er es nicht kann, es macht nicht nur, dass es Spaß macht, es macht einem das Leben leichter.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: bisschen die Erkenntnis oder wenn die Erkenntnis dann da ist, dann sagt man, ja, uns fehlt die Zeit, solche Dinge zu machen.
Kai Ole Hartwig: Und das ist, finde ich, so ein bisschen so eine Fehlannahme.
Kai Ole Hartwig: 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,
Daniel Langemann: Ja, versuch mal die Unterschiede zu finden.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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
Kai Ole Hartwig: Eigentlich sollte die Applikation aber auch auf der neuen PHP-Version laufen und das traut sich dann keiner.
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Daniel Langemann: Es gibt in dem Repo einen Ordner, da liegen alle Public Keys drin.
Daniel Langemann: 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.
Daniel Langemann: Und dann kann er dem Bescheid sagen, hier, roll den mal bitte aus.
Daniel Langemann: 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.
Kai Ole Hartwig: Mhm.
Daniel Langemann: je nachdem, wie da das Vertrauensverhältnis ist und wie man das aufsetzt.
Daniel Langemann: Und das ist dann ein nettes Gimmick, wo dann auf einmal auf fünf Rechnern eine neue Key da ist.
Daniel Langemann: Oder wenn der Mitarbeiter ausscheidet,
Daniel Langemann: 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.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, definitiv.
Kai Ole Hartwig: Zum Beispiel, das ist bei uns auch automatisiert.
Kai Ole Hartwig: Das hängt bei uns tatsächlich an den Projektzugriffsrechten im GitLab.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Kai Ole Hartwig: alle Keys, mit denen du dich ins GitLab einloggen kannst, oder wer ist es?
Kai Ole Hartwig: Es können nämlich mehrere sein, werden dann nämlich tatsächlich deployed bei uns.
Kai Ole Hartwig: 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,
Daniel Langemann: Es wiegt das einfach auf.
Daniel Langemann: Also...
Kai Ole Hartwig: falsch angemeldet, sind auch direkt die Zugänge zum Server weg.
Kai Ole Hartwig: Natürlich birgt auch hier Automatisierung ein gewisses Risiko.
Kai Ole Hartwig: Aber der Nutzen überwiegt einfach.
Kai Ole Hartwig: 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.
Daniel Langemann: Oder die Firewall-Regeln falsch eingestellt sind.
Kai Ole Hartwig: Quasi einen gesicherten User mit einem speziellen SSH-Key.
Daniel Langemann: Oh ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ja gut, Firewall-Regeln, jetzt, naja.
Daniel Langemann: Ja, also habe ich auch schon automatisiert, deployed und durfte danach neu anfangen.
Kai Ole Hartwig: Ja, ja.
Daniel Langemann: Aber ja, das automatisierte Deployment ist super interessant.
Kai Ole Hartwig: 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.
Daniel Langemann: Also ich habe keine Zahlen, aber man spart einfach Zeit.
Daniel Langemann: Zeit, die man für wichtigere Sachen gebrauchen kann oder nutzen kann.
Daniel Langemann: 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.
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und
Kai Ole Hartwig: verschiebt halt die Daten auch viel schneller.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Allein wegen den Übertragungsgeschwindigkeiten.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Aber das ist vielleicht auch nochmal ein Thema für eine andere Folge.
Daniel Langemann: Das oder wie ich es geschafft habe, Montagabend um 8 Uhr nicht das System abzuschießen.
Kai Ole Hartwig: Automatisiertes Deployment, ja.
Kai Ole Hartwig: Warum ich zwischendrin Kaffee trinken gehe und dann überrascht bin, dass es deployed ist.
Daniel Langemann: Genau.
Kai Ole Hartwig: Ja, nur weil der Test gefällt ist und die Pipeline blockiert war.
Kai Ole Hartwig: Warum kann ich denn nicht auf Protsch?
Kai Ole Hartwig: Weil da leuchtet was rot.
Kai Ole Hartwig: Was soll das denn?
Kai Ole Hartwig: Ja, ich... Noch besser ist natürlich Freitagsnachmittags.
Daniel Langemann: Genau.
Kai Ole Hartwig: Eigentlich schon im Feierabend und nur kurz ausrollen.
Daniel Langemann: Ja, aber auch die wiederholen, also gleiche Beispiel, sich wiederholende Schritte, die einfach viel Zeit in Anspruch nehmen, wo der Entwickler sinnvoller eingesetzt ist.
Daniel Langemann: Also je nachdem, was du machst, musst du Tests hintereinander ausführen und, und, und.
Daniel Langemann: Und das dauert einfach seine Zeit.
Daniel Langemann: 10, 15, 20, 30 Minuten, je nach Projekt.
Daniel Langemann: Ich habe Projekte gehabt, da hat das eine Stunde gedauert, bis wirklich alles fertig war.
Daniel Langemann: Mit Container bauen, mit Tests.
Daniel Langemann: Also,
Kai Ole Hartwig: Das ist automatisierte oder das manuelle?
Daniel Langemann: Das automatisierte.
Daniel Langemann: Da waren End-to-End-Tests und, und, und.
Daniel Langemann: Also es ist viel mehr passiert, war ein großes Team.
Daniel Langemann: Aber da wärst du verrückt geworden, wenn du das jedes Mal von Hand machen müsstest.
Kai Ole Hartwig: Ja, also ich hatte auch Projekte, wo ich vier Stunden von Hand deployed habe.
Kai Ole Hartwig: So ein totaler Wahnsinn.
Kai Ole Hartwig: Das ist das beste Beispiel dafür, dass man Dinge automatisiert, weil danach ist das in 15 Minuten gelaufen.
Daniel Langemann: Hm, okay.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Daniel Langemann: Das war eine gute Tat für heute.
Daniel Langemann: Feierabend.
Kai Ole Hartwig: Anyway, jetzt hast du mir ja ausgeredet, dass ich mich mit Root unter IP-Adresse oder Root1234 auf meinem Server anmelde.
Kai Ole Hartwig: Tja, was mache ich denn jetzt, Daniel?
Kai Ole Hartwig: Ja, deine gute Tat für heute.
Kai Ole Hartwig: Und sagst, Ansible ist total super und muss überall laufen.
Kai Ole Hartwig: Das lassen wir jetzt mal so stehen, glaube ich.
Daniel Langemann: ich liebe so endgültige Aussagen, die sind so falsch und so fehl am Platz.
Daniel Langemann: Aber ja, es kann vieles besser machen oder es macht vieles besser.
Daniel Langemann: Kein Root-Zugriff, SSH vernünftig absichern, vernünftigen Key nutzen.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, also fassen wir mal zusammen, automatisierte Regeln zur Konfiguration machen das Leben besser, um das ein bisschen toolneutral zu halten.
Daniel Langemann: Und dann hat man schon was.
Daniel Langemann: Ach, das hört sich voll klug an.
Daniel Langemann: Ja, definitiv.
Daniel Langemann: Ja.
Daniel Langemann: Genau.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: zur nächsten Folge Secrets Not Included.
