[Musik]
Hallo und herzlich willkommen zur vorletzten Tür des Focus und Linux Adventskalenders.
Ja, und so langsam neigen sich die Themen so sicher dem Ende, aber das Wort sicher steckt auch in unserem Thema für diese Folge.
Es geht nämlich um Sicherheit, ja.
Denn wie ja einige von euch sicherlich wissen, ist Linux vor allen Dingen im Server- und IoT-Bereich sehr beliebt
und macht natürlich das Betriebssystem dann auch wieder dadurch interessanter für angreifender.
Und es gibt ja diesen lang existierenden Mythos, dass Linux unhackbar ist und das ist natürlich nicht ganz korrekt, ja.
Jedes Betriebssystem ist im Prinzip hackbar und wir wollen euch einfach heute mal ein paar Tipps an die Hand geben,
um eure Linux-Systeme abzusichern.
Das Ganze mache ich natürlich wieder nicht alleine, sondern habt den Felix mit dabei.
Moin.
Und unseren Security-Jan.
Moin, moin.
Ja, und vielleicht beginnen wir erstmal mit ein paar Keyfacts.
Und zwar ist es ja so, das wissen vielleicht nicht alle, dass circa 80% der Web-Server mit Linux laufen
und mehr als 50% der Workloads in der Microsoft Azure Cloud sind ja tatsächlich Linux-Workloads.
Ja, und auch IoT, haben wir ja eingehend schon gesagt, ist ja vor allen Dingen Linux-basiert.
Und das große Problem, das man dann immer so hat und ich denke mal, das kommt euch beiden sicherlich auch bekannt vor,
ist so, dass man immer so einen Trade-off finden muss.
Will ich etwas sehr komfortabel haben oder will ich etwas sehr sicher haben?
Ja, es ist vor allen Dingen immer eine Abwägung.
Sicherheit ist natürlich kein erreichbares Ziel, sondern es ist natürlich immer eine Abwägung.
Also es gibt nie den Zustand, zumindest jetzt, also man möge mich korrigieren, aber soweit ich das beurteilen kann
oder ich glaube soweit das auch Konsens ist, ist der Punkt, man kann immer nur abwägen Risiko und Schadenswahrscheinlichkeit,
also wie wahrscheinlich ist halt mein Schaden quasi, den ich haben kann, eben die Sachen, die passieren.
Und was hat das für Auswirkungen? Und auf dieser Basis muss man immer Abwägung treffen,
okay, welche Maßnahmen sind halt für mich die richtigen. Zu einem 1000%igen Schutz wird man einfach nicht kommen.
Und deswegen ist halt bei jeder neuen Maßnahme immer wieder dieser Punkt die stetige Abwägung.
Und diese gewisse Unsicherheit, die dieses ganze Thema mit sich bringt, ist natürlich auch, ja dann halt Feld für alle möglichen Diskussionen,
was braucht man, was braucht man nicht. Und da wollen wir jetzt einfach mal so ein paar Sachen vorstellen,
die zumindestens auch oft einen gewissen Grundschutz bieten können, mit dem man sich einfach eben ein bisschen sicherer fehlen kann,
mit dem man einfach bestimmte Schäden, die halt eine hohe Wahrscheinlichkeit haben, also weil es einfach sehr wahrscheinlich passieren kann, einfach mal abfangen kann.
Ja. Jan, du hast uns auch ein paar Grundlagen mitgebracht. Was sind denn so gängige best practices,
die auf jedem Linux-System durchaus sinnvoll sind, wenn man die Sicherheit erhöhen möchte?
Also was man sich, da gibt es so Slogans, die man sich in den Kopf wuffen kann.
Zum einen irgendwie so weniger ist mehr, also Pakete, die man nicht braucht, sollten entfernt werden.
Das ist jetzt einfach gesagt als getan, aber so ein APT-Get-Auto-Remove kann man schon mal wagen.
Ich mache da auch ganz gerne, dass ich die Workloads am besten irgendwie in Dockerfiles packe und dann auch mit Lpine Linux arbeite
und das so klein wie möglich versuche zu halten, was tatsächlich auf der Hauptmaschine läuft.
Dann Pakete aus unbekannten Quellen vermeiden. Auf Servern sollte man keine GUI installieren, also so schön, der Webman auch winkt.
Man muss dieser Versuchung wieder stehen und man sollte auch möglichst die automatischen Sicherheitsupdates aktivieren,
also so etwas wie APT-Unattended-Upgrades und Yamcron. Dann die Firewall und SE-Links nicht deaktivieren.
Das ist natürlich immer, wenn man mal eben schnell was zum Laufen kriegen will, dann ist so ein System-Control-Stop-Firewall
natürlich einfacher als jetzt nicht mit den Vorsitzern rumzukämpfen und auch halt so Sachen wie den Guizugange und die Passwort-Authentifizierung,
die aktivieren, dass man sich wirklich per Key anmelden muss und auch mit einem persönlichen Account.
Am besten dann auch noch irgendwie sudo so schalten, dass das wirklich nur die Personen bekommen, die es brauchen,
dass man da vielleicht auch so ein bisschen Audit einbaut und dann ist man glaube ich auch schon ganz gut dabei.
Ja, das klingt auf jeden Fall sinnvoll, wenn man das beherzigt, dann hat man schon mal einige Dinge gut konfiguriert
und ich finde es auch schön, wie wir uns selbst in diesem Adventskalender-Format widersprochen haben.
Also wir reden jetzt über Security und haben halt vor ein paar Folgen über irgendwelche lustigen ASCII-PAN-Commandos gesprochen,
die wir auf unserem System installiert haben. Also man darf sich auch mal selbst widersprechen,
aber es ist natürlich klar, in einem produktiven Umfeld auf einem Server, auf dem wirklich eine unternehmenskritische Anwendung läuft,
da sollte dann natürlich schon Wert drauf gelegt werden, das sicher zu konfigurieren.
Und da gibt es natürlich viele Möglichkeiten. Und ich beginne mal mit einem Tool, das ich persönlich sehr schätze,
und zwar ist das DevSec. Habt ihr davon schon mal was gehört?
Ich persönlich nicht, nee.
Ich kenne, also wir haben da glaube ich auch schon mal drüber gesprochen.
Ich bin gleich gespannt auf deine Erklärung quasi, es ist vielleicht auch mal eine unterschiedliche Interpretation dabei,
aber wenn es das ist, was ich denke oder noch so ist, wie ich es in Erinnerung habe,
das ist ja auch ein Projekt, das sich immer weiter entwickelt, das auf verschiedene Wege dann nimmt,
dann ist auf jeden Fall eine sinnvolle Ergänzung des Decks und vor allem auch eine einfache Variante,
wie man sein System so ein gewisses Grundhardening verpassen kann.
Ja, absolut. Genau das ist es nämlich. Also eine regelmäßige Auditierung von Systemen ist unabdingbar,
gerade wenn ihr produktiv irgendwo was betreibt, in einem Rechenzentrum, irgendwelche Applikationsserver,
denn machen wir uns nichts vor, ständige Updates bringen natürlich auch neue Komponenten und dadurch transitiv neue Fehler.
Deswegen gibt es ja Kunden, die irgendwie sagen, ich installiere nur Bugfixes und Securityfixes und neue Features,
interessieren mich gar nicht.
Das andere Problem ist natürlich, dass man heutzutage in der beschränkten Arbeitszeit, die man hat,
sehr viele Systeme zu verantworten hat. Das heißt, dieses Hardening, das muss im Prinzip weitestgehend automatisiert werden,
sonst ist es einfach nicht praktikabel und effizient. Wenn ich jetzt pro Server, den ich ausrolle auf meiner Serverfarm,
20 Minuten wäre noch vertretbar, aber wenn ich jetzt für jeden Server zwei Stunden brauche
und ich muss an dem Tag vier, fünf Server deployen, dann überlege ich mir das, ob ich die abhärte.
Also das sollte möglichst automatisch funktionieren. Und das ist ja auch ein Trugschluss, dass man sagt,
in einem System, das ich jetzt bereitstelle heute und absichere und härte, das ist es auch in einem Jahr noch,
denn das ist definitiv nicht der Fall. Es gibt immer wieder neue Lücken, die eben auch dann entdeckt werden.
Wir haben ja auch schon in der einen oder anderen Newsfolge, hat Jan ja immer mal wieder auf neue CVEs hingewiesen.
Wir alle wissen, es gibt verschiedene Exploit-Datenbanken, die wir euch auch mal in den Show Notes verlinkt haben,
so Dinge wie WulDB oder CX Security oder Rapid7. Das heißt, im Prinzip, wenn ich weiß, auf einem Server
läuft eine Applikation in einer spezifischen Version, kann ich einfach durch diese Datenbanken gehen
und finde dann Exploits, die ich eins zu eins im schlimmsten Fall einfach anwenden kann.
Und das ist einfach eine sehr frustrierende Situation, in der man sich als Administratorin befindet heutzutage.
Und da kann halt eben auch DevSec helfen, denn das dient dazu, dass es eben das Auditieren und Absichern von Servern automatisiert.
Es gibt da sogenannte Baselines. Das ist ja so eine Folge von Abfragen, die eintreten muss.
Also das sind so Security-Abfragen, ob spezifische Passwörter eingerichtet sind, ob die Schlüssel,
die der SSH Server verwendet, nach spezifischer Größe hat und so weiter.
Das gibt es eben für Betriebssysteme, also für Windows und Linux beispielsweise.
Aber es gibt auch für einzelne Betriebssystemkomponenten auch wieder Baselines, zum Beispiel für SSL oder für SSH
oder für einen Apache-Server. Diese Baselines, die kann ich eben ausführen und die sagen wir dann eben
auf einer Skala von 0 bis 100, wie verwundbar mein System ist, bzw. wie sicher mein System ist.
Und dann weiß ich schon mal, dass es eben Findings gibt und was da drin stehen müsste.
Das heißt, die Ausgabe von so einem Baseline-Check ist dann beispielsweise,
deine Passwörter laufen in 99.999 Tagen ab, aber sie sollten nach maximal 60 Tagen ablaufen, lieber User.
Dann habe ich schon mal den Hinweis, das was nicht nach Best Practice konfiguriert ist und müsste es dann aber manuell ändern.
Das wäre natürlich auch wieder ein Aufwand, aber DevSec geht hier noch einen Schritt weiter, denn für diese Baselines,
die wir gerade angesprochen haben, gibt es dann eben auch Automatismen für Puppet, Chef und Ansible.
Das heißt, um mal beim Beispiel Ansible zu bleiben, es gibt dann eine Ansible-Roller, die genau diese Findings wieder schließen kann.
Und das ist wirklich eine feine Sache und das nutze ich halt eben auch, immer wenn ich einen Server privat für mich hochziehe
oder auch wenn ich bei Kundinnen unterwegs bin und der Kunde, die Kundin sagt, wir hätten gerne eine Grundsecurity
für unsere neuen Systeme, die wir ausrollen, dann kommt da bei mir immer DevSec zum Einsatz.
Und dann kann ich zumindest gewährleisten, dass ich eine gewisse Grundsecurity schon mal eingebaut habe.
Denn machen wir uns nichts vor, auch so ein neu hochgezogener Ubuntu 22.04 Server,
da gibt es einige Dinge, die nicht so konfiguriert sind, wie sie konfiguriert sein sollten.
Eine Frage, die sich jetzt euch vielleicht stellt, ist aber, wo kommen denn die ganzen Informationen für diese DevSec Baselines
oder für diese Kataloge her? Da gibt es verschiedene Informationen, die da reinfließen.
Also das Ganze ist auch wieder open source, GitHub-Link ist in den Show Notes, könnt ihr euch angucken,
könnt selbst auch nochmal eigene Ideen ergänzen. Es gibt diese Sysbenchmarks, also diese Center for Internet Security-Arbeiten,
die da mit reinfließen. Es gibt von der NSA die Hardening Guides für verschiedene Applikationen und Betriebssysteme.
Und die einzelnen Hersteller, die schreiben ja auch best practices und security hardening guides.
Also für Kubernetes zum Beispiel gibt es auch so ein Guide, wo drin steht, wie man das System am besten absichert.
Und das in Kombination mit diesem Scannen, also das Scannen wird über eine Software gemacht, die InSpec heißt,
die gehört jetzt zu Chef. Und dann eben auch nicht nur zu zeigen, was unsicher ist, sondern den Anwender*innen gleich noch
die Option zu geben, einfach einen Ansible nachgelagert auszuführen, um alles zuzumachen, ist schon echt, wie ich finde,
eine sehr feine Sache, war ein absoluter Gamechanger für mich. Wäre das auch was für euch, DevSec?
Also jetzt, was du so vorgestellt hast, das klingt ja eigentlich, also ich sehe mich da auf jeden Fall auch irgendwie,
dass ich mich immer so ein bisschen den inneren Schweinehund durchgehen lasse und dann manche Linux-Systeme nicht so abhärte,
wie sie abgerettet werden sollten. Da sehe ich mich.
Auf jeden Fall, ich habe das auch schon länger in meinem Werkzeugkasten einfach für, ja eben als Baseline,
ich kannte eben vor allen Dingen halt die Linux-Baseline-Playbooks und ja, das ist halt einfach ein einfacher Weg.
Man muss halt auch immer sagen, klassisch, also eine der Security-Sachen ist ja auch immer, erfinde das Rad nicht neu.
Also im Zweifelsfall, wie die oberste Regel implementiere, nicht einen eigenen Krypto-Algorithmus,
können halt die, die jetzt eine mittelbare zweitrige könnte halt sein, okay, du kannst natürlich schon deine eigenen Hardening-Playbooks implementieren,
aber warum? Also, na klar, also immer noch ergänzen, klar, auf jeden Fall anpassen auf die eigene Umgebung,
aber eine der Mächtigkeiten von Open Source ist ja eben auch die Auditierbarkeit durch andere,
das stetig gucken, wo halt eine ganze Community ein Auge drauf hat, okay, das ist halt eine Schwachstelle,
die könnte man vielleicht noch schließen, da hat man noch nicht dran gedacht, also im Zweifelsfall sind ja die 1000 Supporter bei GitHub immer, ja, mächtiger als einer
und das ist schon, glaube ich, ein großer Mehrwert, also definitiv aufschreiben, merken, anwenden.
Ja, und da aber auch unbedingt in die Doku reingucken, also nicht einfach immer Latest und Greatest Versionen von dieser Ansible-Collection benutzen,
da gibt es auch regelmäßige Updates und in der Doku steht wirklich drin, was die Fallstricke sind, also bitte auch nicht sofort auf der Produktion ausrollen,
sondern vielleicht mal auf dem Testsystem, so der Klassiker, es gibt irgendwie in dem Security-Playbook werden auch einige Kernparameter zurückgedreht,
unter anderem das IPv4-Forwarding, ja, und guess what, wenn du halt Docker Compose am Laufen hast und da irgendwelche Container hast,
die miteinander kommunizieren, das dürfen die dann halt nicht mehr, das ist dann halt blöd, wenn das deine Applikation ist, die du damit brichst.
Und für Desktop würde ich das auch nicht unbedingt benutzen, dann darf man keine USB-Sticks mehr einhängen und so weiter,
aber für alles andere kann ich das vorbehaltslos empfehlen.
Das nächste Tool in unserer Liste ist Aid, wer von euch hat das denn mitgebracht?
Dazu kann ich vielleicht ein paar Worte verlieren, also wir haben ein bisschen geguckt, was es so für Tools gibt, die man generell auch vorstellen kann
und so ein bisschen Sachen rausgegriffen nützern kann, der Zoo ist natürlich riesig und da kann man alles Mögliche machen.
Eine der Sachen, die es halt schon relativ lange gibt, ist eben Aid als Advanced Intrusion Detection Environment
und man kann sich so ein bisschen überlegen, ok, was kann ich denn machen noch über die Bordmittel von Linux hinaus
und selbst da kann man ja noch einiges machen, also viele nutzen ja auch zum Beispiel Features wie Access Control Lists oder solche Sachen schon mal,
also das wären schon mal so erste Sachen oder halt die AC Linux Regeln richtig, also im Prinzip kann die meisten von uns auch mit an die eigene Nase gefasst,
auch erstmal relativ grundlegende Sachen machen, bevor man eben zu härteren Bandagen greift.
Aber für Systeme, die eben besonders kritisch sind oder wo man ein besonderes Auge drauf haben muss, aus welchen Gründen auch immer,
kann es sich lohnen eben so ein System wie Aid zu installieren und was tut es nämlich?
Es kann das ganze System so ein bisschen überwachen und vor allen Dingen halt die Integrität von Dateien und Verzeichnissen überprüfen.
Heißt auf Deutsch quasi, ich kann benachrichtigt werden oder halt besonders tracken, wenn an Dateien gefummelt wird.
Das heißt, ich kann unabhängig davon, ob ein bisschen ein User zum Beispiel schafft, warum auch immer, Klassiker ist ja immer das große Ziel, ist immer Who am I? Route.
Das heißt, irgendwie die Kontrolle um ein System zu erlangen, vielleicht irgendwie über einen Trick, über einen Skript, über was weiß ich falsch gesetzt,
Execution Flags oder sowas, irgendwie an meinen Dateien zu fummeln, wenn er aber vielleicht nicht, das ist jetzt wieder ein bisschen Obscurity,
aber wenn er es dann schafft, quasi durch den Trick, irgendwie eine Datei zu verändern, die er eigentlich nicht verändern sollte.
Oder andersrum vielleicht noch die Stufe davor, man muss ja noch nicht mal von der Execution ausgehen, sondern im Prinzip nur ein ganz normaler User, der das auch nicht darf,
versucht erstmal überhaupt an PassWD zum Beispiel auszulesen. Einfach nur mal ein Cut wird nicht funktionieren, kommt nichts raus, aber es klingelt schon mal.
Und dann kommt schon mal der vorsichtige Anruf vom Admin, hey, auf System Nummer 3, Cut auf PassWD, was machst du denn da?
Also dieser, so dieses extra bisschen, hier hat einer ein Auge drauf und guck mal, was da passiert, das kann im Zweifelsfall schon mal eine erste Hürde sein.
Absolut, ja, also ich finde, das ist halt auch so ein Tool, das relativ unbekannt ist, also klar jemand, der sich intensiv damit beschäftigt, der oder die kennt das schon,
aber es ist jetzt nichts, wo man sofort dran denkt, wenn man Security hört, die meisten Leute denken halt an Firewall, an SE Linux, aber Ades ist halt auch ein super mächtiges Tool.
Von daher kann ich auch auf jeden Fall empfehlen, habe ich auch auf Servern, die ich im Internet betreibe, das ist dann schon schön, wenn man dann mitbekommt,
wenn dann Dinge geändert werden, ohne dass man die selbst geändert hat. Das nächste Tool in unserer Liste ist Fail2Ban und ich glaube, das kommt von dir Jan.
Genau, also das wird jetzt hoffentlich kein Großüberraschend, das ist ja eigentlich, wenn man früher so in den 2000er Jahren mal Linux schon gemacht hat
oder in den 2010er Jahren dann ist Fail2Ban immer dabei gewesen und man sagt ja immer, derjenige, der ohne Sünde ist, werfe den ersten Stein,
aber man kann das ändern zu derjenige, der sich noch nicht mit Fail2Ban selber aus dem Server ausgesperrt hat, werfe den ersten Stein.
Genau, da gibt es mehrere Trigger quasi, der beliebteste ist glaube ich SSH und wenn man sich dreimal falsch anmeldet bei SSH,
dann wird man gesperrt für einen beliebig definierbaren Zeitraum, ich glaube der Standard ist ein Tag, manchmal aber auch für immer.
Und genau so, so hat es mich dann ins NetCap VNC Panel verschlagen, um meinen Server irgendwie wieder zu kriegen.
Das Ganze bindet sich aber auch ein in verschiedene Firewalls, also Firewalls, CMD, IP Tables, NF Tables, UFE, BSDFW,
in Mailserver, in Web Server, in Web Anwendungen, sowas wie GitLab, Guacamole, Webmin, PHP, Matmin und verschiedene Datenbanken.
Und das Ganze wird dann gelockt und je nachdem, was dann eingerichtet ist, werden die Leute dann bestraft durch Sperre.
Was ich noch empfehlen kann vielleicht da ist, dass man sich die Log-Dateien nicht per E-Mail zuschicken lässt,
weil das sind, wenn man mal so in dieses SSH-Authlog guckt, das sind ganz schön viele Versuche pro Tag, da hat man dann glaube ich keine Ruhe mehr, wenn man das per E-Mail bekommt.
Ja, absolut. Also es ist per Definition ein Intrusion Detection System bzw. kombiniert auch ein Intrusion Prevention System.
Und das Schöne ist an dem Teil, das ist ja in Python geschrieben, das läuft also auf allen POSIX Systemen.
Und ich habe mich auch ungelogen bestimmt schon 1000 Mal selbst von meinem eigenen Server ausgesperrt, damals auch bei Netcap.
Das ist natürlich, man muss ein bisschen experimentieren, bis die Config perfekt ist, aber es ist mittlerweile auch besser geworden.
Also früher waren die vorgefertigten Konfigurationsdateien nicht so gut, mittlerweile sind die echt gut und man kann die eigentlich ohne sie groß anzupassen direkt weiterverwenden.
Und ich benutze das auch auf meinen öffentlichen Servern, dass wenn halt jemand hier zweimal sich mit dem falschen Passwort versucht zu authentifizieren,
dann wird er direkt für eine Woche oder so auf der Firewall gebannt, weil das ist sonst einfach zu aufwendig.
Und ich habe auch keinen Bock, dass da irgendwelche Scriptkitties, Brute Forcing auf irgendwelche User machen. Das ist auf jeden Fall sehr empfehlenswert.
Ja, und das letzte Tool in unserer Liste ist OpenVas und das ist das Open Vulnerability Assessment System.
Und das ist eine Komponente zum Scannen nach bekannten Verwundbarkeiten.
Das hat vielleicht der eine oder die andere schon mal vorher unter dem Namen Nessus gehört, ja, denn so hieß das Tool vorher.
Da gab es allerdings 2005 eine Lizenzänderung, denn das wurde von Tenable Networks gekauft und closed source gestellt.
Und jetzt ist eben OpenVas Teil von Greenbone Vulnerability Manager oder GVM.
Und das ist ein Software Framework für generell, ja, Verwundbarkeitsmanagement.
Das ist eine deutsche Firma, die Greenbone Networks GmbH, und das wird vor allen Dingen auch häufig im Zusammenhang mit Penetrationstests verwendet.
Das heißt, long story short, was macht das Ding? Das überprüft Komponenten auf bekannte Sicherheitslücken, zum Beispiel Web-Anwendungen oder eben Serverdienste.
Und das Teil kann dabei aber auch den Netztraffic analysieren, um verwendete Komponenten zu erraten.
Das heißt, man kann ja so ein bisschen Fingerprinting machen. Also wer schon mal mit N-Wrap gearbeitet hat, der kennt das bestimmt.
Da kann man dann über verschiedene Parameter versuchen zu erraten, was für eine Webserver-Version hier verwendet wird und was das verwendete Betriebssystem und natürlich transitive dadurch auch verbundene Sicherheitslücken sind.
Ja, wenn ich weiß, es ist ein CentOS in der Version sowieso, mit einem Apache-2-Version sowieso.
Wir haben es vorhin schon kurz gesagt, es gibt diese Vulnerability-Datenbanken, dann kann ich mir einen exploit suchen, je nachdem wie lange das nicht mehr gepatcht wurde.
Das Ganze kann man einmal so machen, dass man einen externen Scan aushört, ohne Zugriff auf das Betriebssystem des Hosts zu haben.
Das heißt, dann gehe ich halt einfach über die offenen Ports, die der Server so hat, Web-Server zum Beispiel, halt über 80.443 zum Beispiel, kann auch versuchen, über SSH ranzukommen und so weiter.
Man kann aber auch Zugangsdaten auf das System hinterlegen und dann könnte man die Scan-Ergebnisse nochmal konkretisieren und hat dann auch sehr detaillierte Empfehlungen, was man noch verbessern könnte.
Und das ist echt eine feine Sache. Ich bin jetzt natürlich kein Pentester und kenne vermutlich nur 2% der Features, die OpenVars so mitbringt.
Aber wenn man jetzt eben sagt, man möchte über die Grundsecurity hinaus nochmal ein bisschen tiefer gehen, dann ist OpenVars echt eine schöne Sache.
Es ist ein bisschen eklig, das bereitzustellen. Da gibt es irgendwie nur super veraltete Pakete für viele Distributionen.
Und die aktuellen Versionen, das zu installieren, ist auch nicht ganz so trivial. Aber es gibt auch Docker-Container, die vorbereitet sind.
Und das kann man dann einfach so auf seinem Arbeitsgerät mal hochziehen, um dann die eigene Umgebung beispielsweise zu scannen.
Also das bitte nicht mit irgendwelchen externen Diensten machen. In aller Regel haben die Anbieter von Applikationen IDS und IPS-Techniken im Einsatz.
Ich habe mal meinen eigenen Web-Server damit gescannt und wurde dann relativ schnell geblockt auf der Firewall, das Host das.
Also da bitte vorher gucken, dass man sich die Erlaubnis einholt oder das nur im eigenen Netz macht.
Auf jeden Fall an sich eine sinnvolle Erweiterung des Toolzets.
Auch eine Sache, die man eben, wenn man diese Installationshürden einmal gemeistert hat, auf jeden Fall relativ gut mit vorbereiteten Reports zumindest mal so eine Übersicht liefert.
Wenn man zum Beispiel mal seine eigenen Web-Server mal so ein bisschen überprüft und guckt, ob nämlich einfach relativ bekannte Schwachstellen schon draufliegen.
Das würde sich natürlich mit dem Tipp von vorher immer aktuellste Paketversion fahren schon mal ein bisschen erledigen.
Aber manche Sachen sind ja auch Einstellungs-Sachen. Zum Beispiel bin ich fest davon überzeugt, dass zum Beispiel bei SSH kann man ja einige Sachen wie das verwendete Verschlüsselungsprotokoll, so ein bisschen das Key-Material,
da kann man ja einiges auch von außen schon erkennen, was da im Handshake rumkommt. Und im Zweifelsfall, wenn man halt bei Web-Servern noch irgendwelche alten TLS-Versionen zulässt, die inzwischen auch schon als deprecated gelten, dann wird das da einen schönen roten Marker geben und sagen hier, mach mal was.
Auf jeden Fall. Guter Punkt, dass du auch von Reports sprichst, weil das bietet dieses Tool halt auch.
Also man hat dann so richtig management-ready Reports, so mit schönen Graphen und mit Diagrammen, die man da exportieren kann.
Das ist jetzt zum Beispiel was, was jetzt DevSec mit InSpec nicht so macht. Da gibt es wieder weitere Tools, die man da dran flanschen kann.
Aber ich glaube, wenn wir da jetzt noch drauf eingehen würden, dann dann sprengen wir vermutlich wieder mal einen Zeitrekord in diesem Adventskalender.
Wir haben ja eigentlich versucht, hier immer kurze Folgen aufzunehmen, aber ich glaube, das ist uns auch in diesem Fall nicht ganz gelungen. Aber es waren ja auch wichtige Themen.
Von daher, liebe Zöger, lasst uns gerne wissen, was ihr persönlich immer unternehmt, um die Sicherheit eurer Linux-Systeme zu verbessern.
Da sind wir immer interessiert dran, das eine oder andere Tool vielleicht auch noch kennenzulernen, das wir noch nicht ganz auf dem Radar hatten.
Und wir freuen uns natürlich auch immer wieder über Feedback, beispielsweise per E-Mail an podcast@sva.de.
Und dann würde ich vorschlagen, wir hören uns morgen mit dem letzten Türchen des Adventskalenders wieder.
[Musik]