Ubuntu szerver logolás (Fossa)
Az Ubuntu Fossa egy systemd System and Service Manager alapú disztribúció, amely a rendszereseményeket egy bináris adatbázisban (journal) rögzíti és ennek feldolgozására számos lehetőséget ad. Noha valószínűleg sokkal hatékonyabb lenne a releváns eseményeket magából az adatbázisból kiválogattatni, ebben a leírásban kihasználjuk, hogy az eseményeket a systemd képes a syslog-nak feladni, így a naplózást a régi megközelítésnek megfelelően a syslog-ng-vel végeztetjük, és a logokat a logcheck-kel figyeljük. Nem használunk naplószervert, az értesítéseket email-ben küldjük el.
Tartalomjegyzék
Elvi megfontolások
Megjegyzés: 2017-es szöveg, ellenőrizni: TODO!
A systemd naplózó szolgáltatása elvileg feleslegessé teszi a hagyományos, szövegállományokra bontott naplók kezelését. A systemd journal jól strukturált, tömörített, tagelt és indexelt bináris adatbázis, melynek kezelésére hatékony eszköz áll rendelkezésre (journalctl). A szöveges naplózásról erre történő áttéréshez azonban - szerintem - az alábbi fejlesztésekre lenne szükség (TODO!):
- hatékony együttműködés a sok naplóbejegyzést termelő, eleddig fájlokba dolgozó szolgáltatások (pl. Apache webszerver) és a systemd naplózó szolgáltatása között. Lehetséges, hogy a journaling nagy terhelés esetén sem számottevő jelentős többlet erőforrást, ezt azonban meg kellene vizsgálni.
- a hagyományos logrotate konfigurációkban megfogalmazotthoz hasonló policy, amely a különféle jellegű naplóesemények megőrzésének idejét szabályozza. Jelenleg a journal egyszerűen perzisztenssé tehető (alapértelmezésben a /run hierarchiában keletkezik, így minden rendszerindításkor kiürül), de számára csak egy általános méretkorlát van beállítva. Nyilvánvaló, hogy a méretkorláton belül különböző mennyiségű (visszamenőlegességű) tűzfal- webszerver-, smtp-, stb. log megtartása lenne szükséges, és ez biztosan be is állítható, azonban ezek a beállítások az Ubuntu terjesztésnek (még) nem részei.
- a (közel) valós idejű értesítésekért felelős logcheck átalakítása úgy, hogy ne csak natív szöveges állományokat, hanem a journalctl segítségével(?) a journal-ből kinyert adatokat is tudjon elemezni. Léteznek erre a célra a logcheck-től független parser projektek is (ld. pl. itt), illetve valószínűnek tartom, hogy a valós idejű értesítés külön eszköz nélkül, magában a journal kezelőben is definiálható(? lesz?), de ezek az eszközök és beállítások az Ubuntu terjesztésnek (még) nem részei.
Amíg a fentiek problémát jelentenek, célszerűbbnek tűnik a szöveges naplózás megtartása, kihasználva azt, hogy a systemd a telepített, hagyományos syslogd (rsyslogd, syslog-ng, stb.) számára képes az általa kezelt eseményeket feladni, vagyis a journaling a rendszernapló szolgáltatás számára (közel) transzparens lehet.
A naplóbejegyzéseket adatként kezelve, azok kiértékelése (pl. adatbázis-lekérdezésekkel) sokkal hatékonyabb, mint lenne szöveges kezelés esetén (olvasás, parse-olás). Több gépes környezetben érdemes egy külön egységet dedikálni (naplószerver), amely megkapja az összes gép figyelt gép naplóadatait, és ezeket egységben képes kezelni. Ezen a gépen futtathatóak automatikus logelemző eszközök, riasztáskezelő vagy automatikus beavatkozó megoldások is, amelyeket nem feltétlenül érdemes minden figyelt gépre külön-külön telepíteni (pl. erőforrás-igényük miatt).
Ebben a leírásban arra az esetre javaslok megoldást, amikor nincsen naplószerver, illetve strukturált adatelemzés (pl. mert standalone gépet telepítünk). Ilyenkor - jobb híján - a szöveges napló szövegét helyben próbáljuk kielemeztetni valamilyen mintakereső eszközzel (a logcheck reguláris kifejezéseket használ a vélhetőleg fontos bejegyzések kiválogatására), azonban ez a módszer by design kevésbé hatékony. A naplóbejegyzések érdemi része ugyanis szabad szöveg, amelyet a maintainer-ek szabadon bővíthetnek vagy módosíthatnak, ráadásul a nyelvi beállítások is befolyásolhatják ezeket. Semmi sem kötelezi a maintainer-t arra, hogy közzétegye programja lehetséges naplóüzeneteinek szövegét, pláne nem arra, hogy megfelelő logcheck szabályokat is készítsen hozzájuk. Úgyhogy a logcheck használata során viszonylag gyakran leszünk kénytelenek finomhangolni a szabályokat, hogy továbbra is értesüljünk a lényeges eseményekről, de ne árasszanak el bennünket felesleges riasztások.
Telepítés
A szükséges komponenseket a szokásos módon telepítjük:
apt install syslog-ng logcheck logcheck-database # +: dependens könyvtárak (sok!) és Python (ha még nincs telepítve)
A fenti művelet eltávolítja az alapértelmezett rsyslog-ot, helyette a syslog-ng lesz az alapértelmezett naplózó démon. Az Ubuntu Fossa-ban a journal feladása alapértelmezetten be van állítva, így a syslog-ng a korábbi Ubuntu terjesztésekkel analóg módon működik.
Annak érdekében, hogy a /etc/syslog-ng/conf.d-ben később teljes értékű overlay állományokat helyezhessünk el, módosítsuk a /etc/syslog-ng.conf állományt, és helyezzük át az inklúziót a fájl végéről a log szekció elé:
-rw-r--r-- root root /etc/syslog-ng/syslog-ng.conf [...] ### # Include all config files in /etc/syslog-ng/conf.d/ ### @include "/etc/syslog-ng/conf.d/*.conf" ######################## # Log paths ######################## [...]
Logrotate módosítások
A rotáláskor a logrotate megkísérel lefuttatni egy scriptet a /tmp-ben. Mivel a biztonsági házirendünk szerint a /tmp nem lesz futtatható, ez hibát okoz. Ezért a root nevében lefutó logrotate számára a /etc alatt létrehozunk egy logrotate.tmp könyvtárat:
mkdir /etc/logrotate.tmp
és a logrotate számára előírjuk ennek használatát:
-rwxr-xr-x root root /etc/cron.daily/logrotate [...] export TMPDIR=/etc/logrotate.tmp [...]
Logcheck
A logcheck lényegében egy cron-ból futtatott script, amely az utolsó futtatása óta készült logrészleteket összehasonlítja megadott reguláris kifejezésekkel, és az egyezéseket kigyűjtve (az előírtak figyelmen kívül hagyásával), email-ben elküldi.
Beállítások
Telepítés után a logcheck.conf-ot teljesen cseréljük le:
mv /etc/logcheck/logcheck.conf /etc/logcheck/logcheck.conf.bak touch /etc/logcheck/logcheck.conf; chown root:logcheck /etc/logcheck/logcheck.conf; chmod 640 /etc/logcheck/logcheck.conf mcedit /etc/logcheck/logcheck.conf
Az új állomány beállításai:
-rw-r----- root logcheck /etc/logcheck/logcheck.conf # Logcheck custom settings # Filtering rules from ignore.d.server REPORTLEVEL="server" # Mail goes to the local administrator SENDMAILTO="root" # The hostname in the subject of generated mails should be fully qualified FQDN=1 # Controls [logcheck] prefix on Subject: lines ADDTAG="yes"
Egy új (.logfiles kiterjesztésű!), overlay állományban írjuk elő, hogy az alapértelmezetteken kívül a logcheck figyelje a kern.log-ot és a messages-t is:
touch /etc/logcheck/logcheck.logfiles.d/additional.logfiles chown root:logcheck /etc/logcheck/logcheck.logfiles.d/additional.logfiles chmod 640 /etc/logcheck/logcheck.logfiles.d/additional.logfiles mcedit /etc/logcheck/logcheck.logfiles.d/additional.logfiles
-rw-r----- root logcheck /etc/logcheck/logcheck.logfiles.d/additional.logfiles /var/log/kern.log /var/log/messages
Reboot-kor, és normális üzemben 5 percenként fusson le az ellenőrzés (idő módosítása):
-rw-r--r-- root root /etc/cron.d/logcheck
# /etc/cron.d/logcheck: crontab entries for the logcheck package
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
@reboot logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
0-59/5 * * * * logcheck if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi
# EOF Megjegyzés: a maintainer óránként, vagy még ritkábban futtatja a logcheck-et. Ha az erőforrások megengedik, talán érdemes ezt gyakoribbra venni egy esetleges illegális távoli bejelentkezés vagy más biztonsági esemény korai jelzése érdekében. Ez kevesebb időt hagy a behatolónak arra is, hogy root jogot szerezve leállítsa a riasztást.
Végül szigorítsuk meg a jelenleg eléggé liberális jogosultságokat a beállítások könyvtárában:
chmod -R o-rwx /etc/logcheck
Szabályok
A figyelmen kívül hagyandó logbejegyzésekre passzoló reguláris kifejezéseket a /etc/logcheck/ignore.d.server alatti kivétel állományok tartalmazzák, míg a mindenképpen jelentendő eseményeket a etc/logcheck/cracking.d vagy /etc/logcheck/violations.d állományokban lehet definiálni. A logcheck telepítésekor kapunk egy szabálykészletet, amely azonban még mindig nagyon sok, számunkra érdektelen logbejegyzést átenged. További szabályokért töltsük le a legfrissebb logcheck-rules-fix tarballt, és a könyvtárszerkezet megtartásával csomagoljuk ki.
Az ebben szereplő szabályok (*-fix állományok) közül az alábbiakra csak speciális esetekben van szükség (de rutinszerű meghagyásuk nem hiba):
- kernel-apipa-fix - DHCP-vel kiszolgált hálózaton lévő gép szerver esetén az automatic private IP address (169.254.0.0/16 B osztály) alhálózat forgalmát nem jelenti;
- kernel-martians-fix - Osztott hálózaton lévő gép esetén "marslakó" (martian source/destination) broadcast-okat nem jelenti;
- dhcp-fix - DHCP szerver esetén a nem IP-vel hanem hostnévvel hivatkozást nem jelenti.
Bármely szabályállományt szabadon szerkeszthetjük, illetve módosíthatjuk, azonban érdemes saját szabályállományokat használni egy esetleges jövőbeni csomagfrissítéssel ütközés elkerülése érdekében. A szabálymódosítások a logcheck következő lefutásakor azonnal érvényesülnek (semmit nem kell újraindítani).
Tesztelési tippek
Saját szabályok teszteléséhez használható tippek (innen: Configure logcheck - thx!):
- Nézzük meg, hogy egy szabályokat tartalmazó állomány milyen üzeneteket fog el (helyettesítsük be a tesztelendő fájlnevet!):
egrep -f /etc/logcheck/ignore.d.server/[FILE] /var/log/syslog # illetve, amelyik naplót teszteljük
- A logcheck manuális indítása:
su -s /bin/bash -c "/usr/sbin/logcheck" logcheck
