Dolibarr fájlintegritás: az ERP saját ujjlenyomat-ellenőrzése
Az ERP, amely ellenőrzi a saját ujjlenyomatát: a Dolibarr rejtett biztonsági próbája
A Dolibarr össze tudja vetni a telepített programfájlokat a hivatalos kiadás ellenőrző adataival. Mire jó egy eltéréslista, és miért nem jelent önmagában feltörést?
Egy ERP-ben nemcsak az adat változhat meg. Maga a programkód is eltérhet attól, amit eredetileg telepítettünk. Maradhat ott egy régi fájl frissítés után, felülírhat valamit egy kézi javítás, hibás lehet a másolás — rosszabb esetben pedig illetéktelen módosítás történhet. A Dolibarr egyik kevéssé ismert adminisztrációs eszköze éppen ezt teszi láthatóvá: digitális ujjlenyomat alapján összeveti a telepített programfájlokat a hivatalos kiadással.
Az integritásvizsgálat azt mutatja meg, hogy egy vizsgált fájl hiányzik vagy tartalma eltér a hivatalos referenciafájltól. Az okot nem dönti el helyettünk: a találat lehet engedélyezett testreszabás, hibás frissítés vagy kivizsgálandó esemény is.
Mi az a fájl „ujjlenyomata”?
A kiadási folyamat során a Dolibarr minden hivatalos verzióhoz fájllistát készít. A listában a programfájlokhoz ellenőrzőösszeg tartozik: ha akár egyetlen bájt megváltozik, az újonnan számított érték már nem egyezik a kiadáskor rögzített referenciával. A hivatalos leírás szerint a csomagok és a referenciafájl ugyanannak az automatizált kiadási folyamatnak a részei, a referencia pedig a Dolibarr szerverére is felkerül.
Az adminisztrátor a Rendszereszközök → A Dolibarr névjegye → Integritás ellenőrzése útvonalon indíthatja el az összehasonlítást. A pontos felirat a használt nyelvtől és verziótól eltérhet.
Miért érdekes ez egy vállalkozásnak?
| Helyzet | Mit jelezhet az eltérés? | Mi legyen a következő lépés? |
|---|---|---|
| Verziófrissítés után | Régi, hiányzó vagy nem megfelelően felülírt programfájlt. | Vessük össze a telepítési naplóval és a hivatalos csomaggal; az éles rendszer előtt tesztpéldányon javítsunk. |
| Megmagyarázhatatlan működésnél | Nem dokumentált kézi módosítást vagy sérült fájlt. | Rögzítsük az eltérést, az időpontot és az érintett verziót, majd vizsgáljuk meg a változás eredetét. |
| Biztonsági incidens gyanújánál | Olyan kódváltozást, amely további vizsgálatot indokol. | Ne írjuk felül azonnal a bizonyítékot; izoláljunk, őrizzük meg a naplókat és vonjunk be szakértőt. |
| Egyedi fejlesztésnél | Szándékos core-módosítást, amely frissítéskor elveszhet. | Dokumentáljuk, majd lehetőség szerint helyezzük át támogatott modulba, hookba vagy sablonba. |
A legérdekesebb eredmény nem mindig a zöld pipa
Egy eltéréslista valójában a rendszer történetét meséli el. Ha egy telepítésen sok alapfájl módosult, az nem feltétlenül támadás, de erős jelzés arra, hogy a rendszer nehezen frissíthető és a változások eredete nem elég jól követett. A tiszta vagy dokumentált eredmény ezért nemcsak biztonsági, hanem karbantarthatósági bizonyíték is.
Különösen fontos a különbség az alaprendszer és a helyi tartalom között. A dokumentumtár, a konfiguráció, az adatbázis és a külső modulok nem ugyanazt a kérdést válaszolják meg, mint a hivatalos programfájlok ellenőrzése. Az integritásteszt tehát nem igazolja, hogy az üzleti adatok helyesek, a jogosultságok megfelelőek vagy a szerver kompromittálatlan.
Öt szabály a helyes használathoz
- Rögzítsük a pontos verziót. Csak a megfelelő kiadás referenciájával van értelme összehasonlítani.
- Ismert állapotban készítsünk alapmérést. Telepítés vagy ellenőrzött frissítés után mentsük el a dátumot és az eredményt.
- Futtassuk változás után. Frissítés, kézi fájlmásolás, incidensgyanú vagy váratlan működés után különösen hasznos.
- Ne töröljünk vakon. Előbb állapítsuk meg, hogy hivatalos fájlról, saját modulról, generált állományról vagy bizonyítékról van-e szó.
- Ne tekintsük teljes biztonsági auditnak. Naplóvizsgálat, hozzáférések, frissítések, mentések és szerveroldali kontrollok ugyanúgy szükségesek.
Egy különösen fontos mellékhatás: láthatóvá válik a core hack
A közvetlenül módosított Dolibarr-alapfájl rövid távon gyors megoldásnak tűnhet, hosszú távon azonban frissítési konfliktust és nehezen auditálható működést okoz. Ha az integritásvizsgálat szándékos eltéréseket sorol, az jó alkalom a technikai adósság leltározására: miért történt a módosítás, ki hagyta jóvá, mely verziót érinti, és kiváltható-e támogatott bővítési ponttal.
Az érintett fájl azonnali lecserélése eltüntetheti a vizsgálathoz szükséges nyomot. Előbb korlátozzuk a hozzáférést, készítsünk bizonyítható másolatot és gyűjtsük össze a releváns web-, rendszer- és alkalmazásnaplókat.
A tanulság
A Dolibarr integritásvizsgálata nem látványos új ERP-modul, mégis sokat mond egy telepítés minőségéről. Egyetlen ellenőrzéssel közelebb kerülhetünk három kérdéshez: az fut-e, amit telepíteni akartunk; dokumentáltak-e a helyi változtatások; és van-e olyan eltérés, amelyet biztonsági eseményként kell kezelni?
A legjobb időpont az első ellenőrzésre nem akkor van, amikor már bajt sejtünk, hanem egy ismert, tiszta állapot létrehozása után. Így a következő eltérésnek lesz mihez viszonyulnia.
Források és további olvasnivaló
- Dolibarr Wiki: hivatalos kiadási folyamat, fájllista és integritás-ellenőrzés
- Dolibarr.org: stabil kiadások hivatalos fájllistái és ellenőrző adatai
- Dolibarr GitHub: hivatalos kiadások és verziócímkék
- Dolibarr Wiki: verziók, dátumok és kompatibilitás
Forrásállapot: 2026. szeptember 9. A funkció a Dolibarr hivatalos programfájljainak eltérését vizsgálja; nem helyettesíti a kártevőkeresést, az incidensvizsgálatot, az adatbázis-ellenőrzést vagy a mentést.
Nézze meg, milyen Dolibarr-folyamat illeszkedhet a vállalkozásához, vagy küldje el röviden a saját helyzetét.
Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.