Raspbian Konfigurationsscript - Sicherheit & Schutz

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen

    Wie ich bereits in einem vorherigen Post erwähnt habe arbeite ich grad an einem Script (siehe hier) welches die Raspbiankonfiguration und die Installation von mir gewünschten Programmen automatisiert. Die ersten Schritte bestehen darin einen neuen User mit Rootrechten anzulegen und den User pi danach zu löschen. Das klappt auch alles wunderbar.

    Der Schönheitsfehler der mich jedoch noch stört ist dass das Rootpasswort nicht mitgeändert wird. Ich hab schon einige Lösungsansätze probiert jedoch war das höchste der Gefühle die Meldung dass ich keine Lese/Schreibrechte habe um das Passwort zu ändern obwohl das Script natürlich mit Rootrechten ausgeüfhrt wurde. Im Terminal funktionieren die Befehle, nur im Script nicht.

    Beide Lösungsansätze liefern mir den oben genannten Fehler.

    Code
    echo "$passwort" | passwd --stdin root
    Code
    sh -c 'echo username:password | chpasswd

    Ist das eine Schutzfunktion und falls ja.. kann man diesen irgendwie umgehen? Oder ist mein Lösungsansatz hier einfach der falsche?

    Grüsse Apop

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Raspbian Konfigurationsscript - Sicherheit & Schutz? Schau mal ob du hier fündig wirst!

  • Ja habe im Script nur geprüft ob es mit Sudorechten aufgerufen wurde und falls nicht wird es mit diesen neu gestartet mittels

    Bash
    if [ "$EUID" -ne 0 ]; then
        echo "Nicht Root"
        [ `whoami` = root ] || exec sudo $0
    else
        echo "Root"
    fi

    Ich schätze mal dass es mit sudo -i nach dem Check nicht ausreichen wird ^^ . Ich recherchiere/probiere mal

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Die ersten Schritte bestehen darin einen neuen User mit Rootrechten anzulegen und den User pi danach zu löschen. Das klappt auch alles wunderbar.

    Das ist allerdings etwas, von dem ich Dir abraten würde. Unter Linux ist grundsätzlich kein User notwendig, der allgemeine root-Rechte benötigt und historisch ist eine solche Verwendung auch nicht vorgesehen. Und wenn Dir die Sicherheit Deines Systems wichtig ist, würde ich darauf auch unbedingt verzichten. Linux ist nicht Windows! Es gibt unter Linux keine Anwendungen im User-Space, also die für den normalen Endanwender-Betrieb notwendig sind, die Administrator-Rechte verlangen.

    Es reicht und es ist signifikant sicherer, wenn Du root ein Password vergibst und auf dieses unsägliche "sudo" verzichtest, weil das eindeutig ein hohes Sicherheitsrisiko darstellt und ziemlich leicht missbraucht werden kann. Du verwendest für alles Dein User-Password, soweit es das normale Arbeiten angeht. Und wenn Du Änderungen am System selber durchführen willst, meldest Du Dich als root an und führst die Änderungen NICHT als Apop85 durch, sondern direkt als root. Wenn Apop85 (oder ein anderer User) keine root-Rechte hat, können die auch nicht missbraucht werden... so einfach ist das... was unter Windows das Kernproblem darstellt. Also ich empfehle, Usern nicht die Möglichkeit einzurichten, unter der eigenen UID Tätigkeiten auszuführen, die root-Berechtigungen erfordern. Wenn Dir die Sicherheit des Systems allerdings egal ist, spricht natürlich nichts dagegen.

    BTW, Scripte, die das Recht haben, sich selber Root-Rechte anzueignen, sind der sicherheitstechnische Super-GAU....... ein absolutes NoGo.

  • Naja das Script ist auch nicht für Endanwender gedacht und auf den Geräten wird es nur den einen User geben daher muss ich mich um andere User mit Berechtigungen die sie nicht benötigen schon mal keine Sorgen machen.

    Den Rest nehme ich so zur Kenntnis. Das Script ist halt darauf ausgelegt dass eine Grundinstallation von Raspbian vorhanden ist mit dem mit zuviel Rechten ausgestatteten User pi. Dieses zuviel beschneide ich immerhin schon mal signifikant indem ich die Passworteingabe bei sudo aktionen beim neuen User drin lasse un pi lösche.

    Und weil bequem würd ich halt gern direkt loslegen nach dem ersten booten nach dem flashen auch wenn das wechseln auf Root jetzt nicht so viel Zeit in anspruch nehmen würde alles andere soll das Script übernehmen.

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Konnte es nun so lösen:

    @ThomasL Denke werde das Script jedoch noch entsprechend anpassen damit für root ein eigenes Passwort vergeben wird. Danke für den Hinweis.

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Dieses zuviel beschneide ich immerhin schon mal signifikant indem ich die Passworteingabe bei sudo aktionen beim neuen User drin lasse un pi lösche.

    Nein, leider nicht. Das hat keinerlei Auswirkung auf eine Verbesserung der Sicherheit. Wenn Du sudo mit default-Setttings verwendest, kann das jedes installierte Programm, Addon, Plugin unbemerkt und ohne Kenntnisnahme durch Dich missbrauchen. Wie gesagt, der mit sudo zu root-Rechten autorisierte User ist das eigentliche Risiko, mit dem Du jegliche Sicherheit Deines Rechners aus der Hand gibst. Welches Passwort Du dem User dafür vergibst ist völlig irrelevant, weil es das Password das Users ist. Die Password-Sicherheit von "aaa" wäre in dem Fall exakt die gleiche, als wäre das Password ein 150 Zeichen langes Sammelsurium von Worten aus der Beschreibung einer Explosionszeichnung einer Waschmaschine.... ist also in dem Fall belanglos. "sudo" und der berechtigte User ist das eigentlich Problem, das Password hat unter diesen Umständen keinen oder nur sekundären Einfluss auf die Sicherheit.

    Ich habe das mal umfassend beschrieben, wenns Dich interessiert, sende ich Dir einen Link per PM.

    [ `whoami` = root ] || exec su root $path

    Wie ich sagte, sowas geht gar nicht..... und ist meiner Meinung nach auch schlechter Stil, weil es zur Laufzeit Password-Abfragen macht. Richtig wäre es imho, wenn das Programmm feststellt, es ist nicht "root", dass es sich mit einer Fehlermeldung beendet. Das heisst, ein solches Programm wird von vornerherein mit den entsprechenden Rechten gestartet, ohne dass eine Abfrage im Programm erfolgt. Und bei solchen, die nur mit root-Rechten ausgeführt werden sollen, sollte das Programm keinesfalls dort gesspeichert werden, wo es mit normalen User-Rechten verändert oder manipuliert werden könnte. Ich glaube, die heutige Zeit mit der hohen Form von digitaler krimineller Energie durch Staat und Ganoven (bei dem Aspekt beides das gleiche) verbietet einem eigentlich solche leichtsinningen Fehler, die man sich eigentlich gar nicht mehr leisten kann.

    Einmal editiert, zuletzt von WinterUnit16246 (10. Januar 2019 um 17:36)

  • Ja gerne schick mir den Link mal bitte. Das würde ich gerne mal lesen.

    Hmm wie kann sich denn ein Script selber sudo rechte erteilen wenn für die Ausführung von sudo ein Passwort benötigt wird? Also ohne interaktion vom User meine ich. Die versuche die ich mit Scripts und den entpsrechenden Befehlen gemacht habe auf meiner VM resultierten alle in einem Passwortprompt oder wurde mit dem Hinweis auf fehlende Rechte unterbrochen daher erstaunt mich das grad etwas.

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Hmm wie kann sich denn ein Script selber sudo rechte erteilen wenn für die Ausführung von sudo ein Passwort benötigt wird?

    Tja, das ist die böse Falle, die ich mit Missbrauchen beschrieben habe... ein Spiel über Bande.....

  • Wie ich sagte, sowas geht gar nicht..... und ist meiner Meinung nach auch schlechter Stil, weil es zur Laufzeit Password-Abfragen macht.

    Das habe ich schon verstanden. Da es jedoch die Antwort auf die bei diesem Thema gestellte Frage ist gehört die mmn hier hin. Dass es schlecht ist hab ich ja schon verstanden.

    Mal rein auf dieses einzelne Script bezogen. Dieses Script ist ein One-Time Script welches nach erfolgreichem Abschluss wieder vom Gerät entfernt wird. Auch ist das Script für den Fall und nur für den Fall bedacht wenn man ein frisch aufgesetztes und unkonfiguriertes Raspbian, was ja eine hohe Sicherheitslücke durch defaultpasswort und rootrechten ist, durch den Besitzer entsprechend konfigurieren möchte.

    Insofern würde ich jetzt das Sicherheitsrisiko in diesem speziellen Fall als überschaubar erachten. Wenn es jetzt ein Script ist welches immer wieder laufen soll dann ist mir diese Argumentation klar und nachvollziehbar.

    Das einrichten des seperaten Rootpassworts sowie das entfernen der Rootrechte für den user hab ich schon mal integriert.

    Ich schau mir mal den Link von dir noch an

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Hab den entsprechenden Abschnitt gelesen. Soweit deinen Tipps für die Sicherheit ist eigentlich alles eingehalten. Der neue Nutzer hat keine Sudoberechtigung und Für Root und User muss zwingend ein unterschiedliches Passwort eingegeben werden.

    Grundsätzlich bleibe ich bei meiner vorhergehenden Argumentation bezüglich Root bei diesem Speziellen Script/Beispiel. Die Grundinstallation von Raspbian ist ein deutlich höheres Sicherheitsrisiko als dieses Script darauf auszuführen mit der entsprechenden rechteaneignung und welches ja auch dazu dient diese Risiken zu minimieren. Wie gesagt, diese Argumentation gillt nur für dieses eine Beispiel. Sonst bin ich ganz deiner Meinung.

    Das mit der Codeinjection bei .bashrc ist wirklich eine sehr doofe Sache. Die auf readonly zu stellen ist keine Option?

    Grundsätzlich würde ich gerne alle diese Sicherheitstips von deinem Link in mein Script einbauen, habe diesbezüglich jedoch noch einige grundliegende Fragen. Sollen wir das per PN weiter besprechen oder hier im Thread? Also falls du denn bereit dazu bist ;) . Ist zwar durchaus sicherlich Interessant für nachfolgende die auf diesen Thread stossen jedoch geht es schon etwas sehr ins OffTopic

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

  • Sollen wir das per PN weiter besprechen oder hier im Thread?

    Nee, nicht per PM, davon hat ja niemand anderes was... gerade weil IT-Sicherheit ja eigentlich ein Thema ist, was alle betrifft. Und darüber hinaus, warum willst Du auf das KnowHow des Forums verzichten.... das ist doch viel mehr als das, was wir alleine und nur per PM ereichen könnten. Besser wäre es, solche Probleme allgemeintauglich forumuliert hier zu besprechen. Und jeder kann sich nehmen, was er für wichtig hält, oder auch alles für unwichtig erachten.

    jedoch geht es schon etwas sehr ins OffTopic

    Das ist Dein Thread, was Ontopic ist, entscheidest Du.

  • Tja, das Thema ist ja immer noch das Script.... und da gehören imho auch sicherheitsrelevante Aspekte hinzu. Ich habe dabei die Sichtweise "Man kann mit Linux zwar alles machen... aber nicht immer ist alles zu machen, was geht, am Ende auch die richtige Entscheidung." Solange es also um das Script geht.....

  • Hmm wie kann sich denn ein Script selber sudo rechte erteilen wenn für die Ausführung von sudo ein Passwort benötigt wird? Also ohne interaktion vom User meine ich.

    Wenn die Script-Shell "non interaktiv" gestartet wird, ist eine Passwortabfrage (denk)unmöglich und deshalb wird auch in diesem Fall kein Passwort abgefragt. Und das ist auch nur wegen der großzügigen Voreinstellung der /etc/sudoers möglich.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Zum allgemeinen Verständnis. Ich beziehe mich bei meinen Fragen auf folgende Quelle:

    http://www.thlu.de/security.html#vermeidbarerisiken

    .bashrc

    Ich habe die Berechtigungen nun mal auf readonly (444) gestellt und mit dieser Einstellung konnte ich keine Befehle mittels echo in die Datei einfügen. Ist das ein möglicher Lösungsansatz? Die Berechtigungen dieser Datei mittels Script zu ändern nachdem der User erstellt wurde ist ja kein Problem.

    Ich konnte auch beim kurzen antesten keine Probleme beim erneuten aufrufen des Terminals oder nach dem reboot feststellen. Würde das längerfristig zu Problemen führen dass du dies in deiner Beschreibung nicht erwähnt hast?

    User darf keine Software installieren/starten

    Lösung: remount von /home, /dev/shm und /tmp mit noexec,nosuid,nodev

    Keine Software installieren ist ja durch den Entzug der Rootrechte des neu angelegten Users gelöst, das kann dann nur noch Root.

    Wie löst du das mit deinen eigenen Scripts? Lässt du da alle unter Root laufen/starten oder hast du da einen weiteren User speziell dafür oder ein Unterverzeichnis irgendwo?

    Direktlogin für root per SSH unterbinden.

    Lösung: /etc/ssh/sshd_config = PermitRootLogin no

    Heisst ich müsste mich dann mit z.b. User Apop anmelden dann im Terminal mit su root fortfahren oder wie ist da die praktische Anwendung wenn ich mich als root per SSH einloggen möchte?

    Du sagst da dass es bei "normalen Client-PCs" unterbunden werden soll... Heisst man kann auch ausnahmen hinterlegen?

    Der Zugang nach draußen ins Internet ist auf einigen besonderen Geräten via Paketfilter reguliert.

    Du sagst da dass du deinen Server nur auf Mail (Getmail + Postfix) und VPN beschränkt hast. Benutzt du in diesem speziellen Beispiel den VPN-Zugang nur um mit diesem zu kommunizieren oder auch für die Weiterleitung deines Traffics in Netz?

    Was ich eigentlich wissen will ist ob diese strenge einschränkung auch bei einem Raspberry zur verwendung kommt der als PiHole/VPN konfigueriert ist, da dieser ja die Aufgabe hat jeglichen Traffic vom Client ans Netz via PiHole weiterzuleiten. Die Clients die ich Hoste benutzen das u.a. um regionblocks in Zensurreichen Staaten (Asien) zu umgehen und Zugriff auf das europäische Angebot zu erhalten und ich um logischerweise Werbung auf allen Geräten zu blocken.

    Befehlseinschränkung für User

    Die Befehlseinschränkung für den User ist natürlich sinnvoll. Welche Befehle sollte und kann man denn sperren ohne dass ich mir selbst das login zum Rootzugang via oben genannter SSH einschränkung verbaue?


    Den Rest sollte ich hinkriegen

    Apop85 Du passt den Titel an und ich verschiebe nach Debian & Raspbian wenn das ok ist?

    Jepp das ist i.o. Hoffe Titel ist noch einigermassen verständlich ^^

    Wenn die Script-Shell "non interaktiv" gestartet wird, ist eine Passwortabfrage (denk)unmöglich und deshalb wird auch in diesem Fall kein Passwort abgefragt. Und das ist auch nur wegen der großzügigen Voreinstellung der /etc/sudoers möglich.

    Wow.... :wallbash:. Und danke fürs aufklären.

    EDIT: In der sudoers Datei sehe ich keinen Eintrag der auf soetwas hinweist ausser du meinst %sudo ALL=(ALL:ALL) ALL. Hast du evt eine Quelle oder kann da jemand auskunft geben wie man das unterbinden kann... bzw ob das möglich ist ohne das system in irgend einer weise zu beschneiden?

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

    7 Mal editiert, zuletzt von Apop85 (10. Januar 2019 um 19:41)

  • Direktlogin für root per SSH unterbinden.

    Lösung: /etc/ssh/sshd_config = PermitRootLogin no

    Heisst ich müsste mich dann mit z.b. User Apop anmelden dann im Terminal mit su root fortfahren oder wie ist da die praktische Anwendung wenn ich mich als root per SSH einloggen möchte?

    Das müsste über Schlüsselpaare (Public key authentication) mögliche sein. Damit entfällt dann das einloggen mittels Passwort. Die Schlüssel müssen "nur" sicher auf das jeweilige Gerät übertragen werden. Siehe auch man ssh und man ssh-keygen usw..

  • Ich habe die Berechtigungen nun mal auf readonly (444) gestellt und mit dieser Einstellung konnte ich keine Befehle mittels echo in die Datei einfügen. Ist das ein möglicher Lösungsansatz?

    Ja sicher, warum nicht. Ich halte das allerdings für einen Workaround, der nur durch eine Entscheidung an anderer Stelle notwendig geworden ist, die ich eben für falsch halte. Man gewinnt mit sudo weder Komfort noch Sicherheit. Vor allem vor dem Hintergrund, dass man im Grundegenommen gar nicht über irgendwelche Workarounds bei einer anderen Heransgehensweise nachdenken müsste, oder das man solche Workarounds auf einen neuen System zu einem späteren Zeitpunkt vielleicht sogar wieder vergessen könnte. Im gleichen Zug hat der Verzicht auf sudo auch keine Nachteile, wie höherer Aufwand oder schwierigere Lösungen. Im Gegenteil, eine saubere Trennung von Verantwortlichkeiten ist mit sudo definitiv unmöglich gemacht. Es gibt bei einem Heim-Desktop-PC oder einem privaten Server mit einem einzigen Admin nicht einen einzigen vernüftigen Grund sudo zu verwenden. Und wenn man als "alter Hase" das gewohnte sudo-Gefühl beibehalten will, kann man das auf einfachste Weise mit einem einfachen Bash-Dreizeiler emulieren, ohne die Nachteile des eigentlichen Paketes "sudo" zu haben. Das Polkit bietet weitaus bessere Möglichkeiten, mit selektiven Rechten umzugehen. Das ist halt nur eine andere Herangehensweise....

    User darf keine Software installieren/starten

    Das hat aber jetzt nichts mit dem Script zu tun, sondern gehört zu den sicherheitstechnischen Folgeüberlegungen auf einem Desktop-PC mit hohem Anteil an Internet-Interaktion durch User.

    Direktlogin für root per SSH unterbinden.

    Auch das ist eine Sache für "hinterher". Man kann hier auch noch nicht mal sagen, dass die root-Anmeldung generell nicht erlaubt sein soll. Auch dafür gibt es durchaus sinnvolle Szenarien. Wenn man das allerdings nicht benötigt, würde ich natürlich die root-Anmeldung via SSH deaktivieren. Viel wichtiger ist aber, generell keine Password-Authentifikation zuzulassen, sondern nur via CA mit zusätzlicher Password-Authentifizierung der CA. Das heisst, die Verwendung der CA wird selber auf dem Client-PC noch mal mit einem PWD gesichert, unabhängig davon, was der Server tut.

    Der Zugang nach draußen ins Internet ist auf einigen besonderen Geräten via Paketfilter reguliert.

    Ein schwieriger Aspekt. Gilt imho auch erst mal nicht für ein Setup-Script und erhält erst im Betrieb seine wirklich Bedeutung... mit völlig unterschiedlichen Zielsetzungen bei Server, Client-PC und mobiler Client-Laptop.

    %sudo ALL=(ALL:ALL) ALL.

    Das ist natürlich nen Freibrief.... ich persönlich würde damit nicht mehr über eine Firewall oder sonstige Maßnahmen nachdenken die Sicherheit zu verbessern und einfach sagen "ach sch**ß drauf, ich habe ja nix zu verbergen." Aber das ist nur meine Meinung, und ich bin da vielleicht etwas sensibler als üblich.

    Einmal editiert, zuletzt von WinterUnit16246 (10. Januar 2019 um 20:19)

  • Ich hab mal anhand des sudoers Manual Versucht eine Konfiguration zusammenzustellen die den Anforderungen entspricht.

    Ich bin mir nicht sicher ob ich alles Verstanden habe also bitte korrigiert mich allenfalls.

    Bash
    # Override built-in defaults
    Defaults                syslog=auth
    Defaults                mail_badpass
    Defaults                env_reset
    Defaults                secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
    Defaults:apop85gruppe   noexec
    
    root        ALL = (ALL:ALL) ALL
    apop85   shanty = NOEXEC: /usr/bin/nonrootscripts

    Bei Zeile 5 bin ich mir nicht sicher, die ist standardmässig bei meiner Beere und meiner VM so hinterlegt. Beisst sich das mit dem noexec vom User?

    Bei der letzten Zeile verwirrt mich shanty etwas. Es wird im Manual sonst nirgends erwähnt also gehe ich davon aus dass dies dazugehört? Und der Pfad sollte ja dann erlauben dass in diesem Ordner Scripts ausgeführt werden?

    Reicht das so aus oder fehlt noch was?

    Das hat aber jetzt nichts mit dem Script zu tun, sondern gehört zu den sicherheitstechnischen Folgeüberlegungen auf einem Desktop-PC mit hohem Anteil an Internet-Interaktion durch User.

    Das gehört zum Script weil ich damit ja die entsprechend passenden Rechte für den Nutzer einrichten möchte. Oder ist das nur für die Endgeräte nicht für den Server gedacht? Sorry wenn ich das falsch interpretiert habe ^^

    Ich suche nicht nach einer fertigen Lösung sondern nach dem Weg dahin ;)

    5 Mal editiert, zuletzt von Apop85 (10. Januar 2019 um 20:41)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!