Kort sagt: Om det är DDoS eller hackerangrepp visar sig i spåren. En DDoS ger mycket många förfrågningar och gör webbplatsen långsam eller onåbar, men ändrar ingenting. En exploit behöver ofta bara få förfrågningar och lämnar nya filer, konton, processer eller förbindelser. Rätt bedömning avgör om ni måste avvärja belastning eller begränsa en incident.
Skillnaden med enkla ord
Ett DDoS-angrepp (Distributed Denial of Service) är som en folkmassa som blockerar ingången till en butik. Ingen kommer in, men i butiken stjäls ingenting. Målet är att överbelasta er webbplats eller server så att riktiga kunder inte längre kommer fram.
En exploit är däremot ett inbrott genom en öppen dörr. Angriparen utnyttjar en sårbarhet, till exempel i PHP, i CMS:et eller i ett tillägg, för att köra kod på er server. Det kan ske tyst, utan att webbplatsen blir långsammare. Följderna sträcker sig från skräpsidor via datastöld till att servern tas över.
För ledningen är skillnaden avgörande: En DDoS är ett tillgänglighetsproblem som upphör när angreppet upphör. En lyckad exploit är en säkerhetsincident som finns kvar tills den är upptäckt, sanerad och dokumenterad.
DDoS eller hackerangrepp: tecknen jämförda
Följande tabell hjälper vid den första bedömningen. Den ersätter ingen analys men visar var ni bör titta först.
| Kännetecken | Snarare DDoS | Snarare exploit eller intrång |
|---|---|---|
| Tillgänglighet | långsam eller nere | ofta normal |
| Förfrågningar i loggen | mycket många, ofta likformiga | få, riktade förfrågningar |
| Filer | oförändrade | nya eller ändrade PHP-filer |
| Konton | oförändrade | nya admins, ändrade lösenord |
| Processer | webbserver och PHP under full last | okända processer, mining, skräppostutskick |
| Nätverk | mycket inkommande trafik | ovanliga utgående förbindelser |
| Efter slutet | allt som förut | spåren finns kvar |
Se upp vid överlappningar: Massiv skanning efter en sårbarhet kan se ut som en liten DDoS. Just det var att vänta kring PHP2Shell, när angripare sökte efter sårbara servrar. Hög belastning kan alltså också betyda att någon just nu försöker ta sig in.
Första kontrollerna på servern
Följande kommandon ändrar ingenting i systemet och ger en snabb överblick. Vid misstanke om intrång bör ni säkra loggarna innan ni gör större ingrepp.
# Belastning och drifttid
uptime
# Förbindelser sammanfattade och de vanligaste motparterna
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Vanligaste klientadresser i åtkomstloggen (anpassa sökvägen)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# PHP-filer som har ändrats de senaste 7 dagarna
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Processer med högst CPU-belastning
ps aux --sort=-%cpu | head -15
I förbindelseöversikten visar den fjärde kolumnen motparten. Många förbindelser från få adresser eller en ökning till ett flertal av normalvärdet tyder på överbelastning. Nya PHP-filer i uppladdnings- eller cachekataloger, processer under webbserverns användare med främmande namn eller utgående förbindelser till okända mål tyder snarare på ett intrång. En utförlig lista finns under Tecken på komprometterad server efter PHP2Shell.
Varför hög belastning också kan vara ett avledningsmanöver
Det förekommer att angripare skapar en överbelastning medan de samtidigt riktat bryter sig in. Teamet är då upptaget med tillgängligheten, och de egentliga spåren drunknar i loggbruset. Därför gäller: Även om en DDoS är uppenbar, kontrollera efter dess slut filer, konton och utgående förbindelser.
I fallet PHP2Shell kommer det till att det enligt php.net och säkerhetsföretagen inte finns några publicerade, bekräftade Indicators of Compromise. Upptäckten bygger på beteendeanalys. En server som var ej patchad under skanningsperioden från mitten av oktober bör därför granskas oavsett den observerade belastningen.
En ytterligare variant är utpressningsmejl där man hotar med ett DDoS-angrepp om ingen betalning sker. Spara sådana meddelanden, betala inte utan samråd med fackfolk och överväg en anmälan till Zentrale Ansprechstelle Cybercrime (ZAC, de tyska polisens centrala kontaktpunkter för it-brottslighet). Informera parallellt ert webbhotell så att skyddsåtgärder kan förberedas. Hur ni analyserar loggarna för det står i guiden Analysera webbserverloggar efter ett angrepp.
Vad ni bör göra under de första timmarna
Vid misstanke om DDoS:
- Informera webbhotellet eller datacentret; där finns ofta filter framför servern.
- Aktivera eller skärp en förkopplad skyddstjänst eller en WAF med virtuell patchning.
- Sätt rate limits i webbservern och skydda dyra sidor som sökning eller varukorg särskilt.
- Spara loggar så att angreppet går att följa upp senare.
Vid misstanke om ett intrång:
- Radera ingenting och installera inte om servern innan loggar och berörda filer är säkrade.
- Uppdatera PHP till en åtgärdad version och starta om alla workers, om det inte redan har skett.
- Om uppdateringen inte kan göras direkt, ta webbplatsen tillfälligt offline, så som BSI rekommenderar.
- Förnya inloggningsuppgifter från en ren enhet, inte från den möjligen berörda servern.
- Låt kontrollera om personuppgifter kan ha påverkats; då kan anmälningsfrister löpa.
I båda fallen hjälper en kort, saklig anteckning till webbhotell och tjänsteleverantörer: sedan när problemet finns, vilka webbplatser som berörs, vad ni har observerat och vad som redan har ändrats. Anteckna också vem som har fattat vilket beslut. Den tidslinjen sparar tid i analysen och är senare värdefull för försäkring, dataskydd och intern uppföljning. Är det oklart om det över huvud taget föreligger ett angrepp, behandla läget försiktighetsvis som en incident tills motsatsen är belagd.
Hur hjälper PHP SOS konkret?
- Vi bedömer läget på distans utifrån belastning, loggar, filer och förbindelser och säger vad ni sannolikt har att göra med.
- Vid överbelastning sätter vi filter, rate limits och förkopplade skyddsregler tills angreppet klingar av.
- Vid misstanke om intrång tar vi över den strukturerade incidenthanteringen: säkra, begränsa, hitta orsaken, sanera.
- I slutet dokumenterar vi vad som hänt och vilka åtgärder som genomförts, tills incidenten är avslutad.
Vanliga frågor
Kan ett DDoS-angrepp stjäla data?
Ett rent DDoS-angrepp syftar på tillgängligheten, inte på data. Det ändrar inga filer och läser inga databaser. Det kan dock inträffa samtidigt med ett intrångsförsök, så en titt på filer och konton lönar sig ändå.
Hur vet jag att min webbplats har hackats?
Typiska tecken är nya eller ändrade PHP-filer, okända adminkonton, omdirigeringar till främmande sidor, oväntade utgående förbindelser och processer som inte hör till er applikation. Ett enskilt tecken är inget bevis, flera tillsammans är en allvarlig signal.
Hjälper ett CDN eller en WAF mot båda angreppstyperna?
Mot volymbaserade angrepp hjälper en förkopplad tjänst oftast bra. Mot exploits fungerar regler bara om de känner igen mönstret. Vid PHP2Shell påpekar Cloudflare själva att regler som enbart bygger på förfrågningsdata inte räcker.
Måste jag anmäla ett DDoS-angrepp?
Det beror på det enskilda fallet och på er bransch. Utan åtkomst till personuppgifter gäller GDPR:s anmälningsskyldighet i regel inte, men branschspecifika skyldigheter kan finnas. Klarlägg det med ert dataskyddsombud eller en advokat.