Pekne, pekne... jen teda k slibovanym informacim se pomoci (sic obstarozniho) protokolu WHOIS nedostanete...
$ whois -h whois.gov.cz ctu.gov.cz connect: Connection timed out
TCP/43 je bedlive ochranen firewallem, takze na TCP/SYN svorne po IPv4 i IPv6 nic neprijde :-)
RDAP je na tom lepe... ale take to bude chtit (i co do spravnosti obsahu) doladit :)
$ curl -s https://rdap.gov.cz/domain/ctu.gov.cz | jq .port43 "whois.nic.cz"
...(vraceny udaj je v principu nesmysl, tam ta informace neni) - a rovnez vsechny links.value ve vracenem json response maji http:// ...takze vse beztak konci na http/301 redirect na https://... proc se tam nevrati rovnou https:// v roce 2025 asi taky nechapu :-)
"links": [
{
"value": "http://rdap.gov.cz/entity/CESKY-TELEKOMUNIKACNI-URAD",
"rel": "self",
"href": "http://rdap.gov.cz/entity/CESKY-TELEKOMUNIKACNI-URAD",
"type": "application/rdap+json"
}
]
Zabavnou obsahovou perlickou (co asi ma puvod primo v DIA) je skutecnost, ze dle overeneho vypisu je identifikacni cislo pry neverejny udaj, dle webu stejnou vlastnosti "trpi" i DIC... :-)
jako, že bychom mohli zažít aukci na gov.cz? Uvidíme příští rok...
Podle whois https://www.nic.cz/whois/domain/gov.cz/ to vypadá jako běžná doména a nikde jsem nezaznamenal to, že by měla mít extra režim.
No uplne "bezna" neni - je to pokryte smlouvou, ostatne jsme se o tom bavili jinde. Vc. toho "rezimu".
A co i samotny "registrar"? :-) Co nam ani na seznamu nefiguruje? To je malo specificke? :-)
On je "specificky"... REG-CZNIC existuje urcite dele, jsou pod nim (dlouhodobe) mj. vsechny domeny samotneho CZNICu. A od roku 2024 take vsechny VIP domeny. Aneb za 150k rocne muzes mit takoveho registratora i ty ;-) Mit tam dalsi "navic" si myslim samotny CZNIC ani neriskne - uz jen proto, ze je pod kontrolou samotnych clenu (vc. registratoru).
A z ceho jste to dovodil? :-) Uz leta existuje Ferda, coz je webove rozhrani pro spravu FREDa.
Právě že jsou všudy přítomná.
Útočníci se na ně zaměřují.
Něco tak důležitého jako gov.cz by mělo být o level lépe zabezpečený než tiskárna nebo pračka.
2FA bych vyžadoval bez výjimky.
Ani TLS není zárukou bezpečí. Verze 1.0 a 1.1 jsou děravé jak ústa staré ženy. A je jen otázka času než prolomí 1.3. Kterou používám.
S 80 to byla nadsázka.
10. 12. 2025, 07:53 editováno autorem komentáře
A tak rozhodne se to obednuje a zabezpecuje jednoduseji, nez ruzne proprietarni protokoly, kde cela bezpecnost je postavena casto jen na obskurdnosti. A samozrejme se serverova cast v pripade hypotetickeho prolomeni TLS1.3 bude resit na webserveru snaze, nez ty ruzna proprietarni "experty" dodana resenicka, zeano. To se tyka i zmineneho MFA (a na to navazanych resenich se SAML/OIDC), ktere mate v prohlizecich implementovane a pripadnou "diru" tam jiste opravi rychleji, nez v te "proprietarni" appce, ktera to bude mit zbastlene buhvijak.
To, jak to vypada v praxi na serveru si samozrejme muzete zbezne otestovat. Asi neprehlednete, ze TLS<1.1 tam nepouzivaji, ze pouzivaji certifikaty na bazi eliptickych krivek a i pouzite kryptograficke algoritmy jsou vcelku pricetne (diskutabilni je max. drzeni se CBC, ale preferovane to neni). A nepredpokladam, ze by "privatni" cast na tom byla nejak hure.
Díky.
Považoval jsem obskurní systémy za bezpečné.
Ale hezky jste to vysvětlil.
Pro někoho malého jako já se nic nemění.
Obskurní = bezpečné.
Ale pro důležitou a velkou společnost už tam je hodně nevýhod.
Popsal jste je hezky.
Další nevýhoda je lidský faktor.
Stačilo by uplatit jednoho člověka a celé by to bylo v pytli.
Za odkaz děkuji podruhé.
Security through obscurity opravdu neni neco, co by fungovalo. A kdo tvrdi opak bezpecnosti vubec nerozumi :)
No jak se to vezme.
Na interní záležitost, která není pokud možno vůbec dostupná s internetu, proč ne.
Ale proč ano, když ma to máme TLS a certifikáty (na interní systém můžou být klidně self-signed) a šifrovat tak můžu standardními prostředky, které se budou aktualizovat v případě odahlení nějakých chyb.
Pak vás nezaskočí, že něco lokálního se má třeba stát dostupným přes internet.
11. 12. 2025, 08:20 editováno autorem komentáře
No jen v praxi je to spis o opacnych extremech :-) IT brutalne podfinancovane a bezpecnost prakticky neresena. Bezpecnost se resi jen reaktivne - kdyz se stane prusvih, tak se hasi vznikle skody. Ale, to ze se "spokojene" provozuje leta derava aplikace nikomu zily netrha, dokud se nestane ten prusvih. Nulovym efektem neni to, ze vas neco bude nutit tu bezpecnost resit, kdyz jste na ni doted kaslal.
V tom odkazu se píše:
"If an attacker is able to reverse engineer"
Navíc musí být 'man in the midle' aby měl vůbec co reverzovat.
(Předpokládám že server nekomunikuje, než se záda správné heslo.)
Plat člověka/skupiny která je toho schopna převyšuje obrat mého HomeLabu.
Je jednodušší čekat až se objeví 0-dey slabina v nějakém rozšířeném nástroji a začít ji zkoušet na chudáky jako já, který aktualizují jednou za měsíc.
Zisk se násobí s počtem obětí.
Nechci se hádat.
Děkuji za cenné rady.
Uvítám další podněty.
Třeba jak nastavit push notifikace na CVE.
Protože bez toho je otázka času než dojde k prolomení zabezpečení.
No, koukám, že web Ministerstva kultury nám pod tou státní adresou "mk.gov.cz" ukazuje jen krásné "Tento web není dostupný. Webové stránky na adrese https://mk.gov.cz/ jsou možná dočasně nedostupné nebo mohly být přemístěny na novou webovou adresu.
ERR_SSL_KEY_USAGE_INCOMPATIBLE"
To ale není problém domény, ta je v pořádku. Stejně tak je v pořádku webový server na adrese www.mk.gov.cz. Rozbitá je ovšem konfigurace webového serveru pro variantu bez www, který po IPv6 vrací self-signed certifikát se špatným obsahem.
A www.mk.gov.cz je taky uz tak nejak "tradicne" bez IPv6... aneb asi si nekdo potreboval udelat carku (nejak mit v testu 100 bodiku) a moc neresil, jak to realne (ne)funguje... minimalne ne z dlouhodobeho pohledu.
Záměr asi dobrý, ale s ohledem na to, jaké s tím bývaly (a místy stále jsou) problémy, tak bych jim spíš doporučil, aby správu domény centralizovali u někoho, kdo tomu skutečně rozumí a ne to roztříštili napříč všemi podorganizacemi.
Oni na to možná, po pár trapasech, přijdou sami, a budou potichu, za drahý peníz, "outsourcovat".
Přál bych nám, aby to bylo funkční (včetně té IPV6) a dobře zabezpečené.
Budoucí "historie" ukáže.
Jake s tim jsou problemy? DNS fakt nemuze za to, ze si nekdo treba i po par tydnech rozbije nastaveni IPv6 na sve strane. Sprava fakticky centralizovana je - pod DIA a nastroj, ktery dnes urady maji jim jen umoznuje editaci vlastni zony - s tim, ze i vite kdo co presne rozbil, pokud jde o udaje v DNS. Jak si to "bezpecne" reseni predstavujete vy? ;-) I to MK je ukazkou toho, ze ani kontrola v case editace zony neni zarukou toho, ze po par tydnech nekdo nerozbije nastaveni zarizeni s DNS nikterak nesouvisejicimi.
Ano, muze se lepe prubezne testovat. Testy, ktere pouziva MPO ad vyse v zasade automatizovatelne jsou. A k tomu, aby se vedelo "komu napsat" se naopak soucasne reseni s registrem docela hodi, ne? :-)
RE: Jake s tim jsou problemy?
Jaké jsou problémy s nastavením DNS napříč státní správou, na to jsme tu na Rootovi naráželi nejednou. I v této diskuzi se několik problematických věcí řeší, takže moc nechápu, že se ptáte.
RE: Jak si to "bezpecne" reseni predstavujete vy?
Takové řešení, že ti, kteří to budou správcovat budou dobře vědět co dělají.
A to je složitější zajistit, pokud to bude:
- rozprostřeno mezi větší skupinu lidí s velmi variabilní úrovní technických znalostí
- lidi s horšími komunikačním vazbami mezi sebou
- lidi kteří takovou akci budou dělat velmi zřídka
Ale jak říkám, rád se nechám i pozitivně překvapit.
Ty problémy s nastavením DNS byly buď 1) chybnou konfigurací DNS serveru nebo infrastruktury – tu nyní provozuje CZ.NIC, takže tyhle problémy budou minimalizované (v ČR není moc subjektů, které by měli s provozem DNS takové zkušenosti, jako CZ.NIC). Nebo 2) chybnými hodnotami DNS záznamů nebo chybějícím DNS záznamy – to žádná centralizace nespraví, protože provozovatel domény gov.cz vždy jenom do domény nastaví to, co mu oprávněná osoba z příslušného úřadu řekne. Kontrolovat to třeba ani nemá jak. Ta decentralizace naopak umožňuje rychlejší řešení chyb – až se Ministerstvo kultury o té chybě dozví (jistě každý, kdo ji hlásil do diskuse, ji také oznámil Ministerstvu kultury), bude ji moci rychle samo opravit. A ne že bude posílat datovou zprávu s žádostí o změnu na DIA, kde někdo v úředních hodinách podatelny tu zprávu přepošle na příslušný odbor a ten v úředních hodinách zajistí úpravu DNS záznamu.
Pokud jde o kontrolu veřejných DNS záznamů, tu je možné dělat nezávisle na možnosti správy té domény.
Ostatně, celé to funguje stejně, jako v komerčním světě. CZ.NIC funguje jako registrátor domény a jednotlivé instituce jako její vlastníci. Když si vy „koupíte“ jakoukoli doménu, také považujete za normální, že její obsah můžete upravovat vy a ne jen registrátor.
Problemy s (technickym) nastavenim DNS soucasny system kolem gov.cz prave resi. Dnes nejen ze nemate oba DNS servery v jedne siti (nedejboze v jednom kamrdliku), bonusove je mate jako geograficky distribuovany anycast - coz z pohledu moznych utoku cini cely system naopak dosti robustni. Aneb ano, srovnavam drivejsi problemy s resenim, ktere je provozovane dnes. DNSSEC se resi instatne, centralne a automaticky a nastaveni je vcelku pricetne - a ne bastly, ktere tam dodal buhvikdo v zavislosti na uradu. Takze ano, ptam se vcelku relevantne, co vam na dnesnim technickem reseni gov.cz prijde "spatne"? A vypadato, ze vas nazor je spise z kategorie "otrok minulosti" - aniz byste podival, jakze to funguje dnes.
To, ze vam nekdo vlozi do DNS konkretni obsahove nesmyslny (technicky nefunkcni A, AAAA, MX... atp) zaznam sebegenialnejsi system nevyresi. A ani centralizace (obsahove) spravy zony nevyresi problem s tim, ze vlozeny zaznam prestane po nekolika mesicich fungovat tak jak ma - coz je presne ten pripad mk.gov.cz. Naopak vidim jako nesmysl, aby byl "centralni" urad, kteremu by vsichni posilali supliku kvuli kazde zmene... jen by to generovalo spoustu byrokracie okolo :)