UNIX - Hostsicherheit
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änlich 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 uüber die
konkreten Tehmen 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/
Letztes Update: 19. Oktober
2K
Maverick <maverick@dragonriders.de>