VPN klient - zablokovanie traficu

[Roman Priesol]

Jestli jsem to dobře pochopil, tak ti jde o to prosadit to proti „vůli“ toho počítače. Pak je odpověď samozřejmě ne, nejde to (a ani z principu jít nemůže). Nastavení jako "push redirect-gateway" si klient samozřejmě může overridnout.

Zavisi akeho mas klienta. V praci pouzivame Network Connect od Juniperu a ten kontroluje smerovaciu tabulku. Ak ju zmenis, tak zhodi spojenie. Teda...za beznych okolnosti Samozrejme, ze je mozne spravit par zmien hex editorom a "route monitor alarm" je minulostou

[Reklama]

[ET]

* cisco vpn klient na tuxe ma i patch, kdy volbu "redirect gw" poslanou ze server ignoruje, shrew (klientska vpn, ktera umi i cisco) by mela mit checkbox na ignorovani "redirect gw" by-default

[Cek]

* cisco vpn klient na tuxe ma i patch, kdy volbu "redirect gw" poslanou ze server ignoruje, shrew (klientska vpn, ktera umi i cisco) by mela mit checkbox na ignorovani "redirect gw" by-default

To jako oficialni patch, který to dela, nebo někdo dobastlil? Protože jestli tohle udelalo Cisco oficialne, hodne u me kleslo.

[Jenda]

Protože jestli tohle udelalo Cisco oficialne, hodne u me kleslo.

Jako že u tebe klesl výrobce, který neimplementuje nesmyslnou DRM feature?

[ET]

ten patch je treb tady: http://projects.tuxx-home.at/ciscovpn/patches/override-local-lan-access.diff (dost urcite neoficialni, ale nejak extra jsem to nezkoumal), ja to sem dal spis jen tak pro pobaveni, kdyz uz padl ten juniper/kerio

a nedelej si iluze, ze "velky vyrobce" neco znamena  - moje zkusenost je, ze cim vetsi, tim horsi (i kdyz Cisco krabicky patri k tomu lepsimu [HW], co jsem zatim videl)

[Reklama]

[Jenda]

Nebo mu pomocí LD_PRELOAD odchytnu funkce, kterými zjišťuje stav routovací tabulky. Nebo nahardcoduju do kernelu, ať procesu s PID X vrací nesmysly. Nebo ho pustím ve virtuálu (což se u backdoornutých blobů hodí stejně - když to povinně poslouchá ze serveru redirect_gateway, tak kdo ví, jestli to neposlouchá ze serveru třeba i libovolné shellové příkazy) a routing přes něj si nastavím úplně jak budu chtít. Nebo reverznu protokol a napíšu si alternativního klienta, který mě bude poslouchat.

No a teď když vidím že to Cisco distribuují normálně jako zdroják, tak tam už je to úplně triviální.

[M.]

Tazatel řeší přístup z Windows klienta. Že si to na linuxu přiohnu jak chci, pokud jsem root, tak je jasné.
Tazatel neuváděl, zda ot chce jako opatření proti tomu, kdy uživatle bude chtít sám aktivně vynášet data (tak je vynese vždy nějak) nebo proti nějakému automatickému nástroji v notebooku, jednajícímu bez vědomí uživatele notebooku.
Pochopil jsme to tak, že hlavně řeší, že když notebook je VPNkou připojen do firmy, aby nešel zároveň notebook ovládat odjinud pomocí VNC/RDP a podobných, tam politika vše do VPN by mu pomohla.
Ale pokud bude mít ten lokální uživatel lokálního admina, tak to ojebe snadno (a pokud nebude, tak to je o něco víc práce). Takže to bude vždy i na kladném přístupu toho uživatele.

[Jenda]

Tazatel řeší přístup z Windows klienta. Že si to na linuxu přiohnu jak chci, pokud jsem root, tak je jasné.

Windows nerozumím, ale čekal bych, že tam budou existovat ekvivalenty postupů, které jsem uvedl.

Tazatel neuváděl, zda ot chce jako opatření proti tomu, kdy uživatle bude chtít sám aktivně vynášet data (tak je vynese vždy nějak) nebo proti nějakému automatickému nástroji v notebooku, jednajícímu bez vědomí uživatele notebooku.

V #8 uvedl, že stojí proti "externímu ITčkáři". Ten bude mít nejspíš znalosti na realizaci uvedeného.

Pochopil jsme to tak, že hlavně řeší, že když notebook je VPNkou připojen do firmy, aby nešel zároveň notebook ovládat odjinud pomocí VNC/RDP a podobných, tam politika vše do VPN by mu pomohla.

Nehledě na to, že tento způsob „ochrany“ je kravina i kdyby fungoval, protože si to může stáhnout lokálně a nahrát potom.

[Radek]

Ahoj,

Obecne si myslim ze to resit nejakym jednoduchym scriptem nejde. Sam pracuji v prostredi kde se klade velky duraz aby nemohla nejaka data uniknout a zatim jako nejlepsi reseni nam vyslo nemit vzdaleny pristup. Nicmene pokud bych to asi takto :

Specialni NTB pro uzivatele ktery ma secure boot(ano to na co vsichni nadavaji) a dale pouziva TPM(pro ulozeni klice) a sifrovani hdd. V tom ntb ma uzivatel jen pravo usera, nemuze nic menit, nastavovat, instalovat novej SW, extrahovat klice pro VPN, ....

Citrix - V jedne praci jsme takto meli reseny pristup do firmy. Nahodil se nejaky client z ktereho neslo delat screenshot a ani ho neslo ovladat pres TV, RDP, ... Jine moznosti me nenapadaji. Jakmile nemas kontrolu nad cizim PC tak to jinak neudelas.

Radek

[Medo]

Ahoj.
Principialne nevynesie utocnik nic.
Vytoci sa vpnka, a dalej je pouzite rdp. Ale tw na pozadi je neziaduci. Aj len sledovanie prace usera mu pri trpezlivosti ukaze nieco, co vidiet nemal.
Ci je externista "dobry" uvidime :-)

[Jenda]

Ale tw na pozadi je neziaduci. Aj len sledovanie prace usera mu pri trpezlivosti ukaze nieco, co vidiet nemal.

Aha, takže stačí občas udělat screenshot.

[Trident]

A nestaci ti graficky/command line terminalovy pristup na misto vpn? Tim se daji pohlidat komplet akce na vzdalenych systemech
Podle toho co jsi napsal tan ten korporatni vztah na IT a bezpecnostni urovni resis nevhodnym nastrojem.

Pokud chces opravdu funkcni omezeni tak existuje. Pouzivaji ho vojaci/vnitro/nato/bankovni sektor/prumysl. Po provereni si te pozvou a mezi chlapama s kulomety na jejich pocitaci pod jejich dozorem, na jejich hw delas akce. Ty akce jsou samozrejme jeste logovany a kazdou musis zduvodnit.
Pripadne nemas pristup vubec nikam a resis vsechno pres x prostredniku maily - tzn. lidske gatewaye kdy jednoducha vec na 10 minut se muze na schvalovacim kolecku protahnout na 1 mesic.

Nejdriv si udelejte poradek v externi komunikaci ve firme a pak to res technicky.Jinak navrhuji polovojensky pristup kdyz uz si neverite.

[Medo]

Uz som sa rozhodol, nazeniem im traffic do VPN gatewaye, a  tam osefujem co nechcem, aj vzhladom na kapacitu linku (TW, YT, ....)
Zvysok nech si tam chodi ... (http/s, pop3, ...)
Komu to bude vadit, nech si makne s pracou, a odpoji sa, po povodnom kanali sa to zase rozbehne ... :-)))
Nemusia trcat na RDP serveri 8h, robit sa ze robia, a nic z toho ...