​​Мне на днях в комментариях подсказали полезный сайт на тему безопасности. Раньше про него не слышал. Я обычно все рекомендации в общую очередь постов ставлю, где они чаще всего несколько месяцев проводят и при моём повторном внимании с подтверждением полезности оформляются в отдельную публикацию. А тут решил сразу изучить и написать, потому что сайт очень понравился.

Речь пойдёт про workbench.cisecurity.org (CIS — Center for Internet Security). Это некоммерческая организация, которая разрабатывает собственные рекомендации по обеспечению безопасности различных систем. Там представлены как настройки различных операционных систем (win, lin, macos и т.д.) и готовых продуктов на их основе (sophos, pfsense и т.д.), так и одиночных программ (nginx, apache, mysql, elasticsearch, mongodb и т.д.)

При этом рекомендации максимально подробные с описанием конкретных действий, которые надо сделать, вектором атак и общей теории по проблеме. Например, есть какая-то ОС Linux. Есть рекомендация отключить поддержку всех неиспользуемых файловых систем. И сразу представлены команды, как посмотреть, какие фс поддерживаются и как выгрузить модули ядра, которые осуществляют поддержку. Всё очень понятно и подробно.

Я посмотрел некоторые документы по системам и программам, которые сам использую. Очень понравилась подача. Увидел некоторые вещи, про которые даже не слышал раньше. Появилось большое желание что-то нужное мне перевести, сократить и оформить в короткие рекомендации. Но не знаю, как получится. На это надо много времени. Документы на сайте CIS очень объёмные. С одной стороны это хорошо, если хочешь подробно изучить тему, а с другой плохо, потому что если тебе нужно только выполнить основные рекомендации, без детального погружения, ничего не выйдет. А не всем и не всегда нужно изучать материал на уровне специалиста по безопасности.

Для примера скачал и выложил 3 документа оттуда по настройке Debian 11, Nginx, PostgreSQL 15.
⇨ https://disk.yandex.ru/d/P1Ph7IvUKHmnKQ

#security #cis

​​На днях писал про CIS. Решил не откладывать задачу и проработать документ с рекомендациями по Nginx. Делюсь с вами краткой выжимкой. Я буду брать более ли менее актуальные рекомендации для среднетиповых веб серверов. Например, отключать все лишние модули и делать свою сборку в обход готовых пакетов я не вижу для себя смыла.

📌Проверяем наличие настройки autoindex. В большинстве случаев она не нужна. С её помощью работает автоматический обзор содержимого директорий, если в них напрямую зайти, минуя конкретный или индексный файл.
# egrep -i '^\s*autoindex\s+' /etc/nginx/nginx.conf 
# egrep -i '^\s*autoindex\s+' /etc/nginx/conf.d/*
# egrep -i '^\s*autoindex\s+' /etc/nginx/sites-available/*
Не должно быть настройки autoindex on. Если увидите, отключите.

📌Обращения на несуществующие домены или по ip адресу лучше сразу отклонять. По умолчанию отдаётся приветственная страница. Проверить можно так:
# curl -k -v https://127.0.0.1 -H 'Host: invalid.host.com'
Если в ответ показывает приветственную страницу или что-то отличное от 404, то надо добавить в самую первую секцию server следующие настройки:
server { 
return 404;
}
Можно просто удалить конфиг с дефолтным хостом, а приведённый код добавить в основной nginx.conf. Тогда это точно будет первая секция server. В остальных секциях server везде должны быть явно указаны server_name.

📌Параметр keep-alive timeout имеет смысл сделать 10 секунд или меньше. По умолчанию он не указан и им управляет подключающийся.
keepalive_timeout 10;
То же самое имеет смысл сделать для send_timeout.
send_timeout 10;

Скрываем версию сервера параметром server_tokens. Проверяем так:
# curl -I 127.0.0.1 | grep -i server
Отключаем:
server {
...
server_tokens    off;
... 
}

📌Дефолтные страницы index.html и error page лучше отредактировать, удалив всё лишнее. Обычно они хранятся в директориях /usr/share/nginx/html или /var/www/html.

📌Запрещаем доступ к скрытым файлам и директориям, начинающимся с точки. Для этого в добавляем в самое начало виртуального хоста location:
location ~ /\. { deny all; return 404; }
Если нужно исключение, например для директории .well-known, которую использует let's encrypt для выпуска сертификатов, то добавьте его выше предыдущего правила.
location ~ /\.well-known\/acme-challenge { allow all; }

📌Скрываем proxy headers. Добавляем в location:
location /docs {
....
proxy_hide_header X-Powered-By; 
proxy_hide_header Server;
.... 
}

📌Не забываем про настройку логирования. Логи нужны, но настройка сильно индивидуальна. Если логи хранятся локально, то обязательно настроить ротацию не только с привязкой ко времени, но и к занимаемому объёму. В идеале, логи должны храниться где-то удалённо без доступа к ним с веб сервера.

📌Настраиваем передачу реального IP адреса клиента в режиме работы Nginx в качестве прокси.
server {
...
location / {
proxy_pass 127.0.0.1:8080);
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
}
}

📌Ограничиваем версию TLS только актуальными 1.2 и 1.3. Если используется режим проксирования, то надо убедиться, что эти версии совпадают на прокси и на сервере. Если не уверены, что все ваши клиенты используют современные версии TLS, то оставьте поддержку более старых, но это не рекомендуется. Настройка для секции http в nginx.conf
ssl_protocols TLSv1.2 TLSv1.3;

📌Настраиваем ssl_ciphers. Список нужно уточнять, вот пример из документа CIS:
ssl_ciphers ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!SSLv3:!MD5:!RC4;

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

Ничего особо нового в документе не увидел. Большую часть представленных настроек я и раньше всегда делал. В дополнение к этому материалу будет актуальна ссылка на предыдущую заметку по настройке Nginx. Надо будет всё свести в общий типовой конфиг для Nginx и опубликовать.

#cis #nginx #security