Linux kann ein sehr sicheres System sein.

Dies trifft allerdings nicht unbedingt auf eine Standardinstallation einer üblichen LinuxDistribution zu (auch wenn dies im Laufe der Zeit besser geworden ist), sondern man muss sich selbst aktiv und kontinuierlich darum kümmern.

Wichtigste Punkte:

• /GrundRegeln der Systemsicherheit

• SicherheitsUpdates der Distributoren

• Außerdem sollte man ein LinuxSystemÜberwachen

Siehe auch die LinuxSecurity/LinuxFaq Seite (muss noch irgendwann mit dieser hier integriert werden!)

Spezielle Sicherheitstechnologien und Software:

• abgesicherte Datenübertragung und VPN

  • OpenSSH

  • IPSec und FreeSWAN bzw. OpenSWAN

  • CIPE

  • stunnel

  • TLS

  • SSL

• Verschlüsselung und Authentizitätsprüfung von Daten

  • GnuPG

• Verschlüsselung auf Filesystem- oder Blockdevice-Ebene

  • CryptoLoopDevice

  • cryptsetup

• Feinere Differenzierung von User- und Dateirechten

  • SELinux

  • grsecurity

  • RSBAC

• IntrusionDetectionSystem

Firewall

• s.a. unter FireWall

Sicherheitsrelevante Fehler in Software entdecken

Häufig muss man alte Software verwenden, die ohne besondere Rücksicht auf Sicherheitsaspekte programmiert wurde. Sollen diese dann in einer gefährdeten Umgebung verwendet werden, so wird ein Security Audit nötig. Darum geht es in diesem Abschnitt.

Software

• Übersicht, von Programmen, die das finden von Fehlern erleichtern sollen.

• valgrind

• FlawFinder

• RATS

Texte

• Practical Code Auditing von Lurene A. Grenier

• Linux Kernel Auditing von Alan Cox.

• http://mixter.void.ru/vulns.html

• http://heap.nologin.net/programming.html

RootKits Entdecken und Entfernen

Mit ChkRootKit kann man nach den verbreitetsten RootKits suchen, siehe auch IX 2002/7 S.103.

Hinweis: Bei neueren SuSE-Versionen (9.1) meldet chkrootkit eine Infektion. Fehlalarm (ist bei Novell dokumentiert).

s.a. Linux Kernel Rootkits {en}

Unter http://www.rootkit.nl findet sich ein weiteres freies Programm, rkhunter.

Fragen

Wie kann ich überprüfen, welche Sicherheitslücken mein Server hat?

• Beim Hersteller Deiner LinuxDistribution anklopfen.

• CERT und BugTraq lesen.

• Zum Überprüfen auf bekannte Schwachstellen dient nessus.

• Bei Debian: security.debian.org in die apt/sources.list aufnehmen.

Ich benutze ein Linux-Firewall, um ein Windows-Netzwerk per DSL an das Internet anzubinden. Wie kann ich überprüfen, ob auf den Dosen irgendein Programm läuft, das eine Verbindung nach außen öffnet, die es nicht soll?

• Reicht es, netstat -M aufzurufen, und die Einträge zu überprüfen?

  • das zeigt Dir allenfalls die aktuellen Verbindungen an
  • Du könntest aber in der Forward-Queue von innen nach aussen alles verbieten und nur das zulassen, was Du haben willst.
• Wie finde ich heraus (ohne die Firewall-Scripte zu lesen), welche Ports von innen nach außen weitergeleitet werden?

  • Port-Weiterleitung muss man normalerweweise explizit konfigurieren. Ich bin mir aber nicht sicher, ob Du das wirklich wissen wolltest

  • Wenn ein Betriebssystem potentiell gegen Dich arbeitet, hast Du kaum ne Chance, das wirklich sicher zu kriegen in punkto Datenschutz und Netzwerksicherheit. Man kann z.B. auch in http- oder DNS-Anfragen Daten übertragen.

  • Ansonsten solltest Du wirklich Dich mit Firewall-Skripts beschäftigen, siehe z.B. PaketFilter und Unterseiten.

-- ThomasKalka 2002-08-29 11:03:17

OffeneFrage: Wie richte ich eine ThomasKalka/SichereSandbox ein ? --ThomasKalka

• Teilantwort: Das kommt drauf an ob der Prozess Root-Rechte braucht. Wenn ja, so kann UserModeLinux helfen. Wenn nein, so reicht meist eine goot ChrootUmgebung. Zunächst muss man verhindern, dass der Prozess auf irgendetwas zugreifen kann, dazu erzeugt man ein System im System (bei Debian mit debootstrap). Nun muss man dem Prozess nur noch verbieten dinge außerhalb des Dateisystems anzufassen. Das bedeutet, dass die UID und GID nicht gleichzeitig Prozessen außerhalb der ChrootUmgebung gehören darf. Weiterhin sollte man den/die Prozesse mittels ulimit im Ram und CPU Bedarf einschränken. -- HelmutGrohne 2004-12-18 13:42:27

Links

Interessante Links zum Thema sind vielleicht auch noch folgende:

• Linux Security HOWTO

• Top 75 Security Tools

• Top 20 Sicherheitsschwachstellen - SANS

• Selflinux: Grundlagen Sicherheit (recht umfassender Artikel)

• Selflinux: Paketfilter Iptables

• Netfilter (dt.)

• LAN-Sicherheitskonzept und Aufbau eines Firewall-Systems (Diplomarbeit von Gregor Domhan, Fachhochschule Aalen, Jahr 2000/2001)

• LASG - Linux Administrator's Security Guide (Kurt Seifried, 2001)

• Linux Security Administrator's Guide (Jahr 1998)

• Sardonix - Infos über Security Audits von Programmen.

• Selflinux über Sicherheit (z.Zt. noch dünn)

• Distributionsspezifisch

  • Anleitung zum Absichern von Debian

• Firewalls mit LinuxKernel 2.6

  • Building a Diskless 2.6 Firewall (Linuxjournal)

• Firewalls für LinuxKernel älter als 2.6

  • Firewall selbst entwickeln (für Kernel-Versionen bis 2.4)

  • Firewall Handbuch für LINUX 2.0 und 2.2

  • Firewall unter Linux (für Kernel-Version bis 2.2)

  • Firewall and Proxy Server HOWTO (Stand: Jahr 2000)

  • Workshop: Desktop-Firewall mit Linux 2.4

• Viren

  • The ELF Virus Writing HOWTO

• Intrusion Detection

  • IntrusionDetection für Linux-Server Buch von Ralph Spennberg (die alte Auflage kann man kostenlos online lesen)

Software

• Samhein - Ein art verteiltes AIDE/Tripwire

Diskussion

• IMO gehört ein PaketFilter nicht zu den /GrundRegeln, da er nicht unbedingt notwendig ist, wenn man die Dienste richtig konfiguriert/abschaltet (dann kann man ihn höchstens zum Schutz vor DOS Attacken nutzen). -- RonnyBuchmann

  • Möchte ich bestätigen. Wenn allerdings NFS im Einsatz ist, braucht man einen Filter gegen gespoofte UDP-Pakete.
    • Wer will schon alles Mögliche abschalten?
      • Die garantiert unsicheren Dienste schaltet man ab: rlogin, rsh, rexec, telnet. Die braucht nämlich auch keiner mehr.
    • Welcher Einsteiger weiss schon, wie er alle benutzten Dienste sicher konfiguriert?

      • Welcher Einsteiger kann einen PaketFilter konfigurieren?

        • RedHat: jeder, der eine Maus bedienen kann

          • Falsch! Das Zeug, welches die Redhat-GUI erzeugt, ist doch ein schlechter Witz! Da ist es schon richtig, dass man lieber die nicht notwendigen Dienste abschaltet! Ich denke, eine Kombination aus beidem stellt die beste Lösung dar! -- JanRoehrich

            • Lies die Diskussion von Anfang bis zum Ende: darum geht es nicht. Es geht darum, dass ein Paketfilter zur grundlegenden Sicherheit gehört - insbesondere für Linux-Anfänger, die gar nicht wissen, was notwendig ist oder wie man xx Dienste sicher konfiguriert.

        • viele, die PaketFilter gelesen haben

        • der Punkt ist einfach der, dass es einfacher ist, ein System mit 1 Methode nach aussen dicht zu machen, als xx Dienste so zu konfigurieren, dass man evtl. auch ohne auskommen könnte.
• Was ist mit Spoofing?
  • Wenn ein Dienst nur auf einer lokalen IP bindet, kann ihm das nichts anhaben, das ist es worauf ich hinauswill. Die Überprüfung des Absenders vom Dienst selbst funktioniert in der Tat nur in Kombination mit einem Anti-Spoofing-Filter.

    • Das ist so nicht ganz korrekt vgl.: http://cert.uni-stuttgart.de/archive/bugtraq/2002/05/msg00103.html sprich das es ist nicht unbedingt die beste Vorgehensweisen Dienste an ein bestimmtes Interface zu hängen. Man muss nun sichergehen das nur Pakete für die IP Adresse des Interface eingehen, oder nur bestimmte IP Ranges auf einen Dienst zugreifen dürfen, diese jedoch auch nur über ein entsprechendes Interface reindürfen, sprich 10.0.0.1 ist eth0 und dort darf nur 10.0.0.0/8 rein und über eth1 dürfen nur ips von 192.168.0.0/24 sodas man selbst mittels simplem IP Spoofing nicht auf den Dienst zugreifen darf.

• Deshalb und auch für den Fall, dass man mal was vergisst, gehört ein PaketFilter mit Deny-All-Strategie IMHO zur Grundausstattung jedes Rechners mit Internet-Verbindung.

  • Deny-All ist asozial. Das IP-Protokoll hat aus gutem Grund Fehlermeldungen, deshalb ist die Grundausstattung (wenn überhaupt) Reject-All.

• Der Meinung ist wohl auch z.B. RedHat, sonst würden sie nicht schon im Grundinstaller das anbieten.

  • Dass es 'hip' ist, zählt da sicher auch. Bei sendmail haben sie ja schonmal mit der richtigen Konfiguration angefangen (läuft nur auf 127.0.0.1), aber spätestens bei cups war wieder Schluss.
• Bei SuSE gibt es die Personal-Firewall.

Außerdem wiegt man sich durch einen PaketFilter zu schnell in falscher Sicherheit. Wenn mir netstat -tanup nur Sachen ala 127.0.0.1:* anzeigt, dann ist mir wohler.

• Frage zum Seitennamen: Ist "LinuxSecurity" ein Fachbegriff? Sonst würde sich doch eher LinuxSicherheit empfehlen?!

  • Hat sich wohl so eingebürgert. Aber LinuxSicherheit zeigt ja auch hierher... -- HenrykGerlach 2004-09-17 21:18:19

KategorieSicherheit