DDoS-Angriff melden und anzeigen: Beweise sichern, Bericht schreiben

Ein DDoS-Angriff ist in Österreich und in Deutschland eine Straftat, und trotzdem verlaufen die meisten Meldungen ergebnislos. Der Grund ist selten die Rechtslage. Er ist fast immer der Zeitpunkt: Die Beweise, auf die es ankommt, existieren nur während des Angriffs. Zählerstände im Kernel, halb offene Verbindungen, die Protokollverteilung auf der Leitung und die Verkehrsgrafik in Minutenauflösung sind eine Stunde später geglättet, überschrieben oder beim nächsten Neustart vollständig weg. Wer erst am nächsten Morgen anfängt zu schreiben, meldet einen Vorfall, den niemand mehr nachvollziehen kann, und bekommt genau die Antwort, die eine solche Meldung verdient.

Dieser Beitrag ist deshalb zuerst eine Anleitung zum rechtzeitigen Sichern und erst danach eine zum Melden. Er zeigt mit konkreten Befehlen, was Sie in den ersten zehn Minuten wegschreiben, warum die Quelladresse aus Ihrem Paketmitschnitt in aller Regel nicht dem Täter gehört, in welcher Reihenfolge Sie sich an den eigenen Anbieter, an die Missbrauchsstelle des Quellnetzes und an die Polizei wenden, was ein Missbrauchsbericht enthalten muss, damit er überhaupt bearbeitet wird, und was realistisch dabei herauskommt. Die Mustervorlage am Ende können Sie übernehmen und ausfüllen.

Eine Einschränkung gleich zu Beginn, und sie steht auch in der FAQ: Dieser Beitrag beschreibt den Weg und gibt den Gesetzesstand wieder. Er ist keine Rechtsberatung und ersetzt im Einzelfall keine anwaltliche Prüfung. Und er nennt bewusst keine Telefonnummern, keine Behördenadressen und keine Fristen. Eine falsche Behördenadresse ist schlimmer als keine, deshalb steht hier stattdessen, wie Sie die für Sie zuständige Stelle selbst finden.

Warum die meisten DDoS-Meldungen im Sand verlaufen

Eine Meldung wird aus zwei Gründen nicht bearbeitet: Sie kommt zu spät, oder sie enthält zu wenig. Beides hängt zusammen, denn was zu spät kommt, kann gar nichts mehr enthalten.

Die Empfängerseite arbeitet fast immer mit Ticketsystemen, die jede eingehende Meldung automatisch einsortieren. Ein Text wie "Ihr Kunde hat mich heute angegriffen, bitte unternehmen Sie etwas" enthält keine maschinell verwertbare Angabe: keine Zeit, keine Adresse, keinen Port, kein Protokoll. Er landet in der Schleife für Rückfragen und stirbt dort. Ein Bericht mit Zeitstempel in UTC, betroffener Adresse samt Port, Quelladresse, Protokoll, gemessenem Umfang und einem angehängten Rohdatenauszug wird dagegen zugeordnet, weil jede dieser Angaben gegen die Protokolle des Empfängers geprüft werden kann.

Der zweite Grund ist die Haltbarkeit der Daten auf der Gegenseite. Wie lange ein Anbieter Verbindungsdaten aufbewahrt, ist von Land zu Land und von Anbieter zu Anbieter verschieden, und Sie können sich nicht darauf verlassen, dass in einem Monat noch etwas da ist. Jeder Tag, den Sie mit dem Bericht warten, verkleinert die Menge dessen, was der Empfänger überhaupt noch nachsehen kann. Bei Angriffen, die in Wellen über Tage laufen, ist das der praktische Unterschied zwischen einer Bestätigung und einem Schulterzucken.

Und der dritte Grund ist ein inhaltlicher: Sehr viele Meldungen zeigen die falsche Partei an. Das ist kein Nachlässigkeitsfehler, sondern eine Folge der Technik, und es ist der Abschnitt, den Sie in diesem Beitrag am wichtigsten nehmen sollten.

Die ersten zehn Minuten: was Sie sichern, bevor es weg ist

Messen statt schrauben, in dieser Reihenfolge. Jede Minute, die Sie mit dem Anpassen von Firewall-Regeln verbringen, ist eine Minute, in der Sie keine Beweise sichern. Und ein Neustart löscht alle Zähler, alle Verbindungszustände und jeden Beweis auf einmal, während die Last nach wenigen Sekunden wieder da ist.

Warum jede Minute Beweismaterial vernichtet

Die Werte, die einen Angriff belegen, liegen an vier verschiedenen Orten mit vier verschiedenen Lebensdauern. Die Zähler in /proc und in ip -s link laufen seit dem letzten Start und sind nach einem Neustart auf null. Die Sockettabelle in ss zeigt einen Momentzustand, der sich im Sekundentakt ändert und nach dem Angriff nicht rekonstruierbar ist. Die Zählerstände Ihrer Firewall überleben ein Neuladen des Regelwerks nicht. Und die Verkehrsgrafik des Anbieters wird mit zunehmendem Alter auf gröbere Mittelwerte zusammengefasst, sodass eine Spitze von zwanzig Minuten irgendwann in einem Tagesmittel verschwindet.

Legen Sie deshalb als Erstes ein Verzeichnis an und schreiben Sie alles hinein, statt einzelne Werte im Terminal zu lesen und wieder zu vergessen.

V=/root/vorfall-$(date -u +%Y%m%d-%H%M)
mkdir -p "$V" && cd "$V"

Der Zeitstempel, ohne den alles andere wertlos ist

Jede Angabe in Ihrem Bericht wird mit Protokollen von Empfängern in anderen Zeitzonen verglichen. Eine Uhrzeit ohne Zeitzone ist deshalb keine Angabe, sondern eine Rückfrage. Schreiben Sie Beginn und Ende in UTC, im Format nach ISO 8601, und halten Sie zusätzlich fest, ob die Systemuhr überhaupt synchronisiert war.

date -u --iso-8601=seconds > 01-zeit-utc.txt
timedatectl > 02-zeitquelle.txt
uptime > 03-uptime.txt

timedatectl zeigt in der Zeile "System clock synchronized" an, ob die Uhr per NTP nachgeführt wird. Steht dort "no", ist Ihre Zeitangabe nur so genau wie die Abweichung Ihrer Uhr, und das gehört in den Bericht. Eine um vierzig Minuten falsch gehende Uhr führt dazu, dass der Empfänger in seinen Protokollen an der falschen Stelle sucht und nichts findet.

Zählerstände aus dem Kernel

Diese fünf Befehle sind der Kern der Beweissicherung. Sie dauern zusammen weniger als eine halbe Minute und liefern die Zahlen, nach denen jede Missbrauchsstelle und jeder Anbieter zuerst fragt.

ip -s link > 10-interfaces.txt
ss -s > 11-sockets.txt
ss -tn state syn-recv | head -200 > 12-syn-recv.txt
nstat -az > 13-nstat.txt
sar -n DEV 1 10 > 14-paketrate.txt
cat /proc/net/softnet_stat > 15-softnet.txt
dmesg -T | tail -200 > 16-kernel.txt

Was diese Dateien belegen: ip -s link liefert die Spalten dropped und overrun je Schnittstelle, also die Pakete, die der Kernel nicht mehr angenommen hat. ss -s gibt die Gesamtzahl der Sockets je Zustand, ss -tn state syn-recv die halb geöffneten Verbindungen; ein fünfstelliger Wert dort ist ein SYN-Flood. nstat -az gibt sämtliche Netzwerkzähler des Kernels aus, auch die auf null stehenden, darunter TcpExtListenOverflows, TcpExtListenDrops und TcpExtSyncookiesSent. Die zweite Spalte in /proc/net/softnet_stat zählt je CPU die Pakete, die verworfen wurden, weil die Empfangswarteschlange voll war. Und sar -n DEV 1 10 misst zehn Sekunden lang Pakete und Bytes pro Sekunde je Schnittstelle, woraus sich die mittlere Paketgröße ergibt.

Die mittlere Paketgröße ist die eine Zahl, die die Angriffsart verrät: Bytes geteilt durch Pakete. Unter 100 Byte deutet auf einen Protokollangriff mit kleinen Paketen, über 1.000 Byte auf einen Verstärkungsangriff mit großen Antworten. Nennen Sie sie im Bericht, dann muss der Empfänger sie nicht selbst ausrechnen.

Die Zählerstände der Firewall

Der Regelsatz allein sagt nichts aus. Interessant ist, wie viele Pakete jede Regel getroffen hat, denn das ist Ihr eigener Nachweis, dass Sie den Verkehr verworfen und nicht einfach ignoriert haben.

nft list ruleset > 20-nft-ruleset.txt
nft -j list ruleset > 21-nft-ruleset.json
nft list counters > 22-nft-counters.txt
iptables-save -c > 23-iptables-counter.txt
cat /proc/sys/net/netfilter/nf_conntrack_count > 24-conntrack-anzahl.txt
cat /proc/sys/net/netfilter/nf_conntrack_max > 25-conntrack-max.txt

Ein wichtiger Vorbehalt: nft list ruleset zeigt Zählerstände nur dort an, wo die Regel ein counter-Statement enthält. Steht in Ihren Regeln kein counter, bekommen Sie nur den Regeltext ohne Zahlen, und der beweist nichts. Wer Angriffe erwartet, baut das counter-Statement vorsorglich in die Verwurfsregeln ein, denn nachträglich einfügen lässt es sich nicht. iptables-save -c liefert dieselbe Information für ältere Regelwerke, jeweils als [Pakete:Bytes] vor der Regel. Die beiden conntrack-Werte zeigen im Vergleich, ob die Verbindungsverfolgungstabelle voll gelaufen ist, was sich im Kernelprotokoll als nf_conntrack: table full, dropping packet wiederfindet.

Der Paketmitschnitt, begrenzt und mit Grund

Der Paketmitschnitt ist das einzige Beweismittel, das Quelladressen, Quellports und Nutzlast enthält. Ohne ihn können Sie keine einzige Missbrauchsmeldung schreiben, weil Sie die Gegenstelle gar nicht benennen können. Er ist zugleich das einzige, das Ihre Lage verschlimmern kann, wenn Sie ihn unbegrenzt laufen lassen: Ein Mitschnitt auf einer gesättigten Leitung füllt die Platte in Minuten und kostet zusätzliche Rechenzeit, die Sie gerade nicht haben.

tcpdump -D
IF=eth0
tcpdump -ni "$IF" -s 128 -c 20000 -w 30-mitschnitt.pcap

Die drei Schalter, auf die es ankommt: -s 128 schneidet jedes Paket nach 128 Byte ab, was für Kopfdaten und den Anfang der Nutzlast reicht und den Mitschnitt klein hält. -c 20000 beendet den Mitschnitt nach 20.000 Paketen, statt ihn laufen zu lassen. -w schreibt das Binärformat, nicht die Textausgabe, denn nur das Binärformat kann der Empfänger selbst auswerten. tcpdump -D listet vorab die verfügbaren Schnittstellen auf, falls Sie den Namen nicht sicher wissen.

Bei einem Angriff in Wellen ist ein Ringpuffer besser, weil er über einen längeren Zeitraum mitschreibt und dabei eine feste Obergrenze auf der Platte einhält:

tcpdump -ni "$IF" -s 128 -W 3 -C 50 -w 31-ring.pcap

-C 50 begrenzt jede Datei auf rund 50 Millionen Byte, -W 3 hält höchstens drei davon vor und überschreibt dann die älteste. Maximal belegt der Mitschnitt damit rund 150 Megabyte, egal wie lange er läuft.

Für den Bericht brauchen Sie danach zwei Auswertungen aus dem Mitschnitt, und zwar lesend, nicht neu mitschneidend:

tcpdump -nr 30-mitschnitt.pcap | head -40 > 32-auszug.txt
tcpdump -nr 30-mitschnitt.pcap | awk '{print $3}' | sed 's/[.][0-9]*$//' \
  | sort | uniq -c | sort -rn | head -20 > 33-top-quellen.txt

Die erste Datei ist der lesbare Auszug, den Sie in den Text des Berichts stellen: vierzig Zeilen genügen, um das Muster zu zeigen. Die zweite ist die Häufigkeitsliste der Quelladressen. Genau diese Liste ist der Grund, warum der nächste Abschnitt existiert, denn sie verleitet dazu, die oberste Adresse anzuzeigen.

Auszüge aus dem Zugriffsprotokoll

Bei einem Angriff auf der Anwendungsebene liegt der Beweis nicht im Netz, sondern im Zugriffsprotokoll des Webservers. Schneiden Sie den Zeitraum heraus, statt die ganze Datei anzuhängen, und liefern Sie zusätzlich die beiden Verteilungen, die das Muster zeigen.

journalctl --utc --since "2026-09-28 20:00" --until "2026-09-28 21:00" \
  -o short-iso > 40-journal.txt
awk '$4 >= "[28/Sep/2026:20:00:00" && $4 <= "[28/Sep/2026:21:00:00"' \
  /var/log/nginx/access.log > 41-zugriffe.txt
awk '{print $1}' 41-zugriffe.txt | sort | uniq -c | sort -rn | head -30 > 42-top-ips.txt
awk '{print $9}' 41-zugriffe.txt | sort | uniq -c | sort -rn > 43-statuscodes.txt
awk -F'"' '{print $6}' 41-zugriffe.txt | sort | uniq -c | sort -rn | head -20 > 44-agents.txt

Im kombinierten Protokollformat von nginx und Apache steht die Quelladresse im ersten Feld, der Zeitstempel im vierten, der Statuscode im neunten und die Kennung des Clients im sechsten der von Anführungszeichen getrennten Abschnitte. Drei bis fünf Beispielzeilen mit dem wiederkehrenden Anfragemuster genügen im Bericht, die vollständigen Dateien gehören ins Archiv. Wie Sie systemd-Protokolle gezielt nach Zeitraum, Dienst und Priorität filtern, steht ausführlich in journalctl-Logs analysieren.

Die Verkehrsgrafik des Anbieters, und warum ein Bildschirmfoto weniger wert ist

Die Verkehrsgrafik in Ihrem Kundenbereich ist das einzige Beweismittel, das außerhalb des angegriffenen Systems gemessen wurde. Das macht sie in zweierlei Hinsicht stark: Sie zeigt auch den Verkehr, der Ihren Server gar nicht mehr erreicht hat, weil die Leitung davor gesättigt war oder weil die Filterung im Netz ihn bereits verworfen hat, und sie stammt nicht von der Partei, die etwas behauptet.

Ein Bildschirmfoto davon ist trotzdem das schwächste Format, das Sie liefern können, und zwar aus vier Gründen. Erstens enthält ein Bild keine Zahlen, die jemand nachrechnen kann: Wer aus der Kurve 400 Gbit/s ablesen will, muss die Achsenbeschriftung interpretieren. Zweitens enthält es keine Zeitzone, sondern nur die Beschriftung, die Ihr Browser gerade angezeigt hat. Drittens enthält es keine Auflösung: Eine Kurve, die aus Fünf-Minuten-Mittelwerten besteht, zeigt eine Spitze von 900 Gbit/s über zwanzig Sekunden als harmlose 60 Gbit/s. Und viertens ist ein Bild in einem Ticketsystem nicht durchsuchbar und nicht mit anderen Protokollen korrelierbar.

Besser ist in dieser Reihenfolge: ein Rohdatenexport der Messwerte mit Zeitstempel und Einheit, falls der Kundenbereich einen anbietet; die von Ihnen selbst gemessenen Werte aus sar und ip -s link, die sich mit der Grafik decken; und das Bildschirmfoto zusätzlich als Illustration, mit ausgeschriebener Zeitzone und Angabe der Auflösung im Begleittext. Wenn Sie nur das Bild haben, schreiben Sie ausdrücklich dazu, in welcher Zeitzone die Achse beschriftet ist und über welches Intervall gemittelt wurde. Ohne diese beiden Angaben ist die Grafik als Beleg für eine Spitzenlast nicht verwendbar.

Alles in ein Archiv, mit Prüfsummen

Zum Schluss friert eine Prüfsummenliste den Stand ein. Das ist kein juristischer Beweis der Unverändertheit, aber es beantwortet die naheliegende Rückfrage, ob nachträglich etwas verändert wurde, und es zeigt jeder Gegenseite, dass Sie sorgfältig gearbeitet haben.

sha256sum "$V"/* > /root/pruefsummen-vorfall.txt
tar -czf /root/vorfall.tar.gz "$V"
sha256sum /root/vorfall.tar.gz

Die Prüfsumme des Archivs schreiben Sie in den Bericht selbst, das Archiv hängen Sie an oder stellen es auf Anfrage bereit. Versenden Sie nie ein Archiv mit einem vollständigen Mitschnitt von mehreren hundert Megabyte ungefragt: Viele Missbrauchsstellen weisen große Anhänge automatisch ab, und Ihr Bericht kommt dann gar nicht an.

Was Sie sichern, auf einen Blick

Warum die Quelladresse meistens nicht der Täter ist

Dies ist der wichtigste Abschnitt dieses Beitrags. Wer die Adressen aus seinem Paketmitschnitt anzeigt, zeigt in aller Regel ein weiteres Opfer an. Das ist keine Feinheit, sondern die Grundeigenschaft der beiden Techniken, mit denen praktisch jeder große Angriff gefahren wird.

Gefälschte Absender bei Verstärkungsangriffen

Bei einem Verstärkungsangriff sendet der Angreifer kleine Anfragen an offen erreichbare UDP-Dienste im Netz und trägt als Absender Ihre Adresse ein. Die Dienste antworten pflichtgemäß, nur eben an Sie, und die Antworten sind ein Vielfaches größer als die Anfragen. Möglich ist das, weil UDP keinen Handshake kennt: Der antwortende Dienst hat keine Möglichkeit festzustellen, ob der eingetragene Absender die Anfrage wirklich gestellt hat.

Die Folge für Ihre Meldung: Jede Adresse, die Sie im Mitschnitt sehen, gehört einem Server, der falsch konfiguriert ist oder einen Dienst öffentlich anbietet, der nicht öffentlich sein sollte. Dessen Betreiber hat den Angriff nicht gefahren, sondern wurde dafür benutzt, oft ohne es zu merken. Die Adresse des eigentlichen Angreifers steht nirgends in Ihren Daten, sie stand nur auf den Anfragepaketen, und die haben Sie nie gesehen.

Technisch verhindert wird das durch Eingangsfilterung an der Netzgrenze des Angreifers, beschrieben in RFC 2827 als BCP 38 und ergänzt durch RFC 3704 als BCP 84. Wäre die überall umgesetzt, gäbe es keine gefälschten Absender. Sie ist nicht überall umgesetzt, und Sie können daran nichts ändern.

Woran Sie einen Verstärkungsangriff im Mitschnitt zweifelsfrei erkennen: Die eingehenden Pakete sind Antworten auf Anfragen, die Sie nie gestellt haben, und der Quellport ist der Dienstport. Eingehendes UDP mit Quellport 53 sind DNS-Antworten, 123 sind NTP-Antworten, 11211 ist memcached, 1900 ist SSDP, 389 ist CLDAP und 27015 ist das Abfrageprotokoll einer Spieleplattform. Wenn Sie keinen dieser Dienste abgefragt haben und die Pakete trotzdem hereinkommen, halten Sie einen Reflexionsangriff in der Hand.

Übernommene Geräte im Botnetz

Der zweite Fall ist der direkte Angriff aus einem Botnetz. Hier sind die Adressen echt, sie gehören aber Geräten, die der Angreifer übernommen hat: Router mit Standardpasswort, Überwachungskameras, Netzwerkrekorder, Fernsehboxen, gelegentlich schlecht abgesicherte Server. Der Besitzer dieses Geräts weiß in aller Regel nichts davon. Auch er ist Geschädigter, nicht Täter.

Eine Meldung an das Netz, in dem dieses Gerät steht, ist trotzdem sinnvoll, nur mit einem anderen Ziel: Sie sorgt dafür, dass der Besitzer informiert und das Gerät bereinigt wird. Formulieren Sie den Bericht deshalb genau so und nicht als Beschuldigung. Missbrauchsstellen reagieren auf eine sachliche Mitteilung erheblich besser als auf eine Anschuldigung, die sie zuerst gegen ihren eigenen Kunden verteidigen müssen.

Woran Sie erkennen, ob eine Quelladresse echt ist

Es gibt eine harte, überprüfbare Regel: Eine TCP-Verbindung, die den Zustand ESTABLISHED erreicht hat, kommt von einer echten Adresse. Der Dreiwege-Handshake verlangt, dass das SYN-ACK des Servers beim Absender ankommt und von dort bestätigt wird. Mit einer gefälschten Adresse geht das nicht, weil die Antwort zum echten Inhaber der Adresse läuft und nicht zum Angreifer.

Daraus folgt die Einordnung Ihrer eigenen Daten. Alles, was Sie in ss -tn state established sehen, und jede vollständige HTTP-Anfrage in Ihrem Zugriffsprotokoll stammt von einer realen Adresse. Alles, was in ss -tn state syn-recv hängt, kann gefälscht sein, und bei einem SYN-Flood ist es das fast immer. Jedes eingehende UDP-Paket kann gefälscht sein, unabhängig davon, wie plausibel es aussieht.

Schreiben Sie diese Einordnung in Ihren Bericht hinein. Ein Satz wie "uns ist bewusst, dass die Quelladresse eines Reflexionsangriffs einem missbrauchten Dritten gehört und nicht dem Urheber" ist der Unterschied zwischen einem Bericht, der als kompetent gelesen wird, und einem, der als Beschuldigung abgelegt wird. Die technische Einordnung von Angriffsarten und Verstärkungsfaktoren steht ausführlich in Was ist ein DDoS-Angriff.

An wen Sie sich wenden, in dieser Reihenfolge

Die Reihenfolge ist keine Formsache. Sie ergibt sich daraus, wer überhaupt etwas ausrichten kann, und der einzige, der den Angriff stoppen kann, steht ganz vorn.

Schritt 1: der eigene Anbieter, weil er als einziger vor dem Server filtern kann

Ihr Anbieter ist die einzige Stelle, die den Verkehr verwirft, bevor er Ihre Leitung erreicht. Jede Regel auf Ihrem eigenen Server entscheidet über ein Paket, das bereits über das Kabel gelaufen ist: Sie können es verwerfen, aber nicht ungesendet machen. Ist die Leitung davor voll, kommen die Pakete Ihrer Nutzer gar nicht mehr an, unabhängig von der Qualität Ihres Regelwerks.

In das erste Ticket gehören genau sechs Angaben, und mit diesen sechs wird es sofort bearbeitet: Zeitpunkt von Beginn und Ende mit Zeitzone, betroffene IP-Adresse und betroffener Port, gemessene Paketrate mit Richtungsangabe, gemessene Bandbreite mit Richtungsangabe, mittlere Paketgröße, und die Protokollverteilung mit den auffälligen Quellports. Hängen Sie das Archiv an oder bieten Sie es an. Alles Weitere, insbesondere die Frage, wer dahintersteckt, klären Sie nicht in diesem Ticket.

Schritt 2: die Missbrauchsstelle des Quellnetzes

Diese Meldung stoppt Ihren Angriff nicht. Sie wirkt langsamer und an einer anderen Stelle: Sie sorgt dafür, dass ein offen erreichbarer Dienst geschlossen oder ein übernommenes Gerät bereinigt wird. Jeder geschlossene Verstärker verringert die Verstärkungskapazität, die weltweit zur Verfügung steht, und zwar dauerhaft. Das ist der einzige Hebel, der langfristig etwas verändert, und er funktioniert nur, weil viele Betroffene ihn bedienen.

Melden Sie je Quellnetz einmal, nicht je Adresse. Zwanzig Einzelmails an dieselbe Missbrauchsstelle werden als Massenversand eingestuft und gemeinsam abgelegt. Eine Mail mit zwanzig Adressen desselben Netzes in einer Liste wird bearbeitet.

Schritt 3: die Polizei

Die Anzeige ist der langsamste Weg und der einzige, der Zwangsmittel kennt. Nur eine Behörde kann von einem Anbieter Bestandsdaten verlangen, und nur über eine Behörde entsteht aus vielen kleinen Vorfällen ein Verfahren gegen den Betreiber eines Angriffsdienstes. Erwarten Sie keine Lösung Ihres akuten Problems, erwarten Sie ein Aktenzeichen (in Österreich eine Aktenzahl) und einen Baustein in einem größeren Bild.

Wie Sie die zuständige Missbrauchsstelle finden

Die Zuständigkeit ergibt sich aus der Adresse, nicht aus dem Namen einer Firma. Jede öffentliche IP-Adresse ist in der Datenbank einer der fünf Regionalen Internet-Registraturen eingetragen, und dort steht die Missbrauchsstelle.

Die fünf Datenbanken und ihre Gebiete

Zuständig sind: RIPE NCC für Europa, den Nahen Osten und Teile Zentralasiens; ARIN für Nordamerika; APNIC für den asiatisch-pazifischen Raum; LACNIC für Lateinamerika und die Karibik; AFRINIC für Afrika. Sie müssen nicht wissen, welche davon es ist: Eine whois-Abfrage wird automatisch an die richtige Datenbank weitergereicht.

whois 203.0.113.5 | grep -iE 'abuse|orgname|netname|descr|country|inetnum|netrange'
whois -h whois.cymru.com " -v 203.0.113.5"

Die erste Zeile liefert den Eintrag der zuständigen Registratur samt Missbrauchskontakt. Die zweite fragt einen öffentlichen Dienst ab, der zusätzlich das autonome System, das angekündigte Präfix und das Land nennt. Das autonome System ist die Angabe, mit der Sie mehrere Adressen demselben Netzbetreiber zuordnen und dadurch aus zwanzig Einzelmeldungen eine machen.

Die Felder, auf die es ankommt

Je nach Registratur heißen die Felder anders, gemeint ist immer dasselbe. In der RIPE-Datenbank verweist abuse-c: auf ein Rollenobjekt, in dem abuse-mailbox: die verbindliche Adresse enthält; bei ARIN steht sie direkt in OrgAbuseEmail:; APNIC nutzt abuse-c: und zusätzlich ein irt:-Objekt für das Reaktionsteam. Schreiben Sie ausschließlich an diese Adresse. Der technische oder administrative Kontakt aus demselben Eintrag ist eine persönliche Adresse und keine Missbrauchsstelle, und eine Meldung dorthin gilt als unerbetene Nachricht.

Beachten Sie außerdem die Verschachtelung: Ein inetnum-Eintrag kann zu einem kleineren Kundennetz gehören, das innerhalb eines größeren Anbieternetzes liegt. Der Eintrag, der Ihre Adresse am genauesten umschließt, ist der richtige. Findet sich dort keine Missbrauchsstelle, gehen Sie eine Ebene höher zum umgebenden Netz.

Wenn im Eintrag nichts Brauchbares steht

Drei Rückfallebenen, in dieser Reihenfolge. Erstens das umgebende, größere Netz aus dem whois-Eintrag, meist der Netzbetreiber selbst. Zweitens die übliche Sammeladresse in der Form abuse@ plus Domain des Betreibers, die viele Netze pflegen, auch wenn sie nicht in der Datenbank steht. Drittens, wenn hinter der Adresse eine Website läuft, die Datei /.well-known/security.txt nach RFC 9116: Sie enthält ein Feld Contact:. Dieser Weg ist für Schwachstellenmeldungen gedacht und nicht für Missbrauchsberichte, aber er führt oft zu einem Menschen, wenn sonst nichts erreichbar ist.

Ein Hinweis zum Format: RFC 5965 beschreibt mit dem Abuse Reporting Format eine maschinenlesbare Form solcher Berichte. Sie ist für den Missbrauch von E-Mail entworfen und wird von Netzbetreibern für Netzangriffe nur selten ausgewertet. Für einen DDoS-Vorfall ist eine klar strukturierte Nur-Text-Mail mit festen Feldern das Format, das tatsächlich gelesen wird.

Was ein Missbrauchsbericht enthalten muss

Die sieben Pflichtangaben

Fehlt eine dieser sieben Angaben, ist die häufigste Reaktion eine Rückfrage, und die zweithäufigste gar keine.

1. Zeitstempel für Beginn und Ende, mit Zeitzone. UTC nach ISO 8601, also in der Form 2026-09-28T20:14:37+00:00. Dazu die Angabe, ob die Systemuhr synchronisiert war.
2. Betroffene Adresse und betroffener Port. Ihre eigene öffentliche IP-Adresse und der Zielport, nicht der Domainname. Der Empfänger sucht nach Adressen.
3. Quelladresse. Eine je Bericht, oder eine Liste von Adressen desselben Netzes. Keine Sammlung aus dreißig verschiedenen Netzen in einer Mail.
4. Protokoll und Quellport. UDP oder TCP, dazu der Quellport, weil er bei Reflexion die Angriffsart beweist.
5. Umfang. Bandbreite und Paketrate, jeweils mit Richtungsangabe und möglichst als Wert für diese eine Quelle, nicht nur als Gesamtsumme.
6. Einordnung der Quelle. Ihre eigene Bewertung, ob die Adresse echt oder gefälscht sein dürfte, und dass Sie den Inhaber nicht beschuldigen.
7. Rohdaten im Anhang oder auf Anfrage. Der begrenzte Mitschnitt, der lesbare Auszug daraus, die Zählerstände und die Prüfsumme des Archivs.

Mustervorlage zum Übernehmen

Die Vorlage ist bewusst auf Englisch gehalten. Missbrauchsstellen arbeiten international, und ein Bericht auf Englisch wird auch in einem Netz gelesen, dessen Betreiber kein Deutsch spricht. An ein deutschsprachiges Netz können Sie ihn selbstverständlich übersetzen. Ersetzen Sie die Platzhalter durch Ihre gemessenen Werte; die Adressen im Beispiel stammen aus den für Dokumentation reservierten Bereichen.

Subject: [Abuse] UDP reflection traffic from 203.0.113.5 towards 198.51.100.7,
         2026-09-28 UTC

Dear abuse team,

we are reporting unsolicited traffic that originated from an address in
your network and hit one of our servers. We are not accusing your
customer, see the note at the bottom.

Reporter organization : Example GmbH
Reporter contact      : abuse-reports@example.com
Incident start (UTC)  : 2026-09-28T20:14:37+00:00
Incident end   (UTC)  : 2026-09-28T20:41:02+00:00
Clock source          : NTP, system clock synchronized
Our IP and port       : 198.51.100.7, UDP/27015
Source IP             : 203.0.113.5
Source port           : UDP/53
Protocol              : UDP, DNS responses we never requested
Volume from this IP   : 480 Mbit/s, 71000 packets per second, peak
Total incident volume : 42 Gbit/s, 6.1 million packets per second
Average packet size   : 860 bytes
Classification        : DNS reflection and amplification

Evidence available    : capture.pcap   (tcpdump, 20000 packets, 128 byte snaplen)
                        capture.txt    (readable excerpt, 40 lines)
                        counters.txt   (ip -s link, nstat -az, nft counters)
                        SHA-256 of archive:
                        6f1c0a...  incident-2026-09-28.tar.gz

Excerpt from the capture (UTC):

20:14:37.118 IP 203.0.113.5.53 > 198.51.100.7.27015: 3721 bytes
20:14:37.118 IP 203.0.113.5.53 > 198.51.100.7.27015: 3721 bytes
20:14:37.119 IP 203.0.113.5.53 > 198.51.100.7.27015: 3721 bytes

Note on attribution: in a reflection attack the source address belongs to
a system that was abused by a third party, not to the originator of the
attack. We therefore do not consider the operator of 203.0.113.5
responsible. Please check whether that host answers recursive DNS queries
from the public internet and, if so, restrict it.

We will hand the full capture to your team or to a law enforcement agency
on request. A criminal complaint has been filed, reference available on
request.

Kind regards
Example GmbH, Network Operations

Was Sie weglassen sollten

Vier Dinge machen einen guten Bericht kaputt. Drohungen jeder Art, auch angedeutete, weil der Bericht dann an die Rechtsabteilung geht statt an die Technik. Fristsetzungen, weil Sie gegenüber einem fremden Netz keine setzen können. Vermutungen darüber, wer hinter dem Angriff steht, weil sie nicht belegt sind und den sachlichen Teil entwerten. Und ungefragte Anhänge von mehreren hundert Megabyte, weil sie automatisch abgewiesen werden. Bieten Sie große Dateien an, statt sie zu senden.

Ebenfalls weglassen: Bildschirmfotos als einziges Beweismittel, Auszüge, in denen personenbezogene Daten Ihrer eigenen Nutzer stehen, und interne Hostnamen oder Pfade, die nichts zur Sache tun. Ein Bericht, der nur enthält, was er belegen soll, wird schneller bearbeitet.

Die Strafanzeige

Wo Sie sie stellen

In Österreich wie in Deutschland nimmt jede Polizeidienststelle eine Anzeige entgegen, ebenso die Staatsanwaltschaft. Eine örtliche Zuständigkeit müssen Sie nicht selbst ermitteln, die Abgabe erfolgt intern. Mehrere deutsche Bundesländer betreiben zusätzlich eine Online-Wache für die Anzeige über das Internet; welche das für Ihren Wohnort ist, steht auf der Website der Landespolizei Ihres Bundeslandes. Für Unternehmen gibt es in Deutschland bei den Landeskriminalämtern jeweils eine Zentrale Ansprechstelle Cybercrime, zu finden über die Website des Landeskriminalamts Ihres Bundeslandes. In Österreich führt das Bundeskriminalamt eine Meldestelle für Cybercrime, deren aktueller Kontaktweg auf der Website des Innenministeriums steht.

Dieser Beitrag nennt bewusst keine konkreten Adressen, Nummern oder Formularlinks. Solche Angaben ändern sich, und eine veraltete Adresse kostet Sie mehr Zeit, als die Suche auf der offiziellen Seite dauert.

Was Sie mitbringen

Bringen Sie den Vorgang in einer Form mit, die jemand ohne Systemkenntnis lesen kann, und die Rohdaten als Beilage. Konkret: eine Seite Sachverhaltsdarstellung in ganzen Sätzen mit Zeitraum, betroffenem Dienst, Auswirkung und Schaden; das Beweisarchiv auf einem Datenträger oder als Datei, mit der Prüfsummenliste; eine Auflistung, welche Datei was zeigt, weil niemand einen Mitschnitt öffnet, ohne zu wissen, was darin zu sehen sein soll; die bereits abgesetzten Missbrauchsberichte samt Ticketnummern, weil sie Ihre eigene Sorgfalt belegen; und eine nachvollziehbare Bezifferung des Schadens, also Ausfallzeit, entgangene Einnahmen, Mehrkosten für Abwehrmaßnahmen, Arbeitszeit.

Die Schadenshöhe ist kein Beiwerk. Sie entscheidet in beiden Ländern über die Strafrahmen, und sie entscheidet praktisch darüber, ob ein Vorgang weiterverfolgt oder eingestellt wird. Schätzen Sie nicht, rechnen Sie, und legen Sie die Rechnung bei.

Warum eine Anzeige auch bei unbekanntem Täter sinnvoll ist

Der häufigste Einwand lautet: Ich weiß doch gar nicht, wer es war. Genau deshalb ist die Anzeige gegen unbekannte Täter der Normalfall und kein Mangel. Drei Gründe sprechen dafür, sie trotzdem zu stellen.

Erstens entstehen Verfahren gegen die Betreiber von Angriffsdiensten fast nie aus einem großen Fall, sondern aus vielen kleinen Anzeigen, die dasselbe Muster zeigen. Die internationalen Aktionen gegen Booter- und Stresser-Dienste, die Europol unter dem Namen Operation PowerOFF seit Jahren wiederholt, beruhen auf zusammengeführten Einzelfällen und auf den beschlagnahmten Kundendatenbanken der abgeschalteten Plattformen. Ihre Anzeige ist ein Datenpunkt in dieser Sammlung.

Zweitens ist die Anzeige die Voraussetzung dafür, dass überhaupt jemand Daten anfordern darf. Ohne Verfahren gibt kein Anbieter Bestandsdaten heraus, und ohne diese Daten bleibt jeder Verdacht unbelegt.

Drittens brauchen Sie das Aktenzeichen für eigene Zwecke: gegenüber Ihrer Versicherung, gegenüber Kunden, denen Sie einen Ausfall erklären müssen, gegenüber einem Vermieter von Infrastruktur, und in dem Fall, dass der Angriff weitergeht und Sie später einen Zusammenhang belegen wollen.

Der Sonderfall mit der Lösegeldforderung

Kommt zu dem Angriff eine Zahlungsaufforderung, ändert sich die Lage in zwei Punkten. Sie haben dann eine Spur, die es sonst nicht gibt, und Sie haben einen zusätzlichen Straftatbestand. Beides gehört ausdrücklich in die Anzeige.

Praktisch heißt das: Zahlen Sie nicht. Eine Zahlung finanziert die nächste Angriffswelle und macht Sie zum bekannten zahlenden Ziel. Sichern Sie die Nachricht in der Rohfassung, nicht als Bildschirmfoto, denn nur die Rohfassung enthält die vollständige Kette der Received-Kopfzeilen und damit den Weg der Nachricht. Bei einer E-Mail speichern Sie sie als Datei, bei einer Nachricht in einem Chat oder auf einer Plattform sichern Sie zusätzlich die Kennung des Absenders und die Kennung der Nachricht. Notieren Sie jede genannte Zahlungsadresse unverändert, Zeichen für Zeichen. Antworten Sie nicht und verhandeln Sie nicht, auch nicht zum Schein.

Rechtsgrundlagen in Österreich und Deutschland

In Österreich fällt ein DDoS-Angriff unter § 126b StGB, "Störung der Funktionsfähigkeit eines Computersystems". Der Grundtatbestand sieht Freiheitsstrafe bis zu sechs Monaten oder eine Geldstrafe bis zu 360 Tagessätzen vor. Dauert die Störung längere Zeit, sind es bis zu zwei Jahre. Werden viele Systeme mit einem Programm angegriffen, das erkennbar dafür geschaffen wurde, sind es bis zu drei Jahre. Und bei einem Schaden über 300.000 Euro, bei einem Angriff auf kritische Infrastruktur oder als Mitglied einer kriminellen Vereinigung liegt der Rahmen bei sechs Monaten bis fünf Jahren. Ergänzend stellt § 126c StGB bereits das Herstellen, Verbreiten und Zugänglichmachen der dafür bestimmten Programme unter Strafe.

In Deutschland greift § 303b StGB, "Computersabotage": bis zu drei Jahre Freiheitsstrafe oder Geldstrafe, bis zu fünf Jahre, wenn die Datenverarbeitung einem Betrieb, einem Unternehmen oder einer Behörde dient, und in besonders schweren Fällen sechs Monate bis zehn Jahre, etwa bei gewerbsmäßigem Handeln oder bei Beeinträchtigung kritischer Infrastruktur. Der Versuch ist strafbar, und für Vorbereitungshandlungen verweist § 303b Abs. 5 StGB auf § 202c StGB.

Strafbar ist dabei nicht nur, wer den Angriff technisch ausführt, sondern auch, wer ihn in Auftrag gibt. Der Hinweis auf einer Booter-Seite, das Angebot diene nur dem Belastungstest eigener Systeme, ändert daran nichts, weil diese Dienste nicht prüfen, wem das eingetragene Ziel gehört. Dieser Abschnitt gibt den Gesetzesstand wieder und ist keine Rechtsberatung.

Was realistisch passiert und was nicht

Der ehrliche Teil, damit Sie Ihre Erwartung richtig setzen und trotzdem melden.

Kein Anbieter nennt Ihnen Kundendaten. Auf die Frage, wem die Adresse 203.0.113.5 gehört, bekommen Sie keine Antwort, und das ist richtig so. Bestandsdaten werden nur auf behördliche Anordnung herausgegeben. Was Sie bekommen können, ist die Bestätigung, dass der Meldung nachgegangen wurde, und manchmal die Information, dass ein offener Dienst geschlossen wurde.

Gefälschte Quellen sind praktisch nicht zurückverfolgbar. Um die echte Herkunft eines Pakets mit gefälschtem Absender festzustellen, müsste jedes Transitnetz auf dem Weg gleichzeitig mitmessen, während der Angriff läuft. Das geschieht bei einem einzelnen Vorfall nicht. Bei einem Reflexionsangriff ist die Kette ohnehin unterbrochen, weil die Anfragen an den Verstärker nie über Ihr Netz liefen.

Dienste im Ausland brauchen Rechtshilfe. Sitzt der Betreiber eines Angriffsdienstes außerhalb des Landes, in dem Sie anzeigen, läuft jede Datenanforderung über ein Rechtshilfeersuchen, innerhalb der Europäischen Union über eine Europäische Ermittlungsanordnung. Beides dauert, und beides ist nichts, worauf Sie Einfluss haben.

Viele Missbrauchsberichte bleiben unbeantwortet. Nicht jede Missbrauchsstelle antwortet, manche bestätigen nur automatisch den Eingang, manche gar nichts. Das heißt nicht zwingend, dass nichts geschehen ist.

Warum es sich trotzdem lohnt, in vier Sätzen. Der Bericht an den eigenen Anbieter wirkt direkt und schnell, das ist der Teil, der Ihren Dienst wieder erreichbar macht. Der Bericht an das Quellnetz verkleinert dauerhaft die Verstärkungskapazität, die für den nächsten Angriff zur Verfügung steht, und zwar für alle. Die Anzeige liefert den Datenpunkt, aus dem zusammen mit anderen ein Verfahren wird. Und Ihre eigene Dokumentation ist die Grundlage dafür, beim zweiten Angriff in fünf Minuten zu wissen, ob es dasselbe Muster ist.

Was Sie parallel tun, damit der Dienst wieder läuft

Melden und Wiederherstellen sind zwei getrennte Aufgaben, und die zweite wartet nicht auf die erste. Sobald das Beweisarchiv geschrieben ist, gehört die Aufmerksamkeit dem Betrieb.

• Feststellen, welche Ebene getroffen ist. Der genaue Diagnoseweg mit ss, Paketzählern, Kernelmeldungen und Webserver-Protokollen steht in DDoS-Angriff erkennen.
• Den laufenden schweren Angriff abarbeiten. Die Reihenfolge vom ersten Messen über das Schließen der Verwaltungsports bis zur Ratenbegrenzung steht in Schwerer DDoS-Angriff: was tun.
• Die Grundlagen nachziehen. Regelwerk, SYN-Cookies, Verbindungsverfolgung und Ratenbegrenzung je Quelladresse stehen in Server vor DDoS-Angriffen schützen.
• Verstehen, was Sie gerade sehen. Angriffsebenen, Verstärkungsfaktoren und die physikalischen Grenzen stehen in Was ist ein DDoS-Angriff.
• Dafür sorgen, dass es beim nächsten Mal automatisch mitgeschrieben wird. Eine laufende Messung liefert den Vergleichswert, ohne den Sie nicht sagen können, ob 40.000 Pakete pro Sekunde viel waren. Der Aufbau steht in Server-Monitoring einrichten.

Ein Hinweis zum Adresswechsel, weil er in dieser Lage oft als Erstes erwogen wird: Er wirkt nur, solange die neue Adresse nicht wieder öffentlich steht, und ein vergessener alter DNS-Eintrag macht ihn wirkungslos. Er vernichtet außerdem den Zusammenhang zwischen Ihren bisherigen Beweisen und dem weiterlaufenden Angriff. Wechseln Sie erst, wenn das Archiv geschrieben ist.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und permanent aktiv, ohne dass Sie etwas bestellen, einschalten oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps vor Ort in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind für die Beweislage entscheidend. Der Schutz läuft dauerhaft und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Dienst weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Nimmt ein Anbieter die angegriffene Adresse dagegen aus dem Netz, ist das Ergebnis für Sie identisch mit einem erfolgreichen Angriff, und Sie können während der Sperre nicht einmal mehr messen. Standort der Echtzeitfilterung ist Frankfurt am Main. Der Schutz ist in jedem Serverpaket ohne Aufpreis enthalten, vom KVM-Rootserver bis zum Dedicated Server.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich getroffen, sondern gezielt und über Wochen. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich, ohne Ticket: Der Dienstport bekommt andere Regeln als der Abfrageport.
• Änderungen greifen in Echtzeit, Sie können also mitten im laufenden Angriff nachjustieren, während Sie parallel die Beweise sichern.
• Schutzprofile passend zur Anwendung, auch für eigene und modifizierte Dienste auf beliebigen TCP- oder UDP-Ports.

Advanced DDoS Protection richtet sich an Server, die bei KernelHost laufen. Wird Ihr Projekt woanders gehostet und dauerhaft angegriffen, ist der Umzug zu KernelHost der Weg, auf dem Sie den Schutz bekommen.

Die beiden Stufen im Vergleich

Läuft Ihr Projekt bereits bei KernelHost, wenden Sie sich mit den sechs Angaben aus Schritt 1 an das Ticketsystem im Kundenbereich. Die Filterung läuft ohnehin, das Ticket sorgt dafür, dass die Regeln für Ihre Adresse nachjustiert werden und dass Sie die Messwerte der Netzseite für Ihre Meldung und Ihre Anzeige bekommen.

Häufige Fehler beim Melden

"Ich habe erst mal neu gestartet, dann sah ich nach." Der Neustart hat sämtliche Zähler auf null gesetzt. Ab diesem Punkt gibt es keinen Nachweis mehr für Paketrate, Verwürfe und Verbindungszustände, und die Last ist nach Sekunden wieder da.

"Ich habe alle 300 Adressen aus dem Mitschnitt einzeln gemeldet." Das wird als Massenversand eingestuft. Gruppieren Sie nach autonomem System oder nach Netzblock und schreiben Sie je Netz eine Mail mit Liste.

"Ich habe die oberste IP aus der Häufigkeitsliste angezeigt." Bei einem Reflexionsangriff ist das der am stärksten missbrauchte Verstärker, also das am stärksten betroffene weitere Opfer, nicht der Täter.

"Ich habe ein Bildschirmfoto der Grafik geschickt." Ohne Zeitzone und ohne Angabe der Mittelungsdauer ist das Bild als Beleg für eine Spitzenlast nicht verwendbar. Liefern Sie Zahlen, das Bild nur zusätzlich.

"Im Ticket stand, der Server sei langsam gewesen." Ohne Zeitstempel, Adresse, Port und Messwert kann niemand in seinen Protokollen an der richtigen Stelle nachsehen. Die Bearbeitung beginnt erst nach der ersten Rückfrage.

"Ich habe eine Frist von 24 Stunden gesetzt." Gegenüber einem fremden Netz können Sie keine setzen. Der Bericht wandert dann in die Rechtsabteilung und nicht zur Technik.

"Ich habe den Mitschnitt mit 900 MB angehängt." Die Mail wurde von der Größenbegrenzung abgewiesen, und niemand hat den Bericht je gesehen. Bieten Sie große Dateien an, statt sie zu senden.

"Ich wollte erst in Ruhe alles sammeln und habe am Wochenende gemeldet." Auf der Gegenseite ist zu diesem Zeitpunkt oft nichts mehr nachvollziehbar. Der Bericht gehört raus, solange der Vorfall frisch ist, auch wenn er noch nicht vollständig ist.

Kurz zusammengefasst

• Die Beweise, auf die es ankommt, existieren nur während des Angriffs: Kernelzähler, Socketzustände, Firewall-Zählerstände und die Verkehrsgrafik in feiner Auflösung sind später geglättet oder weg. Sichern kommt vor Melden.
• Die ersten zehn Minuten gehören sieben Befehlen: date -u --iso-8601=seconds, ip -s link, ss -s, nstat -az, sar -n DEV 1 10, nft list ruleset und ein mit -c begrenzter tcpdump -w.
• Ein Bildschirmfoto der Verkehrsgrafik ist das schwächste Format: keine nachrechenbaren Zahlen, keine Zeitzone, keine Angabe der Mittelungsdauer. Rohdaten mit Zeitstempel sind der Beleg, das Bild nur die Illustration.
• Die Quelladresse aus dem Mitschnitt gehört bei Verstärkungsangriffen einem missbrauchten Dritten und bei Botnetz-Angriffen einem übernommenen Gerät. Wer sie anzeigt, zeigt in aller Regel ein weiteres Opfer an.
• Echt ist eine Adresse nur dort, wo ein TCP-Handshake vollendet wurde, also bei Verbindungen im Zustand ESTABLISHED und bei vollständigen HTTP-Anfragen. Jedes UDP-Paket und jedes SYN kann gefälscht sein.
• Die Reihenfolge lautet: eigener Anbieter, weil er als einziger vor dem Server filtern kann; Missbrauchsstelle des Quellnetzes, gefunden über whois und die Felder abuse-c, abuse-mailbox oder OrgAbuseEmail; danach die Polizei.
• Ein Missbrauchsbericht braucht sieben Angaben: Zeitstempel mit Zeitzone, betroffene Adresse und Port, Quelladresse, Protokoll und Quellport, Umfang, Einordnung der Quelle und Rohdaten im Anhang oder auf Anfrage.
• Eine Anzeige gegen unbekannte Täter ist der Normalfall und trotzdem sinnvoll: Verfahren gegen Betreiber von Angriffsdiensten entstehen aus vielen kleinen Anzeigen, und ohne Verfahren darf niemand Daten anfordern.
• Realistisch ist: kein Anbieter nennt Kundendaten ohne behördliche Anordnung, gefälschte Quellen sind nicht zurückverfolgbar, ausländische Dienste brauchen Rechtshilfe, und viele Missbrauchsberichte bleiben unbeantwortet.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab der Bereitstellung aktiv, ohne Nullrouting: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk plus Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Die Advanced DDoS Protection ergänzt ihn ab 50,00 € im Monat um eine dedizierte Schutz-IP und selbst verwaltbare Regeln je Port.
• Dieser Beitrag beschreibt den Weg und gibt den Gesetzesstand wieder. Er ist keine Rechtsberatung und nennt bewusst keine Behördenadressen, sondern zeigt, wie Sie die zuständige Stelle finden.