Bezpečnost veřejného webového serveru

[popelar]

Dobry den,

zacal jsem s provozem sveho prvniho (verejneho) weboveho serveru a mam k tomu otazku ohledne bezpecnosti.

Server je schovany na interni siti za bastion hostem, ktery je radne zabezpecen a port forwarduje 80 na webserver. Na web hostu bezi server na custom portu pod beznym userem.

Bastion zarucuje, ze na sit nedojde nic jineho nez http traffic. Ale zaujalo me, ze i po http se prakticky ihned po spusteni serveru zacaly vest utoky na tento http server. Vesmes jsou to brute force utoky PUSHem. Polozil jsem si proto otazku, zda verim implementaci serveru, ze odola vsemu, co se po http da vest (nejsem zbehly v bezpecnosti/hackingu). Taky mi vadi, ze to server zatezuje.

Rad bych se proto zeptal, jake jsou pristupy k bezpecnosti http serveru a jak to resit.

Resil bych to asi proxy serverem pred tim webovym (traefik), ktery bude poustet pouze GETy. Je toto doporucena cesta? Co dalsiho muze proxy pro bezpecnost udelat?

Pro ssh na servisnim jump hostu mam nastaveny fail2ban. Da se udelat a doporucuje se to stejne pro http? Tedy ve stylu IF >= 4 pokusy PUSH => put to jail. Pripadne jina implementace nez pres fail2ban?

Pouziva se v praxi jeste neco dalsiho?


Diky za vsechny postrehy.

[Reklama]

[alex6bbc]

je treba hlidat, ze je webserver aktualizovany a se vsemi zaplatami a pokud tam bezi apka tak hlidat i jeji bezpecnost. vhodnejsi je to provozovat na https.

[Petr Branik]

S 25+ let v oblasti cyber security bych vam doporucil sverit bezpecnost nekomu kdo tomu rozumi (pokud je to nejaky firemni web server), tech moznosti utoku na web server je spousta. Nemate s tim zkusenosti, web server mate misto DMZ v interni siti, ptate se na diskusnim foru,… pokud chcete, napistemi do zprav a pustim vam na to minimalne nejaky sken, nic za to nechci ani nic z toho neocekavam.

[Jan Forman]

Bohužel nic univerzálního fakticky neexistuje, fail2ban je sice relativně dobrý, ale bohužel většina útoků probíhá z mnoho míst a tím je pouze trošku přibrzdí.

Web Application Firewall se hodí, ale bez velmi precizní konfigurace bude fungovat jen částečně. Měl by propustit jen to co je nezbytně nutné.
Nějaký rootkit detection toolkit může být taky dobrý - prostě jakkoliv testovat změny souborů v systému.

Běžně je dobré si udělat komplexní seznam aplikací, knihoven, které v tom systému jsou a ty hlídat na nové chyby.
Server hodit do klece :-) kde vidí jen na to co má z vnitřní i vnější sítě - ideálně skoro nic.

Já bych to asi bez zkušeností asi nedělal v produkčním prostředí, může to být nebezpečné.

[Filip Jirsák]

Zaměřujete se na nepodstatné věci a míjíte ty podstatné. Zarazil mne už ten port 80 – ten se používá jen pro ověření před vydáním certifikátu a pro přesměrování požadavků, pokud někoho hloupý prohlížeč po zadání adresy směruje na HTTP a ne HTTPS. Jinak už web dávno běží jen na HTTPS.

Obáváme se zranitelností webového serveru, chcete ho schovávat, blokovat přístupy… Webový server musí vydržet to, že je plně dostupný z internetu. Pokud nevěříte, že to vámi vybraný server zvládne, pak takový software vůbec nepoužívejte.

Nejzranitelnější je aplikace, která na tom serveru poběží. Pokud je to produkt třetí strany, sledujte vydávané aktualizace, co nejdřív je aplikujte – a ještě před instalací si prověřte, jak to ten produkt vůbec s bezpečností má, jestli na ni třeba autoři úplně nekašlou. Jestli je to něco interního, pak je potřeba, aby vývojáři uměli napsat bezpečnou aplikaci – a pokud je to důležité, je dobré podrobit ji pak bezpečnostnímu testování.

[Reklama]

[_Jenda]

Vesmes jsou to brute force utoky PUSHem. Polozil jsem si proto otazku, zda verim implementaci serveru, ze odola vsemu, co se po http da vest (nejsem zbehly v bezpecnosti/hackingu).

Ano, všichni to tak dělají, otevřou webserver do internetu, jak by to taky dělali jinak (v případě že před to dáš nějakou proxy, tak jsi jen problém přesunul na tu proxy). Mělo by jít o nějaký běžný, aktivně udržovaný a veřejně často zkoumaný software (Apache, nginx, lighttpd…) a instalovat záplaty (poskytuje vám distribuce).

Vyhackování skrze díru ve webserveru je věc neslýchaná, vždy jde o hacknutí aplikace - redakční systém typu Wordpress, eshop s pluginy třetích stran pochybné kvality, nebo vlastní aplikace, kde vývojáři dělají chyb, případně globálnější problémy typu log4j chyba. (pokud poskytujete jen statické stránky, nemusíte řešit)

Taky mi vadi, ze to server zatezuje.

U mých webserverů naprosto zanedbatelně, že se ten fail2ban nevyplatí řešit (bezpečnosti nepomůže, pokud botnet dostane nový exploit, stejně to bude zkoušet proti náhodným cílům s náhodných IP adres a nebude do toho bouchat víc než pár požadavky.

Stejně jako některé další diskutující mě zarazil ten port 80. Kde terminujete HTTPS? Na té proxy? A pak je síť důvěryhodná? (a jak někdo psal, jestli považujete „interní síť“ za bezpečnou, tak by možná stálo za zvážení dát to jinam)

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Jak port 80 pomůže s bezoečnosťí v dotazu(což není odposlech ani modifikace)

   Vesmes jsou to brute force utoky PUSHem.

O jaké jde PUSHe? Myslíš metodu Http?na péčkobje akorát put,patch,post