A ve finale zjistime, ze ucetni prestal fungovat pristup do banky, nakupnimu oddeleni objednavkove systemy nekolika dodavatelu, a rediteli jeho oblibeny web o golfu ...
S weby o golfu a objednavkovymi systemy problem s nejvetsi pravdepodobnosti nebude. Bankovniho klienta resime statickou DHCP rezervaci a odpovidajicim pravidlem na firewallu, kdy povolime primo pouze konkretni komunikaci pro skupinu stanic. Jediny problem je paradoxne legislativa. V Rakousku je napriklad zakazano ukladat historii komunikace zamestnancu (je mozne, ze to je pouze specifikum odboru u nasi matky). K predchozimu dotazu ohledne ACL - mel jsem v planu to vzit pouze okrajove, ale je to take zajimave tema, mozna se mu budu venovat vice.
Pouzitim statickej DHCP + konfiguracie firewallu sa cele caro vytraca. Aky je potom rozdiel medzi (podla mna o dost jednoduchsim) nasadenim transparentneho proxy + konfiguraciou firewallu? Odpada manipulacia s AD a DNS, instalacia kniznic a toolov pre reverse-engineeringom zrekonstruovanych proprietarnych rieseni, zbytocne zatazovanie AD, atd...
Ale staticka IP adresa Vam prece vubec negarantuje, jaky uzivatel se ke stanici prihlasi. A o to nam prave jde. Jinak bychom se touto konfiguraci vubec nezabyvali, jak jste spravne naznacil.
Mám vyzkoušeno, že squid v transparentním režimu odmítá zkousnout řadu ne zcela korektně zformulovaných URL, kežto v klasickém proxy režimu to projde. Tak třeba už jen proto nepoužívám transparetní režim.
Transparentni proxy je samo jeste daleko vetsi zhuverilost ... osobne jsem proti jakymukoli sledovani zamestnancu - pokud nekdo odvadi svoji praci, je mi sumafuk, jestli si 1/2 dne browsa na porno webu ...
Na vyse zminene problemy sem narazil prave pri pokusu o takove sledovani (z rozkazu majitele firmy), ktery to (kvuli tomu svemu webu) nasledne nechal zrusit.
Z technickeho hlediska (usetreni trafficu) nema proxy zadny vyznam(tech par MB co tu usetri ...), osetreni pristupu na web lze resit jinak (napr filtry v antiviraku).
Že by cokoliv z toho zmínného rozbila proxina o sobě nemám zkušenost. Obvkyle se to rozbije až ve chvíli, kdy se začne trvat na ověřování klientů.
Protože kde co umí použít proxinu, dokonce si ju samu nastavit minimálně převzetím ze systému, ale už je to bída, pokud se bude trvat na ověřování klientů něčím jiným, než je metoda basic. Na tom řada věci pohoří. Třeba zmiňované bankovní aplikace v Javě, pokud proxina bude chtít jen NTLM, tak Java to umí, ale dělá ji nekorektně (v rozporu se specifikací Microsoftu). Ale třeba s Microsoftím proxy serverem to funguje OK, prootže tu specifikaci MS sám také nedodržuje, kdežto squid na ni trval a pak NTLM v Javě selhalo. Naštěstí v řadě Squid 3 už vyměkli a dělají to stejně nekošer a funguje to. A podobných případů je řada.
Pak to řeším tak, že ACL pravidla povolují určité stránky bez autorizace a zbytek vše jde přes proxinu s ověřením klienta (není povolena vyjímka přímého spojení mimoi proxinu).
pokud jsme lopaty a neumime to resit... ne ted vazne, si udelas bud ve squidu nebo ve squidguardu (na nejake nasobne filtrovani pristupu i pres mouchy vcelku ok) tridy toho kam kdo muze vcetne vyjimek a pokud je to neco jo spesl, tak to muzes mit v predrazenem whitelistu a pohoda... ve firme jsem delal pred pul rokem to same co autor pise v clanku vcetne reportingu/statistik per login, produktivita prace se asi nezvedla, ale tim ze si nikdo nic nestahne a omezilo se porno v praci, tak neni problem s malwarem na windows stanicich...
jen je samozrejme blbost tu statistiku pouzivat proti lidem samotnym, kvuli tomu sem to nedelal... nevim jak autor, ale rozhodne u me statistika je spis o prehledu deni na siti (co se stahuje, co je potreba za porno stranky zakazat ve squidguardu, zda se nekdo neovereny nepokousel pristoupit do internetu, atd.)
