Titta i loggarna på en WordPress-sajt som funnits ett par år. Du hittar hundratals, ibland tusentals, misslyckade inloggningsförsök, skanningar mot kända sårbarheter och förfrågningar som testar om du kör en version som patchades förra veckan.

Du attackeras. Frågan är i vilken takt.

Lindenytt har känt det på kroppen sedan WordPress kom in för ungefär tio år sedan. Sajten i sig är äldre, men det är med WordPress attackerna eskalerade: flooding som gör sajten seg, exploits som dyker upp sekunder efter att en uppdatering publicerats. Det räcker för att förstå vad som faktiskt gör skillnad och vad som är säkerhetsteater.

Angriparna läser samma changelogs som du

Det snabbaste och mest underskattade attackmönstret ser ut så här: WordPress.org publicerar en patch. Changelogen är publik. Den berättar exakt vad som åtgärdats. Angriparna läser den och börjar skanna efter sajter som inte hunnit uppdatera.

Fönstret mellan patch och aktiv attack mäts i minuter.

Det är anledningen till att manuella uppdateringsrutiner med lång eftersläpning är ett problem. Lindenytt kör Composer Bedrock som teknisk plattform, med automatiserade processer som håller beroenden aktuella. Uppdateringar kan inte vara något man hinner med när det passar.

Flooding är ett kapacitetsproblem

En sajt som plötsligt svarar långsamt, eller inte alls, behöver inte vara trasig. Det är ofta flooding: mer trafik än servern klarar att hantera, oavsett om den kommer från riktiga besökare eller en attack.

Att skydda sig kräver flera lager. Filtrering av trafiken innan den når servern, begränsningar på hur aggressivt en enskild källa kan bete sig, och caching som minskar serverbelastningen vid hög trafik. Ingen av de åtgärderna löser problemet ensam. Tillsammans gör de attacken avsevärt dyrare för den som genomför den.

Attackytan krymper när du tar bort saker

Det finns en enkel och undervärderad princip bakom WordPress-säkerhet: varje plugin som inte används, varje tema som glömts kvar och varje oanvänt användarkonto är en potentiell ingång för en angripare.

Att ta bort det som inte behövs, inte bara inaktivera det, är en av de mest konkreta sakerna man kan göra.

Planera för att det ändå kan gå fel

Härdning minskar risken. Den eliminerar den inte. Det är skälet till att backuper borde vara utgångspunkten snarare än eftertanken.

En backup som lagras på samma server som sajten hjälper inte om servern är komprometterad. En backup som aldrig testats är inte en backup.

Det slutar inte

Lindenytt attackeras fortfarande. Det gör din sajt med. Skillnaden är hur lång tid det tar för en attack att ta sig igenom, och om du kan hantera det om den mot förmodan lyckas.

Härdning är underhåll, inte ett projekt med ett slutdatum.