Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский
A Logstash egy sokoldalú adatfeldolgozó eszköz, amely a különböző adatforrásokból származó információkat képes integrálni és továbbítani más rendszerekbe, például az Elasticsearch-be. Az adatok biztonságos átvitele elengedhetetlen, különösen akkor, ha érzékeny vagy személyes információkról van szó. A TLS (Transport Layer Security) titkosítás segítségével biztosíthatjuk, hogy az adatforgalom titkosítva történjen, megvédve ezzel a kommunikációt az illetéktelen hozzáféréstől.
A következő lépésekben bemutatjuk, hogyan készíthetünk el egy Logstash konfigurációt, amely TLS titkosítással védi az adatokat, és biztosítja a megbízható kommunikációt. A folyamat során OpenSSL-t használunk kulcsok és tanúsítványok generálására, valamint bemutatjuk, hogyan konfigurálhatjuk a Logstash-t a TLS beállításokkal.
A tanúsítványokat és kulcsokat először egy konfigurációs fájl segítségével generáljuk. Az openssl parancsot használva lehetőség van a saját titkosító kulcsok és tanúsítványok létrehozására. A következő lépésekre van szükség, hogy generáljunk egy tanúsítványt és a hozzá tartozó privát kulcsot a Logstash számára.
A konfigurációs fájlban a legfontosabb részletek azonosítása kulcsfontosságú. A commonName (CN) mezőnek tartalmaznia kell a kiszolgáló teljesen minősített domain nevét (FQDN), hogy biztosítsuk a régebbi böngészők visszafelé kompatibilitását. A modern böngészők már inkább a Subject Alternative Name (SAN) mezőt használják a tanúsítványok azonosítására. A SAN mezőt az alternate_names szekcióban található DNS nevekkel kell kitölteni, például logstash és logstash.local, hogy a Logstash bármely változata biztonságosan hitelesíthető legyen.
Az OpenSSL használatával generálhatunk kulcspárokat és tanúsítvány aláíró kéréseket. Az alábbi parancs segítségével a Logstash számára generálhatunk tanúsítványt:
Ez a parancs létrehozza a Logstash kulcspárt és a tanúsítvány aláíró kérvényt (CSR). Ezt követően a közbenső CA konfigurációval aláírhatjuk a tanúsítványt:
A tanúsítvány aláírása után ellenőrizhetjük annak helyességét a következő parancsokkal. Az alábbi parancsok segítségével biztosíthatjuk, hogy a tanúsítvány helyesen van aláírva:
Ezekkel a parancsokkal ellenőrizhetjük, hogy a tanúsítvány érvényes, és hogy minden szükséges információ (például az aláíró és a kulcsazonosító) helyesen szerepel.
A Logstash konfigurációjánál figyelmet kell fordítani a megfelelő fájlstruktúrára. A Logstash telepítése után célszerű a certifikátokat és kulcsokat a certs mappába másolni, hogy azok könnyen hozzáférhetők legyenek a konfiguráció számára. A következő parancsokkal másolhatjuk át a tanúsítványokat és kulcsokat a megfelelő mappába:
A Logstash konfigurációját a conf.d könyvtárban található fájlban kell meghatározni. A következő konfiguráció egy alapbeállítást mutat, amely TLS kapcsolatokat fogad a Beats protokoll és a syslog segítségével:
Ez a konfiguráció biztosítja, hogy a Logstash TLS titkosítást használjon a Beats adatfogadásához, és kötelezővé teszi az ügyfél hitelesítését. A syslog beállítás is szerepel a konfigurációban, így az egyéb adatforrások is elérhetők lesznek. Az output szakaszban a rubydebug kódoló segítségével részletes JSON kimenetet generálunk a naplózáshoz.
Az adatforgalom biztonságának megőrzése érdekében nemcsak a Logstash konfigurációt kell helyesen beállítani, hanem megfelelő tűzfal szabályokat is alkalmazni kell. Az alábbi parancsokkal nyithatjuk meg a szükséges portokat Ubuntu rendszeren:
A megfelelő tűzfal beállítások után a Logstash konfigurációt tesztelhetjük, hogy megbizonyosodjunk arról, hogy minden megfelelően van konfigurálva és nincs szintaktikai hiba.
A végén ne felejtsük el, hogy a Logstash és a TLS titkosítás beállítása nem csupán a titkosított adatátvitel biztosítása miatt fontos, hanem azért is, hogy az adatbiztonságot minden szempontból garantálhassuk a rendszerünkben. A helyesen beállított konfigurációk, a megfelelő tanúsítványok és kulcsok használata elengedhetetlen a biztonságos és megbízható kommunikációhoz.
Hogyan hozzunk létre TLS tanúsítványt és konfiguráljuk a Filebeatet biztonságos kapcsolat létrehozásához
A Filebeat telepítésének és konfigurálásának egyik kulcsfontosságú lépése a TLS tanúsítvány létrehozása, amely biztosítja az átvitt adatok titkosítását. A következő lépéseken keresztül bemutatjuk, hogyan hozhatunk létre egy új TLS tanúsítványt a Filebeat számára, hogyan konfiguráljuk a Filebeatet a titkosított kapcsolat használatára, és milyen alapvető beállításokat kell elvégeznünk a fájlokon és a konfigurációs fájlokban.
Első lépésként szükség van egy TLS tanúsítványra, amelyet a Filebeat fog használni az adatok titkosítására. Az elsődleges és köztes hitelesítésségi autoritások (CA) már létrejöttek a 2. fejezetben. Most ezen köztes CA segítségével kell aláírni egy új TLS flex tanúsítványt.
A következő lépésben az OpenSSL-t fogjuk használni egy új TLS flex tanúsítvány létrehozásához. A konfigurációs fájlokat a korábban létrehozott TLS konfigurációs könyvtárban kell tárolnunk, amelyet a 2. fejezetben hoztunk létre (~/tls/configs). A konfigurációs fájl létrehozása után a következő beállításokat kell alkalmaznunk:
Az OpenSSL az itt megadott konfigurációs fájl segítségével generál egy új privát kulcsot a tls/keys könyvtárba. Fontos, hogy a flex_distinguished_name szekcióban szereplő információkat saját adataiddal helyettesítsük (ha nem egy helyi étel, mint a rántott ravioli és sertésszelet földjéről származol). A commonName és nsComment beállítások azt jelzik, hogy ez egy kliens tanúsítvány, amely titkosított kapcsolatokat indít és fogad. A subjectAltName szakaszban meg kell adni a szerver FQDN nevét is, amelyen a Filebeat fut.
Ezután szükséges, hogy az IP-címet és a hosztnevet hozzáadjuk a DNS szerverhez vagy a /etc/hosts fájlhoz, hogy a hostnevek megfelelően feloldódjanak. A következő bejegyzéseknek kell szerepelniük:
A DNS bejegyzések nélkül a Filebeat nem tudja majd létrehozni a TLS kapcsolatokat, mivel a tanúsítvány subjectAltName nem tartalmazza az IP-címeket.
Miután létrehoztuk a tanúsítványt, a következő lépés a tanúsítvány aláírásának folyamata. Ehhez először létre kell hoznunk a kulcspárt és a tanúsítvány aláírási kérelmet (CSR), majd a köztes CA segítségével aláírjuk azt. Az OpenSSL parancs a következőképpen néz ki:
Ezután az alábbi parancs segítségével a köztes CA-val aláírjuk a tanúsítványt:
Ekkor már rendelkezünk az aláírt tanúsítvánnyal (filebeat.local.flex.cert.pem). A tanúsítvány kiterjesztéseit az alábbi parancs segítségével ellenőrizhetjük:
A tanúsítványban szereplő X509v3 kiterjesztések mutatják, hogy a tanúsítvány használható kliens és szerver kapcsolatokra is. Az X509v3 Subject Alternative Name beállítás tartalmazza a megadott DNS neveket: filebeat és filebeat.local.
Miután meggyőződtünk róla, hogy a tanúsítvány hitelesíthető a CA lánc fájllal, megkezdhetjük a Filebeat konfigurálását. A filebeat.yml konfigurációs fájl központi szerepet játszik az alapvető beállítások kezelésében. Itt adhatjuk meg a bemeneteket, átalakításokat, kimeneteket és más fontos beállításokat. A fájl alapértelmezés szerint a helyi Elasticsearch és Kibana példányokhoz próbál csatlakozni, de mi most testreszabjuk és egyszerűsítjük a fájlt, hogy jobban megértsük a működését.
A következő konfigurációs részlet például bemutatja, hogyan állíthatunk be egy egyedi fájlforrást a Subfinder és Httpx eszközök által generált JSON fájlokhoz. A filebeat.inputs rész tartalmazza az input adatokat, a filestream típusú bemenetet és az útvonalat, ahol a fájlok találhatók. A konfigurált fájl így néz ki:
A filebeat.inputs szekcióban a filestream típusú bemenetet adtuk meg, amely lehetővé teszi, hogy a rendszer a Subfinder és Httpx eszközökkel generált JSON fájlokat olvassa. A fájlok helyét a paths szekcióban adjuk meg. A kimeneti adatokat a logstash szerverhez irányítjuk, és TLS titkosítást alkalmazunk a kapcsolat biztonságos létrehozása érdekében.
A TLS használata segít megvédeni az adatainkat a külső támadásoktól és biztosítja, hogy az adatkommunikáció titkosítva történjen, így az érzékeny információk védelme még a külső hálózaton is garantált.
Hogyan állítsunk be Elasticsearch és Kibana SSL titkosítást és konfigurációt?
Az Elasticsearch és a Kibana telepítése és konfigurálása nemcsak az adatbázis-szerverek indítását jelenti, hanem azok biztonságos összekapcsolását is, különös figyelmet fordítva az SSL titkosításra. Az alábbiakban bemutatott konfigurációs beállítások segítségével biztosíthatjuk, hogy a rendszer titkosított kommunikációval és megfelelő hitelesítéssel működjön.
Az elsődleges beállítások az elasticsearch.yml fájlban találhatók, ahol az SSL titkosítást kell engedélyeznünk, mind az HTTP, mind a transport protokollok számára. A következő bejegyzéseket kell hozzáadni:
Ez a konfiguráció biztosítja, hogy az Elasticsearch HTTP kapcsolatainak titkosítása SSL segítségével történjen, a keystore.path értéke az SSL tanúsítványt és kulcsokat tartalmazó fájlt jelöli, míg a certificate_authorities a tanúsítványok megbízhatóságát igazoló CA fájlt adja meg.
A rendszerben az xpack.security beállítások engedélyezésével a titkosított kommunikáció mellett elérhetővé válik a hitelesítés, ami biztosítja, hogy csak megbízható felhasználók és rendszerek férjenek hozzá a szolgáltatáshoz. A következő beállítások felelősek a hálózati kapcsolatokért:
Ezek a sorok meghatározzák a klaszter nevét és azt, hogy az Elasticsearch melyik gépen keresztül érhető el. A network.host beállítás azt a címet adja meg, ahol az Elasticsearch elérhető, míg a discovery.seed_hosts segít az új node-oknak felfedezni az elérhető klasztert, ha több gépen futtatjuk a rendszert.
A privát kulcsok jelszavának tárolása szintén fontos lépés a biztonságos konfiguráció során. Az alábbi parancsokkal hozzáadhatjuk a titkosított jelszót a keystore-hoz:
Ezek a parancsok lehetővé teszik a privát jelszavak biztonságos tárolását, anélkül, hogy a konfigurációs fájlokban nyíltan szerepelnének.
A Java Virtual Machine (JVM) beállításai is kulcsfontosságúak a rendszer stabilitása szempontjából. A rendszerre optimalizált memória-beállítások segítenek elkerülni a túlzott memóriahasználatot. Ehhez a következő parancsokat kell alkalmaznunk:
Ezek a beállítások biztosítják, hogy az Elasticsearch ne használjon több memóriát, mint amennyit szükséges, így a rendszer erőforrásai hatékonyabban oszlanak el.
A jelszavak beállítása után ne feledkezzünk meg az Elasticsearch és Kibana közötti hitelesítésről sem. A következő parancsokkal megváltoztathatjuk az alapértelmezett elastic és kibana_system felhasználói jelszavát:
Ez biztosítja, hogy a rendszer nemcsak technikailag, hanem biztonságilag is védve legyen a nem kívánt hozzáférésekkel szemben.
A rendszer teszteléséhez használhatjuk a következő curl parancsokat, hogy ellenőrizzük az Elasticsearch állapotát és megbizonyosodjunk a működéséről:
A fenti parancsok segítségével lekérdezhetjük a szerver adatait és az egész klaszter állapotát. A válaszból egyértelműen látható lesz, hogy a telepítés sikeresen megtörtént, és az Elasticsearch működik.
Ha több node-ot szeretnénk hozzáadni a klaszterhez, ismételjük meg a telepítési lépéseket, figyelve arra, hogy minden új gépen frissítsük a node.name, network.host és keystore beállításokat. Az új node-ok számára meg kell adni legalább egy meglévő master node-ot a discovery.seed_hosts beállításban, és nem szükséges újra beállítani az elastic és kibana_system jelszavakat, mivel ezek automatikusan frissülnek.
A Kibana telepítése és konfigurálása szintén fontos lépés, mivel ez biztosítja a frontend felületet az Elasticsearch kezelésére. A TLS titkosítás beállításai a Kibana számára is szükségesek, hogy biztosítsák a biztonságos kommunikációt az Elasticsearch-sel. Ehhez létre kell hoznunk a megfelelő cert fájlokat és a szükséges jelszavakat a Kibana konfigurációban.
A megfelelő jelszókezelés és titkosítási szabályok betartása biztosítja, hogy az Elasticsearch és Kibana környezetek biztonságosak és megfelelnek a modern biztonsági előírásoknak, védve a rendszert a kívülről érkező támadásokkal szemben.
Hogyan hajtsunk végre parancsokat távoli gépeken és kezeljünk konfigurációkat Ansible segítségével?
Az Ansible egyik legfontosabb és leghasznosabb modulja a távoli gépeken végzett parancsok futtatásához a command és a shell. Első ránézésre úgy tűnhet, hogy mindkét modul ugyanazt a feladatot látja el: parancsokat futtat távoli rendszereken. Azonban van egy apró különbség közöttük, amely fontos szerepet játszik a megfelelő eszköz kiválasztásában.
A shell modul új shell szintet indít, amely lehetővé teszi a parancsok közötti adatcsővezetékezést (pipe), míg a command modul a Python subprocess modulját használja, amely nem támogatja a csővezetékezést, hanem közvetlenül spawnolja a folyamatokat. Ennek eredményeként, ha pipelést szeretnénk végrehajtani, például egy fájl tartalmát keresni egy listából, akkor a shell modult kell használnunk.
Például, ha a command modullal próbálkozunk, hogy listázzuk a fájlokat egy távoli gép home könyvtárában, akkor az alábbi parancsot futtathatjuk:
Ez a parancs sikeresen listázza a fájlokat és könyvtárakat, és az "CHANGED" kimenet jelzi, hogy a parancs sikeres volt. Azonban, ha próbáljuk pipelni az eredményt a grep parancshoz, például így:
Ez nem fog működni, mivel a command modul nem értelmezi a csővezetéket, és helyette fájlnévként kezeli azt. Ha ugyanazt a parancsot a shell modullal hajtjuk végre, akkor a csővezetékezés sikeres lesz, mivel először elindít egy shell szintet:
Ezáltal sikerül kiszűrni a kívánt fájlokat. A shell modul tehát akkor ajánlott, amikor pipelést vagy komplex parancsokat kell végrehajtani.
Bár a command és a shell modulok hasznosak lehetnek egyedi vagy nem támogatott feladatok végrehajtásához, a legjobb gyakorlat az, hogy az Ansible dedikált moduljait használjuk, ha azok elérhetők, mivel a command és shell parancsok nem idempotens módon működnek. Ez azt jelenti, hogy ezek nem garantálják ugyanazon műveletek többszöri végrehajtása során a rendszer állapotának megőrzését, ami problémát jelenthet, ha ismételten végrehajtjuk őket.
A csomagok frissítése egy másik kulcsfontosságú feladat, amely gyakran előfordul, amikor egy új biztonsági figyelmeztetés vagy frissítés jelenik meg. Az Ansible lehetővé teszi a csomagok egyszerű frissítését a csomagkezelő modulok segítségével, például az apt vagy rpm modulokkal. Az alábbi parancs frissíti az apt csomagkezelő gyorsítótárát anélkül, hogy bármit is telepítene vagy frissítene:
Ez a parancs a --become opcióval superuser jogokat biztosít, míg a --ask-become-pass kéri a sudo jelszót a távoli rendszereken. Ha új csomagot, például az Nmap-ot szeretnénk telepíteni, akkor az alábbi parancsot használhatjuk:
A state=present argumentum arra utal, hogy a csomagnak telepítve kell lennie, ha még nincs jelen. Ha el akarjuk távolítani a csomagot, az absent állapotot használhatjuk:
Ansible támogatja a present, absent, és latest állapotokat, amelyek általánosan használatosak a csomagkezelésben, és ezek a műveletek egyenértékűek a csomag telepítésével, eltávolításával és frissítésével.
A szolgáltatások kezelésére is van dedikált modul, mint a systemd_service, amely lehetővé teszi a rendszerszolgáltatások indítását, leállítását, újraindítását, engedélyezését vagy letiltását. Például, ha újra szeretnénk indítani az rsyslog szolgáltatást, mert frissítéseket végeztünk rajta, az alábbi parancsot használhatjuk:
Az Ansible egy másik fontos modulja a szerverek újraindításához. A reboot modul biztosítja, hogy a távoli gépeket újraindíthatjuk anélkül, hogy manuálisan kellene beavatkoznunk. Az alábbi parancs újraindítja a kafka csoporthoz tartozó gépeket:
A szerverek biztonságos leállításához pedig a community.general.shutdown modul használható:
Amikor több szervert kell egyszerre kezelni, az Ansible csoportosítja azokat a hosts mezőn belül az inventár fájlban, ami lehetővé teszi számunkra, hogy több gépen egyszerre végezzünk el műveleteket.
A Playbookok egy nagyon hasznos lehetőséget kínálnak, amikor több feladatot kell végrehajtanunk egymás után. Például, ha létre szeretnénk hozni egy új felhasználót minden távoli gépen, akkor azt az alábbiak szerint tehetjük meg:
Először is, egy változó fájlban definiáljuk az új felhasználó nevét:
Ezután egy titkosított fájlban tárolhatjuk a felhasználó jelszavát, például az ansible-vault segítségével. Miután elkészítettük a titkosított fájlt, a jelszót SHA-512 hash-tel tárolhatjuk benne. A Playbookban pedig az alábbi módon hozhatjuk létre a felhasználót és állíthatjuk be a jelszavát:
A fenti feladatok végrehajtása után az új felhasználó létrejön, és a megfelelő jelszót biztonságosan beállítjuk.
Fontos megérteni, hogy az Ansible nem csak a parancsok távoli végrehajtására alkalmas, hanem az eszközök és konfigurációk kezelésére is, biztosítva, hogy az automatizált rendszerek biztonságosak, naprakészek és könnyen karbantarthatók legyenek.
Hogyan kezeljük a fenyegetésintelligencia adatokat és építsünk fenyegetésjelző rendszert?
A fenyegetésintelligencia (threat intelligence) kezelésére szolgáló rendszerek fontos szerepet játszanak a biztonsági események észlelésében és az adatok valós időben történő feldolgozásában. A következőkben bemutatott konfiguráció egy példát ad arra, hogyan építhetünk fel egy fenyegetésintelligencia adatkezelő rendszert Logstash és Redis használatával, amely képes tárolni és feldolgozni a fenyegetésekkel kapcsolatos indikátorokat, például URL-eket, IP-címeket, hash-okat és egyéb adatokat.
A rendszer első lépése, hogy biztosítjuk a megfelelő adatokat a megfelelő formátumban. A fenyegetésintelligencia adatokat gyakran JSON formátumban kapjuk, és az első szűrő a JSON kódolt üzenetek feldolgozását végzi, amelyek a szükséges címkék (labels) mezőire vannak bontva. Miután az adatok megfelelő formátumban érkeztek, a következő lépésben a rendszer összesíti ezeket az adatokat, hogy egyetlen, könnyen kezelhető értéket képezzen a Redis gyorsítótár számára.
Az adatfeldolgozási folyamat során a Logstash szűrők és mutálók (mutate filters) segítenek az új mezők létrehozásában. Az első mutáló szűrő például létrehozza a labels.cti_message mezőt, amely az esemény adatkészletének (event.dataset) értékét tartalmazza, és alapértelmezett értékként a "threatintel"-t adja hozzá, ha az érték nem áll rendelkezésre. A következő szűrőművelet hozzáadja a labels.signature mezőt, ha az rendelkezésre áll, amely tartalmazza a malware család nevét. Ha a fájl típusát jelző mező (file.type) nem ismeretlen, akkor ezt az értéket is hozzáadjuk a labels.cti_message mezőhöz. Így folyamatosan építjük fel a fenyegetéshez kapcsolódó információkat, miközben biztosítjuk, hogy a rendszer kevesebb memóriát használjon, mivel a végső értéket gyorsítótárban tároljuk RAM-alapú módon.
A következő lépés a saját, egyedi indikátorok feldolgozása, amelyeket elemzők küldhetnek CSV fájlok formájában. Ilyen fájlok esetén a rendszer először szétválasztja a sorokat eseményekre, majd a CSV fájl oszlopait megfelelő mezőkké alakítja. A rendszer az oszlopneveket ellenőrzi, és eltávolítja azokat, ha azok megegyeznek a indicator és cti_message mezőkkel, hogy elkerüljük a redundanciát. Egy Ruby szűrő segítségével eltávolítjuk azokat a mezőket, amelyek null értékekkel rendelkeznek, mivel a CSV fájlok üres oszlopokat is tartalmazhatnak. Ha bármelyik mező hiányzik, akkor alapértelmezett értékekkel töltjük fel őket, így biztosítva, hogy a gyorsítótárba mindig valamilyen érték kerüljön.
A következő szakaszban a rendszer a Redis adatbázisba menti az összes releváns indikátort. Mivel a Redis az egyik leggyorsabb kulcs-érték tároló, kiválóan alkalmas arra, hogy fenyegetésintelligencia adatokat tároljunk benne rövid távú hozzáféréssel. A konfigurációban a rendszer különböző típusú indikátorokat keres, például IP-címeket, URL-eket, SHA256 vagy MD5 hasheket, és minden egyes indikátort lement a Redis-ba, egy 30 napos lejárati idővel. A rendszer az URL-eket és a domain neveket kisbetűssé alakítja, hogy elkerülje az esetleges duplikációkat és az eltéréseket, amelyek az esetlegesen eltérő nagybetűs formátumok miatt adódhatnak.
Ez a megoldás nemcsak gyorsítótárként működik, hanem lehetőséget biztosít a fenyegetések gyors és hatékony nyomon követésére is. Az IP-címek, hash értékek és egyéb indikátorok folyamatos tárolásával a rendszer képes valós időben reagálni a potenciális fenyegetésekre, és segíti a biztonsági elemzőket abban, hogy gyorsabban észleljék a kártékony tevékenységeket. Az egyedi indikátorok kezeléséhez, valamint a CSV fájlok és HTTP bemenetek integrálásához szükséges szűrők és műveletek lehetővé teszik a teljes folyamat automatizálását, miközben minimalizálják a szükséges erőforrások mennyiségét.
Amikor ilyen rendszert építünk, fontos, hogy mindig tisztában legyünk azzal, hogy a támadók képesek manipulálni az IP-címeket, hash-eket és más indikátorokat. A legkisebb változtatás is, mint egy byte hozzáadása vagy eltávolítása, jelentős hatással lehet a felismerés pontosságára. Ezért fontos, hogy az ilyen típusú rendszerek mindig rugalmasak legyenek, és képesek legyenek az új fenyegetésekhez gyorsan alkalmazkodni. A hash-ek, IP-címek és más információk csak akkor adhatnak megbízható eredményt, ha megfelelő kontextusban, és nem önállóan kezeljük őket.
A valóság relativizálása: Hogyan manipulálják a "tényeket" a politikai diskurzusban?
Milyen szerepet játszik a kereszténység az amerikai nemzeti identitás és politikai diskurzus formálásában?
Milyen tanulságokat vonhatunk le a Moytura első csatájából?
Miért fontos a pénzügyi adatok integritásának kezelése és hogyan érhetjük el a minőséget?