Интересные вопросы по настройке защиты от шелл

[Limitless]

Используйте safemode в php

Большинство CMS не работают в safe_mode.

Для просмотра ссылки Войди или Зарегистрируйся :

**я, да ты серьезно?

+1​

 

[kam1kaze]

И так, сегодня в чате разгорелась битва между мной и Limitless. Последний утверждал, что защита от шелл - элементарная задача. И так, конкурс на IQ и звание лучшего админа нулледа (зы, надо Гризу предложить медальки ввести на форуме ).


Вопрос второй:
Имеется CMS, в которой есть менеджер файлов. Файлики можно загружать на сервер, удалять, перемещать. Короче, стандартно для 99% CMS. Так получилось, что в нём нашлась уязвимость и человек залил шелл. Куда и название мы не знаем. Задача: запретить шелу показывать листинги директорий так, чтобы CMS продолжила показывать листинги и удалять/редактировать файлы.

Ваши самые интересные предложения будем обсуждать детально

Судя по треду, то необходимы какие-то средства широкого спектра действия (шаред хостинг, нельзя трогать окружение пользователя).
Предотвращаем попадание файлов на сервер:
- mod_security + clamav с внешними базами (Для просмотра ссылки Войди или Зарегистрируйся).
Если файл уже на серверe:
- запрещаем/логируем выполнение шелл команд (Для просмотра ссылки Войди или Зарегистрируйся)
- поднимает устойчивость PHP disable_functions (Для просмотра ссылки Войди или Зарегистрируйся) и т.п. функции
90% ботов и скрипткидов идут лесом

Теперь немного коней в вакуме. Если допустить, что шелл это всегда отдельный PHP скрипт, а валидные PHP файлы используются для наращивания CMS функционала (include* + require*). То можно выставлять execution bit для загружаемый файлов (mod_sec - SecUploadKeepFiles, umask) и запретить выполнять PHP скрипты с execution bit (у SuPHP из коробки такое поведение, для FCGI можно простой врапер сделать, для mod_php - хз)

 

[Горбушка]

exec()
system()
shell_exec()
passthru()

Не обсуждаемо, заблокировано на 99,999999% шаредов.

Речь шла об защите от шелов на базе PHP с использованием функций работы с папками и файлами.

 

[kam1kaze]

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

 

[Горбушка]

Мы - администратор, защищаем рядового юзера, к которому залили могут задить шелл. При этом мы не знаем какая CMS и т.д.

 

[olivok]

Вот такую штуку рекомендую посмотреть Для просмотра ссылки Войди или Зарегистрируйся, там и mod_security, и проверка clamav'ом с хорошими базами всего трафика по FTP/HTTP, и рулесы для OSSEC ну и всякие другие плюшки за разумные деньги.

 

[ask0n]

Судя по треду, то необходимы какие-то средства широкого спектра действия (шаред хостинг, нельзя трогать окружение пользователя).
Предотвращаем попадание файлов на сервер:
- mod_security + clamav с внешними базами (Для просмотра ссылки Войди или Зарегистрируйся).
Если файл уже на серверe:
- запрещаем/логируем выполнение шелл команд (Для просмотра ссылки Войди или Зарегистрируйся)
- поднимает устойчивость PHP disable_functions (Для просмотра ссылки Войди или Зарегистрируйся) и т.п. функции
90% ботов и скрипткидов идут лесом

Теперь немного коней в вакуме. Если допустить, что шелл это всегда отдельный PHP скрипт, а валидные PHP файлы используются для наращивания CMS функционала (include* + require*). То можно выставлять execution bit для загружаемый файлов (mod_sec - SecUploadKeepFiles, umask) и запретить выполнять PHP скрипты с execution bit (у SuPHP из коробки такое поведение, для FCGI можно простой врапер сделать, для mod_php - хз)

mod_security и clamav спасут нас от такого:

$_REQUEST['func_name']($_REQUEST['argument']);

?