Az első két részben installáltuk a Home Assistantot egy alap telepítésű debian 11 operációs rendszerre, majd bekonfiguráltuk a https protokoll használatát. Az utolsó részben még ellátjuk a rendszerünket egy tűzfallal és egy fail2ban nevű programmal, ami automatikusan tiltó listára teszi nekünk azon IP címeket, amikről úgy ítéli meg, hogy támadják a rendszerünket. Tűzfalként három program az elterjedt: IPtables, ufw és shorewall. Nekem a Shorewall jobban kézre áll, így azt fogom használni. Az ufw-ről is sok leírás van a neten, ugyanúgy iptables szabályokat módosít, mint a shorewall.

Lássunk is neki a feladatnak, ehhez ssh kapcsolaton keresztül lépjünk be a rendszerünkbe, majd installáljuk a két programcsomagot.

Ha már beléptünk a gépbe, akkor ne feledkezzünk meg a frissítések ellenőrzéséről és telepítéséről sem.

A példában a rendszerünk egy fizikai hálózati interface-vel rendelkezik, így a tűzfal szabályokat is így építem fel. Abban az esetben, ha több hálózati kapcsolattal rendelkezik a gép, módosítani kell ezeket. Az install magával hoz több példa konfigurációt is, amit megtalálunk a /usr/share/doc/shorewall/examples/ mappában. Innen fogom használni az egy interface-s példát és azt fogom módosítani, ezért másoljuk át a szükséges fájlokat a /etc/shorewall mappába.

Ha jobban megnézzük a rendszerünket, láthatjuk, hogy mégsem egy interface van használatban, hanem több is! Ez azért van, mert dockerben hoztuk létre a rendszerünket. De mégis melyek ezek a hálózati interface-k, amiket figyelembe kell vennünk a tűzfal beállítása közben? Kérdezzük le a hálózati interfaceinket.

Tehát három interface megadása szükséges a /etc/shorewall/interfaces fájlban.

Következő lépésben adjuk meg a zónáinkat. A zóna nevei azok, amiket az interfaces fájlban megadtuk a ZONE oszlopban.

Folyatassuk a default policy szabályok megadásával. Egyelőre elég megengedő szabályrendszert hozunk létre, amit a későbbiekben nyugodtan szigorúbbra lehet hangolni. De mit is látunk lentebb? A tűzfalról kifelé ($FW) miden elérést engedünk, a dockerről és a hass-ról is. A net irányából mindent tiltunk és az eldobott csomagok információját lelogoljuk.

Utolsó lépésben adjuk meg az egyedi szabályrendszerünket. A belső hálózatunkból érkező összes forgalmat engedélyezzük. (Ezen lehet hangolni, google segítségünkre lesz.) A 8123-as portot is kinyitjuk, hogy távolról elérjük a Home Assistant rendszrünket. Ha vannak egyéb portok, amiket a rendszerünkben távolról is el szeretnénk érni, azokat is itt kell megadnunk.

Ha mindent beállítást elkészítettünk, ellenőrizzük a konfigurációnkat, ha a rendszer nem talál benne hibát, indítsuk el a shorewall-t. Ha ssh szabályt is hoztunk létre, azt egy másik terminálból ellenőrizzük, hogy tudunk -e még kapcsolódni a géphez, mert a tűzfal indulásával nem bontja el a meglévő kapcsolatokat.

Ha elvégzünk egy alap ellenőrzést, hogy minden szándékozott portot elérünk és megfelelőnek találjuk a beállításainkat, nincs más hátra, mint beállítani, hogy a rendszer indulásakor automatikusan induljon el, ehhez a startup paramétert írjuk át 1-re.

Utolsó lépésként engedélyezzük a szervíz indulását.

Mivel az eldobott csomagokat logoljuk, így érdemes ránézni a /var/log/syslog fájlra, hogy milyen címekről dobálunk el csomagokat. Ha van benne olyan, amit nem akartunk tiltani, a rules fájlhoz adjuk hozzá.

Megvagyunk a tűzfallal, folytassuk a fail2ban beállításával. A főbb paraméterek, amiket módosítani szoktam:

• ignoreip: mely IP címek legyenek a kivételek, amikre nem lesznek érvényesek a szabályok
• bantime: mennyi időre tiltjuk ki az IP címet (másodpercben)
• findtime: mennyi az időablak, amire a logfájlban történő keresések vonatkoznak (másodpercben)
• maxretry: hány találat után kerüljön tiltásra az IP cím

Ezt követően a fájlban a jailek szakaszkoz adjunk hozzá két újabb szabályt, ami a Home Assistant sikertelen belépéseket és a portscan műveleteket fogja figyelni. (Ha több szolgáltatás fut a gépünkön, érdemes végignézni, mik vannak itt, mert sokmindent tud figyelni.)

• enabled=true : aktiváljuk a szabályt
• logpath: ezt a logot fogja elemezni a fail2ban
• filter: filter neve

Az új szabályainkhoz szükséges filtereket is létre kell hozni:

Végezetül állítsuk be a Home Assistantot, hogy írja be a logfájlba a sikertelen belépéseket. Ezt a configuration.yaml fájlba tudjuk hozzáadni.

Ha mindennel elkészültünk, indítsuk újra a fail2ban servicet, ellenőrizzük, hogy elindult -e és a szabályok is betöltésre kerültek.

Csináljuk néhány hibás bejelentkezést, hogy ellenőrizzük, működik -e a szabályrendszerünk, közben figyeljük a Home Assistant logfájlját, hogy a hibás bejelentkezések bejegyzésre kerülnek.

Amint a hibás belépések elérik a megadott darabszámot, a fail2ban logjában láthatjuk, hogy tiltólistára kerül az IP cím.

A Home Assistant weblapja innentől már az adott IP címről elérhetetlen lesz.

Ha sikeresen kitiltottuk magunkat a rendszerünkből és még ssh-n be tudunk lépni, tudjuk a tiltó listáról törölni az IP címet, így nem kell kivárnunk a tiltás idejének leteltét.

A fail2ban logfájlját az indulástól figyelve látjuk, ahogy betölti a szabályokat, amik alapján figyelni fogja a logokat, majd jelzi, ha talál egyezést, végül tiltólistára is teszi a vélt vagy valós támadó IP címét. A portscan filter akkor működik, ha sok portunk van nyitva, mert a port felderítés úgy működik, hogy 0-65535 portot végignézi egy automatizmus. A mi oldalunkon a tűzfalunkon felakadnak a próbálkozások és tiltani fogja azokat, plusz bejegyzi a log fájlba. Viszont mindig arra kell törekedni, hogy a minimális, legszükségesebb mennyiségű portot nyissuk ki a rendszerünk felé, mert minél több port és azokon található szolgáltatás elérhető, annál sebezhetőbb lesz a rendszerünk.

Ha most megnézzük, mely portok vannak nyitva a gépünkön, látható, hogy három ilyen tcp portunk van.

Ha a távolból indítunk egy port felderítést (fail2ban-t kikapcsoltam, hogy ne tiltson ki), látható, hogy csak a tűzfalon engedélyezett port látszik kívülről.

Amit múltkor láttam a shodanos keresgélés közben, hogy sokan használnak nginx webszervert a rendszerükben és elérhetővé is teszik azt az internet irányából. Sokszor írtam már, hogy a használt program verziók megjelenítését kapcsoljuk ki, mert egy támadó számára az egy értékes információ, hisz a verziószám tudtában célzott támadást tud kivitelezni, exploitokat keresni. De hogyan lehet kikapcsolni ennek az információnak a megjelenítését nginx szerver esetén?

nginx version header információ kikapcsolása

Először is ellenőrizzük, hogy megjelenik -e a header információkban az nginx verziószáma. Lépjünk be a szerverünkbe ssh kapcsolaton keresztül, majd adjuk ki az alábbi parancsot.

Ha a válaszban a server paraméternél ott az nginx verziószám, akkor ezt érdemes elrejtenünk.

Ehhez módosítanunk kell a default nginx konfigurációs fájlt. 

Állítsuk át a server_tokens paramétert off-ra és ha már ezt a fájlt szerkesztjük, módosítsuk az ssl protokollokat és csak a biztonságos, TLSv1.3-at hagyjuk meg.

Mentsük a módosításokat, majd ellenőrizzük a konfigurációnkat. Ha minden rendben van, akkor indítsuk újra a szolgáltatást, hogy érvényesüljenek a módosításaink.

Ha most újra ellenőrizzük a header információkat, láthatjuk, hogy a használt nginx verzió már nem jelenik meg.

apache version header információ kikapcsolása

Ha apache szervert használunk, abban is kikapcsolható a verzió információ megjelenítése.

Először is ellenőrizzük, hogy megjelenik -e a header információkban az apache verziószáma. Lépjünk be a szerverünkbe ssh kapcsolaton keresztül, majd adjuk ki az alábbi parancsot.

Ha a válaszban a server paraméternél ott az apache verziószám, akkor ezt érdemes elrejtenünk.

Ehhez módosítanunk kell az apache security.conf konfigurációs fájlt. Állítsuk át a ServerTokens paramétert Prod-ra, majd mentsük a módosításokat.

Indítsuk újra a szolgáltatást, hogy a módosítások érvényesüljenek.

Ha most újra ellenőrizzük a header információkat, láthatjuk, hogy a használt apache verzió már nem jelenik meg.

Végezetül tartsuk szem előtt, hogy csak a legszükségesebb portok legyenek nyitva a rendszerünk felé, rendszeresen frissítsük a rendszerünket (operációs rendszer, programok, router firmware, okoseszközök firmwarei) és a használt jelszavaink is megfelelő bonyolultságúak legyenek.

Ha nagyobb biztonságot szeretnénk, mint amit eddig leírtam, érdemes az operációs rendszerünk konfigurációját a CIS ajánlásai szerint security szempontból is beállítani. Amennyiben nginx-et is használunk, ahhoz is elérhető CIS Benchmark. Használjunk VPN-t és akkor csak a VPN szerver elérésére használt portot nyissuk ki az internet felől a rendszerünk irányába, minden mást zárjunk be. Alkalmanként ellenőrizzük (akár a shodan.io-t használva), hogy mely portok érhetők el a rendszerünk felé, nehogy valamely upnp-s eszköz meglepjen minket egy tudtunkon kívüli port nyitással.