Blog: PHP2Shell, serversikkerhed og nødhjælp
Vurdering af situationen, vejledninger til administratorer og beslutningsstøtte til ledelsen. Sorteret efter emne, hver artikel med kilder.
Situation og vurdering
17 artikler
PHP2Shell: Hvad er dokumenteret, og hvad er ikke
Et faktatjek om PHP2Shell: Hvilke udsagn stammer fra primære kilder, hvilke fra mediedækning, og hvilke påstande ikke holder.
Læs videre →002Hvorfor PHP-sårbarheden blev kendt før patchen
Ifølge rapporter blev detaljer om PHP2Shell offentlige, før embargoen udløb. Vi forklarer forløbet og hvad det betyder for jeres patchplanlægning.
Læs videre →003Myndigheder tager websites af nettet: Hvad virksomheder kan lære
Mainz, den hessiske delstatsregering og BKA tog websites af nettet som forholdsregel. Hvad virksomheder kan lære af det til deres egen beslutning.
Læs videre →004BSI-advarselsniveau orange: Hvad vurderingen betyder
BSI (det tyske forbundsagentur for informationssikkerhed) har vurderet PHP2Shell til 3 / orange. Hvad skalaen siger, hvad den ikke siger, og hvordan virksomheder omsætter vurderingen til beslutninger.
Læs videre →005Hvad CERT-EU og CERT-Bund anbefaler om PHP2Shell
De officielle instanser er enige: patch straks, ellers isolér. Vi sammenligner anbefalingerne og viser, hvordan isolering ser ud i praksis.
Læs videre →006Cloudflares beskyttelsesregler mod PHP2Shell: Hvad de udretter, og hvad ikke
Cloudflare udrullede tidligt beskyttelsesregler mod PHP2Shell. Hvorfor det hjælper, hvorfor det alligevel ikke erstatter PHP-opdateringen, og hvilke indstillinger I bør kontrollere.
Læs videre →00722,6 millioner eksponerede instanser: Sådan vurderer I tallene rigtigt
Unit 42, CybelAngel og andre nævner meget forskellige tal om PHP2Shell. Vi forklarer, hvad der blev talt, og hvilket tal der virkelig tæller for jer.
Læs videre →008PHP2Shell på fem minutter: Briefing til ledelsen
PHP-sårbarheden PHP2Shell på én side til beslutningstagere: situation, risiko, fem spørgsmål til it og beslutningerne for i dag.
Læs videre →009PHP-sikkerhedssårbarheden forklaret enkelt
PHP2Shell for ikke-teknikere: med hverdagsbilleder, en lille ordliste og tre typiske udgangssituationer for, hvad I som website-ejere bør gøre.
Læs videre →010PHP2Shell: 15 spørgsmål fra hostingkunder
Ligger jeres website hos en hostingudbyder, og vil I vide, hvad I selv skal gøre ved PHP2Shell? Her er de 15 hyppigste spørgsmål med korte svar.
Læs videre →011Hvorfor en WordPress-opdatering ikke hjælper mod PHP2Shell
Mange driftsansvarlige har opdateret WordPress efter overskrifterne og føler sig sikre. Hvorfor det går i stå ved PHP2Shell, og hvad der tæller i stedet.
Læs videre →012PHP2Shell og Log4Shell: Hvad sårbarhederne har tilfælles
Mange sammenligner PHP2Shell med Log4Shell fra 2021. Hvad sammenligningen bærer, hvor den halter, og hvilke erfaringer fra dengang hjælper i dag.
Læs videre →013Massescanninger efter upatchet PHP: Sådan forløber automatiserede angreb
Efter PHP2Shell gennemsøger angribere internettet automatiseret efter sårbare servere. Hvordan det forløber, hvorfor størrelsen er ligegyldig, og hvad der beskytter jer.
Læs videre →014Tidsvinduet mellem patch og angreb
Ved PHP2Shell var der angrebsforsøg allerede før patchen. Vi forklarer tidsvinduets faser, hvordan I måler jeres eget, og hvordan I forkorter det.
Læs videre →015Efter PHP2Shell: Hvorfor flere meddelelser er sandsynlige
PHP2Shell er ikke afsluttet med patchen fra den 21. oktober. Hvorfor opfølgende meddelelser er at vente, og hvordan I indstiller jeres team på det.
Læs videre →016PHP2Shell: Situationsbilledet for den første uge
En uge efter det første observerede angrebsforsøg: status for patches, myndighedsadvarsler, angreb og nedlukninger, ordnet efter kilder.
Læs videre →017Farlige falske tips om PHP2Shell, der cirkulerer lige nu
Blokere cookies, skjule fejlmeddelelser, kun opdatere CMS'et: Ni råd om PHP2Shell, der skaber falsk tryghed, og hvad der virkelig tæller.
Læs videre →Hosting og distributioner
18 artikler
Skift PHP-version i hostingens kundeområde
Hvordan I omstiller PHP-versionen i jeres hostingudbyders kundeområde, hvilken version I vælger, og hvad I kontrollerer før og efter.
Læs videre →019Debian og Ubuntu: Er min PHP-pakke patchet?
Hvilke PHP-pakker Debian og Ubuntu har rettet mod PHP2Shell, hvordan I sammenligner den installerede status nøjagtigt, og hvad dokumentationen kan strande på.
Læs videre →020RHEL, AlmaLinux og Rocky Linux: Kontrollér PHP-patchen
Hvad Red Hat har offentliggjort om PHP2Shell, hvordan I dokumenterer pakkestatus på RHEL og efterbygningerne, og hvorfor en genindlæsning ikke er nok.
Læs videre →021sury.org-repositoryet: PHP-pakker fra en tredjepartskilde
Mange Debian- og Ubuntu-servere får PHP fra sury-repositoryet. Hvad det betyder for opdateringer, dokumentation og gamle PHP-versioner efter PHP2Shell.
Læs videre →022Remi-repositoryet: Hold PHP aktuelt på RHEL-systemer
Remi leverer aktuelle PHP-versioner til RHEL-familien, som modul eller installerbart parallelt. Sådan kontrollerer I status efter PHP2Shell og undgår glemte grene.
Læs videre →023Hvorfor php -v viser det samme nummer efter opdateringen
Opdateringen kørte, men php -v melder den gamle version. Oftest er det en backport og ikke en fejl. Sådan skelner I harmløse fra virkelige problemer.
Læs videre →024Dokumentér CVE-numre i pakkens changelog
Den, der skal dokumentere en PHP-patch over for ledelse, revisorer eller forsikringsselskaber, har brug for mere end et versionsnummer. Sådan bliver changelog-posten til et bevis.
Læs videre →025Skift af hostingudbyder efter en sikkerhedshændelse: Hvad skal I være opmærksomme på?
Efter en hændelse er ønsket om en ny hostingudbyder forståeligt. For at skiftet ikke tager angriberen med, kommer det an på rækkefølge og valg.
Læs videre →026Flere PHP-versioner på én server: Patch hver enkelt for sig
På mange servere kører tre, fire eller flere PHP-installationer side om side. Efter PHP2Shell skal hver enkelt findes, opdateres og genstartes.
Læs videre →027Slå gamle PHP-versioner fra i hostingpanelet
PHP2Shell er en god anledning til at blive af med gamle PHP-versioner. Sådan går I frem i tre faser, så intet website og intet cronjob falder ubemærket ud.
Læs videre →028Plesk: Forstå PHP-handlere (FPM, FastCGI, Apache-modul)
Hvilken PHP-handler Plesk bruger til et website, afgør isolation, konfiguration og risiko. En sammenligning med blik på PHP2Shell.
Læs videre →029CloudLinux og alt-php: Hvad hostingkunder bør vide
På CloudLinux-servere kører websites ofte med egne alt-php-pakker. Hver af disse versioner kræver sin egen patch, og kun serveroperatøren kan indspille den.
Læs videre →030PHP på NAS, firewalls og appliances: de glemte systemer
Det er ikke kun webservere, der bruger PHP. Også NAS-systemer, firewalls og specialenheder med webgrænseflade kan være berørt. Patchen kan dér som regel kun producenten levere, tilgængeligheden regulerer I selv.
Læs videre →031PHP hos cloud- og PaaS-udbydere: Hvem patcher kørselsmiljøet?
På platformtjenester afhænger PHP-patchen af driftsmodellen. Afgørende er det kørselsmiljø, der faktisk leverer, ikke det lokale miljø eller applikationskoden.
Læs videre →032Officielle PHP Docker-images: Tags, digests og genopbygning
Et tag på det officielle PHP-image er en pegepind, der med tiden flytter sig til nye statusser. Den, der ved, hvad tag, variant og digest betyder, vælger det rigtige image og kan dokumentere patchstatus.
Læs videre →033CI/CD: Byg PHP-images automatisk om
Et image forældes også uden kodeændringer. Med tidsstyrede builds, en versionskontrol og udrulning via digest når PHP-patches pålideligt ud i produktion.
Læs videre →034Langtidssupport til gamle PHP-versioner: Muligheder og grænser
Den, der ikke straks kan skifte fra PHP 8.1 eller ældre, finder langtidssupport hos distributioner, tredjepartsudbydere og kommercielle tjenester. Hvad disse veje kan, hvad I skal have skriftligt, og hvor grænserne går.
Læs videre →035Opdatér PHP under Windows
Under Windows findes der ingen automatisk PHP-opdatering. Den, der vælger den rette variant, kontrollerer downloadet og genstarter alle processer, får PHP2Shell-patchen rent ud på hver computer.
Læs videre →Opdagelse og forensik
18 artikler
Advarselstegn: Webserveren starter en shell
Starter en PHP-FPM- eller webserverproces en shell, er det et af de stærkeste advarselstegn på et indbrud. Sådan kontrollerer I procestræet, vurderer undtagelser og overvåger mønsteret varigt.
Læs videre →037Find mistænkelige processer på Linux-servere
Skadelige processer camouflerer sig med harmløse navne og kører fra midlertidige mapper eller fra slettede filer. Med få læsende kommandoer finder I det påfaldende og vurderer det.
Læs videre →038Genkend skjulte cronjobs som bagdør
Angribere bruger planlagte opgaver til at vende tilbage efter en oprydning. Sådan kontrollerer I crontabs, cron-mapper, systemd-timere og at-opgaver fuldstændigt og genkender mistænkelige poster.
Læs videre →039Find nyligt ændrede filer på webserveren
Efter et muligt indbrud tæller det, hvad der har ændret sig på serveren. Sådan søger I efter tidsvinduer, bruger mtime og ctime korrekt og afstemmer med pakker, Git og backups.
Læs videre →040PHP-filer i upload-mappen: Tolk fundstederne korrekt
En PHP-fil i upload-mappen er næsten altid et alarmtegn, men ikke enhver er skadelig kode. Sådan vurderer I fundet uden at ødelægge spor og afklarer, om nogen har kaldt den.
Læs videre →041Genkend tilsløret PHP-kode
Ulæselig PHP-kode med eval og base64_decode er et klassisk tegn på indsmuglet skadelig kode. Hvilke mønstre I skal søge efter, hvordan I finder dem risikofrit, og hvornår tilsløring er legitim.
Læs videre →042Kontrollér en servers udgående forbindelser
En webserver svarer først og fremmest på forespørgsler. Opbygger den selv forbindelser til ukendte mål, kan det betyde styring fra angribere eller dataudsivning. Sådan kontrollerer og begrænser I udgående trafik.
Læs videre →043Find fremde admin-konti i CMS og server
En ukendt administrator er ofte den enkleste bagdør. Sådan søger I niveau for niveau efter fremmede konti, også efter dem, som grænsefladen skjuler.
Læs videre →044Find og fjern ukendte SSH-nøgler
En indsmuglet SSH-nøgle åbner døren for angribere, selv om alle adgangskoder er ændret. Sådan finder I hver authorized_keys-fil og kontrollerer hver post.
Læs videre →045Kryptominer på webserveren: Tegn og fremgangsmåde
Konstant fuld CPU, uden at der kommer flere besøgende: Det kan være en kryptominer. Sådan kontrollerer I belastningen, finder processen og dens genstartsmekanismer og går ordnet frem.
Læs videre →046Serveren sender spam: Find årsagerne
Leveringsfejl, blokeringslister, klager: Når jeres egen server sender spam, står der oftest et script eller en kapret postkasse bag. Sådan finder I kilden.
Læs videre →047SEO-spam og fremmede sider i Googles indeks
Pludselig rangerer sider om medicin eller mærkevarer under jeres domæne. Sådan finder I ud af, hvor SEO-spammen kommer fra, og får den væk fra indekset igen.
Læs videre →048Websitet omdirigerer til fremmede sider
Besøgende havner på konkurrencer eller tvivlsomme shops, men I selv ser intet? Sådan finder I det lag, hvor viderestillingen sidder, og fjerner den.
Læs videre →049Sikr beviser, før I sætter serveren op påny
En genopbygning fjerner angriberen, men også alle spor. Den, der først bruger en time på bevissikring, kan senere sige, hvad der skete.
Læs videre →050Opret tidslinjen for en hændelse
Hvornår kom angriberen, hvad gjorde han, hvornår blev det opdaget? En ren tidslinje besvarer de spørgsmål og er grundlaget for anmeldelser, forsikring og rapport.
Læs videre →051Sammenlign CMS-kernefiler med originalen
Sammenligningen med en ren original viser hver ændret fil, uanset om en scanner kender den. Sådan opbygger I afstemningen for WordPress, Composer-projekter og systempakker.
Læs videre →052Kontrollér databasen for indsmuglet kode
Den, der kun kontrollerer filer, overser halvdelen. Sådan gennemsøger I databasens indhold, indstillinger, triggere og konti for indsmuglet kode, læsende og på en kopi.
Læs videre →053Malwarescannere til websites: Hvad de finder, og hvad ikke
Scanneren melder intet, så er alt godt? Ikke nødvendigvis. Hvilke slags website-scannere der findes, hvad hver enkelt ser, og hvad den principielt ikke kan se.
Læs videre →Hærdning og konfiguration
20 artikler
Isolér PHP-FPM-pools pr. website
En egen pool pr. website er begyndelsen, ikke enden. Sådan kontrollerer I eksisterende pools og hærder sockets, endelser, statussider, ressourcer og logs.
Læs videre →055Sæt memory_limit rigtigt
memory_limit begrænser hukommelsen pr. PHP-forespørgsel. Efter PHP2Shell råder php.net midlertidigt til det modsatte. Hvad der gælder i normal drift, i overgangen og efter opdateringen.
Læs videre →056Begræns post_max_size og upload_max_filesize fornuftigt
Upload-grænser virker tre steder: i webserveren, i PHP og i applikationen. Sådan sætter I værdierne konsistent, også med php.nets overgangsværdier til PHP2Shell.
Læs videre →057Slå session.upload_progress fra: rigtigt og varigt
Afhjælpningen mod CVE-2026-115560 og en af PHP2Shell-overgangsforanstaltningerne er hurtigt sat. For at den holder, skal den stå det rigtige sted, være låst og kontrolleres igen efter hver opdatering.
Læs videre →058expose_php og Server-headeren: Skjul versionsangivelser
PHP, Nginx og Apache nævner som standard deres versionsnummer i hvert svar. Det beskytter ikke mod angreb, men giver scannere en bekvem trefferliste. Sådan slår I det fra og bevarer alligevel overblikket.
Læs videre →059display_errors off: Slå fejludskrifter fra i produktion
Synlige PHP-fejlmeddelelser afslører stier, databasenavne og versioner. Sådan slår I dem fra i PHP, i frameworket og i webserveren uden at miste fejlene af syne.
Læs videre →060php_admin_value: Lås indstillinger mod overskrivning
En sikkerhedsindstilling nytter lidt, hvis applikationen ændrer den igen med en enkelt kodelinje. Med php_admin_value og php_admin_flag fastlægger I værdier bindende for PHP-FPM og Apache.
Læs videre →061Sæt hukommelsesgrænser med systemd og cgroups
php.net anbefaler som PHP2Shell-overgangsforanstaltning memory_limit=-1 og en hukommelsesgrænse uden for PHP. Sådan sætter I grænsen med systemd og cgroups, uden at en enkelt worker trækker hele tjenesten med sig.
Læs videre →062Konfigurér Nginx sikkert til PHP
De fleste svagheder i Nginx-opsætninger til PHP sidder ikke i Nginx, men i få linjer i PHP-location'en. Sådan konfigurerer I overdragelsen til PHP-FPM, så kun de ønskede scripts udføres.
Læs videre →063Konfigurér Apache sikkert til PHP
Apache er fleksibel, og netop det gør den sårbar over for fejlkonfiguration. Sådan binder I PHP på via PHP-FPM, lukker .htaccess som bagdør og indstiller de vigtigste kerneindstillinger sikkert.
Læs videre →064Forbyd PHP-udførelse i upload-mapper
En webshell kræver to ting: en mappe, den kan skrives til, og en server, der udfører den. Sådan fratager I den det andet, og det i hver skrivbar mappe, ikke kun i uploads.
Læs videre →065Filtrér upload-forespørgsler i kanten: Muligheder og risici
Fagforfattere foreslår at blokere upload-forespørgsler uden for rigtige upload-stier ved proxyen, indtil PHP er patchet. Det kan hjælpe, men også lamme formularer og bestillinger. Sådan går I kontrolleret frem.
Læs videre →066Brug ModSecurity og OWASP Core Rule Set
En egen web application firewall med ModSecurity og OWASP Core Rule Set er gratis og stærk, men ingen selvløber. Sådan vælger I engine, starter uden udfald og afstemmer reglerne.
Læs videre →067Opsæt Fail2ban til webservere
Fail2ban spærrer adresser, der gentagne gange falder i øjnene i logs. Til webservere medfølger færdige filtre, og med få linjer kommer egne til. Sådan opsætter I det uden at låse jer selv eller jeres kunder ude.
Læs videre →068Firewall til webservere: Åbn kun nødvendige porte
En webserver har udadtil som regel kun brug for to porte. Alligevel lytter databaser, PHP-FPM eller administrationsflader på mange servere på internettet. Sådan finder I åbne tjenester og lukker det, der ikke bruges.
Læs videre →069Automatiske sikkerhedsopdateringer på Linux-servere
Ifølge rapporter leverede distributioner PHP-backports til dels allerede den 21. oktober 2026, dagen for patcherne. Den, der bruger automatiske sikkerhedsopdateringer, havde dem hurtigt på serveren. For at de også virker, kræves genstarter, tredjepartskilder og kontrol.
Læs videre →070Least Privilege: Webserver-brugerens rettigheder
Indsmuglet kode kører med webserver-brugerens rettigheder. Hvad denne konto må, afgør, hvor langt en angriber kommer. Sådan begrænser I shell, sudo, cron, database og filsystem til det nødvendige.
Læs videre →071Afskærm adminområder med IP, VPN eller ekstra beskyttelse
Hvorfor et websites backend ikke behøver at kunne nås fra hele verden, og hvordan I afskærmer det med IP-frigivelse, VPN eller forudgående login uden at låse jer selv ude.
Læs videre →072Konfigurer TLS og HTTPS rigtigt
Hvilke TLS-versioner og cipher suites en webserver bør tilbyde i dag, hvad anbefalingerne bygger på, og hvordan I kontrollerer Nginx, Apache og PHP's udgående forbindelser.
Læs videre →073CIS-benchmarks og BSI-moduler til webservere
Hvilke hærdningsstandarder der findes til Linux-webservere, hvordan CIS-benchmarks og IT-Grundschutz-moduler adskiller sig, og hvordan I gør dem til en kontrollerbar standard for jeres PHP-servere.
Læs videre →Sikker udvikling
16 artikler
Gem adgangskoder sikkert i PHP: Brug password_hash rigtigt
Hvordan udviklere gemmer adgangskoder i PHP med password_hash og password_verify, vælger den passende metode og afløser gamle MD5- eller SHA-1-hashes uden at nulstille adgangskoden for alle brugere.
Læs videre →075CSRF-beskyttelse i PHP-applikationer
Hvordan udviklere forhindrer Cross-Site Request Forgery i PHP-applikationer: tokens til hver forespørgsel, der ændrer noget, kontrol af oprindelsen i headeren og SameSite-cookies som ekstra lag.
Læs videre →076Validér og filtrér input i PHP med filter_var
Hvordan udviklere kontrollerer input i PHP med filter_var, filter_input_array og tilladelseslister, hvilke filtre der er forældede, og hvorfor validering ikke erstatter prepared statements og outputkodning.
Læs videre →077Forhindr command injection i PHP
Hvordan udviklere undgår command injection i PHP: erstat systemkommandoer med PHP-funktioner, brug proc_open uden shell, kontrollér argumenter og find farlige steder i eksisterende kode.
Læs videre →078Forhindr Server-Side Request Forgery (SSRF) i PHP
Hvordan udviklere forhindrer, at en PHP-applikation på vegne af fremmede forespørger interne systemer: tilladelseslister, protokolbegrænsning, kontrol af den opløste adresse og grænser i netværket.
Læs videre →079Forhindr XML External Entities (XXE) i PHP
Hvordan udviklere behandler XML sikkert i PHP: libxml's standardadfærd, risikable indstillinger som LIBXML_NOENT, beskyttelse med entity-loader og LIBXML_NO_XXE og typiske skjulte XML-indgange.
Læs videre →080Type juggling i PHP: Løse sammenligninger som sikkerhedsrisiko
Hvorfor løse sammenligninger med == i PHP kan føre til sårbarheder, hvad der har ændret sig med PHP 8.0, og hvordan I skriver robuste sammenligninger i logins, tokens og rettigheder.
Læs videre →081Sikre tilfældige tal og tokens i PHP med random_bytes
Hvordan udviklere i PHP genererer tokens til adgangskodelinks, API-nøgler og engangskoder: kryptografisk sikre kilder, tilstrækkelig længde, lagring som hash og begrænset gyldighed.
Læs videre →082Beskyt adgangsdata og .env-filer rigtigt
Sådan beskytter I databaseadgangskoder, API-nøgler og andre hemmeligheder i PHP-projekter: .env-filer uden for webroot, spærring i webserveren, snævre rettigheder og ordnet udskiftning efter en hændelse.
Læs videre →083Offentlig .git-mappe: Et undervurderet datalæk
Hvorfor et webroot, der er udrullet med Git, kan afsløre hele kildekoden inklusive historik, hvordan I kontrollerer det, spærrer med det samme og varigt opbygger deployment uden .git-mappe.
Læs videre →084Backupfiler i webroot: .zip, .sql og .bak
Hvorfor database-dumps, arkiver og sikkerhedskopier i den offentlige mappe hører til de hyppigste datalæk, hvordan I finder og spærrer dem og afklarer, om de er blevet hentet.
Læs videre →085phpinfo()-filer: Hvorfor de skal forsvinde
Efter PHP2Shell opretter mange administratorer hurtigt en info.php. Hvorfor sådanne filer er et datalæk, hvordan I finder dem, og hvilke kontrolveje der er bedre.
Læs videre →086Hold afhængigheder opdaterede: Composer, npm og plugins
Et projekt består af tre pakkeverdener: Composer, npm og CMS-plugins. Sådan holder I alle tre opdaterede med fast rytme, klart ansvar og tests.
Læs videre →087Sikkerhedskodereview til PHP-projekter
Hvordan teams målrettet gennemgår egen PHP-kode for sikkerhedssårbarheder: typer af reviews, kritiske funktioner, fornuftige værktøjer og en tjekliste.
Læs videre →088Log sikkert: Registrér fejl uden datalæk
Logge hjælper ved fejlsøgning og forensik, men bliver hurtigt selv et datalæk. Hvad PHP-applikationer bør logge, hvad aldrig, og hvordan man beskytter logge.
Læs videre →089Sikr REST-API'er i PHP
Grænseflader er ofte dårligere beskyttet end websitet foran dem. De vigtigste regler for REST-API'er i PHP, fra objektrettigheder til hastighedsbegrænsning.
Læs videre →Ledelse og jura
14 artikler
IT-leverandørkontrakter: Fastlæg sikkerhedspligter klart
PHP2Shell har vist, hvor ofte det er uklart, hvem der skal patche. Hvilke sikkerhedspligter der hører hjemme i kontrakter med bureau, hostingudbyder og IT-leverandør.
Læs videre →091Databehandling, når leverandører får adgang til servere
Den, der lader eksterne komme til servere med kundedata, har som regel brug for en databehandleraftale. Hvad art. 28 GDPR kræver, og hvordan I organiserer adgange i en nødsituation i overensstemmelse med databeskyttelsen.
Læs videre →092Sårbarhedshåndtering for mindre og mellemstore virksomheder
Ingen mellemstor virksomhed kan behandle hver eneste melding med det samme. Et slankt kredsløb af registrering, vurdering, beslutning og dokumentation sørger for, at det vigtigste sker først.
Læs videre →093Vid, hvad der kører: oversigt over alle websites og servere
Ved PHP2Shell strandede mange ikke på rettelsen, men på spørgsmålet om, hvor PHP overhovedet kører. Sådan opbygger I en oversigt over alle websites og servere.
Læs videre →094Patch management som proces i stedet for brandslukning
Den, der kun patcher, når det brænder, taber tid i en nødsituation. Sådan forbinder en patch management-proces med faste klasser, vinduer og dokumentation rutine og nødsituation.
Læs videre →095Nødkontakter: Hvem skal informeres hvornår?
I en nødsituation tæller det, hvem man får fat i, og hvornår. Sådan opbygger I en liste over it-nødkontakter med udløsende hændelser, stedfortrædere og de oplysninger, som hvert opkald kræver.
Læs videre →096Hvad en hacket server koster: Omkostningsposterne
En hacket webserver giver flere omkostninger end selve reparationen. Hvilke omkostningsposter der opstår, og hvordan I med egne tal begrunder et budget til forebyggelse.
Læs videre →097Underret kunder efter en hændelse
Pligt eller frivilligt: Sådan afgør I efter en hændelse, hvem I informerer, hvilke kanaler der er sikre, og hvordan jeres kundeservice er forberedt.
Læs videre →098Leverandørkæden på nettet: Bureau, hostingudbyder, plugin-udbyder
PHP2Shell har vist, hvor mange led der ligger mellem en patch og jeres website. Sådan kender, sikrer og opfanger I udfald af enkelte led i jeres websites leverandørkæde.
Læs videre →099Sikkerhedsbevidsthed for administratorer og redaktører: Security awareness i webteamet
Den, der vedligeholder websites, træffer dagligt sikkerhedsbeslutninger, ofte uden at lægge mærke til det. Sådan skoler I administratorer og redaktører rollebaseret og uden slideshow-maraton.
Læs videre →100Nødøvelse ved bordet: Gennemspil en hændelse på webserveren
En øvelse ved bordet koster en eftermiddag og viser, om jeres nødplan holder. Her finder I en færdig drejebog til en hændelse på en PHP-webserver.
Læs videre →101ISO 27001 og TISAX: Hvad der berører webservere
Den, der driver et ISMS efter ISO 27001 eller har et TISAX-label, skal tænke webservere med. Her står, hvilke krav de berører, og hvilken dokumentation der tæller efter PHP2Shell.
Læs videre →102VdS 10000: Informationssikkerhed for små og mellemstore virksomheder
VdS 10000 er en slank ramme for informationssikkerhed i mellemstore virksomheder. Hvad den kræver, hvad der kom nyt i 2025, og hvad det betyder for websites og webservere.
Læs videre →103Lessons learned: Bliv bedre efter hændelsen
Efter hændelsen er før den næste. En struktureret eftergennemgang uden skyldsfordeling gør en dårlig uge til målbar fremgang.
Læs videre →Beslutningsstøtte
10 artikler
Patche, lukke ned eller vente? En beslutningshjælp ved PHP-sårbarheden
Ved en kritisk PHP-sårbarhed skal de ansvarlige beslutte hurtigt. Denne hjælp ordner de tre muligheder, nævner kriterier og viser, hvornår det er forsvarligt at vente.
Læs videre →105WAF eller opdatering: Hvorfor I har brug for begge dele
En Web Application Firewall kan opfange angreb, men lukker ikke en sårbarhed i PHP-fortolkeren. Hvornår en WAF hjælper, hvor den ender, og hvordan I kombinerer begge fornuftigt.
Læs videre →106Opsætte serveren på ny eller rydde op? Beslutningen efter et angreb
Efter et indbrud står to veje åbne: rydde serveren op eller bygge den op på ny. Hvilke kriterier der afgør det, og hvorfor rækkefølgen er vigtigere end valget.
Læs videre →107Udbedre selv eller hente en leverandør? En ærlig afvejning
Ikke enhver sikkerhedssituation kræver ekstern hjælp. Med disse kriterier og en kort selvtest afgør I, om jeres team klarer PHP2Shell alene, eller om det har brug for støtte.
Læs videre →108Vælg en it-sikkerhedsleverandør: 12 spørgsmål før opgaven
Under tidspres er det svært at finde en god sikkerhedsleverandør. Disse tolv spørgsmål hjælper med at sammenligne tilbud sagligt uden at falde for reklameløfter.
Læs videre →109Managed hosting eller egen server? Sikkerhedssammenligningen
PHP2Shell var en stresstest for enhver driftsmodel. Sammenligningen viser, hvornår managed hosting er sikrere, hvornår egen server er, og hvilke blandingsformer der har vist sig at fungere.
Læs videre →110PHP-opgradering eller backport? Beslutningen for ældre systemer
For gamle PHP-versioner findes der efter PHP2Shell flere veje: distributionens backport, tredjepartskilde, kildekodepatch, langtidssupport eller opgradering. Hvad hver vej duer til, og hvor længe den holder.
Læs videre →111Skifte CMS efter hacket? Hvornår det hjælper, og hvornår ikke
Efter et indbrud er tilliden til CMS'et ofte væk. Men et nyt system løser sjældent den egentlige årsag. Hvornår skiftet er fornuftigt, og hvordan det lykkes rent.
Læs videre →112Statiske websites: Mindre PHP, mindre angrebsflade
Et statisk website leverer færdige HTML-filer og kræver ikke PHP på serveren. Det mindsker angrebsfladen betydeligt, men har egne grænser og pligter.
Læs videre →113Pentest, bug bounty eller sårbarhedsscanning? Vælg den rette kontrolmetode
Scanning, penetrationstest og bug bounty kontrollerer websites på vidt forskellige måder. Hvad hver metode kan, hvor den svigter, og hvilken rækkefølge der passer til jeres virksomhed.
Læs videre →Hver time tæller. Skriv til os nu.
Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.