Subreg/Gransy je pod útokem, většina jeho služeb nefunguje

Střípek informací z Facebooku Subregu, který odpovídá i na některé spekulace ve zdejším vlákně:

Lide se i ptaji, proc jsme nemeli zalohy, proc nepouzivame git, virtualizaci, conteinerovani, zalohy v jinych lokalitach, atd. Pouzivali jsme uplne vsechno. Zalohovali jsme zcela mimo nase racky, spousta sluzeb byla virtualizovana, sluzby noveho hostingu dockerizovane, a vyvoj novejsich sluzeb i v GIT repositarich na vlastnim GIT serveru, ktery byl geograficky zalohovan. Bohuzel byla ale vyuzivana i jedna vec, co nemela byt. A to SSH klice mezi servery pro jednodusi automatizaci a reseni veci. Toto byla ta pricina ktera se nam vymstila, ze utocnik provedl kompletni likvidaci (primarne smazani /etc, /var ... sekundarne pak vsecho obsahujici slovo "backup" a finalne zbytek). Toto byla ta finalni chyba diky ktere byla zkaza fatalni.

Základní pravidlo - nezálohuji na backup server, ale backup server zálohuje na sebe.Jeho zabezpečení musí být největší. On se dostane všude, na něho "nikdo".Hodí se generovat i offline zálohyZálohování je zbytečnost, zbytečný náklad - do první ztráty dat

Tady se mimo jiné ukázalo, jak je napr zálohovací proces, když zdroj má plny přístup k záloham. Hold si neudělá analýzu rizik navrženého procesu zálohování. Já osobně na to vždycky upozorňuji a případně nabízím jiné řešení, kdy je pak server odsrinen od vlastních záloh.Automatizace a infrastruktura as code by jim taky usnadnila práci.

strasne mudri su tu vseci, ale kolko z vas ma svoj vlastny biznis s desiatkami tisicov zakaznikov a kopou zamestnancov?

zrovna infrastructure as code vede právě k podobným problémům, stejně tak automatizace. Jakkákoliv chyba v konfiguraci nebo proniknutí způsobí vlnu, která projde jak nůž úplně vším. Dokud se dělalo vše ručně, na vše znovu zadávaná hesla, bylo to sice humpolácké, ale nedošlo k násobení rizik, naopak moderní přístupy mít vše automatizované vedou k centralizaci přístupových oprávnění (ssh klíčů) na stroje vývojářů nebo CI servery. Docker z pohledu bezpečnosti je také dost problémů.Ve světě kritických infrastruktur děláme kompletně oddělení DR prostředí, kdy i git a CI server jsou extra, neexistují žádné přímé prostupy právě z důvodu konfiguračních či jiných chyb. Prostředí musí být nezávislé, jinak se to nedá nazývat DR a neprojde formálním auditem na spolehlivost. Cenově to je ale drahé a u malých projektů to nepoužívám.Při deploymentu je naopak poměrně užitečné při zásazích do produkce vyžadovat klíče a hesla od dvou a více adminů (útoky na stanice vývojářů se množí a jsou dnes běžnou praxí), aby byla vzájemná kontrola (technicky lze řešit podepisováním ssh klíčů a vynucením dvou podpisů v chainu nebo vlastním authorizačním serverem, který tu schopnost má). V prostředí cloudů, kubernetes a containerů je tohle více než důležité.Stejně tak je kardinální problém nepoužívání offline backupů a jejich rotování (v enterprise světě i dnes máme pásky, vycházejí nejlevněji, v cloudech se naopak mixuje více účtů a uložišť). Při backupech je nejhorší varianta je mít připojené přes nfs/sambu s write přístupem, kdy backupující může staré smazat (stejná chyba se dělá i u logování, aplikace nesmí mít možnost smazat svoje logy). Append only (někdy to je funkce v rámci CoW) přístup umí dnes i spousta filesystémů (brtfs, zfs), file distribuovaných služeb (hdfs, glusterfs) nebo cloudů (s3, azure block storage).V rámci akceptačních testů děláme vždy nějakou formu DR, často se kompletně smaže testovací produkce a nahazuje se ze záloh znovu. Nejedná se pouze o data a nastavení, ale i repositáře pro linux a podpisové klíče pro balíčky. Zrovna třeba u výše zmíněných Vodafone je tohle běžná rozcvička před přejímkou jakkéhokoliv systému, kdy se interní IT učí hlavně, jak to celé zprovoznit na čisto. I na našem trhu je několik firem, které se živí penetračními testy, dají se jim různé druhy přístupů, dokumentace a zkoušejí co nejvíce škodit, cena za takový test jde ale do stovek tisíc a není to pro každého.Už párkrát jsem zažil, že vyhořel celý rack v servovně, stačí jeden zkrat, požár jednoho serveru a jde celá skříň (někdy i ta vedlejší) do háje, když jsem třeba v low cost DC6, je tam vidět ve velkém, že řada firem má maximálně jeden sdílený rack, to je dneska obrovské riziko.

Napsal node;1597868

strasne mudri su tu vseci, ale kolko z vas ma svoj vlastny biznis s desiatkami tisicov zakaznikov a kopou zamestnancov?

pokud děláš B2B, tak desítky tisíc zákazníků je trochu utopie ;). Pro mě to je blízké téma, živím se infrastrukturou a provozem velkých systémů a zaměstnávám vlastní tým lidí. U mých projektů jdou podobné katastrofy právě na moji hlavu. Stav, do kterého se Subreg dostal nasvědčuje tomu, že to neudělali dobře, chci dělat osvětu hlavně pro ostatní, ať ví, co je možné a jak se to dá také řešit. Subreg si teď musí poradit sám.

Napsal TomášX;1597872

pokud děláš B2B, tak desítky tisíc zákazníků je trochu utopie ;). Pro mě to je blízké téma, živím se infrastrukturou a provozem velkých systémů a zaměstnávám vlastní tým lidí. U mých projektů jdou podobné katastrofy právě na moji hlavu. Stav, do kterého se Subreg dostal nasvědčuje tomu, že to neudělali dobře, chci dělat osvětu hlavně pro ostatní, ať ví, co je možné a jak se to dá také řešit. Subreg si teď musí poradit sám.

z toho co pisu mi skor pride ze to praveze dobre robili, akurat sa im dostal nejaky bot cez pc zamestnanca k dolezitemu ssh klucu a potom uz to padlo ako domcek z kariet. cize tak 99.99% mali "spravne" akurat to 0.01% ich zhodilo a machrovat so 100% nemoze nikto, ani ty tomas :DPS: ale z gransym mam biznis vztah takze ak sa jemu dari, dari sa aj mne. takze som zaujaty a keby som mal unho nejaky dolezity projekt ktory by ma zivil a prisiel by som o kto vie kolko penazi sposobene takymto vypadkom, tiez by som nebol uplne spokojny, ale to uz su emocie a realita je taka aka je a ako som pisal, nikto s tym nic nenarobi, treba len vyckat a prisposobit sa situacii.PPS: a znovu sa ukazalo ze moj hejt na ssh kluce a vsetko s nimi spojene je opodstatneny :D

a ty považuješ za správné chování, když ti někdo může takhle smazat komplet vše? Přece v takových případech nemůžeš tvrdit, že 99 % fungovalo dobře... Správně to nejspíš neměli, když se to stalo. To jestli to dopředu věděli, mohli vědět či nemohli je jiná věc.Problém nejsou ale samotné ssh klíče, ale to, že neměli kontrolovaný přístup k produkčním serverům, to stejné se ti může stát s hesly, nebo ve fyzickém světě, když máš klíče k trezoru v obyčné skříňce kam může kdokoliv.

Napsal node;1597875

z toho co pisu mi skor pride ze to praveze dobre robili, akurat sa im dostal nejaky bot cez pc zamestnanca k dolezitemu ssh klucu a potom uz to padlo ako domcek z kariet. cize tak 99.99% mali "spravne" akurat to 0.01% ich zhodilo a machrovat so 100% nemoze nikto, ani ty tomas :D

PS: ale z gransym mam biznis vztah takze ak sa jemu dari, dari sa aj mne. takze som zaujaty a keby som mal unho nejaky dolezity projekt ktory by ma zivil a prisiel by som o kto vie kolko penazi sposobene takymto vypadkom, tiez by som nebol uplne spokojny, ale to uz su emocie a realita je taka aka je a ako som pisal, nikto s tym nic nenarobi, treba len vyckat a prisposobit sa situacii.

PPS: a znovu sa ukazalo ze moj hejt na ssh kluce a vsetko s nimi spojene je opodstatneny :D

Na 99.99% správně? To jste se zbláznil. Toto je zásadní zranitelnost skrz celou infrastrukturu. Jedna věc je, když máte zranitelný jeden stroj, druhá je, když máte naprosto zásadní chybu v infrastruktuře.

A tak to vypadá, když je nějaký proces co se zajede před 10-15ti lety, který pomáhá řešit danou problematiku a nejsou s ním žádné problémy .... člověk taky nosí svoji oblíbenou peněženku tak dlouho, dokud se mu nerozpadne. A jestli to je špatně ? Ano je! Svět kolem nás se vyvýjí, technologie taky, zabezpečení taky - ruku v ruce by měli jít i postupy, byť jsou zavedené a plně automatické. Zde rozhodně neplatí rady našich babiček a dědečků: Dokud to funguje, nešahej na to!

Napsal Whois Proxy;1598392

A tak to vypadá, když je nějaký proces co se zajede před 10-15ti lety, který pomáhá řešit danou problematiku a nejsou s ním žádné problémy .... člověk taky nosí svoji oblíbenou peněženku tak dlouho, dokud se mu nerozpadne. A jestli to je špatně ? Ano je! Svět kolem nás se vyvýjí, technologie taky, zabezpečení taky - ruku v ruce by měli jít i postupy, byť jsou zavedené a plně automatické. Zde rozhodně neplatí rady našich babiček a dědečků: Dokud to funguje, nešahej na to!

Vidím to také tak. Když jsem začínal, stačilo denně prohlédnout logy na každém serveru, pak se přišlo s remote syslogem, pak byl elastic/splunk, dnes se nasazují rozsáhlé realtime systémy typu SIEM, u nás to již mají několik let všechny banky, nově to začínají implemetnovat a osvojovat operátoři. Dokonce i pár projektů máme přímo pro datová centra, kdy to chtějí poskytovat jako formu zajištění pro svoje klienty. Dnes přestává stačit mít systém dobře zabezpečený pro útok z venku, útočí se na zaměstnance, sociální inženýrství je na vzestupu, někdy jsou útočníkem i sami zaměstnanci, do sítě se nosí cizí zařízení, DMZ a bezpečnostní perimetr už je skoro také věc minulosti a to ještě spoustu firem ani tohle nestačila zavést.Mám dobré zkušenosti např. s českým produktem logmanager.cz, Miroslava Knapovskýho znám ještě z HPE a tenhle produkt hodně pozvedl. Tohle je cesta, kam se bezpečnost teď ubírá a co se řeší. Hrozby jsou rychlé, objemy provozu velké.

Klientce stále nefunguje web.... jakože mazec, toto je vážení fakt mazec...

Napsal pawlisko;1598405

Klientce stále nefunguje web.... jakože mazec, toto je vážení fakt mazec...

určitě má zálohy a potom není problém rozjet web jindenebo je problém v DNS? přenést dns servery a záznamy např. na cloudflare

"Unknown host ..." píše webJinak FTP jede až dnes.... hned jak to bude možné, tak se udělají zálohy (jen email má téměř 10GB) a přesune se to jinam, ale bez záloh není co obnovovat...

s DNS mají pořád nějaké problémy, vyzývají, aby jim lidé napsali, pokud nebude jejich zóna funkční. Za mě je asi vhodnější udělat přesun DNS, pokud ještě vše nefunguje. Ostatní věci vč. ftp a webu by už měli běžet. Bohužel museli dělat nějaké upgrady php a dalších subsystémů, takže některé weby je potřeba lehce upravit.Z počátku jsem věřil, že to za pár dní dají dohromady, tohle vypadá jako pořádná bota.