# Brandvägg för webbservrar: öppna bara nödvändiga portar

> Brandvägg för webbservrar: kontrollera öppna portar, tillåt bara 80 och 443, begränsa SSH, avgränsa utgående anslutningar. Med nftables och ufw.

Källa: https://phpsos.de/sv/blog/firewall-fuer-webserver/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** En brandvägg för webbservrar släpper inkommande bara in TCP 80 och 443, vid HTTP/3 dessutom UDP 443, och SSH bara från kända nät. Allt annat förkastas: databaser, cacher, PHP-FPM och administrationsgränssnitt hör inte hemma på internet. Kontrollera först med `ss -tulpn` vad som lyssnar, bygg sedan ett regelverk med standarden ”förkasta” och testa resultatet utifrån. Att begränsa utgående anslutningar begränsar dessutom följderna av ett intrång.

## De bortglömda dörrarna bredvid ytterdörren

Vid PHP2Shell riktades blicken mot själva webbservern, mot portarna 80 och 443. De måste vara öppna, annars finns ingen webbplats. Vid inventeringar efter sådana sårbarheter märks dock ofta något annat: bredvid ytterdörren står fler dörrar öppna. En databas lyssnar på alla nätverksgränssnitt, en PHP-FPM-pool på port 9000, en cachetjänst utan lösenord, ett administrationsgränssnitt från installationsfasen.

Var och en av dessa dörrar är en egen angreppsyta med egna sårbarheter. En brandvägg som bara släpper igenom det nödvändiga stänger dem med några få regler. Det är en av de mest verksamma åtgärderna när man säkrar en egen server, som även sidan [Säkra root-servrar och vServrar själv](https://phpsos.de/sv/server/root-server-vserver/) beskriver.

## Vad ska vara öppet, vad inte?

Grundprincipen är en tillåtelselista: allt är stängt, och bara medvetet frisläppta tjänster är nåbara. Översikten nedan hjälper till vid placeringen.

| Tjänst | Typisk port | Nåbar utifrån? |
|---|---|---|
| HTTP och HTTPS | TCP 80, TCP 443 | ja |
| HTTP/3 (QUIC) | UDP 443 | bara om det används |
| SSH | TCP 22 | bara från kända nät eller via VPN |
| Hostingpanel | beroende på produkt | bara från kända nät |
| MySQL/MariaDB, PostgreSQL | TCP 3306, TCP 5432 | nej |
| Redis, Memcached | TCP 6379, TCP 11211 | nej |
| PHP-FPM | TCP 9000 eller Unix-socket | nej, helst bara socket |
| Mailserver | TCP 25, 465, 587, 993 | bara om servern tar emot eller tillhandahåller e-post |

En tjänst som inte behöver nå utåt bör dessutom bara lyssna på `127.0.0.1` eller en Unix-socket. Då förblir den onåbar även vid ett haveri i brandväggen. För administrationsåtkomst passar IP-godkännanden eller ett VPN; detaljer finns i inlägget [Skärma av administrationsområden via IP, VPN eller extra skydd](https://phpsos.de/sv/blog/admin-bereiche-abschirmen/).

## Steg 1: ta reda på vad som lyssnar

Innan ni skriver regler skaffar ni en överblick. Kommandona nedan läser bara:

```bash
# Alla lyssnande TCP- och UDP-portar med process
sudo ss -tulpn
# Nftables aktuella regelverk
sudo nft list ruleset
# Status för ufw, om det används
sudo ufw status verbose
```

Lägg märke till adressen före porten i utdata från `ss`. `0.0.0.0` eller `[::]` betyder: tjänsten lyssnar på alla gränssnitt. `127.0.0.1` betyder: bara lokalt. Anteckna för varje tjänst om den måste vara nåbar utifrån. Den listan är samtidigt en del av er serverinventering.

## Brandvägg för webbserver med nftables

nftables är det aktuella paketfiltret under Linux. Regelverket nedan följer exemplet i den officiella nftables-wikin och kompletterar med ett godkännande för SSH bara från ett förvaltningsnät. Adresserna är dokumentationsexempel och måste ersättas.

```nft
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    set verwaltung_v4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.0/28 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        # IPv6 behöver grannupptäckt
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmp type echo-request limit rate 5/second accept
        icmpv6 type echo-request limit rate 5/second accept

        # Webbplats
        tcp dport { 80, 443 } accept
        # bara vid HTTP/3:
        # udp dport 443 accept

        # SSH bara från förvaltningsnätet
        ip saddr @verwaltung_v4 tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}
```

Kontrollera regelverket före inladdningen med `nft -c -f /etc/nftables.conf`. Den första raden `flush ruleset` raderar alla befintliga regler, även sådana som Docker eller Fail2ban har lagt in. På servrar med Docker eller andra tjänster som sätter egna regler anpassar ni därför regelverket i stället för att ersätta det generellt. Hur Fail2ban samarbetar med brandväggen står under [Ställ in Fail2ban för webbservrar](https://phpsos.de/sv/blog/fail2ban-fuer-webserver/).

Den som vill ha det enklare använder under Ubuntu `ufw`. Viktig är ordningen: först SSH-godkännandet, sedan påslagning.

```bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 203.0.113.0/28 to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
```

> **Viktigt:**
> Ändra brandväggsregler på fjärrservrar bara med en andra åtkomstväg, till exempel leverantörens konsol. En felaktig SSH-regel spärrar annars er själva.

## Utgående anslutningar: den underskattade hälften

De flesta brandväggar tillåter allt utgående. För en webbserver är det generöst. Efter ett intrång använder angripare utgående anslutningar för att läsa in verktyg, dra ut data eller ta emot kommandon. Webbserver- eller PHP-processer som upprättar oväntade anslutningar räknas därför som varningstecken.

En begränsning av utgående anslutningar är mer arbetskrävande, eftersom varje legitim anslutning måste vara känd: paketkällor för uppdateringar, betaltjänster, gränssnitt, e-postutskick, tidsservrar. Ett pragmatiskt sätt är att först logga utgående anslutningar, sedan bilda en tillåtelselista och först därefter spärra. Hur ni kontrollerar befintliga anslutningar beskriver [Kontrollera en servers utgående anslutningar](https://phpsos.de/sv/blog/ausgehende-verbindungen-pruefen/); vilka spår som annars tyder på ett intrång står under [Är jag redan komprometterad?](https://phpsos.de/sv/php2shell/bin-ich-gehackt-anzeichen/).

Till sist testar ni utifrån, från en annan dator och bara mot era egna system, vilka portar som faktiskt är nåbara. Först det testet visar om Docker, leverantörens brandvägg och serverregler tillsammans ger den önskade bilden.

## Slutsats: få regler, stor verkan

En brandvägg för webbservrar behöver inte vara komplicerad. Webbportar öppna, administration bara från kända nät, allt annat förkastat: med de grundreglerna försvinner databaser, cacher och bortglömda tjänster från internet. Det är en av åtgärderna med bäst förhållande mellan insats och nytta.

Mot sårbarheter i webbservern eller i själva PHP hjälper brandväggen inte, eftersom just de portarna måste förbli öppna. Dess styrka ligger i att hålla den övriga angreppsytan liten och med en begränsning av utgående anslutningar dämpa följderna av ett intrång.

Avgörande är underhållet. Varje ny tjänst, varje container och varje ändring hos leverantören kan förskjuta bilden. Upprepa därför kontrollen utifrån efter varje större ändring och med fasta intervall, till exempel en gång per kvartal.

## Hur hjälper PHP SOS konkret?

- **Ta inventering:** Vi kartlägger alla lyssnande tjänster och kontrollerar utifrån vad som faktiskt är nåbart.
- **Bygga regelverk:** Vi upprättar en tillåtelselista för inkommande och, där det är meningsfullt, utgående anslutningar, avstämd mot Docker, Fail2ban och leverantörens brandvägg.
- **Ställa om säkert:** Ändringar genomför vi med en andra åtkomstväg och reservplan.
- **Dokumentera:** Portar, godkännanden och skäl dokumenterar vi inom ramen för [serverhärdningen](https://phpsos.de/sv/leistungen/server-haertung/).


## Vanliga frågor

**Vilka portar behöver en webbserver?**  
För besökare i regel bara TCP 80 och 443, vid HTTP/3 dessutom UDP 443. SSH och administrationsgränssnitt bör bara vara nåbara från kända nät eller via VPN. Portar för databas, cache och PHP-FPM hör inte hemma på internet.

**Skyddar en brandvägg mot PHP2Shell?**  
Nej. PHP2Shell utnyttjas via webbservern, alltså via just de portar som måste vara öppna. Brandväggen minskar dock den övriga angreppsytan, och en begränsning av utgående anslutningar kan dämpa följderna av ett intrång.

**Varför visar ufw portar som stängda som ändå är nåbara?**  
Ett känt fall är Docker-containrar: Docker lägger in publicerade portar direkt i paketfilterreglerna, förbi ufw. Kontrollera därför alltid öppna portar dessutom utifrån.

**Räcker min hostingleverantörs brandvägg?**  
En förkopplad brandvägg hos leverantören är ett bra andra lager. Den ersätter dock inte brandväggen på servern, eftersom den inte verkar vid fel i leverantörens konfiguration eller vid interna anslutningar. Bäst använder ni båda med samma grundregler.

## Källor

- [nftables-wiki: enkelt regelverk för en server](https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server)
- [Ubuntu Server: brandvägg (ufw)](https://ubuntu.com/server/docs/how-to/security/firewalls/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)