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" <[EMAIL PROTECTED]> wrote:
>
> > Es ist f�r den sicherheitsbewussten unstable-Nutzer also keinesfalls
> > hinreichend, nur [EMAIL PROTECTED] 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
pgp5pICLamTy6.pgp
Description: PGP signature
