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

[Горбушка]

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

И так, вопрос первый:
У нас имеется 2 файла PHP с неизвестными именами (для простоты понимания 1.php и 2.php), находятся в 1 папке, оба залиты через FTP одним человеком. Так же у нас есть некий 3-ий файл, имя которого известно (пусть будет 3.php), который лежит в папке folder. Задача: дать права чтение/запись файла 3.php файлу 1.php так, чтобы файл 2.php не получил такие же права. Напомню, имена файлов 1.php и 2.php неизвестны, юзер заливал их сам => владелец/группа у них одинаковые.

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

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

 

[Limitless]

Задача: дать права чтение/запись файла 3.php файлу 1.php так, чтобы файл 2.php не получил такие же права.

Задача невыполнима. Но, можно сделать так чтобы запустив файл 1.php не было доступа на чтение 2.php и 3.php и на создание файлов/директорий (именно об этом я и говорил).

Так получилось, что в нём нашлась уязвимость и человек залил шелл.

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

Задача: запретить шелу показывать листинги директорий так, чтобы CMS продолжила показывать листинги и удалять/редактировать файлы.

Если убрать функции листинга то и CMS не сможет его смотреть, удалять/редактировать файлы = опять же настройка прав и конфига apache. А вообще листинг очень редко используется и на мой взгляд потенциальная опасность, да и для работы с файлами есть фтп.

P.S. Видимо мы не совсем поняли друг-друга в нашей дискуссии.

 

[Цукер]

Идем в PHP.INI - auto_prepend_file добовляем срипт который будет проверять куки админа CMS и собственно делать die() если таких куков нет... зачем с правами замарачиваться? главное чтоб php и апач не о рута были)))

 

[Limitless]

Идем в PHP.INI - auto_prepend_file добовляем срипт который будет проверять куки админа CMS и собственно делать die() если таких куков нет... зачем с правами замарачиваться? главное чтоб php и апач не о рута были)))

Не вариант, при бажном движке вполне можно получить права админа.

 

[Горбушка]

Limitless, ответ верный, о чём в чате уже договорились =) Действительно, просто не поняли друг друга.

Идем в PHP.INI - auto_prepend_file добовляем срипт который будет проверять куки админа CMS и собственно делать die() если таких куков нет... зачем с правами замарачиваться? главное чтоб php и апач не о рута были)))

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

Тут кто-то высказывал ещё варианты:
В папке с "аплодами" ставим запрет на ПХП - верно, но уязвимость в движке может дать доступ выше этой папки
В папках, кроме "аплод" запретить запись - не верно, ибо мы не знаем имена файлов и т.д. И опять же, не должны вмешиваться в работу CMS. Кроме того, это запретит править конфиг CMS'ки из админ-панели
...

 

[Limitless]

В папке с "аплодами" ставим запрет на ПХП - верно, но уязвимость в движке может дать доступ выше этой папки

Права.

В папках, кроме "аплод" запретить запись - не верно, ибо мы не знаем имена файлов и т.д. И опять же, не должны вмешиваться в работу CMS. Кроме того, это запретит править конфиг CMS'ки из админ-панели

Причем здесь "имена файлов" ? Зачем CMS редактирование PHP-файлов с веба? Для этого есть фтп.

Редактирование каких либо файлов с админки - это конечно удобно, но в тоже время и потенциальная уязвимость.

 

[Горбушка]

Причем здесь "имена файлов" ? Зачем CMS редактирование PHP-файлов с веба? Для этого есть фтп..

Если ты поставишь права 111 - хоть с FTP, хоть с веба ты ничего не сделаешь с ним, пока не вернёшь права...

Кстати, защита CHMOD от шелла - тупо. Никто не мешает выполнить команду chmod из PHP и вернуть нужные права =))

 

[Limitless]

Если ты поставишь права 111 - хоть с FTP, хоть с веба ты ничего не сделаешь с ним, пока не вернёшь права...

Кстати, защита CHMOD от шелла - тупо. Никто не мешает выполнить команду chmod из PHP и вернуть нужные права =))

Apache работает по дефолту от daemon/daemon, то бишь, если файл "1.php" (шелл) с правами root/root в папке скажем "folder" (chmod 755) запустить с веба он не сможет редактировать даже себя (1.php), а уж тем более создавать файлы в папке. А вот если зайти с фтп, которое работает не от прав daemon/daemon будет совсем другая история.

Совсем не тупо. Для начала нужно залить шелл, а в папке "upload" отключен пхп. Даже если шелл получилось залить (что маловероятно) то с правами daemon/daemon много не выполнишь.

 

[Василий Иванченко]

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

 

[smalllamer]

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

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