Ako zabezpecit webserver?

jenze na to je prave cool cloudlinux + LFD + CSF .. vsechny mozny pretizeni a veci vychytam prave diky tomuhle, i kdyz bude exploit napadne max jeden ucet. Pokud bych chctel 100% ochranu a resni proti memory leaks a podobnym vecem pak uz jen openbsd v 2 restricted rezimu. Ale stim se moc zit neda :) ..ale musim priznat ze mam par stroju na OpenBSD, kde vse kompiluju hned jak vyjde novaverze nebo nejaky patch. Je to otrava ale co by clovek neudelal pro bezpecnost.

@hacktrack: Já Vám rozumím, ale tady je potřeba si ujasnit, co tazatel chce. Pokud mu nabídnete správu VPS, pak mu klidně CL vychvalujte do nebe, je to cajk. On ale uvažuje, že si to zkusí sám a předpokládám na nekomerčním projektu, aby se to naučil. Tam je pak užití distribuce které nezná nesmyslné.---------- Příspěvek doplněn 04.03.2016 v 11:30 ----------BTW, není lepší nechat oddělení aplikací na virtualizaci? Tedy užívat to jako já stylem co app, to VPS a spíše si vyřešit nějakou hromadnou správu těch virtuálů?

ano odeleni aplikaci / reseni pres virtualizaci je ted nejlepsi varianta. pokud se nechce/nemuze neco ucit at si vezme predpripravenou distribuci CPANEL+CLOUDLINUX neni zas tak hroznej a tak drahej. Da se tam zapnout i automaticky update a upgrade..

ona ani nemusí být virtualizace (pv pod xenem je super, qemu je naproti tomu časovaná bomba, 1m řádku kódu skrývá určitě nejedno překvapení), rád používám jaily na freebsd, lxc na linuxu, ve spojení s chroot, apparom/selinux a cgroup to tvoří relativně silné řešení a administrace je mnohem lehčí. OpenBSD je proti virtualizaci dlouhodobě a tepve teď se začíná s tím seznamovat, obecně se nedoporučuje na hostování více nezávislých aplikací, ale pouze pro tu jednu jedinou a v tom umí být velice dobrý. Cpanel je dlouhodobě problémové řešení, výrazně zasahuje do konfigů a špatně se výsledný stav audituje, verzovat konfigurace je vlhký sen, pro mě cpanel != bezpečnost.Pokud jde k úvodní myšlence vlákna, nejlevnější cesta je pro linux šáhnout po dockeru, pravidelně aktualizovat (i konteinery), zakázat práva pro zápis všude možně, omezit apache/fpm přes chroot, nastavit na iptables rate limit, zavřít všechny nepoužívané porty, pravidelně zálohovat (databázi i www dir) a kontrolovat změny (verzování do gitu je ideální), php provozovat pouze s suhosin, razantně omezit délku běhu php procesu a pokud to není pro aplikaci třeba, zakázat php cli režim, pravidelně procházet logy, nedovolit spouštění kódu z upload složky a nenechávat v filesystému původní názvy uploadovaných souborů atd.Dírám v aplikacích se nevyhneš, chce jen minimalizovat důsledky a hlavně pravidelně procházet logy, bez toho jsi v háji, viz tvůj úvodní příspěvek. Primárně jde o sledování url, které vrací 404 a 500 a poté IP adres, které mají velký hit rate na tyhle url, často vidíš jednorázové skenování, to je vesměs v pořádku, horší je, když se opakovaně vrací stejné adresy. 404 jsou většinou důsledek skenování, 500 naopak jsou velký problém, to už druhá strana něco zkouší. Přístup na login formuláře by měl mít vlastní dashboard, sleduj všechny POST requesty, zejména ty, u kterých nepředchází 200 pro tu ip adresu nebo je opakovaně více postu po sobě (k tomuhle ti třeba s blokováním pomůže fail2ban).Problém je, když používáš nějaký prestashop či WP a neaktualizuješ, často se ti robot dostane dovnitř na první pokus a v logách si toho nevšimneš, naopak, když aktualizuješ, všimneš si podobného selhání a víš, že máš dávat bacha. Stejně tak je zbytečné vytvářet seznamy IP adres a doživotně je blokovat, max. v řádu hodin. Jedná se často o IP adresy běžných uživatelů, které mají nějakou neplechu u sebe.

Dovolím si povedať že to čo píšete o cPanel nie je pravda.Za prvé je to komerčné riešenie. V spojení s CloudLinux je to parádne riešenie. A CloudLinux je taktiež komerčný OS.A hlavne treba sa naučiť ako funguje potom je sledovanie čo sa kde deje úplne jednoduché.

jamire40: nechci sem zanášet flame o cpanelu, pokud to chceš více probrat, klidně PM. Tak jen krátce co se mi na cpanel nelíbí:- kompiluje si vlastní verze opatchovaných balíčků- dává logy na jiná místa než člověk čeká (ano, to se dá naučit a stahovat si je odjinud)- bezpečnostní patche trvají někdy pěkně dlouho než k nimi probublají, stejně tak nemají všechny balíčky up to date- dovolují jednoduše nastavit věci, které server položí nebo ho otevřou světu- diagnostika systému pod cpanelem není snadná (žádná historie změn, chabé acl např.)- nemluvě ne "nemožnosti" hromadné správy pokud mám desítky serverů, poprat se s rolling update je peklíčko- možnosti auditování a nastavení bezpečnostní politiky jsou obtížnéNeřikám, že to je vždy špatně, naopak základní administraci systému zjednodušuje a více ho otevírá méně znalým lidem, ale porušuje základní poučky pokud jde o konfiguraci systému, zanáší bariéry pro jeho správu atd. Pro mě systém nad cpanelem není bezpečný, protože ho admin může mít jen složitě pod kontrolou, nemluvě o jeho úzkém zaměření pouze na weby.

cPanel a hlavně WHM je bastl. Kromě netransparentního chování nejsou schopni zajistit ani zpětnou kompatibilitu API, viz třeba obsazený prostor. Na hrání a testovací servery oukej, ale na produkci bych jej už nepustil.

Globálně je největší problém neaktualizovaný OpenSource a jeho moduly/pluginy. Všechny aplikace jsou zranitelné, ale ty automatizované útoky botů jsou typicky zaměřeny na známé chyby v OpenSource. Nastavení serveru může snížit následky, ale v principu to chce, aktualizovat, aktualizovat a aktualizovat a nepoužívat věci, které nejsou udržované.

Spoustu důležitých informací a možností zde již bylo napsáno, ale já bych doporučil v případě méně zasvěceného uživatele linuxu (pokud nepředá správu profíkovi vč monitoringu), nasadit alespoň nad http/s službu webový firewall jako službu. V dnešní době již už je na trhu pár dobrých a za rozumné peníze (třeba sucuri). Navíc nasazení je triviální a v popsaném případě by to mohlo dobře sloužit. Neříkám, že je to všespásné, to né, ale v tomto případě, kdy byl útok veden via http službu by to řešilo hodně ;)