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

Posted by alex on Jan 31, 2011 in Security |

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


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

Никогда, вы слышите? Никогда! не следуйте инструкциям с интернета (книжек и вообще любых источников) и особенно форумным советам (вы же еще не забыли знаменитый однострок на 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, насколько я помню, для этой цели нужно править исходник.
  • В php.ini так же есть возможность урезать отображаемую информацию

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

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

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

Никогда не выставляйте права 777 на файлы cms’ок (да и вообще они крайне редко нужны). Это совершенно ни к чему, даже несмотря на повальное требование к таким правам у некоторых горе-кодеров. На php-шном хостинге вполне достаточно 644 для файлов и 755 для директорий. И раздел, где лежат файлы сайтов вообще лучше монтировать с noexec.
hint:find /path/to/dir -type f -exec chmod 644 {} \;
Да и вообще неплохо бы четко понимать, нужны ли выставляемые права файлу или нет.

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

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

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

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

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

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

Источник: http://habrahabr.ru/

Copyright © 2018 Заметки по UNIX All rights reserved.
Desk Mess Mirrored v1.4.3.1 theme from BuyNowShop.com.