From 22f26cd5700de5204d3c4958e7183b7f3b3da18e Mon Sep 17 00:00:00 2001 From: IY Date: Wed, 11 Sep 2019 21:18:28 +0300 Subject: [PATCH] references --- 6. For administrators | 187 +++++++++++++++++++++--------------------- 7. References | 36 ++++++++ 2 files changed, 130 insertions(+), 93 deletions(-) create mode 100644 7. References diff --git a/6. For administrators b/6. For administrators index bd1ffc0..49a473d 100644 --- a/6. For administrators +++ b/6. For administrators @@ -1,99 +1,100 @@ 6.9 For adminnistrators 6.1 Docker https://blog.aquasec.com/docker-security-best-practices - Помните, что при использовании FROM наследуются все проблемы исходного имиджа - Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать - соответствующие решения - Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут - от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера - https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом - будет настройка профиля AppArmor для защиты основной системы на уровне ядра. - Обратите внимание на сложность и большое количество абстракций - Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую - Ограничивайте доступные ресурсы для контейнеров - Необходимо использовать SECCOMP для ограничения доступа - Необходимо периодически мониторить активность конетйнеров - Необходимы правила менеджмента жизненных циклов контейнеров - Контейнеры должны находиться на отдельном разделе - Необходима грамотная настройка сети для контейнеров - legacy registry и Userland Proxy должен быть отключен - В случае удаленного доступа необходимо использовать TLS для демона - Включите логгирование на уровне хотя бы INFO - Делайте HEALTHCHECK в контейнере - Запретите setuid и setgid в образах - COPY более безопасный, чем ADD - По возможности не используйте привилегированные контейнеры - Настройте container restart policy - Используйте отдельный network namespace для контейнеров - Не открывайте устройства с хоста напрямую в контейнер - Проверьте настройки cgroups + 6.1.1 Помните, что при использовании FROM наследуются все проблемы исходного имиджа + Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать + соответствующие решения + 6.1.2 Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут + от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера + https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом + будет настройка профиля AppArmor для защиты основной системы на уровне ядра. + 6.1.3 Обратите внимание на сложность и большое количество абстракций + 6.1.4 Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую + 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 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/ - K8s всегда должен быть обновлен до последней версии. Новые функции безопасности - а - не только исправления ошибок - добавляются в каждое ежеквартальное обновление, и чтобы - воспользоваться ими, мы важно использовать последнюю стабильную версию. Самое лучшее, - что можно сделать, - это запустить последнюю версию с самыми последними исправлениями, - особенно в свете открытия CVE-2018-1002105. Обновление и поддержка могут становиться все - труднее по мере усложнения архитектуры кластера и при обновления возможны остановки подов и - падения, поэтому планируйте обновление как минимум раз в квартал. Использование Kubernetes as - a service может сделать обновление очень простым. - Необходимо использовать 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. - Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации. - Такой подход снижает риск доступа к чувствительному приложению через менее защищенное приложение, которое совместно - использует среду выполнения контейнера или хост. Например, учетные данные Kubelet скомпрометированного узла обычно - могут получить доступ к содержимому секретов, только если они используются подами, бегущими на данной ноде -- - если поды с чувствительными секретами бегут на разных нодах кластера, у злоумышленника будет больше возможностей украсть их. - Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet, - могут быть украдены или использованы не по назначению для повышения привилегий в кластере. Например, в недавнем - раскрытии информации о багах Shopify подробно рассказывалось о том, как пользователь смог повысить привилегии, - вызвав на микросервисе утечку информации из службы метаданных облачного провайдера. Функция сокрытия метаданных - в GKE изменяет механизм развертывания кластера, чтобы избежать этого, рекомендуется использовать его до тех пор, - пока он не будет заменен постоянным решением. Подобные контрмеры могут быть необходимы в других средах - Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для - ммикросервисов. Чтобы использовать их, вам необходимо убедиться, что у вас есть сетевой провайдер, который поддерживает - этот ресурс; с некоторыми управляемыми провайдерами Kubernetes, такими как Google Kubernetes Engine (GKE), вам нужно будет - вручную включить данную функциюю. (Для включения сетевых политик в GKE потребуется небольшое обновление, - если кластер уже создан). После того, как это будет сделано, начните с некоторой базовой сетевые политики по - умолчанию, например блокировка трафика из других пространств имен по умолчанию. - Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере. - Подумайте об определении политики и включении Pod Security Policy - инструкции могут отличаться в зависимости от - вашего облачного провайдера или модели развертывания. Для начала можно отключить NET_RAW, чтобы заблокировать - определенные классы сетевых спуфинговых атак. - Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте - доступ к машинам. - Включите журнал аудита. Многие облачные провайдеры предоставляют возможность настройк алертов при неудачных - попытках входа, желательно их влючить. - Проведите бенчмарк. https://www.cisecurity.org/benchmark/kubernetes/ - Даже если вы не используете Rancher, почитайте инструкцию по харденингу https://rancher.com/docs/rancher/v2.x/en/security/hardening-2.2/ - и бенчмаркингу https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf -6.3 Bare-metal Nginx -https://geekflare.com/nginx-webserver-security-hardening-guide/ -https://www.upguard.com/articles/10-tips-for-securing-your-nginx-deployment - - SSL/TLS - используйте только SSL/TLS-соединение, отключайте или настраивайте редирект на HTTP. Используйте - протокол TSL вместо устаревшего SSL3. Проверьте безопасность SSL на https://www.ssllabs.com/ssltest/. Отключите - устаревшие шифры. Используйте chain сертификат, так как иначе могут возникать ошибки в Chrome. Настройте DH для TSL, - сгенерируйте уникальный DH GROUP и добавьте ssl_dhparam. - - Минимизируйте утечки информации - удалите версию из баннера nginx. - - Отключите неежелательные методы - TRACE и DELETE, так как это может повлиять на возможность проведения XSS-атак. - Подумайте об отключении TRACE и TRACK. - - Для предотврещания clickjacking-атак можно добавлять заголовок X-FRAME-OPTIONS. - - Добавьте заголовок X-XSS-Protection для защиты от XSS-атак. - - Подумайте об использовании ModSecurity в качестве WAF. - - Всегда обновляйте nginx до последней версии. - - Отключите все неиспользуемые модули. - - Ограничте размер буфера для клиента. + 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. + 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/ + и бенчмаркингу https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf + 6.3 Bare-metal Nginx + 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 которые создают отчет по безопасности заголовков. diff --git a/7. References b/7. References new file mode 100644 index 0000000..cf96c97 --- /dev/null +++ b/7. References @@ -0,0 +1,36 @@ +7. References + 7.1 https://docs.djangoproject.com/en/2.2/topics/security/ + This document is an overview of Django’s security features. + It includes advice on securing a Django-powered site. + 7.2 https://docs.djangoproject.com/en/2.2/internals/security/ + Django’s security policies + Django’s development team is strongly committed to responsible reporting + and disclosure of security-related issues. As such, we’ve adopted and follow + a set of policies which conform to that ideal and are geared toward allowing + us to deliver timely security updates to the official distribution of Django, + as well as to third-party distributions. + 7.3 https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/ + Deployment checklist + The Internet is a hostile environment. Before deploying your Django project, + you should take some time to review your settings, with security, performance, + and operations in mind. + 7.4 https://docs.djangoproject.com/en/2.2/releases/security/ + Archive of security issues. CVE. + 7.5 https://medium.com/@ksarthak4ever/django-and-web-security-headers-d72a9e54155e + Django and Web Security Headers + 7.6 https://bandit.readthedocs.io/en/latest/config.html + Bandit is a tool designed to find common security issues in Python code. To do this, + Bandit processes each file, builds an AST from it, and runs appropriate plugins + against the AST nodes. Once Bandit has finished scanning all the files, it generates a report. + 7.7 https://snyk.io/blog/python-security-best-practices-cheat-sheet/ + Python Security Best Practices Cheat Sheet + In this installment of our cheat sheet series, we’re going to cover the best practices + for securely using Python. + 7.8 https://github.com/sellonen/django-security-tips + The aim of this guide/repository is to learn and promote secure system administration tips and + practices in the Django community. My motivation is that most articles that focus on getting a + Django application up and running do not talk much about security, yet database security guides + often feel too abstract and intimidating for newcomers. + 7.9 https://nvisium.com/blog/2019/04/18/django-vs-the-owasp-top-10-part-1.html + Django’s built-in mitigations for some of the most common risks listed in the OWASP Top 10 +