Portok és figyelő szolgáltatások

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

Tanulási cél: A lecke után Ön látni fogja, mely szolgáltatások figyelnek a szerverén és milyen címen, el tudja magyarázni a különbséget a 0.0.0.0 és a 127.0.0.1 között, és kívülről ellenőrizni tudja, mit lát a szerveréből bárki az interneten.

Kulcsfogalmak: port, TCP és UDP, figyelés (listen), ss -tulpn, 0.0.0.0 és [::], 127.0.0.1 és [::1], bind-address, nyitott, zárt és szűrt, támadási felület, szkennerek

Egy IP-cím 65 535 ajtóval

A szerverének van egy IP-címe, például 192.0.2.10 és 2001:db8::10. Ezen a címen egyszerre több program is elérhető lehet, mindegyik a saját portján: ez egy 1 és 65 535 közötti szám. Az a program, amely kapcsolatokat fogad, egy porton figyel. Néhány ismert példa:

A TCP azoknak a kapcsolatoknak a protokollja, amelyeknek megbízhatóan kell célba érniük (web, SSH, adatbázisok). Az UDP gyors, különálló csomagokra szolgál (DNS, VPN-ek, például a WireGuard, HTTP/3). Egy szolgáltatás figyelhet TCP-n, UDP-n vagy mindkettőn.

Minden figyelő port egy ajtó a szerverére. Minden ajtó mögött szoftver áll, amely hibákat tartalmazhat. A kívülről elérhető ajtók összességét nevezzük támadási felületnek. Minél kisebb, annál jobb: egy weboldalt kiszolgáló szervernek kívülről csak a 22-es, a 80-as és a 443-as portra van szüksége.

Mi figyel? Az ss parancs

A ss (socket statistics) parancs megmutatja, mi figyel a szerverén. A következő kapcsolókkal: -t (TCP), -u (UDP), -l (csak a figyelők), -p (melyik program) és -n (számok, nem nevek):

anna@web1:~$ sudo ss -tulpn
Netid State  Local Address:Port  Peer Address:Port Process
udp   UNCONN 127.0.0.54:53       0.0.0.0:*         users:(("systemd-resolve",pid=402,fd=16))
tcp   LISTEN 0.0.0.0:22          0.0.0.0:*         users:(("sshd",pid=611,fd=3))
tcp   LISTEN 0.0.0.0:80          0.0.0.0:*         users:(("nginx",pid=902,fd=6))
tcp   LISTEN 0.0.0.0:443         0.0.0.0:*         users:(("nginx",pid=902,fd=7))
tcp   LISTEN 127.0.0.1:3306      0.0.0.0:*         users:(("mariadbd",pid=755,fd=21))
tcp   LISTEN 0.0.0.0:6379        0.0.0.0:*         users:(("redis-server",pid=780,fd=6))
tcp   LISTEN [::]:22             [::]:*            users:(("sshd",pid=611,fd=4))
tcp   LISTEN [::]:80             [::]:*            users:(("nginx",pid=902,fd=8))
tcp   LISTEN [::]:443            [::]:*            users:(("nginx",pid=902,fd=9))

A legfontosabb oszlop a Local Address: ez az a cím, amelyen a program figyel.

A fenti példában a MariaDB rendben van: a 127.0.0.1 címen figyel, így csak a szerveren futó programok (például az Ön weboldala) érhetik el. A Redis viszont a 0.0.0.0:6379 címen figyel. Ha a tűzfal nincs jól beállítva, az egész internet hozzáférhet. Pontosan ilyen hibákról szól ez a lecke.

Figyelés a megfelelő címen

Egy adatbázisnak, gyorsítótárnak vagy kezelőfelületnek szinte soha nem szabad kívülről elérhetőnek lennie. Az első és legjobb védekezés az, hogy a szolgáltatás csak a loopback címen figyel. A tűzfal (5.2. lecke) a második réteg; az véletlenül ki lehet kapcsolva, vagy nem minden esetben érvényes (például Docker esetén, 9.3. lecke).

Hogy ezt hol állítja be, az programonként eltér:

A Debian és az Ubuntu csomagjai ezeket a szolgáltatásokat alapértelmezetten már a localhostra állítják. A hiba általában akkor történik, amikor valaki egy olyan útmutatót követ, amely azt mondja: „állítsa a bind-address értékét 0.0.0.0 címre, hogy kívülről csatlakozhasson”. Ha Ön a saját laptopjáról szeretné elérni az adatbázist, használjon SSH-alagutat (2.3. lecke): a port zárva marad, és csak az fér hozzá, aki SSH-n keresztül jön be.

A módosítás után indítsa újra a szolgáltatást, és nézze meg újra a ss -tulpn paranccsal.

Nyitott, zárt és szűrt

Kívülről nézve egy port háromféle állapotban lehet:

• Nyitott (open): valami figyel, és a kapcsolat létrejön.
• Zárt (closed): semmi sem figyel, vagy egy tűzfal aktívan elutasítja a kapcsolatot. A szerver azonnal „nem” választ küld vissza (TCP esetén egy RST-csomagot). A kapcsolat azonnal meghiúsul a „Connection refused” üzenettel (a kapcsolatot elutasították).
• Szűrt (filtered): egy tűzfal csendben eldobja a csomagot. A kapcsolat egy időtúllépésig (time-out) függőben marad.

Az adatbázis szempontjából a zárt és a szűrt állapot egyaránt jó: senki sem fér hozzá. A különbség csak azt mutatja meg, miért: a szűrt állapot szinte mindig azt jelenti, hogy a tűzfala tartja vissza a forgalmat.

Kívülről nézve

A ss megmutatja, mi figyel a szerveren, de azt nem, hogy mi érhető el kívülről. Közöttük ugyanis ott van még egy tűzfal, a szolgáltatónál esetenként egy hálózati tűzfal is. Az egyetlen valódi ellenőrzés ezért ez: nézze meg kívülről, egy másik számítógépről.

A saját számítógépéről (nem magáról a szerverről, mert akkor a loopbacken keresztül menne) ezt egy portra a nc (netcat) segítségével teheti meg:

anna@laptop:~$ nc -vz -w 3 192.0.2.10 6379
nc: connect to 192.0.2.10 port 6379 (tcp) failed: Connection refused
anna@laptop:~$ nc -vz -w 3 192.0.2.10 22
Connection to 192.0.2.10 22 port [tcp/ssh] succeeded!

Windows alatt a PowerShell ugyanezt a Test-NetConnection 192.0.2.10 -Port 6379 paranccsal végzi el. Egy portszkenner, például az nmap, egyszerre több portot is meg tud vizsgálni; ilyen szkennert csak a saját szerverén használjon.

Ne feledkezzen meg az IPv6-ról. Gyakori hiba, hogy a tűzfalban csak IPv4-szabályok vannak, miközben a szolgáltatás a [::] címen is figyel. Ezért az IPv6-címet is tesztelje: nc -6 -vz -w 3 2001:db8::10 6379.

Miért olyan fontos ez?

A szerverét az első perctől kezdve szkennelik. Az internetre kötött eszközöket és szolgáltatásokat kereső keresőmotorok, valamint a bűnözők botjai folyamatosan végigpróbálják az összes IPv4-címet az ismert portokon. Egy jelszó nélküli, nyitott Redis, egy Elasticsearch-fürt vagy egy hozzáférés-szabályozás nélküli MongoDB rövid időn belül megtalálható. A nyitott adatbázisok és nyitott keresőfürtök miatti adatvédelmi incidensek rendszeresen bekerülnek a hírekbe, és szinte mindig pontosan erről a hibáról van szó: egy belső használatra szánt szolgáltatás az összes címen figyelt.

Az SSH portján is egész nap kopogtatnak. Ez normális, és kulcsokkal (2.2. lecke) és a fail2ban segítségével (5.3. lecke) nem jelent problémát.

A tanfolyami ellenőrzés

Az ehhez a leckéhez tartozó feladatban a tanfolyami program kívülről öt rögzített adatbázisportot ellenőriz a szerverén: 3306 (MySQL/MariaDB), 5432 (PostgreSQL), 6379 (Redis), 9200 (Elasticsearch/OpenSearch) és 27017 (MongoDB). A program csak azt próbálja meg, hogy létrejön-e kapcsolat, nem küld adatot, és sehova nem jelentkezik be. Más portokat nem szkennel. Az ellenőrzések a feladatban megadott IP-címről érkeznek, így Ön felismerheti őket a saját naplójában. Egy címet óránként csak néhány alkalommal lehet ellenőrizni.

AlmaLinux és Rocky Linux alatt

A ss ugyanúgy működik. A szolgáltatások fájljai máshol találhatók (például /etc/my.cnf.d/ a MariaDB-hez, /var/lib/pgsql/data/postgresql.conf a PostgreSQL-hez). Emellett a SELinux megakadályozhatja, hogy egy szolgáltatás szokatlan porton figyeljen; ezt ilyenkor a journalctl kimenetében látja (6.2. lecke), és nem a ss kimenetében.

Összefoglalás

• Minden figyelő port egy ajtó; kívülről csak azt hagyja nyitva, amire valóban szükség van (általában a 22-es, a 80-as és a 443-as portot).
• A sudo ss -tulpn megmutatja, melyik program melyik címen és melyik porton figyel.
• A 0.0.0.0 és a [::] jelentése „minden cím”, a 127.0.0.1 és a [::1] jelentése „csak maga a szerver”. Az adatbázisok, gyorsítótárak és keresőfürtök helye a loopback.
• Egy adatbázisnál a zárt és a szűrt állapot egyaránt jó; a nyitott állapot hiba.
• Mindig kívülről ellenőrizzen, IPv4-en és IPv6-on is, mert a ss nem látja a tűzfalat.

Kvíz

Feladat

Z5.1. feladat: Az adatbázisportok kívülről zárva. Futtassa a sudo ss -tulpn parancsot a szerverén, és derítse ki, milyen címeken figyelnek a szolgáltatásai. Ezután ellenőriztesse a tanfolyami programmal kívülről, hogy a szervere 3306-os, 5432-es, 6379-es, 9200-as és 27017-es portja nem érhető el, IPv4-en és (ha a szerverének van AAAA rekordja) IPv6-on is. Adja meg azt is, mely szolgáltatásai figyelnek a 0.0.0.0 vagy a [::] címen. A program csak kapcsolatot létesít erre az öt portra, és nem küld semmit.

További olvasnivaló

• A VPS biztonságossá tétele: az első öt perc
• A ss(8) kézikönyve: https://manpages.debian.org/trixie/iproute2/ss.8.en.html
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/