Egy szerveren minden hálózati szolgáltatás egy porton fogad kapcsolatot: az SSH a 22-esen, a webszerver a 80-ason és a 443-ason, a MariaDB a 3306-oson. Hogy éppen mely portok vannak nyitva, és melyik program foglalja őket, az ss paranccsal tudhatod meg. Ez a cikk azt is bemutatja, miért nem elég, hogy egy port a szerveren figyel: kívülről csak akkor érhető el, ha a tűzfal is átengedi.

A parancsokat 2026 novemberében AlmaLinux 10.2 rendszeren próbáltuk ki, amelyen nginx, MariaDB, Valkey, egy Node.js-alkalmazás és Docker 29.9 futott, valamint Ubuntu 26.04 rendszeren nginx-szel. Egy saját KVM VPS-en érdemes időnként végignézni a listát: minden fölöslegesen nyitott port egy újabb támadási felület.

Figyelő portok: ss -tulpn

Az ss az iproute (Ubuntun és Debianon iproute2) csomag része, minden mai disztribúción telepítve van.

sudo ss -tulpn

A kapcsolók:

• -t: TCP;
• -u: UDP;
• -l: csak a figyelő (listening) socketek, a kiépült kapcsolatok nélkül;
• -p: a portot foglaló program neve és PID-je (process);
• -n: számokat ír ki, nem szolgáltatásneveket (:22, nem :ssh).

A -p csak sudo-val mutatja a más felhasználók (például a root vagy a mysql) programjait; nélküle a Process oszlop üres marad. Ha csak a portokra vagy kíváncsi, az ss -tuln sudo nélkül is elég, és keskeny ablakban is kifér:

A teszten a sudo ss -tulpn kimenete (rövidítve):

Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp   UNCONN 0      0          127.0.0.1:323       0.0.0.0:*    users:(("chronyd",pid=642,fd=4))
tcp   LISTEN 0      80           0.0.0.0:3306      0.0.0.0:*    users:(("mariadbd",pid=839,fd=20))
tcp   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1217,fd=6),...)
tcp   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1188,fd=7))
tcp   LISTEN 0      511        127.0.0.1:6379      0.0.0.0:*    users:(("valkey-server",pid=1190,fd=8))
tcp   LISTEN 0      511             [::]:80           [::]:*    users:(("nginx",pid=1217,fd=7),...)

A kimenet oszlopai

Oszlop	Jelentése
Netid	protokoll: tcp vagy udp
State	TCP-nél LISTEN (figyel); az UDP-nek nincs kapcsolata, ezért ott UNCONN áll
Recv-Q, Send-Q	figyelő socketnél a várakozó kapcsolatok száma, illetve a várólista mérete; a hétköznapi használatban nem fontos
Local Address:Port	a cím és a port, amelyen a program figyel
Peer Address:Port	figyelő socketnél * (bárhonnan várhat kapcsolatot)
Process	a program neve, PID-je és a socket fájlleírója (fd); csak a -p kapcsolóval

Mit jelent a cím a port előtt?

A Local Address mutatja meg, honnan érhető el a szolgáltatás:

Cím	Jelentése
0.0.0.0:80	minden IPv4 címen figyel, kívülről is elérhető (ha a tűzfal engedi)
[::]:80	minden IPv6 címen figyel
*:3000	minden IPv4 és IPv6 címen, egyetlen sockettel (a teszten így jelent meg egy Node.js-alkalmazás)
127.0.0.1:6379, [::1]:6379	csak a szerveren belülről érhető el (localhost)
127.0.0.53%lo:53	csak a loopback interfészen; Ubuntun így figyel a systemd-resolved helyi DNS-feloldója
10.0.2.15:68	csak ezen az egy IP-címen

A teszten a Valkey alapból csak a 127.0.0.1 címen figyelt, kívülről tehát akkor sem érhető el, ha a tűzfal nyitva van. A MariaDB viszont az AlmaLinux 10 csomagjával alapból a 0.0.0.0:3306 címen figyelt: ha az adatbázist csak a szerveren futó weboldal használja, a /etc/my.cnf.d/mariadb-server.cnf fájl [mysqld] szakaszában a bind-address=127.0.0.1 sorral és a szolgáltatás újraindításával korlátozhatod a helyi elérésre (a teszten ezután az ss már csak a 127.0.0.1:3306 címet mutatta). A MariaDB telepítését külön cikk írja le.

Szűrés egy portra

sudo ss -tlnp 'sport = :80'
sudo ss -tlnp | grep ':3306 '

A sport (source port) a helyi portot jelenti. A grep-nél a port utáni szóköz miatt a :3306 nem illeszkedik például a :33060 portra.

Kiépült kapcsolatok

A -l nélkül, állapotra szűrve az éppen élő kapcsolatokat látod, például hogy kik csatlakoznak SSH-n:

sudo ss -tnp state established

Az ss -s összesítést ad a socketek számáról protokollonként; sok timewait vagy estab kapcsolat egy terhelt webszerveren normális, egy csendes szerveren viszont gyanús lehet.

Melyik program foglalja a portot? lsof és fuser

Az lsof a megnyitott fájlokat listázza, és Linuxon a hálózati socket is fájlnak számít:

sudo lsof -nP -i :80
sudo lsof -nP -i -sTCP:LISTEN

COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mariadbd  839  mysql  20u  IPv4   9075      0t0  TCP *:3306 (LISTEN)
mariadbd  839  mysql  21u  IPv6   9076      0t0  TCP *:3306 (LISTEN)

Az -n a címeket, a -P a portokat hagyja számként (nélküle *:http jelenik meg). Az AlmaLinux 10 cloud image-én az lsof nem volt telepítve (sudo dnf install lsof), az Ubuntu 26.04-en igen.

A fuser (a psmisc csomagból, mindkét rendszeren telepítve volt) csak a PID-eket adja:

sudo fuser -v 80/tcp

A fuser -k 80/tcp le is lövi a portot foglaló programokat. Szolgáltatásnál ehelyett állítsd le a szolgáltatást (lásd lent), mert a systemd a lelőtt szolgáltatást a beállításától függően újraindíthatja.

netstat: a régi parancs

A netstat a net-tools csomag része, amely sem az AlmaLinux 10, sem az Ubuntu 26.04 cloud image-én nem volt telepítve. Ha megszoktad, telepítheted (sudo dnf install net-tools vagy sudo apt install net-tools), és ugyanazokkal a kapcsolókkal használhatod:

sudo netstat -tulpn

A kimenete hasonló, az IPv6 címeket :::80 formában írja. sudo nélkül a PID/Program name oszlopban csak - áll. Az új szkriptekben az ss ajánlott, mert az mindenhol telepítve van.

A portot foglaló szolgáltatás leállítása

Az ss -tulpn a program nevét és PID-jét mutatja. Hogy melyik systemd szolgáltatás indította, azt a ps vagy a systemctl status mondja meg:

ps -p 1217 -o pid,comm,unit
systemctl status 1217

Ezután leállíthatod, és kikapcsolhatod az automatikus indítását:

sudo systemctl disable --now nginx

A szolgáltatások kezelését a systemctl parancsot bemutató cikk írja le részletesen.

Az Ubuntu 26.04-en a 22-es portnál az sshd mellett a systemd (PID 1) is megjelenik: ott az SSH-t socket aktiválás indítja (ssh.socket), a portot a systemd is nyitva tartja. Az SSH beállításairól, köztük a port áthelyezéséről, az SSH szerver biztonságos beállításáról szóló cikk szól.

Address already in use: foglalt port

Ha egy program olyan portot próbál megnyitni, amelyet már egy másik foglal, nem indul el. A teszten az nginx így nem indult, mert a 80-as porton egy másik program figyelt:

$ sudo journalctl -u nginx | grep bind
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Más programok ugyanezt saját szavaikkal írják (Pythonban például OSError: [Errno 98] Address already in use). A teendő:

1. Nézd meg, ki foglalja a portot: sudo ss -tlnp 'sport = :80' vagy sudo lsof -nP -i :80.
2. Ha egy régi vagy fölösleges szolgáltatás, állítsd le (sudo systemctl disable --now apache2). Gyakori eset, hogy az Apache és az nginx egyszerre próbál a 80-as porton indulni, vagy egy Docker-konténer foglalja a portot.
3. Ha mindkettőre szükség van, az egyiket állítsd át másik portra.

Figyel, de nem érhető el? A tűzfal

Az ss csak azt mutatja meg, hogy a program fogadna kapcsolatot. Hogy kívülről valóban elérhető-e, azt a tűzfal dönti el. A teszten az nginx a 0.0.0.0:80 címen figyelt, kívülről mégsem válaszolt, amíg a firewalld nem engedte a http szolgáltatást; utána azonnal elérhető lett.

A tűzfal szabályainak ellenőrzése:

# AlmaLinux, Rocky Linux (firewalld)
sudo firewall-cmd --list-all

# Ubuntu, Debian (ufw)
sudo ufw status verbose

Az AlmaLinux 10 cloud image-én a firewalld nem volt telepítve, az Ubuntu 26.04-en az ufw telepítve volt, de kikapcsolva (Status: inactive). Hogy a szervereden milyen alapbeállítás van, azt mindig ellenőrizd. A tűzfal beállítását a Hogyan állítsak be tűzfalat a VPS-emen? cikk mutatja be.

A Docker megkerüli a tűzfalat

A Docker a konténerek közzétett portjait (-p 8081:80) saját szabályokkal nyitja meg. A teszten egy -p 8081:80 kapcsolóval indított nginx-konténer kívülről elérhető volt, pedig a firewalld public zónája csak az SSH-t engedte; ugyanekkor a gépen közvetlenül futó nginx a 80-as porton nem volt elérhető. Az ss kimenetében az ilyen portot a docker-proxy program foglalja.

Ha egy konténert csak helyben (például egy reverse proxy mögött) szeretnél elérni, kösd a helyi címre:

docker run -d -p 127.0.0.1:8082:80 nginx:alpine

Ekkor az ss a 127.0.0.1:8082 címet mutatja. A Docker telepítését és alapjait a Docker telepítéséről szóló cikk írja le.

Ellenőrzés kívülről: nc és nmap

Hogy a port valóban elérhető-e, azt egy másik gépről (például a saját számítógépedről) ellenőrizd. A szerveren belülről végzett próba a tűzfalat nem teszteli.

nc -zv 203.0.113.10 80
nc -zv -w 3 203.0.113.10 3306

Az Ubuntu nc parancsa (netcat-openbsd) sikeres kapcsolatnál Connection to ... 443 port [tcp/https] succeeded! üzenetet ír, zárt portnál Connection refused, a tűzfal által eldobott csomagoknál pedig a -w 3 másodperc után timed out hibát. AlmaLinuxon az nc a nmap-ncat csomagban van, és Ncat: Connected to ... vagy Ncat: Connection refused. üzenetet ad.

Több portot egyszerre az nmap vizsgál:

nmap -Pn -p 22,80,443,3306 203.0.113.10

PORT     STATE    SERVICE
443/tcp  open     https
3306/tcp filtered mysql

• open: a port elérhető, egy program fogadja a kapcsolatot;
• closed: a gép válaszol, de a porton nem figyel semmi;
• filtered: nem jött válasz, a csomagokat valószínűleg tűzfal dobja el.

Csak a saját szerveredet vizsgáld így: mások gépeinek portszkennelése engedély nélkül visszaélésnek számíthat. További hálózati hibakeresési eszközöket (ping, traceroute, curl) a hálózati hibakeresésről szóló cikk mutat be.

Összefoglalás

Feladat	Parancs
Figyelő portok programokkal	sudo ss -tulpn
Figyelő portok sudo nélkül	ss -tuln
Egy port vizsgálata	sudo ss -tlnp 'sport = :80'
Ki foglalja a portot?	sudo lsof -nP -i :80
Élő kapcsolatok	sudo ss -tnp state established
Régi forma	sudo netstat -tulpn (net-tools)
Melyik szolgáltatás?	systemctl status PID
Tűzfal szabályai	sudo firewall-cmd --list-all vagy sudo ufw status verbose
Elérhető-e kívülről?	nc -zv IP PORT vagy nmap -Pn -p PORT IP (másik gépről)