Web proxy szerver (appliance?)

Hálózatok általános

Sziasztok,

Keresek szoftver megoldást, vagy web proxy appliance-ot egy 100-200 végpontos hálózat internet használatának szabályozásához.

Minimális elvárás, az ACL kezelés és karbantartott URL kategóriák, amivel az egyes felhasználói
csoportok internet használatát lehessen korlátozni. (pl. XY csoport social media engedélyezett, pron tiltott. )

Előny ha nem kell sokat reszelni a beüzemeléshez, úgyhogy kereskedelmi termékek és hardware appliance-ok is szóba jöhetnek.

Köszönettel vennék pár javaslatot + tapasztalatot.

  • 1597 megtekintés

( zeller | 2019. 02. 06., sze – 09:30 )

Dansguardian++Squid? Esetleg egy ClamAV/Eset betolva a kettő közé? Vagy ez túl ódivatú stack manapság? Ha az, akkor engem is érdekel, hogy ki, mivel rakna össze egy ilyet :-)

Nálunk is ez megy, de én is vadásznék jobb, hatékonyabb megoldásra. A mai SSL-es világban nem érzem túl hatékonynak és UX szempontjából használhatónak :/

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( zrubi v | 2019. 02. 06., sze – 09:45 )

Squid + a neked szimpatikius filter lista (előfizetés)
(én ezt preferálom, mert össze tudom kalapálni, és az igényeimhez igazítani)

Ha előre összerakott appliance-ként szeretnéd inkább:
http://www.squid-cache.org/Support/products.html

Vagy ha full Enterprise megoldás kell,
szinte mindegyik nagy gyártónak van web proxy doboza.
(persze ezek szinte kizárólag zárt cuccok, és enterspájz árcimke van rajtuk ;)

--
zrubi.hu

Pont arra lennék kiváncsi, hogy mik a tapasztalatok az enterprise cuccokkal.
Raktam már össze ilyet squid-al, meg pl. Artica proxy-val is játszottam, de ezt most nem feltétlen a reszelés kategóriája.

Nincs túl sok rááldozható időm, előfizetéses kulcsrakész megoldások érdekelnek - mivel ilyenekkel nincs tapasztalatom.

( godot v | 2019. 02. 06., sze – 09:49 )

A baj az, hogy normálisan karbantartott/frissített Open Source URL adatbázist nem nagyon fogsz találni, szóval arra mindenképpen előfizetés kell. Egyébként a PfSense-ben vagy OPNSense-ben is van Squid plugin ami viszonylag könnyen összekattogtatható.

Vagy valamilyen Enterprise megoldás (Websense, Cisco WSA stb) végtelen pénzért.

( quash | 2019. 02. 06., sze – 09:52 )

Minden gyártónak van merre UTM-je vagy hasonló megoldása.

Egyetlen dolgot viszont ne felejts el!, csak HTTP korlátozása már nem elegendő.
HTTPS-nél viszont már jogilag is rendbe kell rakni a dolgokat!

Ha te építesz squid-al teljesen használhatóan meg lehet csinálni, ez kb. platform független, SSL bump-ot kell jól körüljárni, nem minden tanúsítványt cserélhetsz le!
És innentől Man-in-the-middle, amit ahogy írtam jogilag kezelni kell.

Ez csak user függő.

De egészen biztosan észrevehető, mindegy hogy csinálod.

A legtöbb (l)user akkor sem kezd gyanakodni, ha a böngésző sikitozik neki tanúsítványhiba miatt.

De enterprise környezetben is sokszor látok olyat, hogy dokumentációban és/vagy tréning anyagban van instrukció arról, hogyan halgattasd el a böngészőt, ssh klienst.

Vagy még durvább, ha a cég által letolt böngésző config van lebutítva a saját szaraikhoz.

--
zrubi.hu

Az elsőre 2016-ban még azt írták, hogy ha telepítve van a kiállító tanúsítványa, akkor nem bajlódik vele a böngésző, lehet azóta már komolyabban kezelik ezt.
Amúgy vannak olyan fizetős tűzfalak, amik állításuk szerint ki tudják bontani a forgalmat és újracsomagolni. Valóban nem tudom, hogy csinálják, de valahogy csak sikerül nekik, lehet hogy kell hozzá böngészőbővítmény, valamint a Barracuda esetén írják, hogy püfölni kell valamit a GSuite használatához, de valahogy megoldják.

Key Pinning nem csak böngészőben van, hanem mondjuk egy mobilappban. Ismerek olyan mobilalkalmazást, ami validálja a tanúsítványlánc alapján, hogy tényleg ahhoz a szerverhez csatlakozik, akihez kellene. És máris használhatatlan az alkalmazás, ha a munkahelyi BYOD wifi kapcsolaton is csinálsz HTTPS szűrést.
Meg kell érteni, hogy HTTPS-t nem csak böngészők használnak, hanem sok esetben natív appok is adathozzáférésre. És ha kritikus az adat, akkor ott bizony szükséges a rendes key pinning.

Key Pinninget nem csak így lehet ám csinálni. Elkéred a TLS kapcsolat során az ellenoldali fél által bemutatott certet, és ellenőrzöd, hogy az megfelel a nálad tárolt certtel. Ennyi az egész. Javaból, Kotlinból, Swiftből, Objective-C-ből ezt meg tudod tenni, van rá API. Ennyi az egész, nem kell abban gondolkodni, hogy aki a HTTP kapcsolatot kezeli, az mindenképp a browser.

( bennyh | 2019. 02. 06., sze – 12:40 )

Ha nincs se idő, se anyagiak, akkor IPFire. Domainnév alapú blokkolást tud SSL mellett is, tud frissíteni tiltólistát, https intercept és IPv6 támogatás nincs, az elsőt nem is tervezik a második majd talán a 3-as főverzióban, egyébként kezes jószág.
Ha van rá lelkes emberke aki szeretné elütni az idejét, csak pénz nincs, akkor ott a PFSense.