Moderní způsob zabezpečení webserveru

[Dzimy]

Nazdarek,

Chci se zeptat zkusenejsich, jake jsou nejake nove metody zabezpeceni web serveru s vhosty? Jde mi primarne o to, ze v pripade, ze dany vhost bude mit derave php/cgi skripty, tak dojde maximalne ke kompromitaci toho vhostu, ale ostatni vhosty a system budou bez dopadu ...
Kdyz jsem to delaval pred 10 lety, tak jsem nasazoval veci jako suphp, suexec, v konfiguraci openbasedir, pozdeji mod_ruid2 a dalsi.
Verim ze dnes se to uz resi jinak a snad lepej a jednodusej, budu rad za jakekoliv zkusenosti!

[Reklama]

[McFly]

Já používám MPM-ITK (v kombinaci s Openbasedir direktivou) - každý vhost má svůj UID/GUID. Info např. https://www.howtoforge.com/running-vhosts-under-separate-uids-gids-with-apache2-mpm-itk-on-debian-etch

[to_je_jedno]

docker a mas po starostech

[john]

docker a mas po starostech

Docker a typicky vsetky procesy v kontajneri budu bezat pod rootom = ked uz sa dostanes do kontajnera, napr. cez derave PHP, tak mas root, ktory dokaze (takmer) ako root komunikovat s kernelom = nic moc zabezpecenie.

Ked uz Docker tak so zapnutym user namespacom (t.j. root v kontajneri != root  na hostovi), pripadne este vhodny selinux/apparmor profil podla pouzitia kontajnera.

[Tomas2]

stejně jako si necháš bezpečnostní dveře zamontovat od specializované firmy, nech zabezpečení lidem, kteří to umí. Bez znalostí a zkušeností to nikdy sám nedokážeš.

Docker je jen iluze, nikdy nebyl navržen jako bezpečnostní technologie.

Linuxový kernel má dobrou úroveň zabezpečení, spolehni se na něj - každý vhost pod svým uživatelem, zákaz přístup a zápisu tak kam nemá, omezení přístupu na síť pro php, přidělení jen určitého množství zdrojů (cgroup) a zákaz většiny syscallu (apparmor, selinux).

Častá chyba bývá třeba otevřený nějaký daemon (tcp, socket) přes kterého lze zneužít nějaké díru, omez počet běžících procesů a služeb na pozadí, omez množství balíčků, sleduj jejich verze, pravidelně nejen aktualizuj, ale i otáčej služby, aby se aktualizace projevila. Sleduj logy, měj monitoring a alerting. Jen tak můžeš mít bezpečnou platformu.

[Reklama]

[Sten]

Nazdarek,

Chci se zeptat zkusenejsich, jake jsou nejake nove metody zabezpeceni web serveru s vhosty? Jde mi primarne o to, ze v pripade, ze dany vhost bude mit derave php/cgi skripty, tak dojde maximalne ke kompromitaci toho vhostu, ale ostatni vhosty a system budou bez dopadu ...
Kdyz jsem to delaval pred 10 lety, tak jsem nasazoval veci jako suphp, suexec, v konfiguraci openbasedir, pozdeji mod_ruid2 a dalsi.
Verim ze dnes se to uz resi jinak a snad lepej a jednodusej, budu rad za jakekoliv zkusenosti!

PHP-FPM a nginx. Oddělit web server od PHP, jak jen to jde. Pokud možno PHP-FPM instance každého uživatele navíc šoupnout do vlastního kontejneru a osekat tam, co jde (žádná nová odchozí spojení, tvrdý RLIMIT_CPU na maximální dobu běhu procesu, immutable PHP skripty mapované zvenku u toho, co není potřeba měnit ap. — tohle je u spousty CMS opravdu těžké odladit, protože s něčím takovým to často vůbec nepočítá).

Docker a typicky vsetky procesy v kontajneri budu bezat pod rootom = ked uz sa dostanes do kontajnera, napr. cez derave PHP, tak mas root, ktory dokaze (takmer) ako root komunikovat s kernelom = nic moc zabezpecenie.

Ked uz Docker tak so zapnutym user namespacom (t.j. root v kontajneri != root  na hostovi), pripadne este vhodny selinux/apparmor profil podla pouzitia kontajnera.

Tohle dělá každé spuštění Dockeru, LXC, OpenVZ a asi i všech ostatních kontejnerů, jinak by to byl jenom fancy chroot.

[Dzimy]

McFly: Jsem se zapomel zminit, itk samozrejme pouzivam s tim vsim co jsem psal na zacatku. Jinak mam pocit, ze prave openbasedir promenna se nejak bude rusit resp. se nedoporucuje nadale pouzivat, rikal jeden kolega ...

Spis jsem treba cekal navrhy/napad jak pouzit nejake nove apache moduly o kterych nevim, nebo
zkusenosti s mod_security, mod_ruid2, suexec, suphp a dalsi. Co z toho ma budoucnost a co uz ne a tak.

Samozrejme diky za napad s kontejnery, je to na zvazeni.

[Tomas2]

ona bezpečnost a novinky nejde moc dohromady. Každá technologie, funkce potřebuje čas než jí lze označit za bezpečnou a ověřenou.

Bezpečnost php aplikací musíš řešit v systému a ne na apache serveru či php modulem, nikdy nechceš, aby apache nebo php moduly měly taková oprávnění, aby mohly řešit bezpečnost, to je postavené na hlavu.

Vem si k srdci doporučení od Sten, zagoogli si co tím básník chtěl říct a nastuduj si to.

[.]

A ještě doplním: automatizuj, automatizuj, automatizuj. Nic nedělej ručně.

[shr3k]

PHP-FPM a nginx. Oddělit web server od PHP, jak jen to jde. Pokud možno PHP-FPM instance každého uživatele navíc šoupnout do vlastního kontejneru a osekat tam, co jde (žádná nová odchozí spojení, tvrdý RLIMIT_CPU na maximální dobu běhu procesu, immutable PHP skripty mapované zvenku u toho, co není potřeba měnit ap. — tohle je u spousty CMS opravdu těžké odladit, protože s něčím takovým to často vůbec nepočítá).

Dělám to také tak... a jako bonus občas ani požadavky nepustit k FPM (try_files pro přímý přístup ke statickým věcem, limit_req_zone, geoip_country_code atp.).