A Qubes OS egyik remek tulajdonsága, hogy különböző típusú VM-eket lehet benne használni, köztük az egyik legérdekesebb a ProxyVM.
Ezek a NetVM-ek számára AppVM-nek, az AppVM-ek számára pedig NetVM-nek ‘látszódnak’, így tehát a kettőjük között helyezkednek el a belső virtuális hálózaton. Ez az elhelyezkedés ideális állapotot teremt arra, hogy ebben a típusú VM-ben „elkapjuk” és elemezzük az AppVM-ek által generált átmenő forgalmat.
Erre a feladatra a szerintem az egyik legalkalmasabb megoldás a Suricata, ami egy Open Source, IDS/IPS és Network Security Monitoring (NSM) szoftver. Jelen cikkem azonban kizárólag a Qubes-ba való integrálásáról szól.
Telepítés
Hozzunk létre egy új template-et, a Fedora-minimal-ból kiindulva – mondjuk „F24-Proxy” néven. Az ott leírtakon kívül még a következő csomagokat kell telepíteni:
suricata mate-notification-daemon dejavu-sans-fonts jq
Ha a template kész, hozzunk létre egy új virtuális gépet, pl „IDS” névvel. Fontos, hogy ProxyVM típusú legyen, és az újonnan elkészült (F24-Proxy) template-et használja. Kezdetben elegendő 2 vCPU, 1Gb RAM, és a default 2Gb Private Storage terület.
A további műveleteket már ebben az új ProxyVM-ben kell majd végrehajtani.
Szabályok
Szabályok (rule) nélkül a gyakorlatban semmit nem ér egy ilyen megoldás, hiszen tulajdonképpen ezeken múlik, hogy az elemezni kívánt forgalomból mi az ami számunkra érdekes. Szabályokat kreálhatunk saját igényeink szerint is, vagy használhatunk mások által előre elkészített szabálykészleteket is. Ennek részleteibe én nem is mennék bele, sokkal inkább javaslom a hivatalos dokumentáció témába vágó részeinek olvasgatását.
A Qubes specifikus dolog annyi, hogy az alapértelmezett könyvtár – ahol a szabályokat keresi /etc/suricata/rules – az nem permanens, tehát vagy minden boot után újra kell őket telepíteni, vagy pedig áthelyezni az egészet /home/user/.config/ könyvtár alá. Példáimban én ez utóbbit alkalmaztam.
Csomagszűrő
Annak ellenére, hogy a hálózati forgalom gyakorlatilag keresztülhalad a Suricata processzt futtató ProxyVM-en, a megoldás működéséhez kell némi támogatás csomagszűrő oldalról is.
Hogy ez kompatibilis maradjon a Qubes OS dinamikusan változtatható virtuális hálózati topológiájával az /rw/config/qubes-firewall-user-script állományba kell elhelyeznünk az ehhez szükséges iptables szabályt:
# NFQ rule for Suricata iptables -I FORWARD -j NFQUEUE
Majd tegyük is futtathatóvá:
$ sudo chmod +x /rw/config/qubes-firewall-user-script
Konfiguráció
A Suricata konfigurációja egyetlen fájlban található: /etc/suricata/suricata.yaml
Ezt (is) érdemes lemásolni, és/vagy áthelyezni a $HOME/.config/suricata/ könyvár alá, és benne minimum a következőket beállítani:
HOME_NET: "[10.137.0.0/16]" EXTERNAL_NET: "!$HOME_NET" default-rule-path: /home/user/.config/suricata/rules classification-file: /home/user/.config/suricata/classification.config reference-config-file: /home/user/.config/suricata/reference.config default-log-dir: /home/user/.local/var/log/suricata/
Igény szerint ezeket is érdemes lehet bekapcsolni:
# a line based log of HTTP requests (no alerts) - http-log: enabled: yes filename: http.log append: yes # a line based log of TLS handshake parameters (no alerts) - tls-log: enabled: yes filename: tls.log append: yes # a line based log of DNS requests and/or replies (no alerts) - dns-log: enabled: yes filename: dns.log
Természetesen, ezek csak az alapok, további információk a programban rejlő lehetőségekről a hivatalos a dokumentációjában találhatóak.
Indítás
Az első kísérletek alkalmával egyszerűen indítsuk el a programot egy terminálból:
$ sudo suricata -c /home/user/.config/suricata/suricata.yaml -q 0 &
Később érdemes a Qubes Manager-ből bekapcsolható szervízként indítani – de egyelőre ezzel én nem foglalkoztam.
Riasztások
A fenti műveletek sikeres elvégzése után a rendszerünk már vizsgálja is a rajta átmenő forgalmat. Természetesen, ahhoz hogy legyen is tényleges átmenő forgalom, legalább egy AppVM-nek ezt az új ProxyVM-et kell beállítnai NetVM-ként. A forgalomelemzés eredményét – többek között – egy JSON formátumú log állományban (eve.json) tárolja. Ezeket a logokat ideális esetben egy komolyabb SIEM rendszernek kellene továbbítani, amelyik akár további korrelációkat végezhet rajtuk, majd végül valamilyen felületen értesít is minket (vagy az illetékeseket) az észlelt eseményekről.
Esetünkben azonban „csak” a saját virtuális gépeink forgalmáról van szó, amiről viszont jó lenne azonnal az éppen használt desktop felületen értesítést kapni. Erre nyújt megoldást a következő „parancshalmaz”:
$ sudo tail -f /home/.local/var/log/suricata/eve.json \ | jq --unbuffered -r -c 'select(.event_type=="alert")' \ | jq --unbuffered -r '@sh "signature=\(.alert.signature) SRC=\(.src_ip) action=\(.alert.action)"' \ | while read -r line; \ do \ eval $line; \ notify-send "$signature" "$(echo -e "source:\t$SRC\naction:\t$action")" -t 50000 -i /usr/share/icons/Adwaita/48x48/status/software-update-urgent.png ;\ done &
Ez így persze még eléggé nyers, azonban egyszerű és könnyen értelmezhető módon hozza tudtunkra a hálózati forgalomban felfedezett problémákat/eseményeket.
Ebben a főszereplő a jq parancs, ami a JSON formátum értelmezést végzi, és végül a notify-send, ami a szabványos értesítések küldéséért felelős.
Természetesen, ezt is érdemes lesz majd egy külön ki/be kapcsolható szolgáltatás formába tölteni – amint ez elkészül, frissítem ezt a cikket is.
Ha mindent jól ment – és mondjuk böngészni kezdünk az IDS-en „keresztül” – egyből kapunk is riszatást, ami a Qubes DNS megoldásából fakad. A következő feladatunk, hogy ezt kiszűrjük, hiszen esetünkben ez normális működés. Ez azonban már egy másik cikk témája lesz…