Linux Kernsystem absichern durch Chroots und gute Rechtevergabe

Dieses Thema im Forum "Linux OS" wurde erstellt von feiz, 23.08.2010.

  1. feiz

    feiz Eroberer

    Dabei seit:
    21.03.2008
    Beiträge:
    67
    Zustimmungen:
    0
    Hi.

    Ich versuche grade meinen router/homeserver etwas sicherer zu machen.
    Ich möchte das Linux Kernsystem absichern.
    Z.B. durch eine gute Rechteverteilung, chroots usw.
    OS: Debian Linux.

    Leider klappt nicht alles so wie ich es mir vorstelle. Ich hätte ja gerne gehabt, wenn man als Admin mit dem Useraccount per SSH eingelogt hat, erst mal in einem chroot ist.
    Dadurch wollte ich verhindern, dass ein geknacker User Account Verzeichnisse wie z.B. /etc auslesen kann und der Hacker die Systemkonfiguration sehen kann / auf Schwachstellen untersuchen kann.
    Direkt per ssh als Admin oder Root einloggen ist natürlich auch gesperrt :)

    Hab nur ein paar Grundlegende Befehle in den chroot rein getan.
    Außerdem habe ich SU für den chroot neu kompiliert.
    Der Plan war, dass der Admin mit dem Useraccount im chroot dann su anwendet und so aus dem Gefängnis rauskommt auf den eigentlichen Adminaccount.
    Also quasi doppelt einloggen: Von aussen mit dem Admin-Useraccount erst mal in das chroot. Und von da dann per SU auf den Admin Account. Ein HAcker müsste also schon 2 Hürden überwinden, wenn er per SSH Login eindringen will.

    Leider klappt das nicht. wenn ich mit dem useraccount mit SSH einlogge bin ich wie gewünscht im chroot. Nur sobald ich su benutze schließt sich sofort die SSH Session und ich bin vom Server weg.

    Also musste ich den admin ssh login doch wieder freischalten, was ja nicht Sinn der Sache ist.

    Kann mir da jemand helfen?


    2. Ich will ne Gruppe anlegen namens sys oder so.
    Alle Linux Konten die für das System gebraucht werden, dann in diese Gruppe packen. als sekundäre Gruppe.

    Die eigentlichen Benutzeraccounts nicht.

    und dann chmod o-rwx /etc , Das selbe mit /bin und /usr.

    Somit wollte ich den normalen Useraccounts den Zugang zu /etc und co verwehren.
    Die CGI Scripte lasse ich zur sicherheit unter einem normalen Benutzeraccount laufen der nicht in die SYS Gruppe rein soll. Es könnte ja z.B. mal einen Angriff über meine Perl CGI Scripte geben.
    und der Angreifer könnte dann eventuell /etc auslesen und Schwachstellen in der Konfiguration suchen. Das soll halt nicht mehr so leicht möglich sein.

    Wenn ich dann ein Programm installiere, über apt-get oder so, und das einen User anlegt, muss ich den natürlich auch in die Gruppe sys packen.

    Ist sowas sinnvoll oder nutzlos? Oder führt es sogar zu Problemen?
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 bitmuncher, 24.08.2010
    Zuletzt bearbeitet: 24.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    Es ist nicht sinnvoll, was du da vorhast. Schliesslich nutzen auch normale User Programme, die ihre Konfigurationen in /etc abgelegt haben. Ausserdem werden dort z.B. User-Limits usw. festgelegt, die beim Login eingelesen werden müssen und gerade für Systemuser wie die Server-User notwendig sind. Und die häufigste Möglichkeit an Daten zu kommen, die der User eigentlich nicht sehen darf, sind Privilege Escalations in Programmen und fehlerhafte SUID-Programme. Aus einem chroot auszubrechen ist bekanntermaßen ein Kinderspiel für jeden durchschnittlich begabten Hacker. Anleitungen dazu finden sich zuhauf im Netz. chroot-Umgebungen machen daher nur Sinn um einzelne Prozesse einzusperren, aber nicht ganze User, die diverse Befehle u.a. auch Systembefehle wie ls, ps, cd etc. nutzen können müssen. Sobald 'su' innerhalb einer chroot-Umgebung zugelassen ist und man damit "offiziell" die Umgebung verlassen kann, wird die chroot-Umgebung ziemlich ad absurdum geführt.

    Kurzum: Du bastelst da gerade ein relativ unbenutzbares System zusammen. Sorge dafür, dass Systemuser keine Shell mehr haben. Installiere die hardened-Pakete, sichere Server-Tools korrekt ab und sorge dafür, dass nach außen nur Services erreichbar sind, die auch erreichbar sein müssen. Setze dann korrekte Limits in der limits.conf, patche den Kernel mit einem Stack-Smashing-Guard und das System ist ausreichend gesichert. Wenn du ganz paranoid bist, setzt du noch ein IDS ein, das unliebsamen Traffic ausfiltert (z.B. Traffic, der NOPs oder Shellcodes enthält, der nicht mit dem angeprochenen Protokoll korrespondiert etc.). Dann noch Tripwire oder AIDE rauf, um Änderungen im Dateisystem zu merken und regelmäßige Checks der Dateien. SSH-Login begrenzt du natürlich auf Key-Authentifizierung und mittels ACLs sorgst du dafür, dass User nur die Daten sehen können, die sie auch nutzen müssen. Temp-Verzeichnisse des Webservers mountest du mit noexec, so dass über den Webserver keine Programme eingeschleust werden können, selbst wenn es in CGI-Skripten Fehler gibt, die sowas ermöglichen könnten. Dass die CGI-Skripte selbst nicht auf Dateien ausserhalb des DocumentRoot zugreifen können sollten, versteht sich eigentlich von selbst und ist Aufgabe der Skripte. Um z.B. auf Directory-Traversal-Lücken und ähnliche typische Lücken zu prüfen, kann man ja Skipfish u.ä. nutzen, bevor die Skripte auf dem Server landen. Fertig ist ein einigermaßen gut gesicherter Server. Solange der Linux-Kernel aber ständig neue Sicherheitslücken offenbart, wirst du eine Kiste mit Linux eh nie wirklich sicher bekommen. Daher sind "schnelle" Updates das A und O bei einem Server.

    Wenn ein Hacker erstmal eine Shell auf dem Server bekommen hat, ist eh meist alles verloren. Da hilft auch eine chroot-Umgebung nichts mehr. Erspar dir also lieber die Mühe und nutze die Standards für Server-Sicherung.
     
  4. feiz

    feiz Eroberer

    Dabei seit:
    21.03.2008
    Beiträge:
    67
    Zustimmungen:
    0
    Danke für deinen sehr ausführlichen Text.
    Habe ihn mir gebookmarkt um das alls mal durch zu gehen.

    Aus dem Text geht hervor, dass es ein unkalkulierbares Risiko ist, normalen Usern einen Shellzugang zu geben da chroot zu unsicher ist, und rbash erstrecht.
    Bei manchen Webhosten hat man aber Shellzugang als Kunde. Wie machen die das dann?

    Was mir auch nicht gefällt, dass der Adminaccount direkt von außen per SSH auf den Server rauf kommen soll.
    Deswegen wollte ich ein zweistufiges Loginsystem machen. Zuerst mit dem Useraccount des Admins drauf, und dann mit SU erst Admin werden.
    Das mit den SSH Key Files ist auch nicht das Gelbe vom Ei.
    Wenn die Files abhanden kommen, kommt der Hacker ganz ohne Aufwand auf den Server. Deswegen müsste man das Passwort trotz Key File bestehen lassen.


    Ich möchte außerdem, dass man über den Webspace keinesfalls an /etc und co rankommt. Und auch nicht an die Verzeichnisse der anderen Webhosting Accounts- Nicht über PHP und auch nicht über CGI. Auf die Sicherheit der php/CGI Scripts kann ich mich nicht verlassen, da dritte Webhosting Accounts auf dem Server bekommen.
     
  5. #4 bitmuncher, 24.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
    Natürlich sollte ein root-Login via SSH nicht direkt möglich sein. Das versteht sich aber eigentlich von selbst. Die Dummheit von Usern, wie z.B. das Verlieren von SSH-Keys kann man nie wirklich ausschliessen. Das sollte aber kein Grund sein Bruteforce-Möglichkeiten wie einen Passwort-Login beim SSH aufzumachen, wenn du schon so paranoid bist. ;)
    Im übrigen ist mir kein anständiger Webhoster bekannt, der seinen Usern einen Shell-Zugang bietet. Jene Hoster, die Shell-Accounts bieten, verwenden zumindest eine restricted Shell, die nur den Aufruf bestimmter Befehle ermöglicht. Die Rechtevergabe im Dateisystem wird dann über ACLs gemacht. Wenn du sicherstellen willst, dass Webskripte nicht an ein Systemverzeichnis kommen, solltest du den Webserverprozess chrooten, aber nicht alle User. Du könntest ihn auch in einer VM laufen lassen, woraus man wesentlich schwieriger als aus einem chroot ausbrechen kann. Alternativ verwendest du SELinux und schränkst dann über Rollen die Rechte ein. Damit kannst du dann auch ganz "einfach" dafür sorgen, dass der Webserver auch keine Programme aufrufen kann. Für solche Anwendungsfälle wurde es ja schliesslich gemacht.
     
  6. feiz

    feiz Eroberer

    Dabei seit:
    21.03.2008
    Beiträge:
    67
    Zustimmungen:
    0
    Im 2.6er Kernel müsste SELinux ja schon dabei sein oder?
    Dann werde ich mich mal über SELinux und ACLs schlau machen.

    Den Apache ansich wollte ich nicht in einer chroot laufen lassen. Aber die einzelnen Webhosting Konten unter jeweils einer eigenen UID und im eigenen chroot laufen lassen.

    Das mit den vhosts wäre zwar auch ne gute Idee.
    Wenn Vhots, dann würde ich aber nur einen "webhosting" vhost machen. Also nen vollständigen LAMPP Vhost für die User-Webhosting.
    Ich würde also nicht für jeden Dienst nen eigenen vhost machen.
    Den Rest alles auf dem normalen Host. Auch mein eigenes Webhosting auf dem normalen Host, wegen der Adminoberfläche.
    Ist es schwer, einen vhost einzurichten?

    Die rbash, ist übrigens sehr Unsicher. Die ist höchstens eine "besser als garnix" lösung.
    Den SSH Zugang für die User könnte ich natürlich auch abschaffen, und nur SCP / SFTP zulassen.
    Normales FTP für die Dateiverwaltung zu verwenden ist sehr unsicher. Deswegen will ich es nicht benutzen.


    Root SSH Login ist natürlich nicht möglich. Habe dem auch noch /bin/false in passwd eingetragen.
    Aber Admin login geht. Admin ist ein Nutzerkonto mit Sudo rechten.
    Das Admin Konto wollte ich für ssh sperren, so dass ich nur über meinen normalen Useraccount per SU zum Admin werden kann.


    User sind zwar alles nur Familienmitglieder und der Server hängt am heimischen Internetanschluss, aber ich möchte das system trotzdem so sicher haben, dass man es ohne Probleme in ein Rechenzentrum verlagern könnte, und auch fremde User drauf lassen könnte.
     
  7. #6 bitmuncher, 24.08.2010
    bitmuncher

    bitmuncher Der Stillgelegte

    Dabei seit:
    08.05.2007
    Beiträge:
    3.171
    Zustimmungen:
    0
  8. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  9. #7 saeckereier, 25.08.2010
    saeckereier

    saeckereier Graue Eminenz

    Dabei seit:
    08.05.2005
    Beiträge:
    1.920
    Zustimmungen:
    0
    Ort:
    Im schönen Norden
    Eine kleine Ergänzung noch zu den sehr, sehr sinnvollen Hinweisen von bitmuncher: Eine Möglichkeit der Isolierung bietet zum Beispiel OpenVZ. Hierbei kannst du für jeden User eine virtuelle Instanz aufsetzen. Da nur das Betriebssystem virtualisiert wird, ist der Overhead mit ca. 2% sehr gering. Es gibt eine Reihe ähnlicher Techniken, aber mit OpenVZ arbeite ich, daher kenne ich die anderen, aktuellen nicht so genau. Für Webhosting wäre es dann zum Beispiel sinnvoll, einen Server, der als Reverse-Proxy fungiert einzusetzen. Nachteil ist natürlich, dass du n+1 Webserver laufen lassen müsstest. Ob das unbedingt Apache ist oder eine der leichtgewichtigeren Alternativen steht auf einem anderen Blatt. Ich nutze im Moment lighttpd + fastCGI PHP, wobei die PHP-Instanzen jeweils mit einem eigenen User laufen. Vergleichbares bietet Apache natürlich auch. Und insgesamt ist mir die Konfiguration vom Apache eingängiger. Ich bin allerdings auch mit der aufgewachsen.

    EDIT: Gerade gesehen, bitmuncher hatte es schon am Rande angeschnitten :-)
     
  10. feiz

    feiz Eroberer

    Dabei seit:
    21.03.2008
    Beiträge:
    67
    Zustimmungen:
    0
    Hey Danke für eure sehr guten Antworten.

    Ich werde mir das OpenVZ mal ansehen, weiß aber nicht ob ich damit klarkomme und ob der Server das packt mit den vielen Apaches.

    SELinux hab ich mir mal angeguckt, ein sehr kompliziertes Thema.

    Fürs Erste habe ich jezt jedenfalls die Useraccounts vom SSH weg, außer meinen eigenen.
    Root und Admin ist über ssh auch gesperrt.

    Aber irgendwie frickel ich grade an 5 Stellen rum und komme nirgends so richtig vorran :( Mir fehlt halt auch bisschen das Hintergrundwissen.

    Ich wollte mir jetzt verschiedene Bücher zulegen, und alles nochmal ganz von Anfang an durchgehen.

    Hab mir eure Hinweise jedenfalls mal in eine Datei rein kopiert und abgespeichert.
    Und mir die ganzen Sachen wie ACL, SElinux, openVZ mal auf der Liste aufgeschrieben. Um es wieder aufzugreifen, wenn ich mit den Grundlagen durch bin.
    Wie gesagt, ich fange auf nem Testrechner nochmal ganz von Vorne an, mit einer frischen Debian Minimalinstallation. Dieses mal nicht nur schnell alles aus irgendwelchen Howtows zusammengepappt, sondern mal versuchen, mal das ganze wie und warum zu verstehen.


    Gruß
     
Thema:

Linux Kernsystem absichern durch Chroots und gute Rechtevergabe

Die Seite wird geladen...

Linux Kernsystem absichern durch Chroots und gute Rechtevergabe - Ähnliche Themen

  1. Arch Linux via Hamachi zu bestehendem VPN verbinden

    Arch Linux via Hamachi zu bestehendem VPN verbinden: Guten Tag zusammen! Ich betreibe zu Hause einen kleinen Server für Minecraft und samba file sharing und möchte diesen nun zu meinem bestehenden...
  2. linux-firmware-nonfree in Centos 15.11 (64 Bit)

    linux-firmware-nonfree in Centos 15.11 (64 Bit): Hallo wie kann man linux-firmware-nonfree in Centos 15.11 (64 Bit) installieren?
  3. Linux konvertieren

    Linux konvertieren: Hallo, ich benutze VMware auf meinem Windows-Rechner. Dort würde ich gern eine neue Linux-VM einrichten. Nur, wie bekomme ich eine Linux-VM?...
  4. [SOLVED]Linux/W7 Dualboot efi problem

    [SOLVED]Linux/W7 Dualboot efi problem: Moin, ich plage mich gerade mit dem Problem des Dualboot Und zwar würde ich gerne mein efi installiertes Windows ebenfalls mit grub booten...
  5. Kunden-Skript ausgelöst durch Linux-Cluster Pacemaker

    Kunden-Skript ausgelöst durch Linux-Cluster Pacemaker: Hallo! Ich komme aus der AIX-Welt wo es im HACMP-Cluster die Möglichkeit der Ausführung eines Start- bzw. Stop-Skriptes im Zuge einer...