Ako zabezpecit webserver?

Ahojte, pred casom som mal vlastne VPS, webserver, ktore som si nechal nainstalovat od profika ktoreho mi odporucil znamy. Ale po nejakom tyzdni bolo VPS hacknute. Ukazalo sa ze to bol obycajny bot ktory zneuzil nejaku php fcgi chybu, tusim nieco s maximalnym poctom alebo dlzkou POST hodnot a islo o uplne nahodny utok kedy bot iba skenoval ip adresy a snazil sa aplikovat epxloity. Skratka nic extremne. Jednalo sa o nejaky redhat(mozno fedora, neviem), ssh na zmenenom porte a nejak viac o nastaveni toho VSP uz neviem. Nuz, teraz si idem riesit znova VPS a skratka sa potrebujem takymto veciam vyhnut a ako tvorca webstranok nie som dostatocne znaly tejto problematiky a tak by ma zaujimalo ako riesite bezpecnost vasich webserverov vy...skratka nejake prakticke rady do zivota? :)

Pokud chceš, aby přes jeden web nedokázali vykrást druhý, musíš ty virtualhosty od sebe oddělit. Bohužel, php bylo, je a bude samá díra. Takže spouštět ho jako cgi, každý virtualhost pod svým uživatelem, to je základ. Pokud to je hodně kritické, stojí asi za to zvážit, jestli to nespouštět jako oddělené kontejnery. Útoku na php se ubráníš jen velice těžko, je třeba s ním předem počítat a snažit se minimalizovat případné škody, aby ti přes něj útočník nevybral celou VPSku.

Tak myslim ze zavriet vsetko okrem http(80) a https(443) nie je problem, ale v mnou popisovanom pripade by mi to aj tak nepomohlo.

Nejsem server admin a produkční věci raději svěřím někomu zkušenějšímu, ale nějaké dev servery mám a ty si zakládám za letu sám.. U těchto věcí mi moc o bezpečnost nejde, protože mají většinou jepičí život a pak destroy, ale obecně se snažím dodržet pár zásad.-Zakázat přístup heslem (SSH) a povolit pouze certifikát-Držet aktuální verzi OpenSSH a NGINX-Odstranit jakékoliv podrobnosti o verzích Nginx, případně PHP pokud tam je-Loadovat pouze nezbytné moduly, ideálně si vše zkompilovat pouze s tím co potřebuji-Vypnout upload souborů pokud jej nepotřebuji, případně alespoň omezit velikost-Omezit velikost POST pokud není třeba nahrávat soubory z web app-Vypnout allow_url_fopen a zapnout sql safe_mode pokud je-Správný memory limit, input_time a max_execution_time-U PHP vypnout exec, shell_exec, system,p roc_open, curl_exec, show_source, atd-Správná práva adresářů a souborů = dodržovat dělení do skupin-SELinux?-Správné restrikce v iptables-Správně nastavit NGINX proti přetečení bufferu-NginxHttpLimitZone, fail2ban-U webserveru správné restrikce adresářůNějaké tipy třeba tady: http://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.htmlObecně asi není problém to i s pár tutoriály dostat do funkčního stavu, větší problém je, že to každý vymazlí a dál se o to nestará.. Pokud někdo nemá čas sledovat aktulní bezpečnostní hrozby (jako já), pak by to spíše měl svěřit odborníkům, toť můj názor :-)

Aktualizovat.

ten admin to nenastavil správně, tečka.řiď se tím co napsal i-press s vyjímkou vlastní kompilace (balíčky jsou dobře udržované a často s dobrým výchozím nastavení, vlastní kompilací jen přidáš další místo, které můžeš zkazit). Selinux (či apparmor) je k ničemu pokud ho neumíš konfigurovat.Tvůj hlavní problém byl, že webový uživatel mohl někam zapisovat a z toho místa šlo spustit php kód. Příště zajisti 2 důležité věci, pokud používáš nějaký wordpress nebo prestashop:1) udělej dva uživatele, jeden pod kterým poběží frontend a který nebude mít právo kamkoliv zapisovat a číst jen webový adresář (klasicky se volí neexistující uživatel a pohlídají se práva na souborech, aby nikam neměl přístup nikdo mimo nějakou skupinu). A druhého pod kterým bude běžet administrace a který bude mít právo na zápis pouze do adresářů, které připadají v úvahu (uploads, plugins, themes), s tím, že z uploads není možné spouště php kód (nastavení nginx). V nginx se to řeší jiným backendem a na serveru poběží třeba dvě php-fpm služby. Tím zminimalizuješ využití neaktualizovaných děr v aplikacích, což byl v tomlhe případě tvůj problém.2) přes firewall (iptables) zakážeš přístup ven ze serveru (mimo http, ntp, icmp atd.), případně povolíš jen konkrétní služby (wordpress aktualizace) - prakticky většina webových aplikací nepotřebuje komunikovat ze serveru ven. Pokud budeš mít na serveru i jiné služby, což nepodoručuji, které budou moci komunikovat ven, je ideální nasadit selinux a prostě jen jim povolit konkrétní místa. Tím zabráníš v případě kompromitace, aby mohl daný "virus" fungovat.Samozřejmě k tomu se váže to, že musíš kontrolovat logy, které ideálně musí být mimo samotný server, aby nemohlo dojít k jejich změně.Doporučení na závěr, neexistuje dobře zabezpečený server bez toho, aby se o něj průběžně staral admin. Není prostě možné něco jednorázově nastavit a víc to nekontrolovat, automatické skripty jsou hodně efektivní. Včera jsem spustil wordpress na portu 8080 a během 30 min tam byli roboti a zkoušeli přihlášení do administrace.

Pokud si amater v nastavovani a administraci a nechces mit starosti pouzij cloudlinux a pokud se ti nechce nic delat v konzoli dej si k tomu cpanel. Kazdy web pod samostatny ucet a izolaci jak na procesech tak na IO ti zaridi cloudlinux, kdyz ti hacknou jeden web zadny dalsi to neodnese ani ztratou vykonu.Jinak sem schopnej ti nachystat VPS s CentOS , LAMP konfiguraci s advanced pravidly nad iptables. A postup jak vytvaret izolovane weby, jedne co tam budu kompilovat bude proftpd . To co pise i-press tam davam vzdy, jen primarni webserver je apache a da se pred nej nginx postavit jako proxy, chrani to pred par utoky a nekterymi problemy co neumi apache vychytat.

hacktrack: hezké doporučení, ale nic z toho by problému v úvodu nezabránilo...

Napsal TomášX;1272563

hacktrack: hezké doporučení, ale nic z toho by problému v úvodu nezabránilo...

Mohli budto napadnout nejakou znamou a diravou aplikaci nebo povodni admin nechal nejakou vychozi aplikaci nebo vec zapnutou, tomu se da predejit kdyz vite co delate.Spravnym nastavenim by se dalo hodne vecem predejit..

Správné nastavení je dost široký a neurčitý problém.Ano, je pravděpodobné, že nějakou známou dírou třeba v pluginu na server propašovali svůj php skript a přes něj již měli dveře otevřené. Obecné doporučení je, že tam kam může aplikace zapisovat, nesmí být možnost spouštět kód a skripty, klasicky upload složku přimountnu jako noexec a nginx dostane nakázáno požadavky na tuhle složku neposílat na backend, ale buď zakázat nebo načíst jako soubory.Pokud jde třeba o Wordpress, tam je problém, že administrace může zapisovat do adresářů s pluginy a vzhledy, což jsou php soubory. Není tedy jiné cesty než pro konkrétní cesty, které obsluhují nahrávání vzhledů, pluginů a aktualizace vytvořím vlastního uživatele v systému a ty práva mu dám. Sice tím nezabrání nahrání špatného pluginu nebo zneužití díry v samotném nahrávání nebo aktualizaci, ale nebude možné tuhle funcionalitu zneužít z jiných míst, zejména třeba z frontendu nebo jiného pluginu.Jako další úroveň zabezpečení používám zakázání php skriptům komunikování ven ze serveru, případně jen na konkrétní místa tj. ikdyž tam útočník propašuje někam svůj php kód a bude se snažit s ním tropit hlouposti, bude mít omezené možnosti jak s ním komunikovat. Odřízneš tímhle velkou část podobných automatických skriptů, ale zaděláš si na problémy s kompatibilitou různých kódů třetích stran.Zabezpečit server je jedna věc, to ti udělá kdokoliv na zakázku, druhá věc je, že musíš znát aplikaci, kterou provozuješ a také zabezpečit jí, aspoň způsobem, který jsem tady popsal. Existuje ale více cest. Důležité je vždy a co nejrychleji aktualizovat, sledovat systém a monitorovat nestandardní chování. Neexistuje univerzálně bezpečný server pokud jsou slabiny v samotné aplikaci a server k tomu je benevolentní a dovoluje spouštět a zapisovat kód aplikaci dle libosti a aplikaci nijak neomezuje pátrat v systému, je to špatně. Vždy počítej s tím, že i samotná aplikace může dělat neplechu v systému a nedovil jí to.

A co díry v samotném PHP? Těch je taky požehnaně... A tam žádné omezení přístupu k adresářům daného webu nepomůže, pokud útočník skrze díru v php získá vládu nad strojem. Pomůže jedině omezit práva samotnému php.

Ano, přsně tak, ani samotná aplikace nesmí být schopná udělat nic špatného, chroot, práva, omezení komunikace ven, suhosin patche jsou samozřejmost.To jsme se ani nedostali k omezení db, kontrole na proxy co se posílá ven, sledovaní podezřelého chování atd. atd. Nejlíp zabezpečený systém má ale admina, který ho nonstop sleduje a řeší každou odchylku...

Napsal TomášX;1273284

Ano, přsně tak, ani samotná aplikace nesmí být schopná udělat nic špatného, chroot, práva, omezení komunikace ven, suhosin patche jsou samozřejmost.

To jsme se ani nedostali k omezení db, kontrole na proxy co se posílá ven, sledovaní podezřelého chování atd. atd. Nejlíp zabezpečený systém má ale admina, který ho nonstop sleduje a řeší každou odchylku...

jenze nondstop dohled zadnej admin u malyho webu nebo eshopu nebude delat. a dle vlastni praxe se to nedela ani u obrich projektu kde se staci vykrast tabulky s platebnimi informacemi.ad PHP chyby: ty samozrejme sou ale jsou hodne zavisle na prostredi kde a jak PHP bezi, za posledni dobu moc univerzalnich PHP exploitu nebylo. Za me nejlepe funguje cloudlinux tam je izolace dokonala a vse automaticky oddeleno. Adminovy to vyresi kupu prace.

Jasně admin je drahej, uvedl jsem jen hranici.Je vcelku jedno jakou distribuci používáš, znát problematiku a umět nastavit tu svoji je daleko důležitější. Cloudlinux zavádí poměrně dost svých věcí a musíš se je naučit. Stejně tak instalace na běžném hostingu není v režii bězných adminů a výhodnost pro malé projekty a pár serverů je nula nic. Doporučuješ ho, jak kdybys ho nikdy neimplementoval.Opravených zranitelností v php je pořád hodně. Exploity ani ne, spíše náchylnost k přetížení serveru, úniku paměti procesu atd.

S tím nelze než souhlasit. Node zde chtěl nějaké praktické rady a jsem si jistý, že si je vědom rizik pokud se o to jako neznalý bude starat sám. Nemyslím si, že je vhodné tlačit mu nějakou konkrétní distibuci, tím spíše ne CL, který si jde vlastní cestou. Bezpečnější v tomto případě spíše bude to, pokud použije distro které zná a je jedno jestli to bude Debian, CentOS, nebo Ubuntu, ale alespoň ví, co od toho může čekat.Nejbezpečnější server je nakonec stejně vždy ten vypnutý :-)