Příspěvky

46

Server / Re:vlastna CA

« kdy: 10. 08. 2023, 14:26:45 »

Osobne vnimam ako jednu moznost, aby na intranete boli validne certifikaty i pre navstevy (nahodny clovek z ulice s android telefonom napriklad), vystavovat si certifikaty od lets encrypt-u na domenu ako napriklad chladnicka.mojaDomacnost.root.cz. Takyto certifikat by musel ziskavat verejne dostupny server s vhodnym SW a nasledne sa certifikat stiahne na domace NASko a nasadi do reverzneho proxy (predpokladam, ze chladnicka nebude podporovat nahranie certifikatu)...

Nevyhoda je, ze clovek musi vlastnit nejaku domenu a raz za cas (validnost certifikatov lets encrypt), musi mat moznost spristupnit do Internetu server pre vydanie certifikatu pre "domace" sub-domeny.

Moja otazka je, nakolko je toto pouzivane riesenie a ake vyhody/nevyhody poskytuje oproti dvom uz spomenutym.

Ano, musíte mít vlastní doménu. Do internetu žádný server pro vystavení certifikátů vystavovat nemusíte, stačí DNS. Let's Encrypt má možnost ověřovat vydání certifikátu přes DNS, takže tu veřejnou část zajistí DNS server – a ten máte typicky k dispozici od toho, kde jste doménu koupil (a nebo jsou DNS hostingy zdarma). Ideální je, když ty DNS záznamy můžete spravovat přes nějaké všeobecně známé API, abyste to nemusel dělat ručně, ale mohl nechat celý proces získávání certifikátů dělat automatizovaně.

Já pro tohle používám Caddy server, který umí hned v základu získávat a obnovovat certifikáty protokolem ACME (tedy např. od Let's Encrypt). Jediné, co jsem musel udělat, je změnit výchozí konfiguraci, že se certifikáty nevalidují přes HTTP ale přes DNS. Jedním z DNS providerů, se kterými už umí Caddy komunikovat, je Cloudflare. Takže doména je hostovaná (zdarma) na Cloudflare, vytvořil jsem k ní API key, ten jsem zadal do konfigurace Caddy a ten se stará o výměnu klíčů. Caddy běží jen ve vnitřní síti a slouží jako reverzní proxy ke všem HTTPS službám.

Za mne je to vlastně jediné použitelné řešení. DNS záznamy jsou všude stejné, tj. nestane se mi, že by třeba mobil byl na mobilní síti, kde by si nakešoval odpověď „DNS záznam neexistuje“, pak přešel do vnitřní sítě, kde se ten DNS záznam teoreticky přeloží, ale s mobilem budu muset čekat, než vyprší cache. Používá se normální všeobecně důvěryhodná certifikační autorita. Což je velká výhoda proti vlastním CA. Ono nacpat svou vlastní CA do desktopového systému je celkem jednoduché. Pak zjistíte, že Firefox má vlastní seznam důvěryhodných CA. Dostat do do mobilního OS je trošku složitější, ale jde to. Pak k vám přijde někdo na návštěvu, a jemu už asi vlastní CA do mobilu instalovat nebudete. A pak třeba začnete řešit vývoje, Node.js nebo Docker, a zjistíte, že v Node.js byste vlastní autoritu musel přidávat na několik míst, a cpát vlastní autoritu do Docker image běžícího v jiném Docker image už vůbec nechcete. Chápu, že někde vlastní CA ještě dobíhají, ale určitě bych teď nastavěl vlastní CA pro běžný provoz uživatelské sítě – tam už jedině ta varianta s ACME protokolem a DNS validací při vydání certifikátu.

47

Server / Re:Vlastní důvěryhodná CA

« kdy: 10. 08. 2023, 14:12:11 »

Neskusal niekto vyriesit ten problem doveryhodnosti nejakym kupenym/inak ziskanym "CA-like" certifikatom s platnou certifikacnou cestou?

Současný systém certifikačních autorit neumožňuje dávat žádná omezení na certifikační autority (technicky by to šlo, ale v tom systému to není implementované). Tj. kdybyste vaši certifikační autoritu dostal na úroveň ostatních certifikačních autorit, znamenalo by to, že všichni na celém světě budou té vaší certifikační autoritě důvěřovat, a to ať vydáte certifikát pro jakékoli jméno. Klidně byste mohl vydat certifikát pro google.com. Takže mezi ty důvěryhodné autority se dostane jen někdo, kdo prokáže, že má procesy i techniku nastavenou tak, že nevydá omylem (nebo jako důsledek útoku) certifikát někomu, komu by ho vydat neměl. Jenom dostat vaši certifikační autoritu technicky na takovou úroveň by bylo velmi drahé (rozhodně byste nemohl mít privátní klíče autority v souboru na disku, ale musely by být v certifikovaném HSM), drahý by byl i návrh procesů a jejich následná certifikace.

Mohlo by se zdát, že schůdnější cesta by byla nesnažit se dostat přímo na seznam důvěryhodných certifikačních autorit, ale aby certifikát vaší certifikační autority křížově podepsala jiná certifikační autorita. Tak, jak to měl třeba Let's Encrypt, nebo jako to používá třeba Google pro své certifikáty. Jenže ani v tomto případě to nebude lepší, protože certifikační autorita, která by vám certifikát vaší CA podepsala, nemůže nijak omezit, jaké certifikáty byste mohl vydávat. Ale měla by za vámi vydávané certifikáty plnou odpovědnost. Tedy by na vás měla stejně vysoké nároky, jaké jsou kladené na ni samou.

48

Odkladiště / Re:Domény, které vedou na „linky do aplikací“

« kdy: 26. 07. 2023, 11:51:38 »

Linky pro Android kdy mají aplikace zaregistrovaný vlastní schéma? To intent://app=nazev&action=něco je taky pro Android (googlujte co je intent v androidu). V podstatě to na Androidu otevře aplikaci...

To je vlastní schéma, to funguje ve všech systémech, ne jen v Androidu – je to způsob, jak se odkázat dovnitř aplikace.

Ale mikesznovu uváděl URL s klasickým schématem https na normálních existujících doménách (revolut.onelink.me a app.link). Vzhledem k tomu, že mikesznovu blokuje kde co, je možné, že se mu ty odkazy nezobrazují – to je jediné, co mne k takhle obecnému dotazu napadá.

49

Odkladiště / Re:Domény, které vedou na „linky do aplikací“

« kdy: 26. 07. 2023, 11:05:54 »

Co se vám na těch odkazech nelíbí? Co řešíte za problém?

50

Vývoj / Re:lxml xpath problém procházení strukturovaného menu [python]

« kdy: 25. 07. 2023, 23:07:42 »

Trochu mi uniká, proč jsou v XPath všechna lomítka zdvojena. To je v Pythonu nutné? Standarní XPath to nebere.

Dvojité lomítko je normální součást XPath a znamená to potomka v libovolné úrovni zanoření. Je to zkratka pro /descendant-or-self::node()/.

51

Vývoj / Re:lxml xpath problém procházení strukturovaného menu [python]

« kdy: 25. 07. 2023, 22:17:13 »

XPath výraz //li[not(@class="wnd-with-submenu")]/a vám vytáhne všechny elementy a, které jsou přímo uvnitř li, které nemá třídu wnd-with-submenu. Tj. tohle nahrazuje rekurzi, to vám vrátí odkazy rovnou ze všech úrovní. Z a získáte název a odkaz. Pak od každého nalezeného a použijete .//ancestor::ul[1], čímž se vrátíte k nejbližšímu nadřazenému ul a z něj získáte class, kde bude třeba to level-3 (což je předpokládám ta hloubka, kterou chcete).

Takže v tom Pythonu to bude vypadat zhruba takhle nějak:

Kód: [Vybrat]

links = menu_nav.xpath('.//li[not(@class="wnd-with-submenu")]/a')
for link links:
    ul = link.xpath(".//ancestor::ul[1]")
    print(link.text)
    print(link.get("href"))
    print(ul.get("class"))

Kód: [Vybrat]

li_obj = ul_obj[0].xpath('//li[parent::ul[@class="level-2"] and not(parent::ul[@class="level-3"])]/a')

Citovaný XPath výraz najde všechna a v elementech li, které mají jako rodiče ul s třídou level-2 a zároveň nemají jako rodiče ul s třídou level-3. Což je nesmysl, ta druhá podmínka je tam zbytečná – žádný li přímo uvnitř ul s třídou level-2 nemůže mít jako rodiče zároveň ul s třídou level-3. Tenhle výraz by vám tedy vybral jen všechna a v úrovni level-2, bez ohledu na to, zda tam je nebo není zanořená třetí úroveň.

52

Vývoj / Re:lxml xpath problém procházení strukturovaného menu [python]

« kdy: 25. 07. 2023, 20:07:23 »

Ukážu vám kousek z kódu jak jsem se to snažil řešit.

Ale já jsem se neptal jak se to snažíte řešit. Já jsem se ptal, co se snažíte řešit – co má být výstupem toho vašeho kódu.

53

Vývoj / Re:lxml xpath problém procházení strukturovaného menu [python]

« kdy: 25. 07. 2023, 19:38:28 »

Co tedy má být výstupem? Seznam všech listů menu? A jenom jejich názvy/odkazy, nebo i cesta k nim v menu? Pokud vám stačí jenom ty elementy s odkazy, pak to řeší XPath výraz ul//a a nepotřebujete žádnou rekurzivní funkci.

54

Desktop / Re:Chrome nechce uznat certifikat na jednej subdomene *

« kdy: 21. 07. 2023, 18:17:33 »

Řešení je zjistit, proč je ta stránka považovaná za škodlivou, a problém odstranit. Pokud se to v jedné instalaci Chrome děje a v druhé ne, zaměřil bych se na rozdíl v konfiguraci a rozšířeních. Jestli třeba nějaké rozšíření do té stránky nevkládá nějaký škodlivý skript.

55

Server / Re:WordPress htaccess imppanfree

« kdy: 19. 07. 2023, 11:15:57 »

Opravdu nevím, proč by to mělo být umožněno botům z celé jihovýchodní Asie včetně Číny.

Protože přístupové údaje stejně musí být tak silné, aby ničemu nevadilo, když to ti roboti budou zkoušet. A problém je, že vy nedokážete odfiltrovat jenom ty roboty.

Jak už jsem psal, IPv4 adres je čím dál větší nedostatek, tím pádem jsou dražší, více se s nimi obchoduje a to ve všech zónách, od legální zóny přes šedou po jednoznačně nesprávné převody. Takže se neustále zvyšuje pravděpodobnost, že tu IP adresu teoreticky z jihovýchodní Asie dostane klidně někdo z Turnova na svém domácím připojení.

To už mi přijde jednodušší upozornit zákazníky na skutečnost, že pokud chtějí upravovat cokoliv z administrace WP na cestách, je potřeba htaccess kvůli tomu upravit.

Ale co tou blokací získáte?

Jak už jsem psal, blokace IP rozsahů je dost humpolácké řešení – nerozlišuje, jestli je někdo padouch nebo hrdina, zablokuje všechny; a na druhou stranu pro aspoň trochu motivovaného útočníka není problém to obejít. Takže by se neměla používat jen tak, protože to jde a protože se vám chce.

56

Server / Re:Obnova certifikátu přes ACME.sh za proxy

« kdy: 18. 07. 2023, 18:09:24 »

Pro obnovu certifikátu ACME protokolem potřebujete prokázat vlastnictví domény. Buď přes HTTP (musíte na webové adrese, pro kterou certifikát získáváte, zveřejnit soubor s daným obsahem) – tj. potřebujete, aby se z internetu daný DNS záznam přeložil na nějaký webový server, na kterém bude vystavený alespoň ten jeden soubor. Nebo přes DNS – je potřeba do zóny příslušné domény vložit správný TXT záznam. (Ostatní metody se moc nepoužívají a mají stejné požadavky, jako HTTP metoda). Řešení s DNS je u interních webů méně invazivní – nemusíte řešit, aby se na internetu DNS název překládal na server zprostředkující ověření a ve vnitřní síti na adresu se skutečným webem.

Za mne je nejjednodušší řešení použít Caddy server – klidně jen v roli reverzního proxy serveru. Použití Let's Encrypt certifikátů obecně tam nakonfigurujete tak, že server prostě spustíte – Caddy má zabudovanou automatickou výměnu certifikátů přes Let's Encrypt a ta je ve výchozím nastavení zapnutá. Používá ale ve výchozím nastavení HTTP metodu, nicméně lze ho přepnout na použití DNS metody. Umí se napojit na API spousty poskytovatelů DNS služeb, takže jenom nakonfigurujete, že pro danou doménu se má používat DNS metoda, který DNS poskytovatel se má použít a přístupové údaje k poskytovateli, a o zbytek už se postará Caddy.

Konfigurace vydávání certifikátů v Caddy pak může vypadat třeba takhle:

Kód: [Vybrat]

{
  "module": "acme",
  "ca": "https://acme-v02.api.letsencrypt.org/directory",
  "email": "**********",
  "challenges": {
    "dns": {
      "provider": {
        "name": "cloudflare",
        "api_token": "**************************"
      }
    }
  }
}

(Je to JSON, protože mi připadá přehlednější a udržovatelnější. Caddy má ale možnost používat i svůj vlastní formát konfigurace, který je zjednodušený a kde by to nejspíš zabralo jeden či dva řádky.)

57

Server / Re:WordPress htaccess imppanfree

« kdy: 18. 07. 2023, 17:55:19 »

Otázka pro zkušenější. Jak moc je nutné mít v htaccess povolen k WordPressu  pouze IP tvůrce webu, případně pomocníka, který občas web upravuje?

Nutné to určitě není – měly byste se snažit udržovat WordPress v takovém stavu, aby ho nikdo napadnout nemohl. Druhá věc je, jestli je to vůbec možné – jestli dokážete oddělit administrační a návštěvnický prostor cest. A za třetí, jestli se nemýlím, zranitelnosti ve WordPressu i pluginech bývají i mimo administrační rozhraní – že je možné zneužít nějakou „běžnou“ cestu k získání vyšších práv nebo zkrátka k nepleše. Nebo-li je otázka, zda by takový zákaz k něčemu byl.

Také myslete na to, že možná běžně spravujete WordPress z jedné IP adresy, ale k nějakému průšvihu typicky dojde v okamžiku, kdy budete někde na dovolené apod. Zákon schválnosti říká, že u sebe budete mít třeba jen mobil, ze kterého byste zvládl udělat tu opravu ve WordPressu – ale dostat se do administrace webu a povolit si tam přístup z jiné IP adresy bude daleko složitější, než oprava toho původního problému.

A je dobrou cestou zakázat přístup vymezením, zákazem IP adres z jihovýchodní Asie a Ruska v případě, že webová stránka ve WP je pouze pro lokální maximálně české uživatele?

Není to dobrá cesta, protože nevíte, jestli se tam nebude chtít někdo podívat třeba z dovolené v jihovýchodní Asii, nebo jestli se třeba ty IP adresy nepřestěhují někam jinam.

Blokování na základě geolokalizace (nebo obecně větších rozsahů IP adres), zejména když je to služba určená pro veřejnost, bych používal jenom v extrémních případech (kdy není jiné řešení) a pokud možno jen po omezenou dobu.

58

Odkladiště / Re:Jak je těžké (najít) EHLO hostname pro útočníka

« kdy: 18. 07. 2023, 17:42:56 »

Může útočník nějak zjistit/uhádnout, jakým FQDN se regulerní odesílatel hlásí při odesílání pošty?

Kdyby útočník napadl nějakou domácí síť, bude ta mít třeba jeden člověk účet u GMailu a druhý na Seznamu, takže pro odesílání pošty vůbec nebudou využívat tu IP adresu, za kterou je schovaná domácí síť. jejich e-maily se budou odesílat ze serveru GMailu resp. Seznamu.

Ale pokud jste se chtěl zeptat, zda útočník může uhádnout, jaké jméno by mohlo být v HELO – ano, může. Pokud je to NAT za jednou IP adresou, zjistí si tuto IP adresu (např. se připojí na svůj server, který mu tu IP adresu prozradí, nebo se připojí na libovolnou službu, která prozrazuje veřejnou IP adresu klienta. Tuto IP adresu pak přeloží pomocí reverzního DNS (PTR záznamu) na odpovídající A záznam. Pokud má ISP nastavené vše dokonale, bude IP adresa mít reverzní záznam, k tomu reverznímu záznamu bude existovat dopředný záznam a ten povede (i) na původní IP adresu.

Problém pro útočníka může nastat, pokud ten NAT bude používat více IP adres a při prvotním zjišťování veřejné IP adresy se použije jedna IP adresa, při navázání SMTP spojení se použije jiná.

Ale útočníci rozesílající nevyžádanou poštu nejedou na spolehlivost nýbrž na množství. Prostě se to zkusí, a když to cílový server odmítne, nic se neděje – protože zároveň se o rozeslání spamu snaží stivky jiných zařízení, a některá z nich uspějí.

PTR záznam IP adresy taky nic neřeší, protože ta je třeba 82-2-2-4.cust.....provi...cz

No a proč by takový název nemohl použít v HELO?

59

Windows a jiné systémy / Re:Po připojení myši k macOS chce zmáčknout Shift

« kdy: 12. 07. 2023, 21:53:55 »

MacOS si myslí, že jste připojil klávesnici, a pokouší se detekovat, jak vypadá. Co je v tom průvodci za další volby? Není tam něco v tom smyslu, že jste nepřipojil klávesnici?

60

Software / Re:ssh nevytvoří spojení kvůli nezapisovatelnému /.ssh/

« kdy: 12. 07. 2023, 16:28:06 »

Ten disk je trvale nezapisovatelný? Pokud do něj jednorázově zapsat dokážete, bylo by nejjednodušší ten záznam do known_hosts přidat, ať se vás to pokaždé neptá. Když už tam bude, SSH tam nic dalšího zapisovat nebude.