LINUX.ORG.RU

[php][BSD] Защита от взлома


0

2

Недавно попросили почистить веб-сервер. FreeBSD, Apache, MySQL, куча виртуальных сайтов на PHP.

В /tmp обнаружился выводок разнообразной гадости - скрипты на perl, python, php, один файл на C (явно неудачный выбор - должен был использовать старые уязвимости в ядре Linux, попал не по адресу).

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

Особой защиты на сервере не было. Отключил его от сети, настроил ipfw, закрыл все, что не нужно (то есть практически все - снаружи только 80 и 443). После подключения подозрительной активности не заметно.

В php не разбираюсь, но интересует вопрос - что нужно сказать разработчикам, куда их ткнуть носом (использование include, настройки php.ini - с учетом того, что используется CMS)? И что еще можно сделать для минимизации угроз?

★★

Ответ на: комментарий от hizel

Ага. Тем более, что http://www.linux.org.ru/forum/admin/5483675

...

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

KRoN73 ★★★★★ ()

Для начала посмотри на популярные дыры - SQL-injection, PHP-include. Чаще всего они и становятся началом взлома.

Viglim ()
Ответ на: комментарий от Viglim

> Для начала посмотри на популярные дыры

Похоже, эти дыры - просто стиль программирования (PHP-include уж точно) у тех, кто поддерживает сайты на обсуждаемом сервере.

oami ★★ ()
Ответ на: комментарий от oami

Самый верный способ - поотрывать руки быдлокодерам, которые так делают.

Viglim ()
Ответ на: комментарий от vostrik

Ясно. Тех php-кодеров, которые не знают о существовании рекомендаций по безопасности, не допускать на сервер :)

oami ★★ ()
Ответ на: комментарий от anton_jugatsu

Осталось, конечно. Для изучения заинтересованными лицами. Думаю, ничего секретного там нет, но лучше это поискать на соотвествующих сайтах.

oami ★★ ()
Ответ на: комментарий от anton_jugatsu

Ты сделай виртуалку, снаружи прокинь в неё 22 порт, а ней уже сделай какой-нибудь популявный аккант типа nobody открытым и без пароля. Я гарантирую, что такого добра у тебя в /tmp за пару дней накопится прилично :)

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

Rost ★★★★★ ()

Тут говорили, что, мол, можно запустить тысячи jail'ов без потери для производительности. Может поместить каждого пользователя в свой jail? Автоматизировать процесс обновления и жить абсолютно счастливо.

Enoch ()

Всякие гадости заливают и выполняют, как вы, надеюсь, понимаете, через наличие command execution тем или иным образом. Т.е., прежде всего, где-то в скриптах есть возможность залить .php скрипт - как любой другой файл или под видом картинки/CSS/шаблона, расширение правильно не проверяется и/или оставляется исходное имя файла. В некоторых случаях команду можно выполнить через модификацию того или иного шаблона прямо в админке, если CMS использует PHP в качестве шаблонизатора (привет, Joomla). А уж как подобную возможность злоумышленник получает - думайте сами, здесь вариантов множество.
Для минимизации угроз прежде всего должен быть нормальный код, не имеющий явных уязвимостей, и грамотно расставленные права на файлы/директории для предотвращения записи в них. В чём-то помогает установленный Suhosin патч.

frozen_twilight ★★ ()
Ответ на: комментарий от frozen_twilight

> Для минимизации угроз прежде всего должен быть нормальный код, не имеющий явных уязвимостей, и грамотно расставленные права на файлы/директории для предотвращения записи в них.

/tmp на запись закрыть вряд ли получится. В других местах все чисто.

А вот с «нормальным кодом» явно проблемы (и да, Joomla наверняка кем-то используется из тех, кто хостится на сервере).

oami ★★ ()
Ответ на: комментарий от oami

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

frozen_twilight ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.