layer 7 szűrés

Hálózatok általános

hello

Javaslatokat szeretnék kérni ahhoz, hogy tudjak szűrni oldalakat layer 7 szinten. Router vásárlásban is benne vagyok, vagy esetleg szoftveres megoldásban is.
Mit javasoltok hogy lehetne normálisan megoldani? A cél hogy tudjak egyes oldalakat letiltani a kliensek számára (kb 50-60) pl: facebook, youtube, híroldalak stb.

  • 4881 megtekintés

( mackosajt | 2016. 10. 03., h – 19:02 )

A Mikrotik termékek képesek erre. Szerintem tulajdonképp bármelyik, talán csak az erőforrás miatt kellene egy erősebb procival szerelt.

Ha jól emlékszem mikrotikban csak url-re lehet szűrni nem contentre ami könnyen kijátszható. Anno egy Rb1100-ason használtam és megizzasztotta a vasat rendesen. Az áteresztő képesség kb a felére esett vissza. Utána beruháztunk egy UTM-re ami tökéletes ilyen és egyéb extra célokra.

( ang | 2016. 10. 03., h – 19:18 )

valamilyen lokalis dns szervert, amely nem engedi resolvalni megadott hosztokat

vagy http proxy-t, ami url alapjan tilt

( mauzi v | 2016. 10. 03., h – 19:38 )

facebook, youtube HTTPS fölött szeret menni, tehát azt egy "sima" HTTP proxyval nem fogod megfogni. Én kezdésnek leginkább DNS irányból támadnám a problémát.

( zrubi v | 2016. 10. 04., k – 09:47 )

röviden:
Good Luck!

Bővebben:

Sokan sokféleképpen próbáltak és próbálnak ilyesmit kivitelezni, de szinte mindegyik megoldás elvérzik valahaol.
A legfőbb kérdés, hogy ki ellen akarsz védekezni.

Van aki ellen már a DNS alapú "tiltás" is elegendő. De kicsit több tudással bíró userek mindig találnak kerülőutat, bármhogy is próbálod ezt megakadályozni.

Természetesen, létezik "tökéletes" megoldás, ám azt a userek nem fogják szeretni, Neked meg nem lesz elég erőforrásod üzemeltetni. És a főnök gépével meg majd mindig kivételezni kell.

A gyakorlatban sokkal hatékonyabb, ha kihirdeted hogy a netezés logolva van, Te pedig megnézed havonta a top 10-20 site-ot, és az érintetteknek felhívod a figyelmét arra, hogy ezt nem kéne munkaidőben.

A logolást bármilyen HTTP proxy megoldja neked
(a HTTPS oldalak esetén is)

Szerintem.

--
Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion
zrubi.hu

( godot v | 2016. 10. 04., k – 13:34 )

Ahogyan írták tökéletes megoldás sosem lesz , ha van pénz rá akkor venni kell egy ún "NGFW" bullshittel ellátott tűzfalat, ami vagy proxy vagy valamilyen DPI technológiával szűr. Sajnos az open megoldások amellett, hogy nagyon jók lehetnek technológiailag a megfelelő (free) szignatúra/alkalmazás adatbázis(ok) hiányán véreznek el ezen a területen legtöbbször.

Egy két érdekes "kezdeményezés" azért a témában ami nem proxy alapú:

http://www.ntop.org/products/deep-packet-inspection/ndpi/

Netfilter modul hozzá:

https://github.com/betolj/ndpi-netfilter

Snort OpenAppID:

http://blog.snort.org/2014/03/firing-up-openappid.html

Libprotoident:

http://research.wand.net.nz/software/libprotoident.php

Egy-két összehasonlító elemzés a DPI-kről:

http://www.ac.upc.edu/app/research-reports/html/RR/2014/1.pdf (460 oldal!)
http://tomasz.bujlow.com/publications/2014_journal_elsevier_comnet_inde…

Ezek sem érnek sokat, köszönhetően az "SSL everywhere" irányzatnak:

Mivel SSL/TLS URL-ek szinte mindenhol ki vannak engedve. Jobb helyeken is csak blacklist-en lévőket tiltják, esetlegesen. Ez a gyakorlatban azt jelenti, hogy bárki bárhonnan egy random 3rd party szerveren a 443-as porton futó, TLS-t beszélő proxy/VPN/akármi megoldást használva röhögve kikerül mindenféle kitiltási kísérletet. Mivel ezek ugyan azt a TLS/SSL-t beszélik mint egy "safe" HTTPS-es webszerver, így csak MITM implementációkkal lehetne belenézni/korlátozni, ami pedig legtöbb országban a helyi jogszabályokba ütköző, és büntetendő cselekedet.

Ezellen egyetlen megoldás létezik:
- DNS-t csak a saját helyi szervertől lehet kérdezni,
- csak a helyi saját proxy-n keresztül lehet internetet elérni, ahol:
* HTTP oldalak blacklist/WAF szűréssel,
* HTTPS oldalak csak ellenőrzött whitelist alapján kiengedve.

Itt az utolsó pont kivitelezése szinte lehetetlen, de ha megoldod valahogy, akkor is még van még lehetőség a kikerülésére: MIFI és/vagy mobil hotspot, mobilnet, "szomszéd" WiFI

Persze ezek tiltása/korlátozása már egészen más téma.

Sőt, bátran tippelem, hogy az eredeti probléma valójában nem technikai megoldást igényel.

--
zrubi.hu

Egyetértek. MITM témában sem vagyok otthon a jogszabályokban, ha aláíratod, hogy megfigyelik a titkosított forgalmat (mondjuk a bankok, ügyfélkapu azért whitelisten vannak, vagy eleve MITM whitelist van, minden más HTTPS tiltott) akkor is jogszabályba ütközik?
Az összes nagy FW gyártó tud SSL MITM-et, szóval igény az van rá látszik.
Egyébként az nDPI ben is van SSL dekóder, hogy hogyan működik azt nem tudom.
Mondjuk a BYOD ellen nem véd semmi, ha az user munkaidőben netezni akar megoldja.

Nem vagyok jogász, de szerintem ilyen esetben nem csak a kliens oldaltól kell(ene) beleegyezés. A szerver oldal meg nyilván nem fog beleegyezni.

(mondjuk meglátásom szerint a jogszabályok ~10 éves lemaradással, és a politikus szintű informatikai tudással "keletkeznek". Ennek megfelelően (IT Security) szakmai szemmel egytől egyig röhelyesek)

--
Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion
zrubi.hu

( Sea-you | 2016. 10. 04., k – 13:38 )

Websense, BlueCoat, de biztos vannak olcsobb megoldasok is.

( connor v | 2016. 10. 04., k – 14:48 )

sub.

nekem most a fordítottját kell megoldanom. x db oldal mehet, más nem.

( uid_720 | 2016. 10. 04., k – 17:30 )

Layer 7? Az már a user, nem? :-D
Ma már ennek a tiltogatásnak nem sok hasznát látom, mindenkinek ott a zsebében egy okostelefon. Ha nem lehet gépen facebookozni, akkor majd telefonról fognak.

Fuszenecker Róbert

( freeoli v | 2016. 10. 05., sze – 07:18 )

Mekkora a keret?

Sophos UTM es Dell SonicWall eszközökkel sokat csináltam L7, alkalmazás szintű szűrést, kész termékek, csak konfigurálni kell.

Free ben opnsense ami szoba jöhet, de nem garantál az sem.

A dpi nem jogi, hanem biztonsagtechnikai kérdés. A jelen támadások jelentős része https-en kerül be a klienshez, vagy dpi vagy no https.