Hoppa till innehåll 
Brandvägg iptables och UFW kontrollerar vilka anslutningar en webbserver accepterar och vilka jag blockerar - detta avgör attackytan och misslyckanden. I den här praktiska artikeln visar jag tydliga regler, säkra standardinställningar och testade kommandon för SSH, HTTP(S), databaser, loggning, IPv6 och Docker - direkt tillämpliga på produktiva värdar.
Centrala punkter
Följande viktiga punkter ger mig en snabb orientering innan jag börjar med konfigurationen.
- Begränsande Start: Standardavvisning för inkommande, öppna specifikt
- SSH Tillåt först: Riskera inte åtkomst
- UFW som gränssnitt: enkel syntax, iptables i bakgrunden
- Loggning aktivera: Kontrollera regler, känna igen attacker
- Uthållighet säkerställa: Upprätthålla regler för omstarter
Grunderna: iptables och UFW i korthet
Jag förlitar mig på iptablesnär jag behöver finkornig kontroll över paket, kedjor och matchningar. Jag använder UFW när jag snabbt vill tillämpa tillförlitliga regler som internt slutar som iptables-regler [1]. Detta gör att jag kan kombinera enkla kommandon med kraften i Linux nätfilter utan att gå vilse i detaljerna. För webbservrar innebär detta att jag bygger ett tydligt filter framför Apache, Nginx eller Node så att endast den önskade trafiken kommer fram [2]. Denna separation minskar attackytorna och gör att attacker misslyckas oftare.
Båda verktygen kompletterar varandra och jag bestämmer vilket som passar bäst i situationen. UFW utmärker sig genom att vara lättläst, särskilt på Ubuntu och Debian [3]. iptables ger mig utökade alternativ, till exempel för NAT, specifika gränssnitt och komplexa matchningar. Viktigt: Jag dokumenterar mina regler kortfattat så att det är lätt att underhålla dem senare. Om du vill lära dig mer om säkerhetskonceptet kan du hitta en tydlig introduktion här: Brandvägg som skyddande sköld.
Starta konfigurationen: Ställ in standardpolicyer på ett säkert sätt
Jag börjar med Standard-Policyer: Blockera inkommande, tillåt utgående. Det är så här jag förhindrar att nya tjänster blir oavsiktligt tillgängliga. Jag tillåter alltid loopback så att interna processer fungerar stabilt. Jag accepterar befintliga anslutningar för att undvika avbrott. Denna sekvens minimerar fel vid aktivering av brandväggen [2][5].
Jag använder UFW för att ställa in basen med bara några få kommandon. Jag kontrollerar sedan statusen i detalj för att omedelbart upptäcka skrivfel. För särskilt känsliga värdar begränsar jag också utgående portar. Detta minskar risken för dataläckage om en tjänst har äventyrats. Jag använder ofta följande kommandon:
# UFW: Standardregler
sudo ufw standard neka inkommande
sudo ufw standard tillåter utgående
# Alternativ striktare policy för utgående
sudo ufw standard neka utgående
sudo ufw tillåter ut 53
sudo ufw tillåter ut 80
sudo ufw tillåter ut 443
# Kontrollera status
sudo ufw status verbose
Stateful-filtrering: tillstånd och sekvens
Ett rent paketflöde står och faller med Conntrack säger. Jag accepterar etablerade anslutningar först, avvisar ogiltiga paket tidigt och lämnar loopback öppen. Detta minskar belastningen och förhindrar bieffekter på grund av sena avhopp. För iptables ställer jag avsiktligt in ordningen:
# iptables: solid grund
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Tillåt alltid loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Tillåt befintliga/associerade anslutningar
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Släpp ogiltiga paket tidigt
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Med UFW tas redan hänsyn till ESTABLISHED/RELATED internt. Jag är också uppmärksam på om jag föredrar DROP (tyst) eller AVVISA (aktiv, snabbare failover). För interna nätverk föredrar jag REJECT, i det publika nätverket vanligtvis DROP.
Grundläggande regler för webbservrar: SSH, HTTP och HTTPS
Jag byter SSH först, annars låser jag lätt ut mig själv. Sedan tillåter jag HTTP och HTTPS så att webbservern blir tillgänglig. Jag ställer bara in de portar som jag verkligen behöver. Senare lägger jag valfritt till hastighetsbegränsning eller Fail2ban för att stävja brutala inloggningsförsök. Jag kontrollerar varje ändring omedelbart med kommandona status eller list.
Jag håller kommandona för detta enkla. UFW erbjuder talande alias för webbportar, vilket ökar läsbarheten. Med iptables kan jag ställa in exakta portar och protokoll. Jag sparar iptables-reglerna i efterhand så att de överlever omstarten. Här är de minsta stegen:
# SSH
sudo ufw tillåter 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw tillåter http
sudo ufw tillåter https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
Säker SSH: Begränsa och öppna selektivt
Förutom frisläppandet dämpar jag attacker med Begränsning av hastighet eller vitlistor. UFW ger ett enkelt skydd:
# SSH hastighetsbegränsning (UFW)
sudo ufw limit 22/tcp kommentar "SSH-hastighetsbegränsning"
Jag ställer in finare gränser med iptables. Detta förhindrar massiv lösenordsgissning utan att utesluta legitima administratörer:
# SSH: Begränsa anslutningsförsök per källa
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
Där det är möjligt tillåter jag bara SSH från IP-adresser för administratörer och arbeta med SSH-nycklar. Att byta portar är ingen ersättning för säkerhet, men det kan minska bullret. Jag dokumenterar undantagen och kontrollerar dem regelbundet.
Säkra databaser och begränsa IP-källor
Jag öppnar aldrig databasportar globalt, utan bara lokal eller för definierade käll-IP-adresser. Detta hindrar skannrar från att hitta öppna MySQL-, PostgreSQL- eller MongoDB-portar. För lokala appar är 127.0.0.1 tillräckligt som mål; jag kontrollerar extern administratörsåtkomst strikt via IP. Jag dokumenterar ändringar kortfattat, till exempel i serverwikin. Detta sparar tid för mig vid revisioner.
Jag använder ofta följande exempel i projekt. Jag kontrollerar i förväg att varje tillåten IP är korrekt. UFW tillåter en ren "från-till"-notation, iptables implementerar samma logik tekniskt. Jag använder ytterligare tillståndsregler för tillfälliga underhållsfönster och tar bort dem efteråt. Detta håller gränssnittet litet:
# Endast lokalt: MySQL
sudo ufw allow från 127.0.0.1 till valfri port 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Tillåt en enda IP
sudo ufw allow från 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Tillåt port för specifik IP
sudo ufw allow från 10.1.2.3 till valfri port 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Blockera kända angripare
sudo ufw deny från 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Ren hantering av loggning, gränssnitt och IPv6
Jag byter Loggning för att verifiera regler och känna igen iögonfallande trafik. Nivå "on" i UFW är tillräcklig för de flesta värdar, jag använder bara högre nivåer selektivt. Jag analyserar loggar med journalctl, fail2ban eller SIEM-verktyg. Detta gör att jag kan känna igen mönster från skanningar eller brute force-försök. Om något avviker justerar jag reglerna omedelbart [2].
Jag knyter ofta regler till en specifik Gränssnitttill exempel eth0 i publika nätverk. Detta förhindrar att interna nätverk påverkas i onödan. UFW kan "allow in on eth0 to any port 80", iptables använder -i för input interfaces. För IPv6 kontrollerar jag aktiveringen i /etc/default/ufw för "IPV6=yes" och använder ip6tables för inbyggda regler [2]. Denna separation undviker luckor med dual-stack-värdar.
ICMP och ICMPv6: Tillgänglighet utan luckor
Jag lämnar nödvändiga ICMP-typer så att MTU-identifiering, timeouts och diagnostik fungerar. ICMP är inte en fiende, utan kärnan i IP-protokollet. Jag begränsar bara överdrivna ekon.
# IPv4: Begränsa eko, tillåt viktiga ICMP-typer
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/sekund --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: Tillåt ICMP i allmänhet (finjustering i before.rules möjlig)
sudo ufw tillåt in proto icmp
På IPv6 ICMPv6 är absolut nödvändigt (Neighbour Discovery, Router Advertisement). Jag tillåter kärntyperna och begränsar ekoförfrågningar:
# 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/sekund --limit-burst 20 -j ACCEPT
Använda begränsning av utgående trafik och NAT/masquerading på rätt sätt
Jag begränsar utgående trafik när jag Riskprofil och efterlevnad. Jag tillåter DNS och HTTPS och blockerar allt annat utom för definierade mål. Detta minskar mängden exfiltrerad data om en tjänst kapas. Jag skapar definierade undantag för applikationer som kräver uppdateringar eller API:er. Jag dokumenterar dessa undantag på ett tydligt sätt och kontrollerar dem regelbundet.
För routningskonfigurationer använder jag NAT/Masquerading via UFW-Before-Rules eller raw med iptables. Jag är uppmärksam på kedjornas ordning så att paketen skrivs om på rätt sätt. Efter ändringar testar jag konnektivitet och latenser. För produktionssystem planerar jag ett underhållsfönster och säkerhetskopierar konfigurationen. Detta gör att jag kan hålla nätverksvägarna spårbara [7].
Utgående information: systemtjänster och protokoll
Med en strikt utgående policy tillåter jag specifikt DNS (53/udp), HTTPS (443/tcp) och om så krävs NTP (123/udp). För e-postservrar lägger jag till 25/tcp och 587/tcp. Jag löser inte domänbaserade undantag på paketnivå, utan via proxyer eller applikationslogik.
# UFW: typiska systemtjänster
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - endast om e-postserver
sudo ufw allow out 587/tcp # Submission - endast om det behövs
# iptables: specifik Tillåt
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 och brandväggar: så undviker du fallgropar
Docker sätter sin egen iptables-regler som kan påverka min policy. Jag kontrollerar därför NAT- och FORWARD-kedjorna efter varje komponerings- eller daemonstart. Jag släpper medvetet exponerade portar och undviker "-p 0.0.0.0:PORT". Istället binder jag dem till administrations-IP:n eller den omvända proxyn. Detta gör att attackvektorn blir mindre och mer synlig [1].
Jag håller värdbrandväggar aktiva trots Docker. Jag kontrollerar också säkerhetsgrupper på infrastrukturnivå, om sådana finns. I händelse av konflikter mellan UFW och Docker använder jag dokumenterade lösningar eller fastställer regler i DOCKER-USER. Det är viktigt att ha tydliga ansvarsområden: värden blockerar alltid, containrar öppnar endast explicit. Denna ordning förhindrar omedvetna releaser.
# DOCKER-USER: Tillämpa global värdpolicy före 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
Fininställningar för UFW: Sekvens, profiler och dirigerad trafik
När precision räknas använder jag "infoga", "numrerad" och app-profiler. Det är så här jag håller regelsekvensen ren och använder testade servicedefinitioner.
# Kontrollsekvens
sudo ufw insert 1 neka in från 198.51.100.0/24
# Numrerad vy och riktad borttagning
sudo ufw status numrerad
sudo ufw radera 3
# App-profiler (t.ex. Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full"
sudo ufw tillåter "Nginx Full"
# Blockera dirigerad trafik som standard (vidarebefordran)
sudo ufw default deny routed
Jag lagrar mer komplexa undantag i före.regler resp. efter.regler. Där kan jag placera ICMP-fintrimning eller NAT exakt utan att förlora läsbarheten hos standardreglerna.
Beständiga regler: Spara och återskapa
Med UFW är reglerna ihållande och överlever automatiskt omstarter. Detta förenklar administrationen på Debian/Ubuntu-värdar avsevärt. Med iptables sparar jag reglerna efter ändringar och återställer dem vid uppstart. Jag använder iptables-save/restore eller netfilter-persistent för detta. Utan dessa steg förlorar jag annars ändringarna efter en omstart [5].
Jag testar uthållighet systematiskt: schemalägger en omstart och kontrollerar sedan statusen. Om räknarna och kedjorna är korrekta är konfigurationen solid. Om regler saknas korrigerar jag laddningsvägen i init- eller systemd-kontexten. Denna rutin förhindrar överraskningar under underhåll. Dokumentation och säkerhetskopiering av regelfilerna avrundar proceduren.
# Debian/Ubuntu: Persistens för iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent spara
# Manuell säkerhetskopiering
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
#-återställning (om så krävs)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Prestanda och skydd: gränser, inställningar och kernel tuning
När belastningen är hög minskar jag antalet kontroller och använder riktade Gränsvärden för priser. För stora blocklistor arbetar jag med ipset för att minska uppslagstiderna. Jag använder också systembaserade skyddsmekanismer:
# Innehåller SYN-flod (kärna)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Begränsa HTTP-anslutningshastigheten per käll-IP (exempel)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/sekund
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Jag behåller storleken på Conntrack bord på ett ögonblick. Om det finns många samtidiga anslutningar ökar jag nf_conntrack_max, men testar effekterna i förväg.
Hantering, tester och förebyggande av fel
Jag lämnar SSH innan jag aktiverar "neka inkommande". Jag testar sedan från en andra session om åtkomsten förblir stabil. Jag kontrollerar varje ny regel med "ufw status verbose" eller "iptables -L -v". Detta gör att jag kan känna igen träffräknare och se om paket landar i den förväntade kedjan. Jag säkerhetskopierar brandväggsfilerna innan jag gör några större ändringar.
För att få en heltäckande säkerhet kombinerar jag brandväggen med härdningssteg i systemet. Dessa inkluderar säkra SSH-inställningar, patchhantering och minimala tjänster. Jag använder gärna en praktisk guide som checklista: Serverhärdning för Linux. Jag upprepar dessa kontroller regelbundet och håller mig till fasta underhållsfönster. På så sätt håller jag mina servrar i gott skick på ett tillförlitligt sätt.
Avancerade tester och observationer
Jag kontrollerar den externa påverkan med Portskanning från ett externt nätverk och verifiera öppna socklar internt. Jag övervakar loggar noga i början för att tidigt upptäcka falska slutsatser.
# Öppna uttag
ss -lntup
# iptables översikt kompakt
sudo iptables -S
sudo iptables -L -v -n
# UFW: detaljerad status och loggar
sudo ufw status verbose
journalctl -k | grep -i ufw
# Extern kontroll (från en annan värd/nätverk)
nmap -Pn -p 22,80,443
För högriskförändringar planerar jag en Reservnivå på. Jag arbetar i Screen/Tmux och ställer vid behov in en tidsstyrd återställning om jag låser mig ute. Efter ett lyckat test avbryter jag reservåtgärden igen.
# Exempel: automatisk avaktivering som nödankare (använd försiktigt)
echo "ufw disable" | nu + 2 minuter
# Ta bort igen efter ett lyckat test: atrm
Jämförelse av hostingleverantörer: Fokus på brandväggsintegration
För hosting förlitar jag mig på Säkerhet nära plattformen. Anpassade policyer, snabba regeldistributioner och bra övervakning lönar sig. I aktuella jämförelser imponerar webhoster.de med snyggt integrerade brandväggsalternativ och snabb support. De som föredrar panelkonfigurationer drar nytta av tydliga instruktioner för Plesk brandvägg. Följande tabell kategoriserar viktiga kriterier.
| Leverantör | Integrering av brandvägg | Prestanda | Stöd | Placering |
|---|---|---|---|---|
| webhoster.de | individuellt konfigurerad. | Mycket hög | topp | 1 |
| Leverantör B | Standard | hög | bra | 2 |
| Leverantör C | Standard | bra | Tillfredsställande | 3 |
Praktiska exempel: Från test till produktionsregel
Jag börjar varje regeluppsättning i Skärm eller i en andra SSH-session. På så sätt kan jag fortfarande rädda mig själv om det skulle uppstå ett driftfel. Först när en testvärd fungerar som den ska tillämpar jag regler i produktionen. Regler för returväg och en rollback-plan ger mig ytterligare säkerhet. I slutet dokumenterar jag ändringarna kortfattat i ändringsloggen.
Jag använder återkommande byggstenar för webbservrar: tillåt SSH, släpp HTTP/S, bind interna portar lokalt, logga in, begränsa ICMP, blockera överflödiga protokoll. Jag tar sedan hand om IPv6-spegelningsregler så att inga luckor kvarstår. Jag kontrollerar alltid Docker-kedjor separat eftersom de anger sina egna sökvägar. Slutligen validerar jag åtkomst via externa kontroller och övervakning. Detta håller gränssnittet rent och spårbart [1][2].
Sammanfattning för administratörer
Med tydlig Regler och några kommandon säkrar jag webbservrar på ett tillförlitligt sätt. Inkommande standard neka, SSH först, aktivera HTTP/S - detta utgör den stabila grunden. Databasportar endast lokalt eller via vitlista, loggning aktiv, observera IPv6, kontrollera dockerkedjor. Beständig lagring och regelbundna tester förhindrar obehagliga överraskningar. Den här rutinen håller tjänsterna tillgängliga och minskar riskerna avsevärt.
Oavsett om jag använder UFW eller iptables direkt är en tydlig och ekonomisk policy avgörande. Jag dokumenterar kortfattat, verifierar regelbundet och håller undantagen till ett minimum. Begränsning av utgående trafik stoppar onödiga anslutningar och begränsar skadan i händelse av intrång. Med ett tränat öga på loggar upptäcker jag avvikelser snabbare och kan reagera på lämpligt sätt. På så sätt håller jag webbservern motståndskraftig och attackytan liten.
