Kort gezegd: Geautomatiseerde aanvallen op webservers verlopen in golven: programma's doorzoeken het internet naar bereikbare servers, delen ze in op grond van uiterlijke kenmerken en proberen bekende lekken zoals PHP2Shell massaal uit. De omvang van het bedrijf speelt daarbij geen rol. Bescherming bieden gepatcht PHP, een klein aanvalsoppervlak en een bewaking die geslaagde treffers snel opmerkt.
Het begin: „Wie zou zich voor onze website interesseren?”
Die vraag horen wij na PHP2Shell vaak, vooral van kleinere bedrijven. Het eerlijke antwoord: waarschijnlijk niemand persoonlijk. Maar dat is bij lekken van dit soort ook niet nodig. De aanvallen worden uitgevoerd door programma's die niet naar namen zoeken, maar naar gelegenheden.
Het BSI (de Duitse federale dienst voor informatiebeveiliging) rekende bij PHP2Shell op snel, grootschalig misbruik. Cloudflare meldde aanvalspogingen en dat aanvallers hun patronen veranderden om beschermingsregels te omzeilen. Beide past bij wat bij kritieke lekken in wijdverbreide software regelmatig gebeurt.
Hoe geautomatiseerde aanvallen op webservers verlopen
Geautomatiseerde campagnes volgen meestal een vergelijkbaar patroon. Het volgende overzicht beschrijft de fasen in het algemeen, zonder aanvalsdetails:
| Fase | Wat er gebeurt | Wat ertegen helpt |
|---|---|---|
| Zoeken | Programma's controleren grote adresbereiken of openbare registers zoals certificaatlogs op bereikbare webservers | weinig openbaar bereikbare systemen, inventaris van alle adressen |
| Indelen | Antwoorden worden geanalyseerd: webserver, PHP-versie, CMS, typische paden | versievermeldingen verbergen, onnodige bestanden verwijderen |
| Uitproberen | bekende lekken worden massaal getest, vaak zonder voorafgaande indeling | actueel PHP, herstart, WAF als extra laag |
| Vastzetten | bij succes wordt een achterdeur geplaatst, bijvoorbeeld een webshell of een cronjob | beperkte schrijfrechten, geen PHP-uitvoering in uploadmappen |
| Te gelde maken | de server wordt gebruikt, bijvoorbeeld voor spam, cryptomining, doorverwijzingen of gegevensdiefstal | bewaking van processen, bestanden en uitgaande verbindingen |
Belangrijk is de derde regel. Veel campagnes nemen niet eens de moeite servers vooraf nauwkeurig in te delen. Ze proberen eenvoudig alles uit wat bereikbaar is. Daarom beschermt onopvallendheid alleen niet.
Waarom aanvallen in golven komen
Geautomatiseerde campagnes lopen zelden één keer en dan nooit meer. Typisch is een patroon in golven. De eerste golf volgt kort na het bekend worden van een lek, vaak nog met onvolgroeide tools. Verdere golven komen als aanvallers hun tools verbeteren of aanpassen aan beschermingsregels. Cloudflare heeft bij PHP2Shell precies dat waargenomen: veranderde aanvalspatronen om de regels te omzeilen.
Voor u betekent dat: een server die de eerste golf ongedeerd heeft doorstaan, is niet blijvend veilig zolang hij ongepatcht is. En een nieuw opgezette server is doelwit vanaf het moment dat hij bereikbaar is. Wie bijvoorbeeld een nieuw TLS-certificaat laat uitgeven, maakt de naam zichtbaar in openbare certificaatlogs, die ook scanners analyseren. Een nieuw systeem hoort daarom pas aan het net als het al is bijgewerkt.
Waarom kleine bedrijven net zo getroffen worden
Voor geautomatiseerde aanvallen telt niet de waarde van een afzonderlijk doelwit, maar het aantal. Een server van een klein bedrijf biedt rekenkracht, een domein met een goede reputatie, mailverzending en soms klantgegevens. Voor aanvallers is dat genoeg.
Daar komt bij: kleinere bedrijven hebben vaak geen eigen IT die updates direct inspeelt. Hun servers blijven langer kwetsbaar en belanden daarom vaker in de resultaatlijsten van scanners. Wie als eerste patcht, valt uit die lijsten.
Een ander punt is de toeleveringsketen. Veel kleine websites staan op servers van bureaus of kleine hostingproviders, waarop tientallen klantprojecten naast elkaar draaien. Voor aanvallers is zo'n server bijzonder lonend, omdat één enkele treffer veel websites tegelijk raakt. Uw risico hangt dan niet alleen af van uw eigen zorgvuldigheid, maar ook van die van uw dienstverlener.
Scans in uw logs zijn normaal en geen bewijs van een inbraak. Een geslaagde aanval toont zich aan andere sporen: nieuwe bestanden, vreemde processen, onbekende accounts, ongewone uitgaande verbindingen.
Wat u zelf kunt controleren
Een blik in de logs toont hoe sterk uw server wordt gescand. De volgende opdrachten lezen alleen en wijzigen niets:
# De tien adressen met de meeste verzoeken in het actuele toegangslog
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Verzoeken die met "niet gevonden" zijn beantwoord, naar frequentie
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Geeft de server zijn PHP-versie prijs in de header?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Veel verzoeken naar niet bestaande paden zijn typische scanruis. Alerter moet u worden als op zulke verzoeken plotseling geslaagde antwoorden volgen, als in uploadmappen bestanden worden opgeroepen die u niet kent, of als de webservergebruiker processen start die hij anders nooit start. Bevestigde herkenningskenmerken speciaal voor PHP2Shell bestaan tot nu toe niet, de beoordeling berust daarom op zulk afwijkend gedrag. Hoe u logs grondiger analyseert, beschrijft de gids Webserverlogs analyseren. Toont de derde opdracht een PHP-versie, dan loont de instelling expose_php = Off; achtergronden staan onder Versievermeldingen verbergen.
De beschermingslagen in de juiste volgorde
- PHP bijwerken en herstarten: Zonder deze stap blijven alle andere maatregelen lapwerk.
- Aanvalsoppervlak verkleinen: ongebruikte websites, testsystemen en oude microsites uitschakelen of achter een aanmelding plaatsen.
- Regels aan de rand: Een Web Application Firewall met een onderhouden regelset, bijvoorbeeld de OWASP Core Rule Set met ModSecurity, vangt een deel van de pogingen op.
- Herhaalde pogingen afremmen: Tools zoals Fail2ban blokkeren adressen die opvallend veel fouten veroorzaken. Tegen verspreide scans helpt dat maar beperkt.
- Bewaken: Processen van de webservergebruiker, nieuwe PHP-bestanden en uitgaande verbindingen in het oog houden, zodat een geslaagde treffer niet wekenlang onopgemerkt blijft.
Hoe helpt PHP SOS concreet?
- Aanvalsoppervlak vaststellen: Wij stellen vast welke van uw systemen van buitenaf bereikbaar zijn en wat ze over zichzelf prijsgeven.
- Patchen en harden: Wij werken PHP bij, herstarten en beperken versievermeldingen, schrijfrechten en onnodige diensten.
- Regels en blokkades: Wij richten WAF-regels en blokkeermechanismen in die bij uw toepassing passen.
- Doorlopende bewaking: Wij melden opvallende processen, bestanden en verbindingen voordat een treffer een incident wordt.
Hoe dat in de dagelijkse praktijk eruitziet, beschrijft Security-monitoring voor webservers.
Conclusie
Geautomatiseerde aanvallen vragen niet van wie een server is. Ze vragen alleen of hij kwetsbaar is. Het beste antwoord daarop is onspectaculair: snel patchen, weinig aanbieden, goed kijken. Wie dat doet, wordt nog steeds gescand, maar niet meer gevonden.
Veelgestelde vragen
Zijn kleine bedrijven doelwit van geautomatiseerde aanvallen?
Ja. Geautomatiseerde scans controleren bereikbare servers zonder te kijken naar de beheerder. Of erachter een concern of een ambachtsbedrijf staat, speelt voor de software geen rol. Beslissend is of de server kwetsbaar lijkt.
Waaraan herken ik scans in mijn logs?
Typisch zijn veel verzoeken naar paden die op uw website helemaal niet bestaan, vaak van wisselende adressen en met opvallende kenmerken. Zulke vermeldingen zijn normaal en nog geen bewijs van een geslaagde aanval, maar tonen wel dat uw server wordt gecontroleerd.
Helpt het de PHP-versie te verbergen?
Het maakt het scanners iets moeilijker uw server gericht in te delen en is een zinvolle basisinstelling. Maar het beschermt niet tegen aanvallen die eenvoudig elke server uitproberen. De update blijft verplicht.
Kan ik scans helemaal voorkomen?
Nee. Elke openbaar bereikbare server wordt regelmatig gescand. Het doel is niet scans te voorkomen, maar ervoor te zorgen dat ze niets vinden: actuele software, weinig aanvalsoppervlak en een bewaking die bijzonderheden meldt.