Szerver tűzfal beállítása: védelem DDoS és rosszindulatú botok ellen Magyarországon

A szerver tűzfal beállítása azt jelenti, hogy csak a szükséges portokat hagyjuk nyitva, minden egyéb hozzáférést pedig blokkolunk. Ez az első védelmi vonal a DDoS támadások, brute force próbálkozások és káros botforgalom ellen. A cél a gyakorlatban az SSH hozzáférés korlátozása, a webszolgáltatások kontrollált megnyitása, gyanús kérelmek sebességkorlátozása, naplózás figyelése, és ha lehet, CDN vagy WAF használatával a forgalom kiszűrése még mielőtt elérné a szervert.

Amint egy web szervert az internetre nyitunk, perceken belül portszkennelések, SSH próbálkozások, sebezhetőséget kereső botok és álkliens azonosítók érkeznek. Különösen WordPress, webáruház, adminisztrációs panel, API vagy játék szerver esetén a tűzfal nem csupán technikai választás, hanem az üzemmenet alapfeltétele. Ebben az útmutatóban egy Linux szerverre lépésről lépésre építünk biztonsági tűzfal felépítést; érintjük az UFW, firewalld, nftables, Fail2ban, webalkalmazás tűzfal és DDoS védelem együttes használatát.

Egy fontos tény: a helyi szerver tűzfal önmagában nem fogja megállítani a nagy volumenű DDoS támadásokat. Ha a támadás eléri a 20 Gbps, 80 Gbps vagy még nagyobb sávszélességet, akkor a csomagok az operációs rendszer szabályai előtt eláraszthatják a hálózatot vagy az adatközpontot. Ezért a helyes stratégia a többrétegű védelem: szolgáltatói szintű DDoS védelem, CDN/WAF, operációs rendszer tűzfal, alkalmazás szintű sebességkorlátozás és rendszeres naplóelemzés együttese. Infrastruktúra választáshoz ajánljuk a Hostragons VPS és VDS szerver megoldások, weboldal biztonságos üzemeltetéséhez pedig a Hostragons web hosting csomagok oldalakat.

Mi a szerver tűzfal szerepe?

A szerver tűzfal egy olyan biztonsági réteg, amely a hálózati forgalmat a forrás IP, cél IP, port, protokoll, kapcsolat állapota és bizonyos esetekben csomag tulajdonságai alapján szűri. Egyszerű példával: a weboldalnak a 80-as és 443-as portnak nyitva kell lennie, de az adatbázis portja, például a 3306, nem lehet elérhető az internetről. Az SSH-hoz tartozó 22-es portot sem célszerű bárkinek megnyitni, sokkal biztonságosabb, ha csak az irodai IP-címekről engedjük a hozzáférést.

A tűzfal elsődleges célja nem az, hogy minden támadást varázsütésre megállítson. Inkább az, hogy csökkentse a támadási felületet. Minél kisebb a támadási felület, annál kevesebb lehetőség marad a támadónak. Egy újonnan telepített Linux szerveren például egyszerre nyitva lehet az SSH, webes admin panel, levelezőszolgáltatás, adatbázis, monitorozó ügynök és teszt szolgáltatások – mindegyik külön kockázatot jelent. Egy jól konfigurált tűzfal az „alapértelmezett elutasítás, csak szükséges engedélyezése” elvén működik.

DDoS és botforgalom megértése

Miért különlegesek a DDoS támadások?

A DDoS, azaz elosztott szolgáltatásmegtagadásos támadás, több forrásból érkező nagy mennyiségű forgalommal teszi elérhetetlenné a célzott szolgáltatást. A támadás vagy a sávszélességet telíti, vagy a szerver CPU és memória erőforrásait fogyasztja el, vagy pedig az alkalmazás rétegén drága műveleteket vált ki. Például egy másodpercenként 50 000 HTTP kérés érkező kis alkalmazás szerver akkor is lelassulhat vagy válaszképtelenné válhat, ha a hálózat nem telítődik, mert a PHP-FPM, Node.js vagy az adatbázis kapcsolat medence korlátai miatt nem bírja a terhelést.

Mindig rosszak a botok?

Nem. A Googlebot, Bingbot és bizonyos elemző botok hasznosak. Viszont a rosszindulatú botok végigpásztázzák az admin panelek sebezhetőségeit, keresik a nyilvános mappákat, spammelik a formokat, lopják a tartalmat, visszaélnek az XML-RPC-vel, hamis regisztrációkat és bejelentkezési próbálkozásokat indítanak. Emiatt a botkezelés célja nem az összes bot kizárása, hanem a viselkedés alapú szűrés. Fontos jelek a magas hibaarány, nagyon rövid idő alatt sok kérés, a valódi böngészőt nem imitáló fejléc és gyanús URL-mintázatok.

Előkészületek a telepítés előtt

Éles szerveren tűzfal szabályokat írva a legnagyobb veszély, hogy véletlenül kizárjuk magunkat a szerverből. Ezért minden változtatás előtt érdemes egy rövid ellenőrző listát követni. Az alábbi lista a termelési környezetekben bevált, biztonságos kezdő lépéseket tartalmazza.

• Ne zárja be az aktív SSH munkamenetet, teszteljen egy másik terminálról is.
• Győződjön meg arról, hogy a szolgáltató biztosít konzol, VNC vagy mentési hozzáférést.
• Listázza a nyitott portokat: ss -tulpn vagy netstat -tulpn parancsokkal.
• Jegyezze fel a web, mail, DNS, adatbázis, admin panel és monitorozó szolgáltatások portjait.
• Ha IPv6-ot használ, tervezze meg a hozzá tartozó tűzfal szabályokat is.
• Először az engedélyező (allow) szabályokat állítsa be, utána a tiltó (deny) szabályokat.
• Gondoskodjon róla, hogy a szabályok tartósak legyenek, és újraindítás után se vesszenek el.

Például egy alap weboldalt futtató szervernél általában csak a 80-as, 443-as és egy korlátozott SSH portot kell nyitva hagyni. Ha nincs levelező szerver, akkor a 25, 465, 587, 993 portokat nem kell engedélyezni. Ha az adatbázis csak a szerveren belül használatos, akkor a 3306 vagy 5432 portokat kívülről zárni kell.

Melyik tűzfal eszközt válasszuk?

Linux alatt többféle eszköz áll rendelkezésre, amelyek ugyanazt az alaprendszerű hálózati szűrést kezelik, de eltérő kezelőfelülettel. Kezdőknek az UFW a legegyszerűbb és gyors. Nagyvállalati vagy Red Hat alapú rendszereken a firewalld az elterjedt. Haladóbb esetekben az nftables modern, rugalmas megoldást kínál. Az alábbi táblázat segít a választásban.

Lépésről lépésre szerver tűzfal beállítás

1. Nyitott portok és szolgáltatások feltérképezése

Az első lépés, hogy lássuk, mi van nyitva. Linuxon az ss -tulpn parancs megmutatja, mely szolgáltatások mely portokon figyelnek. Például ha az nginx 0.0.0.0:80 és 0.0.0.0:443 címen hallgat, akkor a webforgalmat minden interfészről fogadja. Ha MariaDB 0.0.0.0:3306 címen figyel, az általában kockázatos; az adatbázisnak jellemzően csak 127.0.0.1-en kell futnia.

Az egyszerű szabály: ami nem kell elérhetőnek lennie kívülről, az ne hallgasson 0.0.0.0 címen. Előbb a szolgáltatás konfigurációját érdemes javítani, majd a tűzfalon keresztül zárni. Mert ha a tűzfal ki is kapcsol, a szolgáltatás akkor se legyen nyitott az internetre.

2. Alapértelmezett szabályok lezárása

Biztonságos szabályrendszerben az alapértelmezett bejövő forgalmat elutasítjuk, a kimenőt pedig szükség szerint engedélyezzük. Ez megakadályozza, hogy véletlenül nyitva hagyjuk a nem kívánt szolgáltatásokat. UFW esetén az Ubuntu szerveren a logika: először engedélyezze az SSH-t, majd a 80 és 443 portokat, ezután állítsa be az alapértelmezett bejövő forgalom tiltását, végül aktiválja a tűzfalat.

Példa: engedélyezze az SSH-t a rendszergazda IP-címére, nyissa meg a HTTP és HTTPS portokat, zárja be a felesleges portokat, majd aktiválja a tűzfalat. Ha előbb aktiválja a tűzfalat SSH engedély nélkül, az távoli szerverek esetén gyakori hiba, ami hozzáférés elvesztéséhez vezet.

3. SSH hozzáférés korlátozása

Az SSH a leggyakoribb célpont a támadók számára. Egy 22-es porton elérhető szerver naponta több száz vagy ezer sikertelen bejelentkezési próbát tapasztalhat. A legbiztonságosabb megoldás az SSH hozzáférés korlátozása meghatározott IP-címekre. Ha fix IP-címe van, csak az irodai vagy VPN IP-címeket engedélyezze. Fix IP hiányában legalább kulcs alapú hitelesítést alkalmazzon, és zárja le a jelszavas bejelentkezést.

• Tiltsa le a root felhasználó közvetlen SSH belépését.
• Használjon SSH kulcsokat jelszó helyett.
• Használja az AllowUsers vagy AllowGroups direktívákat a felhasználók korlátozására.
• Fail2ban segítségével automatikusan blokkolja az ismétlődő sikertelen próbálkozásokat.
• Ha van admin panel, annak portját is korlátozza IP címen.

A port módosítása önmagában nem nyújt erős védelmet, de csökkenti az automatikus botok zaját. A valódi biztonság IP korlátozás, erős hitelesítés és naplófigyelés kombinációjával érhető el.

4. Web portok kontrollált megnyitása

A legtöbb weboldal számára a 80-as (HTTP) és 443-as (HTTPS) portok szükségesek. Manapság a 443-as portnak kell lennie az elsődleges forgalmi kapunak, míg a 80-as portot csak a HTTPS átirányítására használjuk. Az SSL tanúsítvány nélküli oldalak gyengítik a felhasználói bizalmat és a keresőoptimalizálást is. Itt a Hostragons SSL tanúsítványok oldal természetes belső linkként segíti az olvasót a biztonságos HTTPS beállítás felé.

Web portok nyitásánál ügyeljen a valós IP-k kezelésére. Ha CDN-t vagy visszafelé proxy-t használ, akkor a szerver 80 és 443 portját ne tegye nyitottá az egész internet előtt, hanem csak a CDN IP tartományokból engedélyezze a forgalmat. Így ha támadó ismeri a szerver valódi IP címét, nem tud közvetlenül a webszolgáltatáshoz hozzáférni.

5. Adatbázis és belső szolgáltatások lezárása az internetről

A MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB és hasonló szolgáltatások internetes elérése súlyos kockázatot jelent. Redis esetén például az azonosítás hiánya, Elasticsearchnél az illetéktelen indexelés, MongoDB-nél az admin port nyitottsága már számos adatvédelmi incidens forrása volt. Ezeket a szolgáltatásokat mindig lehetőség szerint csak localhoston vagy zárt hálózaton keresztül engedélyezze.

Például egy WordPress weboldal esetén az adatbázisnak 127.0.0.1-en kell futnia. Ha külön alkalmazás- és adatbázis-szerver van, akkor csak az alkalmazás szerver privát IP-címét engedélyezze. Soha ne hagyja nyitva a 3306 vagy 5432 portokat az internet felé, mert ezeket a botok folyamatosan szkennelik.

6. Fail2ban a brute force támadások ellen

A Fail2ban a naplófájlokat figyelve azonosítja az ismétlődő sikertelen belépési kísérleteket, és ideiglenesen blokkolja az adott IP-címet. SSH, nginx, Apache, Postfix, Dovecot, WordPress bejelentkezés és egyes admin panelek esetén is konfigurálható. Például ha egy IP 10 perc alatt 5 sikertelen SSH próbálkozást tesz, az 1 órára blokkolható – ez egyszerű, de hatékony megoldás.

Fail2ban konfiguráláskor figyeljen arra, hogy túl agresszív szabályok ne zárjanak ki jogos felhasználókat. Érdemes kezdetben mérsékelt beállításokat alkalmazni, majd fokozatosan szigorítani, miközben a naplókat figyelemmel kíséri.

7. Sebesség- és kapcsolatszám korlátok beállítása

A DDoS és botforgalom ellen az operációs rendszer szintjén is érdemes sebességkorlátozást alkalmazni. Ha egy IP-ről túl sok új kapcsolat érkezik rövid időn belül, akkor azt korlátozni lehet. Web szervereken például nginx-ben a limit_req és limit_conn modulok, Apache-ban a mod_evasive vagy hasonló eszközök segítenek. Az alkalmazás szintjén pedig a bejelentkezési, keresési, kosár, fizetési és API végpontokat külön limitálni kell.

Konkrét példa: egy bejelentkezési oldalon percenként 10 próbálkozás egy IP-ről elfogadható lehet. Egy kereső végponton másodpercenként 2-5 kérés javasolt. API esetén felhasználónként token alapú, IP alapú és viselkedés elemzést egyaránt használjunk. Így a támadó nem tudja egyszerűen IP-cím váltogatással kikerülni a korlátozásokat.

Példa biztonságos beállítás UFW-vel

Ubuntu vagy Debian alapú szervereken egy egyszerű, biztonságos induló beállítás így nézhet ki: először ellenőrizzük a meglévő szolgáltatásokat, engedélyezzük az SSH hozzáférést a rendszergazda IP-jéről, megnyitjuk a 80-as és 443-as portokat, majd az alapértelmezett bejövő forgalmat elutasítjuk és aktiváljuk az UFW-t. Ha az SSH hozzáférés nem korlátozható fix IP-címre, először engedélyezzük minden IP-re, majd később váltunk VPN vagy fix IP megoldásra.

Példa szabályok: legyen a 203.0.113.10 az admin IP-cím. Csak innen engedjük az SSH-t, a webforgalom legyen nyitva a 80-as és 443-as portokon mindenki számára, az adatbázis, Redis, admin panel és teszt portok zárva legyenek. Ez a konfiguráció jó alap kis- és középvállalati weboldalak számára. A domain és DNS helyes beállításához a Hostragons domain ellenőrzés és regisztráció oldal ajánlott.

firewalld és zone alapú kezelés

AlmaLinux, Rocky Linux és RHEL alapú szervereken a firewalld az elterjedt megoldás. A firewalld zónákban kezeli a forgalmat: a public zóna az internet felé nyitott interfészekhez, a trusted zóna megbízható belső hálózatokhoz, a drop zóna pedig a nem kívánt forgalmat csendben eldobja. Fontos megérteni a runtime és a tartós (permanent) szabályok különbségét: a runtime szabályok azonnal életbe lépnek, de újraindításkor elvesznek, a permanent szabályok állandóak, de reload után aktiválódnak.

Vállalati környezetben a szolgáltatás alapú szabályozás megkönnyíti a kezelést. Például a http és https szolgáltatásokat a public zónán engedélyezhetjük, míg az ssh-t csak bizonyos IP-címekről érhetővé tehetjük. Ha a menedzsment hálózat, mentési hálózat és felhasználói forgalom külön interfészeken fut, a zónák használata növeli a biztonságot és az átláthatóságot.

CDN, WAF és szolgáltatói szintű DDoS védelem

A helyi tűzfal csak a szerverre érkező csomagokat szűri. Nagy DDoS támadásoknál a cél, hogy a forgalmat még a szerver előtt kiszűrjük. Ebben a CDN, WAF és a szolgáltatói DDoS védelem kulcsszerepet játszik. A CDN a statikus tartalmakat a felhasználókhoz közel lévő kiszolgálókon szolgálja ki, a WAF az alkalmazás rétegben szűri a káros kéréseket, a szolgáltató pedig a hálózati szinten nyeli el vagy tisztítja a túlterhelő forgalmat.

Ideális esetben a DNS beállítások a CDN-en keresztül mennek, a valódi szerver IP-je rejtve marad, a szerver tűzfala csak a CDN IP tartományokból érkező 80 és 443 port forgalmat engedi be. A menedzsment portokat VPN vagy fix IP alapján érjük el. Ez a modell csökkenti a közvetlen IP támadás esélyét és megakadályozza, hogy a botok közvetlenül elérjék az alkalmazást. További információkért és tippekért a weboldal gyorsítási és biztonsági útmutatók oldal ajánlott.

Alkalmazás szintű védekezés botok ellen

A botok elleni védekezés nem merül ki az IP címek tiltásában. A modern botok proxykat, mobil hálózatokat, adatközponti IP-ket, valamint változó user agenteket használnak, ezért viselkedés alapú megközelítés szükséges. Egy IP-ről rövid idő alatt sok bejelentkezési próbálkozás, folyamatos 404-es hibák generálása, wp-login.php vagy xmlrpc.php forgalom, a normálistól eltérő kattintásminták és gyanús fejlécmezők elemzése ajánlott.

• Használjon aránykorlátozást bejelentkezési és regisztrációs űrlapokon.
• Kapcsolja ki vagy korlátozza az XML-RPC elérést, ha nincs rá szükség.
• Az adminisztrációs panelt védi eltérő URL, IP korlátozás és többfaktoros hitelesítés.
• Szűrje a gyanús user-agent és referer mintákat a WAF szinten.
• Formokon egyensúlyozottan alkalmazzon CAPTCHA-t vagy láthatatlan bot ellenőrző megoldásokat.
• API végpontoknál kulcs, aláírás, kvóta és időbélyeg ellenőrzéseket alkalmazzon.

A botkezelésnél fontos, hogy ne rontsa a felhasználói élményt. A túl sok CAPTCHA, agresszív tiltások vagy téves országblokkok kárt okozhatnak valódi ügyfeleinek. Ezért a folyamatos mérés, tesztelés és fokozatos szigorítás a legjobb módszer.

Naplófigyelés és riasztási szabályok

Nem szabad azt hinni, hogy a tűzfal beállítása után vége a munkának. Egy élő rendszer biztonsági tűzfala folyamatos figyelmet igényel. Az auth.log vagy secure fájlokban az SSH próbálkozásokat, az nginx hozzáférési naplóiban a szokatlan forgalmat, a hibákban a 404 és 500-as jelzéseket, valamint a rendszer metrikáiban a CPU kihasználtságot és kapcsolat számokat érdemes figyelni. Egy egyszerű riasztás is sok perc előnyt adhat egy támadás kezdetén.

Példák kezdő küszöbértékekre: 5 perc alatt ugyanattól az IP-től több mint 100 db 404-es kérés; 1 perc alatt 20-nál több bejelentkezési próbálkozás; 10 percen át 90% feletti CPU terhelés; kapcsolatok száma megsokszorozódása. Ezek az értékek oldalanként változhatnak, fontos, hogy ismerje a normál forgalmi mintát.

Gyakori hibák és elkerülésük

• Biztonsági tűzfal aktiválása SSH engedély nélkül: Ez távoli szerveren elvesztett hozzáférést eredményezhet. Mindig legyen második SSH munkamenet a teszteléshez.
• IPv6 elfelejtése: IPv4 lezárása mellett az IPv6-on továbbra is nyitva maradhatnak szolgáltatások.
• Adatbázis nyitva tartása az internet felé: A 3306, 5432, 6379 és 9200 portokat folyamatosan szkennelik botok.
• CDN használata mellett a valódi IP nyitva hagyása: Így a támadó megkerülheti a CDN védelmet és közvetlenül a szerverre támadhat.
• Szabályok dokumentálásának hiánya: Vészhelyzetben nehéz megérteni, hogy melyik szabály mire szolgál.
• Nincs biztonsági mentési terv: Rossz szabály esetén, ha nincs konzol hozzáférés, a leállás hosszú lehet.

Gyakorlati tűzfal politika példa

Egy kisvállalati weboldalra alkalmazható összefoglaló politika: a bejövő forgalom alapértelmezésben zárt; a 443-as port minden látogatónak nyitott; a 80-as port csak HTTPS átirányításra nyitott; az SSH csak VPN vagy fix admin IP-ről elérhető; az adatbázis csak localhoston vagy zárt hálózaton fut; CDN használat esetén a 80 és 443 port csak a CDN IP tartományokból engedélyezett; Fail2ban figyeli az SSH és webes bejelentkezési kísérleteket; a naplókat központi monitorozó rendszerbe küldi.

Közepes méretű webáruház esetén ehhez hozzátartozik a fizetési callback IP-k engedélyezése, az admin panel VPN mögé helyezése, API token alapú korlátozások, WAF SQL injection és XSS szűrők aktiválása, valamint ideiglenes ország vagy ASN alapú blokkolási terv készítése. Fontos, hogy ez a terv írásban is meglegyen, így támadás esetén előre meghatározott protokoll szerint lehet cselekedni, csökkentve a kiesési időt.

Hogyan teszteljük a szabályokat?

A tűzfal beállítása után mindig ellenőrizni kell, hogy a szabályok valóban működnek-e. Más hálózatról portszkennelést végezzen, igazolja, hogy az SSH csak az engedélyezett IP-ről elérhető, a weboldal HTTPS-en keresztül hozzáférhető, az adatbázis portja pedig kívülről zárt. CDN használata esetén küldjön közvetlen HTTP kérést a szerver IP címére, és ellenőrizze, hogy az tiltva van.

A tesztelés során tartózkodjon a túl agresszív portszkennelésektől, amelyek kárt okozhatnak az éles rendszerekben. A cél a biztonságos ellenőrzés. Minden változtatás után exportálja vagy jegyezze fel a szabályrendszert, így probléma esetén könnyen visszaállítható a működő konfiguráció.

Karbantartás és frissítés

A szerver biztonsága nem egyszeri beállítás, hanem folyamatos karbantartás eredménye. Új szolgáltatás telepítésekor a portokat újra kell vizsgálni, régi szolgáltatások eltávolításakor az engedélyeket törölni kell, a biztonsági frissítéseket időben telepíteni kell, és rendszeresen ellenőrizni a naplókat. Jó gyakorlat legalább havonta egyszer portellenőrzést végezni, háromhavonta pedig áttekinteni a tűzfal szabályokat.

A biztonsági stratégiához tartozik a mentési terv is. A DDoS támadás elérhetetlenné teheti a szolgáltatást, de zsarolóvírus vagy illetéktelen behatolás adatvesztést okozhat. A biztonságos tárhely, SSL, domain kezelés és mentés együttesen ad védelmet. Ebben a témában hasznosak a A biztonságos hosting kiválasztásakor figyelembe veendő szempontok és Hogyan telepíthető az SSL tanúsítvány? tartalmak.

Összegzés

A szerver tűzfal beállítása nem teszi a szervert teljesen láthatatlanná DDoS és botok előtt, de jelentősen csökkenti a támadási felületet, mérsékli az illetéktelen hozzáférések kockázatát, és lehetővé teszi a kontrolláltabb reagálást. A legjobb eredményt a szolgáltatói szintű DDoS védelem, CDN/WAF, szigorú portpolitika, SSH korlátozás, Fail2ban, sebességkorlátozás és folyamatos naplófigyelés együttes alkalmazásával érhetjük el.

Ha új projektet indít, a tűzfal politika megtervezése az elején sokkal egyszerűbb, mint később javítani. A Hostragons platformon szerver, tárhely, domain és SSL infrastruktúrát is összehangolhat biztonsági igényeivel, így egy stabilabb webes környezet jön létre. Ha kell, kezdje egy egyszerű ellenőrző listával: zárja le a felesleges portokat, korlátozza az SSH-t, kényszerítse a HTTPS használatát, és figyelje a naplókat.

Gyakran Ismételt Kérdések

Megakadályozza-e teljesen a szerver tűzfal a DDoS támadásokat?

Nem. A helyi tűzfal csökkentheti a kisebb és bizonyos protokoll szintű támadásokat, de nagy volumenű DDoS esetén szolgáltatói szintű védelem, CDN és WAF használata szükséges.

Mely portok maradjanak nyitva egy web szerveren?

Egy tipikus web szerveren a 80-as és 443-as portok nyitva maradnak. Az SSH port csak az adminisztrátor IP címe számára legyen engedélyezve. Az adatbázis és belső szolgáltatások portjai zárva legyenek az internet felől.

UFW-t vagy firewalld-t használjak?

Ubuntu és Debian rendszereken az UFW egyszerűbb kezdőknek. AlmaLinux, Rocky Linux és RHEL alapú rendszereken inkább a firewalld az elterjedt. Haladó vagy speciális esetekben az nftables javasolt.

Elég az IP címek tiltása a botok ellen?

Általában nem. A modern botok sokféle IP-t és proxy-t használnak. Az IP tiltáson kívül sebességkorlátozás, WAF szabályok, viselkedéselemzés, CAPTCHA és alkalmazás szintű kvóták is szükségesek.

Mi a legnagyobb veszély a tűzfal beállításakor?

A legnagyobb kockázat, hogy rossz szabály miatt kizárjuk magunkat az SSH hozzáférésből. Ezért először engedélyezni kell az SSH-t, másik terminállal tesztelni, és a szolgáltató konzol hozzáférést biztosítania kell.