MeetupStandup/6. For administrators

115 lines
16 KiB
Plaintext
Raw Permalink Normal View History

2019-09-13 21:03:43 +03:00
6 For administrators
6.1 Docker
https://blog.aquasec.com/docker-security-best-practices
2019-09-13 00:16:43 +03:00
https://xakep.ru/2019/07/05/docker-security/.
2019-09-11 21:18:28 +03:00
6.1.1 Помните, что при использовании FROM наследуются все проблемы исходного имиджа
Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать
соответствующие решения
6.1.2 Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут
от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера
https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом
будет настройка профиля AppArmor для защиты основной системы на уровне ядра.
6.1.3 Обратите внимание на сложность и большое количество абстракций
2019-09-13 00:16:43 +03:00
6.1.4 Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую. Верифицируйте достоверность через
Docker Content Trust
2019-09-11 21:18:28 +03:00
6.1.5 Ограничивайте доступные ресурсы для контейнеров
6.1.6 Необходимо использовать SECCOMP для ограничения доступа
6.1.7 Необходимо периодически мониторить активность конетйнеров
6.1.8 Необходимы правила менеджмента жизненных циклов контейнеров
6.1.9 Контейнеры должны находиться на отдельном разделе
6.1.10 Необходима грамотная настройка сети для контейнеров
legacy registry и Userland Proxy должен быть отключен
6.1.11 В случае удаленного доступа необходимо использовать TLS для демона
6.1.12 Включите логгирование на уровне хотя бы INFO
6.1.13 Делайте HEALTHCHECK в контейнере
6.1.14 Запретите setuid и setgid в образах
6.1.15 COPY более безопасный, чем ADD
6.1.16 По возможности не используйте привилегированные контейнеры
6.1.17 Настройте container restart policy
6.1.18 Используйте отдельный network namespace для контейнеров
6.1.19 Не открывайте устройства с хоста напрямую в контейнер
6.1.20 Проверьте настройки cgroups
2019-09-13 00:16:43 +03:00
6.1.21 Проверяйте конфигурацию при помощи Docker Bench Security
6.1.22 Проверяйте отсутствие смонтированного сокета docker внутри контейнера
2019-09-13 21:03:43 +03:00
6.2 Kubernets
https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/
https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/
https://xakep.ru/2019/08/28/bulletproof-kubernetes/
2019-09-11 21:18:28 +03:00
6.2.1 K8s всегда должен быть обновлен до последней версии. Новые функции безопасности - а
не только исправления ошибок - добавляются в каждое ежеквартальное обновление, и чтобы
воспользоваться ими, мы важно использовать последнюю стабильную версию. Самое лучшее,
что можно сделать, - это запустить последнюю версию с самыми последними исправлениями,
особенно в свете открытия CVE-2018-1002105. Обновление и поддержка могут становиться все
труднее по мере усложнения архитектуры кластера и при обновления возможны остановки подов и
падения, поэтому планируйте обновление как минимум раз в квартал. Использование Kubernetes as
a service может сделать обновление очень простым.
6.2.3 Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие
разрешения они имеют с помощью управления доступом на основе ролей (RBAC). RBAC обычно включается
по умолчанию в Kubernetes 1.6 и более поздних версиях (позже для некоторых управляемых провайдеров),
но если вы обновились с тех пор и не изменили свою конфигурацию, вам нужно будет дважды проверить
ваши настройки. Из-за способа объединения контроллеров авторизации Kubernetes необходимо включить
RBAC и отключить устаревшее управление доступом на основе атрибутов (ABAC). После применения RBAC вам
все равно нужно эффективно его использовать. Как правило, следует избегать общекластерных разрешений в
пользу разрешений, специфичных для пространства имен. Избегайте предоставления кому-либо привилегий
администратора кластера, даже для отладки - гораздо безопаснее предоставлять доступ только по мере
необходимости в каждом конкретном случае. Вы можете просмотреть роли и роли кластера,
используя `kubectl get clusterrolebinding` или` kubectl get rolebinding all-namespaces`. Если вашему
приложению необходим доступ к API Kubernetes, создайте учетные записи служб индивидуально и предоставьте
им наименьший набор разрешений, необходимых для каждого сайта использования. Это лучше, чем предоставление
слишком широких разрешений учетной записи по умолчанию для пространства имен. Большинству приложений вообще
не нужен доступ к API; Для них можно установить «false» для automountServiceAccountToken.
2019-09-13 00:16:43 +03:00
Для аудита и автоматизации настройки RBAC можно использовать Audit2rbac и Rbac-manager.
2019-09-11 21:18:28 +03:00
6.2.4 Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации.
Такой подход снижает риск доступа к чувствительному приложению через менее защищенное приложение, которое совместно
использует среду выполнения контейнера или хост. Например, учетные данные Kubelet скомпрометированного узла обычно
могут получить доступ к содержимому секретов, только если они используются подами, бегущими на данной ноде --
если поды с чувствительными секретами бегут на разных нодах кластера, у злоумышленника будет больше возможностей украсть их.
6.2.5 Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet,
могут быть украдены или использованы не по назначению для повышения привилегий в кластере. Например, в недавнем
раскрытии информации о багах Shopify подробно рассказывалось о том, как пользователь смог повысить привилегии,
вызвав на микросервисе утечку информации из службы метаданных облачного провайдера. Функция сокрытия метаданных
в GKE изменяет механизм развертывания кластера, чтобы избежать этого, рекомендуется использовать его до тех пор,
пока он не будет заменен постоянным решением. Подобные контрмеры могут быть необходимы в других средах
6.2.6 Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для
ммикросервисов. Чтобы использовать их, вам необходимо убедиться, что у вас есть сетевой провайдер, который поддерживает
этот ресурс; с некоторыми управляемыми провайдерами Kubernetes, такими как Google Kubernetes Engine (GKE), вам нужно будет
вручную включить данную функциюю. (Для включения сетевых политик в GKE потребуется небольшое обновление,
если кластер уже создан). После того, как это будет сделано, начните с некоторой базовой сетевые политики по
умолчанию, например блокировка трафика из других пространств имен по умолчанию.
6.2.7 Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере.
Подумайте об определении политики и включении Pod Security Policy - инструкции могут отличаться в зависимости от
вашего облачного провайдера или модели развертывания. Для начала можно отключить NET_RAW, чтобы заблокировать
определенные классы сетевых спуфинговых атак.
6.2.8 Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте
доступ к машинам.
6.2.9 Включите журнал аудита. Многие облачные провайдеры предоставляют возможность настройк алертов при неудачных
попытках входа, желательно их влючить.
Проведите бенчмарк. https://www.cisecurity.org/benchmark/kubernetes/
Даже если вы не используете Rancher, почитайте инструкцию по харденингу https://rancher.com/docs/rancher/v2.x/en/security/hardening-2.2/
2019-09-13 00:16:43 +03:00
и бенчмаркингу https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf.
Утилиты для аудита: kube-bench, тест CIS Kubernetes.
6.2.10 Запустите Kubesec и выполните рекомендации по использованию сервисов хранения секретов и настроек безопасности
6.2.11 Используйте систему обнаружения вторжения наподобие Falco, настройте оповещения в корпоративный мессенджер
6.2.12 Настройте фильтрацию сетевой активности через межсетевой экран Cilium - сервер фильтрации сети с учетом API-вызовов.
6.2.13 Используйте сеть Calico для безопасного сетевого соединения. Calico - софтверный свитч, который создает сеть
третьего уровня и использует туннелирование.
6.2.14 Подумайте об использовании коммерческого SaaS секьюрити-направленности - Aqua Security, Cavirin, NeuVector, Sysdig Secure.
6.2.15 Если кластер бежит на AWS, можно использовать Kube2iam для подставления учетных данных AWS IAM в контейнеры
2019-09-13 21:03:43 +03:00
6.3 Bare-metal Nginx
2019-09-11 21:18:28 +03:00
https://geekflare.com/nginx-webserver-security-hardening-guide/
https://www.upguard.com/articles/10-tips-for-securing-your-nginx-deployment
6.3.1 SSL/TLS - используйте только SSL/TLS-соединение, отключайте или настраивайте редирект на HTTP. Используйте
протокол TSL вместо устаревшего SSL3. Проверьте безопасность SSL на https://www.ssllabs.com/ssltest/. Отключите
устаревшие шифры. Используйте chain сертификат, так как иначе могут возникать ошибки в Chrome. Настройте DH для TSL,
сгенерируйте уникальный DH GROUP и добавьте ssl_dhparam.
6.3.2 Минимизируйте утечки информации - удалите версию из баннера nginx.
6.3.3 Отключите неежелательные методы - TRACE и DELETE, так как это может повлиять на возможность проведения XSS-атак.
6.3.4 Подумайте об отключении TRACE и TRACK.
6.3.5 Для предотврещания clickjacking-атак можно добавлять заголовок X-FRAME-OPTIONS.
6.3.6 Добавьте заголовок X-XSS-Protection для защиты от XSS-атак.
6.3.7 Подумайте об использовании ModSecurity в качестве WAF.
6.3.8 Всегда обновляйте nginx до последней версии.
6.3.9 Отключите все неиспользуемые модули.
6.3.10 Ограничте размер буфера для клиента.
6.3.11 Используйте Securityheaders.com или observatory.mozilla.org которые создают отчет по безопасности заголовков.