113 artiklar

Blogg: PHP2Shell, serversäkerhet och nödhjälp

Bedömning av läget, anvisningar för administratörer och beslutsstöd för ledningen. Sorterat efter ämne, varje artikel med källor.

WhatsApp-nödläge

Läge och bedömning Webbhotell och distributioner Upptäckt och forensik Härdning och konfiguration Säker utveckling Ledning och juridik Beslutsstöd

Läge och bedömning

17 artiklar

001

PHP2Shell: vad som är belagt och vad som inte är det

En faktakoll om PHP2Shell: vilka uppgifter som kommer från primärkällor, vilka från mediarapporter och vilka påståenden som inte håller.

Läs mer →002

Varför PHP-sårbarheten blev känd före patchen

Enligt rapporter blev detaljer om PHP2Shell offentliga innan embargot löpte ut. Vi förklarar förloppet och vad det betyder för er patchplanering.

Läs mer →003

Myndigheter tar webbplatser offline: vad företag kan lära

Mainz, den hessiska delstatsregeringen och BKA tog webbplatser offline som försiktighetsåtgärd. Vad företag kan lära för det egna beslutet.

Läs mer →004

BSI:s varningsnivå orange: vad bedömningen betyder

BSI klassar PHP2Shell som 3 / orange. Vad skalan säger och inte säger, och hur företag omsätter bedömningen i beslut.

Läs mer →005

Vad CERT-EU och CERT-Bund rekommenderar om PHP2Shell

De officiella instanserna är eniga: patcha direkt, annars isolera. Vi jämför rekommendationerna och visar hur isolering ser ut i praktiken.

Läs mer →006

Cloudflares skyddsregler mot PHP2Shell: vad de klarar och vad de inte klarar

Cloudflare rullade tidigt ut skyddsregler mot PHP2Shell. Varför det hjälper, varför det ändå inte ersätter PHP-uppdateringen och vilka inställningar ni bör kontrollera.

Läs mer →007

22,6 miljoner exponerade instanser: sätt siffrorna i rätt perspektiv

Unit 42, CybelAngel och andra anger mycket olika siffror för PHP2Shell. Vi förklarar vad som räknades och vilken siffra som verkligen gäller för er.

Läs mer →008

PHP2Shell på fem minuter: briefing för företagsledningen

PHP-säkerhetsluckan PHP2Shell på en sida för beslutsfattare: läge, risk, fem frågor till IT och besluten för i dag.

Läs mer →009

PHP-säkerhetsluckan enkelt förklarad

PHP2Shell för icke-tekniker: med vardagsbilder, en liten ordlista och tre typiska utgångslägen för vad ni som webbplatsägare bör göra.

Läs mer →010

PHP2Shell: 15 frågor från webbhotellskunder

Ligger er webbplats hos ett webbhotell och ni vill veta vad ni själva måste göra vid PHP2Shell? Här är de 15 vanligaste frågorna med korta svar.

Läs mer →011

Därför hjälper en WordPress-uppdatering inte mot PHP2Shell

Många ägare har efter rubrikerna uppdaterat WordPress och känner sig säkra. Varför det går i tomma intet vid PHP2Shell och vad som räknas i stället.

Läs mer →012

PHP2Shell och Log4Shell: vad sårbarheterna har gemensamt

Många jämför PHP2Shell med Log4Shell från 2021. Vad jämförelsen bär, var den haltar och vilka lärdomar från den tiden hjälper i dag.

Läs mer →013

Massskanning efter opatchad PHP: så går automatiserade angrepp till

Efter PHP2Shell söker angripare automatiskt igenom internet efter sårbara servrar. Hur det går till, varför storleken inte spelar någon roll och vad som skyddar er.

Läs mer →014

Tidsfönstret mellan patch och angrepp

Vid PHP2Shell fanns angreppsförsök redan före patchen. Vi förklarar tidsfönstrets faser, hur ni mäter ert eget och hur ni förkortar det.

Läs mer →015

Efter PHP2Shell: varför fler rapporter är sannolika

PHP2Shell är inte avslutat med patchen den 21 oktober. Varför uppföljande rapporter är att vänta och hur ni ställer in ert team på det.

Läs mer →016

PHP2Shell: lägesbilden efter första veckan

En vecka efter det första observerade angreppsförsöket: läget för patchar, myndighetsvarningar, angrepp och avstängningar, rent uppdelat efter källor.

Läs mer →017

Farliga felaktiga tips om PHP2Shell som just nu cirkulerar

Blockera cookies, dölja felmeddelanden, bara uppdatera CMS: nio råd om PHP2Shell som skapar falsk trygghet, och vad som verkligen räknas.

Läs mer →

Webbhotell och distributioner

18 artiklar

018

Ändra PHP-version i webbhotellets kundområde

Hur ni byter PHP-version i webbhotellets kundområde, vilken version ni väljer och vad ni kontrollerar före och efter.

Läs mer →019

Debian och Ubuntu: är mitt PHP-paket patchat?

Vilka PHP-paket Debian och Ubuntu har rättat mot PHP2Shell, hur ni jämför den installerade nivån exakt och varför beviset ofta faller.

Läs mer →020

RHEL, AlmaLinux och Rocky Linux: kontrollera PHP-patchen

Vad Red Hat har publicerat om PHP2Shell, hur ni styrker paketnivån på RHEL och dess efterbyggen och varför en omladdning inte räcker.

Läs mer →021

Förrådet sury.org: PHP-paket från tredjepartskälla

Många Debian- och Ubuntu-servrar hämtar PHP från sury-förrådet. Vad det betyder för uppdateringar, bevis och gamla PHP-versioner efter PHP2Shell.

Läs mer →022

Remi-förrådet: hålla PHP aktuellt på RHEL-system

Remi levererar aktuella PHP-versioner för RHEL-familjen, som modul eller installerbara parallellt. Så kontrollerar ni läget efter PHP2Shell och undviker bortglömda grenar.

Läs mer →023

Varför php -v visar samma nummer efter uppdateringen

Uppdateringen gick igenom, men php -v anger den gamla versionen. Oftast är det en backport och inget fel. Så skiljer ni ofarligt från verkliga problem.

Läs mer →024

Styrk CVE-nummer i paketets changelog

Den som måste styrka en PHP-patch för ledning, revisorer eller försäkringsbolag behöver mer än ett versionsnummer. Så blir changelog-posten ett bevis.

Läs mer →025

Byta hostingleverantör efter en säkerhetsincident: vad bör ni tänka på?

Efter en incident är önskan om en ny hostingleverantör begriplig. För att bytet inte ska ta med sig angriparen kommer det an på ordningsföljd och urval.

Läs mer →026

Flera PHP-versioner på en server: patcha var och en för sig

På många servrar körs tre, fyra eller fler PHP-installationer sida vid sida. Efter PHP2Shell måste varje installation hittas, uppdateras och startas om.

Läs mer →027

Stäng av gamla PHP-versioner i hostingpanelen

PHP2Shell är ett bra tillfälle att bli av med gamla PHP-versioner. Så går ni tillväga i tre faser, så att ingen webbplats och inget cronjobb faller bort obemärkt.

Läs mer →028

Plesk: förstå PHP-handlers (FPM, FastCGI, Apache-modul)

Vilken PHP-handler Plesk använder för en webbplats avgör isolering, konfiguration och risk. En jämförelse med blick på PHP2Shell.

Läs mer →029

CloudLinux och alt-php: vad hostingkunder bör veta

På CloudLinux-servrar körs webbplatser ofta med egna alt-php-paket. Varje version kräver sin egen patch, och bara serverns operatör kan installera den.

Läs mer →030

PHP på NAS, brandväggar och appliances: de bortglömda systemen

Det är inte bara webbservrar som använder PHP. Även NAS-system, brandväggar och specialenheter med webbgränssnitt kan vara berörda. Patcha kan där oftast bara tillverkaren, nåbarheten styr ni själva.

Läs mer →031

PHP hos moln- och PaaS-leverantörer: vem patchar körmiljön?

På plattformstjänster beror PHP-patchen på driftmodellen. Avgörande är den körmiljö som faktiskt levererar, inte den lokala miljön eller applikationskoden.

Läs mer →032

Officiella PHP Docker-images: taggar, digests och ombyggnad

En tagg för den officiella PHP-imagen är en pekare som med tiden flyttas till nya nivåer. Den som vet vad tagg, variant och digest betyder väljer rätt image och kan styrka patchnivån.

Läs mer →033

CI/CD: bygg om PHP-images automatiskt

En image åldras även utan kodändring. Med tidsstyrda builds, en versionskontroll och utrullning via digest når PHP-patchar tillförlitligt produktion.

Läs mer →034

Långtidssupport för gamla PHP-versioner: alternativ och gränser

Den som inte kan byta direkt från PHP 8.1 eller äldre hittar långtidssupport hos distributioner, tredjepartsleverantörer och kommersiella tjänster. Vad de vägarna ger, vad ni behöver skriftligt och var gränserna går.

Läs mer →035

Uppdatera PHP i Windows

I Windows finns ingen automatisk PHP-uppdatering. Den som väljer rätt variant, kontrollerar nedladdningen och startar om alla processer får PHP2Shell-patchen rent på varje dator.

Läs mer →

Upptäckt och forensik

18 artiklar

036

Varningssignal: webbservern startar ett skal

Startar en PHP-FPM- eller webbserverprocess ett skal är det en av de starkaste varningssignalerna för ett intrång. Så kontrollerar ni processträdet, placerar undantagen och övervakar mönstret varaktigt.

Läs mer →037

Hitta misstänkta processer på Linux-servrar

Skadliga processer maskerar sig med harmlösa namn, körs från temporära mappar eller från raderade filer. Med några läsande kommandon hittar ni avvikelser och placerar dem.

Läs mer →038

Känn igen dolda cronjobb som bakdörr

Angripare använder schemalagda uppgifter för att komma tillbaka efter en sanering. Så kontrollerar ni crontabs, cron-kataloger, systemd-timers och at-jobb fullständigt och känner igen misstänkta poster.

Läs mer →039

Hitta nyligen ändrade filer på webbservern

Efter ett möjligt intrång räknas det som har förändrats på servern. Så söker ni efter tidsfönster, använder mtime och ctime rätt och stämmer av mot paket, Git och säkerhetskopior.

Läs mer →040

PHP-filer i uppladdningsmappen: tolka fynden rätt

En PHP-fil i uppladdningsmappen är nästan alltid ett larmtecken, men inte varje sådan är skadlig kod. Så bedömer ni fyndet utan att förstöra spår och klargör om någon har anropat den.

Läs mer →041

Känn igen förvrängd PHP-kod

Oläslig PHP-kod med eval och base64_decode är ett klassiskt tecken på insmugglad skadlig kod. Vilka mönster ni söker, hur ni hittar dem riskfritt och när förvrängning är legitim.

Läs mer →042

Kontrollera en servers utgående anslutningar

En webbserver svarar framför allt på förfrågningar. Bygger den själv upp anslutningar till okända mål kan det betyda styrning av angripare eller dataläckage. Så kontrollerar och begränsar ni utgående trafik.

Läs mer →043

Hitta främmande adminkonton i CMS och server

En okänd administratör är ofta den enklaste bakdörren. Så söker ni nivå för nivå efter främmande konton, även sådana som gränssnittet döljer.

Läs mer →044

Hitta och ta bort okända SSH-nycklar

En insmugglad SSH-nyckel öppnar dörren för angripare, även om alla lösenord är bytta. Så hittar ni varje authorized_keys-fil och kontrollerar varje post.

Läs mer →045

Kryptominer på webbservern: tecken och tillvägagångssätt

Ständigt full CPU utan att fler besökare kommer: det kan vara en kryptominer. Så kontrollerar ni belastningen, hittar processen och dess omstartsmekanismer och går ordnat tillväga.

Läs mer →046

Servern skickar spam: hitta orsakerna

Obeställbara e-postmeddelanden, spärrlistor, klagomål: när den egna servern skickar spam ligger oftast ett skript eller en kapad postlåda bakom. Så hittar ni källan.

Läs mer →047

SEO-spam och främmande sidor i Googles index

Plötsligt rankar sidor om läkemedel eller märkesvaror under er domän. Så tar ni reda på varifrån SEO-spamen kommer och får bort den ur indexet igen.

Läs mer →048

Webbplatsen omdirigerar till främmande sidor

Besökare hamnar på tävlingssidor eller tvivelaktiga butiker, men ni själva ser ingenting? Så hittar ni lagret där omdirigeringen sitter och åtgärdar den.

Läs mer →049

Säkra bevis innan ni installerar om servern

En ominstallation gör sig av med angriparen men också med alla spår. Den som först lägger en timme på bevissäkring kan senare säga vad som hände.

Läs mer →050

Upprätta tidslinjen för en incident

När kom angriparen, vad gjorde han, när märktes det? En ordentlig tidslinje besvarar de frågorna och är underlag för anmälningar, försäkring och rapport.

Läs mer →051

Jämför CMS-kärnfiler med originalet

Jämförelsen med ett rent original visar varje ändrad fil, oavsett om en skanner känner igen den. Så bygger ni upp avstämningen för WordPress, Composer-projekt och systempaket.

Läs mer →052

Kontrollera databasen efter inplanterad kod

Den som bara kontrollerar filer missar hälften. Så söker ni igenom databasens innehåll, inställningar, trigger och konton efter inplanterad kod, läsande och på en kopia.

Läs mer →053

Skadekodsskanner för webbplatser: vad de hittar och vad de inte hittar

Skannern rapporterar ingenting, så allt är bra? Inte nödvändigtvis. Vilka slags webbplatsskannrar som finns, vad var och en ser och vad den i grunden inte kan se.

Läs mer →

Härdning och konfiguration

20 artiklar

054

Isolera PHP-FPM-pooler per webbplats

En egen pool per webbplats är början, inte slutet. Så kontrollerar ni befintliga pooler och härdar sockets, filändelser, statussidor, resurser och loggar.

Läs mer →055

Ställ in memory_limit rätt

memory_limit begränsar minnet per PHP-förfrågan. Efter PHP2Shell rekommenderar php.net tillfälligt motsatsen. Vad som gäller i normaldrift, under övergången och efter uppdateringen.

Läs mer →056

Begränsa post_max_size och upload_max_filesize förnuftigt

Uppladdningsgränser verkar på tre ställen: i webbservern, i PHP och i applikationen. Så sätter ni värdena samstämmigt, även med php.nets övergångsvärden för PHP2Shell.

Läs mer →057

Stäng av session.upload_progress: rätt och permanent

Åtgärden mot CVE-2026-115560 och en av PHP2Shell-övergångsåtgärderna är snabbt satt. För att den ska hålla måste den stå på rätt ställe, vara spärrad och kontrolleras igen efter varje uppdatering.

Läs mer →058

expose_php och Server-huvudet: dölj versionsuppgifter

PHP, Nginx och Apache anger som standard sitt versionsnummer i varje svar. Det skyddar inte mot angrepp men ger skannrar en bekväm träfflista. Så stänger ni av det och behåller ändå överblicken.

Läs mer →059

display_errors off: stäng av felutskrifter i produktion

Synliga PHP-felmeddelanden avslöjar sökvägar, databasnamn och versioner. Så stänger ni av dem i PHP, i ramverket och i webbservern utan att tappa felen ur sikte.

Läs mer →060

php_admin_value: spärra inställningar mot överskrivning

En säkerhetsinställning hjälper föga om applikationen ändrar den igen med en kodrad. Med php_admin_value och php_admin_flag fastställer ni värden för PHP-FPM och Apache bindande.

Läs mer →061

Sätta minnesgränser med systemd och cgroups

php.net rekommenderar som PHP2Shell-övergångsåtgärd memory_limit=-1 och en minnesgräns utanför PHP. Så sätter ni den gränsen med systemd och cgroups utan att en enskild worker drar med sig hela tjänsten.

Läs mer →062

Konfigurera Nginx för PHP säkert

De flesta svagheter i Nginx-upplägg för PHP sitter inte i Nginx utan i några få rader i PHP-locationen. Så konfigurerar ni överlämningen till PHP-FPM så att bara avsedda skript körs.

Läs mer →063

Konfigurera Apache för PHP säkert

Apache är flexibel, och just det gör den känslig för felkonfiguration. Så kopplar ni in PHP via PHP-FPM, stänger .htaccess som bakdörr och ställer in de viktigaste kärnalternativen säkert.

Läs mer →064

Förbjud PHP-körning i uppladdningsmappar

En webbshell behöver två saker: en mapp den kan skrivas till och en server som kör den. Så tar ni ifrån den det andra, och det i varje skrivbar mapp, inte bara i uploads.

Läs mer →065

Filtrera uppladdningsförfrågningar i kanten: möjligheter och risker

Fackförfattare föreslår att blockera uppladdningsförfrågningar utanför riktiga uppladdningssökvägar i proxyn tills PHP är patchad. Det kan hjälpa men också lamslå formulär och beställningar. Så går ni kontrollerat tillväga.

Läs mer →066

Använd ModSecurity och OWASP Core Rule Set

En egen Web Application Firewall med ModSecurity och OWASP Core Rule Set är gratis och kraftfull men ingen självgående lösning. Så väljer ni motor, startar utan avbrott och trimmar reglerna.

Läs mer →067

Ställ in Fail2ban för webbservrar

Fail2ban spärrar adresser som upprepat dyker upp i loggarna. För webbservrar medföljer färdiga filter, och med några få rader kommer egna till. Så ställer ni in det utan att spärra er själva eller era kunder.

Läs mer →068

Brandvägg för webbservrar: öppna bara nödvändiga portar

En webbserver behöver utåt oftast bara två portar. Ändå lyssnar på många servrar databaser, PHP-FPM eller administrationsgränssnitt mot internet. Så hittar ni öppna tjänster och stänger det som inte behövs.

Läs mer →069

Automatiska säkerhetsuppdateringar på Linux-servrar

Enligt rapporter levererade distributioner PHP-backports delvis redan den 21 oktober 2026, patchdagen. Den som använde automatiska säkerhetsuppdateringar hade dem snabbt på servern. För att de ska verka krävs omstarter, tredjepartskällor och kontroll.

Läs mer →070

Least Privilege: webbserveranvändarens behörigheter

Inplanterad kod körs med webbserveranvändarens behörigheter. Vad det här kontot får göra avgör hur långt en angripare kommer. Så begränsar ni skal, sudo, cron, databas och filsystem till det nödvändiga.

Läs mer →071

Avskärma adminområden med IP, VPN eller extra skydd

Varför en webbplats backend inte behöver vara nåbar för hela världen och hur ni avskärmar den med IP-spärr, VPN eller förinställd inloggning utan att stänga ute er själva.

Läs mer →072

Konfigurera TLS och HTTPS rätt

Vilka TLS-versioner och cipher suites en webbserver bör erbjuda i dag, vad rekommendationerna utgår från och hur ni kontrollerar Nginx, Apache och utgående PHP-anslutningar.

Läs mer →073

CIS-benchmarks och BSI-moduler för webbservrar

Vilka härdningsstandarder som finns för Linux-webbservrar, hur CIS-benchmarks och IT-Grundschutz-moduler skiljer sig åt och hur ni gör en kontrollerbar föreskrift för era PHP-servrar av dem.

Läs mer →

Säker utveckling

16 artiklar

074

Lagra lösenord säkert i PHP: använd password_hash rätt

Hur utvecklare lagrar lösenord i PHP med password_hash och password_verify, väljer lämplig metod och ersätter gamla MD5- eller SHA-1-hashar utan lösenordsåterställning för alla användare.

Läs mer →075

CSRF-skydd i PHP-applikationer

Hur utvecklare förhindrar Cross-Site Request Forgery i PHP-applikationer: tokens för varje förändrande förfrågan, ursprungskontroll i headern och SameSite-cookies som extra lager.

Läs mer →076

Validera och filtrera inmatning i PHP med filter_var

Hur utvecklare kontrollerar inmatning i PHP med filter_var, filter_input_array och tillåtelselistor, vilka filter som är föråldrade och varför validering inte ersätter prepared statements och utdatakodning.

Läs mer →077

Förhindra command injection i PHP

Hur utvecklare undviker command injection i PHP: ersätt systemkommandon med PHP-funktioner, använd proc_open utan skal, kontrollera argument och hitta farliga ställen i befintlig kod.

Läs mer →078

Förhindra Server-Side Request Forgery (SSRF) i PHP

Hur utvecklare förhindrar att en PHP-applikation på uppdrag av främlingar frågar efter interna system: tillåtelselistor, protokollbegränsning, kontroll av den upplösta adressen och gränser i nätverket.

Läs mer →079

Förhindra XML External Entities (XXE) i PHP

Hur utvecklare bearbetar XML säkert i PHP: libxmls standardbeteende, riskabla alternativ som LIBXML_NOENT, skydd med entity-loader och LIBXML_NO_XXE samt typiska dolda XML-ingångar.

Läs mer →080

Type juggling i PHP: lösa jämförelser som säkerhetsrisk

Varför lösa jämförelser med == i PHP kan leda till säkerhetsluckor, vad som ändrades med PHP 8.0 och hur ni skriver robusta jämförelser i inloggningar, tokens och behörigheter.

Läs mer →081

Säkra slumptal och tokens i PHP med random_bytes

Hur utvecklare skapar tokens i PHP för lösenordslänkar, API-nycklar och engångskoder: kryptografiskt säkra källor, tillräcklig längd, lagring som hash och begränsad giltighet.

Läs mer →082

Skydda inloggningsuppgifter och .env-filer rätt

Hur ni skyddar databaslösenord, API-nycklar och andra hemligheter i PHP-projekt: .env-filer utanför webbroten, spärrar i webbservern, snäva rättigheter och ordnat utbyte efter en incident.

Läs mer →083

Offentlig .git-mapp: ett underskattat dataläckage

Varför en webbrot som rullats ut med Git kan avslöja hela källkoden inklusive historiken, hur ni kontrollerar det, spärrar direkt och bygger driftsättningen varaktigt utan .git-mapp.

Läs mer →084

Backupfiler i webbroten: .zip, .sql och .bak

Varför databasdumpar, arkiv och säkerhetskopior i den offentliga katalogen hör till de vanligaste dataläckorna, hur ni hittar dem, spärrar dem och tar reda på om de har hämtats.

Läs mer →085

phpinfo()-filer: varför de måste bort

Efter PHP2Shell skapar många administratörer snabbt en info.php. Varför sådana filer är ett dataläckage, hur ni hittar dem och vilka kontrollvägar som är bättre.

Läs mer →086

Håll beroenden aktuella: Composer, npm och tillägg

Ett projekt består av tre paketvärldar: Composer, npm och CMS-tillägg. Så håller ni alla tre aktuella med fast rytm, tydligt ansvar och tester.

Läs mer →087

Säkerhetsinriktad kodgranskning för PHP-projekt

Hur team målinriktat går igenom egen PHP-kod efter säkerhetsluckor: typer av granskningar, kritiska funktioner, användbara verktyg och en checklista.

Läs mer →088

Logga säkert: logga fel utan dataläckage

Loggar hjälper vid felsökning och forensik men blir snabbt själva ett dataläckage. Vad PHP-applikationer bör logga, vad aldrig och hur man skyddar loggar.

Läs mer →089

Säkra REST-API:er i PHP

Gränssnitt är ofta sämre skyddade än webbplatsen framför dem. De viktigaste reglerna för REST-API:er i PHP, från objektbehörighet till hastighetsbegränsning.

Läs mer →

Ledning och juridik

14 artiklar

090

IT-leverantörsavtal: reglera säkerhetsskyldigheter tydligt

PHP2Shell visade hur ofta det är oklart vem som måste patcha. Vilka säkerhetsskyldigheter som hör hemma i avtal med byrå, webbhotell och IT-leverantör.

Läs mer →091

Personuppgiftsbehandling när leverantörer får åtkomst till servrar

Den som släpper in externa på servrar med kunddata behöver oftast ett personuppgiftsbiträdesavtal. Vad art. 28 GDPR kräver och hur ni organiserar åtkomster dataskyddsenligt i nödläge.

Läs mer →092

Sårbarhetshantering för medelstora företag

Inget medelstort företag kan ta tag i varje varning direkt. En smal cykel av kartläggning, bedömning, beslut och underlag ser till att det viktigaste görs först.

Läs mer →093

Veta vad som körs: förteckning över alla webbplatser och servrar

Vid PHP2Shell stannade många inte på patchen utan på frågan var PHP över huvud taget körs. Så bygger ni upp en förteckning över alla webbplatser och servrar.

Läs mer →094

Patchhantering som process i stället för brandkår

Den som bara patchar när det brinner förlorar tid i ett skarpt läge. Så förenar en patchprocess med fasta klasser, fönster och underlag rutin och nödfall.

Läs mer →095

Nödkontakter: vem måste informeras och när?

I ett skarpt läge avgör vem man når och när. Så bygger ni upp en lista över IT-nödkontakter, med utlösare, ersättare och de uppgifter som varje samtal kräver.

Läs mer →096

Vad en hackad server kostar: kostnadsposterna

En hackad webbserver kostar mer än reparationen. Vilka kostnadsposter som uppstår och hur ni med egna siffror motiverar en budget för förebyggande arbete.

Läs mer →097

Informera kunder efter en incident

Oavsett om det är plikt eller frivilligt: så avgör ni efter en incident vem som ska informeras, vilka kanaler som är säkra och hur kundservice förbereds.

Läs mer →098

Leveranskedjan på webben: byrå, hostingleverantör, tilläggsleverantör

PHP2Shell visade hur många led det finns mellan en patch och er webbplats. Så lär ni känna leveranskedjan, säkrar den och fångar upp bortfall av enskilda led.

Läs mer →099

Säkerhetsmedvetenhet för administratörer och redaktörer: Security Awareness i webbteamet

Den som sköter webbplatser avgör varje dag om säkerheten, ofta utan att märka det. Så utbildar ni administratörer och redaktörer rollanpassat och utan bildspelsslag.

Läs mer →100

Krisövning vid bordet: spela igenom en incident på en webbserver

En övning vid bordet kostar en eftermiddag och visar om er krisplan håller. Här hittar ni ett färdigt manus för en incident på en PHP-webbserver.

Läs mer →101

ISO 27001 och TISAX: vad som berör webbservrar

Den som driver ett ISMS enligt ISO 27001 eller har en TISAX-märkning måste tänka på webbservrar. Här står vilka krav de berör och vilka underlag som räknas efter PHP2Shell.

Läs mer →102

VdS 10000: informationssäkerhet för små och medelstora företag

VdS 10000 är en smal ram för informationssäkerhet i medelstora företag. Vad den kräver, vad som tillkom 2025 och vad det innebär för webbplatser och webbservrar.

Läs mer →103

Lessons learned: bli bättre efter incidenten

Efter incidenten är före nästa. En strukturerad efterträff utan skuldbeläggning gör en dålig vecka till ett mätbart framsteg.

Läs mer →

Beslutsstöd

10 artiklar

104

Direktkontakt

Varje timme räknas. Skriv till oss nu.

Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.

WhatsApp-nödläge Ring