Рекомендации по защите: Web-серверы. Linux
Web-серверы — неотъемлемая часть инфраструктуры практически любой компании. Они являются теми посредниками, с помощью которых функционирует ваш ресурс и неважно, сайт-визитка это или целая социальная сеть с количеством зарегистрированных пользователей более миллиона.
Естественно, при такой массовости данного класса ПО они часто становятся целью злоумышленников. При этом цели хакеров могут варьироваться от атак «for fun» до атак с целью перехвата трафика пользователей для получения критичной информации, номеров карт и прочего. Также целью может служить использование веб-сервера как «входной» точки в локальную сеть компании. Поэтому грамотная настройка безопасности — один из немаловажных этапов при развёртывании любого веб-ресурса. Далее мы коснёмся общих настроек наиболее часто используемых серверов на ОС Linux: Apache и nginx. Меры, предлагаемые в данной статье, применимы и к другим серверам, хотя их конфигурация будет отличаться.
Обратите внимание: в тексте мы не будем рассматривать анализ кода самого веб-ресурса, настройку DMZ для веб-сервера, а также конфигурацию прочих сервисов, таких как SSH, о настройке которого можно прочитать здесь. Но если вы хотите повысить безопасность вашей компании, не игнорируйте все эти меры!
Рекомендации по защите
1. Обновляйтесь. Несмотря на то, что данная рекомендация звучит везде и всегда, почему-то до сих пор ею пренебрегают. И часто именно несвоевременное обновление приводит к крайне печальным последствиям.
2. Изолируйте работу веб-сервера, если это возможно. Docker или chroot — отличный способ оградить ПО и не дать злоумышленнику проникнуть дальше в систему в случае компрометации. Не забывайте, что в обоих случаях в контейнере/chroot-системе должен быть «минимум» ПО: если какая-то утилита не нужна, то она должна быть вырезана. И данная мера не поможет, если была скомпрометирована основная система, а не веб-сервер.
3. Удалите «дефолтный» контент. Он служит только для диагностики того, что веб-сервер запустился и работает. А злоумышленнику он поможет узнать, какое ПО используется.
4. Уменьшите информацию, возвращаемую сервером.
# Apache: ServerTokens Prod ServerSignature Off 5. Составьте список модулей, которые вам действительно необходимы, остальные же требуется удалить. Например, если ваш сервис не подразумевает управление файлами для клиентов, смело комментируйте нужные строки c модулем WebDAV в файле конфигурации
httpd.conf (Apache): ##LoadModule dav_module modules/mod_dav.so ##LoadModule dav_fs_module modules/mod_dav_fs.so Другой пример — autoindex, позволяющий автоматически создать структуру директорий. Рекомендуется делать это вручную, оставив только необходимые файлы и папки. Для отключения необходимо закомментировать следующие строки:
## LoadModule autoindex_module modules/mod_autoindex.so Из подобных модулей для Apache вас могут заинтересовать mod_userdir, mod_status, mod_info и прочие. Для nginx подобными модулями могут быть http_autoindex_module или http_ssi_module.
Чтобы просмотреть список доступных модулей, необходимо ввести команду:
#nginx: nginx -V 2>&1|xargs -n1|grep module #Apache: httpd –M / apachectl –M / apache2 –M / apache2ctl –M # в зависимости от ОС, подойдёт одна из перечисленных. 6. Отключайте ненужные опции для директорий. В директории нет исполняемого контента? Отключайте ExecCGI. Не требуется FollowSymlinks? Смело удаляйте. А если опция все же требуется, смотрите на SymLinksIfOwnerMatch.
7. Настройте фильтры для файлов. Здесь каждая настройка уникальна, суть её сводится к тому, чтобы пользователь мог получать доступ только к тем файлам, которые ему необходимы. Таким образом, можно заблокировать выполнение PHP в различных директориях, доступ к служебным папкам и прочее.
8. Внимательно проверяйте CGI. У CGI довольно богатая история, связанная с различными инцидентами безопасности. И даже несмотря на то, что сейчас он считается относительно безопасным, рекомендуется удалять скрипты, которые вам не требуются и которые могут привести к неожиданным последствиям. Такими, например, являются printenv и test-cgi.
9. Отключите неиспользуемые HTTP-методы. Trace, который часто используется при дебаге, в продуктивной среде может привести к получению cookie сторонним лицом, а выключить его зачастую забывают. Для отключения следует добавить в конфигурацию следующие строки:
#nginx: if ($request_method !~ ^(GET|HEAD|POST|PATCH)$ )
#Apache: TraceEnable off # В конфигурации сервера … Require all denied 10. Отключайте старые версии HTTP. Версии ранее 1.1 не должны поддерживаться, а на текущий момент происходит миграция на более быстрый HTTP/2. Старые и некорректные версии HTTP позволяют отследить специальные модули для web-серверов, повышающие безопасность, о которых будет сказано далее.
11. Отключите доступ к сайту по IP. Большинство обычных пользователей подключаются к сайту по доменному имени, в то время как сканеры, анализирующие веб в поисках уязвимого софта, «идут» по IP-адресам.
#Apache: ServerName www.yoursite.ru #nginx: server < server_name www.yoursite.ru; >Также в некоторых случаях возможно использование редиректа, например: Redirect permanent / www.yoursite.ru 12. Указывайте конкретный IP-адрес, на котором веб-сервер должен обслуживать клиентов. Это избавит от проблем, вызванных добавлением новых интерфейсов и отсутствием либо некорректной настройкой межсетевого экрана.
#Apache: Listen 10.10.10.10:80 Listen [2001:11d8:1311:0:a221:18:e416:cb11]:80 Базовые рекомендации для повышения безопасности *nix веб-сервера
Вдохновившись статьей о поиске следов взлома, решил написать статью о предупреждении взлома и базовых шагах для сведения возможности взлома сервера к минимуму.
Все шаги крайне важны, и невозможно выделить самый-самый важный, либо второстепенный.
Данная статья не является пошаговой инструкцией, а лишь списком рекомендуемых шагов.
Шаг нулевой. Отставить тупое следование инструкциям.
Никогда, вы слышите? Никогда! без полного понимания того, что произойдет от совершаемых действий, не следуйте инструкциям с интернета (книжек и вообще любых источников) и особенно форумным советам (вы же еще не забыли знаменитый однострок на perl’e?). Даже если вы настраиваете веб-сервер по супер крутой статье от самих разработчиков apache и компилируете ядро по инструкции Линуса Торвальдса, помните, что людям свойственно ошибаться и никто не застрахован от опечаток и ошибок в инструкциях, которые могут привести к фатальным последствиям. Поэтому если вы что-то в инструкции не понимаете, то сначала следует разобраться, а потом делать.
Собственно без соблюдения этого пункта, вообще в IT лучше не соваться.
Шаг первый. Настройка удаленного доступа (ssh).
- Перевешиваем ssh на нестандартный порт. От злоумышленника, решившего во чтобы то не стало взломать ваш сервер, это не спасет, однако мы избавимся от кучи ломящихся ботов и в логах найти нужную строчку будет гораздо проще, если вдруг что.
Для параноиков можно реализовать port knocking (это когда мы порт с ssh по умолчанию закрыт и открывается только после того, как мы постучимся в определенный другой). Для совсем безнадежных параноиков можно выстроить цепочку из портов, в которые нужно стучаться. - Запрещаем логин от рута (по умолчанию он, как ни странно, разрешен).
- Явно задаем список пользователей, которым разрешено логиниться на сервер.
- Ставим фильтр, который банит ipшники после, скажем, пяти неудачных попыток залогиниться (fail2ban, например).
- (опционально, т.к. не всегда является возможным) Запрещаем логин по паролю и разрешаем ходить только по открытым ключам.
Шаг второй. Собственно сам веб-сервер.
- Не пренебрегать 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
Все это не является в полной мере исчерпывающей информацией по вопросу безопасности, но даже при соблюдении лишь этих пунктов, подобраться к вам будет значительно сложнее.