DebSec - Simples Security Check Script für Debian Server

  • Nabend meine lieben Serverhorder, Neulinge und Netcupler,


    das Vorhaben geht ja bereits seit ein paar Tagen durch das längste Thema - aufgrund der vielen Neulinge in letzter Zeit, die kaum oder keine Kenntnisse in Puncto Serveradministration mitbringen, kam es ja bereits zu heftigen Diskussionen, wie man den nun mit solchen Menschen und Situationen umgehen sollte.


    Wenngleich es der beste Weg wäre, dass diese Leute erstmal in einer geschützten Umgebung üben und dort alles ausprobieren sollten - viele wollen dies nunmal nicht. Es ist jedermanns gutes Recht, sich mal eben einen Server anzuschaffen. Das ist halt so, daran können wir nichts rütteln.

    Die Erfahrung hat halt wie gesagt gezeigt, dass man mit dieser Empfehlung meistens auf Granit beißt. Das verschlechtert bloß den Ruf der Community und sorgt dafür, dass die Leute erst recht bei Problemen nicht mehr fragen oder komplett weggehen.


    Mir hat diese Thematik lange zu denken gegeben, sodass ich mich mittlerweile entschlossen habe, einen Mittelweg einzuschlagen.

    Wir wollen Sicherheit. Neulinge wollen Hilfe. Also habe ich mal angefangen, für die vermutlich populärste Linux Distribution im Privatanwenderserverbereich ein Script zu schreiben, dass in der Lage ist, Probleme bei der grundsätzlichen Absicherung eines Servers mit einem solchen OS zu finden und ggf. auch Hinweise/Anweisungen zu geben.

    Und ja, es gibt Lynis und Co. Aber die Ausgabe dieser Scripts sind für einen Newbie wie eine Vorlesung in Raketenwissenschaften. Mein Ziel ist KISS - keep it simple and straightforward.


    Natürlich kommt dies nie mit einem professionell abgesicherten Server gleich, aber es deckt die Basics ab bzw. soll sie, wenn es fertig ist, abdecken. So können wir Newbies etwas an die Hand geben, womit wir zumindest theoretisch eine Grundlegende Sicherheit innerhalb der Netcup Community gewährleisten können. Das Ziel ist also eine Art Win-Win Situation für alle beteiligten. Je besser und intuitiver wir das Script gestalten, desto höher ist die Wahrscheinlichkeit, dass es genutzt wird und entsprechend für Sicherheit gesorgt wird.


    Ich würde mich freuen, wenn einige Community Mitglieder evtl. mit Vorschlägen oder Scriptschnipseln etwas helfen würden, sodass wir zu einem bestmöglichen Ergebnis kommen.

    Alle Community Mitglieder, auch die "Neuen", sind recht herzlich dazu eingeladen, das Script zu testen und mir bzw. uns Feedback zu geben. :)


    Das Projekt ist unter der Public Domain lizensiert. Es steht auf Codeberg, ihr könnt dort also gerne auch Issues, Pull Requests, etc. erstellen! *klick*


    So. Das war es erstmal meinerseits. ;)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Bei mir hängt auf einer Kiste das Script bei:

    Check: Is the SSH login restricted to specific users?


    Bei mir steht diese Zeile in der ssh_config:

    AllowUsers bxxxxx


    AllowUsers kommt auch nur einmal vor.

    Das konnte ich so reproduzieren. Ich hatte bei einem grep den Pfad zur Datei vergessen.


    Das ist gefixt und commited+gepusht. :)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Bei mir spuckt das Script folgendes aus:

    Zitat

    Check: Is the login as root via SSH disabled?

    Result: [x] Login as root via SSH is enabled, change PermitRootLogin in /etc/ssh/sshd_config to no!


    Ich habe Debian 10 und folgende Einstellung:
    PermitRootLogin prohibit-password


    Zitat

    PermitRootLogin prohibit-password sagt, dass sich root nicht über ein Passwort anmelden darf. Die Option prohibit-password wurde mit OpenSSH 7.0 eingeführt.




    Außerdem sagt das Script noch folgendes:

    Zitat

    Check: Is it possible to use password authentication for SSH login?

    Result: [x] Please generate a KeyPair on your local client and copy the PublicKey to ~/.ssh/authorized_keys of your remote user. After this, add the line 'AuthenticationMethods publickey' and change PasswordAuthentication in /etc/ssh/sshd_config to no!



    Bei mir ist Login mit SSH Key und noch zusätzlich mit Google Authenticator bei folgenden Einstellungen:

    AuthenticationMethods publickey,keyboard-interactive

    PasswordAuthentication no

  • Moin,


    in sshd.sh ist dir (vermutlich) ein kleiner Flüchtigkeitsfehler unterlaufen.


    Zeile 76


    Code
    if [[ $(dpkg -l | grep -iE "^ii[ \t]+fail2ban.*$") && $(systemctl is-enabled ssh) && $(systemctl is-active ssh) ]]



    Die beiden letzteren Bedingungen sollten wohl eher prüfen ob fail2ban aktiv(iert) ist ;)


    Das nur mal so vom überfliegen.


    Vielen Dank für deinen Einsatz!

  • Welchen Grund hat es das dass Home Verzeichnis auf eine eigene Position soll???

    Gerade auf einem Server auf dem Weg keiner im Home Verzeichnis arbeitet??

    Das Problem der Sache nennt sich Filesystem Flooding.

    Ich lasse das bewusst nur als Warning, nicht als Error ausgeben. Natürlich wäre das in deinem Fall irrelevant. Aber oftmals werden in Tutorials irgendwelche Apps im /home Directory installiert.

    Das ist dann natürlich unpraktisch, da so irgendwelche normalen User das OS lahmlegen können, indem zu viele Daten generiert werden. Und dann hören wir wieder "Mimimi, mein Server startet nicht mehr."

    Ich werde nochmal deutlich machen, dass das nur eine Empfehlung ist.


    Ich habe Debian 10 und folgende Einstellung:
    PermitRootLogin prohibit-password

    Ein Login als Root sollte auch mit einem Zertifikat nicht möglich sein. Daher wird prohibit-password nicht akzeptiert.



    Bei mir ist Login mit SSH Key und noch zusätzlich mit Google Authenticator bei folgenden Einstellungen:


    AuthenticationMethods publickey,keyboard-interactive

    Ich merke mir das mal. 2FA ist von der Sache her ja nicht verkehrt, das lässt sich sicher umbauen.


    Die beiden letzteren Bedingungen sollten wohl eher prüfen ob fail2ban aktiv(iert) ist

    Öhm... Si, da stimmt was nicht. Werde ich ändern. :P

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • So. Die genannten Fehler/Probleme habe ich gefixt/angepasst.


    Zusätzlich habe ich bei den Additional checks & hints mal noch einen Checker für die Netzwerkkonfiguration eingebaut. Wir hatten es meines Wissens ja schon ein paar mal, dass es Probleme mit DHCP Konfigurationen gab... Aber wie gesagt, nur als Hinweis.


    Weitere Hinweise, Tipps und Ideen nehme ich gerne an. ;)

    Tests und Feedback sind natürlich auch gerne gesehen. :)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Um explizit in diesem Diskussionsstrang nochmal den Advocatus Diaboli zu geben: Im "längsten Thema" hier im Forum und in der Einleitung oben kam ja vorher bereits der Verweis auf Lynis ("Auditing, system hardening, and compliance for Unix-based systems (Linux, macOS, BSD, and others)"), welches bereits deutlich umfangreicher ausfällt und im Zweifelsfall auch mit höherem Aufwand auf aktuellem Stand gehalten wird (kostenlos, aber auf Wunsch auch mit kommerziellem Supportvertrag). Warum das Rad also neu erfinden – zumal das Werkzeug auch spezifische Tipps gibt, wie man Probleme potentiell abstellen kann?

    Solange sich keine Tests finden lassen, welche nicht bereits von Lynis abgedeckt werden – wäre es wirklich nicht ratsamer/zeitsparender/hilfreicher, eine Dokumentation über den sinnvollen Einsatz dieses Werkzeugs (oder vergleichbaren Werkzeugen) zu verfassen, wenn man der Meinung ist, die Ausgabe existierender Lösungen wären nicht für Anfänger verständlich?

    Alternativ wäre es gegebenenfalls auch denkbar, ein Frontend für die vorgenannten Werkzeuge zu implementieren, welches eine Klassifizierung/Filterung der Ausgabe vornimmt, um Anfänger nicht zu überfordern – auch der hiermit verbundene Aufwand sollte deutlich geringer ausfallen als eine Reimplementation von Tests.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Vielen Dank für das Skript. Es ist sehr hilfreich.


    Ich habe noch einen Hinweis zu Debian Buster:

    Die Netzwerkkonfiguration liegt unter /etc/network/interfaces.d. Ist es möglich, dass die Konfigurationen in diesem Ordner auch geprüft werden?

  • Bei mir auf der NAS zuhause ist zuviel Rot und Orange... Aber funktioniert soweit und mir ist auch kein Fehler aufgefallen.


    PS: Ist für mein Heimnetz sicher genug. Und von außen ist nur ein ngnix erreichbar.

    Das Script ist auch für Server im freien Netz gedacht. Prinzipiell muss man sich, meines Erachtens, in einem Heimnetz, dass nicht stark von Gästen frequentiert ist, nicht so viel Aufwand und Arbeit machen.


    Die Netzwerkkonfiguration liegt unter /etc/network/interfaces.d. Ist es möglich, dass die Konfigurationen in diesem Ordner auch geprüft werden?

    Ja, den Gedanken hatte ich auch schon. Ich schau mal, was sich da machen lässt.



    m_ueberall Wenn du die Sache so angehst, können wir es auch lassen und nur sagen "Gib mal bei (Metager|Searx|Google|whatever)+ 'Linux Server absichern' ein und mach da mal ein paar Sachen.". Ich bin nicht so wirklich der Meinung, dass da ein Wille da ist, Dokumentationen zu wälzen und ewig zu lesen.

    Das widerspricht zudem meinem Ansatz der Einfachheit des Tools grundsätzlich. Ich möchte nur einen Ansatz und die Basis schaffen. Wenn jemand Interesse hat und sich wirklich Zeit nehmen will, dann wird er/sie nach besseren/tiefgreifenderen Lösungen fragen.


    Alternativ wäre es gegebenenfalls auch denkbar, ein Frontend für die vorgenannten Werkzeuge zu implementieren, welches eine Klassifizierung/Filterung der Ausgabe vornimmt, um Anfänger nicht zu überfordern – auch der hiermit verbundene Aufwand sollte deutlich geringer ausfallen als eine Reimplementation von Tests.

    Ein Frontend. Für die... und deutlich geringerer Aufwand? Kann ich mir in meinen dunkelsten Träumen nicht vorstellen. ^^


    Nur nochmal zum Verständnis. Ich will hier nicht Lynis nachbauen oder auch nur Ansatzweise etwas ähnlich komplexes bauen. Ich mag einen simplen Ansatz bereitstellen, mit dem man schnell und einfach ein Mindestmaß an Sicherheit herstellen kann. Mehr nicht. Keep it simple and straightforward!

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Die Idee so etwas zu machen, finde ich auch toll, sehe die Sache aber auch zweischneidig: Nur, weil man ein Mindestmaß an Sicherheit mittels Skript herstellen kann, bedeutet das noch nicht, dass man versteht, was auf dem Server passiert. Für die angedachte Zielgruppe der Neo-VPS-Besitzer ohne Vorerfahrung ist das vielleicht das falsche Signal. Für die Zielgruppe der tippfaulen Erfahrenen und für die Automatisierer ist die Sache sicherlich super.

    Ich teile also die Bedenken, freue mich aber, dass Du whoami0501 es versuchst. Sehen wir uns an, wohin der Weg führt. Mach weiter, lass Dich nicht entmutigen! Und danke, dass Du etwas verbessern möchtest.

  • eripek hey, macht das projekt mal nicht ganz so schlecht.

    ich sehe eigentlich sogar so, das es auch von Profis verwendet werden kann um zu schauen, hab ich auch nichts vergessen (basics)

    Und ja ich betreibe schon ne weile Server, hatte die letzten Jahre sehr viel Glück mit dem was ich gemacht habe oder habe es nie bemerkt. Bleibt bei einem Hobby und von so gesehen...


    Hier bei Netcup will ich es besser angehen und das auch zurecht, das Tool hilft mir gewisse Punkte an die ich bisher nicht so gedacht habe, aber auch andere Stellen wie das /home (in gelb) was ich bei einem Raid10 in Frage stelle, zumindest solang ich vorgefertigte images verwende, die bei installation über alles drüberbügeln.

    jeder der einen Schreibfehler in meinem Post findet, darf ihn Kommentarlos behalten

    P.S. gilt auch für Schignaturen ;)

  • eripek hey, macht das projekt mal nicht ganz so schlecht.

    ich sehe eigentlich sogar so, das es auch von Profis verwendet werden kann um zu schauen, hab ich auch nichts vergessen (basics)

    [...]

    Hast du eripeks Beitrag überhaupt gelesen?

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • mfnalex würde ich jetzt behaupten es wurde editiert wäre das vermutlich falsch, aber die letzten Zeilen habe ich wohl vorhin nicht so gelesen.

    was ich aber sage: für mich kam das beim Ersten mal lesen so rüber das alle VPS Besitzer dumm und hässlich sind und dahin zurück gehen sollen wo sie herkommen.

    jeder der einen Schreibfehler in meinem Post findet, darf ihn Kommentarlos behalten

    P.S. gilt auch für Schignaturen ;)

  • mfnalex würde ich jetzt behaupten es wurde editiert wäre das vermutlich falsch, aber die letzten Zeilen habe ich wohl vorhin nicht so gelesen.

    was ich aber sage: für mich kam das beim Ersten mal lesen so rüber das alle VPS Besitzer dumm und hässlich sind und dahin zurück gehen sollen wo sie herkommen.

    Das „Danke“ habe ich tatsächlich editiert, denn das fehlte zuvor, und das Fehlen fand ich selbst unangemessen. Aber ich würde mir niemals erlauben, in Schubladen dieser Art zu denken oder zu schreiben, wie Du sie in Deiner Schilderung Deines Eindrucks artikulierst.


    Ich finde das Vorhaben gut, habe aber Vorbehalte, die durchaus auch dem Plädoyer unseres advocatus diaboli m_ueberall entsprechen. Zugleich sehe ich auch Potential darin - auch, weil es zur Schaffung eines Problembewusstseins beiträgt - und diese Gedanken habe ich ausgedrückt.

    Dass einige neu hinzugekommene VPS- und RS-Besitzer vielleicht nicht die für diese Produkte erhofften Voraussetzungen (siehe netcup AGB) mitbringen, ist ja hier wohlbekannter Fakt und Ausgangslage zugleich. Daran ist nichts zu werten.

  • Dass einige neu hinzugekommene VPS- und RS-Besitzer vielleicht nicht die für diese Produkte erhofften Voraussetzungen (siehe netcup AGB) mitbringen, ist ja hier wohlbekannter Fakt und Ausgangslage zugleich. Daran ist nichts zu werten.

    Könntest Du vielleicht kurz aus netcup AGB zitieren, welche "erhofften Voraussetzungen" genau Du meinst?
    Danke. :)