Ez az útmutató az Arcivéo Security 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 Security 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.
Kétféle ütem. A panel oldalai megnyitáskor kérdezik le az eszközöket — mindig az aktuális állapotot látja. Emellett ütemezetten (cron) háttérfeladatok is futnak:
A feladatok teljes listája az „Az összes cron-feladat egy helyen” fejezetben található.
A pontszám a maximumról indul, és minden feltárt problémáért csökken:
PermitRootLogin yes) — −20PasswordAuthentication yes) — −10X11Forwarding, 3-nál nagyobb MaxAuthTries, vagy minden fiók számára olvasható sshd_config — −5TRACE metódus, vagy hiányzik a Strict-Transport-Security vagy az X-Frame-Options fejléc — −5Eredmé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.
Négy csatorna van: Telegram, e-mail, webhook és push a böngészőben. Egymástól függetlenek — bármelyiket bekapcsolhatja, akár mind a négyet. Ugyanezeken a csatornákon megy a napi biztonsági jelentés, a terhelési riasztások és az eseményérzékelő találatai; egyszer kell beállítani őket, itt, a „Beállítások” részben.
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.Webhook. Egyetlen POST-ot fogadó cím lefedi a Slacket, a Discordot, a Mattermostot, az n8n-t és a saját kezelőjét is. „Beállítások” → Webhook: illessze be a címet, és kapcsolja be a kapcsolót.
{"text": …} alakot kapja, a Discord a {"content": …} alakot (a Discord elutasítja a 2000 karakternél hosszabb üzeneteket, ezért a szöveg rövidül);text, event, severity, source, count, host, ts — az üzenet szövegét nem kell újra elemezni.Push értesítések. Az üzenet közvetlenül a böngészőbe érkezik, és ha a panel fel van véve a telefon kezdőképernyőjére, közönséges alkalmazásértesítésként — bot és levelezőkiszolgáló nélkül. „Beállítások” → Push értesítések: kapcsolja be a kapcsolót, és minden eszközön, amelyiknek értesítést kell kapnia, nyomja meg az „Eszköz csatlakoztatása” gombot. A „Csatlakoztatott eszközök” számláló mutatja, hány van.
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.
A panelt jelszavas bejelentkezés védi, és — ha be van kapcsolva — az IP-szűrő. Egy programnak egyik sem felel meg, ezért a külső rendszerek saját bejáratot kapnak: két csak olvasható címet, tokennel védve. A token semmit sem változtat a kiszolgálón: kizárólag adatok lekérésére jó.
Bekapcsolás — „Beállítások” → „Csak olvasható API”: a „Kapcsolja be az API-t” kapcsoló; a token az első mentéskor automatikusan létrejön. Az „Új token” gomb másikat ad ki, és ugyanabban a pillanatban lekapcsol mindenkit, aki a korábbit használta.
/api/status.php — JSON: biztonsági pontszám, a modulok állapota, a legutóbbi terhelési mérés a legterhelőbb folyamatokkal, valamint az elmúlt 24 óra biztonsági eseményei;/api/metrics.php — ugyanezek a számok a Prometheus szöveges formátumában (arciveo_* mérőszámok: arciveo_security_score, arciveo_fail2ban_banned, arciveo_cpu_busy_pct és így tovább).Ha az Ön kliense nem tud fejlécet küldeni, a token paraméterként is elfogadott — ?token=…. Vegye figyelembe, hogy ebben a formában bekerül a webkiszolgáló hozzáférési naplójába, ezért a fejléc a jobb megoldás.
Prometheus. Kész blokk a scrape_configs részhez:
api disabled szöveggel — az API ki van kapcsolva a beállításokban. Az elutasított kéréseket a rendszer a küldő IP-címével együtt az alkalmazásnaplóba írja, így a token találgatása látszik az „Alkalmazásnaplók” oldalon.
A panel kiszolgálónként települ, és arra a kérdésre, hogy „hogy áll ez a gép”, jól válaszol. Arra, hogy „hogy áll az összes gépem”, nem — ezért minden panel küldhet rövid összefoglalót az ügyfélfiókba, ahol a kiszolgálók egyetlen listában látszanak.
Amit az ügyfélfiókban kell elővenni my.arciveo.com → „Kiszolgálóim” rész: itt kap egy tokent (fk_… alakban), és itt szerepel a fogadó címe: https://my.arciveo.com/api/fleet.php. A token fiókonként egy — minden kiszolgálójához ugyanaz.
Amit a panelen kell beállítani — „Beállítások” → „Kiszolgálók áttekintése”: a fogadó címe, a token, a kiszolgáló neve (ahogy a listában megjelenik; üresen hagyva a panel domainje kerül oda) és az „Összefoglaló küldése” kapcsoló. A „Küldés most” gomb azonnal ellenőrzi a kapcsolatot, az ütemezés bevárása nélkül.
Ezután az összefoglaló cronnal megy ki, 15 percenként:
Pontosan mi megy ki: a kiszolgáló neve és domainje, az operációs rendszer, az üzemidő, a PHP verziója; a biztonsági pontszám; a modulok állapota (UFW, a Fail2ban jailek száma, a mai tiltások, fut-e a CrowdSec, a Suricata és a Falco, ClamAV-fenyegetések, AIDE-változások, Lynis-index, várakozó frissítések, szükséges-e újraindítás, hány nap van a tanúsítvány lejártáig, a veszélyesen nyitott portok száma); a legutóbbi terhelési mérés (load, CPU, RAM, lemez, inode); az elmúlt 24 óra eseményszámlálói és a legutóbbi kritikus esemény. Naplók, jelszavak és fájltartalom nincs az összefoglalóban.
sudo crontab -l), és hogy mit válaszol a „Küldés most” gomb. A küldési hibák FLEET jelöléssel kerülnek az alkalmazásnaplóba — ott látszik, hogy a tokent utasították-e el (HTTP 401), vagy maga a kapcsolat nem jött létre.
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 alapértelmezett a 24 órás ablak: a felső gombokkal 7 napra vagy 30 napra válthat.
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.
Két tárolási mélység. A „nyers” ötperces pillanatképek egy napig élnek (plusz egy óra tartalék, hogy a grafikon legrégebbi pontjának legyen még elődje a számításhoz). Minden befejezett óra egyetlen sorrá záródik össze; ezt az órás sort 30 napig őrzi a rendszer, és éppen ezt olvassa a „7 nap” és a „30 nap” nézet. Egy hónapnyi előzmény így körülbelül 720 sorba kerül nagyjából 8600 helyett.
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.
Legterhelőbb folyamatok. A grafikonok alatt két táblázat áll az öt legtöbb CPU-t fogyasztó folyamattal:
Mindkét táblázat mindig az elmúlt 24 órát írja le, akkor is, ha a grafikonok egy hónapot mutatnak: folyamat-pillanatképet csak az ötperces sorok hordoznak, azok pedig nem maradnak meg egy napnál tovább.
ps, a gyűjtő PHP-szkript és a fölötte lévő cron/sudo lánc) kimaradnak a listából — különben minden pillanatkép élén állnának: a ps az indulás pillanatában közel 100 % CPU-t mutat. Az ugyanabban a percben futó többi cron-feladat viszont megjelenik — éppen ezért van a táblázat.
Terhelési riasztások („Beállítások” → „Terhelési riasztások” rész) — a CPU/RAM/lemez/inode küszöb túllépésekor a panel minden bekapcsolt csatornán értesítést küld (Telegram, e-mail, webhook, push — ugyanazok, mint a napi jelentésnél; a riasztásokhoz külön semmit sem kell bekapcsolni), majd még egyet, amikor a mérőszám visszatér a normális tartományba. Amíg a küszöb fennáll, nem küld újra és újra: a következő értesítés csak a „helyreállt → ismét 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 napi jelentés arra a kérdésre válaszol, hogy „hogy áll a kiszolgáló”. Az érzékelő egy másikra — „mi történt az imént”. 5 percenként lekérdezi a gyors forrásokat, és csak azt jegyzi fel, ami az előző ellenőrzés óta megváltozott; a menüben lévő „Biztonsági események” oldal mutatja a találatok listáját.
A lassú ellenőrzésekhez — Lynis, debsums, csomagfrissítések, az SSL lejárata — az érzékelő nem nyúl: ezek számai úgyis naponta egyszer változnak, és a napi jelentés hatáskörében maradnak.
Mit vesz észre — kilenc forrás:
[Priority: 1] jelölés kritikus szintre emeli a találatot;FOUND sorok a vizsgálati naplóban;root néven (kritikus) és bejelentkezés korábban nem látott címről (figyelmeztetés);Az az eszköz, amelyik nincs telepítve, vagy amelyiknek a naplóját a panel nem tudja olvasni, egyszerűen hallgat — ez nem hiba és nem esemény.
data/secwatch_state.json fájl), és az első futás csak ezt a jelölést írja ki. Különben a figyelés bekapcsolásakor mindarról értesítés érkezne, amit a naplók hónapok alatt felhalmoztak.
Beállítás — „Beállítások” → „Események figyelése”:
23-7 formátumú ablak, amely alatt a figyelmeztetések nem mennek ki.Az értesítések ugyanazokon a csatornákon mennek, mint a napi jelentés (Telegram, e-mail, webhook, push) — külön semmit sem kell bekapcsolni. Minden találat bekerül a listába attól függetlenül, hogy ment-e értesítés, és 90 napig megmarad.
Az eseménylista. Szűrők: időszak (24 óra, 7, 30 vagy 90 nap), fontosság és forrás; az utolsó 500 bejegyzés látszik. Az „Ellenőrzés most” gomb pontosan ugyanazt a menetet indítja, mint a cron — közvetlenül a beállítás után hasznos, hogy ne kelljen öt percet várni; meg is nevezi az okot, ha nem ment ki értesítés („a fontossági küszöb alatt”, „csendes órák”, „nincs beállítva értesítési csatorna”). A menüpont melletti piros számláló az elmúlt 24 óra kritikus eseményeinek száma.
A cím adatlapja. Az eseménylista egy sorára vagy az Összefüggő címek blokk egy sorára kattintva megnyílik minden, ami egy címről tudható: eseményeinek időrendje, az ország, és az első sorban a következtetés. A lista sora akkor nyitja meg az adatlapot, ha az esemény pontosan egy címhez tartozik; ha többet nevez meg, a soron belüli címek a hivatkozások. Négyféle következtetés van:
Az időrend alatt a Mi történt a kiszolgálón ugyanekkor blokk áll: olyan események, amelyeknek egyáltalán nincs címük. Az AIDE nem tudja, ki módosította a fájlt, a ClamAV nem tudja, ki hozta a fertőzöttet. Azok látszanak, amelyek a cím tevékenységének idejére és az azt követő hat órára esnek. Épp a bejelentkezés és az utána történtek együtt választják el a kísérletet a tényleges hozzáféréstől.
Ütemezés. A feladat a root crontabjába kerül (sudo crontab -e), a mérésgyűjtéshez képest 2 perccel eltolva, hogy a kettő ne induljon egyszerre:
php cron/security_watch.php paranccsal. A wrapper megtalálja a panel összes telepítését a kiszolgálón, és a webhely tulajdonosának nevében indítja az ellenőrzést — pontosan azokkal a sudo jogokkal, amelyeket a panel a webről használ. A root crontabjából indított közvetlen hívás root tulajdonú data/secwatch_state.json állapotfájlt hozna létre, és az „Ellenőrzés most” gomb működésképtelenné válna.
A „Webkiszolgáló” oldal a hozzáférési naplót elemzi, és megmutatja, hány kérés érkezett, ezek mekkora része végződött hibával, és ki küldte őket. A ModSecurity arra válaszol, hogy „mi lett blokkolva”, ez az oldal arra, hogy „mi jutott el egyáltalán a webhelyre”.
Ami látszik: a kérések száma, RPS, a hibaarány, külön 5xx számláló és a kiszolgált adatmennyiség; óránkénti kérésgrafikon; a 2xx/3xx/4xx/5xx kódok megoszlása; gyakori címek, gyakori IP-k, gyakori hibák (kód és útvonal) és kliensek (User-Agent). Az időszak: 24 óra vagy 7 nap.
A forrás a combined formátumú hozzáférési napló, így az Nginx és az Apache is megfelel, és nem kell hozzá külön modul. A panel a szabványos fájlok között keresi a naplót:
/var/log/nginx/access.log/var/log/apache2/access.log/var/log/apache2/other_vhosts_access.log/var/log/httpd/access_logEzeken kívül a panel átnézi a *access*.log és *requests*.log nevű fájlokat a /var/log/nginx/, /var/log/apache2/ és /var/log/httpd/ könyvtárban. Így megtalálja azt a naplót is, amelyet egy webhely a CustomLog direktívával saját fájlba ír — például az arciveo-monitor_requests.log fájlt, amelyet az Arcivéo telepítője hoz létre.
Csak egy napló olvasódik be: ha az Nginx az Apache előtt áll, két napló összeadása minden kérést kétszer számolna. A panel a fenti lista első olyan naplóját veszi, amelybe az elmúlt egy napban írtak (a névminta alapján találtakat utána próbálja, a legfrissebbel kezdve); ha egy napja egyikbe sem írtak, a legutóbb módosult nem üres naplót. Így a logrotate által kiürített vagy egy leállított webkiszolgálóról ott maradt napló nem takarja el az élőt. A napló utolsó szakasza olvasódik be (3 MB), az eredmény pedig 5 percig gyorsítótárban marad — terhelt webhelyen ezért előfordulhat, hogy a választott időszak nincs teljesen lefedve; a ténylegesen elért lefedettség a grafikon fölött olvasható.
adm csoporté, a webfelhasználó pedig nincs benne. Az Arcivéo telepítője felveszi őt ebbe a csoportba; kézi telepítés után egy apró, roothoz tartozó wrapper segít, amelynek pontosan egyet szabad — kiírni a naplót (a ModSecurity oldala ugyanígy működik). A wrapper ugyanazokkal a szabályokkal választja ki a naplót, mint a panel. A parancs magán az oldalon is megjelenik; itt is. Illessze be egészben — ez egyetlen parancs:
A webfelhasználó eltérhet a www-data felhasználótól — ellenőrizze, melyik felhasználóval fut a webhely PHP-FPM készlete (ps -o user= -C php-fpm), és írja be a sudoers sorába. Ha a napló nevében sem access, sem requests nem szerepel, írja be az útvonalát a wrapperben az L=… sor elejére.
Ismert sebezhetőségek kihasználási kísérletei. A panel a napló kéréseit mintegy húsz elterjedt exploit aláírásával veti össze: PHP-CGI, könyvtárbejárás az Apache-ban, PHPUnit, Log4Shell, routerek, kamerák és VPN-átjárók hibái. Minden kísérletnél megmondja, működhet-e ezen a szerveren, és tényekre támaszkodik: a telepített Apache- és PHP-verzióra, a Java meglétére és arra a válaszkódra, amellyel a szerver a fájlkérésre felelt. Pirossal csak az van jelölve, ami tényleg működhet.
A webszerver védelme. A panel a szerver minden oldalát lekéri a 127.0.0.1 címen keresztül, és megnézi, mit kap a látogató: látható-e a webszerver és a PHP verziója, be van-e kapcsolva a TRACE metódus, és megvannak-e a Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy és Content-Security-Policy védőfejlécek. Az oldalak a panel megnyitási címéből és a virtuális hosztok fájljaiból származnak, ha a panel olvasni tudja őket. Az eredmény 10 percenként frissül.
Ha valami hiányzik, a táblázat alatt egyetlen parancs jelenik meg. Külön zz-arciveo-hardening.conf fájlt hoz létre, és a webszervert csak sikeres konfigurációs teszt után tölti újra; az oldal által már küldött fejlécek nem duplázódnak. A CSP-t nem ajánlja egy sorként: a szabályzatot az adott oldalhoz kell összeállítani, különben az oldal nem tölti be a saját szkriptjeit, stílusait és betűtípusait. A módosítás visszavonása Apache alatt:
ServerSignature) a panel nem jelöli, ha a webszerver verziója már rejtve van: verzió nélkül csak a szerver nevét és a hosztnevet mutatja.
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.A panel már működik, és ugyanezen a szerveren szükség van még egy webhelyre — saját domainnel a monitor mellett. Az automatikus telepítés után a szerver egy szokásos Apache + PHP-FPM gép, így a webhelynek három dolog kell: saját könyvtár, saját vhost és saját tanúsítvány. A panelhez közben nem nyúlunk: az egész szervert figyeli, a második domainhez nem kell második példány.
site2.example.com az új webhely címe. Ez lehet külön domain (mycompany.com) és aldomain (shop.mycompany.com) is — az Apache-nak mindegy, csak a DNS-rekord (1. lépés) és a tanúsítvány kiállítása (5. lépés) tér el. A site2 csupán a webhely rövid neve: így hívják a /var/www/site2 könyvtárat és a site2.conf konfigurációs fájlt. A domainhez semmi köze, az Apache a címet kizárólag a ServerName értékéből veszi; a név bármi lehet — a shop.mycompany.com esetén például kényelmes a shop: könyvtár /var/www/shop, konfiguráció shop.conf.
1. DNS. A domain regisztrátorának DNS-felületén hozzon létre egy A rekordot a szerver IP-címére:
Néhány perc múlva ellenőrizze: a dig +short site2.example.com a szerver IP-címét kell visszaadja.
2. A webhely könyvtára.
3. A vhost. A blokkot egészben illessze be a terminálba — a PHP-FPM socket útvonalát a szkript magától megállapítja:
4. Kapcsolja be a webhelyet, és újratöltés előtt ellenőrizze a konfigurációt:
5. SSL. A certbot-ot az automatikus telepítés már feltette; ekkorra a DNS-nek már a szerverre kell mutatnia:
A harmadik és a további domaineket ugyanígy veheti fel — ismételje meg az 1–5. lépést más domainnel és könyvtárral.
Host egyetlen ServerName értékkel sem egyezik (IP-címmel való megnyitás vagy a szerverére irányított idegen domain), az Apache a /etc/apache2/sites-enabled/ könyvtárból az ábécésorrendben első bekapcsolt webhelyet szolgálja ki. A gyári 000-default webhelyet az automatikus telepítés kikapcsolja, így ez az „ügyeletes” szerep a panel vhostjánál (arciveo-monitor.conf) marad — a saját nevükön megnyitott webhelyeket ez nem érinti. Ha IP-címmel más webhelynek kell megnyílnia, nevezze el a fájlját úgy, hogy ábécésorrendben előrébb kerüljön (például 000-site2.conf).
site2_error.log és site2_access.log a /var/log/apache2/ könyvtárban.
.htaccess vezérli (front controller), és egy beágyazott webhely nem azt szolgálná ki, amit várna. Tartsa a webhelyeket egymás mellett: /var/www/monitor, /var/www/site2.
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;security-watch-all.sh → /usr/local/bin/ (chmod +x) — a panel cron/security_watch.php szkriptjét a webhely tulajdonosának nevében futtatja („Biztonsági események” oldal, a fenti crontab 2-57/5 sora); a security_watch.php már a panel része, külön telepíteni nem kell;fleet-push-all.sh → /usr/local/bin/ (chmod +x) — a kiszolgáló összefoglalóját küldi az ügyfélfiókba a panel cron/fleet_push.php szkriptjén keresztül (a fenti 3,18,33,48 sor);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.