Z důvodů, že jsme v poslední době zaznamenali spamování z různých webů, rozhodli jsme se pro následující změny v nastavení serverů.
Dojde k zablokování funkce eval() v PHP, která umožňuje jakýkoliv vstup reprezentovat jako PHP kód což bylo v poslední době příčínou spoustu code-injection útoků převážně na starší verzi systému WordPress, na kterém je i provozován tento blog (v aktuální verzi). Tato funkce je vnímána odborníky jako riziková.
Dojde k vypnutí zobrazování chyb – to nadále bude možné zapnout skrze soubor .htacccess nebo jednoduše přes funkci error_reporting().
Před změnou bychom rádi ználi Váš názor na danou situaci. Přesný termín nasazení těchto úprav bude upřesněn na základě reakcí uživatelů, tak aby byl prostor na úpravu skriptů uživatelů, kterých se tato změna týká.
Já souhlasím, i když se mě to zřejmě netýká, ale člověk alespoň vidí, že pro zabezpečení děláte maximum.
Měl jsem za to, že se mají řešit příčiny problémů, nikoli jejich důsledky. Příčinou jsou špatně napsané aplikace, za ty by měli trpět ti, kterých se to týká, ne ti, kteří za to nemohou. Navíc ti kteří budou eval z nějakého důvodu potřebovat jednoduše uloží obsah parametr pro eval na disk a následně includují, kupodivu to udělá to samé co eval. To se zakáže i include/require?
Ano, určitě se má řešit příčina. Bohužel díky špatným aplikacím právě dochazí k zbytečným narušením provozu serverů. Samozřejmě je tu možnost include, a tu určitě nechceme zakázat, bohužel nyní dochází k tomu, že se využivá eval($_GET..) a útočník tak vkládá dynamicky obsah skriptu. Případ podobný třeba eval(‚echo hello‘) jsme nezaznamenali. Možnost povolení eval() zde stále bude pro konkretní klienty, kteří budou mít zájem a budou vědět k čemu funkce slouží – tedy ji budou umět použít.
len a len spokojnosť 🙂
čo tak zapracovať na e-mailoch? doceľa často to nejde
Dobrý den,
omlouváme se za komplikace s mail serverem. Další informace naleznete zde – https://blog.gigaserver.cz/2010/03/01/neplanovana-odstavka-mail-serveru/
Dobry den,
neprojevi se zmeny nastaveni serveru ve funknosti WordPress (Version 2.9.2)? Nebo v jeho pluginech?
Dobrý den,
problémy by to němělo udělat. Maximálně v některém z pluginů, kde by eval() mohly využívat. Ale je to málo pravděpodobné.
Pavel Ondřej
nevím jak ostatní frameworky, ale nette framework si s novým zabezpečením neporadí.
Já mám dvě možnosti: buď přepsat stránky, aby fungovaly i bez nette, anebo přesun na jiný hosting. No ani jedna varianta se mi nezamlouvá, ale přepisovat to nebudu.
Dobry den, staci zakomentovat v bootstrap.php debug. Viz http://kb.gigaserver.cz/entry/53/
Zakomentovat Debug:enable() neberu jako uspokojivou odpověď. Pokud se bojíte bezpečnosti, pak věřte, že Nette patří k tomu nejbezpečnějšímu, co u Vás může běžet. Spokojení uživatelé/programátoři jistě potvrdí:
http://nettephp.com/cs/kdo-pouziva-nette-framework
Dobry den,
netvrdime, ze Nette je nebezpecny. Bohuzel jine aplikace ano. Debug lze meho delat i bez pomoci nette fr. V dane dobe, ale nemuzeme umoznit klientum svevolne menit memory limit, safe mode atp. Jak jiste chapete, pripad kdy si memory limit nastavi nekdo na 1GB ma pro stablitu serveru neblahe dusledky.
Dobrý den,
dívám se dobře, že magic quotes jsou ON a vypnutí je zakázané?
chápu snahu o bezpečnost, ale zakázat „php_flag magic_quotes_gpc off“ je podle mě docela extrém … to že je to defaultně ON dejme tomu, ale netuším proč zakázat vypnutí … nadto „There is no reason to use magic quotes“ dle manuálu, escapování musí být z principu specifické dle kontextu, takže je to celkově nesmysl (viz i http://phpfashion.com/escapovani-definitivni-prirucka)
Dobry den,
nebyl to zrovna ucel zakazat tuto moznost, ale bohuzel je nutne zakazat php_flag uplne aby se zabranilo jinym direktivam – jako memory limit atp. Bohuzel PHP nenabizi moznost specifikovat co jde a nejde nastavit timto zpusobem – navic je tam duvod i mimo PHP a to primo v nastaveni options…
Jsem rád za tento postup. Web mi stále napadají viry kvůli aplikacím třetích stran a Opera tak stránky blokuje. Snad to problém vyřeší.
servus,
„Dale dojde k zablokovani pouziti Options v souboru .htaccess – “
sory tomuto nerozumiem, na wordpress vyuzivam rewrite_mod na permalinky, ovplyvnia to tieto zmeny?
Dobrý den, pokud máte problémy s viry, zkuste rozhodně i změnit heslo na FTP a hlavně ho neukládat přímo v FTP klientovi.
Dobrý den,
vše by mělo být v pořádku.
Moc se zakázáním php_flags nesouhlasím, ale pokud je to pro vás nejlepsí řešení, abyste zajistili bezpečnost klientům i sobě, tak to nějak strpím, protože další nastavení můžete pořád udělat individuálně sami.
Dobrý den,
bohužel je to nutnost z důvodu zachování stability (nastavení safe mode či memory limitu). Nicméně budeme se snažit klientům vždy vyhovět.
Je hezké pozorovat, jak jsou omezováni všichni kvůli chybám několika. Nevím jak to řešit jiným způsobem, nejsem admin, ale připadá mi celý hosting postavený na principu kolektivní viny. Proč mám nést zodpovědnost za někoho jiného? Proto si snad neplatím hosting. Věřím tomu, že pro admina je zákaz všeho možného jednoduché, rychlé a účinné řešení. Nemám nic proti zabezpečení, jen mám strach, co zas někdo způsobí, abychom to odnesli my všichni. Možná do budoucna budeme moci na tomto hostingu používat pouze javascript na klientovi. Neměl by se dobrý admin poohlédnout po řešení, které nebude tak restriktivní ke všem nebo danou funkcionalitu zakáže jen z části a ne celou? Nemám teď na mysli poslední zákazy, ale dlouhodobí vývoj. Jsem laik…
Komentář petrf mne inspiroval k nápadu, který tímto sdílím (byť jsem laik co do zabezpečení serverů) – když provozujete několik serverů, můžete snad přestěhovat uživatele, kteří mají „špatné aplikace“ (termín beru z předchozích postů) na jiné z vašich serverů, kde by bylo nastaveno „omezenější“ prostředí, zatímco jiní, kteří se cítí v tomto být „nevinně“, by mohli zůstat na serverech, které budou zabezpečeny méně omezujícím způsobem. Není to řešení?
Jaké je tedy definitivní stanovisko? Bude či nebude zablokována funkce eval? Používám systém Nucleus CMS, kde se tato funkce poměrně hojně používá.
[petrf]
Dobrý den,
můžeme Vás jistit, že to není chyba několika klientů, ale jejich počet je poměrně vysoký (a bohužel o té chybě aní neví) – a s tím, se myslím potykají všude. Zásadní problém je ten, že riziko je vetšinou skryté dokud se neprojeví – hlavně zneužitím chyby. Poté se z našich serverů posílá spam či se útočí na jiné servery atp. Funkce, které se blokují nejsou vhodné na sdílený hosting. PHP bohužel neumí lépe vyřešit zabezpečení pro sdílené servery. Pokud existuje mirnější varianta nebráníme se ji použít, ale ne vždy je a ne vždy je použitelná pro sdílený webhosting. Snad na závěr jen podotknu, že funkce, které se blokují se použivají zřídka. Neberu-li nastavení options v .htaccess. Zde, ale není možné dopustit, že si klient nastaví memory_limit na 1GB a pak zahlcuje operační pamět serveru na úkor jiných.
[Alarix]
Dobrý den,
bohužel toto řešení není. Jak jsem psal v reakci na uživatele petrf – chyby jsou většinou ukryté do té doby než se zneužijí. A jelikož zdrojové kódy klientů nelze procházet a hledat v něm chyby, které by mohly způsobit problémy, je nutné globální zabezpečení, které rizika využití chyb minimalizují.
[Pavel Jaroš]
Dobrý den,
eval blokován nebude.
TO admin (2. Listopad 2010 at 13:08)
Plně chápu nutnost bezpečnosti, proti tomu nic nemám a snad jsem to i naznačil, ale jak je nebezpečný tento příkaz „popen(„tar –version“, „r“);“ resp. „popen(„tar -zvxf $file_safe -C $dir_safe“, „r“);“? Myslím si, že je jednoduší zakázat funkci než řešit zdali vlastní volání funkce je či není v souladu s bezpečnostními pravidly. Zkrátka je to zakázáno, ale nikdo neřeší, že volání TAR asi servery nezlikviduje. Tohle jsem měl na mysli. Globální omezování. Někdo spustí nějakou blbost a my ostatní utřeme nos! Jsem sice laik, ale vím že slovo „nejde“ na počítačích neexistuje. Vše je to otázkou schopnosti hledat a řešit problém. V tomto konkrétním případě je ukázáno, že to co by šlo a neškodilo by je zakázáno globálně a je na straně zákazníka aby si problém vyřešil. Elegantní řešení ze strany poskytovatele …
[petrf]
Dobrý den, možnosti jsou různé. Věnovali jsme dostatek času vyhodnocením výhod/nevýhod všech přijatelných řešení. Momentální zabezpečení pomohlo eliminovat desítky pokusů o zneužití serverů.
Děkujeme za pochopení
funkci eval pouziva napr. php obfuscator, tedy placeny skript/aplikace, ktera zabezpeci php aplikaci pred kradezi nebo preprodavanim hotoveho produktu za zady programatora, zvlast u studenta jako jsem ja je to dulezite, protoze pri nizkem vydelku je potreba minimalizovat ztratu a zajistit tak budouci vyvoj a podporu, jsem rad, ze k zakazani teto funkce nedoslo