phpshell и защита от него!

Клиенты бегут? :)

Я Вам только что объяснил, как оно "будет работать". Вы видите толк от такой "работы" - я нет.

Если человек хочет, чтобы сайты были изолированы - пусть размещает их на разные аккаунты. Если же на один - вполне логично наоборот, что схема хостинга не изолирует эти сайты друг от друга. В частности, они могут код друг друга использовать - ISP тут ставит даже open_basedir общий.

Проблема простая - отсутствие документации для пользователей. Вот они и ждут чудес.

А голову сами Вы не используете? Вы должны понимать - это эвристика. Нет никаких точных алгоритмов для выявления "плохих" запросов. Вы будете фильтровать их по подстрокам, регулярным выражениям и т.п.

Если уже получили рут-доступ - я Вам не советую подобной ерундой ограничиваться. Возможностей оставить себе лазейку в систему - вагон, так что это фиговый листок. Если к серверу получили root-доступ, тем более далеко не на пару минут - самый безопасный и дешевый путь это инсталяция сервера заново.

Вас не пугает необходимость сборки и сопровождения своего ядра? Тем более, что grsecurity поддерживает версию ядра сильно отличающуюся от centos.

open_basedir вообще не спасёт от php_shell. Он никак не ограничивает shell-функции, только что работа средствами самого php ограничена. А всякие shell_exec() вообще его игнорируют.

Вы про disable_functions у ТС забыли? Не к лицу Вам брать пример с Андрейки - Вы вроде обычно читаете посты автора топика.

Я ответил на ваше сообщение про basedir. "Букав" много в теме, поэтому действительно не прочитал целиком :)

Кстати, ещё и функциями ioncube loader можно открывать файлы в обход basedir :)

вот этот вариант очень уж мне понравился и по моему мнению (возможно ошибочному) закроет проблему , или почти закроет, но конечно же хочется понимать чем это чревато, прошу прокомментировать именно вариант использования grsec kernel на Centos , есть ли те кто применял такое решение именно на шеред хостинге и насколько это усложняет администрирование?

Да дырка это сплошная, все знают ;)

С другой стороны - лучше чем ничего. А во-вторых, для ограничения доступа к другим аккаунтам - у Вас есть механизмы посильнее open_basedir. Создалось впечатление, что об этом Вы забыли.

Нет, не закроет. Проблема - в том, что кто-то получил у Вас root-доступ (с Ваших слов). И пока Вы не разобрались как это было сделано и что конкретно хакер делал, обладая root-доступом - рано говорить о каких-то решениях.

Собрать свое ядро несложно. Хотя займет уйму времени в первый раз (в цикле: чтение документации -> конфигурация ядра -> сборка -> тестирование). Будьте также готовы к тому, что даже после продолжительного тестирования - использование ядра в продакшен выявит какие-то проблемы и придется начинать цикл заново.

Вам потребуется также самостоятельно следить за ошибками в ядре, закрывая новые уязвимости. Т.е. обновлять и longterm релиз (2.6.32) и grsecurity патч.

А что будет, когда Вы собрали и оттюнили себя ядро, исключив из него "все лишнее", а потом захотели его водрузить на новый хостинговый сервер? А он - оппа! - с совершенно другими комплектующими идет.

Я лишь рассказал, что я думаю об этом basedir =) Он скорее больше сайтам мешает работать нормально (скажем, если нужен доступ к утилитам типа convert и т.п.), чем даёт существенное преимущество с точки зрения безопасности. Я недавно освежал свои знания на тему "какие есть варианты доступа к системным файлам и файлам других юзеров", когда делал удит безопасности хостерам. Оказалось, что даже серьёзные компании часто такие глупые ошибки делают :)

myhand, клиенты бегут, только ЗП не растёт так как цены мизерные, всё для народа ;)

Как вариант, дать возможность включать пользователям open_basedir на любую директорию и вкл/выкл шелл функций, у меня это организовано. Но всё ещё предрассутки, что система не идеальна, а именно не хватает запрета для PHP/Perl на запись в пользовательские файлы с правами 644.

У "серьезных компаний" есть штат сотрудников, занимающихся как раз администрированием. И кого-то с "аудитом безопасности" туда просто не пустят ;) - Вы явно переоценили "серьезность" компании.

ТС, а защитить директории с помощью htaccess не получается?

Например такого вида:

<Files ~ "\.(php[2-5]?|cgi|pl|fcgi|fpl|phtml|shtml|asp|jsp|tx)$">

Ну, а в общем, дырки конечно нужно искать и затыкать.