Názory k článku Postřehy z bezpečnosti: kocoura Apache ohrožuje Strašidelná kočka

„Omezte používaní doplňků prohlížečů [...] Před několika lety ho ale původní majitel prodal a nový majitel tento doplněk modifikoval tak, že teď kontroluje, zda uživatel edituje určité webové stránky jako např. WordPress nebo Joomla. Pokud zjistí, že ano, na konec editovaného souboru přidá javascriptový kód, který má za úkol zobrazovat nevyžádané reklamy.“

Popravdě, od článku, který popisoval něco podobného, jsem si vytvořil čistý profil Firefoxu a doplňky již neinstaluji. Byla to celkem studená sprcha.

Na druhou stranu jsem nedávno potkal holku, která používá doplněk na blokování JavaScriptu s tím, že jej selektivně a snadno může zapínat pro jednotlivé stránky, je-li to potřeba. Od té doby přemýšlím, čí řešení je vlastně bezpečnější.

Ani jedno řešení není do nekonečna udržitelné.
Nejjistější je používat doplňky (ostatně jakýkoliv software) od "důvěryhodných" vendorů. Jenže kdo to je?

Z mého pohledu to je takový vendor, u kterého rozumím jeho komerčnímu zájmu a věřím, že by svůj zájem neohrozil nějakou "klukovinou". Zkrátka, pokud někdo něco dává zadarmo nebo za hubičku (pár dolarů), dá se očekávat, že nehospodaří s přebytkem peněz. Pak se dá taky očekávat, že může hledat "alternativní" způsoby přivýdělku. Proti tomu nedokáže ochránit žádné bezpečnostní opatření, žádná heuristika. U WordPressu a jeho okolí (doplňky, témata) jsou bezpečnostní statistiky dlouhodobě hrozivé. Přesto jsou lidé nepoučitelní.

PS: ani můj klíč výběru důvěryhodných vendorů není bezchybný. Viz kauza Avastu a prodeje deanonymizova­telných dat.

9. 3. 2020, 08:56 editováno autorem komentáře

„ Nejjistější je používat doplňky (ostatně jakýkoliv software) od "důvěryhodných" vendorů. Jenže kdo to je?“

A to je právě ten problém. Vámi popsaný způsob výběru stále podle mne neřeší, co popisují oba články - co když ten doplněk (či jiný SW) přenechá někomu jinému? (Např. někomu věřím proto, že daný SW implementuje kvůli řešení problému, který mám také, ale po X letech se autorova situace změní, už jej nepotřebuje a projekt si vezme pod křídla jiný.) Není v mých silách (nebo ochota, chcete-li) si udělat 100% soupis veškerého SW (vč. teoretických pluginů), který používám a sledovat třeba každý měsíc, co s ním autor dělá.

Takže ve výsledku to mám, zase podobně jako vy, postavené na víře. V některých případech jsem přísný (právě v rámci pluginů ve Firefoxu kvůli postavení webu v dnešní době; zároveň třeba aktualizuji jeden web na Drupal 8 a můj přístup k jeho modulům je podobný a prošlo jich jen pár a zbytek si implementuji sám), v případě velkých autorů (Canonical, Mozzila, VideoLAN, autoři jádra Drupalu) doufám, že kdyby vymýšleli něco, co považuji za hodně problémové, tak se to dovím a ten zbytek (např. Zim) je vědomý risk, sázka.

Takže ve výsledku to mám, zase podobně jako vy, postavené na víře.

Bezpečnost není postavená na víře, ale na důvěře. Zadavatel důvěřuje dodavateli, že vybral správné technologie. Zodpovědný dodavatel vybírá subdodávky, aby se sám mohl spolehnout. Nežijí mezi námi jen zodpovědní dodavatelé, praxe je spíš taková, že se web splácá z toho, co se kde zadarmo najde.

co když ten doplněk (či jiný SW) přenechá někomu jinému?

Toto se právě u některých vendorů moc nestává, protože vědí, že po prodeji by šel dolů i goodwill prodávajícího. Na to, aby tato úvaha fungovala, musí ovšem existovat nějaký goodwill, o který nechce aspoň jedna ze stran přijít. Když je to doplněk od "firmy," která nedělá nic jiného než pár pluginů do WP, tak prodejem nemají o co přijít.

Není v mých silách (nebo ochota, chcete-li) si udělat 100% soupis veškerého SW (vč. teoretických pluginů), který používám a sledovat třeba každý měsíc, co s ním autor dělá.

Ano, přesně tak. Je těžké vysvětlit zákazníkovi, kterému vytvoříte web za hubičku s využitím komponent třetích stran, že od té chvíle by měla začít pravidelná (a asi ne úplně zdarma) správa, ve které je zahrnutá i tato činnost. Ono to pak působí obousměrně regulačně: i Vy si pak budete vybírat co nejméně dodavatelů, abyste neměl tolik práce s revizí stavu.

Ve výsledku to vždy zaplatí zákazník. Buďto formou hlubokých problémů, když to nastane, nebo pravidelným asset managementem, nebo formou vlastního vývoje (do kterého z části patři znovu asset management a správa).

9. 3. 2020, 10:40 editováno autorem komentáře

„Bezpečnost není postavená na víře, ale na důvěře.“

Ok, upravím/upřesním: má volba SW je založena na víře. (Na druhou stranu, mé jazykové dovednosti nedokáží dost dobře rozlišit pojmy „víra“ a „důvěra“. Nicméně používám pojem „víra“, protože není postavená na žádné formální/racionální analýze, nedělal jsem žádný code-review open source, nestudoval jsem detailně případné audity, např. u TrueCryptu, ...)

„Toto se právě u některých vendorů moc nestává, protože vědí, že po prodeji by šel dolů i goodwill prodávajícího. Na to, aby tato úvaha fungovala, musí ovšem existovat nějaký goodwill, o který nechce aspoň jedna ze stran přijít. Když je to doplněk od "firmy," která nedělá nic jiného než pár pluginů do WP, tak prodejem nemají o co přijít.“

No a tímto jsem se odřízl od většiny pluginů, které by byly pro mne ve Firefoxu zajímavé, a v tom zbytku se mi moc nechce hledat.

„Je těžké vysvětlit zákazníkovi, kterému vytvoříte web za hubičku s využitím komponent třetích stran, že od té chvíle by měla začít pravidelná (a asi ne úplně zdarma) správa, ve které je zahrnutá i tato činnost. [...]“

Souhlas.

K ghost cat je vhodne doplnit, ze postihuje vyhradne protokol AJP.

to ludia prevadzkuju tomcat bez firewallu a reverznej proxyny (nginx)?!

Ano, velmi často. Tomcat už je pro spoustu "adminů" moc složitý mechanismus, na který nenajdou zázračné kuchařky, jak nainstalovat a spustit ve třech krocích a bez zapnutí mozku. Proto i spousta aplikací se distribuuje rovnou včetně Tomcata (tedy i bez možnosti nezávisle aktualizovat!) a jen se spustí. Pak se nedivte, že ti samí pak považují reverzní a perverzní proxy za totéž.

Tento nešvar se objevuje i v bohatých korporátech. Dodavatel nabídne aplikaci a prohlásí, že ji dodá nainstalovanou. Project owner, aby šetřil peníze a čas nezkontaktuje ani IT oddělení aby specifikovalo požadavky na začlenění do sítě (jsou to staří potížisti, kteří hledají problémy tam, kde nejsou :)). Na konci projektu, obvykle týden po deadline, někdo zavolá do IT, kam že mají tu aplikaci nainstalovat. Další humbuk není asi třeba popisovat, ale na konci běží někde nová VPS, nabastlená, se spuštěným Tomcatem "na ostro". A tento stav se někdy i roky nezmění, protože project ownerem je oddělení, které za provoz odpovídá, a nechce si ho nechat "rozbořit" zásahy ajťáků.

Pekny pribeh. Este doplnim ze ani firewall vas neochrani pred nasledkami troch magickych slov: "default admin password".

Proč by ne? Firewall (na L3 nebo L4) v tomto případě nic moc neřeší (pokud má AJP naslouchat jen na localhostu, má se to řešit konfigurací AJP a ne na firewallu). A k čemu reverzní proxy server? Tomcat už dávno umí HTTP dostatečně dobře. Mimochodem, ten problematický AJP je určený právě pro to, aby bylo možné Tomcat umístit za reverzní proxy. Kdyby se Tomcat za reverzní proxy nikdy nedával, nevznikl by ani tento problém…

1) firewall na masine ma byt proaktivne nasraty, teda deny all, allow potrebne porty.
2) nginx ako reverse proxy napriklad kvoli subjektivne jednoduchsej konfiguracii, hlavne ked je v rieseni tomcat, staticke zdroje a IIS. V takomto mixe je v ramci psychohygieny vhodne robit https endpoint, rewrite rules, poor man's load balancing, reverse proxy a basic auth priamo v nginxe.

10. 3. 2020, 18:17 editováno autorem komentáře

O IIS vůbec nebyla řeč. Běžná aplikace má statické zdroje i pravidla pro přepisování a přesměrování v sobě, nginx tam pak nedělá nic jiného, než překlápí data z jedné strany na druhou. Případě je brzda pokroku, když se trefíte třeba do období, kdy backend server už umí HTTP/2 ale nginx ještě ne. Dnešní SPA aplikace mmohou být samostatný frontend se statickými soubory a vedle nějaké REST nebo GraphQL API a můžete to chtít provozovat vše na jedné doméně, pak může nginx alespoň servírovat statické soubory – akorát je otázka, zda je k něčemu dobré mít tam dva HTTPS servery, když to celé zvládne i jeden. Samozřejmě je spousta případů, kdy dává nginx jako reverzní proxy před nějakým aplikačním serverem smysl, ale určitě se nedá tvrdit, že tam má být vždy.