Vlákno názorů k článku Návod: Bind 9 jako DNS resolver pro domácí síť nebo testovací prostředí od s6c - Popsaný návod je asi poplatný umístění souborů v...
-
Popsaný návod je asi poplatný umístění souborů v Ubuntu, takže při
použití jiných distribucí je to zřejmě třeba upravit.K souhlasu s výhradami Dana Ohnesorga ohledně volby "domácí" domény lze
jen dodat, že poměrně vhodnou TLD pro domácí použití může být např.
"localdomain.", která bývá použita ve vzorech /etc/hosts pro localhost a
u které nejspíš nehrozí, že by se stala jednou z nových genTLD (jedinou
nevýhodou je její délka, ale proti "uzanční" home.arpa - viz doporučení od
"M_D" - ne o moc a navíc formálně nezavádí dosti zbytečný 2. řád). Snad
by šla i "local.", ale používat např. "int." (takový návrh byl zaznamenán) je
zcela nevhodné, protože je kolizní (viz např. ecb.int).Když už domácí resolver, tak moc nechápu, proč forward na resolver
ISP nebo kohokoliv jiného, když lze resolvovat rovnou proti root-serverům
(jen se musí občas kontrolovat jejich množina v iana.org, což lze jednoduše
automatizovat). Dělám to tak už léta a funguje to. Na každém z několika
domácích PC primár poslouchající jen na localhostu. Při změně v localdomain
snadno zónové soubory rozkopíruji a reloaduji named a v /etc/resolv.conf
jako druhý je "pro jistotu" resolver na routeru s forwardem k ISP. Extra server
netřeba. Pro ne-UX systémy (MS-OS, resp. ty v patlafonech) to rodinným
příslušníkům resolvuje jen router přes ISP (má to v DHCP), ale tím se
nezabývám. Je to možná celé trochu svérázné a třeba ne moc bezpečné, ale
zatím nebyly žádné problémy a mně to vyhovuje. :-) -
Pridavam se k vyhrade, .local se skutecne pouzivat pro ucely popsane v clanku nema a soucasne se dneska uz casto pouziva pro to mDNS, protoze Apple zarizeni to masivne pouzivaji a navic to pouziva spousta krabicek zalozenych na ESP32 a podobnych IoT platformach.
.localdomain bych taky nepouzil, localhost a localhost.localdomain je na spouste mist zadratovane pro vlastni/interni interface daneho zarizeni. Nemuzu dolozit zadny priklad, ale verim, ze se najde situace kdy nejake zarizeni prelozi jmeno treba nas.localdomain na 127.0.0.1 a nebude fungovat.
-
Smím vdět, kd eje to .lan definováno, že je k tomu určeno? Ano, často se používá, ale třeba RFC6761 ji mezi specialitkami neuvádí. Že ji často používá WRT a dnsmasq je věc jiná.
I dle tohoto je zatím fáze hledání vhodného kandidáta: https://www.icann.org/en/system/files/files/sac-113-en.pdf -
Filip JirsákStříbrný podporovatelJá bych znovu upozornil na TLS certifikáty, které Dan zmiňoval. I když vymyslíte nějakou „domácí TLD“, která se zaručeně v příštích padesáti letech nestane globální TLD, nebo použijete nějakou „rezervovanou“ TLD – pořád se připravujete o možnost vystavovat na ty názvy důvěryhodné certifikáty.
Možná vám to teď nevadí. Ale jste si opravdu jistý, že vám to nebude vadit ani za pět, deset, dvacet let? Už nyní jsou některá API ve webových prohlížečích dostupná jen pro stránky nahrané přes HTTPS. Dá se předpokládat, že toho bude přibývat – a cílem, i když zatím vzdáleným, je nešifrované HTTP z prohlížečů úplně dostat pryč. Takže pokud bych DNS názvy do domácí sítě zaváděl teď, rozhodně to nebudu dělat způsobem, abych musel ty názvy zase za pár let měnit.
Když už domácí resolver, tak moc nechápu, proč forward na resolver
ISP nebo kohokoliv jiného, když lze resolvovat rovnou proti root-serverům
Kvůli rychlosti. DNS resolver vašeho ISP toho bude mít nakešovaného mnohem víc, než váš domácí DNS resolver. Takže vyřízení dotazů bude rychlejší. -
Tohle bych já osobně za problém nepovažoval - na "domácí" servery lze použít "domácí" ("privátní") certifikační autoritu a certifikáty si vydávat ve vlastní režii.
(Nicméně se přikláním k pořízení běžné domény a jejímu následnému použití jak "zvenku" pro webové prezentace či e-maily, tak pro "interní" potřebu.) -
Filip JirsákStříbrný podporovatel
Dělat si vlastní certifikační autoritu není něco, co by vám nezabralo vůbec žádný čas. Pak ji musíte instalovat do každého domácího zařízení – opět, někde je to jen práce navíc, některá zařízení se tomu brání (a budou čím dál víc), u některých zařízení to může být nadlidský úkol (třeba takové chytré televize). No a pak do toho vstupují třeba návštěvy, kterým budete chtít povolit třeba zobrazit fotky z jejich mobilu na vaší televizi. A instalovat vlastní certifikační autoritu návštěvám je myslím něco, čemu bych se chtěl vyhnout, i kdybych měl náladu vše předchozí absolvovat.
Nezapomeňte, že i na certifikační autority jsou kladeny stále větší nároky. Privátní jsou z toho (zatím a většinou) vyjmuté. Ale „zatím“ a „většinou“… Přidávat SAN do certifikátů se dalo vyřešit snadno (pokud měl někdo tu autoritu založenou na OpenSSL a ne na Windows AD). Ale jestli v budoucnosti bude požadavek na uvádění i certifikátů privátních autorit na Certificate Transparency list, nebo jestli budou muset podporovat OCSP, nejsou to úplně věci, které bych chtěl implementovat do své domácí certifikační autority.
-
Takže, pokud zavrhneme věci jako TLD .local, je pořád možné si zařídit vlastní doménu, pod nějakou vhodnou běžnou TLD, s krátkým jménem. A pokud si člověk připlatí i nějaký ten webhosting/mailserver (ano, to už je k tisícovce ročně) u providera s rozumnou politikou pro DNS, není problém na "prázdný hosting" nasměrovat potřebné "virtuální virtuální servery" a nechat si scriptem generovat certifikáty od LE. Ty pak lze "přehazovat" do vnitřní sítě a distribuovat na příslušná zařízení. A domácí DNS resolver na routeru může mít staticky přidané IP adresy oněch "serverů" na vnitřní síti,
Výsledkem bude, že "doma" vše funguje na lokálních IP adresách, s certifikáty od důvěryhodného vydavatele, "zvenku" skončíte na prázdné stránce, opět s platným certifikátem.
Jako bonus je tu prostor pro nějakou tu osobní prezentaci či předávání souborů, a e-mailová adresa s "rodinným jménem".
Jasně, není to řešení pro úplně neznalého "klikače", ale s trochou snahy se to udělat dá.
A jasně - klíče by se kopírovat neměly, když jsou tajné... Ale v rámci zjednodušení a pro tyhle domácí účely bych to s tou bezpečností protentokrát až tak nepřeháněl. Ostatně - i to se dá udělat solidně zabezpečené. -
Filip JirsákStříbrný podporovatel
Pro generování LE certifikátů nepotřebujete „virtuální virtuální servery“ a nějaké přehazování certifikátů. Doménové jméno můžete autorizovat přes DNS (ACME DNS-01 challenge), takže jediné, co musí být opravdu venku, je DNS server. Nebo-li stačí si zvolit poskytovatele DNS, který má rozumné API a se kterým si bude rozumět váš nástroj pro automatizované vydávání certifikátů. Dá se k tomu zneužít třeba Cloudflare, jeho API umí kde kdo.
Doufám, že za pár let tohle budou umět rovnou SOHO routery a jenom si to tam naklikáte. Třeba Turris by mohl jít příkladem.
-
Filip JirsákStříbrný podporovatel
R. R. Šimek: Nové věci musí nejprve vyzkoušet a odladit „někdo dobrej“, pak to mohou okopírovat ostatní :-)
-
Tak, nemusite to implementovat sam, staci pouzit existujucu. Napr dogtagpki, ma vsetko co by mal od nej clovek chciet. Pouziva ju napr freeipa.
Co sa tyka bezpecnosti takej privatnej CA - rozsirenie name constraints umoznuje definovat pre ake domeny je mozne CA certifikatom vydavat. A implementovane to ma uz aj dokonca osx. Takze mim sa nekona.
-
Filip JirsákStříbrný podporovatel
Co sa tyka bezpecnosti takej privatnej CA - rozsirenie name constraints umoznuje definovat pre ake domeny je mozne CA certifikatom vydavat.
Problém je, že množina lidí, kteří si name constraints zkontrolují, než si nainstalují certifikát nějaké certifikační autority, bude asi tak stejně velká, jako množina lidí, kteří to u své privátní certifikační autority nastaví. Po zaokrouhlení nula. -
Filip JirsákStříbrný podporovatel
To je hezká teoretická poučka, ale v praxi to samozřejmě musí řešit někdo povolanější. Takže prohlížeče při stahování spustitelného obsahu uživatele varuje, ve Windows pak před spuštěním OS kontroluje podpis programu. Na linuxu vám prohlížeč alespoň nenastaví
xbit. -
Njn, varuje. Ale ako ste sam pisal, tak ani ca certifikat nenainstalujete len tak.
Kedze vedsina binariek je v linuxe mimo repozitare distribuovana cez tar, tak si budte isty ze vam to eXecutable priznak nastavi, staci na to chrome, ktore akonahle zisti ze ide o archiv, tak sa pyta kam to ma rozbalit.
-
Nanestastie dogtag vyzaduje 389ds. Pokial ste bez LDAP, alebo pouzivate iny, nebodaj s uplne inou schemou (napr. AD/Samba, co bude trosinku viac pouzivane ako freeipa|, tak je dogtag nepouzitelny.
Stale zostavaju openssl, step-ca, alebo scep, podla narokov, alebo klientov co si maju provisionovat certifikaty.
-
1) ADCS je samostany service, Windows ho ma ako optional, Samba to nema (hovorim o Sambe v AD mode, ked to nie je jasne). Co som videl, tak pomerne dost instancii AD to nema rozchodene.
2) Napriklad taky blazon, co ma Synology a pouziva to v domacnosti alebo malej firme na centralnu spravu uctov. Ked sa tu riesi bind alebo postfix na domace ucely, co je zvlastne na Sambe?
3) Ja som nepisal ze dogtag je zavisly na freeipa. Ja som pisal ze dogtag je zavisly na 389ds. Z https://github.com/dogtagpki/pki/wiki/Architecture:
The Certificate System uses 389 Directory Server as its database for storing information such as certificates, requests, users, roles, ACLs, and other internal information. The Certificate System communicates with the internal LDAP database securely through SSL client authentication.
A ako to viem? Clovek sa dost nauci pri krieseni system, ked dogtagu expiruju certifikaty na to, aby sa dostal k svojmu vlastnemu store a vytvoril si nove (bol to virtualny lab, ktory bol vypnuty prave vtedy, ked by si ich zijuci system obnovil).
4) Naco freeipa, ked mam Sambu? 99% 3rd-party aplikacii vie spolupracovat s AD, ale nie s freeipa. Koniec-koncov aj Samba funguje s freeipa tak, ze ma samostatnu domenu a urobi medzi nimi trust.
FreeIPA som svojho casu prevadzkoval, v jednej malej firme. Ma niektore pekne veci, ktore AD nema (hba, sshfp by default, sudoers), ale na konci dna to bola zbytocna pakaren, integracia tretich stran nulova, clovek mal s tym len zbytocnu pracu. Este aj ten trust so Sambou bolo treba bejbysitovat, tak to islo prec.
-
1) njn, ved ani dogtag nie je sucastov freeipa, jaksi mi unika zmysel na co sa tym snazite poukazat.
2) tak takych sa vela nenajde, povedal by som ze dost ludi navstevujucich tento server, prevadzkuje sluzby ako openwrt (a klony), nejaky ten nas postaveny na linuxe, enigmu a tak podobne... btw, kolko stoji domaca licencia AD?
3) tak nie je to urcene len na take bastlenie si po veceroch. Ako by to podla vas malo byt ulozene, v plaintexte, vratane privatnych klucov? Ked uz taketo nieco prevadzkujete tak sa o to musite starat.
4) no vidite, ja pouzivam vacsinu aplikacii ktore su spolahlive prave koli tomu ze pouzivaju MIT kerbera a nie tu spatlaninu od malehomakkeho.
Moc nechapem co chcete povedat tym ze prakticky cela vasa siet je zavisla na widlach?
2. 2. 2022, 15:09 editováno autorem komentáře
-
1) Povodna myslienka bola, ze dogtag _vyzaduje_ na svoj beh LDAP server. A to nie hocijaky, ale konkretne a vylucne 389ds. Takze pokial uz nejaky iny LDAP mate, ci uz MS AD, Samba AD alebo OpenLDAP, tak dogtag s nim nepobezi. Inymi slovami, prevadzkovat dogtag, pokial uz neprevadzkujete 389ds je pomerne _neprakticke_. No a pokial ho uz prevadzkujete, tak na 99% je to s freeipou, kde je bundlovany, takze samostanu CA neriesite.
Odbocka: nepride vam zvlastne, ze prevadzkovat AD v malom povazujete za blaznovstvo, ale rozbiehat konkretny LDAP server pre jednu-jedinu aplikaciu je OK?
2) Napriklad spomenute Synology spadaju do kategorie "nejaky ten NAS postaveny na linuxe" a (tusim v modeloch + a vyssie) je tam klikatko, kde si AD domenu vytvori kazdy. Rovnako je to trivialne rozbehnut napr. v beznych distribuciach, staci nainstalovat prislusne balicky a domenu vytvorite pomocou "samba-tool domain provision".
Takze AD domenu mozete mat za rovnaku cenu ako freeipa: v intervale od 0 po kolko chcete minut.
3) No a tu mame opacny nazor. Kedze ale nechceme flamovat, ale byt konstruktivni, tak:
- je rozdiel medzi tym, co ukladam (obsah: ciphertext vs plaintext) a kam to ukladam (store: LDAP, subor, iny store). Aj do LDAP sa da ulozit plaintext a aj do suboru mozte ulozit ciphertext. Naprklad taky HashiCorp Vault uklada tajomstiev podstatne viac ako dogtag (vid dalsi bod), ale nema problem ani s textovym key/value storage. Teda nema problem so secret engines ako pluginmi celkovo, dokaze ich ulozit bezpecne hocikam, kde to pouzivatel potrebuje.
- PKI system nema co poznat privatne kluce. Privatny kluc ma byt znamy iba klientovi, ktory si ho vygeneroval, inak nie je privatny. PKI ma od zaujemcu o certifikat dostat iba CSR a v pripade kladneho vyhodnotenia odoslat naspat podpisany certifkat. Tym sa dostavame k tomu, ze jedine tajomstvo, ktore PKI ma, je privatny kluc CA. V idealnych podmienkach je tento HSM (v domacich podmienkach to tak povacsinou nebude, aj ked napr. yubikey by sa dal pouzit).
Naproti tomu spomenuty Vault uklada skutocne aj dalsie tajmostva, nielen jediny kluc.
4) Viete o tom, ze okrem MIT Kerbera existuje aj Heimdall? Tak nemusite predkladat falosnu dilemu o MIT vs Microsoft, ked tych moznosti je viac.
A podobne, v mojej sieti, aj ked je tam AD, su "widle" len klient. Neviem ako to este povedat, ale Samba nie je Windows a Samba je plne* pouzitelna implementacia AD.
[*] ano, Samba nema DFS-R a replikacia SysVol medzi domenovymi kontrolermi prebieha, no, nazvime to alternativne. Neriesme nieco, co ine adresarove sluzby vobec nemaju.
2. 2. 2022, 23:25 editováno autorem komentáře
-
Takze fajn, ja som rad ze nebudeme flejmovat ;)
Ja som v povodnom prispevku nepisal ze musi a jedina spravna cesta je dogtag. Pisal som ze je mozne pouzit napriklad dogtag.
Ak vam dogtag nevyhovuje ale ste odkazany na klon AD v synology tak, je to vas boj. Nemusite vsetkych presviedcat ze vase riesenie je jedine spravne a nevyhnutne dobre pre kazdeho.
-
Vsak ja som ziadne jedno riesenie nepresadzoval, citujem "zostavaju openssl, step-ca, alebo scep," (to su 3 riesenia, a to som vynechal vault)... a podotkol, ze dogtag nie je pouzitelny bez 398ds, co na 99,9999% ti, co nemaju freeipu nebudu mat nasadene a ti, co freeoipu pouzivaju uz dogtag maju.
"Klon AD v Synology" je uplne standardna Samba.
3. 2. 2022, 13:24 editováno autorem komentáře
-
Ale vy ste zobral moj prispevok ofenzivne, nevypadalo to tak ze predstavujete len dalsie mozne riesenie.
Tak si skuste tu vasu standartnu sambu pripojit k nadradenemu AD serveru. Podari sa nam to len vtedy ak autoritativny AD server bude len ta vasa "standartna" synology samba.
A uvedomte si jednu podstatnu vec, samba nie je nevyhnutnost.
-
Synology v starsich verziach naozaj nepodporovalo viac ako jeden DC. Ale to bolo v casoch, ked mali Sambu 4.4. Kde ty lansky casy jsou...
A to nic nehovori o clenstve. Clenstvo v AD bez ohladu na implementaciu podporovali uz vtedy, ked este nepodporovali AD rezim u seba.
3. 2. 2022, 15:13 editováno autorem komentáře
