DNS tunelling: észreveni, megakadályozni. Oké, hogyan?

Hálózatok általános

Szeretném elkerülni, hogy a hálózatunkból DNS-en keresztül információt lehessen kiszivárogtatni. Ahogy agyalok rajta, ez nem tűnik egy triviális feladatnak (a whitelist nem oké). Egyelőre szigorúan elméleti szinten, azaz feltételezve hogy minden (is) adott, milyen megoldások léteznek? Bár jó lenne, ha pl. nem kéne érte fizetni (mert elsőnek a szűrt, biztonságos DNS-t adó szolgáltatók jutottak az eszembe, bár kérdés, hogy efféle ellen védenek-e).

  • 2762 megtekintés

( slinky v | 2018. 08. 27., h – 14:49 )

elkapod tcp/udp 53 es redirecteled a rekurziv NS-re?

( szollosiimre | 2018. 08. 27., h – 15:00 )

IPS, APP kontroll.

Tűzfala válogatja.

Najó, ennyi erővel azt is írhattad volna, hogy google.

Ha mondjuk azt írtad volna hogy Suricata, akkor azt mondom hogy oké, de kéne hozzá legalább egy minta (ez nem minta, ez muhaha: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/protoc…), mert talán nem egyértelmű, de nem nagyon vagyok otthon a témában.

Azért mondtam ezt, mert egy normál NGFW-ben az összes szignatúra benne van. Kezdve az iodine-el, meg a többivel. Kérdés mennyire használható.

https://www.researchgate.net/figure/Iodine-specific-Snort-Rules-The-two…

Amugy ezek a snort rule-set-ben is benne vannak. UGyanakkor mivel DNS-ben közlekedik TXT rekordokban, ezért a DNS csomagok ésszerű korlátozásával ( AKA DOS szenzor ) is lehet eredményt elérni.

https://hup.hu/node/160594?comments_per_page=9999#comment-2260487

Hint: a TXT rekord szóba se kerül, egyszerű A (NS, valami) lekérdezésről van szó. És nem, nem közismert szoftver, hanem egy egyedi fejlesztésű, tulajdonképpen kémszoftver, amit a gyártó aliglegálisan hegesztett a termékébe, amit mi idióták megvettünk, és azóta csak a baj van vele.

Ugyan a konkét témához nem értek, de így a hozzászólásokat olvasgatva az jutott eszembe, ha esetleg leírnád részletesen a problémát, elmagyarázva, hogy mi az, amit nem akarsz, mi küldi, hová, hogyan, és mi jellemző ezekre az üzenetekre, akkor azok az emberek, akik értenek ehhez a témához, bizonyára tudnak értelmesen válaszolni jó ötletekkel.

Az alap felvetésed elég általános volt, részletek nélkül, valószínűleg ezért kaptál ilyen általános válaszokat.

Az egyik baj az, hogy pontosan nem tudom, mert valamiért (hehehe) a szoftverek gyártói nem írják le hogy mit csinálnak. Amit tudok, az jórészt reverse engineering (wireshark) és találgatás. Emiatt a "mi küldi" részt se nagyon akarom kifejteni. A maradék meg olyan, hogy egyelőre ilyeneket találtam: https://hup.hu/node/148757?comments_per_page=9999 (illetve ehhez hasonlóakat, más alkalmazásokban, más domainnal).

Sajnos ennél jobban nem részletezhetem.

( lavian v | 2018. 08. 27., h – 19:39 )

En valami proxy iranyba mennek, ami beszeli a DNS-t es ismeri az RFC-ket korulotte. Beallitani, mint forwarder-t es megnezetni vele a payload-ot. Ha nem oda valo, kib@szni, mint cirmost, ha sietos neki az alomra.
Emlekeim szerint a Zorp csapat talan tud ilyent, de keress utana kerlek, mert reg volt vele dolgom.

Vagy naplozod a DNS kereseket es ha egy kliens mondjuk 10 perc alatt tobb mint 100 kerest indit egyazon iranyba, egyszeruen lenyomod a kapcsolatat, vagy kuldetsz magadnak egy mail, vagy az illetekes megmondonak. Erre akar a fail2ban is jo lehet es egy sima iptables log rule.

'Deep packet inspection' a kulcsszo hozza.

De ha mar itt tartunk: van egy teljesen jol mukodo tuzfalad, ami blokkol minden tunnelinget. Fogom magam es teljesen legitim keresekkel elkezdek lekerdezni hostokat egy letezo domainbol. Mondjuk 1-3 perces idokozonkent egyet. De akar 20-30 domainbol is. Hibara futnak, vagy nem, de ez mindegy is. A lekerdezesek es azok sorrendje is adhat ki informaciot es meg csak blokkolni sem tudod, ha csak a tunnel szurese a cel.

Ezer modon lehet kivinni az infot, ha van kimeno engedelyezett kapcsolat.
(Beleirom egy banki atutalas kozlemenyebe, amit szeretnek. Elotte gondosan valasztott bank, ahol ellenorzik, hogy nem cserelt-e a cert egy helyire es innentol nem tudod szurni proxyval. Fontos ember vagyok, kisirom magamnak az elerest.)

Whitelisttel. Az egyik dolog amire gondoltam, hogy a whitelistet valahogy rászögelem a DNS-re is, de az kényelmetlenül megbonyolítaná a jelenlegi konfigot.

Addig volt vidám az élet, amikor még wiresharkkal megtaláltam a payload POST kérését. De most próbálok mindenféle, a hálózatot nem dögre lövő módszert találni az esetleges emberi hiba kivédésére.

Nalunk is van (lokaciotol fuggoen), onnan tudom hogy letezo jelenseg. Csak hat megis MITM ugrik be mikor pl. a hup.hu-t megnezem, es nem a Let's Encrypt altal sign-olt certi jon be, hanem ceges.
Mondjuk amig van ssh kifele addig van megoldas erre :)
____________________
echo crash > /dev/kmem

( Zahy v | 2018. 08. 27., h – 20:55 )

Hogyan jut ki az infó? Csak mert már olvastam olyat, hogy magának a hostnak a lekérdezése a szivárogtatás - azt pedig ha egyáltalán kiengeded (vagy akár proxyzod) a kérést, máris átjutott az adat. De ha nem ez ellen akarsz védekezni, akkor simán nem engedsz ki natívan kérést, csak a saját szerveredtől, és mindenki más meg őt használja.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( bennyh | 2018. 08. 28., k – 07:53 )

Lehet nagy hülyeséget írok, de feltétlenül el kell érnie a klienseknek a DNS szolgáltatást? Mi van ha csak a tartományi DNS-t érhetik el, annak meg blokkolod, hogy kifele használjon bármilyen forwardert. Egy Webproxy használatához meg nem kell DNS szerver, elég ha maga a webproxy ér el egy DNS szervert, hisz a kliens átpasszolja neki a címet, ha nem transzparens proxy-ról beszélünk. A Proxy-ra meg kell valami whitelist, hogy ha kifele akar üzenni bármi, ne tudjon, mert az ismeretlen URL-eket kapásból eldobja a proxy névfeloldás nélkül. Ugyanúgy levelezéshez meg sok más szolgáltatáshoz se kell, hogy az interneten bármely DNS szerverrel kommunikáljanak a kliensek, elég nekik a tartományi névszerver.

Remélem nem írtam nagy hülyeséget.

Az a baaaaaj, hogy a használt - mondjuk - 312 szoftverből 310 tökéletesen megy http(s) proxy-val (még ha esetleg kicsit tákolni is kell). De mindig van 1-2 olyan, amit egyrészt muszáj használni, másrészt meg az istennek se akar proxy-t figyelembe venni/használni. És nem is tehetjük meg hogy nem használjuk ezeket, mert már mittoménhogymik, de kellenek.

Meg mindig akad egy-egy kivétel, ami azértse akar valami normális protokollt beszélni, és akkor egy hülyeség miatt vagy lyukasztgatom a tűzfalat, és/vagy megőrülök.

( Proci85 v | 2018. 08. 28., k – 09:11 )

Új ez nekem. Jól értem, hogy arról van szó, hogy egy program felolvassa az fájlt, esetleg base64-gyel kódolja, darabolja és a darabokat aldomainként meghívja, amit a túloldali webszerver logol, összerak?

Valahogy a fő domain-t, a whatever.com-ot kellene kiiktatni.
Az első lépés szerintem az, hogy a helyi dns forwarder kivételével minden 53-as portra/ról menő forgalmat blokkolsz (vagy elegánsan átirányítasz a saját dns forwarder-edre). Aztán a helyi dns forwarder-t beállítod úgy, hogy ő authoritative legyen a wahtever.com domain-re, azaz a kém sw-nek azt adná vissza, hogy a whatever.com NS rekordja ő maga. Ezután a kém sw a s00diufajf45238967897jhd28942752d576.whatever.com kérésre szépen megkapná az NXDOMAIN-t, aztán jóidő. Persze nem árt logolni a DNS kéréseket se, mert ha van whatever2.com, whatever3.com, stb., akkor az így ki tud bukni.

Sajnos a frissítéseket követnünk kell. Bár van, ahol még a öt évvel ezelőtti verziót használjuk, máshol meg a tegnapit már elavultnak nézik.

No mindegy. Már annyiból hasznos volt a számomra, hogy eddig bele sem gondoltam, hogy a statisztika alapú felfedezés az alapvetően használhatatlan. Eddig is kémkedtek a gyártók, ezután is fognak. Én meg túl sok energiát nem akarok beleölni, mert nincs értelme (inkább csinálok rendes wifit a cégnél, annak több haszna van, de azt a kérdést majd holnap teszem fel :D).

Mondjuk ha Bind-ot használsz akkor a fenti leírás helyett lehetne inkább RPZ-t használni és akkor egyszerűbb a konfig és egy köteg dolgot meg lehet vele még csinálni.

https://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-l…

http://www.zytrax.com/books/dns/ch7/rpz.html

https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls…

( zrubi v | 2018. 08. 28., k – 10:58 )

Feltételezem, hogy a klienseid nem tudnak direktbe kikérdezni, csak a local forwardere(ke)n kersztül.
Ezesetben észrevenni a legegyszerűbb, ha a kimenő DNS kéréseket logolod, amiből kimazsolázod a tunnelingben használtakat. pl a TXT, és/vagy a gyanúsan hosszú, random nevek.

De IDS/IPS is segíthet, felteszem van már kész snort rule erre is, bár biztosan nem adják ingyen.
Ez akár ki is tilhatja a nem valid forgalmat.

--
zrubi.hu

Az a baj ezekkel, hogy ja, felsorol egy csomó lehetséges detektálási módszert, viszont egyik sem tökéletes, és némelyikkel elég sok meló van (pl. nézzed a szemeddel "It has been shown that Visualization can be used for detecting DNS tunnels"). És sok csak jó idő után veszi észre hogy jajajj van, mert statisztikai adatokat elemez. Úgy tűnik, hogy az efféléhez annyi befektetett munka kell, amennyit nem ér meg.

( fairlane | 2018. 08. 28., k – 14:29 )

Ha befekteted a munkád vagy megbízol egy szolgáltatót/specialistát, szakértőt/stb... az is pénzbe kerül.
Itt szokott jönni a kockázatelemzés, azaz hogy egy adatvesztés vagy -szívárgás kerül-e többe, mint maga a védekezés ill. megelőzés.

--------------------------------
...úgyis jönnek...