Vlákno názorů k článku Nextcloud: když chcete vlastní cloud pod kontrolou od Bez Podezdívky - O Nextcloudu jsem už víckrát slyšel celkem pozitivní...

O Nextcloudu jsem už víckrát slyšel celkem pozitivní ohlasy a chystám se ho taky nasadit na "takové to domácí sdílení". Co mi ale není úplně jasné, je jak je na tom s bezpečností.

Možná mám zbytečné obavy, ale nejradši bych to zpřístupnil jen přes VPN, abych snížil riziko, že se někdo neoprávněný dostane k mým datům. Má to ale nevýhodu, že pak bych Nextcloud nemohl použít ke sdílení dat nikomu mimo VPN. To by se dalo asi řešit druhou instancí, ale tím se to stává trochu neohrabané.

Řešili jste někdo podobné myšlenkové pochody (a došli k nějakému závěru)? :).

Bezpečnost konečného řešení není jen o Nextcloudu, ale o nastavení celého serveru. Myslím si, že Nextcloud je na tom s bezpečností dobře. Hodně ho používají vládní organizace, má různé certifikace, podporuje nejrůznější dvoufaktorové autentizace apod. Pokud máte vše správně nastavené a aktualizované, nemyslím si, že byste podstupoval nějaké zvýšené bezpečnostní riziko.
Nextcloud s tím správným nastavením dost pomáhá díky bohaté dokumentaci, kde jsou nejrůznější tipy na security hardening. Mají i službu, v které si svoji instanci můžete "oskenovat", jak se z pohledu bezpečnosti jeví z venku.
Schovávat to za VPN by bylo opravdu hodně krkolomné.

Ja nextcloud pouzivam na "takove to domaci sdileni" pouzivam uz nekolik let, a nenarazil jsem na problem. Pravda, audit kodu jsem nedelal :-) Bezpecnost jsem resil standardnim zabezpecenim VPS a nasazenim HTTPS.

Za zminku stoji, ze maji implementovane sifrovani dat, maji jak sifrovani na serveru, tak end-to-end.

To je z hlediska bezpečnosti asi ideální. Druhý server někde bokem se mi ale úplně řešit nechce, takže jsme spíš uvažoval jít cestou dvou instancí na jednom fyzickém serveru. První z nich dostupná jen přes VPN, s přístupem k citlivým datům a druhá "veřejná", uzavřená ve VM co nejvíc ořezané co se týká přístupu ke zbytku systému. Ostatně takovou VM tam stejně plánuju už jen kvůli webserveru, pro jistotu :).

Měl jsem to (testovací, malé řešení) nastavené jako dvě nezávislé instance, na různém HW (PC + Raspberry Pi), na routeru nastavenou veřejnou IP a jeden port pro VPN (a následně na interní), druhý přesměrovaný na externí.

za mě je doporučení to prostě nevystavovat ven bez další vrstvy, která se bude starat o sanitizaci provozu. CVE přestali používat a místo toho mají mají svůj register, mělo by to být místo, který denně kontroluješ https://nextcloud.com/security/advisories/, problémy se objevují skoro každý měsíc.

Zdrojový kód je ale občas dost šílený, nepřehledný, proměnné jsou nekonzistentě pojmenované, žijou v představě, že nejlepší kód je takový, který se sami implementují. Třeba taková perlička je escapování hodnot do databáze přes addcslashes (ve funkci escapeLikePara­meter), výsledek pak většinou používají přes prepared stmt, ale jen většinou, jsou tam situace, kdy to nacpou přímo do sql a na problém je zaděláno.

Stávají se obětí své popularity, kód by potřeboval výraznější koncepční refaktorování, aby nebyl takový prostor k chybám, teď vše řeší záplatami, záplatami a záplatami. Tým není velký a nestačí odbavovat issues (skoro 3k issues otevřených na githubu).

Když už jsem si dal práci a nějaký bezpečnostní problém jim nahlásil, zůstal měsíce netkutý.

Doteď tam mají otevřené věci jako admin heslo v logu (https://github.com/nextcloud/server/issues/13630), u sftp mají vypnutý host verification (https://github.com/nextcloud/server/issues/14108), nebezpečné používání imagick pro uživatelský vstup se řeší dva roky (https://github.com/nextcloud/server/issues/13099), nebo naprostá anarchie v požávání CSP a frame origin (https://github.com/nextcloud/server/issues/13042).

Projekt, který konzumuje uživatelský vstup, který poskytuje výstup dalším uživatelům by měl trochu více myslet na bezpečnost. Nasadit ho v tomhle stavu veřejně je za mě velké riziko, provozovat ho za vpn je sice lepší, ale tak pro domácí účely, do firmech bych se to neodvážil.

Dá se skutečně díky těmto chybám, něco zneužít, nebo jde jen o ty typy chyb, kde musí být splněno dalších 5 podmínek, aby byl vůbec nějaký útok úspěšný?

Já spíš všude čtu, že NC prošel dostatkem bezpečnostních auditů, vidím že mají bounty program, vidím, že je NC celkem dost používaný v mnoha firmách(ano, veřejné instance)

No a pak tu čtu, něco jako:
"Nasadit ho v tomhle stavu veřejně je za mě velké riziko"...

Rád bych věděl jaké...
Protože dle Vašeho měřítka, může být riziko i obyčejný Wordpress, či Joomla... :-)

Ono vcelku nejvíc záleží na tom, kdo tu instanci spravuje a kdo jí používá.. Pokud správce povolí END-TO-END šifrování, klient si to aktivuje...
Tak mu je nějakej únik dat z NC, tak nějak fuk, když NC drží jen zašifrovaná data.

argumentace, tak mi ukažte jak ten systém napadnete, když tvrdíte, že je nebezpečný, je hodně špatná. Útočník má zpravidla mnohem více znalostí, času a nástrojů než já, ať už to dělá hromadně nebo cíleně.

Argumentace, že to někdo používá, tak to musí být nebezpečné je také falešná, firmy a lidé používají kdejaké voloviny. Je moje práce pak jim ty voloviny rozmlouvat nebo na ně upozorňovat.

Stačí se podívat na jejich bounty program, jaké chyby a jak závažné opravují. Všechny issues, které jsem tady zmínil považuji za hodně nebezpečné. Třeba ten zmíněný imagick umožňuje věci jako https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html jen tím, že tam necháš takový soubor nahrát, ten je potřeba zajistit, aby se ten soubor tam dostal. Heslo v logu souboru je také velké riziko, zrovna log soubory rádi někde unikají, nejsou tak chráněné a má na ně přístup spousta lidí.

Ale já vůbec neargumentuji, ať něco někde napadnete, jen říkám, že i přes tyto chyby, se dá v určitých případech a určitém nastavení, Nextcloudu věřit..

No, náhodný útočník tuto chybu, jednoduše nezneužije, protože útočník má přístup jen k login obrazovce, ze které PDFko nenahraje...

Děkuju za obsáhlé příspěvky týkající se mých otázek (díky i všem ostatním, samozřejmě). Tím pádem to vidím tak, že pokud se opravdu pro nasazení NC rozhodnu, schovám ho za VPN a pokud bych snad měl potřebu sdílet něco i mimo vybranou skupinu uživatelů, nahodím druhou oddělenou a ořezanou instanci.

A nebo si vystačím s něčím úplně jednoduchým, jako třeba se skriptem pro nahrání a zpřístupnění souboru, který budu chtít s někým "externím" sdílet, čistě přes webserver pod náhodně vygenerovaným názvem/URL + mazání takto zpřístupněných souborů cronem po určité době. Když nad tím přemýšlím, asi by to mohlo naprosto bohatě stačit.

Jak by mohla přibližně vypadat ta nadřazená vrstva pro sanitizaci provozu? Nedovedu si to představit.

mam v To-do toto riesit.
Zatial mi napadlo riesenie s 2 instanciami - 1 (primarnu) za VPN a 2., cisto na zdielanie, otrcenu do internetu.
Tieto instancie by som skusil spojit do Federacie (cez federation addon) a kedykolvek by som chcel nieco zdielat, zazdielal by som to sekundarnej instancii. Samozrejme by to na 2. instancii vyzadovalo bud druhy krok, kde to uz konecne zazdielam do internetu (na primare musi byt asi povoleny resharing) alebo mat prednastaveny nejaky flow, ktory automaticky novo spristupnene subory automaticky sharuje do netu a nejakym sposobom postne comment s URL primarnemu uctu (mozno aj pomocou push notifikacie) - je to kostrbate? Definitivne.

druha moznost by mohla byt - obmedzenie prihlasenia iba clientom z LAN:
https://apps.nextcloud.com/apps/limit_login_to_ip
teoreticky by tym stale mohol byt funkcny public sharing.
Pripadne sa to mozno da vyladit v nastaveni httpd.

Dalsia, mnou neprebadana oblast by bola pouzivat 1 instanciu za reverznou proxy (u mna Traefik) a pri shareovani dynamicky pridat (Host rule) route na konkretnu url.

18. 3. 2021, 12:33 editováno autorem komentáře

Já to mám nastavené už historicky "skrz VPN" - tedy nejdřív se připojím "domů" a když je to dostupné, koná to svou práci.
To sdílení "něco ven" jsem měl jen chvíli (nebylo to potřeba, jen jsem zkoušel) udělané, jak píšete: druhá (externí) instance a synchronizovat to, co se má. Zas tak neohrabané to nebylo, jen pravidelný rsync mezi servery a, samozřejmě, správa "externích" uživatelů oddělená od "interních".

Pokud to chcete pro sebe, je to použitelné. Ale pro sdílení s někým dalším těžko. Implementace přihlášení certifikátem je v prohlížečích dost nemožná. Neumí rozumně informovat o chybách (i když TLS záměrně poskytuje minimum informací, dá se zobrazit něco jiného než prázdná stránka). Ve Firefoxu bylo nutné při výběru certifikátu vždy klikat na detail, protože informace zobrazené v seznamu byly nepoužitelné pro zjištění, o jaký certifikát se jedná. Chrome mělo (a nejspíš ještě má) chybu, kdy při použití TLS 1.3 velmi agresivně vyměňuje šifrovací klíče, ale často k tomu potřebuje až uživatelův privátní klíč – takže pokud má uživatel privátní klíč chráněný PINem, musí ho zadávat třeba každých 5 minut.

Tenhle přístup by mimo jiné neřešil třeba případ, kdy chci jen někomu bez normálního přístupu do NC nahrát a nasdílet nějaký soubor a poslat mu odkaz na stažení.

Pokud máte na mysli klientský certifikát v prohlížeči, tak to se nechá nastavit na HTTP serveru, ale v prohlížeči je to implementované "jak kde" a někdy je s tím víc starostí, než užitku. Na nějaké profesionální řešení bych to nedoporučoval, na drobné sdílení je to zas docela zbytečně složité.
Ale mám (na OC) odzkoušený "jednosměrný" HTTPS přístup (opět jen na straně serveru)" a to je docela použitelné řešení, pokud nepotřebujete šifrovat upload. (Já to nepotřebuji, protože to používám jen ve vnitřní síti a případně po VPN, která je šifrovaná - a té docela věřím.) Synchronisační klient to umí, zvládne to i CalDAV/CardDAV tool v mobilu nebo v Thunderbirdu...

Co myslíte tím „jednosměrný HTTPS přístup“? Pokud tím myslíte klasické HTTPS bez přihlášení klientským certifikátem, tam je samozřejmě šifrovaný i upload. Pomocí TLS je šifrovaná celá komunikace, oba dva směry. Stačí si uvědomit, že kdysi se říkalo, že by se přes HTTPS měly přenášet alespoň přihlašovací údaje a obsah vyplněných formulářů s osobními daty – a to je právě upload.

Máte samozřejmě pravdu, myslel jsem hlavně to ověření/přihlášení: vy věříte serveru, protože má správný certifikát, ale server vám věří "jen" jméno a heslo.
Pokud by byl server v Internetu, nic nebrání, aby to někdo zkoušel (hrubou silou nebo jinak), ale při vynucení klientského certifikátu se nemusí dostat ani na první stránku.