Názory k článku Apache Guacamole: gateway pro vzdálený desktop (RDP a VNC)
-
Díky.
Guacamole máme za reverzní proxy, tam se dá třeba nahodit nějaké GeoIP omezení. V další fázi Tomcat loguje úspěšná i neúspěšná přihlášení z dané IP adresy (funguje normálně X-Forwarded-For) a je tedy možné danou IP adresu zlikvidovat skrze Fail2ban.
Otázkou zůstává, jak se bránit proti 0-day zranitelnostem, to asi musí řešit chytřejší lidi než jsem já. -
Diky za clanek. Uz nejakou dobu se taky chystam Guacamole nasadit.
Mam par otazek:
1) Kdyz je nutne kompilovat proxy, proc to cele nespustit v Dockeru? Ja to zkousel a jelo to. Ma kompilace nejake vyhody?
Pouzival jsem tento docker-compose, z 99% jsem se nekde inspiroval, me upravy jsou minimalni https://gist.github.com/tuxmartin/55c27c57bd5d533f66254d350761b516 (zdroj se mi uz nedari najit).2) Je mozne nejak nastavit potvrzeni pred pripojenim?
Priklad: potrebuju pridat dost uzivatelskych poctiacu, kterym delam vzdalenou spravu. Rad bych se vyhnul tomu, ze kdyz omylem mysi kliknu na jiny pc, okamzite se k uzivateli pripojim. To neni zadouci a je to neslusne. Proto by se mi libilo, aby nejdriv vyskocilo okno s hlaskou neco jako "Opravdu se chcete pripojit? Ano/Ne".3) Resil jste nejak moznost pripojeni usb flash disku, lokalnich disku a tiskaren do RDP? Jde to vubec? Po pripojeni vidim ve win10 neco jako "guacamole printer". Ale na pc mam pritom vice tiskaren.
4) U nekterych Windows pocitacu pouzivam Wake on Lan, kde se nejdriv pres Winbox, pripadne SSH prihlasim do mikrotiku a poslu WoL paket. Jde tohle nejak vyresit v guacamole?
Diky!
-
Zdravím
1) Je to asi otázka vkusu. Mnoho let používám LXC, takže košile je pro mě bližší než kabát.
2) Guacamole umí filtrovat, čili nemusím procházet tím košatým stromem. Také je možní jít přímo na URI daného spojení. Teď jsem se koukal na connection properties a na první dobrou tam nevidím nic jako "potvrzení připojení".
3) Device redirection tam je, ale nějak extra jsem to neřešil, pro můj use-case je to spíše nežádoucí.
4) Na WoL už je pull request, v dohledné budoucnosti má být :-). -
Dovolím si přeci jen nesouhlasit s tím, že tohle řešení je lepší než NAT s port-fwd. Ačkoli je to řešení vyzkoušené, velmi funkční a také příjemné na obsluhu, vidím v něm potenciální díru. Zkrátka nemusí tam být, ale je tam. Další článek v řeťezu, který lze napadnout.
I když fail2ban a geo-omezení mohou pomoci, zdaleka to dnes nestačí. Už skoro měsíc čelím v jedné firmě, o kterou se starám útoku, který je totální vějíř. Jde ze všech zemí a zablokováno mám v současnosti okolo 25.000 ip adres a útok jede dál. Napadených počítačů jsou miliony a ty slouží jako kulomet útoků. Proti tomu je fail2ban i geo-limitace zcela bezmocná.
takže, chápu autora, ale nikdy bych to nenasadil....
-
Karel Hudaň (neregistrovaný)
A co nějakou obezličku typu "Port knocking" z jiné webové aplikace?
Ještě rozvažuji, že bych někdy někde vyzkoušel nutnost mít v prohlížeči ten správný certifikát, jinak člověka webový server ani nepřipojí. Tak to třeba řeší polská ING.
Ale popravdě mi zatím vždy přišlo jednodušší zprovoznit VPNku :) -
Tak, VPN je samozřejmě preferované řešení a pokud má někdo pracovní notebook a zároveň počítač v kanceláři, tak ji nasazujeme. Obecně nám ale přišlo jako menší riziko zprovoznit tohle, než dávat lidem VPN do jejich domácích strojů, nad kterými máme nulovou kontrolu. Certifikát je perfektní idea a jsem hodně nalomen k její implementaci.
-
VPN není dobrá volba, pokud potřebujete dostat RDP až na stanice.
V tu chvíli musíte mít statické IP adresy (čtyřikrát fuj pro IPv4, šestkrát fuj pro IPv6).
Na úrovni L3 firewallu nemáte informaci ani o uživateli VPN - takže se musíte zase spoléhat na statickou IP adresu, ani jistotu, že na cílové adrese je skutečně zamýšlené PC. Stačí malá chyba v konfiguraci firewallu nebo přiřazení uživatele VPN a stanice na pevnou adresu a máte díru jak vrata. Navíc jak za krále Klacka budete vést excel s IP adresami. Na IPv6 se už zblázníte, nastavit statické přiřazení.Pokud VPN, tak do DMZ a v DMZ použít proxování (např. remote desktop gateway). VPN může být zlepšení bezpečnosti, nikoliv náhrada.
-
Je to náchylné na chyby.
Nedá se to kontrolovat a ovládat centrálně.
Jakoukoliv změnu musíte provádět oběhnutím a přenastavením zařízení.
Obvykle nemáte dynamický zápis do DNS.U serverů lze využívat statické IP adresy, ale serverů je řádově méně, než stanic. Tam se IP adresa nastavuje staticky kvůli bezpečnosti.
U stanic statické adresy nepřinášejí žádnou výhodu. Obvykle statické adresy volí admini, kteří je "potřebují" kvůli bezpečnosti (L3 firewall nenastavíte aby chránil dynamickou adresu), nebo kvůli NATU. Obě myšlenky jsou v případě stanic a někdy i serverů z hlediska bezpečnosti překonané. L3 firewall dobře nastavit znamená prakticky neustále vylepšovat pravidla (kdo na to má čas?) a NAT na stanici je z gruntu špatná myšlenka. Proto se spíš používají protokolové proxy, na kterých lze vyhodnocovat daleko víc kritérií, než jen L3 hlavičky.
Mít statické IP adresy, NAT, VPN - to byla mantra devadesátých let a milenia. Dnes jsme už někde jinde.
-
Jasně, chápu vaši volbu a vysvětlení. To tedy potřebuje upřesnit. Váš popis perfektně funguje v případě velké firmy, kde máte stovky stanic v několika openspacech. Není to tak u menších firem a různých "nestandardních případů".
Vemte si, že se starám o firmu, která má 19 kanceláří v několika místech staré zástavby 19 počítačů. Obskurita - řeknete. Ale já se starám o 3 takové obskurity, každá jinak obskurní. Podle IP sleduji, které stanice běží, případně které jsou nedostupné a v případně výpadku vím v jakém místě šílené infrastruktury je porucha. No a pokud potřebuju něco přenastavit, nemusím nic obíhat, jen se vzdáleně přihlásím a přenastavím nadálku. (hlásím se servisním účtem, nikomu nelezu do jeho heslel apod).
Takže spíše bych řekl, že je to trochu případ od případu, nemyslíte? :-) -
Podle IP sleduji, které stanice běží, případně které jsou nedostupné a v případně výpadku vím v jakém místě šílené infrastruktury je porucha. No a pokud potřebuju něco přenastavit, nemusím nic obíhat, jen se vzdáleně přihlásím a přenastavím nadálku. (hlásím se servisním účtem, nikomu nelezu do jeho heslel apod).
Takže spíše bych řekl, že je to trochu případ od případu, nemyslíte? :-)Určitě je to situace od situace. Bohužel na takovou popsanou situaci se nabalují právě ta další hloupá řešení. Např. nemít gateway pro vzdálenou plochu a řešit přístupy přes VPN a RDP. Ono pak už jedno blbé řešení nabaluje druhé, třetí, čtvrté .- a už z toho není cesta ven. Když to chcete změnit k nějakému normálu, tak zjistíte, že by to stálo neskutečně moc peněz (a pak už vymyslíte spoustu argumentů, proč je lepší nic neměnit).
Můj názor na to je, že "obskurní" situace se mají předně řešit. Když už musím mít ve staré zástavbě spoustu switchů, tak tam dám třeba Cisco Catalysty a nastavím si AAA + monitoring. O síťovém problému vím hned, aniž bych to musel suplovat "pingáním" statických IP adres stanic. Chci vědět jestli stanice běží? Podívám se, jestli je port na switchi UP, kdy natáhl poslední lease z DHCP apod. Na dálku se na stanice přihlásím stejně tak, ať mám statické nebo dynamické IP adresy. Stačí k tomu nastavit i registraci do DNS. Myslím, že je daleko lepší šetřit čas zkušeného ajťáka na to, aby něco opravdu tvořil, než ho profesně zabít na obskuritách.
Argumenty, co jste mi popsal, jsem samozřejmě v praxi taky potkal. Své kolegy se mi nakonec vždy podařilo přesvědčit o tom, že to jde dělat lépe a otevřít si tím možnosti pro nasazování i novějších technologií.
PS: když už mít na pevno přiřazenou IP adresu, tak aspoň přes rezervaci v DHCP. I to dokáže dost pomoct, když potřebujete síť přenastavit.
25. 3. 2020, 23:55 editováno autorem komentáře
-
Nu, u velkého korporátu bych už spíše čekal, že normální lidi nemají důvod lézt na svůj fyzický desktop, ale polezou na nějaký virtuální. Stejně tak i když sedí v kanclu, tak stjeně jeho lokální PC slouží často jen jako temrinál pro pouštění remota app/desktopu. Takže přístup z venku míří stejně na ten virtuál. Na desktop leze leda tak admin nějakým vhodným nástrojem pro administraci/asistenci.
U malých chápu, že toto řešení připadá těžko v úvahu, když je toho mnoho rozházeno po lokálních stolních PC.
To Win infrastruktura neumí dělat rozumně řízení statických IP adres tak, aby se admin z toho nezbláznil? Mám DB přípustných PC, jejich MAC pro lan, wifi, ID LTE4 karty, k tomu přidělen suffix IP a IPv6 adresy (jejich lokální LAN část) a z toho se automaticky berou podklady pro všechny DHCP/DHCPv6 sítě po celé republice i na mobilní připojení (čili LAN část IP/IPv6 je pořád stejná ať je kde je, mění se prefix sítě dle aktuální polohy ve firmě), samozřejmě napojeno na DNS, ať se aktualizuje záznam. Stjeně tak se dle toho beoru data pro 802.1x, počítač se ověří svým certifikátem/členstvím v doméně, dle toho plyne ne/puštění do LAN, namapování na příslušnou VLAN, dle tooh dostane i IP/IPv6 od DHCP, nahodí se i MAC/IP/IPv6 svázání kontroly a další podobné vylomeniny.
Celkem potkávám podobné řešení i ve velkých firmách. Vidám, že počátač i servery mají stjené IP přes 20 let, přestože se vlastní HW už X-krát změnil a třeba i přestěhoval o pár set km jinam (velká firma=má problém se svoji vnitřní infrstrukturou vejít do segmentu 10.0.0.0/8). :-) -
-
VPN je bezva (na WinOnly SSTP asi nejjednodušší). Ale:
- VPN do DMZ, kde je jen Terminal server … nicméně, pokud útočník pronikne vinou nekvalitního hesla uživatele na terminál, stejně má k dispozici většinu sítě.
- VPN do sítě: dtto, připojený PC/NTB je riziko pro LAN a neuhlídáš, zda uživatel nemá jeden PC i s dětmi, kteří hrajou hry a bezpečnost/antivir neřeší.
- řešením není ani dvoufaktorová autentizace … viz bod 2.Nezbývá, než pravidelně zálohovat, projít LAN, zda tam není slabé místo pro průnik s vysokým oprávněním (typicky SMB1 nebo SMB2/3 Public bez hesla), sledovat LAN 24/365 a pokud by došlo k instalacei Emotetu, ihned odpojit všechny uživatele a hledat, odkud to přišlo … útočník zanechá stopu na napadeném PC, ze kterého pak vede útok.
A bohužel … pak reinstalace všech serverů, protože nevíš, kde se Emotet skrývá … může být i vzálohách a jen vyčkávat i 14 dnů, než se pustí do práce.
… a hlavně modlit se, aby zrovna u Vás nebyl Emotet nalezen … v podstatě největším rizikem je vždy uživatel a to ten nejslabší (obvykle nějaký lajdák, nebo starší před důchodem, co tomu vůbec nerozumí a bezpečnost je cizí slovo. Seznam je jediné, co zná ...
-
Karel Hudaň (neregistrovaný)
Reinstalace...
Zatím jsem to teda nikdy v nouzi nepotřeboval, ale jelikož všechny servery (primárně Linux, ale sem tam i Windows) jedu v režimu HW -> KVM -> VMs, tak pokud by se něco takového stalo, tak to merge LVM snapshotu jistí.Běžně to používám třeba v rámci instalace nového SW na Windows serverech, abych se mohl vrátit, když to jde šejdrem, a vždy OK. Plus samozřejmě mám zálohy systému i dat, lokálně i vzdáleně. Zálohovaný stroj má právo pouze udělat novou zálohu, staré mazat nemůže.
A co se týká LAN, pohrávám si s myšlenkou, že časem nasadím WireGuard na komunikaci mezi stanicí a servery (+firewall). No uvidíme :).
-
Co čtu zkušenosti lidí na redditu apod, vypadá to funkčně. Vzhledem k tomu, že budu chystat reinstall Windows serverů a domény, přemýšlím, jaké to má reálné benefity či smysl.
RDP dnes řeším na úrovni firewallu na známé veřejné adresy a pro roadwarriory přes VPN. Vše bez RD Gateway, tu jsem zavrhl při prvním testu na Win2K8R2, kde navazovaní bylo nesmírně pomalé.
Potřeboval bych poradit nějaké scénáře, jak by Guacamole mohlo být přínosem, jelikož při existenci VPN a hlavně samotného RDP mi to pořád nedává smysl. Co se týče přístupu - klientů, tak:
- pracovní stanice s Windows mají mstsc
- linux a MacOS mají klienta(y) v repozitářích
- RD server má nativní podporu pro web browser už i bez RD gateway (takže RD HTML5 Client FTW)SSH v browseru bych nechtěl používat, na svém desktopu otevírám terminály přes klávesovou zkratku, na Windows jedu přes linux pod WSL, protože vyklikávat se puttynou mě fakt nebaví.
VNC je taková nouzovka a reálně nikde nepoužívám. Ve světě plném RDP, !M, Moonlight či Chromotingu (jako náhrada TeamVieweru) si na VNC ani nevzpomenu.
26. 3. 2020, 09:29 editováno autorem komentáře
-
Karel Hudaň (neregistrovaný)
Jaké řešení namísto VNC tedy používáte na klasickém PC, aby jste se mohl na dálku připojit a mohl kooperovat s uživatelem při řešení jeho problému?
* RDP - odpojí uživatele
* !M - to jsem nenašel co to je :)
* Moonlight - pochopil jsem, že vyžaduje nVidia grafiku
* Chromoting - primárně dávám všude FF :)
* TeamViewer, AnyDesk, LogMeIn - u těchto a podobných SW mi vadí, že je to široce dostupné přes Internet, takže stačí obejít autentizaci (chyba v SW nebo tak něco) a kdokoliv má plný přístup na PC. No a výrobce SW tam má přístup vždy. -
Uff, patří k otázce od KarelH:
Souhlasím, že pro jedodušší instalace (a citlivé na cenu) vypadá Guacamole OK, pokud stačí jen převzít obrazovku. Zkoušel jsme si to teď a jed eto OK pro běžnou robotu.
K otázce, co jiného zkusit - podívejte se na Nomachine Enterprise. Používáme a řeší hodně z těchto věcí. Pro větší nasazneí má pak centralizovanou proxy, která pak uí dělat dál spojneí na další NoMachine instalace, RDP, VNC, X-Win stroje a agregovat je do jednoho vstupního bodu (NoMachine Enterprise Terminal Server). Pro stroje s Windows (i linux a MacOS) místo VNC na převzetí plochy mají Enterprise Desktop, my používáme pro linuxy spíše NoMachine Workstation (umí vedle převzetí plochyi i virtulní desktopy).
Klienta to má pro kdd co - HTML5 web a nativní klienty pro PC, MAC, Win, Android a něco dalšího. Při nativním klientu jde řešit přenosy souborů, clipboardu, zvukovka, tiskárna, mapovat disky, čipové karty, USB, ... Jde zaintegrovat rozumně s doménou, používéme komplet kerberozivované řešení, někde dvoukator, certifikáty, ...
Jenom to něco stojí, od všeho mají měsíční demo ke stažení s plným provozem.26. 3. 2020, 13:06 editováno autorem komentáře
-
a b (neregistrovaný)
Nevím netuším, co mě napadá web sockety máte povolené https://www.nginx.com/blog/websocket-nginx/ ?
https://mkyong.com/tomcat/how-to-configure-tomcat-to-support-ssl-or-https/
https://medium.com/@mashrur123/a-step-by-step-guide-to-securing-a-tomcat-server-with-letsencrypt-ssl-certificate-65cd26290b70
Na tomcatu to opravdu není problém návodů je spousta, Jetty na tom bude podobně -
Ten cfg ve článku jsem zavrhl testoval jsem to několikrát a pokaždé jsem dospěl k tomu že SSL spojení bylo pomalé. Nehledal jsem pak už důvod a nevím kde byla chyba. Třeba jen mezi klávesnicí a židlí nebo měl problém desítkovej Debian těžko soudit.
Tohle problém vyřešilo. Nikterak výrazní obměna v tom základu není.
cat /etc/nginx/sites-enabled/reverse-proxy
server {
listen 80;
server_name ABCDEFGH;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name ABCDEFGH;
root html;
index index.html index.htm;ssl on;
ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1440m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";access_log /var/log/nginx/guacamole.access.log;
location / {
proxy_pass http://localhost:8080/ABCDEFGH/;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_cookie_path /ABCDEFGH/ /;
}
ČLÁNKY DO MAILU