Kort sagt: Automatiserede angreb mod webservere forløber i bølger: Programmer gennemsøger internettet efter tilgængelige servere, klassificerer dem ud fra ydre kendetegn og afprøver kendte sårbarheder som PHP2Shell i massevis. Virksomhedens størrelse spiller ingen rolle. Beskyttelse giver et patchet PHP, en lille angrebsflade og en overvågning, der hurtigt opdager vellykkede træffere.
Udgangspunktet: „Hvem skulle interessere sig for vores website?“
Det spørgsmål hører vi ofte efter PHP2Shell, især fra mindre virksomheder. Det ærlige svar: formentlig ingen personligt. Men det er heller ikke nødvendigt ved sårbarheder af denne art. Angrebene udføres af programmer, der ikke leder efter navne, men efter muligheder.
BSI (det tyske forbundsagentur for informationssikkerhed) regnede ved PHP2Shell med hurtig, omfattende udnyttelse. Cloudflare rapporterede om angrebsforsøg og om, at angribere ændrede deres mønstre for at omgå beskyttelsesregler. Begge dele passer til det, der regelmæssigt sker ved kritiske sårbarheder i udbredt software.
Sådan forløber automatiserede angreb mod webservere
Automatiserede kampagner følger som regel et lignende mønster. Oversigten nedenfor beskriver faserne generelt, uden angrebsdetaljer:
| Fase | Hvad sker der | Hvad hjælper imod det |
|---|---|---|
| Søge | Programmer gennemgår store adresseområder eller offentlige fortegnelser som certifikatprotokoller efter tilgængelige webservere | få offentligt tilgængelige systemer, inventar over alle adresser |
| Klassificere | Svar analyseres: webserver, PHP-version, CMS, typiske stier | skjul versionsoplysninger, fjern unødvendige filer |
| Afprøve | kendte sårbarheder testes i massevis, ofte uden forudgående klassificering | aktuelt PHP, genstart, WAF som ekstra lag |
| Fæstne sig | ved succes lægges en bagdør, f.eks. en webshell eller et cronjob | begrænsede skriverettigheder, ingen PHP-udførelse i upload-mapper |
| Udnytte | serveren bruges, f.eks. til spam, kryptominering, omdirigeringer eller datatyveri | overvågning af processer, filer og udgående forbindelser |
Vigtig er den tredje række. Mange kampagner gider slet ikke klassificere serverne nøje på forhånd. De prøver simpelthen alt, hvad der er tilgængeligt. Derfor beskytter det ikke alene at være uopdagelig.
Hvorfor angreb kommer i bølger
Automatiserede kampagner kører sjældent én gang og så aldrig mere. Typisk er et mønster i bølger. Den første bølge følger kort efter, at en sårbarhed bliver kendt, ofte stadig med umodne værktøjer. Yderligere bølger kommer, når angribere forbedrer deres værktøjer eller tilpasser dem til beskyttelsesregler. Det har Cloudflare netop observeret ved PHP2Shell: ændrede angrebsmønstre for at omgå reglerne.
For jer betyder det: En server, der har klaret den første bølge uskadt, er ikke varigt sikker, så længe den er upatchet. Og en nyopsat server er mål fra det øjeblik, den er tilgængelig. Den, der f.eks. lader udstede et nyt TLS-certifikat, gør navnet synligt i offentlige certifikatprotokoller, som også scannere analyserer. Et nyt system bør derfor først på nettet, når det allerede er opdateret.
Hvorfor små firmaer er lige så berørte
For automatiserede angreb tæller ikke værdien af det enkelte mål, men mængden. En server hos et lille firma tilbyder regnekraft, et domæne med godt ry, mailafsendelse og nogle gange kundedata. For angribere er det nok.
Hertil kommer: Mindre virksomheder har ofte ingen egen it, der straks indspiller opdateringer. Deres servere forbliver sårbare længere og havner derfor oftere i scannernes resultatlister. Den, der patcher først, falder ud af disse lister.
Et yderligere punkt er leverandørkæden. Mange små websites ligger på servere hos bureauer eller små hostingudbydere, hvor dusinvis af kundeprojekter kører side om side. For angribere er en sådan server særlig lukrativ, fordi én enkelt træffer berører mange websites på én gang. Jeres risiko afhænger så ikke kun af jeres egen omhu, men også af jeres serviceudbyders.
Scanninger i jeres logs er normale og ikke bevis på et indbrud. Et vellykket angreb viser sig ved andre spor: nye filer, fremmede processer, ukendte konti, usædvanlige udgående forbindelser.
Hvad I selv kan kontrollere
Et blik i logs viser, hvor kraftigt jeres server bliver scannet. Følgende kommandoer læser kun og ændrer intet:
# De ti adresser med flest forespørgsler i den aktuelle adgangslog
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Forespørgsler, der blev besvaret med "ikke fundet", efter hyppighed
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Afslører serveren sin PHP-version i headeren?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Mange forespørgsler på ikke-eksisterende stier er typisk scanningsstøj. Mere opmærksomme bør I blive, hvis sådanne forespørgsler pludselig følges af vellykkede svar, hvis der i upload-mapper åbnes filer, I ikke kender, eller hvis webserverbrugeren starter processer, den ellers aldrig starter. Bekræftede kendetegn specifikt for PHP2Shell findes hidtil ikke, vurderingen bygger derfor på sådanne afvigelser i adfærd. Hvordan I analyserer logs grundigere, beskriver vejledningen Analysér webserverlogs. Viser den tredje forespørgsel en PHP-version, er indstillingen expose_php = Off umagen værd; baggrund står under Skjul versionsoplysninger.
Beskyttelseslagene i den rigtige rækkefølge
- Opdatér PHP, og genstart: Uden dette trin forbliver alle andre foranstaltninger lappeværk.
- Gør angrebsfladen mindre: Luk ubrugte websites, testsystemer og gamle microsites ned eller læg dem bag et login.
- Regler i kanten: En Web Application Firewall med et vedligeholdt regelsæt, f.eks. OWASP Core Rule Set med ModSecurity, fanger en del af forsøgene.
- Bremse gentagne forsøg: Værktøjer som Fail2ban spærrer adresser, der frembringer påfaldende mange fejl. Mod distribuerede scanninger hjælper det kun begrænset.
- Overvåge: Hold øje med webserverbrugerens processer, nye PHP-filer og udgående forbindelser, så en vellykket træffer ikke forbliver uopdaget i ugevis.
Hvordan hjælper PHP SOS konkret?
- Kortlægge angrebsfladen: Vi fastslår, hvilke af jeres systemer der er tilgængelige udefra, og hvad de røber om sig selv.
- Patche og hærde: Vi opdaterer PHP, genstarter og reducerer versionsoplysninger, skriverettigheder og unødvendige tjenester.
- Regler og spærringer: Vi indretter WAF-regler og spærremekanismer, der passer til jeres applikation.
- Løbende overvågning: Vi melder påfaldende processer, filer og forbindelser, før en træffer bliver til en hændelse.
Hvordan det ser ud i daglig drift, beskriver Security-monitoring for webservere.
Konklusion
Automatiserede angreb spørger ikke, hvem en server tilhører. De spørger kun, om den er sårbar. Det bedste svar herpå er ukompliceret: patch hurtigt, tilbyd lidt, se nøje efter. Den, der gør det, bliver fortsat scannet, men ikke længere fundet.
Ofte stillede spørgsmål
Er små virksomheder mål for automatiserede angreb?
Ja. Automatiserede scanninger kontrollerer tilgængelige servere uden at se på, hvem der driver dem. Om der står en koncern eller et håndværkerfirma bagved, er ligegyldigt for softwaren. Afgørende er, om serveren virker sårbar.
Hvordan opdager jeg scanninger i mine logs?
Typiske er mange forespørgsler på stier, der slet ikke findes på jeres website, ofte fra skiftende adresser og med påfaldende identifikatorer. Sådanne poster er normale og endnu ikke bevis på et vellykket angreb, men de viser, at jeres server bliver undersøgt.
Hjælper det at skjule PHP-versionen?
Det gør det lidt sværere for scannere at klassificere jeres server målrettet og er en fornuftig grundindstilling. Men det beskytter ikke mod angreb, der blot prøver enhver server. Opdateringen er fortsat en pligt.
Kan jeg helt forhindre scanninger?
Nej. Hver offentligt tilgængelig server bliver jævnligt scannet. Målet er ikke at forhindre scanninger, men at sørge for, at de ikke finder noget: aktuel software, lille angrebsflade og en overvågning, der melder påfaldende forhold.