Ez az útmutató az Arcivéo Monitor telepítéséhez, beállításához és karbantartásához. A szakaszok csoportosítva vannak: általános áttekintés, a vezérlőpult telepítése, a biztonsági eszközök csatlakoztatása, beépített modulok és diagnosztika. A parancsok a jobb oldali gombbal másolhatók.
A panel telepítése külön, lépésről lépésre haladó oldalakon található. Válasszon módszert:
Arcivéo Monitor — szerverbiztonsági irányítópult. Összegyűjti a telepített eszközök (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco stb.) adatait, és egységes felületen jeleníti meg őket irányítópulttal, támadási térképpel és eszközönkénti részletes oldalakkal.
A Monitor nem aktív védelmi eszköz — önmagában nem blokkolja a támadásokat. Feladata a már működő eszközök adatainak összegyűjtése és áttekinthető megjelenítése.
A monitor kizárólag helyben működik — arra a szerverre kell telepíteni, amelyet felügyel. Nincs SSH és nincs távoli API.
Minden parancsot (fail2ban-client, ufw status, ipset list stb.) a panel a webszerver felhasználójának nevében futtat (általában www-data, tárhelypaneleknél a webhely fiókja) szűk jogosultsági körrel a sudo révén — csak az adott segédprogramokra, teljes root-hozzáférés nélkül. Az eredményeket a rendszer feldolgozza és a böngészőben jeleníti meg.
A pontszám a maximumról indul, és minden feltárt problémáért csökken:
PermitRootLogin yes) — −20Eredmény: 80+ = Védett, 60–79 = Figyelem, <60 = Veszélyben.
A WebAuthn jelszó nélküli hitelesítési szabvány hardveres biztonsági kulccsal. Támogatja a YubiKey, Touch ID, Face ID, Windows Hello és Passkey eszközöket.
A jelszavas belépés után a rendszer megerősítést kér a regisztrált kulccsal. Még ha a jelszó ki is szivárog, fizikai kulcs vagy biometria nélkül a belépés lehetetlen.
A beállításhoz nyissa meg a WebAuthn-kulcsok menüpontot az oldalsó menüben, és kattintson a „Kulcs regisztrálása” gombra. Regisztráljon egyből két kulcsot: ha az egyetlen kulcs elveszik vagy elromlik, a panelbe való belépés vele lehetetlenné válik.
A vezérlőpult biztonsági jelentést tud küldeni Telegramra és e-mailre (gombnyomásra és ütemezetten). A beállítás a „Beállítások” szakaszban történik.
Telegram. Szükség van egy bot-tokenre és egy chat id-re:
@BotFather címre → /newbot → megkapja a 123456:ABC... formátumú tokent.@userinfobot botnak, vagy nyissa meg a https://api.telegram.org/bot<TOKEN>/getUpdates címet, és keresse meg a "chat":{"id":...} részt.E-mail. Két módszer közül választhat a „Beállítások” → E-mail menüben:
re_...) és a megerősített feladói domaint.Jelentés állapota: „FIGYELEM” vagy „OK”. A fejléc csak valós probléma vagy függőben lévő teendő esetén válik „FIGYELEM” állapotúvá: ClamAV-fenyegetést talált, fájlváltozások az AIDE-ban, kritikus Falco-események (Emergency/Alert/Critical az elmúlt 24 órában), leállt szolgáltatás a Monitban, újraindítás szükséges, lejáró SSL (≤14 nap) vagy függőben lévő biztonsági frissítések. A háttérzaj — a botok SSH-próbálkozásai, a fail2ban által kitiltott IP-k, a Suricata-riasztások, a Lynis-figyelmeztetések és a már elhárított ModSecurity-kérések — nem emeli meg az állapotot, ezért az ilyen számok a jelentésben önmagukban nem jelentenek „FIGYELMET”.
A részletes felügyeleti modulok (Lynis, UFW, ModSecurity, támadási térkép, AIDE, ClamAV stb.) érvényes licenc esetén nyílnak meg. Enélkül az irányítópult, a beállítások és a fiók működnek, a modulok viszont a „Licenc szükséges” kártyát mutatják.
A fiókban történt vásárlás után rendelkezik egy aktiválási kóddal, amely ARCIVEO-XXXX-XXXX-XXXX-XXXX formájú. Ezt „aktiválni” kell a panel doménjére – ez a kódot egy aláírt licencfájllá alakítja ([license] blokk), amelyet beilleszt a panelbe.
Hogyan aktiválható (3 lépés):
my.arciveo.com fiók → „Licencek” / „Licenc aktiválása” szakasz – másolja ki az ARCIVEO-… kódot.monitor.example.com). Kattintson az aktiválásra – a rendszer legenerálja az ehhez a doménhez kötött licencfájlt, és megjeleníti egy mezőben a „Másolás” gombbal.A panel kriptográfiailag ellenőrzi a kulcsot: az aláírást, a doménhez kötést és az érvényességi időt.
config.php APP_URL konstansából, és csak a gazdanevet adja meg – https:// és www előtag nélkül. Az aktiválás egyszeri: a kód a megadott doménhez tartozó licenccé alakul, és nem aktiválható újra – hibás domén esetén a kulcs nem illik a paneléhez, a kód pedig elhasználódik. Ezért figyelmesen adja meg a doment.
A panel összes fő paramétere egyetlen config.php fájlban van megadva a gyökérben (a public/ mappa mellett), egyszerű define() konstansokkal. A fájl a telepítéskor jön létre; kézi szerkesztésre ritkán van szükség — főként domainváltáskor, átköltöztetéskor vagy másik adatbázishoz való csatlakozáskor. Bármilyen módosítás után indítsa újra a PHP-FPM-et (különben az OPcache miatt a változások nem lépnek életbe).
Írja be saját értékeit a kiemelt helyekre; a többit hagyja úgy, ahogy van:
Adatbázis. A MySQL/MariaDB kapcsolat adatai:
DB_HOST — az adatbázis-kezelő hosztja, szinte mindig localhost;DB_NAME — a panel adatbázisának neve;DB_USER — az adatbázis felhasználója (csak a saját adatbázisához fér hozzá);DB_PASS — ennek a felhasználónak a jelszava;DB_CHARSET — a kapcsolat kódolása, hagyja utf8mb4 értéken.Alkalmazás.
APP_URL — a panel teljes címe (pl. https://monitor.example.com). Egyeznie kell azzal a domainnel, amelyre a licencet aktiválták — különben a rendszer elutasítja a kulcsot (lásd a „Licenc” szakaszt);TIMEZONE — a PHP időzónája: csak arra hat, ahogyan a panel a dátumokat és az időt megjeleníti. A cron-feladatok indítási idejére nincs hatással — ott a rendszer időzónája érvényes (lásd „Az összes cron-feladat”).Munkamenet ideje. A SESSION_LIFETIME a munkamenet tétlenségi időkorlátja másodpercben (gördülő: aktivitáskor frissül). Alapértelmezetten 28800 = 8 óra; ennyi tétlenség után a panel újbóli belépést kér. Például 3600 = 1 óra, 86400 = egy nap.
Hibanaplózás. A hibák soha nem jelennek meg a látogatóknak, hanem a logs/php_errors.log fájlba íródnak — ezek az „Alkalmazásnaplók” oldalon láthatók. Ezeket a sorokat (display_errors=0, log_errors=1, az error_log útvonala) általában nem kell módosítani — a beállítások közvetlenül a fájlban vannak megadva, és nem függenek a php.ini fájltól.
public/ mellett), és ennél a panelnél a webgyökér (DocumentRoot) éppen a panel gyökere, nem a public/. Maga a fájl nem „szivárog ki”: a gyökér .htaccess fájljában explicit tiltás van rá (Require all denied) — a szerver 403 választ ad. E szabály nélkül sem szivárogna ki a forráskód: ez PHP — a szerver végrehajtja, nem szövegként adja vissza. A biztonság kedvéért: ne tegye közzé nyilvános tárolókban, és ne küldje el a támogatásnak valós jelszóval. A fájl jogosultsága — 640.
Az UFW (Uncomplicated Firewall) egyszerű felület az nftables/iptables felé. Az összes bejövő portot lezárja, kivéve a kifejezetten engedélyezetteket. Az „UFW tűzfal” oldal mutatja az állapotot és a szabályokat.
ufw enable előtt feltétlenül engedélyezze az SSH-t (ufw allow OpenSSH), különben elveszíti a hozzáférést a szerverhez.
deny szabállyal lezárt port nem számít kívülről elérhetőnek.
Skipping adding existing rule nem hiba. Az UFW így jelzi, hogy pontosan ilyen szabály már létezik, és nem adja hozzá ismételten. Az automatikus beállítás újbóli futtatásakor (amely idempotens) ez normál üzenet — nem kell reagálni rá.
Automatikusan blokkolja az IP-címet a sikertelen bejelentkezési kísérletek számának túllépése után. Elemzi az SSH, nginx, Apache és más szolgáltatások naplóit.
Az alaptelepítés fent található. Itt a működő konfiguráció, amely több tucat aktív jailt és több ezer tiltást eredményez: általános beállítások, kulcsfontosságú jailek és a rosszindulatú IP-k automatikus tiltása az ipsum listából.
A /etc/fail2ban/jail.local fájl — általános beállítások és a legfontosabb jailek:
ignoreip mezőbe feltétlenül írja be saját IP-jét és a megbízható hálózatokat, különben saját magát is kitilthatja. A módosítások után: sudo fail2ban-client reload.
Az ipsum tiltólista automatikus betöltése a root cronba (sudo crontab -e): a level 1 (100+ ezer IP) betöltődik az ipsum halmazba, amelyet a tűzfal szűr (részletek a „IPset tiltólista” szakaszban):
ipsum legyen — pontosan ezt olvassa be a dashboard (az „IPset ipsum” kártya). Szintek: levels/1.txt — maximális lefedettség, levels/3.txt — pontosabb (3+ forrás).
Miért van a „Biztonsági monitor” két zónára osztva. A védelem két szinten működik, és a dashboard nem keveri őket:
sshd, apache-*, nginx-* stb. jailek) és a rosszindulatú visszaesők (a recidive jail — akiket már többször tiltottak). Ezek olyan IP-k, amelyek ténylegesen betörni próbáltak Önhöz — ott vannak a támadási térképen és az „Idővonalon”.ipset ipsum tiltólistája, amelyet a tűzfal szűr le a DROP szabállyal. Ezek a címek többségükben nem is érintették a szerverét — előre le vannak tiltva; az „IPset ipsum” számláló mutatja, mennyit szűrt meg megelőző jelleggel.A különbség egyszerű: a reaktív — „ezek támadtak és tiltást kaptak”, a megelőző — „ezeket még a kísérlet előtt letiltottuk”. Korábban a recidive-be mesterségesen betöltötték az ipsum list-3-at (innen ered a régi „listás recidive” felosztás); most a recidive már csak a valódi visszaesőket tartalmazza, a megelőzés pedig teljes egészében a tűzfalon van.
ipsum — nyilvános, naponta frissülő lista a rosszindulatú IP-címekről. A Monitor a betöltött címek számát mutatja a vezérlőpulton és a támadási térképen, és beszámítja a biztonsági pontszámba (−10, ha a lista nincs betöltve).
fail2ban nélküli minimális megoldás — külön ipsum lista iptables-alapú blokkolással:
@reboot eseményhez. Egyúttal a create … -exist parancs beállítja a maxelem 300000 korlátot (az alapértelmezett 65536 mellett a level 1 nem fér el, „Hash is full” hibát kapna):
ipsum listába, és ha a tűzfalat a telepítő kezeli (friss VPS — „Teljes”/„Könnyített” profilok), egy DROP szabállyal csatolja a listát a UFW-hez — ezekről az IP-címekről a forgalom ténylegesen blokkolódik. A szabály az ESTABLISHED,RELATED után áll, ezért a meglévő kapcsolatok (köztük az Ön SSH-ja) nem szakadnak meg — csak a listán szereplő új kapcsolatok tiltódnak. A lista az ipsum-load.service szolgáltatás indulásakor áll helyre, a tűzfal előtt (különben a UFW nem indulna el), és a cron 04:00-kor frissíti. Egy már beállított szerveren (panel, saját tűzfal) a telepítő nem nyúl a tűzfalhoz — ott az ipsum a vezérlőpult és a támadási térkép listája marad, a DROP szabály pedig igény szerint kézzel adható hozzá (a minimális megoldás az iptables … --match-set ipsum … -j DROP-pal — feljebb). Automatikus telepítéskor kézzel semmit sem kell tenni.
A Fail2ban modern helyettesítője kollektív threat intelligence funkcióval: közösségi bannok és saját szabályok. A bannok tűzfalra alkalmazásához külön bouncer szükséges.
systemctl is-active crowdsec paranccsal ellenőrzi). Indítás: sudo systemctl enable --now crowdsec; hiba esetén nézze meg: sudo journalctl -u crowdsec -n 30. Ugyanez érvényes minden „Nincs elindítva” állapotú szolgáltatásra (Suricata, Falco, Monit, MySQL).
stream halted / a bannok nem érvényesülnek. Ez egy árva api-kulcs: a bouncert eltávolították a cscli bouncers list listából, de a régi kulcsa megmaradt itt: /etc/crowdsec/bouncers/*.yaml. Regisztrálja újra a bouncert, és írja be a friss kulcsot:
Az AIDE (Advanced Intrusion Detection Environment) pillanatképet készít a fájlrendszerről, és minden ellenőrzéskor jelzi a változásokat a /etc, /bin, /usr könyvtárakban. Telepítés után kötelező az adatbázis inicializálása (aideinit).
aideinit során a terminál 5–15 percig a Running aide --init... soron áll — ez normális (az egész fájlrendszer hasítása, lemezterhelés). Ne szakítsa meg Ctrl+C-vel. Ha a folyamat „lóg”, de semmit sem ír ki, lehet, hogy egy rejtett Overwrite existing aide.db.new [Yn]? kérdésre vár választ (nyomja meg a Y billentyűt). Az aktivitás egy másik munkamenetből ellenőrizhető: pgrep -af aide.
aideinit hiba: „21_aide_spamassassin … printf: invalid number” (return code 20) — az AIDE konfigurációs kódrészletének ismert hibája Ubuntu 22.04 alatt. Az adatbázis nem jön létre. Vegye ki a hibás kódrészletet, majd próbálja újra:
aideinit, vagy (Ubuntu 24.04) a /var/lib/aide könyvtár 700 módban jött létre és a www-data számára elérhetetlen — ezt a sudo chmod 755 /var/lib/aide orvosolja (lásd a fenti blokkot). „Nem volt ellenőrzés” = az adatbázis megvan, de ellenőrzés még nem futott — ez nem hiba. Az eredményeket a monitor a /var/log/aide/aide.log fájlból olvassa.
/etc/cron.daily/aide az újabb Ubuntu/Debian rendszereken lehet, hogy nem a megfelelő formában írja a /var/log/aide/aide.log fájlt (és az aide.wrapper sincs már meg bennük). Megbízhatóbb saját cron-bejegyzést hozzáadni explicit --config kapcsolóval — ez root által, 644 módban írja a naplót, és a monitor további csoportok nélkül olvassa:
chmod 755 /var/lib/aide és a 02:00-kor futó ellenőrző cron — kézzel semmit sem kell tennie.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Víruskereső Linuxra. Különösen hasznos a /var/www ellenőrzéséhez PHP-shellek és kártékony kód után.
enable --now után? Három tipikus ok:
1. A konfigban benne maradt az Example sor — a clamd nem indul el, amíg ott van:
2. Nincs letöltve a szignatúra-adatbázis — a clamd nélküle nem indul el:
3. Egyszerűen csak betölt — a clamd 30–60 mp alatt tölti be a ~8 millió szignatúrát a memóriába. Várjon, majd ellenőrizze: systemctl is-active clamav-daemon (az activating állapot → még tölt).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd démon csak a memóriában tartja a szignatúrákat, magától ütemezetten semmit sem vizsgál. A panel az ütemezett vizsgálat eredményeit mutatja, ezért kell egy cron, amely vizsgál és naplóz. Az automatikus telepítő elhelyezi a /usr/local/bin/clamav-scan.sh burkolót és egy cront 01:30-ra — az első futás után feltöltődik az „Ellenőrzött fájlok” és az „Utolsó vizsgálat” érték. Azonnali indítás az ütemezés bevárása nélkül: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) – webes fenyegetésekre szabott kártevőkereső: PHP-shellek, webes backdoorok, letöltők. A ClamAV motorját használja, és saját szignatúrákkal egészíti ki.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet sor – ez ártalmatlan. A maldet nem használja az init.d-t, a szignatúrafrissítés és a vizsgálatok a /etc/cron.daily/maldet révén futnak. Ha lentebb látható az installation completed, akkor minden települt.
apt révén települ, hanem a /usr/local/maldetect könyvtárba, és bekapcsolt open_basedir esetén a megléte a shellen keresztül ellenőrizhető – lásd „Az oldal üres, pedig az adatok megvannak a szerveren” szakaszt.
Hálózati behatolásérzékelő rendszer: csomagszinten elemzi a forgalmat, és több ezer támadási szignatúrát ismer. Kiegészíti a ModSecurity-t (az HTTP-szinten működik, a Suricata pedig TCP/IP-szinten).
/var/log/suricata/eve.json fájlt root alatt írja, a könyvtár 750-es jogosultsággal, így a webszerver (www-data) nem tudja olvasni. Nyissa meg a könyvtárat átjárásra – a benne lévő fájlok védettek maradnak:
eBPF/kernel module segítségével elfogja a rendszerhívásokat, és valós időben észleli az anomáliákat: shell az nginxből, a /etc/passwd olvasása webes folyamat által, írás a /bin könyvtárba stb.
journalctl -u falco paranccsal olvassa a Falco eseményeit (sudo nélkül — a systemd-journal csoporton keresztül). Győződjön meg róla, hogy a www-data tagja ennek a csoportnak — lásd a „sudo beállítása” pontot (2. lépés) a kézi telepítés oldalán.
/etc/passwd olvasása, írás a rendszerkönyvtárakba). A nulla kritikus esemény napi szinten egy nyugodt szerveren egészséges állapot.
journalctl olvasásához naplójogosultság kell; hogy a panel stabilan lássa az eseményeket, az automatikus telepítés bekapcsolja a Falco file_output beállítását → /var/log/falco/falco.log, és a szolgáltatáshoz beállítja az UMask=0022 értéket (a naplót a webszerver is olvashatja). Új telepítésnél ezt kézzel nem kell beállítani.
A ModSecurity egy webalkalmazás-tűzfal (WAF) Apache vagy Nginx alá. Alkalmazásszinten blokkolja a támadásokat: SQL-injekciók, XSS, útvonalbejárás, szkennerek.
IncludeOptional /etc/modsecurity/*.conf sorral tölti be a konfigokat, a csomag viszont csak a modsecurity.conf-recommended fájlt helyezi el — ez nem esik a *.conf maszk alá. Ha nem másolja át a modsecurity.conf fájlba, a SecRuleEngine Off marad: a modul betöltődik, a CRS-szabályok betöltődnek, de a forgalom nem kerül ellenőrzésre, és auditnapló sem jön létre. A köztes DetectionOnly mód csak naplózza az eseményeket, a kéréseket nem blokkolja — a felület ezt sárgával jelzi.
A felület hozzáférése az auditnaplóhoz. A /var/log/apache2/modsec_audit.log napló a root tulajdona (640-es jogosultság), a webes felhasználó nem tudja olvasni. A felület egy burkolón keresztül veszi az adatokat — hozza létre ezt:
SecRuleEngine direktívát veszi: a behúzott sorok <LocationMatch>/<Directory> blokkokon belül vannak (például a WAF kikapcsolása phpMyAdminhoz), és nem határozzák meg a globális módot.www-data, HestiaCP-ben a webhely poolja a webhely tulajdonosa alatt fut (például admin) — ellenőrizze a grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf paranccsal.X-Forwarded-For fejlécből veszi. A statisztikába csak a szabály általi találatot okozó tranzakciók kerülnek: a SecAuditLogRelevantStatus direktíva minden 4xx/5xx választ az auditnaplóba ír, ezért oda a hétköznapi 403/500-as válaszok is bekerülnek — ezeket a felület nem tekinti WAF-eseménynek.---RULES--- blokkra a „Minden aktív szabály” szakasznak van szüksége — a felület nem csak a találatot okozó, hanem az összes betöltött CRS-szabályt + az egyénieket is megjeleníti. A for f in … ciklus három útvonala a CRS-szabályok és a helyi kiegészítések tipikus helye; ha Önnél más az elrendezés (a csomag a saját könyvtárába telepíti a fájlokat, vagy az egyéni szabályok nem a /etc/modsecurity/custom-rules.conf fájlban vannak), keresse meg a valós útvonalakat a sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null paranccsal, és illessze be őket a listába. Ha a burkoló régi (e szakasz nélküli) — a szakasz csak egy „nem elérhető” figyelmeztetést jelenít meg, az oldal többi része a korábbiak szerint működik.
Az Auditd (Linux Audit Daemon) kernelszinten rögzíti a rendszerhívásokat: be- és kijelentkezéseket, sudo-parancsokat, sikertelen hitelesítési kísérleteket, fájlmódosításokat. A Monitor megjeleníti a mai bejelentkezéseket, a sikertelen kísérleteket és a sudo-parancsokat.
ausearch paranccsal (/usr/sbin/ausearch) olvassa az eseményeket, szükség esetén pedig a /var/log/audit/audit.log fájlból a tail paranccsal. Mindkettőnek szerepelnie kell a sudoers fájlban.
Figyeli a szolgáltatásokat (nginx, php-fpm, mysql stb.), és leállás esetén újraindítja őket. E-mailben tud riasztásokat küldeni.
monit status paranccsal kéri le a szolgáltatások listáját. A /etc/monit/monitrc fájlban engedélyezve kell lennie a HTTP-felületnek (a set httpd blokk allow localhost beállítással), különben a monit status hibát ad vissza.
monitrc fájlban a set httpd sor ki van kommentelve (alapból # set httpd port 2812 … formában). Vegye ki a blokkot a kommentből, és engedélyezze a localhostot. (2) A bekapcsolt httpd önmagában semmit sem figyel — a Monit csak azt veszi számításba, amit check-stanzák írnak le; ezek nélkül a lista akkor is üres, ha a felület működik. Minimális működő konfiguráció:
conf.d fájlt helyez el a 2812-es porton figyelő httpd-vel és egy sor ellenőrzéssel — új telepítésnél nem kell kézzel beállítani.
A PSAD az iptables naplóját elemzi, és felismeri a portszkennelést és a hálózati támadásokat, minden forráshoz veszélyszintet (1–5) rendelve. Kiegészíti a fail2bant és a Suricatát.
psad --Status parancson keresztül olvassa be az adatokat (szükséges a sudoersben). Az iptables naplózása nélkül az oldal üres lesz — ez normális, amíg nem történt szkennelés.
A Mandatory Access Control korlátozza, hogy egy program mely fájlokhoz és erőforrásokhoz férhet hozzá, még akkor is, ha feltörték. Az Ubuntu/Debian rendszereken alapértelmezésben az AppArmor működik (általában már telepítve és aktív).
aa-status parancson keresztül olvassa az állapotot (sudoersben kell lennie). Megjeleníti az enforce/complain módú profilok számát és a profil nélküli folyamatokat.
A „betöltött profilok” száma nagyobb, mint az enforce + complain — ez normális. Az AppArmor 4.x-ben (Ubuntu 24.04 és újabb) megjelent az unconfined mód: a profil be van töltve a kernelbe, de semmit sem korlátoz. Az Ubuntu így jelöl meg több tucat profilt olyan programoknál, amelyek user namespace-eket használnak (böngészők, torrentkliensek és hasonlók). Ha vannak ilyen profilok, a „betöltött profilok” kártya borostyánszínűvé válik, és megjeleníti a számukat — például unconfined: 90 a 120 betöltöttből, amiből 26 enforce módú. Ténylegesen csak az enforce módú profilok védenek; az Ubuntu 22.04-en (AppArmor 3.x) ez a mód nincs, és a számok mindig egyeznek.
unconfined állapotban, csak tudatosan érdemes enforce módba állítani: nem tévedésből vannak kikapcsolva, hanem mert különben az adott programok működése megszakad. A complain módú profilok más eset: ott a szabályok már meg vannak írva, csak nem érvényesülnek.
A debsums ellenőrzi, hogy a telepített csomagok fájljai egyeznek-e a tárolóból származó ellenőrzőösszegekkel — felderíti a kicserélt rendszerbinárisokat (kiegészíti az AIDE-ot). A teljes ellenőrzés 1–2 percig tart, ezért cron futtatja, a felület pedig a data/debsums/debsums.log fájlból olvassa be az eredményt, és maga sorolja kategóriákba (csak a binárisok és a könyvtárak fontosak).
A feladat a root cronba kerül (sudo crontab -e). A kész debsums-scan.sh burkoló a /usr/local/bin/ mappába kerül (chmod +x; lásd a cron-feladatok összegzését), és maga írja a jelentést a felület data/debsums/ mappájába.
A debsums-scan.sh burkoló maga megtalálja a felület data/ mappáját — az útvonalat nem kell megadni.
/etc/ (konfigurációk) és a /usr/share/ (erőforrások) módosításai általában normálisak — a felület külön színnel jelöli őket. A binárisok és könyvtárak módosításai riasztóak (/bin, /sbin, /usr/lib stb.) — a „Binárisok / könyvtárak” kártya éppen ezeket mutatja.
A Lynis kézzel vagy cron segítségével indítható. A jelentést a projekt data/lynis/ mappájába kell menteni — a monitor a lynis-report.dat fájlt olvassa.
lynis-scan.sh parancsfájlt közvetlenül a panelről (a cronra nem várva): megjeleníti a „Vizsgálat…” állapotot, és a végén magától frissíti a jelentést. Ehhez a webes felhasználónak sudoers-sorra van szüksége a szkript futtatásához — a telepítő ezt automatikusan hozzáadja a /etc/sudoers.d/monitor fájlhoz. Ha a panelt kézzel/korábban telepítette, egészítse ki azzal a felhasználóval, amely már szerepel a fájlban:
A Logwatch mentse a napi jelentéseket a projekt data/logwatch/ mappájába .txt formátumban. A monitor megjeleníti a legutóbbi jelentést és az archívumot.
A hálózati monitor nem igényel telepítést — ez a vezérlőpult beépített oldala. A szerver hálózati állapotát helyi forrásokból jeleníti meg:
/proc/net/dev alapján;ip segítségével;ss segítségével;journalctl -k segítségével.Az első három forrás sudo nélkül működik, ezért az interfészek, a forgalom, a kapcsolatok és a portok azonnal láthatók. A „Kernelesemények” blokk a journalctl -k parancsot használja — ez a systemd-journal csoporton keresztül olvasható („A sudo beállítása”, 2. pont), sudo nem szükséges. Ellenőrizze, hogy minden elérhető-e a webes felhasználó számára:
UFW BLOCK bejegyzései nem kerülnek ide — ezek a „UFW tűzfal” és a „Támadási térkép” oldalakon vannak. Az üres blokk zöld pipával = a nap folyamán nem volt hálózati hiba.
A beépített oldal három dolgot mutat:
df); a sáv ≥90%-nál pirosra vált;lsblk), csak a valósak (a loop/snap rejtve van);smartctl).A tárhely és az eszközlista beállítás nélkül, azonnal működik. A SMART-hoz a smartmontools csomag szükséges. A webes folyamatnak nincs közvetlen hozzáférése a lemezes eszközökhöz, ezért a SMART-adatokat cron útján a data/disk/smart.txt fájlba gyűjti, a dashboard pedig azt olvassa be.
A feladat a root-cronba kerül (sudo crontab -e). A kész smart-scan.sh burkoló a /usr/local/bin/ könyvtárba kerül (chmod +x; lásd a cron-feladatok összefoglalóját), és maga ír a dashboard data/disk/ könyvtárába.
A smart-scan.sh burkoló maga megtalálja a dashboard data/ könyvtárát — az útvonalat nem kell megadni. Belül az lsblk -e7,11 kizárja a loop/cdrom eszközöket.
Az oldal a szerver terhelésének előzményeit mutatja az elmúlt 24 órára — Load Average, CPU-kihasználtság és I/O-várakozás, RAM/Swap, hálózati forgalom (fogadás/küldés), lemez I/O (olvasás/írás), lemez- és inode-telítettség, nyitott fájlleírók és MySQL-kapcsolatok, továbbá az aktuális TCP-kapcsolatok és folyamatok száma.
Az adatokat a cron/collect_metrics.php gyűjti — 5 percenként egy „nyers” pillanatképet ír a számlálókról (/proc/loadavg, /proc/meminfo, /proc/stat, /proc/net/dev, /proc/diskstats, df/df -i, /proc/sys/fs/file-nr, SHOW GLOBAL STATUS LIKE 'Threads_connected') az adatbázis system_metrics táblájába; a százalékokat és sebességeket az oldal maga számolja a szomszédos pillanatképek különbségéből (a lemez-/inode-/fájlleíró-telítettség és a MySQL-kapcsolatok pillanatnyi értékek, átszámítás nélkül). Sudo nem szükséges — a források root jogosultság nélkül olvashatók. A 24 óránál régebbi pontok minden íráskor automatikusan törlődnek.
A collect-metrics-all.sh csomagoló (lásd a cron-feladatok összefoglalóját) maga megtalálja a szerveren telepített összes panelpéldányt, és mindegyik cron/collect_metrics.php fájlját a webhely tulajdonosának nevében futtatja.
Terhelési riasztások („Beállítások” → „Terhelési riasztások” szakasz) — a CPU/RAM/lemez/inode küszöb túllépésekor a panel értesítést küld Telegramra/e-mailre (ugyanazok a csatornák, mint a napi jelentésnél — a riasztásokhoz nem kell külön bekapcsolni őket), és egy továbbit akkor, amikor a metrika visszatért a normál tartományba. A küszöb tartása alatt nem küld ismételten spam-et: a következő értesítés csak a „helyreállt → újra túllépte” ciklus után érkezik.
collect_metrics.php ellenőrzi minden futtatáskor (5 percenként) — külön cron nem szükséges. A „már értesítettünk / még nem” állapot a data/alerts_state.json fájlban tárolódik, a küszöbök pedig a panel beállításaiban.
A „Támadási térkép” oldal a geoiplookup paranccsal állapítja meg az országot az IP alapján. A GeoIP csomag nélkül az országok nem ismerhetők fel, és a pontok nem jelennek meg a térképen:
/usr/share/GeoIP/GeoIP.dat adatbázist bárki olvashatja, az eredmények a tmp/geoip_cache.json fájlba kerülnek gyorsítótárba. Maga a térkép (Leaflet + OpenStreetMap csempék) a böngészőben töltődik be — internet szükséges azon a számítógépen, ahol a vezérlőpult meg van nyitva.
Két beépített irányítópult-kártya, amely nem az eszköz „be/ki” állapotát mutatja, hanem a szerver tényleges védettségét. Nem igényelnek telepítést, helyben, sudo nélkül olvashatók.
Külső kitettség — hány szolgáltatás figyel minden interfészen (0.0.0.0/[::]), és érhető el kívülről. Pirossal jelzi, ha adatbázis vagy gyorsítótár lóg ki kifelé (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) — ez közvetlen rés (−10 a Biztonsági pontszámhoz). Forrás: ss -tuln.
127.0.0.1 címhez (bind-address a MySQL/PostgreSQL konfigban, bind 127.0.0.1 a Redisben), vagy zárja le a portot az UFW-ben.
127.0.0.1 (loopback) címen figyelő szolgáltatás csak magának a szervernek látszik — kívülről nem érhető el, még ha a port „nyitva” is van. Ezért biztonságos a 25-ös porton loopbackhez kötött Postfix: az automatikus beállítás beállítja az inet_interfaces = loopback-only értéket (plusz a semleges smtpd_banner — ezzel megszűnik a Lynis MAIL-8818 figyelmeztetése a verzió felfedéséről). A „Külső kitettség” kártya csak azt számítja kifelé nyitottnak, ami a 0.0.0.0/[::] címen figyel; a loopback-szolgáltatások nem kerülnek oda.
/etc/postfix/main.cf fájlban állítsa be az smtpd_banner = $myhostname ESMTP (verzió és OS nélkül) és az inet_interfaces = loopback-only értéket, majd sudo systemctl restart postfix.
Biztonsági frissítések — hány biztonsági javítás vár telepítésre, és szükséges-e újraindítás a kernelfrissítés után (−5 a Biztonsági pontszámhoz, ha vannak javítások). Forrás: /usr/lib/update-notifier/apt-check, a /var/run/reboot-required fájl. Részletes lista a „Biztonsági frissítések” oldalon.
update-notifier-common). Ha az apt-check hiányzik — a monitor az apt-get -s upgrade paranccsal számolja a javításokat.
Automatikus biztonsági frissítések (unattended-upgrades) — a „Biztonsági frissítések” oldalon külön kártya mutatja, hogy be van-e kapcsolva a biztonsági javítások automatikus telepítése, és mikor futott le utoljára. Sudo nem szükséges — az állapot az apt-config dump paranccsal olvasható.
A biztonsági mentés a legfőbb védelem: az adatvesztés minden feltörésnél súlyosabb. Két dologra van szükség — a szerver/webhelyek mentése és külön a vezérlőpult adatbázisának mentése (itt vannak a felhasználók, a WebAuthn-kulcsok, a beállítások és a licenc).
A változat — HestiaCP: a felhasználó Backup lapja → mentéskészítő gomb (vagy ütemezetten a szerverbeállításokban). A mentés tartalmazza a webhelyeket és azok adatbázisait.
B változat — kézzel (cron): adatbázis-dump + a vezérlőpult data/ könyvtárának archívuma:
Frissítés új verzióra. Először készítsen biztonsági mentést. Ezután töltse fel újra a kódfájlokat, megőrizve az adatait:
public/, includes/, assets/, cron/, database/, valamint a gyökérben lévő .htaccess (a front controller — az útválasztást nem szabad a régi verzióból meghagyni), manifest.json, sw.js;config.php (adatbázis-adatok), data/ (jelentések), logs/, tmp/ (munkamenetek és gyorsítótár).SSH_FX_PERMISSION_DENIED — Permission denied. A panel fájljai a www-data tulajdonában vannak (a telepítéskor így lettek beállítva), miközben az SFTP-kliens a saját felhasználójával csatlakozik, amelynek nincs írási joga. Ha az egész panelt a www-data-nak adja „hogy működjön”, épp az vezet ehhez a hibához; alább három módszer, mindegyik megoldja a problémát.
data/ (jelentések), tmp/ (munkamenetek és gyorsítótár), logs/; ezek a www-data-nál maradnak. A többi kód, és a webszervernek csak olvasásra van rá szüksége, amit a www-data csoport 644 jogosultsággal biztosít. Mellékhaszon: PHP-sebezhetőség esetén a panel fájljai már nem írhatók felül. Hosting-paneleken (HestiaCP és hasonlók) az A változat nem szükséges: ott a webhely fájljai amúgy is ahhoz a fiókhoz tartoznak, amellyel SFTP-n bejelentkezik, a webszerver pedig csoport alapján olvassa őket.
chmod visszaállítja az ACL-maszkot, és a hozzáférés csendben megszűnik. Ha a „jogosultságok rendbetétele” után a feltöltés ismét Permission denied hibába ütközik — futtassa le újra mindkét setfacl parancsot.
2-es bit a setgid: az SFTP-n feltöltött fájlok a www-data csoportban maradnak, különben a panel nem tudja felülírni őket. A C változat után csatlakozzon újra a FileZillában — az új csoport csak új bejelentkezéskor lép életbe. Ellenőrzés: id deploy (meg kell jelennie a www-data csoportnak) és ls -ld /path/to/monitor (drwxrwsr-x — az s betű azt jelenti, hogy a setgid be van állítva).
Áthelyezés másik szerverre:
config.php és data/ mellett.mysqldump a régin → importálás az újon; javítsa az adatbázis-adatokat a config.php fájlban.adm csoporttagság, cron-feladatok.Ha nem tud bejelentkezni, minden közvetlenül az adatbázisban javítható a szerverről. Nyissa meg az adatbázist (a neve a config.php fájlból):
Elveszett WebAuthn kulcs (a második faktor nem sikerül) – kapcsolja ki a 2FA-t, jelentkezzen be jelszóval, majd regisztráljon új kulcsot:
Elfelejtett jelszó – állítson be új hasht (generálja a szerveren, és illessze be):
Kizárta magát az IP-szűrővel – kapcsolja ki a korlátozást:
sudo mysql a szerveren, vagy a phpMyAdmin / a tárhely vezérlőpultjának adatbázis-szakasza. A visszaállítás után kapcsolja be újra a WebAuthn-t és az IP-szűrőt.
A feladatok összesítése a szerver root cron-jában van (a sudo crontab -e paranccsal adhatók hozzá). Csak azoknak az eszközöknek a sorait hagyja meg, amelyeket használ; az útvonalakat igazítsa a saját szerveréhez.
sudo crontab -l és hogy a cron-szolgáltatás aktív-e.
config.php-beli TIMEZONE. A TIMEZONE konstans csak a PHP-t érinti (ahogy a panel a dátumokat megjeleníti), de a cron-démon az operációs rendszer rendszeridejéhez igazítva futtatja a feladatokat. Ha a szerver időzónája nem egyezik az Önével, a „08:00”-s jelentés nem a megfelelő időben érkezik. Példa: a szerver másik időzónában áll (Europe/London, UTC+1), Ön viszont Budapesten (UTC+2) → a „08:00”-s jelentés az Ön ideje szerint 09:00-kor érkezik. Ellenőrizze, és szükség esetén igazítsa a rendszer időzónáját a sajátjához:
0 8 * * * sor a helyi idő szerint 08:00-kor fut le. Egyébként magát a cront kellene eltolni, de a téli/nyári időszámításra váltáskor az eltolás ismét elcsúszna — ezért helyesebb a rendszer időzónáját beállítani.
crontab.txt) a projekt melletti system/ mappában találhatók, a public_html-en kívül. Ez nem része a webhelynek — a webgyökérbe nem kell feltölteni; helyezze el a szerveren a rendszerútvonalakon (mint a fenti crontabban):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — futtatja a lynis audit system-et, a vizsgálat idejére kihelyezi a /tmp/lynis-running jelzőt, és a lynis-report.dat-ot a panel data/lynis/ mappájába másolja;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — napi Logwatch jelentést készít (sshd, fail2ban, sudo, postfix) a data/logwatch/ mappába;smart-scan.sh → /usr/local/bin/ (chmod +x) — rögzíti a lemezek állapotát (smartctl) a data/disk/ mappába;debsums-scan.sh → /usr/local/bin/ (chmod +x) — ellenőrzi a csomagok integritását (debsums) a data/debsums/ mappába;clamav-scan.sh → /usr/local/bin/ (chmod +x) — ClamAV víruskeresés a veszélyes útvonalakon (web, home, temp); az összesítést a /var/log/clamav/scan.log-ba írja, ahonnan a ClamAV oldal beolvassa (a fenti crontab 01:30-as sora);load-ipsum.sh → /usr/local/bin/ (chmod +x) — helyben frissíti az ipsum ipset halmazt (level 1), anélkül hogy megtörné az aktív tűzfalszabályokat (a 04:00 sor a fenti crontabban);daily-report-all.sh → /usr/local/bin/ (chmod +x) — a panel cron/daily_report.php jelentését futtatja (a fenti crontab 08:00-as sora);daily_report.php — már a panel része (cron/daily_report.php), a daily-report-all.sh-n keresztül fut, külön nem kell telepíteni;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — a panel cron/collect_metrics.php-ját futtatja („Teljesítmény” oldal, a fenti crontab */5 sora); a collect_metrics.php már a panel része, külön nem kell telepíteni;crontab.txt (system/cron/) — feladatminta; a szükséges sorokat a sudo crontab -e paranccsal írja be./usr/local/bin/ mappába. Közvetlenül a FileZillából nem lehet oda írni — a könyvtár a root tulajdonában van, és az SFTP-kliens SSH_FX_PERMISSION_DENIED hibát kap. A sorrend a következő: először töltse fel a fájlt a /tmp mappába (oda mindenki írhat), majd egyetlen paranccsal helyezze át a helyére:
/tmp kell — nem a /var/tmp és nem a panelen belüli tmp/ (utóbbi a www-data tulajdonában van, és zárva van az Ön felhasználója elől). A FileZilla fájlfájában a /tmp egy felső szintű ág, a var mellett, nem azon belül.
/usr/local/bin/-ba, a napló a /var/log/arciveo-cron.log) — kézzel nincs teendő.
/home/*/web/*/public_html és a /var/www/* végigjárásával találják meg, és a jelentéseket ezek data/ mappájába teszik. Ha a panel más útvonalon van — adja hozzá a szkriptekben lévő for app in … sorhoz, különben a Lynis/SMART/debsums/Logwatch jelentések nem jutnak be a panelbe.
logs/cron.log fájlt elsőként a root cron hozza létre — így az a root tulajdonába kerül, és a panel „Cron napló” lapja sem olvasni, sem törölni nem tudja majd. Hozza létre a fájlt előre a webfelhasználó nevében (a webhely könyvtárának tulajdonosa; HestiaCP esetén ez egy fiók, pl. admin) — így a root cron már csak hozzáír, nem változtatja meg a tulajdonost:
stat -c %U /path/to/monitor.
sudo crontab -e), különben kétszer fut le.
sudo crontab-ra (ez közvetlen root-jogosultság-emelés lenne bárki számára, aki hozzáfér a panel munkamenetéhez), hanem egy szűk, két parancsból (list/set) álló szkriptre, amely csak a saját blokkját érinti a szolgáltatási megjegyzések között. Telepítse egyszer:
www-data-tól — ellenőrizze, milyen felhasználóval fut a webhely PHP-FPM készlete (ps -o user= -C php-fpm), és azt írja be a sudoers-sorba.
public/crontab_monitor.php fájlt FTP/SFTP-n keresztül más rendszerfelhasználóval (például root) töltötte fel, mint a webhely többi fájlját, a webszerver nem tudja majd elolvasni. Vesse össze a tulajdonost és a jogokat a szomszédos fájllal, és hozza összhangba:
A Monitor a dpkg-query – az APT csomagadatbázisa – segítségével észleli az eszközök meglétét. Ha egy eszközt nem az apt révén telepítettek (kézzel, snap-ből vagy forrásból), a dpkg nem látja azt.
500-as hiba — ellenőrizze a PHP, az nginx és maga a monitor naplóit:
www-data alatt fut, hanem a felhasználói fiók alatt (például admin — a webhely könyvtárának tulajdonosa). Minden sudo-szabályt és csoporttagságot (adm, systemd-journal) erre a felhasználóra kell beállítani, különben a modulok „Nem aktív / 0” állapotot mutatnak, miközben a szolgáltatások futnak. A PHP valódi felhasználójának lekérdezése: ps -o user= -C php-fpm | sort -u, vagy a webhely könyvtárának tulajdonosa: stat -c '%U' /path/to/monitor. Az alábbi parancsokban ezt írja be a www-data helyett. Az automatikus telepítő maga ismeri fel a webfelhasználót, és a sudoers-t rá állítja be.
Az adatok nem jelennek meg — szinte mindig a be nem állított sudo-jogosultságok az ok. Ellenőrizze az adott parancsot a webfelhasználó nevében (cserélje a www-data-t a sajátjára). A -n kapcsoló = jelszó nélkül, ahogy a PHP is — ha jelszót kér, akkor nincs rá szabály a sudoers-ben:
sudo aa-status a terminálban profilokat mutat, az „AppArmor” oldal viszont „Nem aktív”). Ok: a webfelhasználónak nincs sudo-joga ezen modul parancsához. Ellenőrizze a fenti listából: ha jelszót kér — adja hozzá a hiányzó sort a /etc/sudoers.d/monitor fájlhoz („A sudo beállítása”). Gyakori „új” parancsok: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status vagy ss, illetve a webfelhasználó nem tagja az adm/systemd-journal csoportoknak (innen olvassa a rendszer a fail2ban/auth/modsec naplókat és a journalctl-t — Falco és kernelesemények).
Tünet: a szerveren vannak adatok (shellen keresztül láthatók), az oldal viszont „nincs adat” üzenetet vagy hibás állapotot mutat — például az AIDE azt írja, hogy „Nincs inicializálva”, pedig az adatbázis létre lett hozva.
Az ok az open_basedir: sok panel és tárhely a domain könyvtárára korlátozza a PHP-FPM pool-t, ezért a file_exists(), file_get_contents(), filemtime() PHP-függvények a rendszerútvonalakon (/var/lib/aide, /var/log, /proc…) blokkolódnak. A monitor ezt úgy kerüli meg, hogy az ilyen útvonalakat szabványos rendszerparancsokkal (cat, test, stat) olvassa.
open_basedir a hibás. A helyes megoldás a rendszerparancsokkal való olvasás (az AIDE és a Hálózati monitor esetében ez már megvalósult). Az open_basedir kiterjesztése a /var, /proc útvonalakra nem szükséges, és kevésbé biztonságos.
A monitor a tanúsítványokat úgy ellenőrzi, hogy közvetlenül, a 443-as porton keresztül csatlakozik a domainekhez. Ha a domain magáról a szerverről nem érhető el, vagy a portot blokkolja a tűzfal, az ellenőrzés sikertelen lesz.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) és az Apache (/etc/apache2/sites-enabled/) konfigjaiból veszi, valamint a HTTP_HOST aktuális hosztjából.
A monitor a config.php fájlban megadott felhasználóval csatlakozik a MySQL-hez, akinek csak a saját adatbázisához van hozzáférése. A MySQL az information_schema táblában csak a jogosultsággal rendelkező adatbázisokat mutatja — ezért a többi nem látszik.
Ahhoz, hogy a monitor minden adatbázist lásson, adjon ennek a felhasználónak csak olvasási jogot (egyszer, rootként; helyettesítse be a config.php fájlban szereplő felhasználónevet):
sudo mysql parancsot nem használ: az adatbázisok listáját a saját PDO-kapcsolatán keresztül kéri le.
A PostgreSQL a postgres felhasználói szintű hozzáférést igényli, amellyel a panel webes felhasználója nem rendelkezik. A széles jogkörű sudo psql PHP-ből való megnyitása nem biztonságos — ehelyett a panel egy szűk, paraméter nélküli burkolót hív meg, amely csak a verziót, a kapcsolatok számát és az adatbázisok listáját írja ki a méretükkel. Hozza létre:
monitor-pgstat sort a sudoersből (a kézi telepítés 13. lépése), és magát a szkriptet se hozza létre: a PostgreSQL kártya egyszerűen inaktív marad.
A vezérlőpult megmutatja, mi történik; alább az áll, mi a teendő tipikus helyzetekben. Az általános elv: ne essen pánikba, vesse össze a jogszerű tevékenységgel (saját műveletek, frissítések, biztonsági mentések), és a súlyosság szerint reagáljon.
ignoreip listában./etc és a /usr/share könyvtáron kívül) — potenciális manipuláció. Ellenőrizze a csomagot: debsums PACKAGE_NAME, kétség esetén telepítse újra (apt install --reinstall).127.0.0.1 címhez, vagy zárja le a portot az UFW-ben. Ez valós biztonsági rés.certbot renew parancsot vagy a beállításokat a vezérlőpulton).sudo apt update && sudo apt upgrade; a kernel frissítése után indítsa újra a szervert.