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