Mikrotik webezési statisztika

Hálózatok általános

Üdv,

Tud valaki olyan egyszerű módszert Mikrotik router-hez amivel lehet statisztikát készíteni a látogatott weboldalakról és arról, hogy ezt kik követték el, ahol elég a forrás IP. Nem kell ágyú, elég egy faék egyszerű lista is, mondjuk top web-oldalak és top ip-k.

Köszi.

  • 689 megtekintés

( lbandi | 2022. 08. 17., sze – 13:02 )

Igazából csak akkor tudsz ilyet ha proxy-t használsz. Viszont a mikrotik proxy tudomásom szerint nem képez access log-ot. Ha mégis ilyenre van szükséged, a legyegyszerűbb egy alap squid és valami log analyzer, például SARG.

A https forgalom többsége miatt ez elég nehéz lenne, ahogy ezt itt előttem írták. Ha pedig valamilyen IDS-en megy át, akkor nem árt tájékoztatni a népet, hogy bizony a munkahelyi hálózat kizárólag munkaügyre használható, és a felhasználást folyamatosan figyeli "a rendszer".

IP cím alapon nem fogsz messzire jutni, mert egy-egy nagyobb oldalon kívül jellemzően soksok oldal osztozik egyegy IP-n.

A "folyamatosan" sajnos nem igaz, a suricata inline módban random összefossa magát pedig elvileg van az intel kártyához netmap driver, Legacyban meg néha skippel. :) Amúgy meg https-nél nem igazán ad több infot mint a helyi DNS szerver query logja.
Viszont gyorsan kiderül, ha VIP gizi az otthoni pendriveról behozott és duplán kattintott .lnk által letöltött jóság elkezd TOR-zni. :P 

olyanból van itt is pár.. (mmint VIP gizikéből :) )

btw, amúgy elsiklottatok felette, a proxy jó lehet, arra, hogy lehessen látni, hogy milyen domain felé ment az illető. Az IP cím itt a _FORRÁS_ IP címre vonatkozik -> amiből ha van rendes leltár visszavezethető hogy melyik gépen, milyen user ült.

Cél IP monitoringnak én se sok értelmét látnám ilyen esetben.

Anno nálam is futott egy squid + logolt ezt meg azt + sarg generált belőle szép html oldalt, itt volt még user auth is előtte. Soha nem kértek be semmi ilyesmire vonatkozó adatot, bár közölve is volt a dolgozókkal hogy itt ilyen naplózás történik. De ez volt vagy ~10 éve.. Azóta ahogy lentebb is írták https* és tls1.2-3 miatt perpill nem tudom hogyan is nézne ki ez a cucc squid proxy-val megoldva.

Az op gondolom olyasmire kiváncsi hogy milyen weboldalaok bóklásznak az emberek munkaidőben, melyik gépről. ennyi. 

( arpi_esp v | 2022. 08. 17., sze – 13:15 )

Szerkesztve: 2022. 08. 17., sze – 13:17

hat a https miatt nem is nagyon lehet mar ilyet csinalni... es ma mar alig van weboldal ami nem https.

tls 1.2-ig ugye volt az a trukk hogy belenezel az ssl handshake-be es legalabb a domaint ki lehetett onnan nezni, de amennyire tudom 1.3-nal mar az is titkositva megy...  de sztem ezt is csak a cisco tudta, meg 1-2 linuxos ids, a mikrotik nem.

masreszt manapsag mar sokra nem is mennel az infoval, mert akar egy index.hu is tele van pakolva facebook stb kulso hivatkozasokkal, masreszt szinte minden komolyabb oldal reszben valamilyen CDN-rol toltodik.

tolem ugy 10 eve kerte 2 ugyfelem hogy monitorozzam nekik a dolgozok weboldal szokasait, de mar akkor se volt kb semmi haszna.

Yes, the full URL string is hidden, and all further communication, including the application-specific parameters.

However, the Server Name Indicator that is formed from the hostname and domain name part of the URL is sent in clear text during the first part of the TLS negotiation.

The Server Name Indicator is used so that the endpoint server can know to which virtual server the connection is supposed to address. This information gives the knowledge necessary in the choosing of the certificate needed to correctly identify itself and the correspondent private encryption key.

https://www.baeldung.com/cs/https-urls-encrypted

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

igen, ez volt tls 1.2-ig. "TLS v1.3, the current and recommended version, has a proposal to encrypt the ServerName. "

bar ugy latom ez meg opcionalis, de pl. a cloudflare mar hasznalja 4 eve:

https://blog.cloudflare.com/encrypted-sni/

igen, nem fasza, hogy ennyire ők fingják a passzátszelet. Vannak nekik jó dolgaik, de egyrészt azért nem minden fekete fehér, másrészt valahogy mindig olyat sikerül kitalálni, amihez azért véletlen kell egy jóóó kis adatbázis.

Ez a konkrét eset egyébként időnként simán a visszafele tud elsülni. Eddig elég volt a szűréshez az sni-t nézegetni, most meg adott esetben majd az enterprise IT jobb híján tényleg proxyzni fogja a teljes TLS sessionöd.

( gyuri23 | 2022. 08. 24., sze – 12:46 )

Köszi eddig mindenkinek.

Van esetleg olyan opensource megoldásra ötlet ami "konyhakész" és nem kell pilótavizsga a beüzemeléséhez?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( peterdif | 2022. 08. 24., sze – 16:26 )

Ezt mikrotikkel lehet nem oldod meg, de érdemes átfutni az alábbi linket, hogy tiszta legyen a tls 1.3 mivolta és hogy hogy megy a "kibontása" a proxy-n.

https://www.zscaler.com/blogs/product-insights/tls-13-busting-myths-and-debunking-fear-uncertainty-doubt

"True inline SSL proxy" esetén (összekötött kliens-proxy és proxy-server kapcsolatokkal) ez nem megugorhatatlan és csak ezzel tudod biztosítani hogy kártékony oldalakat ne látogassanak, lássad hova mentek, mit töltöttek le -ha vírus blokkold, milyen linkre akarnak a kapott e-mailből kimenni,... természetesen bizonyos kategóriák (egészségügy, bank, kormányzat,... ) bypass-olva szokott lenni az SSL inspection résznél.

Teljesen alap secu szolgáltatás kell hogy legyen ez egy cégnél. Enélkül eléggé vakrepülés a dolog.

Szerintem....

Nem értem a kérdést? Mi a probléma?

Igen létezik ilyen, de eddig kb 1 spanyol kormányzati weboldalon futottunk bele.

A weboldalak 99,99% nem használ ilyet, emiatt nagy felelőtlenség azt mondani, hogy nem használsz egy ilyen fontos security kontrollt. 

Felveszel egy exception-t rá a konfigban arra az oldalra (természetesen jóváhagyatás után) és meg is van oldva. Már ha alapból a kormányzati oldalak kategória alapján nem voltak bypass-olva. 

Sajnos van friss, élő példám is, de mivel még folyamatban van az ügy sokat nem mondhatok, bár nagyon tanulságos....

Ha egy IT-s dönti el hogy kell-e "rendes" web gw/proxy annak általában sírás lesz a vége....lett is.

Lehet, de mi a gond?

Felveszed kivételnek, ha ezt engedni akarod, hogy kontroll nélkül tudjanak ki és letöltögetni dolgokat, meg elcseszni az idejüket felesleges dolgokkal - nem mindenhol szokták engedni, mert munkahely. A CISO majd eldönti, az ő felelőssége. 

Ez arról szól, hogy lehetséges kártékony kódokat tartalmazó mindenféle "fisz-fasz" oldalakat blokkolni tudj még ha TLS-es titkosítás is van rajta. Ha egy kártékony/megütött oldalra pinnelnek certet akkor ezt csak akkor tudja az user-ed elérni ha kivételben beállítod neki, aki meg jóváhagyja ezt, az megnézni hogy mi az oldal és miért kell a user napi munkájához. Van kontroll a dolog felett és ez a lényeg. A technológia adott, egy folyamatot kell csak köré tenni és működik.

Egy lista a cikk végén a használókról. Nagyok, de nem túl sok site az intenet összeségéhez képest.

https://help.zscaler.com/zia/certificate-pinning-and-ssl-inspection

Egy része a céges forgalomnál lehet alapból "trusted", ha pl O365 használók vagytok, a másik része meg tök felesleges, blokkolható (Xbox live, Blizzard online games,..)

+ a nagyokra, ha cégként használod CASB-t szoktak alkalmazni, az egy kicsit jobban belelát mint egy proxy.

Meg mostanában ilyen/olyan ingyenes "pagebuilder" vackokra teszik a jelszóbekérőt , így még csak wordpresst se kell törni hozzá. :D 

Van egy újabb magyar kopogtató is (többek közt ezért nem teszünk vacak kínai kamerát/nvr-t közvetlen internetre)

https://www.abuseipdb.com/check/91.82.76.141