Videre til indhold 
Firewall iptables og UFW styrer, hvilke forbindelser en webserver accepterer, og hvilke jeg blokerer - det bestemmer angrebsfladen og fejlene. I denne praktiske artikel viser jeg klare regler, sikre standardindstillinger og testede kommandoer til SSH, HTTP(S), databaser, logning, IPv6 og Docker - direkte anvendelige på produktive værter.
Centrale punkter
Følgende nøglepunkter giver mig en hurtig orientering, før jeg går i gang med konfigurationen.
- Restriktiv Start: Standardafvisning for indgående, åben specifikt
- SSH Tillad først: Risikér ikke adgang
- UFW som grænseflade: enkel syntaks, iptables i baggrunden
- Logning aktivere: Tjekke regler, genkende angreb
- Vedholdenhed sikre: Oprethold regler for genstart
Grundlæggende: iptables og UFW på et øjeblik
Jeg stoler på iptablesnår jeg har brug for finkornet kontrol over pakker, kæder og matches. Jeg bruger UFW, når jeg hurtigt vil anvende pålidelige regler, der internt ender som iptables-regler [1]. Det giver mig mulighed for at kombinere enkle kommandoer med styrken i Linux' netfilter uden at fortabe mig i detaljerne. For webservere betyder det: Jeg bygger et klart filter foran Apache, Nginx eller Node, så kun den ønskede trafik kommer frem [2]. Denne adskillelse reducerer angrebsoverflader og gør det muligt for angreb at mislykkes oftere.
Begge værktøjer supplerer hinanden, og jeg beslutter, hvilket der passer til situationen. UFW scorer med ren læsbarhed, især på Ubuntu og Debian [3]. iptables giver mig udvidede muligheder, for eksempel for NAT, specifikke grænseflader og komplekse matches. Vigtigt: Jeg dokumenterer mine regler kortfattet, så det er nemt at vedligeholde dem senere. Hvis du vil lære mere om sikkerhedskonceptet, kan du finde en klar introduktion her: Firewall som et beskyttende skjold.
Start konfiguration: Indstil standardpolitikker sikkert
Jeg begynder med Standard-Politikker: Bloker indgående, tillad udgående. Det er sådan, jeg forhindrer, at nye tjenester bliver utilsigtet tilgængelige. Jeg tillader altid loopback, så interne processer fungerer stabilt. Jeg accepterer eksisterende forbindelser for at undgå aflysninger. Denne sekvens minimerer fejl, når firewallen aktiveres [2][5].
Jeg bruger UFW til at indstille basen med nogle få kommandoer. Derefter tjekker jeg status i detaljer for at opdage skrivefejl med det samme. For særligt følsomme værter begrænser jeg også udgående porte. Det reducerer risikoen for datalækager, hvis en tjeneste er blevet kompromitteret. Jeg bruger ofte følgende kommandoer:
# UFW: Standardregler
sudo ufw default deny indgående
sudo ufw standard tillader udgående
# Alternativ strengere udgående politik
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw tillader udgående 80
sudo ufw tillader udgående 443
# tjekker status
sudo ufw status verbose
Tilstandsbaseret filtrering: Tilstande og sekvens
Et rent parcelflow står og falder med Conntrack siger. Jeg accepterer etablerede forbindelser først, kasserer ugyldige pakker tidligt og lader loopback være åben. Det reducerer belastningen og forhindrer bivirkninger på grund af sene drop. For iptables indstiller jeg bevidst rækkefølgen:
# iptables: solidt grundlag
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Tillad altid loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Tillad eksisterende/associerede forbindelser
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Drop ugyldige pakker tidligt
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Med UFW er der allerede taget højde for ESTABLISHED/RELATED internt. Jeg er også opmærksom på, om jeg foretrækker DROP (lydløs) eller AFVIS (aktiv, hurtigere failover). Til interne netværk foretrækker jeg REJECT, i det offentlige netværk normalt DROP.
Vigtige regler for webservere: SSH, HTTP og HTTPS
Jeg skifter SSH først, ellers låser jeg nemt mig selv ude. Derefter tillader jeg HTTP og HTTPS, så der er adgang til webserveren. Jeg indstiller kun de porte, jeg virkelig har brug for. Senere tilføjer jeg eventuelt hastighedsbegrænsning eller Fail2ban for at bremse brutale login-forsøg. Jeg tjekker alle ændringer med det samme med status- eller listekommandoer.
Jeg holder kommandoerne til dette enkle. UFW tilbyder talende aliaser for webporte, hvilket øger læsbarheden. Med iptables kan jeg indstille præcise porte og protokoller. Jeg gemmer iptables-reglerne bagefter, så de overlever genstarten. Her er minimumstrinnene:
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw tillader https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Sikker SSH: Begræns og åbn selektivt
Ud over frigørelsen dæmper jeg angreb med Begrænsning af hastighed eller hvidlister. UFW giver enkel beskyttelse:
# SSH-hastighedsbegrænsning (UFW)
sudo ufw limit 22/tcp comment "SSH-hastighedsbegrænsning"
Jeg sætter finere grænser med iptables. Det forhindrer massiv gætning af adgangskoder uden at udelukke legitime administratorer:
# SSH: Begræns forbindelsesforsøg pr. kilde
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP
Hvor det er muligt, tillader jeg kun SSH fra Administrator-IP-adresser og arbejde med SSH-nøgler. Ændring af porte er ingen erstatning for sikkerhed, men det kan reducere støj. Jeg dokumenterer undtagelserne og tjekker dem regelmæssigt.
Sikre databaser og begræns IP-kilder
Jeg åbner aldrig databaseporte globalt, men kun lokal eller for definerede kilde-IP-adresser. Det forhindrer scannere i at finde åbne MySQL-, PostgreSQL- eller MongoDB-porte. For lokale apps er 127.0.0.1 tilstrækkeligt som mål; jeg kontrollerer ekstern administratoradgang strengt via IP. Jeg dokumenterer ændringer kort, f.eks. i serverens wiki. Det sparer mig tid under revisioner.
Jeg bruger ofte følgende eksempler i mine projekter. Jeg tjekker på forhånd, om hver tilladt IP er korrekt. UFW tillader en ren "fra-til"-notation, iptables implementerer den samme logik teknisk. Jeg bruger ekstra tilladelsesregler til midlertidige vedligeholdelsesvinduer og sletter dem bagefter. Det holder grænsefladen lille:
# Kun lokalt: MySQL
sudo ufw allow fra 127.0.0.1 til enhver port 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Tillad en enkelt IP
sudo ufw allow fra 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Tillad port for specifik IP
sudo ufw allow fra 10.1.2.3 til enhver port 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Bloker kendte angribere
sudo ufw deny fra 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Ren håndtering af logning, grænseflader og IPv6
Jeg skifter Logning for at verificere regler og genkende iøjnefaldende trafik. Niveau "on" i UFW er tilstrækkeligt for de fleste værter, jeg bruger kun højere niveauer selektivt. Jeg analyserer logfiler med journalctl, fail2ban eller SIEM-værktøjer. Det giver mig mulighed for at genkende mønstre fra scanninger eller brute force-forsøg. I tilfælde af uregelmæssigheder justerer jeg straks reglerne [2].
Jeg knytter ofte regler til en bestemt Grænsefladesåsom eth0 i offentlige netværk. Det forhindrer, at interne netværk påvirkes unødigt. UFW kan "allow in on eth0 to any port 80", iptables bruger -i til input-grænseflader. For IPv6 tjekker jeg aktiveringen i /etc/default/ufw for "IPV6=yes" og bruger ip6tables til indbyggede regler [2]. Denne adskillelse undgår huller med dual-stack-værter.
ICMP og ICMPv6: Tilgængelighed uden huller
Jeg efterlader nødvendige ICMP-typer, så path MTU discovery, timeouts og diagnostik fungerer. ICMP er ikke en fjende, men kernen i IP-protokollen. Jeg begrænser kun overdrevne ekkoer.
# IPv4: Begræns ekko, tillad vigtige ICMP-typer
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: Tillad ICMP generelt (finjustering i before.rules mulig)
sudo ufw allow in proto icmp
På IPv6 ICMPv6 er absolut nødvendig (Neighbour Discovery, Router Advertisement). Jeg tillader kernetyperne og begrænser ekkoforespørgsler:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Brug udgående begrænsning og NAT/masquerading korrekt
Jeg begrænser udgående trafik, når jeg Risikoprofil og overholdelse. Jeg tillader DNS og HTTPS og blokerer alt andet undtagen for definerede mål. Det reducerer exfiltrerede data, hvis en tjeneste bliver kapret. Jeg opretter definerede undtagelser for applikationer, der kræver opdateringer eller API'er. Jeg dokumenterer disse undtagelser tydeligt og kontrollerer dem regelmæssigt.
Til routing-opsætninger bruger jeg NAT/Masquerading via UFW-Before-Rules eller raw med iptables. Jeg er opmærksom på rækkefølgen af kæderne, så pakkerne bliver omskrevet korrekt. Efter ændringer tester jeg forbindelser og ventetider. For produktionssystemer planlægger jeg et vedligeholdelsesvindue og tager backup af konfigurationen. Det giver mig mulighed for at holde netværksstierne sporbare [7].
Udgående detaljer: systemtjenester og protokoller
Med en streng udgående politik tillader jeg specifikt DNS (53/udp), HTTPS (443/tcp) og om nødvendigt NTP (123/udp) For mailservere tilføjer jeg 25/tcp og 587/tcp. Jeg løser ikke domænebaserede undtagelser på pakkeniveau, men via proxyer eller applikationslogik.
# UFW: typiske systemtjenester
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - kun hvis mailserver
sudo ufw allow out 587/tcp # Submission - kun hvis det er nødvendigt
# iptables: specifik tilladelse
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker og firewalls: undgå faldgruber
Docker indstiller sin egen iptables-regler, der kan påvirke min politik. Jeg tjekker derfor NAT- og FORWARD-kæderne efter hver komponist- eller dæmonstart. Jeg frigiver bevidst eksponerede porte og undgår "-p 0.0.0.0:PORT". I stedet binder jeg dem til management-IP'en eller den omvendte proxy. Det holder angrebsvektoren mindre og mere synlig [1].
Jeg holder host-firewalls aktive på trods af Docker. Jeg kontrollerer også sikkerhedsgrupper på infrastrukturniveau, hvis det er muligt. I tilfælde af konflikter mellem UFW og Docker bruger jeg dokumenterede workarounds eller sætter regler i DOCKER-USER. Det er vigtigt at have klare ansvarsområder: Værten blokerer altid, containere åbner kun eksplicit. Denne rækkefølge forhindrer ubevidste udgivelser.
# DOCKER-USER: håndhæv global værtspolitik før Docker-regler
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
UFW's fine indstillinger: Sekvens, profiler og dirigeret trafik
Når præcision tæller, bruger jeg "Indsæt", "nummereret" og app-profiler. Det er sådan, jeg holder regelsekvensen ren og bruger testede servicedefinitioner.
# Kontrolsekvens
sudo ufw insert 1 deny in fra 198.51.100.0/24
# Nummereret visning og målrettet sletning
sudo ufw status numbered
sudo ufw delete 3
# App-profiler (f.eks. Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw allow "Nginx Full"
# Bloker dirigeret trafik som standard (videresendelse)
sudo ufw default deny routed
Jeg gemmer mere komplekse undtagelser i før.regler hhv. efter.regler. Der kan jeg placere ICMP-finjustering eller NAT præcist uden at miste læsbarheden af standardreglerne.
Vedvarende regler: Gem og gendan
Med UFW-regler er vedholdende og overlever automatisk genstart. Det forenkler i høj grad administrationen på Debian/Ubuntu-værter. Med iptables gemmer jeg reglerne efter ændringer og gendanner dem ved opstart. Jeg bruger iptables-save/restore eller netfilter-persistent til dette. Uden disse trin mister jeg ellers ændringer efter en genstart [5].
Jeg tester vedholdenhed systematisk: planlægger en genstart og tjekker derefter status. Hvis tællerne og kæderne er korrekte, er konfigurationen solid. Hvis der mangler regler, retter jeg belastningsstien i init- eller systemd-konteksten. Denne rutine forhindrer overraskelser under vedligeholdelse. Dokumentation og backup af regelfilerne afrunder proceduren.
# Debian/Ubuntu: Vedholdenhed for iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent gem
# Manuel sikkerhedskopiering
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
# Restore (hvis nødvendigt)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Ydelse og beskyttelse: grænser, sæt og kernel tuning
Når belastningen er høj, reducerer jeg antallet af kontroller og bruger målrettet Prisgrænser. Til store bloklister arbejder jeg med ipset for at reducere opslagstiderne. Jeg bruger også systembaserede beskyttelsesmekanismer:
# indeholder SYN-oversvømmelse (kerne)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Begræns HTTP-forbindelseshastigheden pr. kilde-IP (eksempel)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Jeg beholder størrelsen på Conntrack-bord på et øjeblik. Hvis der er mange samtidige forbindelser, øger jeg nf_conntrack_max, men tester effekten på forhånd.
Ledelse, test og forebyggelse af fejl
Jeg går SSH før jeg aktiverer "deny incoming". Derefter tester jeg fra en anden session, om adgangen forbliver stabil. Jeg tjekker hver ny regel med "ufw status verbose" eller "iptables -L -v". Det giver mig mulighed for at genkende hit-tællere og se, om pakkerne lander i den forventede kæde. Jeg tager en sikkerhedskopi af firewallfilerne, før jeg foretager større ændringer.
For at opnå omfattende sikkerhed kombinerer jeg firewallen med hærdningstrin på systemet. Disse omfatter sikre SSH-indstillinger, patch management og minimale tjenester. Jeg kan godt lide at bruge en praktisk guide som tjekliste: Hærdning af servere til Linux. Jeg gentager disse kontroller regelmæssigt og holder mig til faste vedligeholdelsesvinduer. Det holder mine servere i pålidelig form.
Avanceret testning og observation
Jeg tjekker den eksterne påvirkning med Havnescanninger fra et eksternt netværk og verificere åbne sockets internt. Jeg overvåger logfiler nøje i begyndelsen for at kunne genkende falske konklusioner på et tidligt tidspunkt.
# Åbne stikkontakter
ss -lntup
# iptables oversigt kompakt
sudo iptables -S
sudo iptables -L -v -n
# UFW: detaljeret status og logfiler
sudo ufw status verbose
journalctl -k | grep -i ufw
# Eksternt tjek (fra en anden vært/netværk)
nmap -Pn -p 22,80,443 .
For højrisikoforandringer planlægger jeg en Fallback-niveau på. Jeg arbejder i Screen/Tmux og indstiller om nødvendigt en tidsstyret nulstilling, hvis jeg låser mig selv ude. Efter en vellykket test annullerer jeg fallback-handlingen igen.
# Eksempel: automatisk deaktivering som nødanker (brug omhyggeligt)
echo "ufw disable" | at now + 2 minutter
# Slet igen efter vellykket test: atrm
Sammenligning af hostingudbydere: Fokus på firewall-integration
Til hosting er jeg afhængig af Sikkerhed tæt på platformen. Tilpassede politikker, hurtig implementering af regler og god overvågning betaler sig. I aktuelle sammenligninger imponerer webhoster.de med pænt integrerede firewall-muligheder og hurtig support. De, der foretrækker panelopsætninger, nyder godt af klare instruktioner til Plesk firewall. Følgende tabel kategoriserer de vigtigste kriterier.
| Udbyder | Firewall-integration | Ydelse | Støtte | Placering |
|---|---|---|---|---|
| webhoster.de | individuelt konfigureret. | Meget høj | top | 1 |
| Udbyder B | Standard | høj | godt | 2 |
| Udbyder C | Standard | godt | Tilfredsstillende | 3 |
Praktiske eksempler: Fra test til produktionsregel
Jeg starter hvert regelsæt i Skærm eller i en anden SSH-session. På den måde kan jeg stadig redde mig selv i tilfælde af en driftsfejl. Først når en testhost kører korrekt, anvender jeg regler i produktionen. Regler for returvej og en rollback-plan giver mig yderligere sikkerhed. Til sidst dokumenterer jeg ændringerne kortfattet i ændringsloggen.
Jeg bruger tilbagevendende byggesten til webservere: Tillad SSH, frigiv HTTP/S, bind interne porte lokalt, log på, begræns ICMP, bloker overflødige protokoller. Derefter tager jeg mig af IPv6-spejlingsreglerne, så der ikke er nogen huller tilbage. Jeg tjekker altid Docker-kæder separat, fordi de indstiller deres egne stier. Endelig validerer jeg adgangen via eksterne kontroller og overvågning. Det holder grænsefladen ren og sporbar [1][2].
Oversigt til administratorer
Med tydelig Regler og nogle få kommandoer sikrer jeg webservere pålideligt. Indgående standardafvisning, SSH først, frigivelse af HTTP/S - dette danner det stabile grundlag. Databaseporte kun lokalt eller via whitelist, logning aktiv, observere IPv6, tjekke docker-kæder. Vedvarende lagring og regelmæssige tests forhindrer ubehagelige overraskelser. Denne rutine holder tjenesterne tilgængelige og reducerer risikoen betydeligt.
Uanset om jeg bruger UFW eller iptables direkte, er en klar, økonomisk politik afgørende. Jeg dokumenterer kort, verificerer regelmæssigt og holder undtagelser på et minimum. Begrænsning af udgående trafik stopper unødvendige forbindelser og begrænser skaden i tilfælde af kompromittering. Med et trænet øje på logfiler genkender jeg uregelmæssigheder hurtigere og reagerer hensigtsmæssigt. Det holder webserveren modstandsdygtig og angrebsfladen lille.
