Hogyan gyűjtsünk és elemezzünk rendszer naplókat Sysmon és PowerShell segítségével?

A Windows rendszerek naplózási képességei kulcsfontosságúak az informatikai biztonság terén, hiszen ezek segítségével nyomon követhetjük a rendszerben végbemenő eseményeket, aktivitásokat. A Sysmon és a PowerShell események gyűjtése egyaránt alapvető a hatékony védekezéshez és a biztonsági incidensek gyors felismeréséhez. A következőkben bemutatjuk, hogyan konfigurálhatjuk ezeket a forrásokat, hogy azok a naplókat más biztonsági eszközökhöz továbbíthassuk.

A Winlogbeat segítségével az eseménynaplók Logstash-ba történő továbbítását már beállítottuk. Ez a beállítás biztosítja, hogy a rendszer a különböző Windows naplókat, mint például a Sysmon és PowerShell eseményeket, megfelelő módon gyűjtse és továbbítsa. Az ilyen típusú naplók összegyűjtése kiemelkedő fontosságú a védelem szempontjából, mivel az információk sokszor segítenek a támadások nyomon követésében és azonosításában.

Sysmon telepítése és konfigurálása

A Sysmon telepítéséhez először is szükséges egy konfigurációs fájl, amely az eszközt a kívánt módon állítja be. Olaf Hartong, egy holland biztonsági kutató, egy jól karbantartott és zajmentes konfigurációt készített, amelyet a GitHub-on érhetünk el. Az "default+" sysmonconfig-with-filedelete.xml fájl letöltését követően azokat a beállításokat kell alkalmaznunk, amelyek a DNS lekérdezéseket, fájlok törlését és egyéb kritikus eseményeket naplózzák.

Miután a konfigurációs fájl a Sysmon mappájában van, a következő PowerShell parancsokkal telepíthetjük a Sysmont a rendszerre:

powershell
Copy code
PS> copy -recurse C:\Users\j\Downloads\sysmon "C:\Program Files\Sysmon"
PS> .\sysmon64.exe -i -c sysmonconfig-with-filedelete.xml -accepteula

A telepítés után nem szükséges újraindítani a Winlogbeat szolgáltatást, mivel már tartalmazza a Sysmon adatokat a konfigurációs fájlban. A Sysmon naplók továbbítása most már biztosított, így azokat más biztonsági eszközök, például Logstash, már feldolgozhatják.

PowerShell Script Block Naplók

A PowerShell script block naplók kulcsfontosságúak a PowerShell parancsok és szkriptek követésében. Az ilyen naplók lehetővé teszik, hogy azonosítsuk azokat a parancsokat, amelyeket esetleg rejtve vagy obfuszkálva próbálnak végrehajtani, hogy elkerüljék a felderítést. Az alapértelmezett beállítások nem tartalmazzák a teljes körű naplózást, ezért azt manuálisan kell engedélyezni. Ehhez egy PowerShell függvényt kell létrehoznunk, amely a következőképpen néz ki:

powershell
Copy code
PS> function Enable-PSScriptBlockLogging { 

   $basePath = @('HKLM:\Software\Policies\Microsoft' 'PowerShellCore\ScriptBlockLogging') -join '\'
   if (-not (Test-Path $basePath)) { 
     $null = New-Item $basePath -Force 
   }
   Set-ItemProperty $basePath -Name EnableScriptBlockLogging -Value "1" 
}
PS> Enable-PSScriptBlockLogging

Ezután az összes PowerShell szkriptblokk naplója elérhető lesz, és az esetleges rejtett parancsok, mint például a base64-encoded parancsok is megjelennek a naplókban. A Group Policy segítségével is engedélyezhetjük ezt a naplózást, és így a parancsok végrehajtásának nyomon követése folyamatosan biztosított lesz.

PowerShell Modul Naplók

A modul naplózást a regisztrációs adatbázisban, vagy a Group Policy segítségével is engedélyezhetjük. Az alábbi parancsokkal hozhatjuk létre a szükséges kulcsokat a regisztrációs adatbázisban:

powershell
Copy code
PS> New-Item -Path "HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell" -Name ModuleLogging -Force
PS> Set-Itemproperty -path 'HKLM:\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging' -Name 'EnableModuleLogging' -Value '1'

A PowerShell modul naplók biztosítják a teljes parancssori hívásokat és az alkalmazott paramétereket, amelyek segítenek a potenciális támadók tevékenységeinek azonosításában.

Fontos Megjegyzések

A Sysmon és PowerShell logok konfigurálása és megfelelő feldolgozása kulcsfontosságú a támadások időben történő észlelésében és a rendszer védelme szempontjából. A konfigurációk finomhangolása szükséges ahhoz, hogy a legfontosabb események rögzítésre kerüljenek, miközben elkerüljük a túlzott mennyiségű, értéktelen adat gyűjtését. Az ilyen típusú naplózás mellett ne felejtsük el a tárolási igényeket és az adatvédelmi előírásokat is figyelembe venni, mivel a naplók gyakran nagy mennyiségű érzékeny adatot tartalmazhatnak, amelyeket megfelelő biztonsági intézkedésekkel kell védeni.

Hogyan konfiguráljuk az rsyslog bemeneteit, kimeneteit és sablonjait TLS-sel, Kafka-val és helyi fájlokkal?

module(load="imtcp" streamdriver.name="ossl" streamdriver.mode="1" streamdriver.authmode="x509/name" PermittedPeer=["logstash","logstash.local"] ) input(type="imtcp" port="51443")

A fenti konfiguráció betölti az ossl stream drivert (OpenSSL-alapú). Alternatívaként a gtls modul használható GnuTLS-sel, ami támogatja a privát kulcsokhoz tartozó jelszavakat. A streamdriver.mode=1 kikényszeríti a TLS használatát; a streamdriver.authmode="x509/name" pedig érvényesíti a tanúsítványláncot és a subject-name ellenőrzést. A PermittedPeer beállítás opcionális, de lehetővé teszi megadott szerverek (IP vagy feloldható domainnév) engedélyezett listáját, további hozzáférés-szabályzáshoz. Végül az input(...) inicializálja a hallgató portot.

Kafka klaszterhez való olvasás imkafka modullal történik; a csatlakozási opciókat az input részben adjuk meg, mert ez a rész kezdeményezi a kapcsolatot – ugyanúgy, ahogy az imtcp esetén az input indít hallgatást. Példa:

module(load="imkafka") input( type="imkafka" topic="syslog" broker=[ "kafka01.local:9092","kafka02.local:9092","kafka03.local:9092" ] consumergroup="rsyslog" parsehostname="on" )

Helyi fájlok olvasására az imfile szolgál. Alapértelmezésben a facility local0 és severity notice, de fájlonként felülírhatók:

module(load="imfile") input( type="imfile" file="/var/log/myapp.log" tag="myapp:" facility="local1" severity="info" freshStartTail="on" )

A freshStartTail="on" opció biztosítja, hogy a monitorozás csak a fájl végétől induljon, így nem töltünk be történeti bejegyzéseket meglévő, nagy múltú naplókból. A tag mező határozza meg a syslog tag-et, amely a kimenetben fog szerepelni. Rsyslog képes Unix socketekről fogadni üzeneteket (imuxsock) és a kernel üzeneteket olvasni (imklog); ezek gyakran alapértelmezetten engedélyezettek az /etc/rsyslog.conf fájlban.

action( type="omfwd" protocol="tcp" target="logstash.local" port="51443" streamDriver="ossl" streamDriverMode="1" streamDriverAuthMode="x509/name" streamDriverPermittedPeers="logstash,logstash.local" template="RSYSLOG_SyslogProtocol23Format" )

Ez RFC 5424-kompatibilis üzeneteket küld a megadott célra, a template használatával. A streamDriverPermittedPeers itt vesszővel elválasztott stringként szerepel, nem tömbként.

A sablonok (templates) az igazi erejét jelentik az rsyslog-nak: minden output sablonok segítségével formáz. Előre definiált sablonok használhatók (például RSYSLOG_SyslogProtocol23Format), vagy sajátokat definiálhatunk, például régi eszközlogok átformázására vagy dinamikus fájlnevek előállítására forráshoszt alapján. A sablonok a message property-ket (pri, timestamp, hostname, syslogtag, msg stb.) használják. Példa egy egyszerű string sablonra, amely PRIVESC címkét ad a sudo eseményekhez:

template(name="stringy" type="string" string="PRIVESC::%hostname%::<%pri%>%timestamp% %hostname% %syslogtag% %msg%\n" )

Ezzel az esemény előtagja PRIVESC:: lesz, majd a hostname és a többi kivont property következik. A sablonok lehetővé teszik rugalmas kimeneti formázást és feldolgozást, amely kulcsfontosságú audit- és alerting-pipelinet építve.

Fontos: tanúsítványkezelés, kulcsjelszavak és subject-name egyezés részleteinek dokumentálása; tűzfalszabályok és portok (pl. 51443) nyitottságának ellenőrzése; Kafka fogyasztói csoportok és offset-kezelés megértése, különös tekintettel a fogyasztói csoportok újrainicializálására és offset-visszaállításokra; TLS hibakeresés (cipher-ek, tanúsítványlánc, CRL/OCSP) és naplózási szintek beállítása a problémák feltárásához; fájlolvasási beállítások mellé a log-rotáció és jogosultságok (0644 alapértelmezett, SELinux kontextusok) koordinálása; teljesítmény- és késleltetésfigyelés, backpressure-kezelés és queue-konfigurációk; és a bejövő üzenetek parszolása (RFC3164 vs RFC5424) az alkalmazások helyes mezőkinyeréséhez.

Hogyan kezeljük az eseményeket és adatokat Logstash-ban Ruby szkriptek segítségével?

A Logstash egy rendkívül sokoldalú eszköz az adatfeldolgozás és -átalakítás terén, amely lehetővé teszi a nyers logadatok feldolgozását, a kívánt formátumba alakítását, valamint az események szűrését és manipulálását. Az egyik legnagyobb előnye a rugalmassága, amelyet Ruby szkriptek beépítése révén érhetünk el. A következő példában bemutatott módszerek és szintaxisok segítenek a Logstash konfigurációs fájlok hatékonyabbá tételében, miközben elkerülhetők a túlzott CPU-használat és az irreleváns adatok feldolgozása.

Először is, a példában két változót, arr1 és arr2 hozunk létre, amelyek két IP-cím mezőt tartalmaznak, amelyeket összehasonlítunk. A Logstash API segítségével kérjük le az események mezőit. Fontos megjegyezni, hogy az arr1 és arr2 helyett közvetlenül az event.get().each módszert is használhatnánk, de a kód olvashatósága szempontjából jobban járunk, ha előbb meghatározzuk azokat a változókat.

Amennyiben mindkét tömb létezik és nem nil, akkor az .each módszert hívjuk meg, amely egy ciklust indít el minden egyes elemre. Ez a ciklus lehetővé teszi, hogy minden egyes elemet feldolgozzunk a két tömbben, ahogyan azt más programozási nyelvekben, például a for ciklusoknál is tennénk. A blokk, amely a do és end között található, tartalmazza az adatfeldolgozási logikát, és a pipákkal jelezzük a ciklusba bevitt elemeket, mint például item1 és item2.

Miután összehasonlítottuk az elemeket, és ha azok megegyeznek, akkor a tags mezőt módosítjuk. Ha ez a mező már létezik, akkor egy egyedi karakterláncot (match_itemX) adunk hozzá a tags tömbhöz a << operátor segítségével. Ha viszont a tags mező nem létezik, először létrehozzuk azt, majd hozzáadjuk az egyedi karakterláncot. A tags mezőt akkor is ellenőriznünk kell, hogy ne történjen hiba, ha megpróbálunk értéket hozzáadni egy nem létező mezőhöz.

Ezen kívül a Ruby szintaxis számos hasznos eszközt kínál, amelyek segítenek a fejlesztőknek abban, hogy könnyebben dolgozzanak a Logstash konfigurációval. A Ruby rugalmas a szóközök és a behúzások kezelésében, így például a négy egymás utáni end kulcsszó mindegyike elhelyezhető egyetlen sorban, ami egyszerűsíti a kódot. A Ruby más hasznos módszereket is biztosít, mint például az upcase (nagybetűssé alakítás), a downcase (kisbetűssé alakítás), vagy a capitalize (csak az első betű nagybetűsítése). A join metódus egy tömbből egy karakterláncot hoz létre, míg a split éppen az ellenkezőjét végzi.

A Logstash-ban végzett adatfeldolgozás során az is gyakori feladat, hogy el kell dobni bizonyos eseményeket, hogy ne pazaroljunk CPU ciklusokat értéktelen adatokra. Erre szolgál a drop szűrő, amely lehetővé teszi számunkra, hogy eltávolítsuk azokat az eseményeket, amelyek nem relevánsak a további feldolgozás szempontjából. Például, ha egy új hálózati eszköz túl sok értéktelen eseményt generál, akkor a következő szűrőt alkalmazhatjuk annak eltávolítására:

pgsql
Copy code
filter {

  if [event][code] == 123456789 {
    drop{}
  }
}

A drop szűrő egy másik hasznos funkcióval is rendelkezik, amely lehetővé teszi, hogy bizonyos százalékban eltávolítsuk az eseményeket, így például, ha csak az események 5%-át szeretnénk megtartani, 95%-át pedig eldobni, akkor a következő kódot alkalmazhatjuk:

pgsql
Copy code
filter {
  if [event][code] == 123456789 {
    drop { percentage => 95 }
  }
}

A szűrők elhelyezése során mindig fontos, hogy a logikai sorrendet figyelembe véve a lehető legkorábban alkalmazzuk őket, mivel így minimalizálhatjuk a feldolgozandó adatok mennyiségét.

sql
Copy code
git add .
git commit -a -m "Új szűrők hozzáadása"
git push