Guide til Firewall Opsætning: Beskyt Din Server Mod DDoS og Bots

Opsætning af en server-firewall handler om kun at åbne de nødvendige porte og blokere al unødig adgang. Det er det første forsvarslag mod DDoS, brute force-angreb og skadelig bottrafik. I praksis betyder det at begrænse SSH-adgang, kontrollere åbne webservices, rate-limit mistænkelige forespørgsler, overvåge logs og filtrere trafikken allerede før den rammer serveren – fx med CDN/WAF løsninger.

Så snart du åbner en webserver mod internettet, vil du indenfor minutter se portscanninger, SSH-brute force, sårbarheds-bots og falske user agents. Firewall er ikke kun en teknisk beslutning – det er essentielt for driften, især hvis du kører WordPress, e-handel, API'er, kontrolpaneler eller spilservere. Denne guide tager dig trin for trin gennem opbygning af en firewall på Linux-servere: UFW, firewalld, nftables, Fail2ban, webapplikations-firewall og DDoS-mitigation. Du får både strategi og praktiske eksempler.

En vigtig realitet: En lokal server-firewall stopper ikke massive DDoS-angreb alene. Når et angreb på fx 20 Gbps eller 80 Gbps rammer datacenter eller netværksinfrastruktur, fyldes båndbredden længe før pakken når din server. Det kræver lagdelt sikkerhed: DDoS-beskyttelse hos udbyder, CDN/WAF, OS-firewall, rate-limiting og løbende loganalyse. Vælg den rette platform via Hostragons VPS og VDS serverløsninger, og find sikre hostingmuligheder på Hostragons webhosting pakker.

Hvad Er Formålet Med En Server-firewall?

En server-firewall filtrerer netværkstrafik baseret på IP-adresser, porte, protokoller, forbindelsesstatus og i nogle tilfælde pakkens indhold. Eksempel: For dit website skal port 80 og 443 være åbne, men port 3306 til databasen bør aldrig være åbne mod internettet. SSH-porten (22) bør ikke være åben for alle, men kun for din arbejdsplads' IP-adresse.

En firewall fjerner ikke alle angreb magisk. Målet er at minimere angrebsfladen – jo færre åbne porte/services, jo færre muligheder for angribere. En ny Linux-server kan have SSH, webpanel, mail, database, monitoring-agenter og testservices åbne – hver med deres egen risiko. En velfungerende firewall arbejder efter princippet: "deny by default, allow as needed".

Forstå DDoS og Bottrafik

Hvorfor er DDoS-angreb særligt udfordrende?

DDoS (Distributed Denial of Service) angriber ved at overvælde dit system med trafik fra mange kilder. Angrebet kan fylde båndbredde, tømme CPU/RAM, eller trigge tunge applikations-processer. Fx kan en appserver, der får 50.000 HTTP-requests pr. sekund, gå ned – selv hvis netværket ikke er fyldt – fordi PHP-FPM, Node.js eller database-poolen ikke kan følge med.

Er bots altid skadelige?

Nej. Bots som Googlebot og Bingbot er nyttige. Men skadelige bots scanner admin-paneler, søger efter åbne kataloger, spammer formularer, kopierer indhold, misbruger XML-RPC, opretter falske konti og tester login. Målet er ikke at blokere alle bots, men at adskille dem baseret på adfærd. Tegn på skadelige bots: Høj fejlrate, mange requests på kort tid, user agents der ikke ligner rigtige browsere, mistænkelige URL-mønstre.

Tjekliste Før Du Starter Opsætning

Den største risiko ved at skrive firewall-regler på en live server er at låse dig selv ude. Forbered dig altid før ændringer. Brug denne tjekliste som sikker start:

• Luk ikke din aktive SSH-session – test i et andet terminalvindue.
• Sørg for at din udbyder tilbyder konsol, VNC eller recovery-adgang.
• List åbne porte: Brug ss -tulpn eller netstat -tulpn.
• Notér hvilke porte web, mail, DNS, database, panel og overvågning bruger.
• Planlæg IPv6-firewall regler, hvis du bruger IPv6.
• Start med allow-regler, derefter deny-regler.
• Sørg for at reglerne er permanente – de skal overleve genstart.

Eksempel: På en typisk server der kun hoster websites skal kun port 80, 443 og begrænset SSH være åbne. Hvis du ikke kører mailserver, skal portene 25, 465, 587, 993 ikke være åbne. Hvis databasen kun bruges lokalt, skal port 3306 eller 5432 forblive lukket mod internettet.

Valg af Firewall-værktøj

Der findes flere værktøjer i Linux-verdenen – de styrer samme kerne-filtrering, bare med forskellig brugerflade. UFW er enkel og hurtig for begyndere. Firewalld dominerer på Red Hat-baserede systemer. Nftables er moderne og fleksibel til avancerede behov. Se sammenligningen her:

Trin-for-trin Opsætning af Server-firewall

1. Identificér Åbne Porte og Services

Start med at se, hvad der er åbent: ss -tulpn viser hvilke services der lytter på hvilke porte. Fx hvis nginx lytter på 0.0.0.0:80 og 0.0.0.0:443, accepteres webtrafik fra alle interfaces. Hvis MariaDB lytter på 0.0.0.0:3306, er det ofte farligt – databasen bør lytte på 127.0.0.1.

Hovedreglen: Ingen service, der ikke skal være tilgængelig fra internettet, må lytte på 0.0.0.0. Ret først service-konfigurationen, derefter firewall. Selv hvis firewallen slås fra, må servicen ikke være åben mod verden.

2. Sæt Default Policy Til "lukket"

En sikker firewall har default "deny" for inbound trafik, og tillader outbound efter behov. Det forhindrer utilsigtet åbning af nye services. På Ubuntu med UFW: først tillad SSH fra admin-IP, dernæst åbne 80 og 443, så sæt default inbound til deny, og aktiver firewallen.

Eksempel: Giv adgang til SSH for din IP, åbn HTTP/HTTPS, luk resten, og aktiver. At aktivere firewallen før SSH er tilladt, er en klassisk fejl på remote servere.

3. Begræns SSH-adgang

SSH er ofte mål for brute force. En server med port 22 åben får dagligt tusindvis af forsøg. Det sikreste er at begrænse SSH til faste IP-adresser. Har du en statisk IP, tillad kun din arbejdsplads eller VPN. Har du ikke, brug i det mindste key-basert autentificering og luk for password login.

• Luk for root-login via SSH.
• Brug SSH-nøgler frem for password.
• Brug AllowUsers/AllowGroups til at begrænse brugere.
• Automatisk blokering af mislykkede forsøg med Fail2ban.
• Restriktiv adgang til admin-panel-porten (IP-begrænsning).

At skifte port hjælper kun lidt mod automatiserede bots, men den virkelige beskyttelse ligger i IP-begrænsning, stærk autentificering og log-overvågning.

4. Kontrolleret Åbning af Webporte

De fleste webservere behøver port 80 og 443. I dag bør 443 (HTTPS) være standard; 80 bruges kun til redirect til HTTPS. Manglende SSL giver dårlig brugeroplevelse og påvirker SEO negativt. Se Hostragons SSL certifikater for hjælp til HTTPS-opsætning.

Hvis du bruger CDN eller reverse proxy, bør serverens 80/443 kun være åben for CDN's IP-ranges. Angribere kan ikke ramme webservicen direkte, selv hvis de kender din rigtige IP.

5. Luk Databasen og Interne Services Mod Internettet

MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB m.fl. bør aldrig være åbne mod internettet. Manglende autentificering på Redis, åben Elasticsearch eller MongoDB har tidligere medført massive datalækager. Disse services bør kun lytte på localhost eller private netværk.

Fx for WordPress på samme server, skal database køre på 127.0.0.1. Hvis du har separate app- og databaseservere, tillad kun app-serverens private IP. Aldrig åbne 3306 eller 5432 mod verden – det er en velkendt fejl, som bots konstant scanner efter.

6. Stop Brute Force med Fail2ban

Fail2ban overvåger logs og blokerer IP'er med gentagne mislykkede login-forsøg. Du kan opsætte jails for SSH, nginx, Apache, Postfix, Dovecot, WordPress-login og panelservices. Fx: 5 mislykkede SSH-forsøg på 10 minutter blokeres i 1 time – effektivt og simpelt.

Vær forsigtig med for aggressive regler – du kan ende med at blokere rigtige brugere. Start med moderate værdier for bantime, overvåg logs, og stram gradvist til.

7. Rate Limiting og Begrænsning af Forbindelser

Mod DDoS og bots kan OS-level rate-limiting hjælpe. Fx kan du begrænse antallet af nye forbindelser pr. IP pr. sekund. På webservere: Nginx har limit_req og limit_conn, Apache har mod_evasive osv. Applikationer bør rate-limite login, søgning, kurv, betaling og API-endpoints.

Eksempel: Login-siden kan tillade 10 forsøg pr. IP pr. minut, en søge-endpoint 2-5 requests pr. sekund, API kan have både user-token, IP og adfærdsbaseret limit. Så kan en angriber ikke omgå alle begrænsninger ved at skifte IP.

Eksempel: Sikker UFW Opsætning

På Ubuntu/Debian kan du starte sikkert med: tjek aktive services, tillad SSH fra admin-IP, åbn 80/443, sæt default deny for inbound, og tjek UFW-status. Har du ikke statisk IP, tillad midlertidigt SSH fra alle, og skift senere til VPN eller statisk IP.

Eksempel: Admin-IP er 203.0.113.10. SSH er kun åben for denne IP, webtrafik er åben for alle på 80/443, database, Redis, panel og testport er lukket. Det er et godt udgangspunkt for de fleste virksomhedssites. For korrekt DNS/redirect kan du linke til Hostragons domænesøgning og registrering.

Firewalld: Zone-baseret Sikkerhed

Firewalld er standard på AlmaLinux, Rocky Linux og RHEL. Det bruger zone-konceptet: public zone til internet, trusted til interne net, drop til sortlistede IP'er. Vigtigst er forskellen på runtime og permanent regler – runtime gælder straks, men forsvinder efter genstart; permanent kræver reload, men er blivende.

Brug service-baserede regler for nem styring: Åbn http/https på public zone, SSH kun for specifikke IP'er. Har du flere netværksinterfaces, kan du tildele forskellige zones for backup, admin og brugertrafik – det øger både sikkerhed og overblik.

CDN, WAF og DDoS-beskyttelse hos Udbyder

Den lokale firewall reagerer først når pakken når serveren. Ved store DDoS-angreb skal trafikken filtreres før den når serveren. CDN, WAF og udbyder-baseret DDoS-beskyttelse er derfor afgørende. CDN leverer statisk indhold fra edge-noder, WAF filtrerer skadelig applikationstrafik, udbyderen absorberer eller renser netværksangreb.

Den optimale model: Dit DNS peger på CDN, din server-IP er skjult, firewallen tillader kun CDN's IP-range på 80/443. Adminporte er kun tilgængelige via VPN eller statisk IP. Det minimerer risikoen for direkte IP-angreb og stopper bots før de når applikationen. For guides om webspeed og sikkerhed, se websted hastighedsforøgelse og sikkerhedsvejledninger.

Botbeskyttelse på Applikationsniveau

Botbeskyttelse handler ikke kun om IP-bans. Moderne bots bruger proxy, mobilnet, datacenter-IP og varierende user agents. Man skal analysere adfærd: Mange loginforsøg fra samme IP, mange 404-scans, høj trafik på wp-login.php eller xmlrpc.php, atypiske klikmønstre, mistænkelige headers.

• Brug rate-limiting på login og registreringsformularer.
• Luk eller begræns unødvendig XML-RPC-adgang.
• Skjul admin-panel bag alternativ URL, IP-begrænsning og multifaktor-login.
• Filtrer mistænkelige user-agent/referer-mønstre i WAF.
• Brug CAPTCHA eller usynlig botkontrol på formularer – men balancer det.
• Sæt API-kontrol på nøgle, signatur, quota og tidsstempel.

Det er vigtigt ikke at ødelægge brugeroplevelsen – for meget CAPTCHA, aggressive blokeringer eller fejlagtige land-blokeringer rammer ægte kunder. Test, måling og gradvis tightening er bedste praksis.

Log Overvågning og Alarmer

Tro ikke at opsætningen er "færdig". Firewallen er dynamisk og skal overvåges: auth.log/secure for SSH, nginx access logs for unormal trafik, error logs for 404/500 spikes, system metrics for CPU og connections. Selv en simpel alarm kan redde dig minutter ved angreb.

Eksempler på tærskler: Over 100 x 404 requests fra samme IP på 5 min, over 20 loginforsøg på 1 min, CPU over 90% i 10 min, connections 3x normal. Tilpas til dit site – vigtigst er at kende din normale trafikprofil.

Typiske Fejl og Hvordan Du Undgår Dem

• Aktivering af firewall uden SSH-adgang: Kan låse dig helt ude af remote server. Test altid med ekstra session.
• Glemmer IPv6: Service kan være åben på IPv6 selv hvis IPv4 er lukket.
• Databasen er åben mod internettet: Porte som 3306, 5432, 6379, 9200 scannes konstant af bots.
• Bruger CDN men lader rigtig IP være åben: Angribere kan omgå CDN og ramme serveren direkte.
• Ændrer regler uden dokumentation: Det bliver svært at forstå hvad der sker ved fejl.
• Ingen backup-adgang: Uden konsol/recovery kan en forkert regel føre til lang nedetid.

Eksempel på Praktisk Firewall-politik

For et mindre firmawebsite kan en god politik være: Default inbound lukket, 443 åben for alle, 80 kun til HTTPS-redirect, SSH kun for VPN/statisk admin-IP, database kun på localhost/private net, 80/443 kun for CDN's IP-range, Fail2ban på SSH og login, daglige logs til central overvågning.

For en mellemstor webshop: Allowlisting af payment callback-IP'er, admin-panel bag VPN, API med user-quota, WAF med SQL injection/XSS-regler, midlertidig land/ASN-filtrering. Nedskriv planen – det gør det nemmere under angreb.

Test: Virker Reglerne?

Efter opsætning skal du teste: Portscan fra et eksternt netværk, SSH kun fra tilladte IP'er, web kun via HTTPS, database lukket mod verden. Bruger du CDN, test om direkte HTTP til server-IP blokeres.

Undgå aggressive scans på produktionssystemer. Målet er sikker validering. Tag backup af regler efter hver ændring – så kan du altid rulle tilbage.

Vedligeholdelse og Opdatering

Server-sikkerhed er ikke engangsarbejde – det kræver løbende vedligehold. Når du tilføjer nye services, vurder portbehov; fjern gamle services, slet tilladelser; opdater sikkerhed, og tjek logs regelmæssigt. Tjek åbne porte mindst månedligt, gennemgå firewall-regler hvert kvartal.

Backup-planen er en del af sikkerheden – DDoS kan blokere adgang, men ransomware eller uautoriseret adgang kan slette data. Overvej hosting, SSL, domæne og backup samlet. Se Ting at overveje ved valg af sikker hosting og hvordan man installer SSL certifikat for relevant videre info.

Konklusion

Firewall opsætning gør ikke din server usynlig for DDoS og bots, men det reducerer angrebsfladen markant, sænker risikoen for uautoriseret adgang og giver dig bedre kontrol ved hændelser. Det bedste resultat opnås ved at kombinere DDoS-beskyttelse hos udbyder, CDN/WAF, stram portpolitik, SSH-begrænsning, Fail2ban, rate-limiting og log-overvågning.

Planlæg din firewall-politik fra starten – det er langt lettere end at rette op senere. Når du evaluerer server, hosting, domæne og SSL hos Hostragons, så tænk sikkerhed ind fra begyndelsen og skab et mere robust webmiljø. Start evt. med en simpel tjekliste: Luk åbne porte, begræns SSH, kræv HTTPS, overvåg logs.

Ofte Stillede Spørgsmål

Beskytter firewall helt mod DDoS?

Nej. En lokal firewall kan dæmpe små og visse protokol-baserede angreb, men mod massive DDoS kræves udbyder-beskyttelse, CDN og WAF.

Hvilke porte skal være åbne på en webserver?

Typisk kun port 80 og 443. SSH kun for admin-IP'er. Database og interne ports skal være lukket mod internettet.

Skal jeg vælge UFW eller firewalld?

UFW er lettest på Ubuntu/Debian. Firewalld bruges på AlmaLinux, Rocky Linux og RHEL. Avancerede behov kan kræve nftables.

Kan jeg stoppe bots kun med IP-banning?

Nej. Moderne bots bruger mange IP'er og proxies. Kombiner IP-bans med rate-limiting, WAF-regler, adfærdsanalyse, CAPTCHA og quotas.

Hvad er den største risiko ved firewall-opsætning?

At miste SSH-adgang pga. forkerte regler. Giv altid SSH-tilladelse først, test i ekstra session og hav konsol/recovery adgang klar.