Linux за българи: Форуми

Проблема е че съм пуснал safe_mode , safe_mode_gid, спрял съм опасните функции,register_globals, magic_quotes_gpc, magic_quotes_runtime, allow_url_fopen, allow_url_include са спрени, apache security module е пуснат, но c99 работи. Къде е грешката?

Благодаря предварително

http://php.net/manual/en/install.fpm.php

Разгледай това - конкретно те интересува FPM да се изпълнява от конкретните потребители.

Нека имаме потребител А с достъп до неговата си папка и потребител Б с достъп до неговата си папка. Предполагам че в момента Apache достъпва всичко, НООООО под потребителя apache, www-data или там който дойде и има повечко права.

Когато направиш fpm ще кажеш - всички заявки на потребител А ще се изпълняват под правомощията на потребител А; ако дойде нещо за Б го изпълни като Б. И тогава нямаш достъп до по-интересните неща които имаш достъп в момента... Даже потребителите няма да могат да си виждат файловете един на друг.

Съжалявам, грешно съм се изразил, под хост имах предвид лично мой, само мои файлове се съхраняват вътре, няма други сайтове вътре.

П.П Направил съм апаче на работи с user и group apache

нали обясних по-горе. когато се използва като apache е опасно; когато е като обикновен потребител доста по-малко

еее... ако файловете са на СЪЩИЯ потребител трябва да си имат достъп

Проблема е че съм пуснал safe_mode , safe_mode_gid, спрял съм опасните функции,register_globals, magic_quotes_gpc, magic_quotes_runtime, allow_url_fopen, allow_url_include са спрени, apache security module е пуснат, но c99 работи. Къде е грешката?

Благодаря предварително

при мен съм спрял и тези:
exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

Не може да се направи невъзможно използването на PHP webshell-ове с текущо наличните инструменти и практики, когато в сървъра има работещо PHP, което трябва да може да се използва от сайтовете, хоствани на този сървър, ако се остави дупка, през която атакуващият може да качи PHP webshell. Може да се ограничи средата, до която биха имали достъп, но колкото и да се ограничи с текущите инструменти и практики, наличната среда винаги е достатъчна за поразии. Ако в кода на сайтовете няма дупки и не се допусне неоторизиран достъп през FTP, SSH и т.н., това е достатъчно за защита от PHP webshell-ове, но проблемът е, че това никога не може да се гарантира. PHP webshell-овете са просто PHP код, използващ съвсем стандартни функции в PHP, повечето от които се ползват в почти всеки PHP сайт, изключая от това основно системни функции като exec(), system(), shell_exec() и някои, имащи общо с тяхната насоченост, функции, но понякога и те са нужни в някои PHP сайтове за някои по-специфични, но полезни и напълно нормални нужди. Може да се забранят всички функции в PHP, които не се ползват от сайтовете, но винаги ще останат достатъчно активни функции, които биха свършили добра работа на атакуващия (ако ще да са дори само функциите за връзка с базата данни). Така че нито забрана на PHP функции, нито ограничаване диапазона във файловата система, до която потребителят има достъп, са достатъчни за спасение от поразии с PHP webshell-ове.

Мога да ти предложа една идея за частична защита от PHP webshell-ове - да автентикираш всеки от файловете, съдържащи програмен код, с парола. Т.е., слагаш един ред с таен стринг (удовлетворяващо дълъг и богат на разнообразни символи) в PHP файловете на сайта, например

GeSHi (PHP):
//b8dg*&bG&*F(c7O9S(L&*(H&*(

вписваш нещо подобно в .htaccess

RewriteEngine On
RewriteCond %{SCRIPT_FILENAME} (.*).php
RewriteCond %{SCRIPT_FILENAME} !mychecker.php
RewriteRule ^(.*)$ mychecker.php [L]

целта на което е да препраща всички заявки към PHP файлове, имената на които са различни от mychecker.php, към този файл mychecker.php, а във въпросния файл mychecker.php слагаш нещо подобно

GeSHi (PHP):
<?php
 
$secretString = 'b8dg*&bG&*F(c7O9S(L&*(H&*(';
 
$requestedFile = './'.array_shift(explode('?', basename($_SERVER['REQUEST_URI'])));
 
$contents = file_get_contents($requestedFile);
 
$pattern = preg_quote($secretString, '/');
$pattern = "/^.*$pattern.*\$/m";
 
if (preg_match_all($pattern, $contents, $matches)){
    include($requestedFile);
}
 
?>

с което, когато бъдеш пренасочен към този файл, той ще проверява съдържанието на оригинално извикания файл и, ако намери търсения стринг, ще include-ва извикания файл. Демек, в браузъра извикваш файла index.php, при което .htaccess те препраща към mychecker.php, за да бъде проверено дали файлът index.php съдържа тайния стринг и, ако го съдържа, се зарежда съдържанието на index.php. Така например, ако някой качи в сайта ти PHP webshell през някаква дупка в някоя upload форма, тъй като атакуващият няма да знае за този таен стринг, ще качи файла с PHP webshell-а без него и когато се опита да го извика, ще бъде пренасочен към mychecker.php, който няма да открие нужния стринг и няма да зареди файла с PHP webshell-а.
Това е една идея за защита от PHP webshell-ове, която ми хрумна наскоро и която е доста частична, за да може да се нарече решение за защита, но в много случаи е елементарна за вмъкване и може да даде поне спокойствието, че в сайта няма да бъде задействан PHP webshell, качен през някаква дупка в сайта или сървъра, стига атакуващият да не се добере до тайния стринг или да инжектира кода на PHP webshell-а директно в някой от файловете, които съдържат стринга. Занимавам се с хостинги отдавна и наблюденията ми са, че преобладаващите пакости по сайтовете са именно качени PHP webshell-ове през някаква стандартна дупка (я в upload форма, я вирус в клиентски компютър със запазена парола за S/FTP достъп...), при което атакуващият или не е имал възможност да види съдържанието на другите файлове, или въобще не си е направил труда за това, тъй като работата му е била вършена от бот, така че подобна защита може да свърши някаква работа, поне докато не стане достатъчно използвана, за да почнат атакуващите да обръщат внимание и на това. Досега съм споделял тази идея за защита само на няколко колеги, сега я казвам и публично, а е толкова елементарна като концепция, че със сигурност е хрумвала и ще хрумне на още много хора (даже се чудя как вече не се е изтъркала, вместо сега да говорим за нея), така че може и да не трае дълго ползата ѝ, но засега може да ти даде някакво спокойствие.
Разбира се, тъй като с така приложената автентикация на файловете с парола променяме пътя на четене на файловете, много сайтове биха се нуждаели от допълнителна корекция в кода на целия сайт, за да не се счупи работата на сайта. Най-лесно е със сайтове, които са написани така, че винаги всичко минава през index.php - тогава дори не е нужно да се прави отделен файл mychecker.php, а проверката може да се сложи в самия index.php, където да се проверява всеки include/require. Такъв например е случаят с публичната част на Wordpress - не позволяваш нищо друго да се зарежда там, всичко се насочва към index.php и си правиш проверките. Далеч обаче не е такъв случаят с административната част на Wordpress, където е едно голямо мазало... но няма невъзможни неща :)
Най-добра реализация на тази защита би могла да се постигне, ако не се прави с пренасочване към файл, който да прави проверките, ами се напише един PHP или Apache модул, който да върши тази работа. Тогава няма да е нужно никакво донагласяне на кода на никой сайт, ще е достатъчно само тайният стринг да се опише в конфигурацията на модула и във всички PHP файлове на сайта (което може да се направи и със скрипт за нула време) и всичко просто ще работи. Само дето аз все още не мога да пиша нито PHP, нито Apache, модули, така че не мога да предложа готово решение, но ако някой може да пише и идеята му се стори интересна, нека се чувства свободен да го предложи - нямам никакви претенции за нищо :)

Те ако ти вземат ftp паролата, тази защита просто се превръща в "защитата"...
Няма да е много трудно хахора да се сети да надникне в поне един файл от хостинга и да види за какво иде реч.
Според мен проблема е почти неразрешим, защото все пак ти работиш с клиенти.
И нямаш реален контрол над клиентите, така че те могат да си правят какви ли не неща, включително и качване на код с дупки в него (основната причина за webshell).

Така че според мен единственото (и то, частично) решение е, да се sandbox-не всеки един потребител. От там нататък е излишно всичко останало. PHP има достатъчно възможности да натоварва процесора макар и с орязани функции. Така че един потребител да бъде хакнат, може да коства производителността на останалите. А услугата като не отговаря, ще е все едно дали са хакнали теб или съседа...

Излишното усложняване няма смисъл, когато някой друг до теб може да реже клона, на който седите заедно... :)

Те ако ти вземат ftp паролата, тази защита просто се превръща в "защитата"...

Разбира се. Тази идея за защита е предимно допълнение към стандартните защити на upload форми, които се слагат за предпазване от качване и изпълнение на зловреден код през тях. Ако ти вземат FTP паролата, и стандартните защити на upload форми се превръщат просто в "защитите", но все пак е препоръчително да се слагат. То, ако ти вземат S/FTP паролата в някой споделен хостинг, дори и акаунтът да е в някакъв jail, в повечето случаи и забраната на определени PHP функции се превръща просто в "защитата", защото в повечето хостинги се дава възможност на клиентите да задават напълно или частично потребителски php.ini, но все пак се слагат някои забрани, ако не задължителни, то поне за по подразбиране. А ако ти вземат SFTP (демек, SSH) паролата, благодарение на някой exploit за jail-а, ядрото или нещо друго в системата всички защити могат да се превърнат просто в "защитите", но все пак е препоръчително да се слагат. Та така :)
Май не съм се изразил ясно одеве, та да кажа, че слагането на една защита само по себе си никога не обезсмисля друга. Както и възможността за заобикаляне на защитата само по себе си не прави дадената защита излишна. Както и, че никоя защита не е светая светих, така че никоя защита (и никой комплект от защити) не може да се счита за тотално предпазване от поразии. Колко и какви защити ще се сложат зависи само от личните предпочитания, нужди и познания на този, който го прави.