reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 [2] 3 4 ... 116
16
ACME je rozšiřitelný protokol, vy píšete jen o variantě ověřování http-01. Já tuhle metodu používám k ověření dvou certifikátů, u kterých nemám přístup do DNS. Ve všech ostatních případech používám dns-01. Nemyslím si, že by si měl web server nebo poštovní server sám zařizovat certifikát – jejich správce má vytvořit privátní klíč a vygenerovat žádost a na konci nanejvýš stáhnout nový certifikát. Ale samotné vystavení certifikátu má zařizovat někdo jiný.

Navazoval jsem na Vaši poznámku o lokaci .well-known, takže ano, mluvím jen o http-01.

V praxi právě o certifikáty žádají samotné servery. Touto cestou jde doba a toto usnadnění je nezakrývaným záměrem LE. Opět, v praxi, těžko tomu kdo platí (zákazník, management) vysvětlíte, proč chcete certifikát řešit se správcem a s jasnou hodinovou dotací, když má každý pocit, že to může být zadarmo a samo.

Myslím, že příliš mluvíte o tom, jak by to mělo být, ale málo vnímáte, jak to ve skutečnosti je.

17
To samé v bledě modrém je s validací přes HTTP – díky Bohu za .well-known adresář, konečně je jasné, k jaké cestě nemá mít přístup žádný CMS ani nic podobného a má být výhradně pod správou administrátora serveru. Teď ještě aby se všechny CA do tohoto adresáře co nejrychleji přesunuly.

Podívejte se, jak vypadají ACME klienti v praxi. Velká část z nich definuje .well-known jako globální alias na webserveru a pro všechny virtualweby do stejného místa. Bohužel, lidská lenost je nekonečná a i možná dobře zamýšlený záměr dostane vždy v praxi přes kalhoty.

Druhým případem, kdy naopak .well-known nedostačuje je situace, kdy HTTPS provoz ochytává perverzní proxy, ale ostatní porty předává dál - např. mailserveru. Pak musíte řešit buďto distribuci certifikátu na jiný stroj, nebo nějakými (dost nesymslnými a nesystematickými) pravidly umožnit, aby .well-known byl nastaven jen jako "try", a v případě neúspěchu naopak předán dál na další stroj (aby i on si mohl získat certifikát).

ACME zdaleka není tak růžové. Má i svá proti.

18
V čem přesně je rozdíl, jestli připustíte vystavení certifikátu od DigiCertu, Let's Encrypt, GlobalSign nebo Buypass?

V tom, že mi admin, s přístupem na proxy server nemůže nechat vygenerovat certifikát jen ověřením ACME. U jmenovaných to bude muset být minimálně jedna z osob uvedených jako kontakt v registru domén (což už si opět dokážu jednodušeji pohlídat).

19
Mícháte dohromady věci, které spolu nesouvisí – ACME protokol je jedna věc, DV certifikáty jiná, klidně můžete protokolem ACME vydávat EV certifikáty.

Mimochodem, ověření před vydáním DV certifikátů je velmi slabé, ovšem byl bych velmi opatrný v tom tvrdit, že ověření pro OV je silnější. Ověření zavoláním na vygooglený telefon jde možná hacknout snáz, než to ověření přes http-01.

Já zde hovořím o praxi, o současné situaci a o tom, jak firmy (i vlády) na ni musí reagovat. Proto v současnsti není ze všech hledisek rovnocenné, jestli připustím použití LE certifikátů, nebo od jiné autority. Každá z cest má jinak vysoký práh a jiné překážky, u kterých je potřeba vždy počítat, že je bude možné nějak překonat. Přesto budu volit to, co je "tady a dnes" z mého pohledu nejbezpečnější.

Přidávat další omezení do CAA je hezká věc, já bych raději ta omezení sděloval spoléhající se straně, protože tím se ošetří i chyba certifikační autority.

Z mého pohledu je to naivní představa. Stejně jako vysvětlovat seniorům, že na zájezd zdarma, nebo na "krátkou předváděcí akci s dlouhou neomezenou konzumací" je nikdo ve skutečnosti nepozve.

Obdobou jsou banky: sice si máte hlídat svoji kartu, údaje k ní a PIN, limity si můžete nastavovat podle potřeby on-line v bankovnictví. Přesto banky zaváděj stále složitější procesy pro ochranu zákazníka - 3D secure, dnes se chystá další velmi silné rozšíření. Taky by mohli říct, že by se o to měl starat držitel karty.

Stejně jako banky musí chránit karty svých zákazníků, i poskytovatelé obsahu mají daleko větší možnosti, jak z jednoho místa bezpečnost zvýšit. Souhlasím s tím, že lepší možnost má příjemce sám (stejně jako držitel karty). Tyto dvě cesty se ale nutně nevylučují.

20
Certifikát ACME protokolem nemusíte vůbec obnovovat ze zařízení, kde se pak bude používat. Proces, jakým se na cílovém zařízení dříve zacházelo s privátním klíčem a certifikátem, může zůstat úplně stejný.

To se netýká jen obnovy certifikátu, ale i jeho prvotního vydání. A netýká se to jen Let'S Encrypt, ale snad všech autorit vydávajících DV certifikáty – neznám autoritu, která by jako jeden ze způsobů ověření držení domény nepoužívala HTTP.

Pomocí CAA lze omezit issue jen na jednu vybranou certifikační autoritu. S ní už si lze, při síle jakou má vláda USA, nebo i Seznam, smluvně domluvit odlišné podmínky pro vydávání certifikátů. Tedy např. lze sesmluvnit, že CA nevydá DV certifikát, a že ověřovací procedura firmy pro OV a EV je odlišná od běžných veřejných podmínek. Tím si zajistíte poměrně solidní kontrolu nad certifikáty a můžete ji zanést i do bezpečnostních procedur organizace.

Oproti tomu LE má nevýhodu v tom, že žádnou jinou metodu, než DV neumožňuje, a pokud připustíte issue od LE, tak v tu chvíli musíte mít plně pod kontrolou všechny cesty ověření ACME. To může být složitější mimo jiné i díky tomu, že vůči vlastnímu zaměstnanci (v ČR) nemůžete uplatnit příliš vysokou míru odpovědnosti. Zaměstnanec udělá "chybu", která může stát hodně peněz, ale pokud tam není jasný úmysl (který se prokazuje opravdu složitě), tak ho v nejlepším případě na hodinu propustíte a budete se soudit o něco-málo-násobek jeho průměrné mzdy. Se sesmluvněnou CA, která poruší podmínky ve smlouvě, se můžete soudit neomezeně, nehledě na to, že CA bývají pojištěny.

Ale automatizaci a standardizaci vydávání certifikátů považuji za správnou a byl bych rád, kdyby na ACME přešly všechny autority (samozřejmě s přidáním dalších validačních metod,které jsou pro OV a EV potřeba, třeba fax…). To, že budete všechny autority žádat o validaci a o vydání certifikátu stejným způsobem, přece na bezpečnost nemá žádný negativní dopad.

Zde chybí, jak už jsem napsal, mechanismus, jak vyblokovat vydávání DV certifikátů. Dnes, pokud nemám 100% důvěru ve své zaměstnance, nebo v nastavení bezpečnosti, mohu to maximálně ovlivnit  tím, že omezím CAA na autoritu, která ACME nepodporuje. A to ještě stále musím důvěřovat adminovi s přístupem do DNS a všem mechanismům dynamických změn v DNS (že nepropustí CAA záznam apod.). Přesto ale zůstanou, ať už přímo otevřené, nebo potenciálně existentní, další kanály DV ověření.

U CAA záznamu, nebo v registru domén by možná jen stačilo mít možnost nastavit, jestli chci povolit pro své domény vydávání DV certifikátů, a celý problém, o kterém píšu, by odpadl.

21
Proč by neměla? Let's Encrypt má velkou výhodu v automatizaci svých služeb, takže není potřeba se o obnovení starat. Že to může být problém ukázal nedávný problém ve Spojených státech, kde přestali chodit úředníci na chvíli do práce a některé služby přestaly být dostupné, protože v kanceláři neseděla lidská síla, která je zodpovědná za hlídání platnosti certifkátů a jejich včasné ruční obnovování. Tohle je lepší nechat na stroji.

S tím bych s dovolením nesouhlasil. Na takovýchto serverech je běžná i inspekce provozu ven, takže i vyžvanění ACME protokolu musí projít skrz spoustu mechanismů (firewally, proxy, ...), a bez pochyb to bude vyžadovat práci, bez které by to dřív či později přestalo fungovat. Jaké je v takovém případě riziko, že přestane fungovat obnova jednou za cca dva měsíce vs. ruční obnova jednou za dva roky, bych si nedovolil bez podkladů posuzovat.

Co se týče případu USA, z hlediska bezpečnosti bylo vyústění naprosto v pořádku. Procesy byly nastaveny na to, že vyžadují lidskou kontrolu. Opět nelze bez podkladů (mj. bez bezpečnostního protokolu daného úřadu) od stolu vystřelit, že by bývalo bylo lepší používat LE. Ano, bylo by to lepší pro nepřetržitý běh webu. Ale bylo by to opravdu lepší ve všech ohledech, které administrativa řeší? Není např. proces obnovy certifikátu pevně svázán s nějakými bezpečnostními procedurami? Není např. před výročním datem vyhodnocováno, jaký typ certifikátu a issuer nejlépe odpovídá bezpečnostním ohledům úřadu? Zkuste si např. představit, že se přijde na nějakou bezpečnostní chybu v LE. Bude úřad schopný reagovat tak rychle, jak je požadováno? Nebo je vhodnější podepsat velkou smlouvu s externím partnerem, který ručí za hlídání některých oblastí bezpečnosti, mj. za reissue, pokud by to bylo potřeba? Nemají přístup k LE mechanismům i osoby, které jsou potenciálně nebezpečné pro USA? Pokud ano, bylo by nutné zvážit HPKP - v případě ohrožení USA potřebujete mít kontrolu jak i lidi od informací odříznout, tak i jak jim zaručené informace předat. Pokud se použije HPKP, jak často se bude měnit klíč? Pokud se bude měnit klíč, jak moc to bude (opět) závislé na zaměstnancích? (a jsme na začátku...?)

Nemám opravdu rád, když se bez bližších znalostí vypalují soudy typu: "vidíš, s LE by se to nestalo". To si možná může dovolit laik v diskusi, ale profesionál by měl vědět, že je potřeba aspoň nakouknout i za roh. Bezpečnost není téma jen o černém zámečku v prohlížeči.

V Seznamu očividně vyhodnotili, že pro jejich potřeby stačí LE, že nevyžadují ani OV, ani EV certifikát. To není jen politické rozhodnutí, ale i bezpečnostní. Pokud přejdete na LE, dáváte reissue mechanismus do ruky každému adminovi, který má přístup k toku http požadavku na dané doméně. To musíte pečlivě zvážit, jestli je dobrý nápad. Nebo, pokud chcete issue omezit, pak ACME zatrhnete na vstupní proxy a dál si musíte být jist, že se požadavek nepředá (co když tento filtr selže?). V případě tradičního certifkátu (kupovaného na delší období) omezíte issue pomocí CAA záznamu a interním mechanismem ověření vůči vybrané CA. Oba mechanismy mají administrativně svá pro i proti, oba mechanismy mohou být zneužity jinak a oba mají jiné silné stránky.

Technický ohled je až to poslední, co se v těchto případech zvažuje. Technicky je totiž (pokud vláda USA neví něco víc :)) šum a fuk, jestli je certifikát vystaven od LE, nebo od někoho jiného. LE už dávno nemá nálepku low cost řešení.

22
Běžně potřebujete mít tři prostředí:
1. Produkční.
2. Vývojové - tady programátoři dělají změny v databázi a testují je.

3. Předprodukční - obvykle se jedná o pravidelnou (třeba noční) kopii produkčního prostředí. Na ní se testují patche z vývojového prostředí a dá se otestovat i výkon na reálných datech. Máto to ale i svá úskalí. Např. v předprodukčním prostředí máte kopii ostré uživatelské databáze. Takže existuje riziko, že třeba odejdou e-maily registrovaným uživatelům. Proto se předprodukční prostředí řeši ještě navíc tak, že běží v kontextu jiného systémového uživatele, který nemá právo odesílat e-maily (vč. pravidla na firewallu). Obdobně musí být vyblokované funkce volání vzdálených API (např. platební brány, SMS brány, ...).

23
@Miroslav Šilhavý: To už mi zase přijde jako složité řešení, navíc, myslel jsem, že jste propagoval, aby se takové věci nedělaly uživatelem postgres na tož rootem.

To propaguji dál, ale vy jste položil jako podmínku, že script je rootem spuštěný. Tj. vyšší oprávnění už nejdou získat.

24
Mám na CentOS skript, který potřebuji spouštět rootem, ale zároveň tam jsou části skriptu, které potřebuji spouštět jiným uživatelem, ale navzájem ty části kódu na sebe musí vidět a umět spolu spolupracovat. Jedná se například o příkazy psql a pg_dump, se kterými root neumí pracovat a zároveň ho nechci vytvářet jako roli v postgresql databázi. příkazy bych raději spouštěl uživatelem, který je pro tento účel vytvořen.

Zde by mi přišlo asi nejjednodušší pouštět psql i pg_dump pod rootem. Na to nepotřebujete rootovi dávat roli do databáze. Stačí psql i pg_dump spustit s příkazem -U a uvést, pod jakou rolí se chcete přihlásit. Pak už je potřeba jen nastavit do pg_hba buďto trust, nebo lépe, zadat heslo do .pgpass.

Přehazovat to pomocí su / sudo je podle mě zbytečné, nepřinese to ani zblo bezpečí navíc.

25
Odkladiště / Re:Diskuze na wordpress šabloně
« kdy: 28. 02. 2019, 12:49:24 »
Takže v roce 2015 je to cca remíza. Rok 2016 měla nejméně zranitelností Joomla! a WP a Drupal cca remíza. Pro roky 2017-2018 máte pravdu, nejméně má Drupal a Joomla! a WP jsou na tom o poznání hůř. V následujících dvou letech se to může zase otočit. Každý CMS má své problémy a měnit ho každý rok podle počtu zranitelností nejde.

Podívejte se ještě taky v jakých rubrikách ta rizika jsou. Každý z těch systémů je má rozložené jinak a ne každé riziko se týká každého usecasu.

26
Odkladiště / Re:Diskuze na WordPress šabloně
« kdy: 28. 02. 2019, 08:29:47 »
My se o to právě starat chceme, ale ani nejsme schopni nikoho najít, kdo by nám pomohl. Moc vám všem děkuju za rady, nějak se s tím probereme a pokusíme se to odlatit. Díky.

Až někoho najdete, dejte mi vědět. Já zatím potkalna WP jen amatéry, zatímco profíci (aspoň trohcu kvalitní admini a programátoři) se wordpressem moc zabývat nechtějí.

Zvažte PLESK panel, ten má určité automatizované nástroje, které nekteré zranitelnosti proaktivně mitigují.

27
Odkladiště / Re:Diskuze na WordPress šabloně
« kdy: 27. 02. 2019, 20:25:02 »
Pak je druha vec a to jsou ty XSS a SQLi utoky. Tam lze poradit par veci:
- pravidelne aktualizovat
- idealne mit sveho freelancera, ktery tomu systemu rozumi
- nestahovat placene pluginy "zadaco" - vetsinou to nekdo koupi, "poleci", prida svuj skodlivy kod a hodi na site. tupci si myslej jak vydrbali s puvodnim autorem.

S těmito tvrzeními souhlasím absolutně.
Bohužel, moje zkušenost je, že Wordpress se používá spíš stylem: máme nabídku od šikovného (studenta), který nám udělá ze sexy šablony web za pár korun a budeme si ho moct sami editovat.

Na to, aby se správně vybraly komponenty, zabezpečilo se to, a aby se o to někdo pravidelně staral, na to už se nemyslí. Ve skutečnosti je měsíční správa Wordpressu poměrně časově náročná, určitě to hodinku, dvě vezme. Jenže to už zákazníci nechtějí platit - vždyť je to Wordpress, Opensource, tedy to musí být ZADARMO.

28
Odkladiště / Re:Diskuze na wordpress šabloně
« kdy: 27. 02. 2019, 20:22:26 »
Na to se vyloženě nabízí otázka: Jaký redakční systém místo Wordpressu, který by výše uvedenými problémy netrpěl?

Když se podívám do statistik, tak Wordpress a Joomla jsou průšvih. Drupal a Magento jsou na tom výrazně lépe:
https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337
https://www.cvedetails.com/vendor/3496/Joomla.html
https://www.cvedetails.com/product/2387/Drupal-Drupal.html?vendor_id=1367
https://www.cvedetails.com/product/31613/Magento-Magento.html?vendor_id=15393

29
Odkladiště / Re:Diskuze na wordpress šabloně
« kdy: 27. 02. 2019, 18:02:01 »
Na Wordpress není žádná rada. Je to tak moc rozšířený systém, navíc programovaný poměrně špatně, se spoustou pluginů programovaných amatéry, že to celé přitahuje hackboty jako magnet.

Lze doporučit jen obecné rady, ale ty jistě znáte: automaticky a co nejrychleji aktualizovat na nejnovější verze. Pečlivě vybrat správné pluginy a zabezpečení. Docela dobře může pomoci i Web Application Firewall, např. Atomic má poměrně slušný ruleset za solidní cenu ($ 225 / rok: https://www.atomicorp.com/amember/cart/index/product/id/29/c/). Ten aplikační firewall vyblokuje spoustu útoků a také odhalí hodně slabin v pluginech wordpressu (nejčastěji XSS).

Pak může pomoci nastavit běžný firewall, omezit počet spojení za určitý čas ze stejné IP adresy. Je to sice dost zoufalé řešení, ale pomůže.

Další zoufalé, přesto fungující řešení je fail2ban, zejména pokud do něj nakrmíte právě výsledky z modsecurity.

Ale to všechno jsou ohejbáky, narovnáváky, ..., které nikdy nebudou stoprocentní. Vždy bude určitá část útoků úspěšná, a vždy to bude trpět na falešné detekce.

Pokud můžete, vyhněte se Wordpressu, je to levnější než tyto blbiny. Nenechte se zviklat tím, že "Franta odvedle" provozuje roky Wordpress pro svůj pingpongový klub a bez problémů. Wordpress je o to náchylnější na průšvihy, o co víc jste na internetu zmiňovaný. Hackboti sbírají adresy, které testují - takže neznámé pingpongové stránky mají daleko větší šanci přežít, než aspoň trochu známý web.

30
Server / Re:MircoServer Gen8 - výběr OS + virtualizace
« kdy: 27. 02. 2019, 14:03:48 »
Tohle už je asi na osobních preferencích. Mně jail přijde jako nejelegantnější řešení. Paravirtualizace či kontejnery jsou podle mě zbytečně složité. Jak píšete, jail je vylepšený chroot (o mnoho vylepšený), ale díky tomu má opravdu prakticky nulovou režii. Pokud v jailu nepotřebujete mít spuštěný ani cron, tak v něm nemusí běžet ani jeden proces.

Stran: 1 [2] 3 4 ... 116

reklama