Web és Mikrotik tűzfalazás

A minap a következő üzenetekkel lett tele a Mikrotik routerem logja:

Jól láthatóan valaki erről az IP-ről az L2TP VPN-emet próbálja piszkálgatni. Ez a mai világban annyira nem lenne érdekes, hiszen az internetet naponta többször teljesen végig tudják scannelni egyes bothálózatok, ez viszont egy Magyar Telekomos, lakossági IP cím, szóval nagy valószínűséggel nem bot, hanem Pistike 🙂

Tiltottam a Mikrotik tűzfalban:

/ip firewall filter add chain=input src-address=91.120.89.65 action=drop

Több ezer packetet dobott el tőle, de pár nap múlva megváltozott a koma IP címe és az már újra be tudott találni.

Jólvan mondom, akkor tiltsuk azt is. Felvehettem volna még egy szabályt a tűzfalba, de inkább csináltam egy listát, amire fel lehet mostantól venni a tiltandó címeket és a listán lévő címeket `drop`olom egy új tűzfalszabállyal:

/ip firewall address-list add list=DROP address=91.120.89.65
/ip firewall address-list add list=DROP address=46.107.173.131
/ip firewall filter add chain=input src-address-list=DROP action=drop

A logokat végignézve tiltottam egy rakás olyan service IP címét, amik az internetet scannelgetik, pl. Shodan és társai, így ezekben már egy fokkal nehezebb lesz megtalálni a nálam futó serviceket. Viszont a hülye is látja, hogy ez könnyen megkerülhető. A támadó reseteli a modemet és máris új IP-t kap a szolgáltatói DHCP poolból, és ezt eljátszhatja annyiszor, amekkora az a bizonyos pool, amíg esetleg le nem tiltom az egész tartományt.

Utóbbival viszont lehet, hogy tiltanék legitim felhasználókat is, akik megfelelően szeretnék használni az általam nyújtott serviceket.

Jó, akkor tiltom a teljes L2TP felé menő forgalmat és mostantól port knockkal engedem csak a hozzáférést. Ez azt jelenti, hogy alapesetben tiltva van a hozzáférés az L2TP felé, viszont ha egy meghatározott sorrendben, meghatározott portokra kapcsolódunk, akkor felkerülünk egy whitelistre, amiket a tűzfal mégiscsak beenged.

Tehát felvettem a lista végére a tiltást WAN irányból az L2TP portokra:

/ip firewall filter add chain=input protocol=udp dst-port=1701 in-interface=digi-wan-pppoe action=drop
/ip firewall filter add chain=input protocol=udp dst-port=500 in-interface=digi-wan-pppoe action=drop
/ip firewall filter add chain=input protocol=udp dst-port=4500 in-interface=digi-wan-pppoe action=drop

Aztán csináltam 3 szabályt, ami 1-1 address listre felveszi a forrás IP címet, ha egy bizonyos portra jön adat és az előtte lévő address listen már szerepel az IP cím. Ezzel biztosítjuk, hogy a megfelelő sorrendben kell a portokat meghívni:

/ip firewall filter

add action=add-src-to-address-list address-list="port:1000" address-list-timeout=5s chain=input dst-port=1000 protocol=tcp

add action=add-src-to-address-list address-list="port:2000" address-list-timeout=5s chain=input dst-port=2000 protocol=tcp src-address-list="port:1000"

add action=add-src-to-address-list address-list="knocked" address-list-timeout=15m chain=input dst-port=3000 protocol=tcp src-address-list="port:2000"

add chain=input src-address-list=knocked action=accept

Először tehát az tcp/1000 portra kell csomagot küldenünk. Ekkor felkerülünk a „port:1000” listára. Majd küldhetjük a csomagot a tcp/2000 portra. Ha fent vagyunk a „port:1000” listán, akkor így felkerülünk a „port:2000” listára. Végül, ha a tcp/3000-re is csomagot küldünk, felkerülünk a „knocked” listára, amin ha szereplünk, azt a tűzfal mindig átengedi, ezzel megkerülve a korábbi 3 L2TP portokat blokkoló szabályt. (Természetesen nem ezt a 3 portot használom :)) Könnyen bővíthető több port használatára. Arra figyeljünk, hogy lehetőleg legyen alacsony az `address-list-timeout` és a portok ne legyenek növekvő/csökkenő sorrendben, mert azon nagyon hamar végiglépkednek egy ciklussal.

A port knockhoz használhatunk mobilalkalmazást (https://play.google.com/store/apps/details?id=com.xargsgrep.portknocker&hl=hu&gl=US), cli alkalmazást(https://linux.die.net/man/1/knock), de akár a böngészőnket is.

Fontos azt is megjegyezni, hogy a port knock nem valódi védelem és ha túl is jut rajta valaki még találnia kell egy VPN username/password párost, hogy csatlakozzon L2TP-n. Ez csak egy plusz réteg, amivel elrejtjük, hogy van ilyen service.

Itt elgondolkodtam, hogyha valaki be is lép VPN-be, jó lenne tudni róla, így a VPN profil „On Up” részében a következő scriptet adtam meg:

:local FromEmail "[email protected]"
:local ToEmail "[email protected]"

foreach i in=[/ppp active find where uptime <1m] do={
:local Addr [/ppp active get $i caller-id]
/tool e-mail send user="$FromEmail" from="$FromEmail" to="$ToEmail" subject="[PVGA HQ] New VPN connection" body="New VPN connection from $Addr at $[/system clock get time] $[/system clock get date]";
}

Így pedig a router e-mailt küld, amint valaki sikeresen csatlakozik VPN-re:

Web

Rengeteg weboldalt/webalkalmazást üzemeltetek és ezek közül jónéhány a saját privát dolgaim. Amit tényleg csak én/mi használunk a barátnőmmel, azok kizárólag a helyi hálózaton érhetőek el (DLNA szerver, receptkönyv, ilyesmik), vannak viszont dolgok, amiknél fontos az, hogy WAN irányból elérhetőek legyenek.

Például a Home Assistant instanceom. A külső hozzáférés több okból fontos:

• használok olyan cloud-alapú integrációkat, amiknek be kell küldenie adatot a LAN-on futó Home Assistantba
• használjuk a mobil alapú trackinget, amik automatikákat kapcsolnak a GPS pozíciónk alapján
• így működnek a push notificationök távolról is, ami elég fontos, ha pl. a Home Assistant értesít arról, hogy betörtek a lakásba.

Egyszóval kényelmes is, meg hasznos is, de persze egész veszélyes kitenni a smart home rendszered a netre, még ha jelszóval védett is.

Két dolgot is használok ezért ennek a védelmére: Cloudflare-t és nginx szabályokat.

Azt pedig fontosnak tartom megemlíteni, hogy ez a helyi Home Assistant nem közvetlenül van kiengedve az internetre, hanem első körben csak egy VPS számára érhető el egy VPN-en keresztül. Ott nginx-szel reverse proxyval van egy domainen elérhetővé téve és ezen az nginx-en vannak védelmek beállítva.

Egyrészt bekötöttem rá az [nginx ultimate bad bot blockert](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker), ami egy hatalmas listányi IP cím és user-agent alapú tiltás. Rengeteg botot megfog, előszeretettel használom minden általam hosztolt weboldalnál.

Másrészt az nginx tartalmaz GeoIP alapú szűrést. Ehhez egy GeoIP adatbázisra van szükség és [pár sor konfigurációra](https://fedingo.com/how-to-block-ip-by-country-in-nginx/). Fontos, hogy a példával ellentétben a „GeoIPv6.dat” fájlt kössük be, ill. eleve v6-os adatbázist szerezzünk. Ezek tartalmazzák az IPv4 címeket **is**. Ezzel a megoldással a Home Assistantot kizárólag magyar IP tartományokra engedélyezem. Viszlát cloud providereknél hostolt botok, Tor és társai!

Cloudflareben pedig a tűzfal alatt mindig, minden domainem esetén tiltom a Tor hálózatból és Kínából érkező forgalmat.

Ebben azért nem lehet teljesen bízni, hiszen nagyon gyorsan cserélődnek a Tor relayek. Kipróbáltam, ha kb. 1 percen át nyomogatom a *”New circuit for this site”* gombot, találok olyat, amin elérhetőek a weboldalaim a Cloudflare tiltás ellenére. Az előbb, nginxben beállított GeoIP alapú szűrés viszont ugyan úgy megfogja, szóval együtt jó őket használni.

Frusztráló üzenetek hagyása

Rendkívül fontos dolog, amit nem szabad elfelejteni az, hogy mindig hagyj frusztráló üzeneteket a támadóidnak, hogy érezzék, hogy foglalkozol a securityvel.

Ha például a webszervered logjait átnézve feltűnően keresnek egy-egy mappát és minden infó arra mutat, hogy ezt valódi ember teszi és nem jó szándékból, akkor mindig hagyj neki ott meglepetést, ha azt a legitim usereid úgysem találják meg 🙂

Megéri ismert útvonalakra elhelyezni ezeket, hiszen abban a pillanatban, hogy az URLBuster megjeleníti a varázslatos 200-as kódot a path mellett, hackerünk szeme nagyra tágul és örömmel kattint CTRL+clickkel a terminálban hogy megnyissa… hogy aztán azt olvassa, hogy át lett verve.

Egyes contact formoknál a spammereket rickrollra irányítom 🙂

Régebben ZIP bombokat küldtem a különböző hack toolok user agentjei esetén, így hamar ki tudod nyírni a scannelgető script kiddiek termináljaiban zötyögő, Pythonban írt scripteket, de ez sajnos mindig fenntartana egy-egy connectiont a webszerveren és rájöttem, hogy nem érdemlik meg ezt sem.