02 июля 2018

Рекомендации по защите: Web-серверы. Linux

Общая информация об угрозе

Web-серверы — неотъемлемая часть инфраструктуры практически любой компании. Они являются теми посредниками, с помощью которых функционирует ваш ресурс и неважно, сайт-визитка это или целая социальная сеть с количеством зарегистрированных пользователей более миллиона.
Естественно, при такой массовости данного класса ПО они часто становятся целью злоумышленников. При этом цели хакеров могут варьироваться от атак «for fun» до атак с целью перехвата трафика пользователей для получения критичной информации, номеров карт и прочего. Также целью может служить использование веб-сервера как «входной» точки в локальную сеть компании. Поэтому грамотная настройка безопасности — один из немаловажных этапов при развёртывании любого веб-ресурса. Далее мы коснёмся общих настроек наиболее часто используемых серверов на ОС Linux: Apache и nginx. Меры, предлагаемые в данной статье, применимы и к другим серверам, хотя их конфигурация будет отличаться.
Обратите внимание: в тексте мы не будем рассматривать анализ кода самого веб-ресурса, настройку DMZ для веб-сервера, а также конфигурацию прочих сервисов, таких как SSH, о настройке которого можно прочитать здесь. Но если вы хотите повысить безопасность вашей компании,  не игнорируйте все эти меры!

Рекомендации по защите

1. Обновляйтесь. Несмотря на то, что данная рекомендация звучит везде и всегда, почему-то до сих пор ею пренебрегают. И часто именно несвоевременное обновление приводит к крайне печальным последствиям.

2. Изолируйте работу веб-сервера, если это возможно. Docker или chroot — отличный способ оградить ПО и не дать злоумышленнику проникнуть дальше в систему в случае компрометации. Не забывайте, что в обоих случаях в контейнере/chroot-системе должен быть «минимум» ПО: если какая-то утилита не нужна, то она должна быть вырезана. И данная мера не поможет, если была скомпрометирована основная система, а не веб-сервер.

3. Удалите «дефолтный» контент. Он служит только для диагностики того, что веб-сервер запустился и работает. А злоумышленнику он поможет узнать, какое ПО используется.

4. Уменьшите информацию, возвращаемую сервером.

# Apache:
ServerTokens Prod
ServerSignature Off



# nginx:
server_tokens 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)$ )
{
	return 444;
}



#Apache: 
TraceEnable off # В конфигурации сервера
 …
<LimitExcept GET POST PATCH OPTIONS>
Require all denied
</LimitExcept>

10. Отключайте старые версии HTTP. Версии ранее 1.1 не должны поддерживаться, а на текущий момент происходит миграция на более быстрый HTTP/2. Старые и некорректные версии HTTP позволяют отследить специальные модули для web-серверов, повышающие безопасность, о которых будет сказано далее.

11. Отключите доступ к сайту по IP. Большинство обычных пользователей подключаются к сайту по доменному имени, в то время как сканеры, анализирующие веб в поисках уязвимого софта, «идут» по IP-адресам.

#Apache:
<VirtualHost www.yoursite.ru:80>
ServerName www.yoursite.ru
</VirtualHost>


#nginx:
server {
    server_name www.yoursite.ru;
 }
Также в некоторых случаях возможно использование редиректа, например:
<VirtualHost www.yoursite.ru:80>
Redirect permanent / www.yoursite.ru
</VirtualHost>

12. Указывайте конкретный IP-адрес, на котором веб-сервер должен обслуживать клиентов. Это избавит от проблем, вызванных добавлением новых интерфейсов и отсутствием либо некорректной настройкой межсетевого экрана.

#Apache: 
Listen 10.10.10.10:80
Listen [2001:11d8:1311:0:a221:18:e416:cb11]:80



#nginx:
listen       10.10.10.10:80;

13. Защищаемся от clickjacking, атак с подменой MIME и XSS. Для этого достаточно установить необходимые опции в конфигурации веб-сервера.

#Apache (httpd.conf):
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection "1; mode=block"



#nginx (nginx.conf):
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

14. Content Security Policy. Полезная опция, защищающая от некоторых атак, например, ряда XSS или Code Injection. Для каждого сервиса требуется уникальная настройка, где следует указать, с каких доменов разрешено загружать различный контент, будь то скрипты сбора статистики или изображения. Как пример, настройка CSP, позволяющая загружать скрипты и картинки с серверов Google Analytics, выглядит так:

Content-Security-Policy: script-src www.google-analytics.com; img-src www.google-analytics.com
15. Защитите веб-сервер от DoS/DDoS атак. Смотрите рекомендации по защите от DoS и DDoS атак.

16. HTTPS/HTTP Strict Transport Security. Настройте и используйте шифрование, откажитесь от HTTP. Используйте TLS не ниже v1.2. При настройке обратите внимание на используемые алгоритмы, некоторые из них уже устарели и признаны ненадежными. Среди таких: SHA-1, RC4, DES, 3DES, AES-CBC, MD5. Актуальными на текущий момент являются (06.2018) ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305, ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA384, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA256. Список актуальных шифров можно посмотреть тут. Также следует настроить HSTS, перенаправляющий весь трафик по шифрованному каналу:

#Apache:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"



#nginx:
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

17. После настройки шифрования необходимо обезопасить файлы cookie, для чего требуется включить опции secure (для передачи только по HTTPS) и httpOnly (что обеспечит защиту от XSS). Хотя это возможно настроить и в web-серверах при помощи специальных модулей, рекомендуется всё же провести нужную конфигурацию в коде приложения.

18. Проверьте, что ведётся запись журналов доступа и журналов ошибок:

#Apache:
ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common


#nginx:
access_log /var/log/yoursite_access.log;
error_log /var/log/yoursite_error.log error;

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

19. Отдельно стоит отметить модуль, предназначенный для повышения безопасности: mod_security. Существует исполнение как для Apache, так и для nginx. Данный модуль выполняет как ряд приведенных выше мер защиты, так и добавляет различный функционал, свойственный WAF. В связи с тем, что модуль постоянно развивается, рекомендуется тщательно изучить документацию для его актуальной настройки.

Действия в случае инцидента

В первую очередь, необходимо понять, каким образом действовал злоумышленник. Получил ли он доступ к веб-серверу в результате взлома ОС? Или же какая-то уязвимость/недоработка присутствует в самом сервере? А, может быть, уязвим код веб-приложения? Во всех ситуациях алгоритм последующих действий индивидуален.
Общие шаги следующие:

1. Определите уязвимую точку входа, не дайте злоумышленнику повторно взломать вашу инфраструктуру.

2. Выявите, что именно делал хакер после попадания на сервер. Может случиться так, что, закрыв дыры на веб-сервере, мы пропустим мимо внимания ботнет, который появился на других машинах. Проверить можно при помощи журналов. Но лучше иметь какое-либо средство агрегации и мониторинга логов со всех систем, либо же использовать SOC, который позволит выявить инцидент «на лету».

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