Hlavní navigace

Názory k článku Hardening webového serveru Apache: šifrování a certifikáty

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 2. 2020 7:49

    Miroslav Šilhavý

    Pro vývoj bych doporučoval spíš interní certifikační autoritu. Zejména když projekt volá nějaké API, způsobuje to problémy. Když je nastavená interní CA, do systému se zavede jen její certifikát a všechny weby (projekty) pak už nevyžadují žádné další nastavení.

  • 10. 2. 2020 10:31

    Heron

    Další pěkný skript na kontrolu SSL je testssl.sh stáhnutelný z https://testssl­.sh. Mají to připravené i pro stažení přímo na cli, takže stačí wget -O testssl.sh https://testssl.sh. Je i v některých distrech a třeba ve FreeBSD je připraven port i včetně speciální verze OpenSSL obsahující všechny (tedy i zastaralé a nebezpečné) šifry, takže umí zkontrolovat i opravdu staré webservery a chyby.

  • 10. 2. 2020 13:51

    Filip Jirsák

    Asi by bylo lepší zabývat se v článku jen konfigurací Apache a nepouštět se do obecných a bohužel nesprávných tvrzení.

    Při konfiguraci SSL na straně serveru nezapomeňte zakázat protokoly SSL V2, V3 a TLS v1.0. Jinak budou uživatelská jména a hesla přenášena ve formátu prostého textu.
    Zmíněné verze protokolů se zakazují proto, že jsou známé útoky, přes které je možné šifrovanou komunikaci napadnout a v krajním případě dešifrovat její obsah. Ani u jednoho ale neplatí, že jsou jména a hesla přenášena v otevřeném tvaru.

    Poznámka: HTTP Strict Transport Security (HSTS) je bezpečnostní mechanismus, který chrání síťovou komunikaci mezi webovým prohlížečem a webovým serverem před downgrade útoky a zjednodušuje ochranu proti únosu spojení (tzv. cookie hijacking).
    S ochranou proti úniku spojení nemá HSTS nic společného. Je to prostě hlavička, která řekne prohlížeči „příště při komunikaci se mnou používej jen bezpečné HTTPS“. Nechrání tedy první komunikaci prohlížeče se serverem, a naopak klade i určité nároky na HTTPS – nepůjde přeskočit taková ta různá varování o expirovaném certifikátu. HSTS se samozřejmě nastavuje s nějakou platností – aby to dávalo smysl, musí být minimálně v měsících, Qualys SSL Labs vyžaduje pro stupeň A+ alespoň půl roku. Takže je potřeba mít vše dobře připravené, mít správně nastavenou infrastrukturu pro výměnu certifikátů, protože s HSTS zapomeňte na to, že v případě potřeby na server dáte nějaký „méně kvalitní“ certifikát a uživatelé holt odkliknou nějaké varování. S HSTS zkrátka není cesty zpět.

  • 10. 2. 2020 16:21

    bez přezdívky

    Tvrzeni o prenaseni hesel a dalsich dat v otevrenem tvaru pochazi primo od BSI a odkaz na zmineny dokument v clanku je. BSI je nemecka narodni bezpecnostni autorita (obdoba ceskeho NUKIB). Zkuste priste polemizovat s BSI.

  • 10. 2. 2020 19:21

    Filip Jirsák

    V článku je odkaz na stránku https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.html, kde je PDF soubor ke stažení, stažené PDF má 22 stránek a je nazvané „Technical Guideline TR-02102-2
    Cryptographic Mechanisms: Recommendations and Key Lengths; Part 2 – Use of Transport Layer Security (TLS)“. Tenhle dokument myslíte? Tam ovšem nic takového uvedeno není, ani nic vzdáleně podobného. Jediné místo, kde se tam hovoří o protokolech SSLv2 a SSLv3, je kapitola 3.2, dohromady je to 7 vět. To přečtete rychle.

    Myslel jsem si, že to v článku byla jen nešťastná formulace. Teď uvažuju o tom, zda by článek o konfiguraci HTTPS v Apachi měl psát někdo, kdo nemá ani základní představu, jak vypadá HTTP protokol, nebo jak se TLS a HTTP skládá do HTTPS. Je mi líto. Chybu může udělat každý, ale důležitá je také jistá sebereflexe – vědět, že se v tématu neorientujete, a když vás někdo upozorní na chybu, jít do toho původního dokumentu a tam zkusit najít něco, co vaše tvrzení dokládá. Buď byste měl v ruce něco, co přímo můžete citovat nebo odkázat, nebo byste alespoň relativně včas zjistil svůj omyl.

  • 11. 2. 2020 0:29

    bez přezdívky

    7 vet je opravdu malo na cteni, je treba cist ten dokument cely (otrava, ze?). Tak to ale v branzi chodi. BSI samozrejme neuvadi, co presne ma na mysli tim, ze rezim TLS v1.0 "bude prenaset data ve formatu prosteho textu". TLS v 1.0 je dosti zastaraly a byla zde prokazana rada moznych utoku, ktere vedou ke kompromitaci spojeni. Podobne otazky patri do vetve Cryptosession (ktera bude mozna na ROOT.CZ take vychazet).

    Kazdopadne, u TLS v 1.0 je mozny downgrade na rezim
    Cipher Suite: TLS_EMPTY_RENE­GOTIATION_INFO_SCSV (0x00ff),
    coz je ladici rezim, kde se zadne sifrovani nepouziva. Budete potrebovat "spolupraci" na strane serveru a tady pada podezreni na prislusne binarni knihovny. Neni to samozrejme jedina moznost kompromitace, popsanych utoku je cela rada.

    Mimochodem, binarni knihovny, podporujici rezim TLS_EMPTY_RENE­GOTIATION_INFO_SCSV (0x00ff) je mozne dolozit prakticky u vsech klientu s Androidem do verze 5.x (vcetne). U novejsich verzi Androidu to asi o moc slavnejsi nebude.

    TLS v1.1 a TLS v1.2 samozrejme rezim TLS_EMPTY_RENE­GOTIATION_INFO_SCSV (0x00ff) podporuji take, ale vynuceny downgrade (nedobrovolny) je zatim neproveditelny. Resp. zadna narodni bezpecnostni autorita tuto moznost nepotvrdila. I tak je TLS v1.1 oznacen BSI jako nedoporuceny a nema se jiz dale pouzivat.

  • 11. 2. 2020 8:25

    Filip Jirsák

    Bylo by férovější, kdybyste to napsal naplno, že v tom dokumentu nic takového není a že jste si to vymyslel. Ale OK, beru i tohle vaše zakamuflované přiznání. Ještě to chce opravit v článku, diskusi čte jen menšina lidí.

    Tu poznámku o čtení celého dokumentu jste si mohl odpustit – já jsem z toho dokument přečetl relevantní části pro tuhle diskusi, těch sedm vět byl odkaz pro vás, abyste to nemusel dlouho hledat. Zvlášť směšné je to tvrzení od vás – možná jste ten dokument četl celý, ale stejně jste ho nepochopil.

    To, že jsou ty protokoly slabé a je možné na ně zaútočit a získat část nebo celý obsah šifrované komunikace v otevřeném tvaru, je jasné – pro to jsou ty protokoly považované za zastaralé, málo bezpečné a silně se doporučuje je nepoužívat. Pořád je to ale něco úplně jiného, než že zrovna jména a hesla budou přenášena vždy v otevřeném tvaru (nebo-li že stačí poslouchat na síti a přihlašovací údaje odposlechnete).

    BSI samozrejme neuvadi, co presne ma na mysli tim, ze rezim TLS v1.0 "bude prenaset data ve formatu prosteho textu".
    Neuvádí. Navíc „přenášet data“ je něco úplně jiného, než „přenášet jména a hesla“. Jaké přesně jsou možné útoky na TLS 1.0 nemusí BSI uvádět, protože každý, o problematice něco ví, si to dokáže dohledat. Ale s výjimkou použití prázdné šifrovací funkce žádný útok nezpůsobí, že data budou přenášena v otevřeném tvaru. Bránit se použití TLS_EMPTY_RENE­GOTIATION_INFO_SCSV lze na straně serveru, takže zmiňovat to jako důvod vypnutí TLS 1.0 na serveru je špatně. U novějších protokolů také jen vypínáte slabé šifry a ne celé protokoly – moc protokolů by vám totiž nezbylo (záleží na nátuře, buď by vám zbylo TLS 1.3 nebo nic). Pokud se obáváte, že na serveru TLS_EMPTY_RENE­GOTIATION_INFO_SCSV vypnete ale knihovna to nebude respektovat a dál tu „šifru“ půjde používat, měl byste se úplně stejně být toho, že vypnete TLS 1.0 nebo SSLv3 ale knihovna to dál bude používat.

    Jinak protokoly TLS 1.0 a 1.1 nemají žádné známé neřešitelné problémy (na rozdíl od SSLv2 a SSLv3), nebo-li pokud se klient i server budou bránit známým útokům, např. BEAST, bude komunikace bezpečná. Což je důvod, proč se podpora těchto protokolů ukončuje až teď – je to spíš preventivní ukončení, protože víme, že ty protokoly jsou děravé a každý se děsí, kdy se tam objeví nějaká další díra, ale pokud se použijí správně, je možné je pořád ještě používat bezpečně. Druhá věc je, že bezpečnostní řešení, které potřebuje speciální konfiguraci, aby bylo bezpečné, není moc dobré, protože vždy hrozí, že se někde na něco zapomene.

  • 11. 2. 2020 10:29

    bez přezdívky

    Rozumim, Vy proste mate jiny nazor, a ten je nejlepsi. Sva tvrzeni nijak nedokladate, proste jsou platna a hotovo.
    Muzete napriklad uvest nejaky podklad pro tvrzeni " Pokud se obáváte, že na serveru TLS_EMPTY_RENE­GOTIATION_INFO_SCSV vypnete ale knihovna to nebude respektovat a dál tu „šifru“ půjde používat, měl byste se úplně stejně být toho, že vypnete TLS 1.0 nebo SSLv3 ale knihovna to dál bude používat."
    Tohle je totiz uplna hloupost a v mem textu nic podobneho neni. Vtip je v tom, ze TLS v1.0 umoznoval (za jistych okolnosti) downgrade na NULL cipher neboli TLS_EMPTY_RENE­GOTIATION.
    U TLS v1.1 a v1.2 to prokazano neni.

    Podobne je to i se zbytkem Vasich ostatnich tvrzeni.

    Muj clanek je o hardeningu te casti Apache, ktera se tyka sifrovaneho provozu. Konkretne se jedna o to, aby server "vynutil" na klientech prechod na https, kde budeme pouzivat pouze vybrane sifrove sady v ramci TLS v1.2. A jako podklad pro tento "implementacni scenar" jsem zvolil dopourceni BSI Technical Guideline TR-02102–2, kde jsem navic ocitoval i nektera jejich oduvodneni, proc nepouzivat SSLv2, SSLv3, TLSv1.0 a TLS v1.1.

    Mozna jste od clanku ocekaval neco jineho, ale to je jiz Vase zalezitost.

  • 11. 2. 2020 12:06

    Filip Jirsák

    Michal Vymazal: Ne, nejde o názor. Vy jste v článku uvedl chybné a nesmyslné tvrzení, že v protokolech SSLv2, SSLv3 a TLS 1.0 budou uživatelská jména. Po dotazu jste se odkazoval na dokument BSI, kde ovšem žádné takové tvrzení není. To jsem doložil.

    Proč je to tvrzení nesmyslné jsem nedoložil, ale když chcete… Je potřeba trochu znát, jak HTTP a TLS dohromady skládá HTTPS. TLS je univerzální šifrovaný tunel, kterým mohu procházet různé protokoly. HTTP (ve verzích 0.9 a 1.x) je textový protokol skládající se z hlaviček a těla. Uživatelská jména a hesla při přihlašování k webové stránce se přenášejí buď v hlavičkách (při použití HTTP autentizace) nebo (dnes u webů prakticky výhradně) v těle požadavku jako formulářová data. HTTPS je protokol HTTP tunelovaný skrze TLS spojení. To znamená, že TLS neví nic o tom, kde uvnitř je uživatelské jméno a heslo – to je záležitost HTTP protokolu. Pokud by tedy uvedené protokoly přenášely nešifrovaně uživatelské jméno a heslo, musely by přenášet nešifrovaně i vše okolo, nebo-li celý vnitřek komunikace. Jinými slovy, šifrovací protokoly SSLv2, SSLv3 a TLS 1.0 by od roku 1995 deset let vše přenášely nešifrovaně a nikdo by si toho nevšiml, až v roce 2006 by si toho konečně někdo všiml a malým updatem na TLS 1.1 by se najednou šifrování zprovoznilo. Ale nikomu by to nešifrování dál nevadilo a dalších víc než deset let by se v pohodě TLS 1.0 používalo.

    Samozřejmě, kdokoli si to přečte, a ví trochu o co jde, musí se smíchy válet po zemi. Bohužel je to jen ale rozepsání důsledků vašeho tvrzení v článku.

    Vtip je v tom, ze TLS v1.0 umoznoval (za jistych okolnosti) downgrade na NULL cipher neboli TLS_EMPTY_RENE­GOTIATION.
    Už to z vás pomalu leze a začínáte chápat, proč je to tvrzení v článku nesmyslné. Za prvé píšete „za jistých okolností“. Ano, samozřejmě, za jistých okolností – což je úplně něco jiného, než (implicitní) „vždy“, které je v článku. Přičemž ty jisté okolnosti jsou mimo jiné to, že to server musí podporovat. Takže pro obranu před tímto útokem stačí vypnout podporu nulové šifry na serveru, a nemusíte vypínat TLS 1.0.

    Dále nulová šifra samozřejmě znamená, že není šifrováno vůbec nic – takže by byla nešifrovaná celá komunikace, ne jen jméno a heslo.

    Shrnuto a podtrženo – v článku tvrdíte, že budou vždy přenášeny přihlašovací údaje nešifrovaně, přičemž chybně jsou obě tvrzení. Nebude to vždy, ale jen pokud útočník na komunikaci zaútočí a server takový útok umožní. A pokud už útočník takový útok provede, nebude se to týkat jen uživatelských jmen a hesel, ale nešifrované bude celá komunikace.

    Podobne je to i se zbytkem Vasich ostatnich tvrzeni.
    Ano, jsou logická, pravdivá a nesnažím se tvrdit, že je něco napsaného v textu, kde to napsané není.

    Muj clanek je o hardeningu te casti Apache, ktera se tyka sifrovaneho provozu.
    To jsem psal v prvním komentáři, že by v článku měla být popsána jen konfigurace Apache a neměl byste se pouštět do obecných úvah „proč to nakonfigurovat právě takhle“, když tomu (bohužel) nerozumíte.

    A jako podklad pro tento "implementacni scenar" jsem zvolil dopourceni BSI Technical Guideline TR-02102–2, kde jsem navic ocitoval i nektera jejich oduvodneni, proc nepouzivat SSLv2, SSLv3, TLSv1.0 a TLS v1.1.
    Neocitoval, vy jste si je vymyslel. Pro vaši informaci, citace vypadá tak, že je napsaná v uvozovkách, je u ní uvedeno, odkud se cituje tak, abych dokázal citaci v původním dokumentu najít. A v tom původním dokumentu najdu buď přesný text citace, nebo třeba bude lehce upravený slovosled, abych vytvořil samostatnou větu z něčeho, co se v původním textu váže na okolní text. Případně tam bude to samé v jiném jazyce. Takže pokud by ten váš výmysl s přihlašovacím jménem a heslem byl citací, musel bych být schopen v původním dokumentu najít slovo „password“ – ono tam je, jednou a v úplně jiném kontextu. Nevím, jak ještě víc byste chtěl dokázat tvrzení, že si vymýšlíte – za mne jako důkaz bohatě stačí už to, že jste třikrát napsal, že citujete z dokumentu BSI, přitom jste ani jednou nepoužil citaci (nevložil jste sem konkrétní text BSI), ani jednou jste neodkázal na konkrétní kapitolu dokumentu (na rozdíl od mne – a tvrdíte, že já svá tvrzení nedokazuju), dokonce ani na konkrétní stránku jste nebyl schopen odkázat.

    Důvod, proč nepoužívat TLS 1.0 a TLS 1.1 je ten, že jsou to z dnešního pohledu už slabé protokoly – mají známé díry, které je sice možné vhodnou konfigurací serveru a klienta zalepit, ale často si nemůžete být jistý, že druhá strana tu záplatu opravdu má. Což je zároveň důvod, proč už relativně dlouho platí, že se doporučuje tyhle protokoly opustit, ale k tomu, že přestanou být prohlížeči (ve výchozí konfiguraci) podporované dochází až letos. Jinými slovy platilo (a pořád platí), pokud máte dobrý důvod tyhle protokoly podporovat (např. musíte podporovat staré HTTPS klienty, kteří novější protokol neumí), nakonfigurujte je tak, aby byly bezpečné, a pak je můžete dál používat. Což je diametrálně odlišné od SSLv2 a SSLv3, které zabezpečit nejde – proto je k nim jednoznačný postoj „nepoužívat“, a pokud někde máte zařízení, které nic jiného neumí, je potřeba se k tomu chovat, jako by ten provoz byl nešifrovaný.

    Mozna jste od clanku ocekaval neco jineho, ale to je jiz Vase zalezitost.
    Očekával bych, že v článku nebudou zjevné nesmysly.

  • 11. 2. 2020 23:55

    bez přezdívky

    Skonceme to. Ja myslim, ze uz jste se vytrapil dost :-) Vtip je samozrejme v tom, ze TLS v1.0 je nachylny k tzv. "plain-text-attack". Jedna se o chybu v navrhu TLS v1.0 a tyka se modu s rezimem CBC. Plain-text-attack v BSI dokumentu zminen je a najdete jej nikoliv v textu, ale v tabulce.
    Problem jsem nechtel rozvijet proto, ze patri do oblasti serialu Cryptosession, ktery mozna bude na ROOT.CZ tez vychazet. Tam se muzete podobnymi dotazy opravdu vyradit.

    A pro priste - pokud necemu nerozumite, pak staci se normalne (a zdvorile) zeptat. Autor rad normalne (a zdvorile) odpovi. Staci obvykle dotaz typu "co jste vlastne myslel vetou typu ....".

    Jo, a dokumenty narodnich bezpecnostnich autorit pouzivame v branzi naprosto bezne. Ony totiz ty autority nejsou hloupe a dokazi zpracovat podnety od kohokoliv z verejnosti. Delaji to ve svem vlastnim zajmu a dokazi reagovat opravdu rychle - v radu hodin (kdyz uznaji za vhodne). Porovnejte s reakci spravcu ISO 27000 a mame jasno.

  • 12. 2. 2020 8:56

    Filip Jirsák

    Kdybyste nepsal do článku nesmysly a pak se v diskusi nevymlouval, tolik bychom se netrápili.

    O plain-text-attack psát nemusíte, ani o tom, že je zmíněný v dokumentu BSI. To všichni vědí. Co ale uniklo vám, je to, že to neznamená, že jsou přihlašovací jména a hesla protokoly SSLv2, SSLv3 a TLS 1.0 přenášena nešifrovaně. Resp. vám už to také došlo, akorát to nechcete naplno přiznat. Asi jste si uvědomil, že bych vám mohl předložit dump TLS 1.0 komunikace a chtít po vás, ať z něj ten login a heslo získáte – když je to podle vás nešifrované.

    A pro priste - pokud necemu nerozumite, pak staci se normalne (a zdvorile) zeptat. Autor rad normalne (a zdvorile) odpovi. Staci obvykle dotaz typu "co jste vlastne myslel vetou typu ....".
    Takže já se zde normálně a zdvořile zeptám: Proč píšete články o bezpečnosti, když na to nemáte? Sice znáte názvy jednotlivých protokolů, šifer nebo útoků, ale nedokážete to propojit dohromady.

    Tady je hlavní problém v tom, že jste do článku napsal nesmyslnou zkratku, a místo abyste to přiznal a opravil to, jenom se do toho dál zamotáváte a vymýšlíte si, že citujete dokumenty BSI.

    Můžete se jak chcete dál tvářit, že vy tomu rozumíte a já ne, bohužel jste ale před tím napsal nesmysl do článku, tady do diskuse jste několikrát napsal, že citujete BSI nebo že něco plyne z textu BSI, ale ani jednou jste z toho textu nic necitoval ani nic neodkázal. Každému soudnému člověku je už jenom z toho jasné, že si vymýšlíte – což byste neměl zapotřebí, pokud byste problematice alespoň trochu rozuměl. Já bezpečnosti moc nerozumím, bohužel se ukázalo, že vy jí rozumíte ještě méně.

    Jo, a dokumenty narodnich bezpecnostnich autorit pouzivame v branzi naprosto bezne.
    Tady mám také jeden normální a zdvořilý dotaz: Tohle je zbabělý pokus o argumentační faul, nebo opravdu stále nechápete, v čem je váš problém? Dokumenty BSI tu vůbec nikdo nezpochybňuje. Zpochybněna je vaše interpretace. Resp. kdokoli, kdo sleduje tuhle diskusi, kromě vás, už dávno ví, že byla vyvrácena – protože kdyby v těch dokumentech skutečně bylo to, co tvrdíte, už byste to dávno citoval nebo alespoň odkázal. Jenže tvrzení „přihlašovací jména a hesla jsou při použití protokolů SSLv2, SSLv3 nebo TLS 1.0 přenášena v otevřeném tvaru“ v těch dokumentech nikde není, a ani z těch dokumentů nijak neplyne. Je to čistě jen váš výmysl. Což je právě ten důvod, proč nemáte na to psát články o bezpečnosti.

    Neustále se snažíte zaštiťovat BSI, jenže to, co já rozporuju, jsou vaše výroky. Argument, že jen citujete BSI, už jste sám vyvrátil tím, že jste ani v několikátém komentáři nebyl schopen odkázat nebo citovat cokoli od BSI, co by váš výrok potvrzovalo.

  • 10. 2. 2020 14:00

    bez přezdívky

    Jak zabezpecit intranetovy server, jenz nevystupuje vubec na internet a tudiz nema ani nastavene dns jmeno public (tedy zadnou znamou verejnou domenu)? Se self certifikaty si nektere programy neporadi bohuzel ... a pokud jsem to spravne pochopil, tak pro lokalni domenu intranetu nemohu vystavit ssl certifikat u certifikacni autority (nema se jak overit). Ale spis tomu jen nerozumim a jde uplne vsechno :-)

  • 10. 2. 2020 14:31

    aigor.net

    Pro intranet používám vlastní CA jak tady už padlo v úvodu diskuse. Stačí importovat cert autority a vše se chová koretně. To stejné platí i pro přístup z mobilních telefonů. Na widlích se CA instalovat politikou.

  • 10. 2. 2020 16:12

    Miroslav Šilhavý

    Ale fuj. Přebíjet místním DNS záznam pro veřejnou doménu je cesta do pekel. Dřív nebo později bude někdo honit, proč aplikace nefunguje správně a zrovna rozdílnost DNS odpovědí nikoho nenapadne na první zamyšlení. Na problémy bude stačit jeden cestující uživatel, který si nastaví do laptopu DNS od Googlu a problém je na světě. Rozpadnutá VPN do práce - problém, aplikace si bude najednou tahat data z veřejné adresy a bude se divit, co dostává za odpovědi - namísto not resolved.

    Toto řešení prosím ne.

    Pokud nejde interní CA, tak aspoň self signed certifikáty.

    10. 2. 2020, 16:15 editováno autorem komentáře

  • 10. 2. 2020 19:27

    Filip Jirsák

    První dva odstavce vašeho komentáře škrtám, nejsou reakcí na můj komentář – popisoval jsem něco jiného.

    K poslední větě – nepoužívejte interní CA ani self-signed certifikáty, zaděláváte si tím akorát na problémy. A těch problémů bude čím dál víc. Prohlížeče logicky budou self-signed certifikáty odmítat, a s interní autoritou budete mít čím dál víc problémů dodržet pravidla, která prohlížeče budou vyžadovat. Navíc aplikací používajících HTTPS bude čím dál víc, z HTTPS se stává univerzální transportní protokol. A pak ty self-signed certifikáty nebo vlastní autority budete muset cpát do čím dál většího množství aplikací.

  • 11. 2. 2020 10:08

    Torquemada666

    Rada "nepoužívejte interní CA" je, pochopitelne, naprosta *****
    Jak by se asi obnovoval certifikat ze zabezpeceneho intranetu, ze?

  • 11. 2. 2020 10:26

    Filip Jirsák

    Rada „nepoužívejte interní CA“ je pochopitelně to nejlepší, co můžete udělat. Pokud ještě žádnou interní certifikační autoritu nemáte, tak už jí určitě nezakládejte. A pokud ji už máte, pomalu bych přemýšlel o její náhradě. Samozřejmě se to netýká velkých firem, kde na to mají tým lidí, který se tomu věnuje na plný úvazek – ale takoví lidé se na to nebudou ptát na rootu.

    Jak by se asi obnovoval certifikat ze zabezpeceneho intranetu, ze?
    Přesně tak, jak jsem popsal už včera. Klidně to zopakuju ještě jednou – pro ověření domény pro ACMEv2 stačí DNS, konkrétně je potřeba umět do DNS vložit správný TXT záznam. Nebo-li pro jména, která potřebujete ověřit, vystavíte na veřejném DNS serveru příslušné TXT záznamy – nemusíte tam zveřejňovat nic jiného, žádné A nebo AAAA záznamy. Tak se obnovují záznamy ze zabezpečeného intranetu.

  • 11. 2. 2020 15:53

    bez přezdívky

    Nepochopil jste otazku.
    Mam na intranetu server bez pristupu k internetu. Jak si na nem automaticky obnovim certifikat, az vyprsi?
    Nijak!

  • 11. 2. 2020 16:40

    Filip Jirsák

    Na intranetu, který nemá vůbec žádný přístup do internetu, nemusíte řešit ani obnovu certifikátu – nezajímá vás totiž přístup z webového prohlížeče z běžné pracovní stanice.

    Na intranetu, se kterým dokážete komunikovat alespoň z jednoho zařízení mimo intranet, použijete výše popsaný postup. Na zařízení vygenerujete žádost, vložíte z něj záznam do DNS, necháte provést validaci, stáhnete certifikát a pošlete ho do toho intranetu. Jediný přístup, který do intranetu potřebujete, je možnost nahrát tam obnovený certifikát.

    Možná jste si neuvědomil, že obnovu certifikátu nemusí zajišťovat zařízení, které certifikát bude používat, ale může ho zajistit jakékoli jiné zařízení.

  • 11. 2. 2020 16:15

    Miroslav Šilhavý

    Pokud ještě žádnou interní certifikační autoritu nemáte, tak už jí určitě nezakládejte. A pokud ji už máte, pomalu bych přemýšlel o její náhradě. Samozřejmě se to netýká velkých firem, kde na to mají tým lidí, který se tomu věnuje na plný úvazek – ale takoví lidé se na to nebudou ptát na rootu.

    Jde o to, jestli chcete používat lokální DNS názvy (např. .local). Tam má interní CA smysl. Přechod na veřejné názvy má taky smysl, ale zejména s IPv4 NAT je to složitější, o to víc práce je s nastavením a udržováním firewallu - to si nevyberete. Diskutujeme ale pod dotazem, který se týká právě situace s místním DNS názvem.

    Interní CA je lehlá všude, kde mají Windows Server, tam je certificate enrollment docela snadný. Certifikát CA se pak instaluje na stanice automaticky při přihlášení, takže tým nebude vůbec řešit, jestli povolování certifikátu pro intranetový server.

    Tam, kde je možnost přejít na veřejné názvy to je taky možné, ale zase se musí řešit buďto místní přebíjení DNS odpovědí (fuj praktika), nebo dvojitý nat, aby i zevnitř byly servery dostupné pod veřejnou IP adresou. Nebo v kombinaci s proxy serverem. To je podle mě větší pakárna a bezpečnostně složitější, než používat interní CA.

  • 11. 2. 2020 16:49

    Filip Jirsák

    Jde o to, jestli chcete používat lokální DNS názvy (např. .local).
    Ano, a moje odpověď je, že pokud byste interní názvy nebo autoritu teprve teď zaváděl, tak je používat nechcete.

    Diskutujeme ale pod dotazem, který se týká právě situace s místním DNS názvem.
    Ano, a moje doporučení je začít používat veřejný název. Spoustu věcí si tím dotyčný ulehčí.

    Interní CA je lehlá všude, kde mají Windows Server, tam je certificate enrollment docela snadný.
    Jasně, a snadné je tu autoritu správně nakonfigurovat, udržovat jí (některé tyhle interní autority dodnes nepoužívají SAN), v budoucnu jistě bude snadné dostat certifikáty vydávané touto autoritou na CT list. A stejně tak snadné je udržovat tu autoritu natolik bezpečnou, aby z ní nemohl nikdo vydat certifikát třeba pro google.com.

    Certifikát CA se pak instaluje na stanice automaticky při přihlášení, takže tým nebude vůbec řešit, jestli povolování certifikátu pro intranetový server.
    Do té doby, než někdo zjistí, že existuje třeba prohlížeč Firefox. Nebo další programy, které mají svá vlastní úložiště certifikátů. Ono naklikat něco ve Windows ještě neznamená, že to umíte spravovat.

    Tam, kde je možnost přejít na veřejné názvy to je taky možné, ale zase se musí řešit buďto místní přebíjení DNS odpovědí (fuj praktika), nebo dvojitý nat, aby i zevnitř byly servery dostupné pod veřejnou IP adresou. Nebo v kombinaci s proxy serverem. To je podle mě větší pakárna a bezpečnostně složitější, než používat interní CA.
    DNS split horizon ani dvojitý NAT nemusíte řešit, když použijete IPv6. Bezpečnostně složitější je rozhodně správně provozovat certifikační autoritu.

  • 11. 2. 2020 18:10

    Miroslav Šilhavý

    Do té doby, než někdo zjistí, že existuje třeba prohlížeč Firefox. Nebo další programy, které mají svá vlastní úložiště certifikátů.

    Však to je taky velká překážka, proč se FF nedostává do firem. Nezkoumal jsem, jaké důvody je k tomu vedly, ale je to dost podivné.

    DNS split horizon ani dvojitý NAT nemusíte řešit, když použijete IPv6. Bezpečnostně složitější je rozhodně správně provozovat certifikační autoritu.

    IPv6 je zatím utopie. I ty vyvíjené aplikace musíte testovat pro IPv4. To bohužel dnes není řešení.

  • 11. 2. 2020 18:22

    Filip Jirsák

    Nezkoumal jsem, jaké důvody je k tomu vedly, ale je to dost podivné.
    To je jednoduché. V době, kdy Firefox vznikal, bylo systémové úložiště certifikátů na Windows, ale v Linuxu si to každá distribuce a každá aplikace řešila sama. No a když už si to musel Firefox vyřešit sám pro Linux, bylo nejjednodušší tu samou implementaci použít i pro Windows.

    IPv6 je zatím utopie. I ty vyvíjené aplikace musíte testovat pro IPv4. To bohužel dnes není řešení.
    Nevidím důvod, proč by se třeba webové aplikace musely testovat pro IPv4.

    Na tom je krásně vidět, jaké problémy nedostatek IPv4 adres přináší. Je jich málo, tak musíte používat NAT. Kvůli NATu zase musíte řešit DNS split horizon. To zase způsobuje problémy s vystavováním certifikátů. Jestli ono by nakonec nebylo jednodušší rozchodit v té síti IPv6… Na druhou stranu, takovéhle sítě už stejně split-horizon DNS mají, třeba jen proto, aby se zaměstnanci dostali na firemní web. Takže když už musíte v síti kvůli NATu páchat škody, snažil bych se je omezit na co nejmenší možnou oblast, tj. nejdál do DNS a dál už ne. Až pak konečně zprovozníte to IPv6, opravíte jen DNS a nemusíte sahat ještě na certifikáty a konfigurace a bůhvíco ještě.

  • 11. 2. 2020 18:35

    Miroslav Šilhavý

    Takže když už musíte v síti kvůli NATu páchat škody, snažil bych se je omezit na co nejmenší možnou oblast, tj. nejdál do DNS a dál už ne.

    Interním CA právě žádnou škodu síti nezpůsobíte.

    S tou IPv6 bych byl opatrný. Až se začne dostávat mezi širokou veřejnost, způsobí to ještě nejednu komplikaci. Za léta s IPv4 NAT si všichni zvykli, že zvenčí je interní zařízení neadresovatelné. Dnes se zase setkáváte často s IPv6 bastly, kde kdo Vám nepřidělí ani /56 prefix. Už jsem viděl i pokusy o spojovačky /126 apod. To myšlení se bude měnit, odhaduji, dalších 15 let.

  • 11. 2. 2020 20:31

    Filip Jirsák

    Interním CA právě žádnou škodu síti nezpůsobíte.
    Ale způsobíte. Naučíte uživatele, že mají bezmyšlenkovitě odklikávat varování o certifikátech. Vystavíte je nebezpečí vystavení falešných certifikátů pro nejrůznější adresy – státní instituce, banky, poskytovatele cloudových služeb… A zkomplikujete procesy tam, kde se někdo bude snažit dostat interní autoritu mezi důvěryhodné.

    Za léta s IPv4 NAT si všichni zvykli, že zvenčí je interní zařízení neadresovatelné.
    Vtipné je, že tuhle větu píšete po té, co jste psal o nejedné komplikaci. Jak se říká, člověk si zvykne i na šibenici, ale zrovna na tenhle zvyk – že musejí používat nejrůznější triky, aby se dostali ke svému zařízení – lidé zapomenou velice rychle. To je jako kdybyste argumentoval tím, že si lidé zvykli, že telefonní šňůra má maximálně metr a půl. Nezdá se, že by jim ten zvyk nějak bránil v adopci mobilních telefonů.

  • 11. 2. 2020 20:40

    Miroslav Šilhavý

    Naučíte uživatele, že mají bezmyšlenkovitě odklikávat varování o certifikátech.

    Když si vytvoříte interní CA, naimportujete její kořenový certifikát a právě nic vyskakovat nebude. Na rozdíl od self signed certifikátů, tuto operaci provedete jednou na počítači, a ne pro každý interní web zvlášť. Ve Windows sítích CA máte automaticky, stačí si vyžádat certifikát (a ano, SAN to podporuje).

  • 11. 2. 2020 22:34

    Miroslav Šilhavý

    @Filip Jirsák

    Tak nevím, CA na Windows Serveru je asi šest kliknutí. Povolit SAN jsou asi dva příkazy. V 16:49 jste psal něco o správné konfiguraci a složitosti a nemožnosti SAN, ale to prostě není pravda.

  • 12. 2. 2020 9:46

    Miroslav Šilhavý

    Ano, psal jste tam spoustu bludů, které podle mě vycházejí z toho, že vůbec nic nevíte Windows CA ve Windows doméně, o které jsem psal.

  • 12. 2. 2020 16:14

    Filip Jirsák

    Nemusím. Předinstalované seznamy důvěryhodných certifikačních autorit ve Firefoxu, v Linuxových distribucích, ve Windows, v Javě, v Docker obrazech i v dalších systémech jsou dostatečné, jediný problém dělají interní certifikační autority, jejichž certifikáty musíte na všechna tahle místa dostat/dostávat.

  • 12. 2. 2020 17:05

    Miroslav Šilhavý

    Předinstalované seznamy důvěryhodných certifikačních autorit ve ... jsou dostatečné, jediný problém dělají interní certifikační autority, jejichž certifikáty musíte na všechna tahle místa dostat/dostávat.

    Nevím, přijdete mi odtržený od praxe. Seznamy důvěryhodných CA se mění, přibývají a odstraňují se. To, co píšete, platí v době instalace, případně u systému, který je aktualizován (aktualizovatelný). V praxi ale honíte odzkoušený docker, starou verzi Javy, často i starý Firefox, kvůli požadavkům prostředí. Takže se stejně práci s úložištěm nevyhnete.

    To, co navrhujete, bych se asi snažil zavést v novém prostředí, ale v pravdě, nepotkal jsem za svoji praxi prostředí, kde by mohlo být vše ideální. Proto se volí kompromisy mezi bezpečností, aktualizacemi, testováním a během.

  • 12. 2. 2020 17:48

    Filip Jirsák

    V praxi jsem u žádných aplikací, které jsem vyjmenoval, nenarazil na problém se seznamem důvěryhodných CA – s jedinou výjimkou, a tou byla právě interní CA. Doménové jméno, se kterým byly největší problémy, jsem nechal převést do veřejné domény, validujeme ho pomocí DNS a od té doby nebyl s certifikáty žádný problém. Teda občas v nevýchozím prohlížeči odklikám ta varování u interních webů, ale co, to jsou přece jenom systémy, které firma ani nechce vystavit do internetu, tak je potřeba jejich uživatele naučit, že bezpečnost nemají řešit a mají vše odkliknout… (Bazinga!)

    Tolik příklad z praxe. Že to nesedí na vaši teorii, s tím nic neudělám.

  • 12. 2. 2020 18:15

    Miroslav Šilhavý

    To je asi věc názoru, jak se tyto situace mají řešit. Považuji za menší zlo vyřešit interní CA (kterou potřebuji obvykle na víc věcí, než jen na certifikát k intranetu!), než řešit DNS split horizon nebo dvojnat.

  • 12. 2. 2020 19:14

    Filip Jirsák

    Já bych řekl, že si nejprve musíte ujasnit, co vlastně chcete. DNS split horizon nebo dvojitý NAT potřebujete tehdy, pokud má být daná adresa dostupná jak z internetu, tak z intranetu. Jenže aby byla dostupná z internetu, musí mít veřejný DNS záznam. Pak ale zase nemáte problém na něj vystavit certifikát třeba od Let's Encrypt. A nebo ta adresa v současné chvíli je z nějaké lokální domény (což byl původní dotaz na začátku vlákna), pak je logicky dostupná jen z intranetu. Tudíž když ji změníte na veřejné DNS jméno, abyste na ni mohl vystavit uznávaný certifikát, nemusíte řešit žádný DNS split horizon nebo dvojitý NAT, protože vám pořád stačí, aby se ta adresa byla dostupná z intranetu. Do internetu stačí vystrčit jenom ten jeden validační TXT záznam (který vám ovšem v intranetu nijak nepřekáží). Takže jediný obrovský problém, který musíte vyřešit, je za 1) vystavíte A záznam pro tu doménu do internetu, takže kdo bude to jméno znát a přeloží si ho, dostane IP adresu z privátního rozsahu, z čehož by se někdo třeba mohl opupínkovat. Nebo za 2) ten A záznam vystavíte jen do intranetu, na internetu se překládat nebude, tj. DNS server bude vracet NXDOMAIN. Technicky je to sice split horizon, ale možné škody jsou minimální. A nebo můžete zvolit variantu 3), která je sice na palici (protože ke každému hloupému pravidlu existuje způsob, jak ho obejít se zachováním všech pravidel a napácháním mnohem větších škod), ale nejspíš neporušuje žádné RFC – do veřejného DNS dáte pro to jméno CNAME na vaši lokální doménu, která se vám v intranetu bude překládat správně, v internetu se nepřeloží vůbec a v jiných intranetech se třeba také na něco přeloží, o to větší zábava to bude.

  • 12. 2. 2020 20:35

    Miroslav Šilhavý

    A záznam vystavíte jen do intranetu, na internetu se překládat nebude, tj. DNS server bude vracet NXDOMAIN. Technicky je to sice split horizon, ale možné škody jsou minimální.

    Ano, já Vám rozumím od začátku, ale myslím si, že ty škody právě tak minimální nejsou. Jako příklady můžu uvést (budu se opakovat):

    1. cesťáci s notebooky; do firmy se připojují jen přes VPN - pak musíte pohlídat, že si budou žádat o DNS z VPN, nikoliv z internetu; dá se to řešit default gw do VPN, ale to má taky spoustu nevýhod
    2. ladění jakýchkoliv aplikací a problémů: programátoři i oprašovači IT si DNS split horizon nedokáží představit, takže při hledání problémů naleznou příčinu až strašně pozdě (zažil jsem několikrát)

    Proti tomu distribuce důvěryhodných kořenových certifikátů je snazší záležitost. Je to i přímočařejší řešení, podmíněné jedním jediným předpokladem: dostat certifikát CA do úložiště. Vaše řešení vyžaduje nastavení DNS, nastavení ACME DNS challenge (+proxy, pokud chcete filtrovat i provoz ven, protože LE ověřovací servery nemají pevně dané IP adresy). Když k tomu přičtete, že často interní CA potřebujete i pro jiné účely než jen pro intranet (např. klientské certifikáty) tak z toho vychází prostě lépe.

    Kdybych chtěl naopak využívat možnosti, jaké jsou, a jak by to mělo být, pak bych asi opravdu intranetu dal veřejné jméno, veřejnou adresu (klidně i IPv4 - sehnat se dají, IPv6 ještě snáz) a provoz zvenčí bych utnul na firewallu a v ACL na webserveru. Bohužel, dnes už většina adminu bere NAT a privátní rozsahy jako standard a ne jako my, co ji považujeme za obezličku (a asi oba pamatujeme, kdy bylo běžné mít veřejný IPv4 rozsah ve firmě).

  • 12. 2. 2020 20:43

    Filip Jirsák

    Miroslav Šilhavý: Pořád melete a melete, fakta vás nezajímají, komentáře ostatních ignorujete. Cesťáci s notebooky se snad k vaší intranetové doméně připojí i bez VPN? Nepřipojí. Prostě jen blábolíte.

  • 12. 2. 2020 22:57

    Miroslav Šilhavý

    Cesťáci s notebooky se snad k vaší intranetové doméně připojí i bez VPN? Nepřipojí.

    Nevynutíte, aby pro veřejnou doménu zasílali DNS požadavky na DNS ve VPN. Pokud se jedná o lokální doménu, tak do VPN požadavek spadne. Pokud o veřejnou, není to zajistitelné spolehlivě bez GW do VPN.

  • 13. 2. 2020 7:51

    Filip Jirsák

    Miroslav Šilhavý: Jasně, lokální router se dívá do paketu, zjistí, že je to DNS dotaz na lokální doménu, tak nahodí VPN, paket zaNATuje a pošle do VPN. Vidím, že už jste se rozhodl na seriózní diskusi rezignovat a jenom se bavíte tím, zda vymyslíte ještě větší nesmysl, než před tím.

  • 13. 2. 2020 0:38

    dw

    Mal by som k tomu par postrehov:

    Co sa tyka moznosti internou CA vygenerovat crt trebars pre google.com, na to je jednoduche riesenie. Staci aby ten CA certifikat obsahoval name contraint obmedzene na .local. Podpora klientov sice nie je sie zatupena na 100%, ale vacsina modernych prehladacov v tomto smere funguje tak ako ma. Teda az na safari, ale kto normalny to pouziva...

    Co sa tyka VPN, je idealne ak ma klient svoj certifikat, v tomto smere je interna CA neocenitelna. Co sa tyka sietovania okolo VPN je to na obsiahlu diskusiu, ale pre cloveka ktory vie ako to ma fungovat je nastavenie laptopu pre cestaka skor rutina.

    Co sa tyka verejnych nazvov... zvolime aj pre kazde zariadenie verejnu ip alebo budeme do verejnych DNS pchat ip adresy z lokalnych rozsahov? Odpoved je myslim jasna.

  • 13. 2. 2020 7:56

    Filip Jirsák

    Co sa tyka verejnych nazvov... zvolime aj pre kazde zariadenie verejnu ip alebo budeme do verejnych DNS pchat ip adresy z lokalnych rozsahov? Odpoved je myslim jasna.
    Odpověď byla hned v prvním komentáři, ale podrobněji jsem pak pro pana Šilhavého možnosti rozepsal včera v 19:14. Nemám problém ani s DNS split horizon, ani s privátními IP adresami, ani jedno ničemu neublíží. Druhá varianta je sice v rozporu s RFC, ale holt IPv4 adresy už dávno došly, takže se hledají způsoby, jak to obejít – běžně se používá NAT, což je mnohem větší zlo, než privátní IP adresy ve veřejném DNS.

  • 13. 2. 2020 8:34

    Miroslav Šilhavý

    @Filip Jirsák

    Vymýšlíte složité ptákoviny s různými nedomyšlenými dopady, navrhujete zasahovat do nastavení sítě - a to vše jen kvůli kvaziproblému s importem CA do úložiště. Fungovat to bude, ale je to prostě fuj řešení.

  • 13. 2. 2020 9:26

    Filip Jirsák

    Miroslav Šilhavý: Zase špatně, zase si vymýšlíte. O zasahování do nastavení sítě jsme nic nepsal. Nedomyšlené jsou vaše nápady, když si vymýšlíte ptákoviny, že se lokální DNS resolver vzdáleného uživatele bude rozhodovat na základě toho, jakou doménu má překládat, který server použije.

    Pokud máte jen pracovní stanice s Windows, kde se používá jen Edge nebo MSIE, problém s instalací CA opravdu není. Jenže v některých sítích se toho vyskytuje víc – mobilní telefony, linuxové a unixové servery, počítače a telefony hostů, různé serverové aplikace…

  • 14. 2. 2020 14:44

    dw

    běžně se používá NAT, což je mnohem větší zlo, než privátní IP adresy ve veřejném DNS

    Nat je naopak vynikajuca vec ak s tym vie clovek spravne pracovat. Preto mame aj lokalne rozsahy ip, ci uz je to 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 alebo fe80::/10.

    Lokalne adresy vo verejnom DNS. Hm, naco reverzne zaznamy, vsak. Pretoze pochybujem ze by sa niekomu z vonka podarilo zapisat do reverznej zony pre lokalne rozsahy...

    Je stastie ze rfc k tymto veciam pisu ludia ktory nie su zatazeny bludmi ;)

  • 14. 2. 2020 17:44

    Filip Jirsák

    Nat je naopak vynikajuca vec ak s tym vie clovek spravne pracovat.
    Sádra na ruce je taky vynikající věc, ale ještě lepší je nemít ruku vůbec zlomenou. NAT je totiž hlavně zbytečná věc – používá se v drtivé většině případů jenom jako způsob, jak obejít to, že je nedostatek IPv4 adres. Kdyby bylo dost IPv4 adres a NAT vůbec neexistoval, nic by se nestalo.

    Preto mame aj lokalne rozsahy ip, ci uz je to 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 alebo fe80::/10.
    Zaměňujete příčinu a následek. Nejprve tu byly privátní rozsahy, a teprve pak se (díky jejich existenci a kvůli nedostatku IPv4 adres) začal používat NAT. Účel privátních rozsahů byl původně úplně jiný.

    Lokalne adresy vo verejnom DNS. Hm, naco reverzne zaznamy, vsak.
    Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje. Ale vy asi znáte nějaký důvod, proč jsou u intranetového webu reverzní záznamy potřeba.

    Je stastie ze rfc k tymto veciam pisu ludia ktory nie su zatazeny bludmi ;)
    Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet. Fakt se toho nemusíte bát – to, že je každé zařízení připojené k Internetu routovatelné z libovolného jiného zařízení připojeného k Internetu, není nic nenormálního, nemusíte se bát o tom byť jen přemýšlet. Fungovalo to tak dříve a zase to tak fungovat bude, protože je to krásně jednoduché.

  • 17. 2. 2020 18:49

    dw

    NAT je totiž hlavně zbytečná věc
    Taci si precitat 2 odstavec z rfc1918 - motivation. Mimo ine je tam aj to ze pri niektorych sietach je ziaduce aby neboli pristupne z internetu. Ale kedze sem tam treba updatovat servre tak je naopak potreba aby s tejto siete do internetu pristup bol. Napada vas iny sposob ako dnat? Rad sa necham poucit. A nejake to podupavanie hysterickeho decka, ktore musi mat za kazdu cenu pravdu ma moc nezaujima.

    Nejprve tu byly privátní rozsahy, a teprve pak se (díky jejich existenci a kvůli nedostatku IPv4 adres) začal používat NAT
    Tym som si nie tak celkom isty. Aspom podla datumov vydania rfc1918 a rfc1631... podla toho to vyzera ze nat je cca o 2 roky starsi ako privatne rozsahy.

    Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje.
    Ak je vas jediny nastroj prehliadac, tak to by mnoho vasich domienok vysvetlovalo.

    Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet.
    Ja pamatam este BBSky. A prva klavesnica za ktorou som sedel bola terminal od PDP11 ;)

    17. 2. 2020, 18:52 editováno autorem komentáře

  • 17. 2. 2020 19:59

    dw

    Musim sa opravit: rfc1918 nahradzuje rfc1597, ktore ma rovnaky datum ako rfc1631... teda privatne rozsahy a nat su rovnako stare. Moja chyba. Ale to stale neznamena ze nat je zbytocny - umoznuje korektny pristup z privatneho rozsahu do rozsahu s unikatnimi IP.

  • 17. 2. 2020 20:53

    Filip Jirsák

    Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet.

    Mimo ine je tam aj to ze pri niektorych sietach je ziaduce aby neboli pristupne z internetu. Ale kedze sem tam treba updatovat servre tak je naopak potreba aby s tejto siete do internetu pristup bol. Napada vas iny sposob ako dnat? Rad sa necham poucit
    To, aby nebyly přístupné z internetu, řeší firewall, nikoli NAT. Privátní rozsahy jsou určené pro zařízení, která nepotřebují komunikovat přes internet, nebo kterým stačí vybrané služby. Máte to vtom RFC 1918 v sekci Motivation napsané – když už jste ji zmínil, mohl jste si ji přečíst. A způsob, jak to zajistit pro ta zařízení, která některé služby potřebují? Třeba tu aktualizaci? Proxy server. Opět je to napsané v tom RFC (akorát tam to nazývají application layer gateway). Žádný NAT k tomu nepotřebujete.

    Ak je vas jediny nastroj prehliadac, tak to by mnoho vasich domienok vysvetlovalo.
    Pokud si neumíte přečíst vlákno, ve kterém reagujete, vysvětluje to, proč je váš komentář tak hloupý.

    Ja pamatam este BBSky. A prva klavesnica za ktorou som sedel bola terminal od PDP11 ;)
    Škoda, že si nepamatujete také to, jak vypadal internet bez NATů a jaké se používaly technologie.

    Ale to stale neznamena ze nat je zbytocny - umoznuje korektny pristup z privatneho rozsahu do rozsahu s unikatnimi IP.
    Což je přesně to, k čemu původně privátní rozsahy nebyly určené.

    Navíc já jsem nepsal, že NAT je zbytečný sám o sobě, polemizoval jsem s tím, že NAT je skvělá věc. Napsal jsem, že prakticky jediná jeho funkce je obcházet problém – nedostatek IPv4 adres. Když nebude problém, nebude ani potřeba NATu. Jako s tou sádrou na ruce – když máte zlomenou ruku, je sádra dobrá věc, ale lepší je nemít ruku zlomenou.

  • 17. 2. 2020 22:31

    dw

    Proxy server.
    Proxy - to ale predpoklada ze obe strany ktore proxy obsluhuje maju implementovane SOCKS. Naproti tomu NAT funguje na transportnej vrstve. Viacmenej ak budete potrebovat pouzit aplikaciu alebo zariadenie ktore socks nepodporuju tak sa natu nevyhnete. Je nejaka vyhoda proxy oproti natu? Preco mat nieco co bezi na aplikacnej vrstve a nie na transpornej vrstve. Ostatne aj to je dovod preco nemaju routery proxy ale maju maskaradu vo firewalli.

    Pokud si neumíte přečíst vlákno, ve kterém reagujete, vysvětluje to, proč je váš komentář tak hloupý.
    Myslim ze postaci ak odcitujem to na co som reagoval: Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje. Ale vy asi znáte nějaký důvod, proč jsou u intranetového webu reverzní záznamy potřeba. Ak si vytvorite lokalny kontex, tak by bolo tak nejako divne aby som v nom zohladnoval globalne cele vlakno. Alebo mi nieco uslo a vo vlakne sa cely cas pisalo len o webe. Asi si ho precitam cele este raz, aby som sa uistil ci sa nemylim. Vam by som to odporucal rovnako, teda ak ste ochotny sa presvedcit ci sa memylite a uznat si to.

    Škoda, že si nepamatujete také to, jak vypadal internet bez NATů a jaké se používaly technologie.
    Vzdy ma potesi ak stretnem niekoho kto o mne vie viac nez ja sam :) Ja mam psychologiu ale len ako konicek, prax necham radsej odbornikom, i v pripade ze sa jedna o diskusiu.

    Což je přesně to, k čemu původně privátní rozsahy nebyly určené.
    Ano, povodne boli privatne rozsahy urcene pre privatne siete, ale ako si sa ukazalo ze aj tieto casto potrebuju pristup do globalnej siete.

    Napsal jsem, že prakticky jediná jeho funkce je obcházet problém – nedostatek IPv4 adres
    To iste by sa dalo tvrdit o proxy, tiez mu staci jedna verejna adresa, akurat ma nevyhodu ze nefunguje s hociakou aplikaciou.

    když máte zlomenou ruku, je sádra dobrá věc, ale lepší je nemít ruku zlomenou
    Ja pouzijem zavedenejsie prirovnanie: Zbytocne strielate kanonom na vrabce.

  • 18. 2. 2020 7:57

    Filip Jirsák

    Proxy - to ale predpoklada ze obe strany ktore proxy obsluhuje maju implementovane SOCKS.
    Nikoli. Předpokládá to, že klient umí nějakým způsobem komunikovat s proxy serverem. Vy jste psal o aktualizacích systému, ty se dnes obvykle stahují přes HTTPS, dříve případně přes FTP. Snad všichni HTTP i FTP klienti umějí komunikovat přes HTTP proxy.

    Naproti tomu NAT funguje na transportnej vrstve.
    Což nic neznamená. Některé protokoly například přenášejí v aplikačních datech IP adresu. V případě NATu se to musí nějak obcházet – použít variantu protokolu, která to nedělá, na NATu měnit až na úrovni aplikačního protokolu i tu přenášenou IP adresu apod. Pro vaši informaci, tu IP adresu přenáší i protokol FTP ve svém původně nejpoužívanějším aktivním módu. A protokol FTP se hojně používal mimo jiné právě pro stahování distribučních balíků. Samozřejmě, že stejný problém budete mít i s proxy serverem, jenom poukazuju na to, že NAT není bezproblémové řešení.

    Viacmenej ak budete potrebovat pouzit aplikaciu alebo zariadenie ktore socks nepodporuju tak sa natu nevyhnete.
    Vzhledem k tomu, že neznáte fakta, neměl byste se pouštět do unáhlených závěrů.

    Je nejaka vyhoda proxy oproti natu?
    Například ta, že na proxy serveru můžete mnohem lépe řídit provoz. Přístup přes proxy server může být autentizovaný, můžete na něm povolit přístup jen k určitému doménovému jménu. Třeba pro ty servery povolíte na proxy serveru jenom přístup k serverům s distribučními balíčky a nikam jinam. To s NATem neuděláte – NAT nevidí DNS názvy, jen IP adresy.

    Alebo mi nieco uslo a vo vlakne sa cely cas pisalo len o webe.
    Ono se celou dobu píše jenom o webu nejenom v tomto vlákně, ale v celé diskusi. Řekl bych, že to bude mít něco společného se slovy „webový server“, která jsou v nadpisu článku.

    Asi si ho precitam cele este raz, aby som sa uistil ci sa nemylim.
    Ano, to vám doporučuju. Ve zkratce – původní dotaz na začátku vlákna byl: „Mám server v intranetu, který nemá veřejné doménové jméno. Je možné pro něj nějak vystavit důvěryhodný certifikát?“ Mnou navržené řešení s reverzními DNS záznamy nijak nemanipuluje, tj. pokud měl ten server původně nastavený reverzní DNS záznam, bude úplně stejně fungovat i nadále. Jediná věc je ke zvážení – pro server nemusíte zachovávat původní intranetový název, můžete server na veřejný název přejmenovat (místo vytvoření přezdívky). V takovém případě je potřeba změnit i ten název, na který ukazuje reverzní DNS záznam. Záznam ale pořád zůstane v intranetové reverzní zóně.

    Ano, povodne boli privatne rozsahy urcene pre privatne siete, ale ako si sa ukazalo ze aj tieto casto potrebuju pristup do globalnej siete.
    Tak příště neargumentujte RFC, kde se píše to, co tvrdím já.

    To iste by sa dalo tvrdit o proxy
    Tvrdit by se to dalo, třeba vy byste to tvrdit mohl, ale není to pravda. Proxy servery se používaly a používají i tam, kde jsou jen veřejné IP adresy. Dají se použít např. pro řízení přístupu. Nebo můžete pomocí proxy serveru bezpečně zpřístupnit pomocí aktuálních verzí protokolu HTTPS nějaké bláznivé zařízení, které umí jen HTTP nebo HTTPS se SSLv3. A tak dále.

    akurat ma nevyhodu ze nefunguje s hociakou aplikaciou
    Vzhledem k tomu, jak se postupně víc a víc blížíme k Internet-over-HTTPS (mimo jiné a kvůli NATům), těch aplikací nepodporujících proxy servery je čím dál méně.

    Ja pouzijem zavedenejsie prirovnanie: Zbytocne strielate kanonom na vrabce.
    Myslíte, že nedostatek IPv4 adres je vrabec a NAT je kanón? Bylo by fajn, kdyby to tak bylo, a kdyby zavedení IPv6 bylo mnohem jednodušší řešení, než používat NAT. Bohužel si to ale spousta správců nemyslí.

  • 20. 2. 2020 19:34

    dw

    Ono se celou dobu píše jenom o webu nejenom v tomto vlákně, ale v celé diskusi. Řekl bych, že to bude mít něco společného se slovy „webový server“, která jsou v nadpisu článku.
    httpd server(laicky apache, pod touto hlavickou existuje mnoho dalsieho software) sice primarne komunikuje cez http protokol v1, ktory pouzival prvy browser vobez nazvany worldwideweb, skratene web, ale myslim ze my sme sa skor bavili v suvislosti s tls protokolom (certifikaty od le nemusi vyuzivat len http serrver ale mozete ich napr pouzit aj pre postfix). Naviac openssl pomocou ktoreho si ziskate certifikat serveru s httpd asi nebude komunikovat cez webovy protokol, ale je mozne ze sa len zase mylim...

    Vy jste psal o aktualizacích systému, ty se dnes obvykle stahují přes HTTPS, dříve případně přes FTP.
    Ak by bolo vsetko v rpm repozitari, a memusel pouzivat aj ine sluzby tak by bol moj pohlad rovnako ruzovy. Mne vsak nestaci holy server ktory je aktualny, rovnako potrebujem aj aktualne aplikacie ktore na tom servri bezia.

    Mnou navržené řešení s reverzními DNS záznamy nijak nemanipuluje, tj. pokud měl ten server původně nastavený reverzní DNS záznam, bude úplně stejně fungovat i nadále.
    Uz vidim ako napriklad automobilka aktualizuje klientov u vsetkych autorizovanych servisov tak aby boli vo formate ktory by sa pacil prave Vam. Pripadne napada vas nejaky jednoduchy sposob ako hromadne aktualizovat konfigy s domenovymi menani v rozsiahlej intranetovej sieti tak aby nebol naruseny chod celeho systemu?
    Naviac, mudrujete tu zbytocne o kope veci ale k jednej s namietok ste sa nevyjadril. Ak potrebujem aby klient bol voci serveru overeny certifikatom a nie len server oproti klientovi, tak bud si zaplatite drahy certifikat ktory vam umozni podpisovat klientske certifikaty alebo pouzijete privatnu CA.

    Myslíte, že nedostatek IPv4 adres je vrabec a NAT je kanón? Bylo by fajn, kdyby to tak bylo, a kdyby zavedení IPv6 bylo mnohem jednodušší řešení, než používat NAT. Bohužel si to ale spousta správců nemyslí.
    Verim ze mi nevkladate slova ktore som nepovatl do ust zamerne, dost by ma to rozladilo ;) Kedze ale predpokladam ze ste to len nepochopil tak vysvetlim: Tym kanonom na vrabce je pouzitie proxy tam kde proste staci nat.

    Vzhledem k tomu, jak se postupně víc a víc blížíme k Internet-over-HTTPS (mimo jiné a kvůli NATům), těch aplikací nepodporujících proxy servery je čím dál méně.
    Je zrejme ze NAT zatracujete koli tomu ze vobec nechapte ako funguje, NAT samotny vam neodoprie sa pripojit na akykolvek port serveru ktori lezi vonku, toto uzivatelom zakazete len pomocou firewallu alebo pomocou prave proxy. Cize internetu over https skor mozete podakovat spravcom, ktory to dalej ako na spravcu nedotiahli a maju z dovodu komplexu menejcennosti potrebu nastavovat nezmyselne pravidla na proxy. Nat je v tom uplne nevinne...

    Tak příště neargumentujte RFC, kde se píše to, co tvrdím já.
    Tak si to rfc skuste precitat este raz, je v nom konstatovane ze niektore velke firmy pouzivaju brany na aplikacnej vrstve a nasleduje doporucenie k tomuto prikladu. Pripadne mozete mi poslat link? Myslim ze napisat fragment url adresy nebude pre vas problem napisat tak aby odkazoval na odstavec kde je vymedzeny vyhradne sposob komunikacie internej a externej siete na proxy a kde je odmitane ine riesenie, napr nat.

    Vzhledem k tomu, že neznáte fakta, neměl byste se pouštět do unáhlených závěrů.
    To ste adresoval sebe? Pretoze asi tazko poznate fakt ci niekto potrebuje pouzivat aplikaciu ktora nepodporuje socks. Inak by ste s tymto zaverom pockal az bude zrejme ze nikto taku aplikaciu nepotrebuje.

  • 20. 2. 2020 21:28

    Filip Jirsák

    httpd server(laicky apache, pod touto hlavickou existuje mnoho dalsieho software) sice primarne komunikuje cez http protokol v1, ktory pouzival prvy browser vobez nazvany worldwideweb, skratene web, ale myslim ze my sme sa skor bavili v suvislosti s tls protokolom (certifikaty od le nemusi vyuzivat len http serrver ale mozete ich napr pouzit aj pre postfix). Naviac openssl pomocou ktoreho si ziskate certifikat serveru s httpd asi nebude komunikovat cez webovy protokol, ale je mozne ze sa len zase mylim...
    No, mýlíte se skoro ve všem, co jste v tomto odstavci napsal. Oficiální název toho serveru, pokud na něm trváte, je Apache HTTP Server. „Apache“ není žádný laický název, je to původní název toho serveru – původně existoval patch (tedy „a patch“) na předchozí webový server (jeho jméno z hlavy nevím, můžete si to vygooglit), proto byl následně server pojmenován Apache. To „mnoho dalšího software“ pod hlavičku Apache přibylo až mnohem později. Apache komunikuje protokoly HTTP 1.0 (myslím, že stále ještě zvládne i 0.9), HTTP 1.1 a HTTP 2.0, všechny verze umí v šifrované i nešifrované variantě (tedy HTTPS i HTTP). Protokoly HTTP a HTTPS podporují všechny webové prohlížeče a mnoho dalších nástrojů a programů. World Wide Web byl a je název sítě internetových stránek, první prohlížeč byl „pojmenován“ podle této sítě. Nebavili jsme se v souvislosti s TLS obecně – ještě jednou si přečtěte nadpis článku, případně celý článek – je jenom o HTTPS. Pro získání certifikátu z HTTPS serveru opravdu nepotřebujete OpenSSL. Dokonce žádný z běžně používaných prohlížečů OpenSSL nepoužívá, Firefox má vlastní SSL knihovnu, Google pro Chrome používá fork BoringSSL a Microsoft má také vlastní implementaci. Certifikát se nezískává žádným zvláštním protokolem – certifikát se přenáší na začátku TLS spojení. Takže když se bavíme o protokolu HTTPS, certifikát se přenese na začátku, když se ustavuje šifrovaný kanál (TLS) – konkrétně v TLS zprávě „server hello“, což je první zpráva, kterou posílá server (jako odpověď na „client hello“, kterou začíná TLS spojení).

    Ale i kdybychom se bavili o TLS obecně – SMTP server v intranetu asi nebude potřebovat vybavit důvěryhodným certifikátem. Nicméně i kdybyste měl v intranetu server, jiný než HTTPS a zároveň byste ho potřeboval vybavit důvěryhodným certifikátem – popisoval jsem několik variant, v jedné tomu serveru dáte veřejnou IPv4 adresu a pak normálně nastavíte reverzní záznam pro tuhle veřejnou IPv4 adresu, v jiných variantách zůstane serveru IPv4 adresa z privátního rozsahu, takže s reverzním DNS záznamem nemusíte dělat nic, pořád to bude fungovat stejně, jako předtím.

    Mne vsak nestaci holy server ktory je aktualny, rovnako potrebujem aj aktualne aplikacie ktore na tom servri bezia.
    Asi vás to překvapí, ale v distribučních repozitářích najdete spoustu aplikací. A i pokud tam tu vaši aplikaci nenajdete – můžu se zeptat, jakým protokolem ty jiné aplikace na váš server stahujete? Přes Gopher? (Pokud je tam nahráváte přes SFTP, není to komunikace navazovaná ze serverů ven, ale naopak na ty servery. A asi tam ten software nepotřebujete nahrávat přes internet, bude vám stačit přístup z intranetu.)

    Pripadne napada vas nejaky jednoduchy sposob ako hromadne aktualizovat konfigy s domenovymi menani v rozsiahlej intranetovej sieti tak aby nebol naruseny chod celeho systemu?
    Ano, napadá mne jeden způsob, jak nemuset distribuovat doménová jména pomocí konfiguračních souborů. Přesně z tohohle důvodu byl vymyšlen protokol DNS. Už je to nějaký ten pátek, co tenhle protokol existuje, docela se osvědčil a používá se dost často.

    Naviac, mudrujete tu zbytocne o kope veci ale k jednej s namietok ste sa nevyjadril.
    Ale kdepak, k námitkám jsem se vyjádřil. A pak jsem vám vysvětlil spoustu věcí, ve kterých plavete.

    Ak potrebujem aby klient bol voci serveru overeny certifikatom a nie len server oproti klientovi, tak bud si zaplatite drahy certifikat ktory vam umozni podpisovat klientske certifikaty alebo pouzijete privatnu CA.
    Klientskou autentizaci certifikátem jste sem teď poprvé zavlekl vy. Mimochodem, reálně se tahle autentizace používá čím dál méně, protože podpora v prohlížečích (zejména UX) není moc dobrá. Ale když ji budete chtít použít, nic vám v tom nebrání – narazili jsme tu totiž na další vaši neznalost, a totiž tu, že klientský autentizační certifikát nijak nesouvisí s tím serverovým. Takže serverový certifikát klidně můžete být důvěryhodný od Let's Encrypt, a klientské certifikáty použijete od vlastní certifikační autority.

    Je zrejme ze NAT zatracujete koli tomu ze vobec nechapte ako funguje
    To je od vás velmi odvážné tvrzení.

    Uz vidim ako napriklad automobilka aktualizuje klientov u vsetkych autorizovanych servisov tak aby boli vo formate ktory by sa pacil prave Vam.
    Vidím, že jste konečně pochopil, že píšete nesmysly, a raději jste se přiklonil na mou stranu. Ano, právě proto aby ta automobilka nemusela všem autorizovaným servisům nutit svou certifikační autoritu, použije raději důvěryhodný certifikát.

    NAT samotny vam neodoprie sa pripojit na akykolvek port serveru ktori lezi vonku
    Je vidět, že vaše představa i Internetu už je velmi omezená, deformovaná NATem. Víte, ona komunikace nemusí být navazovaná jenom z vnitřní sítě ven, ale i opačným směrem. A tam už je NAT docela překážkou. Samozřejmě, že když omezíte komunikaci jen na TCP/IP spojení navazované z vnitřní sítě do internetu na jednom standardním portu, vzniká otázka, proč používat různé protokoly – a tak právě vzniká ten Internet-over-HTTP.

    Tak si to rfc skuste precitat este raz, je v nom konstatovane ze niektore velke firmy pouzivaju brany na aplikacnej vrstve
    Ano, některé firmy používají proxy servery – což jsem tu já psal a vás to hrozně překvapilo. Opět jste potvrdil, že v RFC je psáno to samé, co tu tvrdím.

    Myslim ze napisat fragment url adresy nebude pre vas problem napisat tak aby odkazoval na odstavec kde je vymedzeny vyhradne sposob komunikacie internej a externej siete na proxy a kde je odmitane ine riesenie, napr nat.
    Teď jste tu část sám parafrázoval. A RFC 1918 jste jako první odkazoval vy – neměl jste si nejprve přečíst to, co jste odkazoval? NAT v tom RFC vysloveně odmítnutý není, ale ani se o něm nepíše. A je v rozporu s tím, co je popsané v motivaci. Konkrétně si přečtěte v kapitole 2 Motivace rozdělení do tří kategorií. První kategorie jsou sítě, ve kterých zařízení vůbec nepotřebují komunikovat s okolním světem. Druhá kategorie jsou sítě, kde zařízení potřebují komunikovat s omezeným množstvím služeb, a to lze zařídit (při použití privátních rozsahů IPv4 adres) pomocí proxy serverů, které ty vnější služby zpřístupní. A třetí kategorie jsou zařízení, která potřebují plný přístup do internetu – tato zařízení potřebují IP adresy, které jsou globálně nezaměnitelné. Tudíž nemohou používat IP adresy z privátních rozsahů, o kterých pojednává RFC 1918. Celé RFC je o tom, jak zařízení z různých kategorií zkombinovat do jedné sítě a jak tyto privátní IPv4 adresy používat. Všimněte si, že tam nikde není zmínka o NATu, a že se v celém RFC předpokládá to, že když máte zařízení z kategorie 3, přidělíte mu veřejnou IPv4 adresu, ne privátní. Takže žádný NAT nepotřebujete. Nebo-li je to přesně tak, jak jsem psal prve – NAT pro přístup z privátních IPv4 adres do internetu je zneužití těchto adres, je to v rozporu s RFC 1918, protože to předpokládá pro zařízení z kategorie 3 veřejné IPv4 adresy. Samozřejmě dnes je jiná doba a nezbývá, než tohle RFC porušovat. Ale je dobré si uvědomovat, že děláme něco špatně, a že je to jen méně špatné řešení – a ne z toho dělat bůhvíco dobrého, jak to děláte vy.

    To ste adresoval sebe?
    Ne, vám. Když porovnám vaše a svoje komentáře, ty vaše jsou znalostmi sítí někde tak na úrovni první třídy ZŠ, moje někde na úrovni maturanta. Chápu, že s vašimi znalostmi je obtížné to rozpoznat.

    Pretoze asi tazko poznate fakt ci niekto potrebuje pouzivat aplikaciu ktora nepodporuje socks
    Je hezké, že jste se v první třídě dozvěděl o protokolu SOCKS. Nicméně já už jsem vám vysvětloval, že existují i jiné a používanější protokoly pro komunikaci s proxy serverem. Vraťte se k mým předchozím komentářům a dostudujte si to. Ať postoupíte alespoň do druhé třídy.

    Mimochodem, protokol SOCKS nemusí být podporován přímo aplikací, může ho implementovat i socket knihovna. Dříve takové řešení nebylo úplně výjimečné. Ostatně proto se ten protokol jmenuje SOCKS, je to proxy pro sockety… Dalo by se to udělat i s HTTP proxy (která má omezenější možnosti, ale pro spoustu aplikací by to stačilo), ale to se nepoužívalo, alespoň ne tak často.

  • 21. 2. 2020 19:11

    dw

    No, mýlíte se skoro ve všem, co jste v tomto odstavci napsal. Oficiální název toho serveru, pokud na něm trváte, je Apache HTTP Server.
    httpd sa ten server nazyval aj pred tym ako vznikla nadacia apache.
    Ako funguje ssl handchaking mi vysvetlovat nemusite, zopar(teda skor vcelku dost) aplikacii s pouzitim socketov som uz programoval.
    Openssl mozete pouzit ak chcete ziskat certifikat serveru. Bez toho aby ste musel spustit browser.

    (Pokud je tam nahráváte přes SFTP, není to komunikace navazovaná ze serverů ven, ale naopak na ty servery. A asi tam ten software nepotřebujete nahrávat přes internet, bude vám stačit přístup z intranetu.
    Asi ste myslel SCP. SFTP a SCP su diametralne odlisne zalezitorti ;) Mozno viete ze ssh vam po prihlaseni nemusi spustit len shell, odporucal by som si prestudovat moznosti authorized_keys... napr. git proti gitolite na servri...

    Vidím, že jste konečně pochopil, že píšete nesmysly, a raději jste se přiklonil na mou stranu. Ano, právě proto aby ta automobilka nemusela všem autorizovaným servisům nutit svou certifikační autoritu, použije raději důvěryhodný certifikát.
    Preco by som sa v tejto oblasti ktora mi je znama z praxe mal priklanat k teoretikovi z iluzorneho vesmiru.

    Je vidět, že vaše představa i Internetu už je velmi omezená, deformovaná NATem. Víte, ona komunikace nemusí být navazovaná jenom z vnitřní sítě ven, ale i opačným směrem. A tam už je NAT docela překážkou. Samozřejmě, že když omezíte komunikaci jen na TCP/IP spojení navazované z vnitřní sítě do internetu na jednom standardním portu, vzniká otázka, proč používat různé protokoly – a tak právě vzniká ten Internet-over-HTTP.
    Dalsi dovod si mysliet ze danej problematike vobec nerozumiete. V pripade natu existuje okrem DNATu (maskarady) aj SNAT ktory Vam umozni namapovat vonkajsie porty do internej siete. Ale vcelku mi unika dovod preco by niekto umiestnoval server ktory ma byt pristupny verejne do intranetu. Asi zpackana aplikacia na ktoru je lepsie nesiahat na aktualnom servri, nie to ju sprevadzkovat na inom servri.

    Ne, vám. Když porovnám vaše a svoje komentáře, ty vaše jsou znalostmi sítí někde tak na úrovni první třídy ZŠ, moje někde na úrovni maturanta. Chápu, že s vašimi znalostmi je obtížné to rozpoznat.
    Nemlati Vase ego hlavou o veraje dveri ked sa nimi snazite prejst? ;)

    Je hezké, že jste se v první třídě dozvěděl o protokolu SOCKS. Nicméně já už jsem vám vysvětloval, že existují i jiné a používanější protokoly pro komunikaci s proxy serverem.
    A aky protokol chcete pouzit v pripade HTTPS ak nechcete podvrhovat certifikat? Ak nepouzivate ssl bump tak sa vam ta proxy prepne na transportnu vrstvu.

    21. 2. 2020, 19:12 editováno autorem komentáře

  • 21. 2. 2020 20:09

    Filip Jirsák

    Vy jste si dal svazácký závazek, že do každého svého komentáře propašujete alespoň pět nesmyslů?

    Apache se nikdy nenazýval „httpd“, od začátku se jmenuje Apache. httpd je jenom název binárky, protože se tak jmenoval i ten předchozí HTTP server, který Apache nahradil. Ve studiu pokračujte zde.

    Když jsem napsal SFTP, myslel jsem tím SFTP – a vy při vašich neznalostech máte předpokládat, že je to správně, a vygooglit si to. Tak byste se dozvěděl, že SFTP je protokol pro přenos souborů, který jako rozšíření protokolu SSH 2 nahradil starší protokol SCP. SCP má omezené možnosti a proto se dnes už doporučuje ho nepoužívat, místo něj se používá právě modernější SFTP. Samozřejmě je možné, že někteří „praktici“, kteří nejsou moc v obraze, ale myslí si o sobě bůhvíco, dál používají SCP. Ve studiu pokračujte zde.

    Už jsem vám několikrát psal, že vedle protokolu SOCKS existují i jiné protokoly pro komunikace s proxy serverem, například protokol HTTP. Ve studiu pokračujte zde.

    Ty hloupé pokusy o poučování si nechte, nemáte na to. Pokaždé, když se mě pokusíte opravit, napíšete jen další nesmysl. Ve studiu pokračujte zde.

    21. 2. 2020, 20:10 editováno autorem komentáře

  • 21. 2. 2020 20:43

    dw

    Apache se nikdy nenazýval „httpd“, od začátku se jmenuje Apache. httpd je jenom název binárky, protože se tak jmenoval i ten předchozí HTTP server, který Apache nahradil.
    httpd (http daemon) od apchahe neznamena ze sa ten server vola Apache, rovnako ako sa sqlserver nevola microsoft, i ked zvedsa najdete na webe spojenie microsoft sqlserver. Vsimnite si nazvy balickov http://mirror.hosting90.cz/apache/httpd/#binaries

    Když jsem napsal SFTP, myslel jsem tím SFTP
    V rychlosti som miesto SFTP cital FTPS. Moja chyba. Ale potesilo ze ste si uznal ze balicky nemusia byt distribuovane len cez http alebo ftp. I ked nepriamo, nie kazdy ma na to priznat chybu otvorene.

    Už jsem vám několikrát psal, že vedle protokolu SOCKS existují i jiné protokoly pro komunikace s proxy serverem, například protokol HTTP.
    To je sice pekne ale ako cez neho pretlacite dalsie protokoly, Pri https sice mozete podvrhovat certifikat, ale fizlovat uzivatelov v dnesnej dobe je dost negativna prax.

    Ty hloupé pokusy o poučování si nechte, nemáte na to. Pokaždé, když se mě pokusíte opravit, napíšete jen další nesmysl.
    Dunning - krugerov efekt poznam, mozno by ste mohol zacat tym ze by ste si na roote mohol najs aspom 10 prispevkov v ktorych uznavate ze sa mylite. Ak sa vam to nepodari tak by ste si mohol skusit odkazovany clanok precitat z trocha ineho uhla pohladu ;)

  • 21. 2. 2020 21:48

    Filip Jirsák

    Ten server se jmenuje Apache HTTP Server, dříve se nazýval jen Apache server nebo Apache. To HTTP se do názvu přidalo později, když pod Apache Software Foundation začal přibývat další software. Odkaz jsem vám dával. Že neumíte používat Google, to už jsem pochopil. Že pro vás bude problém i kliknout na odkaz, to jsem nečekal.

    S SFTP jste vyrobil další botu. Já jsem nikdy nepsal, že balíčky mohou být distribuované jen přes HTTP nebo FTP. Vy jste ovšem psal o stahování balíčků z internetu. Jenže protokolem SFTP nebudete balíčky stahovat (download) z internetu, ale budete je nahrávat (upload) z intranetu. Tím pádem nepotřebujete přístup toho serveru do internetu, což byl ten důvod, proč jste o tom začal psát. Takže svou chybu jsem neuznal, protože jsem žádnou chybu neudělal – popletl jste to opět vy.

    Jak skrze HTTP proxy protlačíte další protokoly byste snad i vy pochopil, kdybyste si rozklikl ten odkaz, který jsem vám dával. Když takhle budete tunelovat HTTPS, žádné podvrhování certifikátů se nekoná – to je zase jen váš další nesmysl. A můžete takhle samozřejmě tunelovat i jiné protokoly postavené nad TCP/IP, jinak bych vám nepsal, že je to univerzálně použitelný protokol pro aplikační proxy. Např. můžete HTTP proxy použít pro SSH protokol – HTTP proxy lze použít s OpenSSH klientem (s pomocí např. nc/ netcat a volby ProxyCommand), pod Windows to umí Putty i WinSCP.

    Pokud se mýlím, tak to uznám. Ale hlavně nepíšu o věcech, o kterých nic nevím – tím se docela eliminuje to, že bych psal nesmysly. Z čehož následně plyne, že těch omluv nemusí být mnoho. Nicméně tady jde o to, že snad všechny vaše komentáře v této diskusi obsahují nějaký nesmysl. Nějak jsem si nevšiml, že byste se za všechny ty nesmysly omluvil. Místo toho navršíte další nesmysly. Já jsem v této diskusi nenapsal nic, co by bylo špatně.

    21. 2. 2020, 21:52 editováno autorem komentáře

  • 10. 2. 2020 15:13

    Jiří Eischmann

    Asi by bylo dobré uvést, pro kterou distribuci ten návod je a že se můžou na jiných distribucích lišit, protože ty konfiguráky a příkazy, uvedené v článku, rozhodně univerzální nejsou.

  • 13. 2. 2020 0:47

    dw

    No ono sa to lisi len v umiestneni tych konfigurakov, vacsina distier ich ma v adresari /etc/httpd...

    Btw, vzdy ma zaujimalo preco ma debian (a zneho odvodene ubuntu) v tomto adresari (/etc/apache) len httpd server a nie v aj vsetky ostatne projekty od apache...

  • 11. 2. 2020 9:11

    rsaf

    Souhlasím s p. Jirsákem, že na opravdový "hardening" je tohle trošku málo. Článek měl mít spíše nadpis "Qualys A+ snadno a rychle".
    Co OCSP stapling, HPKP, DH klíče...?

    Na druhou stranu jako návod pro rychlé nastavení Apache bez hlubokého zkoumání to celkem stačí.

  • 11. 2. 2020 10:21

    Miroslav Šilhavý

    Od HPKP se spíš upouští. Hardening je zostřování bezpečnosti, nikoliv vyřešení bezpečnosti. Vnímám ten návod jen jako minimum. OSCP stapling spíš ulehčuje (zrychluje), názor na zavádění stapligu se různí. Např. pokud máte na firewallu serveru filtrování směrem ven, musíte řešit stapling přes proxy (na L3 se to povolit nedá), ...

    Z mého pohledu by to rámce, který si autor stanovil, hodilo ještě přidat zmínku o CAA záznamench, protože to opravdu souvisí s prací s certifikáty. Docela přínosný by byl i popis konfigurace za použití dvou serverových certifikátů v kombinaci RSA + EC a výběr vhodné kombinace ciphersuites. Dá se tím pak pokrývat podpora pro velkou řadu prohlížečů a přednostně využívat EC, které je početně jednodušší. RSA pak slouží jako doplněk pro některé prohlížeče, které si nedokáží vybrat z EC.