Language: hu

VPS-biztonság az alapoktól: SSH-kulcsok, tűzfal és Fail2ban

Egy új VPS nem tekinthető azonnal biztonságosnak az Ubuntu telepítése után. Mielőtt beállítanád a hozzáférést, a szerver már látható a szkennerek számára: SSH-jelszavakat próbálnak ki, nyitott vezérlőpaneleket keresnek, és gyakori sérülékenységeket ellenőriznek. Ebben az útmutatóban bemutatjuk, hogyan biztosítsd a VPS-t az alapoktól: hozz létre külön felhasználót, állítsd be az SSH-kulcsos hitelesítést, korlátozd a hálózati portokat UFW-vel, és adj hozzá Fail2bant. Minden lépés működik Ubuntu 22.04 és 24.04 alatt, ha a parancsokat sudo jogosultsággal rendelkező felhasználó futtatja.

Mielőtt elkezded: készíts listát a portokról

Ne nyiss meg portokat „biztos, ami biztos” alapon. Egy tipikus webszervernek ezekre van szüksége:

• 22/tcp — SSH; lehetőleg korlátozd IP-címre, vagy csak kiegészítő intézkedésként helyezd át másik portra;
• 80/tcp — HTTP; általában szükséges HTTPS-re irányításhoz és tanúsítvány-ellenőrzéshez;
• 443/tcp — HTTPS.

Egy olyan alkalmazásportnak, mint a 3000, 8080 vagy 9000, nem szabad elérhetőnek lennie az internetről, ha előtte Nginx vagy Caddy fut. Kösd az alkalmazást a 127.0.0.1 címhez, vagy csak a belső hálózaton engedélyezd a portját. Először nézd meg, mi figyel a szerveren:

sudo ss -tulpn

Docker telepítése után külön ellenőrizd az iptables szabályait is: a -p 3000:3000 közzététele a vártnál szélesebben tehet elérhetővé egy portot. Nyilvános szolgáltatásnál biztonságosabb HTTPS-proxyt használni, és rejtve tartani a belső portot.

1. lépés: A rendszer frissítése és adminisztrátor létrehozása

Csatlakozz a VPS-hez a kapott adatokkal, és telepítsd a frissítéseket:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Hozz létre személyes felhasználót. Az alex helyett a saját nevedet használd:

sudo adduser alex
sudo usermod -aG sudo alex

Ne távolítsd el az eredeti hozzáférést, amíg külön terminálablakban nem tesztelted az új fiókot. Ez fontos szabály: egy SSH-hiba könnyebben javítható, amíg a jelenlegi munkamenet még nyitva van.

2. lépés: SSH-kulcs létrehozása és telepítése a szerveren

Linux-, macOS- vagy Windows PowerShellt futtató számítógépeden futtasd:

ssh-keygen -t ed25519 -C "alex@my-computer"

Nyomj Entert, hogy a kulcs az alapértelmezett fájlba kerüljön, majd adj meg egy jelmondatot. A privát kulcsot soha ne küldd el csevegésben, ne tedd repozitóriumba, és ne másold a VPS-re. Csak a .pub kiterjesztésű fájlt kell átmásolni a szerverre:

ssh-copy-id alex@SERVER_IP

Ha az ssh-copy-id nem érhető el, PowerShellben jelenítsd meg a nyilvános kulcsot a Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub paranccsal, majd add hozzá a szerveren:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Illeszd be a kulcsot egyetlen sorba, és a jelszavak letiltása előtt teszteld a bejelentkezést:

ssh alex@SERVER_IP
sudo whoami

Az utolsó parancs várt eredménye root. Ha az SSH-kliens nem találja a kulcsot, add meg kifejezetten: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP.

3. lépés: Root-bejelentkezés és jelszavas hitelesítés letiltása

Készíts biztonsági másolatot az SSH-konfigurációról:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Győződj meg róla, hogy a fájl tartalmazza ezeket a paramétereket:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

Ubuntu alatt a beállítások az /etc/ssh/sshd_config.d/*.conf fájlokban is lehetnek, ezért ellenőrizd az érvényes konfigurációt:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Ha az sshd -t hibát jelez, ne indítsd újra a szolgáltatást a szintaxis javítása előtt. A sikeres ellenőrzés után alkalmazd a beállításokat:

sudo systemctl reload ssh

Tartsd nyitva a régi SSH-kapcsolatot, és egy új ablakban teszteld a kulcsos bejelentkezést. A kulcs ellenőrzése nélküli jelszóletiltás a szerverhez való hozzáférés elvesztésének leggyakoribb oka.

4. lépés: UFW beállítása az SSH blokkolása nélkül

Az UFW kényelmes burkolóréteg a Linux hálózati szabályaihoz. Először állíts be biztonságos alapértékeket, majd engedélyezd az SSH- és webportokat:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Csak az SSH-szabály hozzáadása után erősítsd meg az aktiválást. Tekintsd át az eredményt:

sudo ufw status verbose
sudo ufw status numbered

Állandó irodai IP-cím esetén az SSH-t arra a címre korlátozhatod:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

Ezt csak állandó IP-címmel és a szolgáltatói konzol elérésével használd: ha a cím megváltozik, kizárhatod magad.

Alkalmazásport ideiglenes megnyitása

Ha közvetlenül kell ellenőrizned egy szolgáltatást, korlátozott forrással hozz létre szabályt:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Tesztelés után töröld a ufw status numbered által mutatott számmal:

sudo ufw delete RULE_NUMBER

Ne használd a sudo ufw allow 1:65535/tcp parancsot: egy ilyen szabály puszta formalitássá változtatja a tűzfalat.

5. lépés: Fail2ban engedélyezése SSH-hoz

A Fail2ban elemzi a naplókat, és több sikertelen bejelentkezési kísérlet után ideiglenes tiltószabályt ad hozzá. Nem helyettesíti az SSH-kulcsokat vagy a tűzfalat, de csökkenti az automatizált brute-force próbálkozások zaját.

Hozz létre helyi konfigurációt, hogy a csomagfrissítések ne írják felül a beállításaidat:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Állíts be ésszerű értékeket a [DEFAULT] szakaszban:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Indítsd el a szolgáltatást, és ellenőrizd a jailt:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Az sshd kimenetében nézd meg a sikertelen próbálkozások és a tiltott címek számát. Ne add hozzá a saját IP-címedet a tiltólistához. Állandó kivételhez használd az ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP beállítást a [DEFAULT] szakaszban.

6. lépés: Automatikus frissítések engedélyezése

Az automatikus frissítések hasznosak a biztonsági csomagokhoz, de a kernel újraindítását továbbra is kezelni kell:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Hetente egyszer ellenőrizd, hogy szükséges-e újraindítás:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Kézi újraindítás előtt győződj meg róla, hogy működő kulcsod és hozzáférésed van a VPS-konzolhoz. Újraindítás után ellenőrizd az alkalmazásszolgáltatásokat, az Nginxet, az UFW-t és a Fail2bant.

7. lépés: Az eredmény ellenőrzése kívülről

Az ellenőrzést másik számítógépről végezd, ne csak a konfiguráció elolvasásával:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

A parancsnak megtagadással kell befejeződnie. A működő kulcsos bejelentkezést külön teszteld:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

A VPS-en ellenőrizd a figyelő címeket és a szabályokat:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

Az alkalmazásportnak a 127.0.0.1 címen kell figyelnie, ha nem szántad közvetlen elérésre. Külső gépről használhatod a nmap SERVER_IP parancsot, de csak a saját szerveredet vizsgáld: más infrastruktúrájának engedély nélküli ellenőrzése sértheti a jogszabályokat és a szolgáltató szabályait.

Biztonsági mentések és helyreállítás

Az SSH-védelem nem véd a törölt adatok, egy adminisztrátori hiba vagy egy feltört alkalmazás ellen. Az adatbázis, a konfiguráció és a felhasználói fájlok másolatait a VPS-től elkülönítve tárold. A minimális beállítás napi mentésből, az előző napok több verziójából és rendszeres helyreállítási tesztekből áll.

Ne írj jelszavakat vagy tokeneket egyszerű szöveges szkriptekbe. Ha egy titok kiszivárog, azonnal vond vissza, és hozz létre újat.

VPS választása biztonságos projekthez

A biztonság az infrastruktúra feletti kontrollal kezdődik. VPS-en te választhatod meg az operációs rendszert, a tűzfalszabályokat, a hozzáférési módot, a mentéseket és a szolgáltatások elhelyezését. Egy kisebb webhelyhez vagy API-hoz a stabil hálózat, az SSD-tárhely és a helyreállítási konzol fontosabb, mint a túl sok virtuális mag.

Amikor projektet indítasz a tropic.host VPS-én, előre határozd meg a nyilvános belépési pontokat: a legtöbb esetben az SSH, a HTTP és a HTTPS elegendő. Az adatbázist és a vezérlőpaneleket tartsd a belső hálózaton. A projekt növekedésével külön VPS-ek az alkalmazás, az adatbázis és a megfigyelés számára segítenek elkülöníteni a hibaterületeket.

Gyakori hibák

• A jelszavak letiltása a kulcsos bejelentkezés tesztelése előtt. Tartsd nyitva a jelenlegi munkamenetet, és az új bejelentkezést külön teszteld.
• A 22/tcp port nyitva hagyása az egész világ előtt, amikor csak megbízható címekről lenne elérhető.
• Docker-portok közvetlen közzététele. Először ellenőrizd a Docker- és UFW-szabályokat.
• A Fail2ban telepítése, majd a naplók újbóli ellenőrzésének elhagyása. Módosítások után nézd át a journalctl -u ssh kimenetét és a jail állapotát.

Összegzés

Az alapvető VPS-védelem nem igényel sok időt, ha a lépéseket helyes sorrendben hajtod végre: hozz létre külön felhasználót, telepíts SSH-kulcsot, ellenőrizd a hozzáférést, tiltsd le a root-bejelentkezést és a jelszavakat, engedélyezd az UFW-t, állítsd be a Fail2bant, majd kapcsold be az automatikus frissítéseket. Ezután adj hozzá mentéseket, naplózást és külső megfigyelést.

Ezek a lépések nem teszik sebezhetetlenné a szervert, de megszüntetik a kezdeti konfiguráció leggyakoribb hibáit. A következő lépés a biztonsági profil hozzáigazítása az adott alkalmazáshoz: frissítsd a függőségeket, korlátozd a szolgáltatások jogosultságait, védd az adminisztrációs paneleket, és rendszeresen ellenőrizd a nyitott portokat.

FAQ

Meg kell változtatnom az alapértelmezett SSH-portot?

Nem feltétlenül. A port áthelyezése csökkenti az automatizált zajt, de nem helyettesíti a kulcsokat, a jelszavak letiltását, az UFW-t vagy a Fail2bant. Ha megváltoztatod a portot, frissítsd a tűzfalszabályt és a Fail2ban jail port paraméterét.

Mit tegyek, ha az UFW beállítása után elveszítem a hozzáférést?

Használd a szolgáltató webes vagy helyreállítási konzolját, majd ellenőrizd az SSH-szabályt és az sshd konfigurációját. Ne zárd be a régi működő munkamenetet, amíg az új bejelentkezést nem erősítetted meg.

Elég a Fail2ban az SSH védelméhez?

Nem. A Fail2ban a már megtörtént sikertelen bejelentkezésekre reagál. Az alapot az SSH-kulcsok, a jelszavas hitelesítés letiltása, a minimális felhasználói jogosultságok és a korlátozott tűzfal adják.

Engedélyezhetem az SSH-t csak egy IP-címről?

Igen, ha a cím állandó: adj hozzá UFW allow from szabályt az IP-hez. Előre gondoskodj szolgáltatói konzolról vagy más tartalék hozzáférésről, mert címváltozás után a kapcsolat blokkolva lesz.

Milyen gyakran ellenőrizzem a VPS biztonságát?

Minden SSH-, tűzfal- vagy Docker-portmódosítás után futtass portellenőrzést és teszteld a bejelentkezést. Rendszeres karbantartásként legalább hetente nézd át a frissítéseket és a naplókat, a mentések helyreállítását pedig rendszeresen teszteld.