iy
/
MeetupStandup
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

references

This commit is contained in:
IY 2019-09-11 21:18:28 +03:00
parent cfe7947213
commit 22f26cd570
2 changed files with 130 additions and 93 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
6. For administrators
View File

@ -1,36 +1,36 @@
6.9 For adminnistrators
6.1 Docker
https://blog.aquasec.com/docker-security-best-practices
Помните, что при использовании FROM наследуются все проблемы исходного имиджа
6.1.1 Помните, что при использовании FROM наследуются все проблемы исходного имиджа
Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать
соответствующие решения
Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут
6.1.2 Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут
от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера
https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом
будет настройка профиля AppArmor для защиты основной системы на уровне ядра.
Обратите внимание на сложность и большое количество абстракций
Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую
Ограничивайте доступные ресурсы для контейнеров
Необходимо использовать SECCOMP для ограничения доступа
Необходимо периодически мониторить активность конетйнеров
Необходимы правила менеджмента жизненных циклов контейнеров
Контейнеры должны находиться на отдельном разделе
Необходима грамотная настройка сети для контейнеров
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 должен быть отключен
В случае удаленного доступа необходимо использовать TLS для демона
Включите логгирование на уровне хотя бы INFO
Делайте HEALTHCHECK в контейнере
Запретите setuid и setgid в образах
COPY более безопасный, чем ADD
По возможности не используйте привилегированные контейнеры
Настройте container restart policy
Используйте отдельный network namespace для контейнеров
Не открывайте устройства с хоста напрямую в контейнер
Проверьте настройки cgroups
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 всегда должен быть обновлен до последней версии. Новые функции безопасности - а
6.2.1 K8s всегда должен быть обновлен до последней версии. Новые функции безопасности - а
не только исправления ошибок - добавляются в каждое ежеквартальное обновление, и чтобы
воспользоваться ими, мы важно использовать последнюю стабильную версию. Самое лучшее,
что можно сделать, - это запустить последнюю версию с самыми последними исправлениями,
@ -38,7 +38,7 @@
труднее по мере усложнения архитектуры кластера и при обновления возможны остановки подов и
падения, поэтому планируйте обновление как минимум раз в квартал. Использование Kubernetes as
a service может сделать обновление очень простым.
Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие
6.2.3 Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие
разрешения они имеют с помощью управления доступом на основе ролей (RBAC). RBAC обычно включается
по умолчанию в Kubernetes 1.6 и более поздних версиях (позже для некоторых управляемых провайдеров),
но если вы обновились с тех пор и не изменили свою конфигурацию, вам нужно будет дважды проверить
@ -53,30 +53,30 @@
им наименьший набор разрешений, необходимых для каждого сайта использования. Это лучше, чем предоставление
слишком широких разрешений учетной записи по умолчанию для пространства имен. Большинству приложений вообще
не нужен доступ к API; Для них можно установить «false» для automountServiceAccountToken.
Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации.
6.2.4 Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации.
Такой подход снижает риск доступа к чувствительному приложению через менее защищенное приложение, которое совместно
использует среду выполнения контейнера или хост. Например, учетные данные Kubelet скомпрометированного узла обычно
могут получить доступ к содержимому секретов, только если они используются подами, бегущими на данной ноде --
если поды с чувствительными секретами бегут на разных нодах кластера, у злоумышленника будет больше возможностей украсть их.
Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet,
6.2.5 Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet,
могут быть украдены или использованы не по назначению для повышения привилегий в кластере. Например, в недавнем
раскрытии информации о багах Shopify подробно рассказывалось о том, как пользователь смог повысить привилегии,
вызвав на микросервисе утечку информации из службы метаданных облачного провайдера. Функция сокрытия метаданных
в GKE изменяет механизм развертывания кластера, чтобы избежать этого, рекомендуется использовать его до тех пор,
пока он не будет заменен постоянным решением. Подобные контрмеры могут быть необходимы в других средах
Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для
6.2.6 Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для
ммикросервисов. Чтобы использовать их, вам необходимо убедиться, что у вас есть сетевой провайдер, который поддерживает
этот ресурс; с некоторыми управляемыми провайдерами Kubernetes, такими как Google Kubernetes Engine (GKE), вам нужно будет
вручную включить данную функциюю. (Для включения сетевых политик в GKE потребуется небольшое обновление,
если кластер уже создан). После того, как это будет сделано, начните с некоторой базовой сетевые политики по
умолчанию, например блокировка трафика из других пространств имен по умолчанию.
Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере.
6.2.7 Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере.
Подумайте об определении политики и включении Pod Security Policy - инструкции могут отличаться в зависимости от
вашего облачного провайдера или модели развертывания. Для начала можно отключить NET_RAW, чтобы заблокировать
определенные классы сетевых спуфинговых атак.
Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте
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/
@ -84,16 +84,17 @@
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. Используйте
6.3.1 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.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 которые создают отчет по безопасности заголовков.

36
7. References Normal file
View File

@ -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