среда, 16 февраля 2011 г.

Базовые рекомендации для повышения безопасности *nix веб-сервера

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

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

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





Шаг нулевой. Отставить тупое следование инструкциям.


Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета (книжек и вообще любых источников) и особенно форумным советам (вы же еще не забыли знаменитый однострок на perl'e?). Даже если вы настраиваете веб-сервер по супер крутой статье от самих разработчиков apache и компилируете ядро по инструкции Линуса Торвальдса, помните, что людям свойственно ошибаться и никто не застрахован от опечаток и ошибок в инструкциях, которые могут привести к фатальным последствиям. Поэтому если вы что-то в инструкции не понимаете, то сначала следует разобраться, а потом делать.


Собственно без соблюдения этого пункта, вообще в IT лучше не соваться.



Шаг первый. Настройка удаленного доступа (ssh).


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

    Для параноиков можно реализовать port knocking (это когда мы порт с ssh по умолчанию закрыт и открывается только после того, как мы постучимся в определенный другой). Для совсем безнадежных параноиков можно выстроить цепочку из портов, в которые нужно стучаться.
  • Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
  • Явно задаем список пользователей, которым разрешено логиниться на сервер.
  • Ставим фильтр, который банит ipшники после, скажем, пяти неудачных попыток залогиниться (fail2ban, например).
  • (опционально, т.к. не всегда является возможным) Запрещаем логин по паролю и разрешаем ходить только по открытым ключам.




Шаг второй. Собственно сам веб-сервер.


В качестве веб-серверов преимущественно используется apache, либо apache+nginx, реже просто nginx, еще реже различные lighttpd, cherokee и прочее. Поэтому шаг относится в большей части все относится именно к apache и nginx.

  • Не пренебрегать open_basedir (многие просто его отключают, т.к. не могут с ним справиться: видят, что возникает ошибка из-за open_basedir и просто тут же его вырубают)
  • Ограничивать доступ по ip (либо по паролям) к важным объектам (если их не нужно показывать всем остальным посетителям) с помощью .htaccess (в apache) либо прямым указанием limit_except'ов (в nginx), а к некоторым вещам (например .htaccess) и вовсе запретить досутп по веб.
  • Скрыть версию используемого ПО. В apache это ServerSignature и ServerTokens, в nginx — server_tokens off; (upd от alxsad).
  • В php.ini так же есть возможность урезать отображаемую информацию
  • upd от edhell: так же отключаем опасные функции в php.ini (exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source, etc).




Шаг третий. Обновление ПО.


Своевременное обновление ПО на сервере — один из важнейших моментов. Лучше к тому же и подписаться на рассылку безопасности, дабы своевременно получать информацию об уязвимостях. Причем данный пункт относится не только к установленной unix-системе, но так же и исползуемым cms.



Шаг четвертый. Права.


Никогда не выставляйте права 777 на файлы cms'ок (да и вообще они, права 777, крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров. На php-шном хостинге вполне достаточно 644 для файлов и 755 для директорий. И раздел, где лежат файлы сайтов вообще лучше монтировать с noexec.


hint:find /path/to/dir -type f -exec chmod 644 {} \;

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



Шаг пятый. Мониторинг.


Необходимо настроить систему мониторинга с оповещением о нестандартном поведении (имеется в виду превышение установленных норм). Идеально подходит munin (легкий в настройке, удобно расширять функционал и графики красивые).

upd от gunya: csf + lfd — автоматически обнаруживает брутфорс, при флуде тоже помогает.



Шаг шестой и последний. Закрываем все неиспользуемые порты для внешнего доступа с помощью iptables.



Как правило, достаточно оставить открытыми порты для ssh + 80 и 443 для веб-сервера + порт для мониторинга. Собтсвенно все.

FTP не случайно отстуствует в этом списке, т.к., на мой взгляд, является небезопасным протоколом и для обмена файлами лучше использовать scp.

upd. от farcaller: Если пользователю не нужен shell, то его следует отключать, при предоставлении доступа для копирования файлов по ssh.



Ну и конечно же не стоит забывать, что пароли 123456 и qwerty использовать не стоит. Есть отличная утилитка для придумывания неплохих паролей:

$ apg -t -q -n 2

dickluer (dick-luer)


JicNeut3 (Jic-Neut-THREE)

$ apg -t -q -m 12 -a 1 -n 2

@%p-a^b`kI>R

dKYeK{7)E`Es





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

6 комментариев:

  1. интересно, спасибо за инфу

    ОтветитьУдалить
  2. А про win-серверы когда будет?

    ОтветитьУдалить
  3. Да, тоже жду про win-серверы

    ОтветитьУдалить
  4. Любопытно, завтра на работу притащу, попрактикуемся. А то ж у нас кошмар с безопасностью.

    ОтветитьУдалить