# Požarni zid za spletne strežnike: odprite samo potrebna vrata

> Požarni zid za spletni strežnik: preverite odprta vrata, sprostite le 80 in 443, omejite SSH, zožite odhodne povezave. Z nftables in ufw.

Vir: https://phpsos.de/sl/blog/firewall-fuer-webserver/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Požarni zid za spletni strežnik dohodno dovoli samo TCP 80 in 443, pri HTTP/3 dodatno UDP 443, in SSH samo iz znanih omrežij. Vse drugo se zavrže: zbirke podatkov, predpomnilniki, PHP-FPM in upravljalski vmesniki ne sodijo v internet. Najprej z `ss -tulpn` preverite, kaj posluša, nato zgradite nabor pravil s privzetim »zavrži« in rezultat preizkusite od zunaj. Omejitev odhodnih povezav dodatno omeji posledice vdora.

## Pozabljena vrata ob glavnih vratih

Pri PHP2Shell se je pogled usmeril na sam spletni strežnik, na vrata 80 in 443. Ta morajo biti odprta, sicer spletne strani ni. Pri popisih po takih ranljivostih pa pogosto opazimo nekaj drugega: poleg glavnih vrat so odprta še druga vrata. Zbirka podatkov posluša na vseh omrežnih vmesnikih, pool PHP-FPM na vratih 9000, storitev predpomnilnika brez gesla, upravljalski vmesnik iz faze postavitve.

Vsaka od teh vrat je lastna napadalna površina z lastnimi ranljivostmi. Požarni zid, ki dovoli samo potrebno, jih zapre z nekaj pravili. To je eden najučinkovitejših ukrepov pri zavarovanju lastnega strežnika, kot ga opisuje tudi stran [Samostojno zavarovanje strežnikov root in vServer](https://phpsos.de/sl/server/root-server-vserver/).

## Kaj sodi odprto, kaj ne

Načelo je seznam dovoljenih: vse je zaprto in dosegljive so samo zavestno sproščene storitve. Naslednji pregled pomaga pri umestitvi.

| Storitev | Tipična vrata | Dosegljivo od zunaj? |
|---|---|---|
| HTTP in HTTPS | TCP 80, TCP 443 | da |
| HTTP/3 (QUIC) | UDP 443 | samo če se uporablja |
| SSH | TCP 22 | samo iz znanih omrežij ali prek VPN |
| Nadzorna plošča gostovanja | glede na izdelek | samo iz znanih omrežij |
| MySQL/MariaDB, PostgreSQL | TCP 3306, TCP 5432 | ne |
| Redis, Memcached | TCP 6379, TCP 11211 | ne |
| PHP-FPM | TCP 9000 ali socket Unix | ne, bolje samo socket |
| Poštni strežnik | TCP 25, 465, 587, 993 | samo če strežnik prejema ali nudi pošto |

Storitev, ki ne rabi biti dosegljiva navzven, naj poleg tega posluša samo na `127.0.0.1` ali na socketu Unix. Potem ostane nedosegljiva tudi ob okvari v požarnem zidu. Za upravljalske dostope so primerne sprostitve naslovov IP ali VPN; podrobnosti so v prispevku [Zaščita skrbniških območij prek IP, VPN ali dodatne zaščite](https://phpsos.de/sl/blog/admin-bereiche-abschirmen/).

## Korak 1: ugotovite, kaj posluša

Preden napišete pravila, si ustvarite pregled. Naslednji ukazi samo berejo:

```bash
# Vsa poslušajoča vrata TCP in UDP s procesom
sudo ss -tulpn
# Aktualni nabor pravil nftables
sudo nft list ruleset
# Stanje ufw, če se uporablja
sudo ufw status verbose
```

V izpisu `ss` bodite pozorni na naslov pred vrati. `0.0.0.0` ali `[::]` pomeni: storitev posluša na vseh vmesnikih. `127.0.0.1` pomeni: samo lokalno. Za vsako storitev zabeležite, ali mora biti dosegljiva od zunaj. Ta seznam je hkrati del vašega inventarja strežnikov.

## Požarni zid za spletni strežnik z nftables

nftables je aktualni filter paketov pod Linuxom. Naslednji nabor pravil sledi primeru v uradni wiki nftables in dodaja sprostitev za SSH samo iz upravljalskega omrežja. Naslovi so dokumentacijski primeri in jih je treba zamenjati.

```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 potrebuje odkrivanje sosedov
        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

        # Spletna stran
        tcp dport { 80, 443 } accept
        # samo pri HTTP/3:
        # udp dport 443 accept

        # SSH samo iz upravljalskega omrežja
        ip saddr @verwaltung_v4 tcp dport 22 accept
    }

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

Nabor pravil pred nalaganjem preverite z `nft -c -f /etc/nftables.conf`. Prva vrstica `flush ruleset` izbriše vsa obstoječa pravila, tudi tista, ki sta jih vnesla Docker ali Fail2ban. Na strežnikih z Dockerjem ali drugimi storitvami, ki nastavljajo lastna pravila, zato nabor pravil prilagodite, namesto da bi ga splošno zamenjali. Kako Fail2ban sodeluje s požarnim zidom, piše pod [Postavitev Fail2ban za spletne strežnike](https://phpsos.de/sl/blog/fail2ban-fuer-webserver/).

Kdor želi preprosteje, pod Ubuntujem uporabi `ufw`. Pomemben je vrstni red: najprej sprostitev SSH, nato vklop.

```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
```

> **Pomembno:**
> Pravila požarnega zidu na oddaljenih strežnikih spreminjajte samo z drugo potjo dostopa, na primer s konzolo vašega ponudnika. Napačno pravilo SSH vas sicer izključi samega.

## Odhodne povezave: podcenjena polovica

Večina požarnih zidov odhodno dovoli vse. Za spletni strežnik je to radodarno. Po vdoru napadalci uporabljajo odhodne povezave za nalaganje orodij, odtekanje podatkov ali prejemanje ukazov. Procesi spletnega strežnika ali PHP, ki vzpostavljajo nepričakovane povezave, zato veljajo za opozorilni znak.

Omejitev odhodnih povezav je zahtevnejša, ker mora biti znana vsaka legitimna povezava: viri paketov za posodobitve, plačilne storitve, vmesniki, pošiljanje pošte, časovni strežniki. Pragmatična pot je, da se odhodne povezave najprej beležijo, nato oblikuje seznam dovoljenih in šele nato zapre. Kako preverite obstoječe povezave, opisuje [Preverjanje odhodnih povezav strežnika](https://phpsos.de/sl/blog/ausgehende-verbindungen-pruefen/); katere sledi sicer kažejo na vdor, piše pod [Ali sem že ogrožen?](https://phpsos.de/sl/php2shell/bin-ich-gehackt-anzeichen/).

Za konec od zunaj, z drugega računalnika in samo proti lastnim sistemom, preizkusite, katera vrata so dejansko dosegljiva. Šele ta preizkus pokaže, ali Docker, požarni zid ponudnika in pravila strežnika skupaj dajo želeno sliko.

## Sklep: malo pravil, velik učinek

Požarni zid spletnega strežnika ne sme biti zapleten. Spletna vrata odprta, upravljanje samo iz znanih omrežij, vse drugo zavrženo: s temi osnovnimi pravili zbirke podatkov, predpomnilniki in pozabljene storitve izginejo iz interneta. To je eden od ukrepov z najboljšim razmerjem med naporom in koristjo.

Proti ranljivostim v spletnem strežniku ali v samem PHP požarni zid ne pomaga, ker morajo prav ta vrata ostati odprta. Njegova moč je v tem, da ohranja preostalo napadalno površino majhno in da z omejitvijo odhodnih povezav zajezi posledice vdora.

Odločilno je vzdrževanje. Vsaka nova storitev, vsak vsebnik in vsaka sprememba pri ponudniku lahko sliko premakne. Preverjanje od zunaj zato ponovite po vsaki večji spremembi in v rednih presledkih, na primer enkrat na četrtletje.

## Kako PHP SOS pomaga konkretno?

- **Popis stanja:** zajamemo vse poslušajoče storitve in od zunaj preverimo, kaj je dejansko dosegljivo.
- **Zgraditev nabora pravil:** izdelamo seznam dovoljenih za dohodne in, kjer je smiselno, odhodne povezave, usklajen z Dockerjem, Fail2ban in požarnim zidom ponudnika.
- **Varen prehod:** spremembe izvedemo z drugo potjo dostopa in načrtom za umik.
- **Dokumentiranje:** vrata, sprostitve in razloge zabeležimo v okviru [utrjevanja strežnikov](https://phpsos.de/sl/leistungen/server-haertung/).


## Pogosta vprašanja

**Katera vrata potrebuje spletni strežnik?**  
Za obiskovalce praviloma samo TCP 80 in 443, pri HTTP/3 dodatno UDP 443. SSH in upravljalski vmesniki naj bodo dosegljivi samo iz znanih omrežij ali prek VPN. Vrata zbirk podatkov, predpomnilnika in PHP-FPM ne sodijo v internet.

**Ali požarni zid ščiti pred PHP2Shell?**  
Ne. PHP2Shell se izkorišča prek spletnega strežnika, torej prek prav tistih vrat, ki morajo biti odprta. Požarni zid pa zmanjša preostalo napadalno površino, omejitev odhodnih povezav pa lahko zajezi posledice vdora.

**Zakaj ufw kaže vrata kot zaprta, ki so vendarle dosegljiva?**  
Znan primer so vsebniki Docker: Docker objavljena vrata vnese neposredno v pravila filtra paketov, mimo ufw. Odprta vrata zato vedno dodatno preverite od zunaj.

**Ali zadošča požarni zid mojega ponudnika gostovanja?**  
Predhodni požarni zid ponudnika je dobra druga plast. Požarnega zidu na strežniku pa ne nadomešča, ker ob napaki v konfiguraciji ponudnika ali pri notranjih povezavah ne deluje. Najbolje je uporabiti oba z istimi osnovnimi pravili.

## Viri

- [Wiki nftables: preprost nabor pravil za strežnik](https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server)
- [Ubuntu Server: požarni zid (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)