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

Речь пойдёт про 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

​​Решил для себя проработать ещё один документ от CIS на тему MySQL сервера. Взял версию 5.7, как наиболее универсальный вариант. Честно сказать, документ вообще не впечатлил. Показался набором очевидных банальностей. Ничего для себя оттуда не вынес, но так как потратил довольно много времени на прочтение и разбор, решил всё же сделать небольшую подборку для вас о тех вещах, что мне показались сколько-нибудь полезными.

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

📌 Если есть возможность использовать аутентификацию пользователей через unix сокет, оставьте только её, а остальные виды отключите. Речь идёт про плагин auth_socket для mysql или unix_socket для mariadb. Удалённые подключения к mysql серверу для безопасности стоит настроить по tls с помощью сертификатов.

📌 Обязательно ограничьте запуск сервера конкретным IP адресом, на котором он должен быть доступен. Например так:
bind_address=192.168.11.3
Если используется внешний IP адрес, необходимо ограничить к нему доступ на уровне firewall.

📌 Если не используете символьные ссылки в файлах, с которыми работает сервер, то отключите их поддержку в my.cnf:
skip-symbolic-links = YES

📌 Настройте ведение лога ошибок:
log-error = /var/log/mysql/error.log

📌 При работе с mysql сервером через консольный клиент следует избегать ситуаций, когда пароль пользователя используется непосредственно в команде и остаётся в системной истории команд. Я, кстати, и сам так попадал, и на других серверах видел пароли mysql пользователей в истории bash. Стоит избегать вот таких конструкций:
# mysql -u admin -p password
Либо интерактивно вводите пароль, либо храните в отдельном файле .my.cnf с ограничением доступа.

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

💡Необходимо устанавливать все обновления, удалить все тестовые данные, если они есть. Проверить всех пользователей и их права. Особенно обратить внимание на права SUPER, PROCESS, CREATE USER, GRANT OPTION. Они должны быть только у административных пользователей.

💡Необходимо следить за бэкапами, за учётными записями, от имени которых они выполняются. Не забывать про binlog, если вам нужна возможность восстановления между полными бэкапами.

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

💡По возможности сервер должен быть изолирован от остальных служб на отдельной VPS или сервере.

#cis #mysql

​​Проработал ещё один документ по безопасной настройки от CIS. На этот раз на тему Apache 2.4. Изучил 217 😱 страниц документа и постарался сделать универсальную краткую выжимку для постоянного использования. Те параметры, что есть в рекомендациях, но по умолчанию уже настроены, я не упоминаю.

📌 Как обычно, первая рекомендация по настройке — проверить список модулей и отключить ненужные. В зависимости от дистрибутива, команда на запуск бинарника может быть разная. В Debian и Ubuntu — apache2ctl, в Centos и клонах — httpd или apachectl.
# apache2ctl -M
Описание модулей можно посмотреть в документации. Для отключения комментируем строку с LoadModule и именем модуля в конфигурационном файле. Здесь же стоит убедиться, что:
◽модуль логирования log_config_module загружен;
◽модули, связанные с webdav (имеют dav в названии), отключены, если не нужны.
◽модуль статистики status_module отключен, если не используется, либо настроен, чтобы исключить доступ к статистике посторонним.
◽модуль autoindex_module отключен, он позволяет выполнять листинг директорий с файлами, если не задана индексная страница (index.html и т.д.)
◽отключены модули проксирования (proxy в названии), если не используются;
◽отключён модуль mod_info, который выводит информацию о сервере;

📌 Не используйте модуль mod_auth_basic, если доступ к сайту по http. В этом случае учётные данные передаются по сети в открытом виде и могут быть перехвачены кем угодно по пути следования пакетов.

📌 Обратите внимание на параметры для директорий AllowOverride и AllowOverrideList. Они разрешают или запрещают использование различных настроек для файлов конфигураций .htaccess, которые могут переопределять многие настройки сервера. По умолчанию подобные разрешения имеет смысл отключить и включать только точечно.
<Directory />
. . .
AllowOverride None
. . .
</Directory>

📌 Для корневой системной директории отключите все Options. По умолчанию включена опция FollowSymLinks.
<Directory />
. . .
Options None
. . .
</Directory>

📌 Традиционная рекомендация по настройке любого веб сервера — удалите весь контент, что идёт по умолчанию с установочным пакетом. Это относится к стартовой странице, страницам с кодами ошибок и т.д. Всё это помогает определить версию системы и веб сервера. Для apache это обычно директории /var/www/html и /usr/share/apache2/error/.

📌 Отключите всё, что касается cgi скриптов, если вы их не используете. Выполнение этих скриптов — наследие прошлого и сейчас чаще всего не используется, но может быть включено по умолчанию. Отключите модуль mod_cgi и настройки с упоминанием алиаса /cgi-bin/ или опции ExecCGI.

📌 Веб клиенты не должны иметь доступ к файлам .htaccess, .htpasswd и .htgroup. Обязательно настройте для них запрет.
<FilesMatch "^\.ht"> 
Require all denied
</FilesMatch>

📌 Запретите доступ к веб серверу по IP адресу или по несуществующему домену (rewrite_module должен быть включён). Для этого создайте виртуальный хост, который будет первым в списке. И добавьте в него редирект всех, кто обращается не на ваш домен:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^example\.com [NC]
RewriteRule ^.(.*) - [L,F]
Если доменов много, можно сделать редирект тех, кто обращается по IP на любой другой домен:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^192\.168\.0\.1$
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

📌 Проверьте, что настроено логирование. Как минимум, должен быть включён error лог.
LogLevel notice core:info
ErrorLog "logs/error_log"
Если настроены access логи, не забудьте настроить их ротацию.

📌 По возможности, установите и настройте модуль mod_security. Это популярный web application firewall (WAF).

📌 Не используйте устаревшие версии TLS и Ciphers:
SSLProtocol TLSv1.2 TLSv1.3
SSLHonorCipherOrder On
SSLCipherSuite ALL:!EXP:!NULL:!LOW:!SSLv2:!RC4:!aNULL

📌 Отключите вывод информации о версии сервера:
ServerTokens Prod
ServerSignature Off

📌 Уменьшите дефолтный таймаут запросов:
Timeout 10


#cis #apache #security

​​Решил познакомиться с ещё одним документом от CIS по рекомендациям для Debian 11. Там 874 страницы 😱. Делаю очень краткую выжимку основного, что может пригодиться в среднестатистическом сервере. Реализация рекомендаций подробно описана в самом документе.

🔹Отключите поддержку неиспользуемых файловых систем (cramfs, squashfs, udf и т.д.). Достаточно отключить соответствующие модули ядра.

🔹/tmp и /var/tmp лучше вынести в отдельный раздел со своими параметрами. Например, noexec, nosuid, nodev и т.д. В идеале, отдельный раздел и настройки должны быть ещё и у /var/log, /home, /dev/shm.

🔹Отключите автомонтирование устройств через autofs. Проверка:
# systemctl is-enabled autofs

🔹Отслеживайте изменения в системных файлах, например с помощью AIDE (Advanced Intrusion Detection Environment):
# apt install aide aide-common

🔹По возможности включайте, настраивайте (и страдайте 👹) AppArmor.

🔹Настройте синхронизацию времени какой-то одной службой (chrony, ntp или  systemd-timesyncd).

🔹Проверьте все открытые порты и отключите всё ненужное:
# ss -tulnp

🔹Отключите неиспользуемые сетевые протоколы. Например, ipv6.

🔹Настройте Firewall. Запретите все соединения, кроме разрешённых явно (нормально закрытый файрвол). Не забудьте про все используемые протоколы.

🔹Настройте аудит доступа, изменения, удаления системных файлов с помощью auditctl.
# apt install auditctl
Убедитесь, что доступ к логам сервиса ограничен.

🔹Настройте логирование действий, выполняемых через sudo. Запретите использование su, если пользуетесь sudo.

🔹По возможности настройте отправку системных логов куда-то вовне.

🔹Отключите возможность подключаться пользователю root по ssh, если хотите отслеживать активность пользователей под их индивидуальными учётными записями.

Сам документ — CIS Debian Linux 11 Benchmark. Напомню, что у меня есть заметка со списком действий, которые я обычно выполняю при настройке типового сервера под Linux. Надо будет её переработать с учётом этих рекомендаций. Кое-что туда точно можно добавить.

Документ огромный, но на самом деле там не так много информации. Очень много подробностей по аудиту, логам, файрволу. Если вам реально нужно разобраться, как всё это настраивается, то там есть все примеры вплоть до каждой команды и скрипта.

#cis #security #linux

​​Разбираю ещё один документ от CIS с рекомендациями по настройке Docker. Напомню, что ранее я уже делал выжимки по настройке Nginx, MySQL, Apache, Debian 11. Используя эти руководства нелишним будет освежить свои инструкции и принять некоторую информацию к сведению.

📌 Директорию для информации /var/lib/docker рекомендуется вынести на отдельный раздел. Docker постоянно потребляет свободное место, так что переполнение раздела нередкое явление.

📌 У Docker высокие полномочия для доступа к хостовой системе. Следите за тем, чтобы в системной группе docker не было лишних пользователей.

📌 Для повышения безопасности рекомендуется настроить аудит службы docker, например с помощью auditd. Ставим службу:
# apt install auditd
Добавляем правило в /etc/audit/rules.d/audit.rules:
-w /usr/bin/dockerd -k docker
Перезапускаем службу:
# systemctl restart auditd
Для повышенной безопасности можно настроить аудит и за файлами и директориями Docker, за конфигурационными файлами, за юнитом systemd, за сокетом. Это общая рекомендация для служб, которые работают с правами root.

📌 Разделяйте контейнеры по отдельным сетям для межконтейнерного взаимодействия. Если этого не делать, они будут взаимодействовать через общий системный бридж, который docker создаёт по умолчанию.

📌 Включите уровень логирования службы "info", добавив в файл конфигурации /etc/docker/daemon.json параметр:
"log-level": "info"
Для повышения безопасности логи имеет смысл хранить где-то во вне. Их можно направить по syslog. Пример:
{
 "log-driver": "syslog",
 "log-opts": {
  "syslog-address": "tcp://192.xxx.xxx.xxx"
 }
}

📌 Если используете подключение к службе Docker по TCP, не забудьте настроить аутентификацию по TLS и ограничьте сетевой доступ.

📌 Используйте параметр no-new-privileges при создании контейнеров, либо добавьте этот параметр в настройку службы по умолчанию.
"no-new-privileges": true
Это предотвратит повышение привилегий в контейнере от пользователя до root. Подробнее тут.

📌 Включите параметр live-restore:
"live-restore": true
Это позволит не останавливать контейнеры в случае остановки самой службы docker, что позволит обновлять её без остановки сервисов. По умолчанию он отключен.

📌 Отключите использование userland-proxy.
"userland-proxy": false
В подавляющем большинстве случаев для проброса портов в контейнеры используется NAT. Отключение прокси уменьшает вектор атак.

📌 Чаще всего файл с настройками /etc/docker/daemon.json по умолчанию отсутствует и вы его создаёте сами, когда нужно задать те или иные параметры. Проследите, чтобы доступ на запись к нему имел только root (root:root 644).

📌 Не используйте без крайней необходимости в контейнерах пользователя root. Хорошая практика запускать всё от обычного пользователя.

📌 Ограничивайте использование памяти контейнерами так, чтобы они не могли использовать всю доступную память хоста. Для этого запускайте их с параметром --memory и задайте объём, к примеру, 1024m.

📌 Ограничивайте количество попыток перезапуска контейнера в случае ошибок. То есть не запускайте их с параметром --restart=always. Используйте вместо этого --restart=on-failure:5. Будет сделано 5 попыток запуска в случае ошибки.

Было много советов по написанию DockerFile. Не стал их разбирать, так как мне кажется, это отдельная тема, которая к самой службе не имеет отношения. Также было много советов по запуску контейнеров. Например, не запускать там службу sshd, не монтировать системные директории и т.д. Это тоже отдельная тема, пропускал такие рекомендации.

К данной заметке будет актуальна ссылка на автоматическую проверку контейнеров с помощью Trivy и исправление с помощью Copacetic. Я написал небольшую статью:
⇨ Проверка безопасности Docker образов с помощью Trivy

Данный список составил на основе переработки вот этого документа: CIS Docker Benchmark v1.5.0 - 12-28-2022. Там подробное описание с обоснованием всех рекомендаций.

#cis #docker

​​Дошли руки обработать ещё одно руководство от CIS на тему настройки Ubuntu Linux 22.04 LTS (нужна регистрация). Это огромный документ на 865 страниц. Я его весь просмотрел и постарался уместить в одну заметку то, что посчитал наиболее полезным и уместным для сервера общего назначения (рекомендации Level 1 - Server). Все детали упоминаемых настроек в подробностях описаны в исходном файле.

🔹Отключите поддержку неиспользуемых файловых систем (cramfs, squashfs, udf и т.д.). Достаточно отключить соответствующие модули ядра. Пример:
# modprobe -f udf

🔹/tmp и /var/tmp лучше вынести в отдельный раздел со своими параметрами. Например, noexec, nosuid, nodev и т.д. В идеале, отдельный раздел и настройки должны быть ещё и у /var/log, /home, /dev/shm. Пример параметров в fstab:
/tmp  tmpfs tmpfs rw,nosuid,nodev,noexec,inode6

🔹Отслеживайте изменения в системных файлах, например с помощью AIDE (Advanced Intrusion Detection Environment):
# apt install aide aide-common

🔹Убедитесь, что загрузка в single user mode требует аутентификации. Для этого обязательно установите пароль root:
# passwd root

🔹Отключите Apport Error Reporting Service, которая автоматически отправляет информацию о сбоях (по умолчанию включена):
# systemctl stop apport.service
# systemctl --now disable apport.service
# apt purge apport

🔹По возможности включайте, настраивайте AppArmor.
# apt install apparmor

🔹Настройте синхронизацию времени какой-то одной службой (chrony, ntp или systemd-timesyncd).

🔹Проверьте все открытые порты и отключите всё ненужное:
# ss -tulnp

🔹Отключите неиспользуемые сетевые протоколы. Например, ipv6. В документе представлена подробная инструкция, как это сделать. Но при этом сделана пометка, что в общем случае рекомендуется оставить ipv6, но корректно настроить всё, что с ним связано. Другие протоколы, которые в общем случае не нужны, но активны: dccp, sctp, rds, tipc. Только убедитесь, что они реально не используются. Какие-то из них могут быть нужны для работы некоторых кластеров.

🔹Настройте Firewall (UFW). Запретите все соединения, кроме разрешённых явно (нормально закрытый файрвол). Не забудьте про все используемые протоколы, в том числе ipv6. 
# apt install ufw

🔹Настройте аудит доступа, изменения, удаления системных файлов с помощью auditctl. 
# apt install auditctl audispd-plugins
Убедитесь, что доступ к логам сервиса ограничен. 

🔹По возможности настройте отправку системных логов куда-то вовне. Используйте systemd-journal-remote или rsyslog.

🔹Настройте логирование действий через sudo. Добавьте через visudo параметр:
Defaults logfile="/var/log/sudo.log"
Ограничьте использование su.

Документ огромный, но на самом деле там не так много информации. Очень много подробностей по аудиту, логам, файрволу. Если вам реально нужно разобраться, как всё это настраивается, то там есть все примеры вплоть до каждой команды и скрипта.

#cis #security #linux

​​Я уже делал серию заметок про CIS (Center for Internet Security). Это некоммерческая организация, которая разрабатывает собственные рекомендации по обеспечению безопасности различных систем. Я проработал рекомендации для:

- Nginx
- MySQL 5.7
- Apache 2.4
- Debian 11
- Docker
- Ubuntu 22.04 LTS

Основная проблема этих рекомендаций - они составлены в огромные pdf книги, иногда до 800 страниц и покрывают очень широкий вектор атак. Выбрать из них то, что вам нужно, довольно хлопотно. Я выделяю основные рекомендации, которые стоит учесть при базовом использовании стреднестатиcтической системы. В этот раз разобрал рекомендации для PostgreSQL 16.

🔹Убедитесь, что настроено логирование ошибок. Задаётся параметром log_destination. По умолчанию пишет в системный поток stderr. Считается, что это ненадёжный способ, поэтому рекомендуется отдельно настроить logging_collector и отправлять логи через него. По умолчанию он отключен. Если настроено сохранение логов в файлы, то не забыть закрыть доступ к ним и настроить ротацию средствами postgresql (log_truncate_on_rotation, log_rotation_age и т.д.)

🔹Для повышения возможностей аудита имеет смысл включить логирование подключений и отключений клиентов. Параметры log_connections и log_disconnections. По умолчанию отключено.

🔹Если вам необходимо отслеживать активность в базе данных, то имеет смысл настроить параметр log_statement. Значение ddl позволит собирать информацию о действиях CREATE, ALTER, DROP.

🔹Для расширенного аудита используйте отдельный модуль pgAudit. Обычно ставится в виде отдельного пакета. Для расширенного контроля за действиями superuser используйте расширение set_user.

🔹Если есть необходимость работать с postgresql в консоли, установите и настройте утилиту sudo, чтобы можно было контролировать и отслеживать действия различных пользователей.

🔹Рекомендованным методом аутентификации соединения является scram-sha-256, а не популярный md5, у которого есть уязвимость (it is vulnerable to packet replay attacks). Настраивается в pg_hba.conf.

🔹Настройте работу СУБД на том сетевом интерфейсе, на котором она будет принимать соединения. Параметр listen_addresses, по умолчанию указан только localhost. Если используется внешний сетевой интерфейс, не забудьте ограничить к нему доступ средствами firewall.

🔹Если есть необходимость шифровать TCP трафик от и к серверу, то не забудьте настроить TLS. За это отвечает параметр hostssl в pg_hba.conf и параметры ssl, ssl_cert_file, ssl_key_file в postgresql.conf. Поддерживается работа с self-signed сертификатами.

🔹Для репликации создавайте отдельных пользователей. Не используйте существующих или superuser.

🔹Не забудьте проверить и настроить создание бэкапов. Используйте pg_basebackup для создания полных бэкапов и копии WAL журналов для бэкапа транзакций.

Остальные рекомендации были в основном связаны с ролями, правами доступа и т.д. Это уже особенности конкретной эксплуатации. Не стал о них писать.

Сам файл с рекомендациями живёт тут. Для доступа нужна регистрация.

#cis #postgresql

​​Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.

Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).

Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:

# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]

Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:

# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2

С помощью ключа -f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).

⇨ Исходники

#docker #devops #cicd #security

​​Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:

▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16

На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.

Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:

# git clone https://github.com/docker/docker-bench-security.git
# cd docker-bench-security
# sh docker-bench-security.sh

Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:

[WARN] 1.1.1 - Ensure a separate partition for containers has been created
[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon
[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge
[WARN] 2.13 - Ensure centralized and remote logging is configured
[WARN] 4.5 - Ensure Content trust for Docker is Enabled

Вспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.

Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:

# docker-compose run --rm docker-bench-security

Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:

# sh docker-bench-security.sh -c container_images,container_runtime

Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:

# docker image pull nginx
# sh docker-bench-security.sh -i nginx -c container_images

Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:

# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2
# sh docker-bench-security.sh -i dockle-test -c container_images

У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.

#cis #docker #devops