Wat betekent een VPS abuse-melding voor uw server?

Wat een VPS abuse-melding daadwerkelijk is

Een VPS abuse-melding is een rapport over netwerkverkeer dat afkomstig is van uw IP-adres. Dit rapport wordt verzonden naar het abuse-contactadres dat is gepubliceerd voor dat IP-blok, waarna uw hostingprovider het aan u doorstuurt met een termijn voor een reactie. Het gepubliceerde contactadres behoort toe aan het bedrijf dat de IP-adresruimte beheert; de eerste persoon die een rapport over uw server leest, bent u daarom bijna nooit. Uw host koppelt het IP-adres en de tijdstempel aan uw account en stuurt de melding door.

De melding is geen bewijs dat u opzettelijk iets heeft gedaan. Een IP-adres is de enige identificator waarover de melder beschikt. Een gecompromitteerde applicatie die om 03:00 uur spam verstuurt, levert hetzelfde rapport op als een persoon die om 03:00 uur spam verstuurt. Daarom is uw reactie het belangrijkste onderdeel. U wordt gevraagd wat de bron was en welke wijzigingen u heeft doorgevoerd.

Wie verstuurt het rapport en hoe bereikt dit uw host

Elk openbaar IP-blok is geregistreerd bij een regionale internetregistratie (RIR): RIPE NCC, ARIN, APNIC, LACNIC of AFRINIC. Elke registratie publiceert een abuse-contactadres en daar worden de rapporten naartoe gestuurd. U kunt hetzelfde record inzien als de melder:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE-records bevatten een abuse-c: role-object met een abuse-mailbox:-regel. ARIN-records bevatten OrgAbuseEmail:. Het adres dat daar wordt gepubliceerd, ontvangt de klacht. Daarom komt een rapport over uw server aan bij uw host in plaats van in uw eigen inbox.

De partij die de melding indient, is meestal een machine. Vier soorten dekken vrijwel alles wat u zult tegenkomen:

• Geautomatiseerde scanners en honeypots. Een machine registreert een verbindingspoging vanaf uw IP-adres en dient een rapport in met het bijbehorende logfragment.
• Feedback loops (FBL) beheerd door mailboxproviders. Een ontvanger klikt op de knop voor ongewenste e-mail en een kopie van het bericht komt terug in ARF (abuse reporting format), een gestructureerd e-mailformaat dat is ontworpen voor machineverwerking.
• Auteursrechtagenten. Zij monitoren torrent-swarms of crawlen openbare URL's en sturen vervolgens een DMCA-kennisgeving (digital millennium copyright act) met daarin de naam van een bestand, uw IP-adres en een tijdstempel in UTC.
• Blocklist-operators en netwerkengineers, die een kort bericht sturen met de relevante regels uit hun eigen logs.

Omdat de meeste eerste rapporten automatisch worden gegenereerd, heeft een discussie in uw antwoord geen zin. Feiten bereiken alles: wat er draaide en wanneer het is gestopt.

Waarom bevat de melding een deadline

Uw host is ook een huurder. De adresruimte bevindt zich achter upstream-providers en in reputatiedatabases die door anderen worden beheerd. Meldingen die onbeantwoord blijven, verhogen de score voor het gehele blok in plaats van alleen voor uw specifieke adres. De deadline die u ontvangt, is daarom druk die wordt doorgegeven. Neem de termijn in de melding serieus en beschouw deze als bindend.

Wanneer er bij een onbeantwoorde zaak actie wordt ondernomen, betreft dit meestal een null route, waarbij verkeer naar dat specifieke IP-adres upstream wordt geweigerd, of een schorsing van de instantie. De aanleiding is doorgaans het uitblijven van een reactie, niet het oorspronkelijke incident. Wat een specifieke host doet en wanneer, staat beschreven in het eigen beleid en in de melding zelf. Deze twee documenten zijn de enige die als referentie dienen; onderneem daarom geen actie op basis van wat er op een forum wordt beweerd over het beleid van een provider.

Uitgaande spam: waarom verstuurt mijn VPS e-mail die ik niet heb verzonden

Het rapport geeft aan dat uw IP-adres e-mail heeft afgeleverd bij een spam-trap, of dat ontvangers uw e-mail als ongewenst hebben gemarkeerd. Vier bronnen verklaren de meeste gevallen: een webapplicatie met een mailformulier zonder snelheidsbeperking, een gelekt SMTP-wachtwoord dat nu door iemand anders wordt gebruikt, een mailserver die relays toestaat voor hosts waarvoor dat niet zou moeten, en een gestolen inloggegevens van een nieuwsbriefapplicatie. Begin bij de wachtrij, omdat een gecompromitteerde afzender daar meestal zichtbaar is:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Een wachtrij met duizenden berichten naar adressen die u niet herkent, betekent dat de server aan het verzenden is. Zoek vervolgens uit wie er is geauthenticeerd:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Eén account met een aantal dat ver boven de rest uitsteekt, is het gelekte account. Als /var/log/mail.log niet bestaat, is rsyslog niet geïnstalleerd op het systeem en staan dezelfde regels in de journal: sudo journalctl -t postfix --since '2 days ago'.

Als er niets is geauthenticeerd, is de afzender een lokaal proces. Controleer de relay-regels en de openstaande verbindingen:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Een standaard Postfix-installatie op Debian of Ubuntu fungeert niet als relay voor vreemden. Het wordt een open relay wanneer mynetworks handmatig wordt verbreed naar een volledig hosting-subnet, omdat elke andere huurder op dat subnet dan wordt vertrouwd om via u te verzenden. Elke verbinding met poort 25 die eigendom is van een proces dat niet uw mailserver is, is een script dat zelfstandig e-mail verstuurt; dit is wat een gecompromitteerde PHP-applicatie doorgaans doet.

Stop de stroom voordat u onderzoek doet en bewaar het bewijsmateriaal:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL maakt de wachtrij leeg, maar vernietigt ook het overzicht van wat er is verzonden; maak dus eerst een kopie. Roteer vervolgens alle inloggegevens die de applicatie gebruikt, update de applicatie en zoek naar wat de indringer heeft achtergelaten. Een spam-incident en een inbreuk zijn meestal hetzelfde voorval; doorloop daarom de herstelstappen voor een gehackte VPS in plaats van alleen de wachtrij te legen.

Portscanning en brute force: hoe een gecompromitteerde container eruitziet

Dit rapport bevat regels uit de logs van een andere beheerder, en die zien er als volgt uit:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

De oorzaak is bijna altijd een service waarvan u dacht dat deze door de firewall werd afgeschermd. Docker is hierbij een veelvoorkomende boosdoener. Het publiceren van een poort met -p 6379:6379 schrijft regels naar de DOCKER-USER en nat chains. Deze worden geëvalueerd vóór de regels van ufw, waardoor ufw deny 6379 het verkeer niet blokkeert en de database antwoordt aan het gehele internet.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

Alles in ss -ltnp dat is gebonden aan 0.0.0.0 of [::] luistert op het publieke adres. Publiceer in plaats daarvan naar het loopback-adres, -p 127.0.0.1:6379:6379, wanneer alleen de host de service hoeft te bereiken. Waar een database in de eerste plaats zou moeten draaien is een afzonderlijke beslissing, en het draaien van de database in Docker of op de host behandelt die afweging.

Om te zien of uw eigen server op dit moment aan het scannen is:

sudo ss -tnp state syn-sent

Veel half-open verbindingen naar veel verschillende bestemmingen duiden op een actieve uitgaande scan. Een kernel-log die volloopt met nf_conntrack: table full, dropping packet bevestigt hetzelfde vanuit een ander perspectief: er is een proces dat veel meer verbindingen opent dan waarvoor deze server enige reden heeft.

Bouw een gecompromitteerde container opnieuw op in plaats van deze op te schonen. U kunt niet bewijzen wat er nog meer in de container is gewijzigd, dus bouw opnieuw op vanaf een image die u vertrouwt, herstel alleen data die u vertrouwt en roteer de keys die de container bevatte.

Auteursrechtelijke kennisgevingen: welk bestand is daadwerkelijk ingezien

Een DMCA-kennisgeving vermeldt een URL of een torrent info hash, uw IP-adres en een tijdstempel in UTC. Bijna alle meldingen zijn terug te voeren op twee oorzaken: een map die de webserver publiekelijk indexeert met mediabestanden erin, of een torrent-client die nog steeds bestanden deelt (seeding) nadat de download is voltooid.

Vergelijk de tijdstempel met het toegangslogboek. Het nginx combined log-formaat plaatst de status in veld 9 en het verzoekpad in veld 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Controleer de klok voordat u concludeert dat er niets is geserveerd. De kennisgeving is in UTC en uw logs gebruiken de tijdzone van de server; een tijdsverschil van enkele uren zorgt ervoor dat u in het verkeerde tijdsvenster zoekt en een fout-negatief resultaat rapporteert:

timedatectl
sudo timedatectl set-timezone UTC

Verhelp vervolgens de oorzaak. Verwijder of beperk het bestand, schakel directory listing uit met autoindex off; in het nginx location-blok en bind de torrent-client aan een interface die niet de publieke interface is. Reageer door het bestand, de wijziging en het tijdstip van de wijziging te benoemen. Als u van mening bent dat de claim zelf onjuist is, dan is dat een juridische kwestie tussen u en de afzender; de kennisgeving vermeldt hoe u deze kunt betwisten. Uw hostingprovider is niet de partij die hierover beslist, dus een ticket waarin u de inhoudelijke gronden betwist, zal niet leiden tot een oplossing.

Blocklist-vermeldingen: waarom werkt mijn uitgaande e-mail niet meer

Dit probleem manifesteert zich vaak doordat u helemaal geen e-mail meer ontvangt. Uitgaande e-mail wordt simpelweg niet meer geaccepteerd en de bounce-melding bevat de reden:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

Controleer een vermelding door de vier octetten van het IP-adres om te draaien en de zone van de lijst op te vragen:

dig +short 10.113.0.203.zen.spamhaus.org

Een leeg antwoord betekent dat u daar niet vermeld staat. Een 127.0.0.x-antwoord betekent dat u wel vermeld staat, waarbij het laatste octet aangeeft welke sublijst overeenkwam. Een antwoord in het 127.255.255.x-bereik betekent dat de query werd geweigerd in plaats van beantwoord; dit gebeurt meestal omdat de query via een grote publieke resolver verliep, die door de gratis dienst niet wordt ondersteund. Voer het commando opnieuw uit vanaf de eigen resolver van de server om een correct resultaat te krijgen.

Verwijdering van de lijst gebeurt op de website van de beheerder van de lijst, niet via uw hoster. Dit is alleen zinvol als de bron eerst is hersteld, omdat de valstrik die u heeft aangemeld u bij het volgende bericht opnieuw zal aanmelden. Twee andere factoren bepalen of e-mail daarna weer wordt verwerkt. Uw PTR-record, de reverse DNS-naam voor het IP-adres, wordt beheerd door uw hoster; vraag hen om een record in te stellen dat terugverwijst naar hetzelfde adres en gebruik die naam als uw HELO. Een adres dat is overgenomen van een vorige huurder kan bovendien een geschiedenis met zich meebrengen die u niet zelf heeft veroorzaakt; het is de moeite waard om hiernaar te vragen voordat u een week besteedt aan het herschrijven van DNS-instellingen. Het correct instellen van SPF (sender policy framework) en DKIM (domainkeys identified mail) records, plus het DMARC-beleid dat deze verbindt, wordt volledig behandeld in de handleiding voor het draaien van een eigen mailserver met Mailcow.

Relay-infrastructuur, waarbij misbruikmeldingen bij het werk horen

Als u een Tor-exitnode, een publieke VPN of een proxy voor anderen beheert, zijn klachten over verkeer dat u niet zelf heeft gegenereerd een normale operationele kostenpost. Het doel is om zichtbaar als relay te fungeren in plaats van als een gecompromitteerde server. Stel reverse DNS in op een beschrijvende naam, host een korte mededeling op poort 80 waarin wordt uitgelegd wat het adres is, beantwoord misbruikmeldingen snel met dezelfde uitleg en gebruik de beleidsopties van de software om de poorten die de meeste meldingen genereren te blokkeren. Draai de service op een eigen IP-adres en idealiter in een eigen instantie, zodat een null route op dat adres niet uw webapplicatie platlegt. Overleg met uw host voordat u begint, aangezien de regels per bedrijf en soms per IP-blok verschillen; dit is een vraag voor hen en niet voor een forumdiscussie. Het draaien van een Tor-exitnode op een VPS behandelt het exit-beleid en de mededelingpagina in detail.

Hoe u reageert zodat het ticket wordt gesloten

• Publiceer een contactadres dat door een persoon wordt gelezen. RFC 2142 maakt abuse@ en postmaster@ op uw domein de adressen die melders als eerste proberen. Host die mailbox ergens anders dan op de server die het beschermt, omdat een opgeschorte instantie de melding dat deze is opgeschort niet kan afleveren.
• Bewaar logs lang genoeg om te kunnen antwoorden. Een melding over verkeer van twaalf dagen geleden is onbeantwoordbaar als de log na zeven dagen is geroteerd. Controleer journalctl --disk-usage, stel MaxRetentionSec=90d in binnen /etc/systemd/journald.conf en voer vervolgens sudo systemctl restart systemd-journald uit. Web- en maillogs roteren volgens hun eigen schema onder /etc/logrotate.d/.
• Houd de server op UTC, zodat een tijdstempel in een melding overeenkomt met een tijdstempel in uw logs zonder dat u berekeningen hoeft uit te voeren.
• Scheid wat klachten uitlokt van wat u niet kunt verliezen. E-mail op het ene adres, de webapplicatie op het andere, relay-services op hun eigen instantie. Actie ondernomen tegen een IP is actie ondernomen tegen alles wat zich daarachter bevindt.
• Antwoord binnen de gestelde termijn, zelfs als het onderzoek nog niet is afgerond. Een voorlopig antwoord met daarin een tijdstip is een volledig antwoord voor de eerste ronde.

Een eerste reactie die de meeste tickets sluit, is kort en specifiek:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Zeg wat u weet en zeg wat u nog niet heeft uitgezocht. Stilte wordt geïnterpreteerd als een niet-onderhouden server, en het escalatiepad is bedoeld voor niet-onderhouden servers. Of dit werk tot uw verantwoordelijkheid behoort, hangt af van het product dat u heeft gekocht; dit is het praktische verschil tussen managed en unmanaged VPS hosting. Bij een unmanaged abonnement is de huurder het beveiligingsteam.

Hoe dit eruitziet als het goed verloopt

Een abuse-melding is in de eerste plaats een routeringsprobleem. Een melding over een IP-adres gaat naar de partij die verantwoordelijk is voor dat adres en wordt doorgegeven aan de persoon die het kan oplossen. De onderdelen waar u controle over heeft, zijn uw contactadres, uw logretentie, de manier waarop uw services over IP-adressen zijn verdeeld en hoe snel u reageert. Als u deze zaken op orde heeft, eindigen de meeste meldingen na één uitwisseling. Dezelfde gewoontes beantwoorden de bredere vraag over of VPS-hosting veilig is, omdat een server die niemand in de gaten houdt, uiteindelijk in de logs van iemand anders belandt.

FAQ

Betekent een abuse-melding dat mijn VPS is gehackt?

Niet per definitie, maar dat is wel het eerste wat u moet uitsluiten. De melding bewijst alleen dat er verkeer vanaf uw IP-adres is verzonden. Uitgaande spam en port scanning zijn veel vaker afkomstig van een gecompromitteerde applicatie of container dan van de accounteigenaar zelf. Controleer daarom als eerste de mailwachtrij met sudo postqueue -p en de openstaande netwerkpoorten met sudo ss -ltnp. Meldingen over auteursrechten en blocklists hebben een ander karakter: deze wijzen meestal op iets dat u bewust uitvoert.

Hoe lang heb ik de tijd om te reageren op een abuse-melding?

De termijn staat vermeld in de melding die u heeft ontvangen en verschilt per hoster en per categorie. Meldingen over auteursrechten en spam-traps hebben doorgaans de kortste termijnen. Beschouw de genoemde tijd als strikt en stuur een korte ontvangstbevestiging voordat de termijn verloopt, ook als u de oorzaak nog aan het onderzoeken bent. Voor de medewerker die het ticket behandelt, is het essentieel dat er een mens aan het werk is en dat het verkeer is gestopt.

Mijn IP-adres staat op een blocklist. Kan mijn hoster dit verwijderen?

Nee. Verwijdering van een lijst wordt gedaan door de beheerder van die specifieke lijst op hun eigen website; uw hoster heeft geen controle over hun database. Uw hoster beheert wel het PTR-record, de reverse DNS-naam voor uw IP-adres. Dit is een apart verzoek dat u tegelijkertijd kunt indienen. Los het verzendprobleem op voordat u een verzoek tot verwijdering indient, omdat de spam-trap die u heeft gelist u bij het volgende bericht opnieuw zal toevoegen.

Moet ik mijn hoster vertellen wat er precies is gebeurd?

U moet voldoende informatie verstrekken om het ticket te kunnen sluiten: wat de bron was en wanneer het verkeer is gestopt. U hoeft geen forensisch rapport of gegevens van uw gebruikers te overleggen. Een vaag antwoord is slechter dan een beknopt antwoord, omdat een medewerker die niet kan zien wat er is veranderd, geen reden heeft om de zaak als opgelost te beschouwen.

Kan ik een geautomatiseerde melding van een scanner negeren?

Nee. Geautomatiseerde meldingen worden geteld en herhaalde meldingen over één IP-adres verhogen de score tegen het gehele IP-blok van uw hoster. Dit is wat een kleine zaak laat escaleren. Uw reactie kan uit één alinea bestaan. De geautomatiseerde melder leest deze doorgaans nooit, maar de medewerker die het ticket bij uw hoster behandelt wel. Die persoon beslist wat er met uw instantie gebeurt.