Vlákno názorů k článku X window a terminálový server na FreeBSD od ddd - Komunikace v XDM sessions neni kryptovana. To...
-
Článek je starý, nové názory již nelze přidávat.
-
ddd (neregistrovaný)Komunikace v XDM sessions neni kryptovana. To se da pouzit v ucebne, nebo v podnikove LAN, kde na bezpecnosti prilis nezalezi. Zajimavejsi by bylo, kdyby se ty X-y napojovaly pres VPN mezi klientem a serverem. Rad bych to zprovoznil na svem Linuxu, ale zatim jsem nenasel cas se tomu venovat.
-
prema (neregistrovaný)jj, ssh -X user@host. -X zapina tunelovani X protokolu na cilovem stroji ti to nastavi promennou DISPLAY takze tam muzes rovnou spoustet X aplikace. Ale aby to fungovalo, tak sshd musi byt zapnutou volbu XForwarding na yes. Problem ale bude s prenosovou rychloti. Na lokalni siti je to ok, ale pres internet? Zalezi na konektivite, ale obecne je to straaasneeee pooommallleee.
-
anonymní"Problem ale bude s prenosovou rychloti. Na lokalni siti je to ok, ale pres internet? Zalezi na konektivite, ale obecne je to straaasneeee pooommallleee."
Jak se to vezme. Dnesni internet je uz relativne rychlej, vetsinou ale z Inetu k userovi (download). Pokud bys tak chtel neco z Internetu spravovat nekomu doma, tak s tim budes mit problemy s rychlosti.
Jedna moznost je nastavit vysokou komprimaci u SSH (-o Compress=yes,CompressLevel=9). Druha moznost je nespoustet ty aplikace primo, ale spustit si na cilovym servery spis VNCserver, pripojit se pres vncviewer a pracovat takhle.
Jednak jde nastavit opet kompresi, take (napr. u tightvnc) jde vybrat urcity druh kodovani (osobne mam dobre zkusenosti s kodovanim tight:)) a tightvncviewer umoznuje taky zadavat kvalitu obrazu (JPG). Takze pokud ti nejde o kvalitu, tak se da nastavit treba "2" - obraz je pak mirne rozmazany a detaily se zaostrujou az pri pouziti, ale jede to i na pomalejsich linkach.
Druha vyhoda je, ze pokud ti spadne spojeni, tak se ti rozdelana prace neztrati padem aplikace, ale bezi v pohode ve vncserveru dal.
Mimochodem, mozna to taky stoji za uvahu, aby se na tenkym klientu nespoustel primo WindowManager, ale vncviewer, ktery se pripoji na server na VNCserver. Uzivatele tak mohou nechat rozdelanou praci, aniz by museli ukoncovat vsechny programy a window manager, a pouze ukonci viewer a jdou. Pokud se nepletu, tak vncserver umi take XDMCP, takze by to taky bylo reseni a mozna by odpadl problem s rychlosti napr. OpenVPN tunelu. -
Marek Chlup (neregistrovaný)Máte s tím nějaké zkušenosti? Jak byste to udělal?
Já to v tuto chvíli řeším tak, že po klasickém přihlášení v textové konzoli se spustí X pak ssh s tunelováním X a pak se nastartuje nějaké desktopové prostředí. Co mi však zde chybí je grafické přihlašování.
Plánuji si více pohrát s:
Xnest :1 -query localhost
či:
gdmXnest -o "-query localhost"
Má s tím někdo zkušenosti?
Taky jsem zatím nedošek k žádnému řešení kolem zvuku (respektive i videa) abych s ním byl spokojen. Pokud někdo u vzdáleného Firefoxe klepne na soubor se zvukem... Zatím se mi prostě nepodařilo najít nějaké transparentní řešení k mé spokojenosti. Máte někdo s něčím dobré zkušenosti? -
anonymníPokud vim, tak XDMCP bezi na UDP, cili na SSH tunnel nebo stunnel zapomenme.
Osobne jsem taky premyslel, jak sifrovat komunikaci mezi bezdiskovou stanici a server nejen na XDMCP, ale take na NFS, a porad mi v hlave lezi myslenka, ze stanice si ze serveru stahne kernel a svuj initrd, ktery je pote nahraje a spusti. V tomhle initrd bude samozrejme startovani nejake VPN (osobne mam rad OpenVPN, ale mam dojem, ze tun umi pouze 10Mbps, coz by mozna mohlo byt poznat pri praci). Pres ten VPN by pak probihala veskera komunikace se serverem. VPN certifikat a klic pro stanici by byl ulozen v tom initrd, klic by byl zasifrovany nejakym udajem unikatnim pro stanici a zjistitelnych pouze lokalne (netusim, co by se dalo pouzit, neco jako ID procesoru, desky nebo tak). Samozrejme by byl zakaz bootovani z cehokoliv jineho, takze pripadny utocnik by nemohl ziskat klic, aby si nahodil vlastni VPNku z vlastniho stroje.
Slo by to takhle? Da se donutit OpenVPN aby pouzival nejaky rychlejsi virtualni interface? Bylo by to dostatecne rychle s OpenVPN nebo by bylo lepsi IPsec (nebo neco jineho)? -
Marek Chlup (neregistrovaný)Mé příklady výše naznačují jak "tunelovat" XDMCP. Zatím jsem si s tím, ale nehrál pořádně.
Viz třeba také zde:
http://www.macosxhints.com/article.php?story=20041117115414383 -
petr_p (neregistrovaný)Nechci vas strasit, ale v principu to je nesmysl, protoze musite prenest klic bezpecnym zpusobem na terminal. Dale musite zabezpecit, ze se k tomu klici nikdo nedostane (napr. nepodvrhne jadro nebo root FS) atd.
Teoreticky vzato neni mozne mit bezstavove terminaly a ocekavat od nichm ze dokazi autentizovat server.
Nejrozumnejsi je do terminalu zapsat jadro a klic treba na disk, z toho nabootovat, vypnout disk a bezpenost resit IPsecem. Pokud byste chtel i aktualni jadro, je mozne jej poustet pres kexec.
Technicky ciste reseni by bylo rozsirit PXE interpret v sitove karte o overovani digitalne podepsanych PXE zavadecu (syslinux) a jader. Jadro by si pak ze sitovky nacetlo klic a pouzilo jej na IPsec. -
anonymní"Nechci vas strasit, ale v principu to je nesmysl, protoze musite prenest klic bezpecnym zpusobem na terminal. Dale musite zabezpecit, ze se k tomu klici nikdo nedostane (napr. nepodvrhne jadro nebo root FS) atd."
Ted mi nejak nedochazi, jak to myslis.
ad prenos klice nesifrovanym kanalem) nejsem zase tak velkej prebornik na bezpecnost a sifrovani, takze nevim, jestli je hodne velkej problem, kdyz poslu klic zasifrovanej dostatecne silnym heslem pres nechranenej kanal. Mozna posilat klic od el.bankovnictvi zasifrovany slabym heslem (rozumnej 5-7 pismen a-z, max. jedno velky) emailem je asi dost velke riziko, ale poslat klic zasifrovany dostatecne dlouhym heslem (coz muzou byt kombinovane najeke ID dilu pocitace) pres lokalni LAN, navic klic ktery ma slouzit pouze k pripojeni pro lokalni VPN, to snad nebude tak velke riziko, ne? Prakticky je jedno, jestli se klic prenasi nesifrovanym kanalem, protoze ve realu bude initrd ulozene na tftp, takze by zrejme utocnik mohl mit moznost si ho stahnout sam.
ad ze se k tomu klici nikdo nedostane) teoreticky pokud na tom stroji nedokaze spustit jiny system (to je asi myslene tim "nepodvrhne jadro nebo root FS") tak by nemel mit pristup k tomu klici, navic i kdyby, tak by klic mel byt pouze v sifrovane podobe.
Jedina hrozba, kterou bych ja videl by byla v pripade, ze by utocnik mohl do site zapojit vlastni stroj s DHCP serverem. -
petr_p (neregistrovaný)Lze podvrhnout DHCP odpovedi, TFTP je taky jen nad UDP, unest linkovou adresu, zmenit smerovaci tabulky, lze odposlouhavat, cokoliv.
Pokud tyto problemy mate vyresene, pak asi utocnik nema pristup k siti a tudiz nepotrebujete jine zabezpeceni.
Jednoduse receno klic, kterym chcete zabezpecit spojeni mezi terminalem a serverem musi znat jen tito dva. Pokud tento klic zasilate terminalu takovym zpusobem, ze nelze zjistit, ze klic ziskal i utocnik, neni mozne komunikaci mezi serverem a terminalem zabezpecit. -
anonymníNo, me osobne trapila hlavne myslenka, ze v pripade nasdileni systemu pres NFS muze kdokoliv nabootovat treba z LiveCD a jako root pak udelat na tohle NFS bordel. Samozrejme, ze jde hackovat hodne do hloubky, ale me spis slo o zabezpeceni NFS stromu proti tento uplne jednoduche metode.
jelikoz se tady bavime spise u uzivatelske siti nez o siti v bance, kterou protekaji skutecne citliva data, mohlo by tohle resit. Predpokladem bude:
- na siti je muj DHCP server
- zadny cizi (neprovereny, neduveryhodny) pocitac se do teto casti site nepripoji
- stanice nepujde nabootovat z jineho media -
ZiGi (neregistrovaný)riesenim je kryptovana komunikacia podporovana v NFS - treba pouzit RPCSEC_GSS
implementacia NFSv4 do linuxu prinasa zvysenie bezpecnosti aj pre NFSv2 a v3. podmienkou je pouzit novy kernel a samozrejme kerberos alebo podobna autentifikacia :-)
http://www.citi.umich.edu/projects/nfsv4/
www.nfsv4.org
alebo sa na NFS vykaslat a pouzit OpenAFS
samozrejme to neriesi problem tenkych bezdiskovych klientov, a aj hrubi klienti musia byt zabezpeceni proti bootu z CD/USB .... -
ppp (neregistrovaný)Obavam se, ze resite problem, ktery je vic teoreticky nez prakticky. Vetsine podniku v soucasne dobe staci, pokud po jejich siti nebehaji plain hesla (samozrejme je spousta vyjimek). Pripojeni vlastniho DHCP, ... serveru je velmi zavazne poruseni pracovni kazne a to si hned tak nekdo netroufne. Ale ethernetova karta "omylem" prepnuta do promiskuitniho modu, ... se objevit muze. (Kdyby se za to vyhazovalo, tak uz jsem davno na ulici, protoze to pouzivam pro diagnostiku sitovych problemu.)
-
ppp (neregistrovaný)Komercni tenci klienti obvykle maji podporu VPN zabudovanou. Napr. Igel (http://www.igel.com/igel_rubrik/powerslave,id,52,nodeid,52,p,0,_language,en.html) ma podporu pro Cisco VPN a microsofti PPTP. Proto se mi zda vyhodnejsi zprovoznit na serveru podporu VPN nez bastlit workaround pres SSH tunel.
Koncepcne to neni problem, akorat se clovek musi prokousat velkym mnozstvim spatne dokumentovanych parametru. Jak se tu uz psalo minule: v naproste vetsine je to navrzeno pro praci v sitich s MS-Windows.
Mimochodem: dalsi duvod pro VPN je ten, ze pak muzete mit kryptovane i NFS spojeni mezi klientem a serverem.
