Reporting a DDoS attack: preserve evidence, write the report, file it

A DDoS attack is a criminal offense in Austria and in Germany, and most reports about one still lead nowhere. The reason is rarely the law. It is almost always the timing: the evidence that matters exists only while the attack is running. Kernel counters, half-open connections, the protocol distribution on the wire and the traffic graph at one minute resolution are smoothed, overwritten or completely gone an hour later, and a reboot wipes all of them at once. Anyone who starts writing the next morning is reporting an incident nobody can verify any more, and gets exactly the response such a report deserves.

This article is therefore first a guide to preserving evidence in time and only then a guide to reporting. It shows with real commands what you write away in the first ten minutes, why the source address in your packet capture almost never belongs to the attacker, in which order you approach your own provider, the abuse desk of the source network and the police, what an abuse report has to contain to be processed at all, and what realistically comes out of it. The template at the end is meant to be copied and filled in.

One limitation up front, and it is repeated in the FAQ: this article describes the path and reflects the state of the law. It is not legal advice and does not replace a lawyer in an individual case. It also deliberately names no phone numbers, no addresses of public authorities and no deadlines. A wrong address for an authority is worse than none, so what you get instead is how to find the office responsible for you.

Why most DDoS reports lead nowhere

A report goes unprocessed for two reasons: it arrives too late, or it contains too little. The two are connected, because a report that arrives too late can no longer contain anything.

The receiving side almost always runs a ticket system that sorts every incoming message automatically. A text such as "your customer attacked me today, please do something" contains nothing a machine can work with: no time, no address, no port, no protocol. It lands in the loop for follow-up questions and dies there. A report with a timestamp in UTC, the affected address and port, the source address, the protocol, the measured volume and an attached extract of raw data does get assigned, because every one of those items can be checked against the recipient's own logs.

The second reason is how long data survives on the other side. How long a provider keeps connection data differs from country to country and from provider to provider, and you cannot rely on anything still being there in a month. Every day you wait shrinks the amount the recipient can still look up. For attacks that run in waves over several days, that is the practical difference between a confirmation and a shrug.

And the third reason is substantive: a great many reports accuse the wrong party. That is not carelessness, it follows directly from the technology, and it is the section of this article to take most seriously.

The first ten minutes: what to preserve before it is gone

Measure, do not tinker, and do it in this order. Every minute spent adjusting firewall rules is a minute in which no evidence is being preserved. And a reboot deletes every counter, every connection state and every piece of evidence at once, while the load is back within seconds.

Why every minute destroys evidence

The values that prove an attack live in four different places with four different lifetimes. The counters in /proc and in ip -s link have been running since the last boot and are zero after a restart. The socket table shown by ss is a snapshot that changes every second and cannot be reconstructed afterwards. Your firewall counters do not survive a reload of the rule set. And the traffic graph at your provider is condensed into coarser averages as it ages, so that a twenty minute spike eventually disappears into a daily mean.

So the first thing you do is create a directory and write everything into it, instead of reading individual values in the terminal and forgetting them again.

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

The timestamp without which everything else is worthless

Every item in your report will be compared against logs kept by recipients in other time zones. A time without a time zone is therefore not a statement, it is a follow-up question. Write down start and end in UTC, in ISO 8601 format, and record whether the system clock was synchronized at all.

date -u --iso-8601=seconds > 01-time-utc.txt
timedatectl > 02-clock-source.txt
uptime > 03-uptime.txt

timedatectl shows in the line "System clock synchronized" whether the clock is being steered by NTP. If it says "no", your time is only as accurate as the drift of your clock, and that belongs in the report. A clock forty minutes off makes the recipient search the wrong part of their logs and find nothing.

Counters from the kernel

These commands are the core of evidence preservation. Together they take less than half a minute and produce the numbers every abuse desk and every provider asks for first.

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-packet-rate.txt
cat /proc/net/softnet_stat > 15-softnet.txt
dmesg -T | tail -200 > 16-kernel.txt

What these files prove: ip -s link gives the dropped and overrun columns per interface, that is the packets the kernel no longer accepted. ss -s gives the total number of sockets per state, and ss -tn state syn-recv gives the half-open connections; a five digit figure there is a SYN flood. nstat -az prints all kernel network counters including the ones at zero, among them TcpExtListenOverflows, TcpExtListenDrops and TcpExtSyncookiesSent. The second column in /proc/net/softnet_stat counts, per CPU, the packets dropped because the receive queue was full. And sar -n DEV 1 10 measures packets and bytes per second per interface for ten seconds, which gives you the average packet size.

The average packet size is the single number that reveals the type of attack: bytes divided by packets. Below 100 bytes points to a protocol attack with small packets, above 1,000 bytes to an amplification attack with large responses. State it in the report so the recipient does not have to work it out.

The counters in your firewall

The rule set on its own says nothing. What matters is how many packets each rule matched, because that is your own proof that you dropped the traffic rather than ignoring it.

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-counters.txt
cat /proc/sys/net/netfilter/nf_conntrack_count > 24-conntrack-count.txt
cat /proc/sys/net/netfilter/nf_conntrack_max > 25-conntrack-max.txt

One important caveat: nft list ruleset only shows counter values where the rule contains a counter statement. If your rules carry no counter, you get the rule text without any numbers, and that proves nothing. Anyone who expects attacks puts the counter statement into the drop rules in advance, because it cannot be added retroactively. iptables-save -c gives the same information for older rule sets, as [packets:bytes] in front of each rule. The two conntrack values show by comparison whether the connection tracking table ran full, which also appears in the kernel log as nf_conntrack: table full, dropping packet.

The packet capture, bounded and for a reason

The packet capture is the only piece of evidence that contains source addresses, source ports and payload. Without it you cannot write a single abuse report, because you cannot name the other side at all. It is at the same time the only one that can make your situation worse if you let it run without limits: a capture on a saturated line fills the disk in minutes and costs processing time you do not have right now.

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

The three switches that matter: -s 128 truncates every packet after 128 bytes, which is enough for the headers and the start of the payload and keeps the capture small. -c 20000 ends the capture after 20,000 packets instead of letting it run. -w writes the binary format rather than the text output, because only the binary format can be examined by the recipient. tcpdump -D lists the available interfaces beforehand if you are unsure about the name.

For an attack that arrives in waves a ring buffer is better, because it records over a longer period while keeping a fixed upper bound on disk:

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

-C 50 limits each file to roughly 50 million bytes, -W 3 keeps at most three of them and then overwrites the oldest. The capture therefore occupies about 150 megabytes at most, no matter how long it runs.

For the report you then need two summaries from the capture, produced by reading it, not by capturing again:

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

The first file is the readable excerpt you paste into the body of the report: forty lines are enough to show the pattern. The second is the frequency list of source addresses. That list is exactly why the next section exists, because it invites you to report the address at the top.

Extracts from the access log

For an attack at the application layer the evidence is not on the wire but in the web server access log. Cut out the time window instead of attaching the whole file, and supply the two distributions that show the pattern.

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-requests.txt
awk '{print $1}' 41-requests.txt | sort | uniq -c | sort -rn | head -30 > 42-top-ips.txt
awk '{print $9}' 41-requests.txt | sort | uniq -c | sort -rn > 43-status-codes.txt
awk -F'"' '{print $6}' 41-requests.txt | sort | uniq -c | sort -rn | head -20 > 44-agents.txt

In the combined log format used by nginx and Apache the source address is the first field, the timestamp the fourth, the status code the ninth and the client identifier the sixth of the sections separated by quotation marks. Three to five example lines with the recurring request pattern are enough in the report, the complete files belong in the archive. How to filter systemd logs by time window, unit and priority is covered in detail in Analyze logs with journalctl.

The provider traffic graph, and why a screenshot is worth less

The traffic graph in your customer panel is the only piece of evidence measured outside the attacked system. That makes it strong in two ways: it also shows the traffic that never reached your server, because the line in front of it was saturated or because filtering in the network already dropped it, and it does not come from the party making the claim.

A screenshot of it is nevertheless the weakest format you can hand over, for four reasons. First, an image contains no numbers anybody can recompute: reading 400 Gbit/s off a curve means interpreting the axis labels. Second, it contains no time zone, only the label your browser happened to render. Third, it contains no resolution: a curve built from five minute averages shows a spike of 900 Gbit/s lasting twenty seconds as a harmless 60 Gbit/s. And fourth, an image in a ticket system is neither searchable nor correlatable with other logs.

Better, in this order: a raw export of the measured values with timestamps and units, if the customer panel offers one; the values you measured yourself with sar and ip -s link, which agree with the graph; and the screenshot in addition, as an illustration, with the time zone spelled out and the averaging interval stated in the text. If the image is all you have, write explicitly which time zone the axis is labeled in and over what interval the data was averaged. Without those two statements the graph cannot be used as proof of a peak load.

Everything into one archive, with checksums

Finally, a checksum list freezes the state. This is not a legal proof of integrity, but it answers the obvious follow-up question of whether anything was changed afterwards, and it shows every counterpart that you worked carefully.

sha256sum "$V"/* > /root/incident-checksums.txt
tar -czf /root/incident.tar.gz "$V"
sha256sum /root/incident.tar.gz

Put the checksum of the archive into the report itself, and attach the archive or offer it on request. Never send an archive containing a full capture of several hundred megabytes unasked: many abuse desks reject large attachments automatically, and your report then never arrives at all.

What to preserve, at a glance

Why the source address is usually not the attacker

This is the most important section of this article. Anyone who reports the addresses from their packet capture is, as a rule, reporting another victim. That is not a detail, it is the basic property of the two techniques behind practically every large attack.

Forged senders in amplification attacks

In an amplification attack the attacker sends small queries to publicly reachable UDP services and enters your address as the sender. The services answer as they are supposed to, only they answer you, and the answers are a multiple of the size of the queries. This works because UDP has no handshake: the answering service has no way to check whether the sender it was given really asked the question.

The consequence for your report: every address you see in the capture belongs to a server that is misconfigured or offers a service publicly that should not be public. Its operator did not run the attack, they were used for it, often without noticing. The address of the actual attacker appears nowhere in your data, it was only on the query packets, and you never saw those.

Technically this is prevented by ingress filtering at the attacker's network edge, described in RFC 2827 as BCP 38 and extended by RFC 3704 as BCP 84. If it were deployed everywhere there would be no forged senders. It is not deployed everywhere, and there is nothing you can do about that.

How to recognize an amplification attack in the capture beyond doubt: the incoming packets are responses to queries you never made, and the source port is the service port. Incoming UDP with source port 53 is DNS responses, 123 is NTP, 11211 is memcached, 1900 is SSDP, 389 is CLDAP and 27015 is the query protocol of a gaming platform. If you queried none of those services and the packets still arrive, you are holding a reflection attack.

Compromised devices in a botnet

The second case is a direct attack out of a botnet. Here the addresses are genuine, but they belong to devices the attacker has taken over: routers with default passwords, surveillance cameras, network video recorders, set-top boxes, occasionally poorly secured servers. The owner of the device almost never knows about it. They are an injured party too, not the offender.

A report to the network hosting that device is still worthwhile, just with a different goal: it gets the owner informed and the device cleaned up. So write the report exactly that way and not as an accusation. Abuse desks respond considerably better to a factual notification than to an allegation they first have to defend their own customer against.

How to tell whether a source address is genuine

There is one hard, verifiable rule: a TCP connection that reached the ESTABLISHED state comes from a genuine address. The three way handshake requires the server's SYN-ACK to arrive at the sender and be acknowledged from there. That cannot happen with a forged address, because the answer goes to the real holder of the address and not to the attacker.

From that follows how to classify your own data. Everything you see in ss -tn state established, and every complete HTTP request in your access log, comes from a real address. Everything stuck in ss -tn state syn-recv can be forged, and during a SYN flood it almost always is. Every incoming UDP packet can be forged, no matter how plausible it looks.

Write this classification into your report. A sentence such as "we are aware that the source address of a reflection attack belongs to an abused third party and not to the originator" is the difference between a report read as competent and one filed as an allegation. The technical background on attack types and amplification factors is covered in What is a DDoS attack.

Who to contact, in this order

The order is not a formality. It follows from who can actually do something, and the only party that can stop the attack comes first.

Step 1: your own provider, because only they can filter in front of the server

Your provider is the only party that drops traffic before it reaches your line. Every rule on your own server decides about a packet that has already traveled down the cable: you can drop it, but you cannot un-send it. If the line in front of it is full, your users' packets no longer arrive at all, regardless of how good your rule set is.

The first ticket needs exactly six items, and with those six it is processed immediately: start and end time with time zone, the affected IP address and port, the measured packet rate with a direction, the measured bandwidth with a direction, the average packet size, and the protocol distribution with the notable source ports. Attach the archive or offer it. Everything else, in particular the question of who is behind it, does not belong in this ticket.

Step 2: the abuse desk of the source network

This report does not stop your attack. It works more slowly and at a different point: it gets a publicly reachable service closed or a compromised device cleaned up. Every amplifier that gets closed permanently reduces the amplification capacity available worldwide. That is the only lever that changes anything in the long run, and it only works because many affected operators pull it.

Report once per source network, not once per address. Twenty separate mails to the same abuse desk are classified as bulk and filed together. One mail listing twenty addresses of the same network gets processed.

Step 3: the police

Filing a criminal complaint is the slowest route and the only one with any power to compel. Only an authority can require subscriber data from a provider, and only through an authority do many small incidents turn into a case against the operator of an attack service. Do not expect a fix for your acute problem, expect a case reference and one building block in a larger picture.

How to find the abuse desk responsible

Responsibility follows from the address, not from a company name. Every public IP address is registered in the database of one of the five Regional Internet Registries, and the abuse desk is recorded there.

The five databases and their regions

The registries are RIPE NCC for Europe, the Middle East and parts of Central Asia, ARIN for North America, APNIC for the Asia Pacific region, LACNIC for Latin America and the Caribbean, and AFRINIC for Africa. You do not need to know which one applies: a whois query is referred to the correct database automatically.

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

The first line returns the entry at the responsible registry including the abuse contact. The second queries a public service that additionally names the autonomous system, the announced prefix and the country. The autonomous system is the field with which you group several addresses under the same network operator and turn twenty separate reports into one.

The fields that matter

The field names differ per registry, the meaning is always the same. In the RIPE database abuse-c: points to a role object whose abuse-mailbox: holds the authoritative address; at ARIN it is directly in OrgAbuseEmail:; APNIC uses abuse-c: and additionally an irt: object for the response team. Write to that address only. The technical or administrative contact in the same entry is a personal address and not an abuse desk, and a report sent there counts as unsolicited mail.

Also mind the nesting: an inetnum entry can describe a smaller customer network inside a larger operator network. The entry that encloses your address most tightly is the right one. If it holds no abuse contact, move one level up to the surrounding network.

When the entry holds nothing usable

Three fallbacks, in this order. First the surrounding, larger network from the whois entry, usually the network operator itself. Second the customary collective address in the form abuse@ plus the operator domain, which many networks maintain even when it is not in the database. Third, if a website runs behind the address, the file /.well-known/security.txt as defined by RFC 9116: it contains a Contact: field. That route is designed for vulnerability reports rather than abuse reports, but it often reaches a human when nothing else does.

A note on formats: RFC 5965 defines the Abuse Reporting Format, a machine readable form of such reports. It was designed for email abuse and is rarely evaluated by network operators for network attacks. For a DDoS incident, a clearly structured plain text mail with fixed fields is the format that actually gets read.

What an abuse report has to contain

The seven mandatory items

If one of these seven is missing, the most common response is a follow-up question, and the second most common is none at all.

1. Timestamps for start and end, with time zone. UTC in ISO 8601 form, that is 2026-09-28T20:14:37+00:00. Plus a statement on whether the system clock was synchronized.
2. The affected address and port. Your own public IP address and the target port, not a domain name. The recipient searches for addresses.
3. The source address. One per report, or a list of addresses from the same network. Not a collection from thirty different networks in one mail.
4. Protocol and source port. UDP or TCP, plus the source port, because in a reflection attack it proves the type.
5. Volume. Bandwidth and packet rate, each with a direction and, where possible, as the figure for that one source rather than only as a grand total.
6. Your assessment of the source. Whether you consider the address genuine or forged, and that you are not accusing its holder.
7. Raw data attached or on request. The bounded capture, the readable excerpt from it, the counters and the checksum of the archive.

A template to copy

Abuse desks work internationally, so a report in English is read in a network whose operator speaks no German. Replace the placeholders with your measured values; the addresses in the example come from the ranges reserved for documentation.

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

What to leave out

Four things ruin a good report. Threats of any kind, including implied ones, because the report then goes to the legal department instead of to engineering. Deadlines, because you cannot set one for a network you have no relationship with. Speculation about who is behind the attack, because it is unproven and devalues the factual part. And unsolicited attachments of several hundred megabytes, because they are rejected automatically. Offer large files instead of sending them.

Also leave out: screenshots as the sole evidence, extracts containing personal data of your own users, and internal host names or paths that have nothing to do with the matter. A report that contains only what it is meant to prove gets processed faster.

Filing a criminal complaint

Where to file it

In Austria as in Germany every police station accepts a criminal complaint, as does the public prosecutor's office. You do not have to determine local jurisdiction yourself, the transfer happens internally. Several German federal states additionally run an online police portal for filing over the internet; which one applies to your location is stated on the website of your state police force. For companies, each German state criminal police office runs a central point of contact for cybercrime, to be found on the website of the state criminal police office of your federal state. In Austria the Federal Criminal Police Office operates a reporting office for cybercrime whose current contact route is published on the website of the Ministry of the Interior.

This article deliberately names no specific addresses, numbers or form links. Such details change, and an outdated address costs you more time than searching on the official site takes.

What to bring

Bring the incident in a form a person without systems knowledge can read, and the raw data as an appendix. Specifically: one page of plain prose describing the facts, with the time window, the affected service, the impact and the damage; the evidence archive on a data carrier or as a file, with the checksum list; a list of which file shows what, because nobody opens a packet capture without knowing what they are supposed to see in it; the abuse reports you already sent, with their ticket numbers, because they document your own diligence; and a traceable calculation of the damage, that is downtime, lost revenue, extra cost for countermeasures and working hours.

The amount of damage is not a side note. In both countries it determines the sentencing ranges, and in practice it determines whether a case is pursued or dropped. Do not estimate, calculate, and enclose the calculation.

Why a complaint is worthwhile even against persons unknown

The most common objection is: but I do not know who did it. That is exactly why a complaint against persons unknown is the normal case and not a defect. Three reasons to file anyway.

First, cases against the operators of attack services almost never grow out of one large incident, they grow out of many small complaints showing the same pattern. The international actions against booter and stresser services that Europol has repeated for years under the name Operation PowerOFF are built on consolidated individual cases and on the seized customer databases of the platforms taken down. Your complaint is a data point in that collection.

Second, a complaint is the precondition for anyone being allowed to request data at all. Without proceedings no provider hands over subscriber data, and without that data every suspicion stays unproven.

Third, you need the case reference for your own purposes: towards your insurer, towards customers to whom you have to explain an outage, towards a provider of infrastructure, and in case the attack continues and you later want to establish a connection.

The special case with a ransom demand

If the attack comes with a demand for payment, two things change. You now have a trace that would otherwise not exist, and you have an additional criminal offense. Both belong explicitly in the complaint.

In practice that means: do not pay. Paying funds the next wave and marks you as a target known to pay. Preserve the message in its raw form as a file, not as a screenshot, because only the raw form contains the complete chain of Received header lines and with it the path the message took. For an email, save it as a file; for a message in a chat or on a platform, additionally record the sender identifier and the message identifier. Note every payment address given exactly as written, character by character. Do not reply and do not negotiate, not even for appearances.

The legal basis in Austria and Germany

In Austria a DDoS attack falls under section 126b of the Criminal Code (StGB), "disruption of the functionality of a computer system". The basic offense carries imprisonment of up to six months or a fine of up to 360 daily rates. If the disruption lasts for a longer period, it is up to two years. If many systems are attacked with a program that was evidently created for that purpose, it is up to three years. And where the damage exceeds 300,000 euros, where critical infrastructure is attacked or where the offender acts as a member of a criminal organization, the range is six months to five years. In addition, section 126c StGB already criminalizes the production, distribution and provision of the programs intended for it.

In Germany section 303b StGB applies, "computer sabotage": up to three years of imprisonment or a fine, up to five years where the data processing serves a business, an enterprise or a public authority, and in particularly serious cases six months to ten years, for example where the offender acts commercially or impairs critical infrastructure. The attempt is punishable, and for preparatory acts section 303b subsection 5 StGB refers to section 202c StGB.

Liability is not limited to whoever runs the attack technically, it extends to whoever orders it. The note on a booter site that the offering is only for load testing your own systems changes nothing, because those services do not check who owns the target entered. This section reflects the state of the law and is not legal advice.

What realistically happens and what does not

The honest part, so that you set your expectations correctly and report anyway.

No provider will name their customer. Asked who owns 203.0.113.5, you get no answer, and that is as it should be. Subscriber data is released only on an order from an authority. What you can get is confirmation that the report was followed up, and sometimes the information that an open service was closed.

Forged sources are practically untraceable. Establishing the real origin of a packet with a forged sender would require every transit network along the path to measure simultaneously while the attack runs. That does not happen for a single incident. In a reflection attack the chain is broken anyway, because the queries to the amplifier never crossed your network.

Services abroad require mutual legal assistance. If the operator of an attack service sits outside the country where you file, every request for data runs through a mutual legal assistance request, and within the European Union through a European Investigation Order. Both take time, and neither is something you influence.

Many abuse reports go unanswered. Not every abuse desk replies, some only acknowledge receipt automatically, some do nothing visible at all. That does not necessarily mean nothing happened.

Why it is still worth it, in four sentences. The report to your own provider works directly and quickly, and that is the part that makes your service reachable again. The report to the source network permanently reduces the amplification capacity available for the next attack, for everyone. The criminal complaint supplies the data point that, together with others, turns into a case. And your own documentation is what lets you tell within five minutes, during the second attack, whether it is the same pattern.

What to do in parallel so the service comes back

Reporting and restoring are two separate jobs, and the second does not wait for the first. As soon as the evidence archive is written, attention belongs to operations.

• Determine which layer is being hit. The full diagnostic path using ss, packet counters, kernel messages and web server logs is in Detect a DDoS attack on your server.
• Work through the ongoing severe attack. The order from first measurement through closing the management ports to rate limiting is in What to do during a severe DDoS attack.
• Catch up on the basics. Rule set, SYN cookies, connection tracking and rate limiting per source address are in How to protect your server from DDoS attacks.
• Understand what you are looking at. Attack layers, amplification factors and the physical limits are in What is a DDoS attack.
• Make sure it is recorded automatically next time. A continuous measurement gives you the baseline without which you cannot say whether 40,000 packets per second was a lot. The setup is in Set up monitoring for a single server.

A note on changing your IP address, because it is often the first idea in this situation: it only works as long as the new address does not become public again, and a forgotten old DNS record makes it pointless. It also destroys the link between the evidence you have and the attack that is still running. Change the address after the archive is written, not before.

What KernelHost puts up against it

The always-on protection included with every server

DDoS protection at KernelHost is built in two layers and permanently active, with nothing for you to order, switch on or configure:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are scrubbed close to their source, before they reach the datacenter.
• Layer 2: Arbor real-time filtering with 3.2 Tbps on site in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are detected and dropped, packet by packet.

Two properties matter for the evidence you can collect. The protection runs permanently and does not have to react to an attack first, so there are no opening minutes in which the service is gone. And no null-routing is used: your IP address stays on the network, only the malicious packets are dropped. If a provider instead takes the attacked address off the network, the result for you is identical to a successful attack, and during the block you cannot even measure any more. The real-time filtering is located in Frankfurt am Main. The protection is included in every server package at no surcharge, from the KVM root server to the dedicated server.

Advanced DDoS Protection for projects under constant fire

Some projects are attacked not occasionally, but deliberately and for weeks on end. For those there is Advanced DDoS Protection from €50.00 per month, PrePaid, with no minimum term and no setup fee. The difference is not more capacity, it is control:

• A dedicated protected IP from the Frankfurt core, which your server is switched over to inside our own network. Nothing has to be rebuilt on your side.
• Self-managed protection rules per port and protocol in the customer panel, without a ticket: the service port gets different rules than the query port.
• Changes take effect in real time, so you can fine-tune in the middle of an ongoing attack while preserving evidence in parallel.
• Protection profiles that match the application, including custom and modified services on any TCP or UDP port.

Advanced DDoS Protection is for servers running at KernelHost. If your project is hosted elsewhere and attacked continuously, moving to KernelHost is the route by which you get the protection.

The two tiers compared

If your project already runs at KernelHost, take the six items from step 1 to the ticket system in the customer panel. The filtering is running anyway; the ticket makes sure the rules for your address are fine-tuned and that you receive the measurements taken on the network side for your report and your complaint.

Common mistakes when reporting

"I rebooted first and then had a look." The reboot set every counter to zero. From that point there is no proof left for packet rate, drops and connection states, and the load is back within seconds.

"I reported all 300 addresses from the capture individually." That is classified as bulk mail. Group by autonomous system or by network block and write one mail per network with a list.

"I reported the top IP from the frequency list." In a reflection attack that is the most heavily abused amplifier, so the most heavily affected additional victim, not the attacker.

"I sent a screenshot of the graph." Without a time zone and without the averaging interval the image cannot be used as proof of a peak load. Supply numbers, and the image only in addition.

"The ticket said the server had been slow." Without a timestamp, an address, a port and a measurement nobody can look at the right place in their logs. Processing only starts after the first round of questions.

"I gave them a deadline of 24 hours." You cannot set one for a network you have no relationship with. The report then goes to the legal department and not to engineering.

"I attached the 900 MB capture." The mail was rejected by the size limit and nobody ever saw the report. Offer large files instead of sending them.

"I wanted to collect everything properly and reported on the weekend." By then the other side often cannot verify anything any more. The report has to go out while the incident is fresh, even if it is not complete.

In brief

• The evidence that matters exists only while the attack is running: kernel counters, socket states, firewall counters and the traffic graph at fine resolution are smoothed or gone later. Preserving comes before reporting.
• The first ten minutes belong to seven commands: date -u --iso-8601=seconds, ip -s link, ss -s, nstat -az, sar -n DEV 1 10, nft list ruleset and a tcpdump -w bounded with -c.
• A screenshot of the traffic graph is the weakest format: no numbers to recompute, no time zone, no averaging interval. Raw data with timestamps is the proof, the image only the illustration.
• In an amplification attack the source address in the capture belongs to an abused third party, and in a botnet attack to a compromised device. Reporting it means, as a rule, reporting another victim.
• An address is only proven genuine where a TCP handshake completed, that is for connections in state ESTABLISHED and for complete HTTP requests. Every UDP packet and every SYN can be forged.
• The order is: your own provider, because only they can filter in front of the server; the abuse desk of the source network, found through whois and the fields abuse-c, abuse-mailbox or OrgAbuseEmail; then the police.
• An abuse report needs seven items: timestamps with time zone, the affected address and port, the source address, protocol and source port, volume, your assessment of the source, and raw data attached or on request.
• A complaint against persons unknown is the normal case and still worthwhile: cases against operators of attack services grow out of many small complaints, and without proceedings nobody may request data.
• Realistically: no provider names customer data without an order from an authority, forged sources are untraceable, services abroad require mutual legal assistance, and many abuse reports go unanswered.
• At KernelHost the two-layer always-on protection is included in every server package at no surcharge and active from provisioning, with no null-routing: 17 Tbps of mitigation capacity in the global scrubbing network plus Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Advanced DDoS Protection adds a dedicated protected IP and self-managed rules per port from €50.00 per month.
• This article describes the path and reflects the state of the law. It is not legal advice, and it deliberately names no addresses of authorities, it shows how to find the office responsible for you.