Hallo! On 30 May 2004 at 14:34 +0200, Maurice wrote: ^^^^^^^ Ich würde dich gerne mit vollem Namen ansprechen können. Wäre das möglich? Danke. > "Elmar W. Tischhauser" <tischhau@rbg.informatik.tu-darmstadt.de> wrote: > > > Es ist für den sicherheitsbewussten unstable-Nutzer also keinesfalls > > hinreichend, nur debian-security-announce@l.d.o zu verfolgen. > > Aber was macht man dann? Sich Zusatzinformationen beschaffen, was im Falle des Privatanwenders nicht einmal übermäßig zeitaufwändig ist, da zum Beispiel alle von böswilligen (lokalen) Benutzern ausgehenden Probleme schon mal per definitionem vom Tisch sind. Wenn also die Eingabe eines seltsamen Passwortes einen Pufferüberlauf im setuid-root installierten /usr/bin/passwd provozieren kann, ist das zu Hause weitaus weniger kritisch ist als etwa in einem Uni-Rechnerpool. Generell dürften die für den sid-Privatanwender relevanten Gefahren sich auf folgende Szenarien beschränken (dabei sind nur Angriffe von außen, also aus dem WAN, berücksichtigt). 1. Fehler im IP- oder TCP-Stack des Kernels. Das wären generisch ausnutzbare Bugs, die z.B. durch ein speziell geformtes Paket getriggert werden können. Sie kommen sehr selten vor und werden wohl meist bei gezielten und weniger bei automatisierten Angriffen genutzt (da Exploits meist an spezielle Kernelversionen gebunden sein dürften). Abhilfe: Möglichst aktuellen Kernel einsetzen. 2. Fehler in auf dem öffentlichen Interface angebotenen Diensten (z.B. HTTP, SSH). Die kommen immer mal wieder vor und werden gelegentlich auch automatisiert ausgenutzt (siehe zum Beispiel Slapper). Exploits in Diensten sind deshalb so kritisch, da diese häufig mit höheren Rechten laufen und somit am Gesamtsystem Schaden anrichten bzw. ihre Aktivitäten viel besser verbergen können als wenn sie nur unter einem unprivilegierten Nutzeraccount liefen. Abhilfe: Zunächst ist danach zu trachten, benötigte Dienste nur lokal bereitzustellen. Wenn am WAN-Interface nichts lauscht, kann dort auch nichts zum Einbruch verwendet werden. Ansonsten bietet es sich an, entweder die Security-Advisory-Mailingliste o.ä. des speziellen Dienstes zu verfolgen oder regelmäßig auf dessen Homepage nachzusehen. In den meisten Fällen dürfte unstable bald die nötigen Updates bereithalten, ansonsten kompiliert man sich die gefixte Upstream-Version unter Verwendung des letzten unstable-Sourcepakets schnell selbst. 3. Fehler in lokal angebotenen Diensten (z.B. NFS, IMAP, HTTP). Für das Vorkommen gilt das Gleiche wie für (2). Der Unterschied ist, dass ein externer Angreifer sich nicht direkt mit dem fehlerbehafteten Dienst verbinden kann, so dass Gefahren "nur" von lokalen Benutzern oder fehlerhafter Datenbehandlung entstehen können. Letztere ist durchaus manchmal gegeben, zum Beispiel könnte ein Fehler im IMAP-Server durch speziell formatierte E-Mails ausgenutzt werden, die ein Angreifer dir senden kann (da hilft es dann nichts mehr, dass der imapd nur auf 192.168.0.5:993 lauscht). Abhilfe: Wie bei (2). 4. Fehler in Clientprogrammen, welche aus dem Netz stammende Daten verarbeiten bzw. mit dem Internet interagieren (z.B. Browser, MUA, Bildanzeigeprogramm). Wenn beispielsweise Letzteres beim Anzeigen eines aus dem Internet heruntergeladenen Bildes bei der Speicherallokation auf dessen Längenangabe vertraut, wäre evtl. das Ausführen beliebigen Codes mit den Rechten des Benutzers möglich. Abhilfe: Wie bei (2). Zusätzlich hilft gesundes Misstrauen gegen "nette Attachments" oder dubiose Webseiten erheblich. 5. Fehler in allen anderen Programmen haben deutlich geringere Sicherheitsrelevanz. 6. Würmer/Viren/Trojanische Pferde. Wenn sie sich automatisiert installieren können, liegt ein Fall von (1)-(4) vor. Wenn nicht, ist man ohnehin selbst schuld. Abhilfe: Mehr als Verwendung des Gehirns in Kombination mit gesundem Menschenverstand ist nicht erforderlich. 7. Konfigurationsfehler. Gegen solche hilft auch der Einsatz von Woody nichts ;-). Abhilfe: Sachverstand beim Administrieren. Da man als Privatanwender in der Regel keine Dienste am öffentlichen Interface und nur wenige lokal benötigt [auch unter den lokalen sind ja nur diejenigen wirklich kritisch, welche aus nicht vertrauenswürdigen Quellen stammende Daten verarbeiten], reduziert sich die Menge der kritischen Anwendungen, die man auf aktuellem Stand halten sollte, erheblich. Auch gilt nicht für jedes unter (4) erwähnte Programm die gleiche Gefährdungsstufe. Der Browser ist sicherlich am kritischsten, bei einem Bildanzeigeprogramm würde ich die Updatefrequenz von sid als allemal ausreichend ansehen. Security-Announce-MLs haben zudem meist sehr geringen Traffic. Gibt es solche nicht, wäre es zum Beispiel eine Möglichkeit, einfach im Browser einen Bookmark-Ordner zu den Sicherheitsseiten oder Homepages der entsprechenden Programme anzulegen und etwa einmal wöchentlich kurz alle Seiten ('Open in tabs') durchzusehen. Der Aufwand dazu dürfte deutlich unter 5 Minuten liegen. Es gibt des Weiteren speziell für Debian ein hervorragendes HOWTO, das beschreibt, wie man ein System möglichst gut absichert, siehe <http://www.debian.org/doc/manuals/securing-debian-howto/> oder das Paket harden-doc. > Die Antworten hier, bringen mich zur Erkenntnis, dass Sid wohl doch > nicht das Non-Plus-Ultra ist. Was ist schon perfekt? Ein sicherheitsbewusster Anwender (wie Du) ist in vielen Szenarien alleine schon enorm hilfreich. Wenn er dann noch über ein vernünftiges Maß Admin-Knowhow verfügt und seine installierten Pakete regelmäßig auf aktuellem Stand hält sowie dabei speziell auf besonders kritische Komponenten (s.o.) ein Auge hat, hätte ich überhaupt keine sicherheitstechnischen Bedenken gegen den Einsatz von sid. Die Wahl sid/woody dürfte für die Nettosicherheit eines an öffentliche Datennetze angeschlossenen Debian-Rechners wesentlich weniger von Bedeutung sein als die Sachkunde des Administrators oder die Mentalität der Anwender. Gruß, Elmar -- [ GnuPG: D8A88C0D / 2407 063C 1C92 90E9 4766 B170 5E95 0D7F D8A8 8C0D ] ······································································· Geschehenes erkennt auch ein Tor. -- Homer, Ilias
Attachment:
pgp3d8noOVlYF.pgp
Description: PGP signature