Tartalomszűrés iskolában (Squid+dansguardian https passthrough problémák)

Web, mail, IRC, IM, hálózatok

Hello,

A jelenlegi felállás a következő (Az eredeti topic: https://hup.hu/node/85847) :

Adott egy squid3+dansguardian kombó, ami a default gw minden gépnek. A http forgalom ezen van áteresztve, a https pedig a proxy-t megkerülve megy tovább.

Mivel azonban 2020-at írunk és a forgalom jelentős része https-en keresztül zajlik valamit lépnem kellene ez ügyben.

A squid-ot nézve ssl_bump-ot nem szeretnék. Szóba jöhet még egy tiltott site lista esetleg illetve a szűrés mellett az OpenDNS alkalmazása.

A dansguardian esetében annyi elég volna, ha a tiltott site-okat meg tudná nézni, de úgy látom by design (Installation#6 Installation#6b) ez nem fog menni.

Egyelőre ennyire jutottam. 

Ti hogy csinál(n|j)átok ?

Köszönöm előre is a javaslatokat!

  • 955 megtekintés

Arra figyelj hogy jön az encrypted SNI, ehhez DNS támogatás szükséges, amit saját DNS szerverrel tudsz elvileg tiltani valahogy, még nem néztem utána. Közismert DNS szerverek (8.8.8.8, 1.1.1.1, 9.9.9.9) forgalmát eltérítheted saját DNS szerveredre, további DNS forgalmat blokkolhatod. Ez után már csak a DNS over https/tls-t kell valahogy blokkolni, és nagyjából készen vagy.

A klienseken a saját DNS szerver van megadva, módosítási joga nincs senkinek (ez egy általános iskola). Persze idegen gépről olyan DNS-t ad meg amit akar, de diák nem hoz ide ilyet. A telefonnal meg, ha van mobilnetje, akkor nem tudok mit kezdeni. Ha a public wifi-re csatlakozik, azt meg szűröm ugyanígy.

Ez után már csak a DNS over https/tls-t kell valahogy blokkolni, és nagyjából készen vagy.

Ezen kívül lehet bontani a rendet ingyenes proxyval, web archive segítségével, tor-on, vpn-nel, extrém esetben az ssh kapcsolat otthonra, és onnan netezgetés megoldással is.

Psszt, elárulom az IP-címemet: 192.168.0.14

( pt56 | 2020. 09. 13., v – 07:56 )

Én a dansguardian helyett az E2guardian-t próbáltam ki, az tudja az SSL-MITM működést, és tényleg működött is.

De csak ott működik, ahol minden kliensre ki tudod telepíteni azt a CA-t, amivel az ssl site-ok fake cert-jeit generálja működés közben. Ha nem tudod az összes csatlakozott klienst ellenőrizni, akkor ez nem opció, ahol ez a CA nem megbízható, ott folyamatos tanúsítványhibát fog eredményezni.

Csak megnéztem, működik-e, és ha igen, akkor hogyan, bevezetésre nem került (én nem vagyok híve ezeknek a megoldásoknak). Különben sem az én dolgom a technikai megoldások jogi részével birkózni, ha ilyet tényleg meg kell valósítani és bevezetni, akkor alaposan körbe kell járni a témát biztosan valami hozzáértőnek.

Lennének eszközök, amik tudnak SSL Interceptet, de nem másolják át a rendszergazdi mappájába a jelszavakat :), csak a tartalomszűrést végzik egyedi szabályok alapján, valamint vannak víruskergetők központi managementel és ugyanúgy ki tudják csomagolni az SSL-t (Eset pl). Csak az első körbe tartozó eszközök drágák és telepíteni kell certeket a kliensekre, utóbbihoz meg vírusirtót, ami mobileszközöknél szintén problémás.

Két hálózat lenne jó. Az egyik a belső, tantermi eszközökhöz pl, és kell ugye a fentebb említett eszközök valamelyike.

Vendég hálóhoz meg DNS szűrés megoldható külső DNS szolgáltatóval is:

https://geekflare.com/dns-content-filtering-software/

Tűzfal disztró, ami bevet mindent, ami nem SSL túrkálás:

https://www.ipfire.org/

( sfeher v | 2020. 09. 14., h – 12:33 )

Ahogy írtam is a topic indítóban, nem szeretnék MITM megoldást. Összeraktam pár teszt konfigurációt. Majdnem jók, de mindegyik elhasal azon, hogy a tiltott https oldalt felkeresve  ERR_TUNNEL_CONNECTION_FAILED jön, hibaoldal helyett. Ez természetesen jogos és lehet, hogy megbékélek vele. Valahogy most azt látom, hogy openDNS+safesearch kikényszerítése lesz a megoldás. 

de mindegyik elhasal azon, hogy a tiltott https oldalt felkeresve  ERR_TUNNEL_CONNECTION_FAILED jön, hibaoldal helyett.

Ez elméletileg sem lehet másképp. Ha nincs MITM és a kliensekre lerakott saját root CA, akkor csakis az eredeti weboldal a saját certificate-jével adhatna bármilyen választ, pl. hibaoldalt. Pont ez a lényeg, hogy nem tud beépülni senki a kapcsolatba, és másfajta választ visszaadni, mint amit az eredeti weboldal adna. Az egyetlen lehetőség, hogy a köztes proxy megszakítja mondjuk TCP szinten a kapcsolatot.

( sfeher v | 2020. 09. 14., h – 14:40 )

Igen, értem a működést :). A proxy nem tud mást tenni.

( freeoli v | 2020. 09. 15., k – 16:51 )

Az SSL kapcsolat újracsomagolás és vizsgálata az egyetlen lehetőséged, hogy az adataikat és az intézményt tényleg hatásosan tudd védeni. E nélkül fölösleges erőlködni, egyedül DNS és DoH tiltás melletti külső és szakosodott DNS szolgáltató segíthet, esetleg egy olyan proxy ahol whitelist-en gyűjtöd azt amit meg lehet nézni.

Az SSL/TLS egy rendkívül jó technológia, nem csak a bakkártya adatok biztonságban tartására, de kártevő böngészőig tartó észrevétlen eljuttatására is és a nagy bajok itt kezdődnek.

A NISZ-nek nincs erre megoldása vagy ajánlása?

Teljesen igaz amit mondasz. Jó megoldást enélkül nem tudok adni, de legalább közelíteni szeretnék hozzá. A fő csapásirány a felnőtt oldalak szűrése. Minden más ami MITM nélkül elérhető az hab a tortán.

Egy 2015-ös ajánlást találtam. https://sulinet.niif.hu/sites/sulinet.niif.hu/files/sulinet_tartalomszu…

Eléggé vegyes a kép...