Vlákno názorů k článku Postřehy z bezpečnosti: kocoura Apache ohrožuje Strašidelná kočka od Youda - K ghost cat je vhodne doplnit, ze postihuje...

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.