logo
18.09.2020 16:45
151
Původně odeslal Wladass
Za 4 dny dát dohromady komplet hosting od nuly? Za mě klobouk dolů.
Tady je děsivé to, že něco musí dávat dohromady od nuly.

To je tady to selhání.

A není jedno:
Zálohování serverů? Nic.
Zálohování konfigurací? Nic.
Zálohování infrastruktury? Nic.

Proč máme více DNS serverů? Aby když jeden vypadne, tak služby nevypadly. V Subregu je více DNS serverů zdá se kosmetická záležitost a nemají žádný reálný sekundární DNS server, který by byl infrastrukturně oddělený. To si mohu dovolit já pro sebe a svých 30 domén, co tam mám a jsem schopný nahodit zonefile ze zálohy kamkoli.

Co se právě děje na Webtrhu?

18.09.2020 17:35
152
Původně odeslal sulphate
nikdo nerika, ze neni, ale tenhle styl komunikace mi tedy nevyhovuje uz od pondeli
s gransym som sedel v sobotu a od vtedy je furt offline, takze mi ver ze na tom maka 24/7 a pochybujem ze on aj jeho tim tento tyzden spali viac nez 12 hodin. ty asi nemas sajnu co by stalo platenie nejakeho helpdesku ktory by nieco taketo vedel zmenezovat z hladiska PR. gransy/subreg su ajtaci a taki proste makaju na produkte a nie marketingu. takze je na hovno ze sa ti nepaci ako komunikuju ale co cakas ze ti povedia? skrata to bude ked to bude a ani ked ich budu otravovat vseci zakaznici tak sa to nezmeni.

inak dnes mi doslo ze mam u subregu moju mejlovu domenu a popravde som za cely tyzden nepozoroval vypadok(profi email od seznamu).
18.09.2020 17:40
153
Původně odeslal sulphate
nikdo nerika, ze neni, ale tenhle styl komunikace mi tedy nevyhovuje uz od pondeli
Njn mne nevyhovuje zdrazeni jablek
18.09.2020 20:23
154
Jako souhlasím.. Ta komunikace je průser. A tady by měla být prioritní.
18.09.2020 23:58
155
Původně odeslal node
s gransym som sedel v sobotu a od vtedy je furt offline, takze mi ver ze na tom maka 24/7 a pochybujem ze on aj jeho tim tento tyzden spali viac nez 12 hodin. ty asi nemas sajnu co by stalo platenie nejakeho helpdesku ktory by nieco taketo vedel zmenezovat z hladiska PR. gransy/subreg su ajtaci a taki proste makaju na produkte a nie marketingu. takze je na hovno ze sa ti nepaci ako komunikuju ale co cakas ze ti povedia? skrata to bude ked to bude a ani ked ich budu otravovat vseci zakaznici tak sa to nezmeni.

inak dnes mi doslo ze mam u subregu moju mejlovu domenu a popravde som za cely tyzden nepozoroval vypadok(profi email od seznamu).
taky cekam od pondeli, zatim tedy jen 24/5 (avsak telo ma sve limity) az ty DNS pojedou normalne, protoze porad cekam a kontroluju jestli se to treba nepodela, abych to pripadne hned zmigroval - informace pro nase planovani a rozhodovani tady bohuzel neexistuji, to, ze se obcas neresolvne nejaky zaznam beru tento tyden skoro jako standard, ale urcite by to uz chtelo vyresit, protoze to bohuzel zacina pusobit trochu zvlastne

ale bohuzel ta Vase teorie s tim, jak ani nespi a makaji se mi nezda byt uplne realna, samozrejme se muzu mylit, ale ani vcera v noci, ani dneska v noci nikdo na facebooku nereaguje (mozna je tam jen podpora pres den a budou zrejme mozna zase az v 8 rano jako vcera ;) posledni update tam vidim vcera v 8 rano.. o DNS vubec neinformuje, jako by snad bylo vse v poradku

prijde mi bohuzel skoda, ze neni mozne rozfungovat zakladni sluzbu jako je DNS v nejakem rozumnem case, nebo Vam to prijde v pohode?

ono pokud nedelate v DNS nejake zmeny v zaznamech, tak Vam to asi fungovat muze - to je pravda, ale kdyz budete potrebovat neco zmenit, tak jste v haji, protoze zhruba polovina serveru vraci stale puvodni hodnotou, tzn. v podstate nedocilite zmeny zaznamu a nebo az po opravdu dlouhe dobe - pro zajimavost - vcera v 8 vecer jsem aktualizoval zonu a nyni v 5 rano tu novou zonu vraci pouze 7 z 12 NS a zbylych 8 NS je nedostupnych (timed out)

pardon, trochu jsem se rozepsal, protoze se nudim - jelikoz mozna vsichni spi ;) kdyz si ted lehnu do postele, tak asi budu taky offline, ale neznamena to, ze pracuji ;)

na zaver, to jestli spi nebo pracuji je mi uprimne jedno, ja chci proste normalni informace na rovinu a funkcni DNS, coz i u maleho registratora povazuju za standard

---------- Příspěvek doplněn 19.09.2020 v 00:01 ----------

Původně odeslal Wladass
Jako souhlasím.. Ta komunikace je průser. A tady by měla být prioritní.
bohuzel, nejen tragicka komunikace - DNS vnimam jako celkem zasadni, jelikoz je na tom vse dalsi zavisle.. mail, web, atd..

---------- Příspěvek doplněn 19.09.2020 v 05:41 ----------

Původně odeslal Oleg
Njn mne nevyhovuje zdrazeni jablek
no jo, jenomze komu by to take vyhovovalo? ;)

---------- Příspěvek doplněn 19.09.2020 v 09:05 ----------

no, ale dnes po ranu tedy opravdu mile prekvapeni! DNS konecne funguji a jeste k tomu velmi podrobny update.. konecne zacinam mit pocit, ze zase vidim Subreg
jdu se konecne trochu prospat, tak at se dari a je videt, ze jsem se mylil a opravdu nespi.. dneska hodne dobre zpravy! diky
19.09.2020 19:34
156
Já tuhle situaci moc nesleduju, jen ze zajímavosti, ale dnes zveřejnili tohle:

O co jsme zatim nenavratne prisli je administrace controlpanel.cz – bohuzel jeji verze kterou mame k dispozici je nekompatibilni s posledni verzi databaze, ktera bude obnovena, protoze v mezi case doslo k zasadnim upravam s ohledem na provazani sluzeb mezi sebou a fakturace.
Můžete mi to někdo vysvětlit? Oni ten SW na administraci nemají v nějakém VCS?
19.09.2020 20:06
157
Původně odeslal Holicz
Já tuhle situaci moc nesleduju, jen ze zajímavosti, ale dnes zveřejnili tohle:



Můžete mi to někdo vysvětlit? Oni ten SW na administraci nemají v nějakém VCS?
Ano, také to tak chápu, že ten SW nemají nikde jinde. Měli git repositář, ale měli ho na těch serverech, které jim útočník promazal. Tohle vypadá, že jim to vnitřně pěkně hnilo, občas je dobré jednou za rok si zaplatit externistu, aby udělal audit, někdy člověk nevidí svoje vlastní zjevné chyby a nedojdou mu důsledky.
19.09.2020 20:51
158
kde to pisu? na twittery nic, na blogu nic a na fb sa uz bez fb uctu neda ist. celkom ma zaujima nejake post mortem.
19.09.2020 21:01
159
Tady se začínají objevovat celkem zajímavý komentáře: https://wladass.cz/subreg-hacknut-timeline/#comments

Víc už k tomu nemám a říkat nechci. Je na čase se začít věnovat důležitějším věcem.
19.09.2020 21:11
160
asi kvoli adblocku mi tam nejde reagovat na creckxa takze to hodim sem - podla https://tools.ietf.org/html/rfc5731 je authInfo(on to pise ako AuthID) plain text a prevod moze schvalit iba administrator alebo majitel domeny, ktori maju uzivatelske hesla hashnute, takze k unosu domeny v ziadnom pripade nehrozi.
19.09.2020 21:37
161
Když máš auth-ID tak už pak nic nepotvrzuješ. Zadáš ho u nového registrátora a doména je převedena.
20.09.2020 12:43
162
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.
20.09.2020 12:57
163
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álohy

Zálohování je zbytečnost, zbytečný náklad - do první ztráty dat
20.09.2020 12:58
164
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.
20.09.2020 13:18
165
strasne mudri su tu vseci, ale kolko z vas ma svoj vlastny biznis s desiatkami tisicov zakaznikov a kopou zamestnancov?
20.09.2020 13:30
166
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.
20.09.2020 13:36
167
Původně odeslal node
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.
20.09.2020 13:45
168
Původně odeslal TomášX
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 :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
20.09.2020 14:06
169
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.
24.09.2020 22:17
170
Původně odeslal node
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.
24.09.2020 22:48
171
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!
25.09.2020 09:36
172
Původně odeslal Whois Proxy
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é.
25.09.2020 10:14
173
Klientce stále nefunguje web.... jakože mazec, toto je vážení fakt mazec...
25.09.2020 10:22
174
Původně odeslal pawlisko
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 jinde

nebo je problém v DNS? přenést dns servery a záznamy např. na cloudflare
25.09.2020 10:29
175
"Unknown host ..." píše web

Jinak 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...
25.09.2020 10:34
176
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.
25.09.2020 11:45
177
Psal jsem jim o bile strance uz pred 3 dny. Neustale "mejte prosim trpelivost".... na fcb pisi ze problem s dns ma par desitek webu. To je za me kec, staci si spocitat odkazy v komentarich.

A php? Klientka ma statickou prezentaci....
25.09.2020 12:34
178
Já teda Subreg používám jako primárního registrátora už 8 let, tohle je jejich první fuck-up, ale i tak mám pocit, že to opravili dost rychle...

Jinak DNS mám vlastní na PowerDNS, jejich DNS používám jen pro 3 domény a tam je vše ok. Hosting naštěstí nemám, každopádně z pohledu domén a DNS se zdá, že již vše funguje...
25.09.2020 12:46
179
Drtivá většina jede. Někde prostě trvá než se to samo propíše. U některých klientů to trvalo třeba týden.
25.09.2020 12:52
180
Původně odeslal TomášX
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.
Došlo tam k úplný ztrátě administrace controlpanel.cz, tj včetně DB a záloh. V DB byly mimo jine data pro DNS Station, poštu, konfigurace webserverů (pro vhosty).

Připravit celý hosting na novo by byla práce na den. Připravit to ale tak, aby to bylo kompatibilní s datama zákazníku, kdy k tomu nemáš ani řádek, to prostě jednoduše nejde.

DB se podařilo vyšťourat vyloženě po sektorech z disku až pár dnech. Nicméně ty data jsou v průběhu času ukládána několikanásobně a složit pak celou tabulku aby byla správná a aktuální je opravdu porod. Trvalo několik obnov, než se podařilo získat takméř původní stav DB. Jenže za tu dobu se udělalo spousta změn co nedovolila prostě vzít DB a celou ji na čisto naimportovat. Například sloučením Station DNS s Gransy DNS, které obsahovali historické nebo automatické zóny.

Prostě ve snaze urychlit spuštění došlo k několika protichůdným krokům který měli smysl jen v daný okamžik a o pár hodin už byly out s ohledem na nový stav - nový data, atd

Mimo jiné upřednostnění zákaznických služeb před vlastními (pošta/telefon) byla taky dost nešťastná avšak dobře mířená věc. Na FB řešilo požadavky až 5 lidí naráz, ale díky tomu jak tam fungují zprávy a komentáře, to je při tý kandenci dotazů naprosto nemožný odřídit.

Nic neobhajuji, nic neomlouvám - stalo se to v pondělí ráno, v úterý jel Subreg. Od středy do pátku jelo více než 50% zákazníků bez problémů. Zbylých 50% se dotkl problém s DNS Station, změna PHP verze, problem s obnovenýma konfiguračníma tabulkama, atd.