Dotaz: Bezpečná centrální správa asi 150ti PC

[chinook]

Zdravím, mám cca 150PC různě po republice, většina není ani viditelná z internetu.

Občas potřebuju od tama stahovat nějaká data. Něco tam nahrát. A něco změnit v konfiguraci. Ted to řeším tak, že na každém PC je cron. Ten se spustí pod rootem a rsyncem to postahuje z centrálního serveru a případně restartuje službu.

Jsem si vědom bezp. rizika, že ta sít PC lze celkem jednodušše zhodit pokud se někdo dostane na ten centrální server.

Po včerejších problémech s windows isssue, bych to rád nějak líp zabezpečil. Jen mě nic kromě lepšího zabezpečení serveru nenapadá. Protože občas tam jsou potřeba i práva roota.

Poradí někdo jak to řešit?

Asi určitě, každé PC co stahuje konfiguraci ze serveru, by mělo tam mít jen práva čtení, aby v případě kompromitace jednoho PC nešla zhodit celá sít. Ale víc jsem nevymyslel.

---

---

Odpovědi

[X]

Tak to vem obracene. Jak by jsi tu sit konkretne shodil?

[chinook]

Tak problém je to PC z kterého se stahují ty scripty, které následně pouští root. Takže asi hledat řešení tam.

[X]

Neodpovedel jsi na otazku.

[chinook]

Jakto, že ne?

Slabé místo je, ten server odkud se to synchronzuje. Protože se od tama stáhne script, který se na klientech spouští pod právy roota.

Přihlašování mezi klientama pomocí klíčů, jsem zrušil, resp. tam dal heslo. Tzn. jediné slabé místo je ted ten server.

[X]

Ja se neptam co je slabe misto, ja se ptam jak by jsi tu sit shodil?

[chinook]

Dám do toho scriptu co je na serveru a spouští jej všichni klienti něco jako:

rm -rf /

Pokud je to tvůj záměr, tak je to pořádku. Ale zřejmě nějak nechápu, o co ti jde.

Ty se bojíš, že ti na serveru někdo změní ty skripty, které se mají spouštět na klientech? Tak omez všechno, co se ti přihlašuje na server, na minimum.

Když si uděláš nějaké VPNky z klientů na server a všechna vzdálená přihlášení se budou odehrávat pouze ve směru server klient, tak prostě ten server bude ohrožen míň. Kromě toho, když se dá ke klientu vzdáleně přihlásit, je to určitě lepší, než když se musí spoléhat na to, že kýženou změnovou akci na klientovi provede zaručeně správně napsaný skript stažený rsyncem ze serveru.

[X]

Utocnik se na server dostane jak?

[chinook]

Doufám, že nijak. Ale je to nejslabší místo. Děkuji všem za odpovědi. Spíše jsem čekal, že bude nějaké lepší řešení, než toto co používám asi 10let.

Server jsem tedy jen pro jistotu přeinstaloval. A vše nahrál zpátky.

Server není dostupný z internetu a ani žádné klientské PC.

Všichni klienti jsou za routerama, které jsou přes VPN připojen k serveru. Tzn. Všechna komunikace se serverem probíhá přes VPN.

Na server se dá přihlásit jen přes klíče a chodím na něj z lokální sítě. Sice z windows 11, ale nejsou tam práva Admina a běží tam jen pár aplikací na kanc. činnost a antivir.

Scripty na serveru jsou vytvářeny pod rootem a pod jiným uživatelem si je klienti stahují. Tedy nemůžou měnit obsah.

Klienti se mezi sebou nevidí, tzn. Jeden druhého by také neměl ovlivnit.

Server budu tedy dál pravidelně aktualizovat. Skoro nic tam neběží a věřit, že to vydrží min. Dalších 10 let.

[Tom K]

Ještě by šlo skripty podepisovat a na klientech kontrolovat podpis.
Pak by ani nabourání serveru útočníkovi nepomohlo.

[…]

vcerejsi problemy byly o tom, ze to neotestovanej zabezpecovaci software shodil, cili z toho asi nevyvozujes relevantni zavery, rekl bych… tady je ta lekce imho o necem jinym, a sice o nejakych procesech, testovani vs. velkem tresku na jeden prikaz, co uz nejde vratit :D takovy ponauceni bych si z toho bral ja, tj. bude o nejakym postupu deploymentu, ne o ochrane proti kompromitaci…

[...]

jeste to muzes pojmout tak, ze od sebe na tom serveru ty veci oddelis tak, aby bylo potreba nekolik bezpecnostnich chyb najednou, aby se z jednoho izolovaneho prostredi dalo vlamat do druheho - tj. pres pouziti nejake kontejnerizace, napr. - tak, aby 1 PC nevidel na zadna dalsi data, nez ma urcene

[...]

(samotna data jde urcite poresit jen pres ugo/rwx na FS primo, s kontejnerizaci jde jit kousek dal, nesdilenim zadneho rsync, ssh, atd. kodu, ale asi by principialne stacilo i jenom to oddeleni dat, pro lepsi pocit... zalezi, kdo k tomu 1 serveru ma pristup, jak moc jsou to bordelari, atd.)

[chinook]

Uplně jsem to nepochopil, ale zdá se, že asi nic universálního nebude. Tzn. budu se soustředit jen na ten server. Kam mám přístup jen já, tzn. zabezpečit by to mělo jít v pohodě.

[kulchs]

co tam maáš za OS že se ptáš na root a rsync

[chinook]

PC UBUNTU a SERVER DEBIAN

[Peter Golis]

Nebol na podobné veci Ansimble?

Len sa pýtam, akosi nie je ozrejmené čo sa má na tých strojoch vzdialene riešiť.

[MP]

Pokud to nejsou servery, tak ansible je na nic (stroje jsou nedostupne). Chce to spis neco typu puppet atd.

[MP]

Pokud to jsou servery, tak ansible je ok. Pokud jsou to stanice, co jsou casto vypnute, tak potrebuje neco typu puppet.

[chinook]

Jsou to stanice a k půlce nich se ani nejde vzdáleně připojit. Resp. jde ale ne uplně jednodušše. Není to potřeba.

Když se stanice mohou připojit vzdáleně na centrální server, tak je možné připojit se z centrálního serveru na stanice. Stačí si tam vybudovat nějaký tunel. Takže potom to můžeš obrátit a místo abys konfiguroval nějaké stahování stanicí ze serveru, můžeš ze serveru provádět změny na stanicích.

[Peter Golis]

Tunel, VPN alebo iné pripojenie. Určite tam bude nejaký typ internetu ktorý by vedel tie stanice pripojiť do firemného intranetu kde sedí server.

[chinook]

TO ano to by se dalo vyřešit, ale zatím nevím jestli to potřebuju.

Jestli nebude stačit zabezpečit ten server z kterého se to stahuje.

twl, ty ten server nemáš zabezpečený už teďka? Staráš se o 150 PC po celé republice a server nemáš zabezpečený?

[eagle.metawerzum]

Nač stahovat kalhoty, když brod je ještě daleko.

[chinook]

Ale tím se toho moc nevyřeší nebo ano?

Furt slabé místo bude ten server a půjde to vše zhodit tím serverem.

A s anisble má jakou hlavní výhodu oproti tomu tak jak to mám?

[Peter Golis]

Pokiaľ je ten server nezabezpečený (alebo heslo je NBUSR123 SolarWinds123), tak je jedno či riskuješ profesionálneho záškodníka z internetu alebo nejaké decko čo si sadne za jeden z tých 150 endpointov. Na sto percent sa to stane, a na tisíc percent keď budeš za to zodpovedný ty.

[Xerces]

Tak proč tě vzrušují nějaké problémy na Windows platformě?

[X]

Boji se, ze se uklepne v bash skriptu a bude jezdit po cele republice ;)..

[ewew]

Reverzný ssh tunel z cieľového pc a potom pripojiť z servera smerom k cieľovému pc. To vyrieši neviditeľosť cieľového pc do internetu ak server je na verejnej ip adrese.

[eagle.metawerzum]

Máš tam dvě úrovně, na kterých můžeš něco zabezpečovat.

První úroveň je důvěryhodnost komunikačního kanálu a serveru. Tedy že si ověříš, že cílové PC komunikuje skutečně se svým serverem a že na serveru není nic pochybného. To znamená šifrovat komunikaci a ověřovat klíče, což snadno zajistíš třeba Wireguardem nebo SSH. Na serveru samotném pak nesmí být nic dalšího, aby jsi neměl díru někde vedle, i když samotná synchronizační služba by byla zabezpečená dobře.

Druhá úroveň je obsah. Instalační balíčky se běžně podepisují a klient, který si je instaluje, si napřed podpis ověří. Například při instalaci aplikace na Androidu musí být balíček s novou verzí aplikace podepsaný stejným klíčem jako instalovaná verze. Pokud na serveru nebude klíč k podepisování instalačních souborů/obrazů, tak i když útočník udělá na serveru cokoliv, tak klientské PC zjistí, že podpis nesedí a nic nenainstaluje. Klíč pak můžeš mít schovaný na HW tokenu a při přípravě aktualizace soubory podepsat na jiném stroji, aby server nikdy nemohl sám instalační balíček vytvořit. Konkrétní nástroje záleží na tom, jak věci děláš, například můžeš mít podepsaný seznam všech souborů s SHA1 hashi všeho a na klientovi ověříš podpis toho seznamu a pak tím seznamem ověříš všechny soubory po stažení, ale předtím, než je reálně použiješ.

[X]

Jeste bych pridal ne-existenci zalozniho serveru v pripade vypadku verzovani konfigurace a "rollback" mechanismus pri selhani aktualizace.

Zalezi jak moc je to kriticke, do jake hloubky to chces resit a kolik tomu venujes casu. Osbne se drzim hesla "v jednoduchosti je krasa".

[Josef Kufner]

Záleží, zda řešíš spolehlivost, nebo bezpečnost. Záložní server, verzování a rollback je o spolehlivosti. Podepisování a šifrování o bezpečnosti.

Krása je sice v jednoduchosti, ale ještě více je v automatizovanosti a reprodukovatelnosti.

[ert]

Rek bych, ze resis neco uplne jineho, nez na co se tazatel pta.

Pokud jsem to pochopil ja, tak mu jde primarne o to, aby tam nepustil nejaku akci a nesejmul si ty klienty. Utocnik si klidne na serveru pocka az tam prijdes a pocka si az budes neco podepisovat ...

Ale pokud se nebavime o umyslnym utoku, tak je potreba pred kazdou akci na klientovi vyrobit snap a nastavit to tak aby pri pripadnem failu nastartoval prave z toho snapu.

Ovsem jinak ... je potreba predevsim zadne (widlo)aktualizace neinstalovat ...

https://www.ghacks.net/2024/07/25/windows-latest-security-update-is-causing-huge-issues-for-some-users/

[eagle.metawerzum]

Pointa je v tom, že na tom serveru se nikdy nic podepisovat nebude a klíče k podpisu tam nikdy nebudou. Server je pak jen komunikační kanál, nikoliv autorita. Balíčky se vytvoří a podepíšou někde uplně jinde a serveru se jen předají k distribuci. Pokud podpis nesedne, klient balíček nenainstaluje a server ani útočník s tím nic nenadělá.

[LA_USER]

Tohle mi smrdí....

Staráte se o 150 PC, cca 10 let....

Asi za to jste finančně ohodnocen...

A za 10 let jste se nenaučil s Ansiblem, nebo OpenVPN/Wireguardem...

Dle mě, děláte něco hodně špatně.

[Cronin]

... ale hodlá s tým niečo urobiť, čo je rozhodne pozitívnejšie ako deštruktívne komentáre, že áno?

[Ruža Becelin]

Klicove slovo je Configuration Management.

Nahodit neco jako CFengine, Chef, Puppet, ...

Konfigurace v gitu.

Cokoli jineho nema smysl...