Ugrás a tartalomhoz

Sütibeállítások

Típusonként válassza ki, mely sütiket engedélyezi. Választását bármikor módosíthatja a Sütibeállítások linken, amely minden oldal alján megtalálható. Adatvédelmi nyilatkozat

Szükséges

Mindig bekapcsolva

A bejelentkezéshez, a kosár megőrzéséhez és a választásai megjegyzéséhez szükségesek. Ezek mindig be vannak kapcsolva.

Milyen sütik?
  • weboke_sessie, weboke_klant, weboke_remember: a munkamenet és a bejelentkezve maradás
  • weboke_basket: a kosár
  • wkBtwIncl: az árak megjelenítése ÁFÁ-val vagy anélkül
  • wok_cookies: a sütiválasztás, 12 hónap

Méri, melyik hirdetés vezet látogatáshoz vagy rendeléshez, hogy ne fizessünk hatástalan hirdetésekért.

Milyen sütik?
  • Google Ads a Google Tag Manageren keresztül (_gcl_au, _gcl_aw), legfeljebb 90 napig
  • OpenAI Ads, hirdetések a ChatGPT-ben
  • wok_aff: melyik partnerünk ajánlására érkezett (partnerprogram), 60 nap

4,6

Ország és nyelv

Minden országnak saját oldala van, az adott ország áraival és ÁFA-jával.

Megtekintés

Tűzfal ufw-vel és nftables-szel

Modul 5: A hálózat védelme · Olvasási idő: 12 perc

Tanulási cél: A lecke után Ön képes lesz olyan tűzfalat beállítani, amely csak azt engedi át, amire szükség van, IPv4-en és IPv6-on egyaránt, anélkül hogy kizárná saját magát, és tudni fogja, mi ellen nem véd a szerverén futó tűzfal.

Kulcsfogalmak: csomagszűrő, netfilter, nftables, iptables-nft, ufw, alapértelmezett házirend, allow, deny, reject, limit, IPv6 az ufw-ben, a szolgáltató tűzfala, firewalld, a Docker és a tűzfal

Mit csinál a tűzfal?

A szerveren futó tűzfal egy csomagszűrő: minden beérkező hálózati csomagnál végignézi a szabályok listáját, és eldönti, hogy átengedi-e. Linuxon ez a szűrő a kernelben található, a neve netfilter. Egy programmal állítható be:

  • Az nftables (parancs: nft) a jelenlegi eszköz. A Debian a Debian 10 óta alapértelmezésként ezt használja.
  • Az iptables a régi eszköz. Modern rendszereken a iptables általában nftables-re fordít (iptables-nft), így a régi útmutatók továbbra is működnek.
  • Az ufw (Uncomplicated Firewall) egy egyszerű réteg ezek fölött: Ubuntun alapból megtalálható, Debianon egyetlen paranccsal telepíthető. Egyetlen szerverhez az ufw a legkényelmesebb választás. Ez a lecke az ufw-t használja, majd megmutatja, hogyan néznek ki ugyanezek a szabályok nftables-ben.

A tűzfal a második védelmi vonal. Az első az, hogy a szolgáltatások csak a megfelelő címen figyelnek (lecke 5.1). A kettő együtt biztosítja, hogy az egyik rétegben elkövetett hiba ne jelentsen azonnal nyitott ajtót.

Először: hogyan jut vissza, ha valami elromlik?

A klasszikus hiba: bekapcsolja a tűzfalat, elfelejti engedélyezni az SSH-t, és megszakad a kapcsolat. Ezután SSH-n már nem éri el a szervert. Mielőtt belekezdene:

  1. Tudja, hogyan nyitja meg a szolgáltatója konzolját (lecke 1.2). Ez a hálózattól függetlenül működik, tehát akkor is, ha a tűzfal mindent lezár. Ott bejelentkezik, és beírja: ufw disable.
  2. Ha bizonytalan, készítsen pillanatképet (snapshot).
  3. Hagyja nyitva a jelenlegi SSH-munkamenetet, és egy második munkamenettel teszteljen.

Az ufw öt lépésben

1. lépés: telepítés és az alapértelmezés kiválasztása.

anna@web1:~$ sudo apt install ufw
anna@web1:~$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
anna@web1:~$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'

Az alapértelmezett házirend mindenre vonatkozik, amire nincs külön szabály. A „Deny incoming” azt jelenti: minden beérkező forgalom tiltott, kivéve azt, amit ezután engedélyez. Ez az egyetlen biztonságos alap. A kimenő forgalmat (amikor a szerver például frissítéseket tölt le) engedélyezzük.

2. lépés: az SSH engedélyezése, még a tűzfal bekapcsolása előtt.

anna@web1:~$ sudo ufw allow OpenSSH
Rules updated
Rules updated (v6)

Az OpenSSH egy alkalmazásprofil, amelyet az ufw ismer (a 22/tcp portot jelenti). Ha az SSH másik porton fut, használja a port számát: sudo ufw allow 2222/tcp. Figyeljen a „Rules updated (v6)” üzenetre: az ufw IPv6-ra is létrehozza a szabályt. Ezt azért teszi, mert a /etc/default/ufw fájlban a IPV6=yes beállítás szerepel, ami az alapértelmezés. Érdemes ezt ellenőrizni; ha no értékre van állítva, a tűzfal csak IPv4-re érvényes.

3. lépés: amire még szüksége van.

anna@web1:~$ sudo ufw allow 80/tcp
anna@web1:~$ sudo ufw allow 443/tcp
anna@web1:~$ sudo ufw allow 443/udp       # csak HTTP/3 használata esetén

Egy szabályt egyetlen forráscímre is korlátozhat, például egy adminisztrációs portot, amely csak az irodájából érhető el:

anna@web1:~$ sudo ufw allow from 198.51.100.20 to any port 9090 proto tcp

4. lépés: bekapcsolás.

anna@web1:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

5. lépés: ellenőrzés. Nyisson egy második ablakot, és jelentkezzen be újra. Ha sikerül, az SSH beállítása rendben van. Ezután nézze meg a szabályokat:

anna@web1:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Egy szabályt sorszám alapján törölhet: sudo ufw status numbered, majd sudo ufw delete 3.

deny, reject és limit

  • A deny csendben eldobja a csomagot: kívülről „szűrt” állapotot lát (lecke 5.1).
  • A reject elutasítást küld vissza: kívülről „zárt” állapotot lát. A saját szolgáltatásainál ez elegánsabb, de elárulja, hogy van ott egy szerver.
  • A limit engedélyezi a kapcsolatot, de letilt egy címet, amely 30 másodpercen belül hatszor vagy többször próbál kapcsolódni. SSH-nál hasznos: sudo ufw limit OpenSSH a allow helyett. Ez durva módszer (a kapcsolatokat számolja, nem a sikertelen bejelentkezéseket); a fail2ban (lecke 5.3) pontosabb.

Ugyanezek a szabályok nftables-ben

Az ufw a háttérben netfilter-szabályokat ír. Ha ufw nélkül szeretne dolgozni, saját nftables-fájlt kell írnia. Debianon ez a /etc/nftables.conf fájl, és a nftables szolgáltatással töltheti be:

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

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        meta l4proto { icmp, ipv6-icmp } accept
        tcp dport { 22, 80, 443 } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Így olvassa. A tábla neve filter, a családja inet: egyetlen tábla egyszerre IPv4-re és IPv6-ra, így az IPv6-ot nem lehet elfelejteni. A input láncban a házirend drop. Ezután: a már létező kapcsolatokra adott válaszok visszajöhetnek (established,related), a loopbacken minden engedélyezett, az ICMP engedélyezett (többek között az IPv6-hoz és a csomagméretre vonatkozó hibaüzenetekhez szükséges), valamint a 22-es, 80-as és 443-as port engedélyezett.

anna@web1:~$ sudo nft -c -f /etc/nftables.conf    # ellenőrzés betöltés nélkül
anna@web1:~$ sudo systemctl enable --now nftables
anna@web1:~$ sudo nft list ruleset

Vagy az ufw-t, vagy egy saját nftables-fájlt használjon, ne mindkettőt: ugyanabba a netfilterbe írnak, és akadályozhatják egymás szabályait.

Mi ellen nem véd a tűzfal?

  • Az Ön által engedélyezett szolgáltatások. A 443-as port nyitva van a webhelye számára, így a webhely egy sérülékenysége is elérhető marad. A tűzfal csak a zárt portokat védi.
  • Docker. Ha a Dockerrel közzétesz egy portot (-p 5432:5432), a Docker saját netfilter-szabályokat állít be, amelyek átirányítják a forgalmat, mielőtt az ufw szabályai érvényesülnének. A Docker dokumentációja szó szerint kimondja, hogy a Docker és az ufw nem működik jól együtt. Egy konténerport tehát kívülről nyitva lehet, miközben a ufw status nem mutatja. A megoldást (közzététel a 127.0.0.1 címen) a 9.3-as leckében ismeri meg.
  • Kimenő forgalom. Az „allow outgoing” beállítással egy feltört program bárhová kapcsolódhat. A legtöbb kis szervernél ez elfogadható döntés; szigorú környezetekben a kimenő forgalmat is korlátozzák.

A szolgáltató tűzfala

Sok szolgáltató a hálózatban, a szerver előtt is kínál tűzfalat, amelyet az ügyfélpanelen állíthat be (néha „cloud firewall” vagy „security group” a neve). Ez kiváló kiegészítő réteg, és akkor is működik, ha magán a szerveren valamit rosszul állít be. A szerveren futó tűzfalat azonban nem helyettesíti: ha a szervert áthelyezi vagy szolgáltatót vált, nem költözik vele, és nem minden szolgáltató kínálja. Ezért mindig legyen tűzfal magán a szerveren is.

AlmaLinuxon és Rocky Linuxon

Ezeken a firewalld alapból be van kapcsolva, zónákkal. A legfontosabb parancsok:

[root@web1 ~]# firewall-cmd --list-all
[root@web1 ~]# firewall-cmd --permanent --add-service=http --add-service=https
[root@web1 ~]# firewall-cmd --reload

--permanent nélkül egy módosítás csak a következő újraindításig érvényes; --permanent használatával pedig csak a --reload után lép életbe. Az alapértelmezett zónában az SSH már nyitva van.

A gyakorlatban

Ha mégis kizárja magát egy WebOké VPS-ről, a VPS-képernyőn nyissa meg a konzolt, jelentkezzen be, és kapcsolja ki a tűzfalat (ufw disable), vagy vonja vissza az utolsó szabályt. Más szolgáltatóknál ezt a vészbejáratot szintén konzolnak, VNC-nek vagy rescue-nak hívják. Tudja, hol van ez a gomb, mielőtt szüksége lenne rá.

Összefoglalás

  • A tűzfal a második réteg a „csak ott figyeljen, ahol szükséges” elv után; az nftables a kernel eszköze, az ufw egy egyszerű réteg fölötte.
  • Kezdje a default deny incoming paranccsal, engedélyezze az SSH-t a ufw enable előtt, teszteljen egy második munkamenettel, és ismerje a szolgáltatója konzolját.
  • Ellenőrizze, hogy az ufw az IPv6-ot is lefedi (IPV6=yes); nftables-ben a inet család ezt egy lépésben elvégzi.
  • A deny kívülről „szűrt”, a reject „zárt” állapotot mutat; a limit fékezi az ismételt kapcsolódásokat.
  • A Docker-portok megkerülik az ufw-t (lecke 9.3); a szolgáltató tűzfala kiegészítő réteg, nem helyettesítő.

Kvíz

1. Milyen sorrendben kapcsolja be először az ufw-t egy olyan szerveren, ahová SSH-n keresztül jelentkezett be?



2. A ufw enable után a webhelye IPv4-en már nem működik, az SSH viszont igen. Mi a legvalószínűbb ok?



3. A Dockerrel közzéteszi egy adatbázis-konténer 5432-es portját. A ufw status nem mutat szabályt az 5432-re. Elérhető kívülről az adatbázis?



4. Miért használ az nftables-példa inet családú táblát?



5. A szolgáltatója hálózati tűzfalat kínál az ügyfélpanelen. Szüksége van ezek után még tűzfalra a szerveren?



Feladat

Feladat O5.2: A tűzfal beállítása. Kapcsoljon be tűzfalat a szerverén az ufw-vel (vagy nftables-szel, illetve AlmaLinuxon/Rockyn firewalld-vel): alapértelmezésként minden beérkező forgalom zárva, az SSH engedélyezve, és ezen felül csak az, amire valóban szüksége van. Teszteljen egy második munkamenettel, ellenőrizze, hogy az IPv6 is le van-e fedve, és kívülről a nc segítségével nézze meg, hogy egy nem engedélyezett port zárt vagy szűrt-e. Töltse ki az ellenőrzőlistát, és illessze be a ufw status verbose (vagy a nft list ruleset) kimenetét; minden nyitott portnál adja meg, mire szolgál.

O5.2. feladat: A tűzfal beállítása

Ezt a feladatot saját maga végzi el, senki nem ellenőrzi. Pipálja ki, amit elvégzett, és jelölje meg a feladatot elvégzettként.



A pipái és jegyzetei csak ebben a böngészőben maradnak meg, sehova nem küldjük el őket. Ha bejelentkezett, a Fiókomban csak azt tároljuk, hogy elvégezte a feladatot.

További olvasnivaló

Egy pillanat…

Domainek beállítása

Állítsa be domainenként a névszervereket, a tárhelyhez való kapcsolást és azt, hogy ki legyen a tulajdonos.

Domainek betöltése…