UNIX - Hostsicherheit
Version 1.2 | unsupported
Dem Titel kann man entnehmen, dass diese Seite der Sicherheit von Hosts
in Netzwerken gewidmet ist. Ich habe mich entschieden über die Sicherheit
von Unix-Hosts (und nicht Windows-Hosts) zu schreiben, da dies gerade für
Leute die auf ihrem PC Linux laufen haben und viel bis sehr viel Zeit online
verbringen interessant sein könnte zu wissen, welche Türen wem
offen stehen und wie man den Rechner vielleicht nicht in eine Festung,
jedoch in ein etwas schwerer einnehmbares Haus verwandeln kann.
Zugegebenermaßen ist die Gefahr für einen privaten PC der
sich zwischen tausenden von mehr oder weniger anonymen DNS-Namen des Dialon-Pools
eines grossen Providers verbrigt eher gering ist, einem Cracker in die
Hände zu fallen, doch kann es nicht schaden etwas über das eigene
System zu wissen und wenn man dann vielleicht später beruflich in
diesem Bereich tätig werden will, kann es auch nicht verkehrt sein
etwas über Sicherheit zu wissen und mit einfachen Methoden vertraut
zu sein.
Inhalt
Ich möchte darauf hinweisen, dass diese Seite keinen Anspruch auf
Vollständigkeit erhebt. Am Ende dieser Seite finden Sie Informationen
über die Quellen die ich verwendet habe, sowie über weiterführende
Literatur zu diesem Thema. Falls Sie sich mit dem Thema Sicherheit eingehender
beschäftigen wollen, sollten Sie sich auf jeden Fall mit dem entsprechenden
System (hier Unix) eingehend auseinandersetzen. In diesem Fall gibt es
zwar viel Theorie, die man auch im Hinterkopf behalten sollte, doch ist
auch die praktische Erfahrung nicht irrelevant! Für angehende Systemadministratoren
empfiehlt es sich ein kleines LAN zu haben, in dem man mal etwas experimentieren
kann. Dies ist vergleichbar mit der privaten Homepage mit der viele Webdesigner
angefangen haben und sie nicht selten auch nebenbei weiterbetreiben. Es
ist einfach etwas ungeschickt verschiedene Denial-of-Service Attacken wie
beispielsweise die Socket-Bombe auf dem Zentralrechner der Firma auszuprobieren
;-)
Gefahren für einen Unix-Host
Ein Unix-Host ist an einigen Stellen verwundbar, das streitet niemand ab.
Ich kann auch nicht versprechen hier alle aufzählen zu können,
doch die bekanntesten dürften vertreten sein:
-
den Host vom Netz trennen
-
den Host handlungsunfähig machen
-
den Host als Plattform für andere Attacken missbrauchen
-
den Host als Authentifikationsmittel missbrauchen
-
die Arbeit auf dem Host stören
-
die Benutzer des Hosts ausspionieren
Während die ersten beiden Attacken ohne direkten Zugriff auf den Host
erfolgen können, benötigt der Angreifer für die weiteren
Attacken einen gültigen Account (also Benutzername und Passwort) auf
dem Host, der als Mittel des Angriffs fungieren soll. Um die Arbeit auf
dem Host zu stören benötigt der Angreifer zwar nicht zwingend
einen Account auf dem Host, doch ist dies häufiger der Fall.
Attacken, die den Host vom Netz trennen und/oder handlungsunfähig
machen wird häufig als Denial-of-Service-Attacken (kurz DoS-Attacken)
bezeichnet. Wie der Name schon
andeutet, wird jemandem (nämlich den
regulären Benutzern) ein Dienst (Service) verweigert. Dies kann entweder
bei einem Webserver die Möglichkeit Seiten abzurufen sein, bei FTP-Servern
die Möglichkeit Dateien up- oder downzuloaden, oder aber die Infrastruktur
eines gesamten Netzes in Mitleidenschaft zu ziehen. Letzteres ist beispielsweise
der Fall, wenn ein Router oder Proxy-Server ausser Gefecht gesetzt wird.
Attacken, deren Ziel es ist den Host für andere Attacken
zu verwenden sind dagegen schon etwas anspruchsvoller. Während für
DoS-Attacken meist Programme exisieren, die nur noch die Angabe von einigen
Parametern erfordern, benötigt ein Angreifer für die weiteren
Attacken einen Zugang zu dem Host. Der am häufigsten verwendete Weg
dürften die trojanischen Pferde sein, wobei auch Telnet-Accounts (durch
leicht zu erratenden Passwörter oder durch Social Engineering ergattert)
ein willkommenes Werkzeug sind.
Wird Ihr Host für weitere Attacken eingesetzt, so kann es
leicht vorkommen, dass Ihnen die Schuld dafür angelastet wird. Vor
allem in Fällen, in denen Ihr Host zur Authentifikation bei anderen
Systemen verwendet wird, wird man Ihnen schlechte Sicherheitsmassnahmen
vorwerfen - der gute Ruf ist dann hinüber.
Im den folgenden Kapiteln sollen die einzelnen Angriffstechniken
erlätert werden. Falls jetzt jedem Administrator das Herz in die Hose
rutschen sollte, weil hier die Methoden zum Angreifen von Rechnern, die
zwar allgemein bekannt sind, aber trotzdem häufig für ungefährlich
eingeschätzt werden, kann ich nur sagen: wenn jemand einen Host angreifen
will, hat er viele Möglichkeiten an das Wissen dazu zu kommen. Die
freundlichen Sprüche die "Bitte missbrauchen Sie dieses Wissen nicht"
sind zwar nett, aber werden wohl kaum jemanden abschrecken. Gute und genaue
Anleitungen und Erläuterungen der Methoden jedoch erlauben es sich
besser dagegen zu schützen, und dieses Ziel ist auch der Sinn dieser
Seite.
Offene Ports
Der Begriff offene Ports verleitet häufig zu einer falschen Ansicht
der Tatsachen. Falls man sich nun denkt, ein Host der einige Ports offen
hat, kann leichter angegriffen werden als einer, der keine Ports offen
hat, mag man zwar generell nicht unrecht haben, doch ist die Quantität
nur bedingt ein Massstab zur Bewertung. Zuerst einmal: ein Port ist offen.
Diese Aussage ist nicht präzise genug. Sie will ausdrücken, dass
auf einem bestimmten Port ein Programm als Server-Prozess auf Anfragen
von Aussen wartet. Daran gibt es im Prinzip nichts auszusetzen. Die Gefahr
besteht darin, dass ein solches Programm Fehler enthalten kann, die der
Angreifer auszunutzen weiss. Nach einigen Überlegungen scheint es
auch einleuchtend, dass die Zahl der möglicherweise fehlerhaften Programme
mit der Zahl der Programme steigt. Jedoch vergisst man häufig, dass
es sehr wohl Programme geben kann, die keine Buffer Overflows (1)
zulassen, keine Hintertüren haben und keinen direkten Zugriff auf
das Sytem ermöglichen. Solche Programme auf Ports laufen zu haben
ist nicht unverantwortlich, sondern der Sinn eines Servers! Wenn man aus
Angst, dass der Webserver fehlerhaft sein könnte einen Host ins Internet
stellt, der keine Ports offen hat, ist er nur Ballast (es sei denn, er
fungiert als Router, Gateway oder dergleichen).
Die Philosophie "je mehr Dienste laufen, desto mehr Dienste können
gestört werden und desto weniger Dienste sind für Benutzer benutzbar"
zeigt schon nach wenigen Augenblicken ein paar Ungereimtheiten: wenn ein
Dienst gar nicht erst angeboten wird, kann er auch nicht verwendet werden.
Was ich zu verdeutlichen versuche ist, dass es der Sinn eines Servers
ist, mit dem Benutzern zu interagieren und deren Wünsche zu erfüllen.
Ob er auch die Wünsche des Angreifers erfüllt ist eine Frage
der Programmierung des Servers, nicht der Tatsache dass er existiert!
Langer Rede kurzer Sinn: alle nichtbenötigten Ports sollten
geschlossen werden und die angebotenen Dienste sollten sorgfältig
ausgewählt sein (sowohl die Art der Dienste als auch die Programme
die diese Dienste erfüllen). Eine Selbstmordhost wüde zum Beispiel
dem Benutzer den Dienst anbieten eigene PERL-Skripte für die CGI-Unterstützung
einer Homepage auf dem Server laufen zu lassen. Dies ist der Dienst. An
sich schon gefärlich, oder? Nun zum Programm: wie wäre es, wenn
es sätliche Programme die der Benutzer uploaded ohne Bemerkung von
wem sie sind oder woher sie kommen mit dem SUID-Bit versetzt und als Root
laufen lassen würde. Blöde, oder? Sie sollten dafür sorgen,
dass Dienste und Programme vor Inbetriebnahme genau durchdacht werden und
nur mit den nötigen Rechen laufen. Die Regel zur Vergabe von Rechten:
so wenig wie möglich und so viel wie nötig.
Wie man Ports verschliesst lesen Sie unter Schutz
gegen Angreifer.
Trojanische Pferde und fremder Code
Trojanische Pferde gibt es auch für Unix! Natürlich denkt man
bei dem Begriff trojanische Pferde zuerst an Back Orifice, NetBus oder
die T-Online Power Tools. Sie zielen auf Windows-Rechner, weil hier die
Rechtevergabe es in der Regel jedem erlauben die Startdateien zu manipulieren
und daher der fremde Code bei jedem Booten ausgeführt wird. Unter
Unix kann nur Root die Startdateien manipulieren, aber das ist ja insofern
nicht so schlimm, als das viele Programme als Root ausgeführt oder
installiert werden müssen. So ist es zum Beispiel nicht schwer für
ein Makefile unter dem Target "install" rechlich Unfug anzustellen. Vom
offensichtlichen Kernel überschreiben bis hin zum Austauschen des
Telnet-Servers gegen ein eigenes Exemplar, das eine Hintertür hat
die dem Benutzer Root-Rechte beschafft - vieles ist denkbar. Zusätzliche
Programme fallen hierbei eher auf, da sie unbekannt sind und ein Systemadministrator
in der Regel weiss welche Dienste laufen. Nach einem netstat
-a wird er sehen ob da etwas lauscht das dies nicht soll. Falls
aber reguläre Programme einfach ausgetauscht werden, fällt dies
weniger auf. Hierzu gibt es Programme, die Checksummen erstellen und feststellen,
ob sich Dateien verändert haben. Mehr zu diesen Programme finden Sie
unter
Schutz gegen Angreifer.
Fremder Code ist ein schwammiger Begriff. Trojanische Pferde fallen
darunter, aber auch Viren bzw. durch Sicherheitslücken ausgeführte
"Benutzerdaten". Dies kann entweder direkt geschehen, indem ein Perl-Script
zum Beispiel mit Systemaufrufen eine Datenbank durchsucht (z.B. mit
grep)
und die Benutzerdaten Sonderzeichen enthalten, die von der Shell interpretiert
werden (beispielsweise
| oder &&).
Andere Sicherheitslücken entstehen durch Buffer Overflows (1).
Hierbei wird ein Puffer mit mehr Daten beschrieben, als hineinpassen. Wenn
der Angreifer den Quelltext des Programmes das er damit angreift zur Verfügung
hat, kann er Angriffe ersinnen, die dies zu seinem Nutzen tun. Buffer Overflows
hingegen sind vermeidbare Programmierfehler und werden bei Programmen für
Unix zum Teil schnell entdeckt, sofern der Quelltext frei verfügbar
ist.
Denial-of-Service Attacken
Das Ziel der Denial-of-Service Attacken ist wie der Name schon sagt das
Behindern des Hosts an der Erfüllung von Diensten. Dies kann auf mehreren
Ebenen erfolgen. Entweder wird der ganze Host vom Netz getrennt (zum Beispiel
durch Ping-flooding), oder aber er wird durch einen Fehler im Betriebssystem
oder einer Anwendung gecrasht (zum Beispiel mit teardrop, bonk oder land).
Die dritte Möglichkeit besteht darin einen Dienst gezielt zu stören
(zum Beispiel Webserver durch SYN-flooding). In jedem dieser Fälle
ist das Ziel anderen die Arbeit mit dem Host zu erschweren oder sie ganz
zu unterbinden. Bei Systemcrashs werden auch lokale Dienste gestört
und es kann Datenverlust auftreten, wenn ungeschriebene Caches verloren
gehen. Ein Beispiel für einen lokalen Fehler der bei Linux-Systemen
zu grossen Problemen (kernel panic) führen kann ist die Socket-Bombe.
Der Fehler der hier ausgenutzt wird ist in der garbage-collection des Netzwerksubsystems.
Kurz: es werden mehr sockets erstellt als erstellt werden können.
Den Quelltext hierzu findet man bei Suchmaschinen mit den Stichworten "socket-bomb",
"garbage.c" oder "garbage collection".
Für Denial-of-Service Attacken benötigt der Angreifer
in der Regel keinen Account auf dem Host den er angreifen will, sondern
nur die IP-Adresse. Anders bei Denial-of-Service Angriffen, die wie die
Socket Bombe lokal sind, hierzu ist selbstverständlich ein gültiger
Benutzername und Passwort notwendig.
Über DoS und DDoS (Distributed DoS) Attacken gibt es schon
sehr viele Texte, interessante Informationen finden Sie auch in (2).
Bandbreite und Probleme damit
Die Bandbreite ist der Durchsatz der Verbindung zum Internet. Probleme
können auftreten, wenn ein oder mehrere Angreifer dafür sorgen,
dass Ihnen diese Bandbreite ausgeht. Gemeint ist Ping-flooding bzw. SYN-flooding.
Diese Begriffe gehüren zwar in den DoS bzw. DDoS-Bereich, doch haben
sie gerade in letzter Zeit für Aufsehen gesorgt (amazon, e-bay, yahoo).
Der Sachverhalt beim Ping-flooding ist ganz einfach: ein Ping (ein ICMP-Paket
das zur Diagnose von Netzwerkproblemen abgeschickt wird) wird von dem Zielhost
mit einem Antwortpaket gleicher Grösse beantwortet. Wenn nun mehr
Pings eingehen, als der Host beantworten kann, kann er sich nicht mehr
um die anderen Dienste, die seinen eigentlichen Sinn ausmachen, kümmern.
Hierbei hat natürlich nur der Angreifer eine Chance, der über
eine grössere Bandbreite verfügt, als der Angegriffene. Da dies
oft etwas schwierig zu bewerkstelligen ist, haben sich Angreifer das Verfahren
der DDoS Attacke zu Nutze gemacht: sie installieren auf vielen Rechnern
mit geringerer Bandbreite trojanische Pferde, die auf Befehl an eine Adresse
pings senden. Hat man nun ein Ziel mit 10 MBit/s und 200 Angreifer mit
ISDN, so kommt man auf mehr Bandbreite (nämlich rund 12,5 MBit/s)
und kann dieses Ziel lahmlegen. Na und, 200 Angreifer sind viel meinen
Sie? Und was ist, wenn ein Angreifer Ihr System kompromitiert und dazu
missbraucht? Wenn eine Firma eine Netzanbindung von 10 MBit/s hat und der
oder die Angreifer entsprechend koordiniert 20 dieser Verbindungen auf
ein Ziel ansetzen können - schon geht es um Grössenordnungen
von 200 MBit/s. Und das beste (für die Angreifer): die Pakete gehen
von den missbrauchten Hosts aus und auf sie fällt zuerst der Verdacht.
Mit SYN-Floodern verhält es sich nun recht ähnlich.
Zuerst ein kleiner Ausflug zum Netzwerkprotokoll TCP: eine Verbindung wird
nach dem three-way-handshake aufgebaut:
-
Der Client fragt den Server nach einer Verbindung
-
Der Server gibt dem Client eine Antwort und bittet seinerseits um eine
Verbindung
-
Der Client bestätigt diese Anforderung und startet dann die Datenübertragung.
Das SYN-Paket ist der erste Schritt: es fragt nach einer Verbindung. Nun
gibt es Programme, die viele dieser Pakete (und nur diese Pakete) losschicken.
Das Ziel denkt nun, dass sich viele Clients verbinden wollen - und da ist
der Trugschluss! Sie warten also brav bis zum timeout auf die weiteren
Schritte und blockieren damit die Verbindung für andere, reguläre
Clients. Diese Angriffe können ebenfalls auf mehrere Angreifer verteilt
werden.
Passwortsicherheit
Das Kapitel Passwortsicherheit lässt sich mit wenigen Worten abfertigen:
Passwärter sind nur sicher, solange sie geheim bleiben. Wählt
man nun zu einfache Passwörter (z.B. die Vornamen der Benutzer) so
können diese mit wenig Aufwand geknackt werden - der Host steht dem
Angreifer für weitere Angriffe offen. Die Annahme, ein Host auf dem
Telnet laufen würde wäre unsicherer als einer auf dem kein Telnet
läft, ist zwar insofern nicht falsch, als dass nur durch die Möglichkeit
sich einzuloggen auch die Möglichkeit erratene Passw¨rter zu verwenden
gegeben ist. Aber: wenn niemand die Passwörter kennt und der Server
frei von Fehlern ist (Buffer Overflows etc.) ist nichts dagegen einzuwenden.
Viel richtiger ist also: ein Host auf dem "schlechte" Passw¨rter verwendet
werden ist zusammen mit einem Telnet-Dienst unsicher.
Über das Ausdenken guter Passwörter sind ebenfalls schon
viele Dokumente verfasst worden - schauen Sie einfach mal am Ende dieser
Seite nach.
Fortgeschrittene Techniken
Zu den fortgeschrittenen Techniken gehören IP-spoofing, IP-Hijacking
und das Ausnutzen von Vertrauensbeziehungen von Hosts untereinander. Diese
Techniken erfordern meist gut Kenntnisse der Ziele und der Zielbetriebssysteme.
Es gibt ausser den hier genannten Techniken noch zahlreiche weitere Techniken,
die als fortgeschritten bezeichnet werden sollten, doch werde ich mich
diesen dreien zuwenden, um den Rahmen des Textes nicht zu überstrapazieren.
Das IP-spoofing ist vom Prinzip her noch einfach: die Quell-IP-Adressen
eines Paketes wird vera¨ndert, so dass das Ziel annimmt, es käme
von einem anderen Host. Der Nachteil dabei, wenn man nur die Quell-IP-Adresse
des Paketes ändert ist, dass man keine Antwort bekommen wird (da dass
Paket an den scheinbaren Sender aber wirklichen Besitzer der IP-Adresse
reroutet wird). Will man eine E-Mail mit einem gefälschteb Absender
verschicken, kann man sich dieses Verfahren zu Nutze machen, indem man
"errät", was der Zielhost (genauer: der Mail-Dienst des Zielhosts)
als nächstes hören will. Man geht dann davon aus, dass alles
erfolgreich verläft und handelt als hätte man eine entsprechende
Rückmeldung des Hosts bekommen. Dies geht natürlich nur, wenn
es keinen Host gibt, der auf die Pakete antwortet. Hierzu stehen die DoS-Attacken
zur Verfügung. Wenn der Host, dem die Adresse wirklich gehört,
gerade beim neustarten ist, kann er nicht antworten. Und wenn er nicht
da ist, die Pakete aber trotzdem geroutet werden, kommt erst nach einiger
Zeit der timeout zum Tragen und der Vorgang würde abgebrochen werden
- doch ist bis dahin die E-Mail schon längst mit falscher Herkunft
verschickt.
Eine weitere Möglichkeit ist Hostnamen zu spoofen, indem man einen
ganzen DNS-Server ersetzt ...
Das IP-Hijacking ist dagegen schon erheblich komplizierter. Das Ziel
dabei ist es, eine bestehende Verbindung zu übernehmen (to hijack,
engl: entführen). Dies wird versucht, wenn beispielsweise eine Athentifizierung
stattgefunden hat (z.B. durch ein Passwort) und die Verbindung somit schon
ohne weitere Abfragen direkten Zugriff auf das Zielsystem verspricht. Hierbei
gibt es allerdings einige Probleme: die IP-Sequenznummer muss erraten werden.
Hierbei handelt es sich um eine 32 bittige Zahl, die bei jedem Paket um
einen bestimmten Betrag erhöht wird (meist 50 oder 100). Der Gedanke
dabei ist, dass die Pakete nicht verwechselt werden können, denn angenommen
unser Host versendet 100 Pakete pro Sekunde, so ist die Zahl erst nach
etwa 5 Tagen wieder auf etwa gleicher Höhe - so lange schwirrt kein
Paket herum, egal wie schlecht es geroutet wird. Nun, hat man die Sequenz
erraten, muss man noch wie beim IP-Spoofing die "original"-Quelle aus dem
Weg schaffen. Wie man sieht erfordert IP-Hijacking gute Kenntnisse der
Systeme, doch sind die Effekte auch nicht zu unterschätzen!
Das Ausnutzen von Vertrauensbeziehungen kann entweder bei Authenifizierung
durch die IP-Nummer durch IP-Spoofing erreicht werden, oder aber bei direktem
Zugriff auf das eine "Opfer"-System durch den Effekt den man vom Proxy-Server
kennt:
/-----------\ /--------\ /--------\
| Angreifer | ----- > | Host A | -------------> | Host B |
\-----------/ \--------/ \--------/
Der Angreifer tut so als wäre er regulärer Benutzer von Host
A, in Wahrheit hat sich der Angreifer einfach nur auf Host A eingeloggt
und operiert von dort aus.
Schutz gegen Angreifer
Der Schutz gegen Angreifer ist ein wichtiges Kapitel. Ich werde hier zu
jeder beschriebenen Attacke eine Schutzmöglichkeit sofern vorhanden
aufzeigen. Sie sollten auf jeden Fall unter "weiterführende Literatur"
am Ende der Seite die Texte bei rootshell durchlesen, falls Sie die Aufgabe
haben ein System effektiv zu sichern. Es ist zwar viel Lesestoff, aber
erstklassiger Natur.
Zu den Möglichkeiten sich zu schützen:
Offene Ports
-
Hier sollten nur die benötigten Dienste angeboten werden, nichtbenötigte
sollten eingestellt werden. Dies geschieht entweder dadurch den entsprechenden
Server nicht zu starten (z.B. beim Webserver), oder in der Datei /etc/inetd.conf
den INet-Deamon anzuweisen nur die benötigten Dienste zuzulassen.
Bei den Diensten, die angeboten werden müssen, sollten immer die aktuellsten
Versionen der Server eingesetzt werden und die Mailinglisten und Security-Foren
in denen über Fehler in diesen berichtet wird, genau verfolgt werden.
Trojanische Pferde und fremder Code
-
Genrell: nur Programme ausführen von denen man sicher ist, wo sie
herkommen. Vor allem als Root aufpassen! Um sich gegen das Austauschen
der Software (siehe das Beispiel mit Telnet) zu schützen, sollten
Programme eingesetzt werden, die Checksummen von allen wichtigen Programmen
erstellen, und regelmässig überprüfen, ob Veränderungen
stattgefunden haben. Dies ist nat¨rlich nur dann sinnvoll, wenn sichergestellt
ist, dass sich das System in einem sicheren Zustand befindet - hat sich
schon was eingenistet wird es später nicht gefunden. Ein Programm,
das diese Aufgaben erfüllt ist tripwire.
Denial-of-Service Attacken
-
Immer die neusten Software-Releases verwenden bzw. alle relevanten Patches
installieren. Wird ein Problem gefunden (z.B. bei teardrop), so gibt es
oft innerhalb weniger Stunden / Tage Patches für alle gängigen
Systeme. Hier gilt ebenfalls: Security-Mailinglisten und -Foren verfolgen
Bandbreite und Probleme damit
-
Gegen Ping-Flooder kann man sich nicht richtig schützen. Gegen Angriffe
durch SYN-Flooder gibt es Möglichkeiten auf Kernel-Ebene. Sie sollten
jedoch Ihr System so einrichten, dass es keine anderen Hosts beeinträchtigen
kann (z.B. durch Spam-Mails). Falls niemand auf Ihrem System trojanische
Pferde hinterlassen kann um DDoS-Attacken durchzuführen, haben sie
unter Umständen vielen anderen Hosts geholfen.
Passwortsicherheit
-
Einfach: sichere Passwörter benutzen und diese nicht weitergeben.
Wichtig: niemandem weitergeben! Vor allem niemanden, die sich als "Leute
von der Abteilung Systemadministration" ausgeben und mal eben ein Passwort
brauchen um was zum Laufen zu bringen ;-)
Fortgeschrittene Techniken
-
Schwierig ... am besten über die konkreten Themen in den Angaben für
weiterführende Literatur nachforschen
Noch ein guter Tipp: immer auf dem neuesten Stand bleiben ist enorm wichtig.
Hierzu kann ich nochmals nur Foren oder Mailinglisten ans Herz legen.
Quellen und weiterführende Literatur
(1) "Buffer
Overflows - eine Einführung". Dieser Text stammt ebenfalls von
mir und ist auf meiner
Homepage
zu finden
(2) "hacker's
guide" von anonymous. Dieses Buch informiert recht gründlich über
das Internet und die verschiedenen Aspekte (Protokolle, Entstehung, etc.)
sowie über einige Aspekte des Hackens inklusive einiger Grundtechniken.
ISBN 3-8272-5460-4.
(3) http://rootshell.com/beta/documentation.html
(4) http://www.securityfocus.com/
(5) http://www.cert.org/
(6) http://phrack.infonexus.com/
Hauptseite