Поиск

ShadowSocks решения: Marzban Quick | Marzban Full | Marzban Node | x-ui | 3x-ui | 3x-ui Docker Всем привет В продолжении прошлой темы. Решил опубликовать набор самых основных настроек и установки в докер. 1. Первым делом ставим docker. bash <(curl -sSL https://get.docker.com) 2. Клонируем репозиторий и падаем в него git clone https://github.com/MHSanaei/3x-ui.git cd 3x-ui 3. Заходим в docker-compose.yml и правим параметры: --- version: "3.9" services: 3x-ui: image: ghcr.io/mhsanaei/3x-ui:latest container_name: 3x-ui hostname: domain.org volumes: - $PWD/db/:/etc/x-ui/ - /etc/letsencrypt/live/domain.org/fullchain.pem:/root/cert/fullchain.pem - /etc/letsencrypt/live/domain.org/privkey.pem:/root/cert/privkey.pem environment: XRAY_VMESS_AEAD_FORCED: "false" tty: true network_mode: host restart: unless-stopped Нам нужно поменять hostname на ваш домен, и указать путь туда, где certbot будет генерировать ключи (строка - $PWD/cert/:/etc/letsencrypt/live/proxy.domain.ru/) Сохраняем и закрываем файл. (ctrl+o, enter, ctrl+x) 4. Выпускаем сертификаты к уже привязанному домену с помощью certbot. (Для управления домена и поддоменами рекомендую использовать Cloudflare, это очень удобно, быстро и комфортно) apt-get install certbot -y certbot certonly --standalone --agree-tos --register-unsafely-without-email -d proxy.domain.ru certbot renew --dry-run Получаем сообщение: Значит все хорошо. Если вы получили ошибку, проверьте домен или возможно привязка к IP не выполнилась ещё, подождите немного. 5. Назначаем разрешение на файлы в папке ключей: chmod 666 -Rf /etc/letsencrypt/live/proxy.domain.ru 6. Запускаем контейнер. docker compose up -d 7. Заходим в панель: http://proxy.domain.ru:2053/panel 8. Логин и пароль admin / admin Добро пожаловать в панель. 9. Сразу идем в настройки панели =- настройки безопасности и меняем пароль 10. Заходим в первую вкладку и пишем наши данные по домену и адрес к нашим ключам: Папка должна соответствовать тому что у нас в docker-compose.yml UPD: 09.08.23. Совладать с файлам ключей не получилось. Нужно скопировать 2 ключа из пути выше, в папку /root/3x-ui/cert/ командой: 10.2. Заходим в раздел подписок, включаем эту опцию и прописываем те же параметры домена и ключей (либо можете использовать отличный от основного домен) 11. Вернемся в нашу консоль. Теперь нужно установить WARP Proxy: Вся информация есть на оф сайте: Announcing WARP for Linux and Proxy Mode (cloudflare.com) Дополнительно читаем про добавление ключей: Cloudflare Package Repository (cloudflareclient.com) А теперь пример реальный, на Ubuntu: Добавляем GPG key: curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg Добавляем репозиторий: echo "deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list Обновляемся: sudo apt update Ставим sudo apt install cloudflare-warp Теперь настраиваем. 1. Всю помощь получаем тут: warp-cli --help 2. Нужно зарегистрироваться: warp-cli register 3. Теперь выставить режим работы (possible values: warp, doh, warp+doh, dot, warp+dot, proxy), я выбираю proxy: warp-cli set-mode proxy 4. Устанавливаем порт для WARP proxy warp-cli set-proxy-port 40000 5. Коннектимся warp-cli connect Готово. Идём обратно в наш веб-интерфейс 3x-ui Здесь нам нужно зайти на вкладку настройки xray и развернув WARP proxy воткнуть все тумблеры Не забывайте, что каждое изменение в панели сперва делается кнопкой Сохранить, а затем необходимо Перезагрузить панель. Создание подключений Можно долго писать про настройки. Я покажу основные. ShadowSocks классический Trojan vless В принципе, если у вас работает одно какое то подключение, вы можете использовать только его. Остальные вряд ли будут чем то отличаться. Хорошей особенностью сборки 3x-ui, в отличии от Marzban является встроенного Ограничение по IP - это то количество одновременных подключений, которые может быть доступно на 1 коннект от 1 пользователя. Готово! Пользуйтесь! Другие мои параметры: PS: Настройки телеграм бота очень просты. И имеют все необходимые комментарии. Вот что выдает бот: Для клиента с прописанным Telegram ID информации минимум, не выдает даже сами конфиги. UPD: Для работы IP Limit нужно установить на сервер Fail2ban

DWG - UI Обсуждение DWG » | DWG-CLI » | DWG-UI » | DWG-DARK » | DWG [multi] » Представляю вам лучшую сборку для самой быстрой настройки VPN сервера на WireGuard dwg-ui = AdGuard with DoH DNS + Wireguard with UI (wg-easy) + Unbound Требования Чистый пустой сервер. Поддерживаемые операционные системы: Ubuntu 20.04, 22.04; Debian 11, Centos 8,9 Скрипт устанавливает все автоматически. Все комментарии по скрипту внутри в комментариях Самая быстрая установка - 1 минута Запусти команду на чистом сервере apt update && apt install curl sudo git -y && curl -Of https://raw.githubusercontent.com/DigneZzZ/dwg-ui/main/setup.sh && chmod +x setup.sh && ./setup.sh Что установится: Сначала установится Git, чтобы можно было скопировать мой репозиторий Docker - последняя версия Docker-compose - последняя версия Wg-easy - интерактивный режим введения пароля для веб AdGuard Home - интерактивный режим создания пользователя и пароля (можно оставить стандартным) Unbound - все в стоке apache2-utils - необходим для генерации хэш-паролей ssh.sh - скрипт для смены порта SSH подключения ufw.sh - скрипт для установки UFW Firewall. Напомнит установить ufw-docker и сам закроет доступ извне! ВНИМАНИЕ! Запускать только после того как создадите для себя клиента в WireGUARD!!! https://github.com/DigneZzZ/dwg-ui

DWG [multi] Обсуждение DWG » | DWG-CLI » | DWG-UI » | DWG-DARK » | DWG [multi] » Универсальная сборка. Она содержит внутри себя варианты установки сборки на выбор: DWG-UI DWG-CLI DWG-DARK(ДОБАВЛЕН!) Не рекомендуется устанавливать две подряд, либо на уже имеющуюся сборку. Требования Чистый пустой сервер. Поддерживаемые операционные системы: Ubuntu 20.04, 22.04; Debian 11, Centos 8,9 Скрипт устанавливает все автоматически. Все комментарии по скрипту внутри в комментариях Самая быстрая установка - 1 минута Запусти команду на чистом сервере bash <(wget -qO- https://raw.githubusercontent.com/DigneZzZ/dwg/main/set-up.sh) Что установится: Сначала установится Git, чтобы можно было скопировать мой репозиторий Docker - последняя версия Docker-compose - последняя версия Wg-easy - интерактивный режим введения пароля для веб AdGuard Home - интерактивный режим создания пользователя и пароля (можно оставить стандартным) Unbound - все в стоке apache2-utils - необходим для генерации хэш-паролей ssh.sh - скрипт для смены порта SSH подключения ufw.sh - скрипт для установки UFW Firewall. Напомнит установить ufw-docker и сам закроет доступ извне! ВНИМАНИЕ! Запускать только после того как создадите для себя клиента в WireGUARD!!! Для изменения пароля к AGH можно воспользоваться скриптом ниже. Позже он будет добавлен возможностью смены пароля и к WG-easy. cd dwg && ./change.sh После смены пароля необходимо пересоздать контейнеры командой: docker-compose up -d --force-recreate https://github.com/DigneZzZ/dwg Описание скриптов в папке tools agh.sh - смена логина и пароля к AGH docker.sh - установка docker и docker-compose nano.sh - установка редактора ssh.sh - скрипт смены стандартного порта ssh. (может поменять любой порт) swap.sh - скрипт добавления файла подкачки (актуально всем) ufw-docker.sh - скрипт установки ufw-docker - актуально для WG-easy. Скрипт с пресетом для сборки dwg-ui. ufw.sh - установка firewall UFW, с автоматическим определением порта SSH и добавлением в исключение.

DWG - DARK Обсуждение DWG » | DWG-CLI » | DWG-UI » | DWG-DARK » | DWG [multi] » Особенности: сборка с возможность контроля и отображения каждого пира WG в AdGuardHome! Интерфейс сделан "тёмный". Сборка на базе WG-Easy. Находится в тестировании! Могут быть ошибки! Требования Чистый пустой сервер. Поддерживаемые операционные системы: Ubuntu 20.04, 22.04; Debian 11, Centos 8,9 Скрипт устанавливает все автоматически. Все комментарии по скрипту внутри в комментариях Самая быстрая установка - 1 минута Запусти команду на чистом сервере apt update && apt install curl sudo git -y && curl -Of https://raw.githubusercontent.com/DigneZzZ/dwg-dark/main/setup.sh && chmod +x setup.sh && ./setup.sh Что установится: Сначала установится Git, чтобы можно было скопировать мой репозиторий Docker - последняя версия Docker-compose - последняя версия Wg-easy - интерактивный режим введения пароля для веб AdGuard Home - интерактивный режим создания пользователя и пароля (можно оставить стандартным) Unbound - все в стоке apache2-utils - необходим для генерации хэш-паролей ssh.sh - скрипт для смены порта SSH подключения ufw.sh - скрипт для установки UFW Firewall. Напомнит установить ufw-docker и сам закроет доступ извне! ВНИМАНИЕ! Запускать только после того как создадите для себя клиента в WireGUARD!!! https://github.com/DigneZzZ/dwg-dark

DWG - сборки Docker WireGuard VPN Обсуждение DWG » | DWG-CLI » | DWG-UI » | DWG-DARK » | DWG [multi] » DWG (Docker WireGuard) — это различные сборки Docker контейнеров WireGuard VPN в комбинации c Unbound (DNS сервер), PiHole, AdGuard Home, WG Easy и другими полезными пакетами в различных комбинациях, для быстрого и легкого воссоздания инфраструктуры вашего VPN сервера. Установка и настройка подобных конфигураций вручную, без использования Docker контейнеров отнимет у вас много времени и сил. Требования: Только что установленная операционная система Ubuntu 20.04, 22.04; Debian 11, Centos 8,9 Данная страница является общей для обсуждения сборок DWG. Любые идеи и новые реализации сборок Docker Wireguard приветствуются

Всем привет Периодически получаю запросы на помощь, как открыть доступ к контейнеру после установки UFW-Docker. Ведь если его не ставить, то все контейнеры по умолчанию обходят правила UFW. Про его установку я писал здесь: Для начала хочется отметить важный момент, принцип работы ufw-docker: Заблокировано всё что не открыто. Дополнительно про работу с ufw-docker я писал здесь: Теперь поговорим про входящий и исходящий трафик. Для того, чтобы разрешить как входящий, так и исходящий трафик для контейнеров Docker с использованием ufw-docker, выполните следующие шаги: 1. Установите и настройте ufw-docker, следуя инструкциям 2. Откройте порты, необходимые для работы ваших контейнеров. Например, если вам нужно открыть порт 80 для работы веб-приложения, выполните следующую команду: sudo ufw allow 80/tcp 3. Разрешите входящий и исходящий трафик для Docker (вместо docker0 нужно указать имя контейнера, полученное из команды docker ps, например, wg-easy).: sudo ufw allow in on docker0 && sudo ufw allow out on docker0 4. Проверьте правила ufw: sudo ufw status numbered В результате вы должны увидеть правила, похожие на следующие:

Иногда необходимо предоставить возможность контейнерам общаться между собой, особенно если уже установлен ufw-docker. Данная статья предполагает что у вас два контейнера и две разные сети. Задача - открыть доступ друг к другу. 1. Настроить правила файрвола для ufw-docker: sudo ufw default allow incoming sudo ufw default allow outgoing sudo ufw allow in on network1 to any port 8080 proto tcp sudo ufw allow in on network2 to any port 8080 proto tcp sudo ufw allow in on network1 from network2 sudo ufw allow in on network2 from network1 sudo ufw reload 2. Настроить маршрутизацию между сетями: docker run -it --rm --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" 3. Протестировать соединение между контейнерами: docker exec -it container1 bash # apt-get update && apt-get install -y curl # curl container2:8080 docker exec -it container2 bash # apt-get update && apt-get install -y curl # curl container1:8080 После выполнения этих шагов, контейнеры должны успешно обмениваться данными между собой. Важно также убедиться, что правила файрвола корректно настроены и не блокируют доступ между контейнерами.

Концепция контейнеров Docker позволяет разработчикам и системным администраторам собирать приложения в легковесные, автономные и переносимые окружения. Это упрощает процесс разработки, тестирования и развертывания приложений, а также уменьшает время, затрачиваемое на настройку и конфигурацию окружений. Однако, иногда бывает необходимо перенести контейнер с одного сервера на другой. Например, если вы разрабатываете приложение на своем локальном компьютере и хотите перенести его на сервер для тестирования или развертывания. В этой статье мы расскажем, как запаковать Docker контейнер и перенести его на другой сервер без потери данных. Как запаковать Docker контейнер и перенести его на другой сервер без потери данных Docker - это платформа для создания, развертывания и управления приложениями в контейнерах. Контейнеры Docker представляют собой легковесные, автономные и переносимые окружения, которые работают практически в любой среде. В этой статье мы рассмотрим, как запаковать Docker контейнер и перенести его на другой сервер без потери данных. Шаг 1: Остановить контейнер Перед запаковкой контейнера необходимо остановить его. Используйте команду docker stop для остановки контейнера: $ docker stop <container_name> Здесь <container_name> - это имя контейнера, который вы хотите остановить. Шаг 2: Сохранить контейнер в образ Чтобы запаковать контейнер, необходимо сохранить его в образ. Используйте команду docker commit для сохранения контейнера в образ: $ docker commit <container_name> <image_name> Здесь <container_name> - это имя остановленного контейнера, а <image_name> - это имя образа, в который будет сохранен контейнер. Шаг 3: Экспортировать образ в файл Чтобы перенести образ на другой сервер, необходимо экспортировать его в файл. Используйте команду docker save для экспортирования образа в файл: $ docker save <image_name> > <file_name>.tar Здесь <image_name> - это имя образа, который нужно экспортировать, а <file_name> - это имя файла, в который будет экспортирован образ. Шаг 4: Перенести файл на другой сервер Скопируйте файл <file_name>.tar на другой сервер. Для этого можете использовать команду scp: $ scp <file_name>.tar <user>@<server_ip>:<path> Здесь <user> - это имя пользователя на удаленном сервере, <server_ip> - это IP-адрес удаленного сервера, а <path> - это путь к месту, где нужно сохранить файл на удаленном сервере. Шаг 5: Импортировать образ на другом сервере Чтобы использовать образ на другом сервере, необходимо импортировать его из файла. Используйте команду docker load для импортирования образа из файла: $ docker load < <file_name>.tar Шаг 6: Запустить контейнер После импорта образа можно запустить контейнер на другом сервере. Используйте команду docker run для запуска контейнера: $ docker run -d --name <container_name> <image_name> Здесь <container_name> - это имя контейнера, который вы хотите запустить, а <image_name> - это имя образа, который вы хотите использовать для запуска контейнера. На этом всё.

Работы выполняются на чистом сервере. Установлен Ubuntu 22.04 1. Ставим docker и docker-compose. // Я делал по этой инструкции. sudo apt update sudo apt install apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install docker-ce И проверяем статус: sudo systemctl status docker Проверяем запуск контейнера docker run hello-world Ставим docker-compose: sudo apt install docker-compose Тут описан вариант для Debian 11.

Если в контейнере подняты какие-либо веб-интерфейсы, например как это реализовано в WG-easy, то стандартными средствами типа UFW и iptables закрывать порты будет достаточно проблематично. Поэтому на помощь приходит ufw-docker с очень простым алгоритмом. Заблокировано всё, что не разрешено. Ставим! Для начала у вас должен быть установлен и запущен стандартный UFW: sudo apt install ufw ufw enable Качаем из репозитория ufw-docker. sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker sudo chmod +x /usr/local/bin/ufw-docker Затем устанавливаем и перезапускаем UFW. ufw-docker install sudo systemctl restart ufw Готово!!!! В утилите ufw-docker есть команда, которая выборочно вносит порты в белый список для определенных контейнеров Docker. ufw-docker allow httpd 80 Однако если вы хотите использовать более продвинутое правило, например, белый список на основе IP, вам придется использовать ufw route allow ufw route allow proto tcp from 1.2.3.4 to any port 9443 Мануал простой Usage: ufw-docker <list|allow> [docker-instance-id-or-name [port[/tcp|/udp]] [network]] ufw-docker delete allow [docker-instance-id-or-name [port[/tcp|/udp]] [network]] ufw-docker service allow <swarm-service-id-or-name <port</tcp|/udp>>> ufw-docker service delete allow <swarm-service-id-or-name> ufw-docker <status|install|check|help> Для варианта с wireguard-ui будет просто: Разрешаем. ufw-docker allow wg-easy Удаляем: ufw-docker delete allow wg-easy Done.

С учетом того, что сегодня число интернет-пользователей поражает воображение, а сами веб-приложения выполняют больше задач, чем когда-либо в прошлом, масштабирование, поддержка и разработка крупных веб-приложений стали серьезной проблемой для команд DevOps. Теперь, когда приложения масштабируются в нескольких публичных облаках с использованием различных технологических стеков, для их поддержки и развертывания требуются современные решения. Среди них популярны контейнерные приложения, обычно использующие такие технологии, как Docker. Дальнейшее масштабирование стало возможным с появлением таких технологий, как Kubernetes. Контейнерные приложения позволяют DevOps-командам поддерживать контейнеры с определенными конфигурациями и версиями приложений. Эта практика также позволяет командам DevOps реплицировать их столько раз, сколько необходимо, и все это в автоматическом режиме. Сочетание таких технологий, как Kubernetes (которая сделала развертывание, масштабирование и обслуживание контейнерных приложений очень простым) и Docker, зарекомендовало себя как решение для удовлетворения требований современных приложений, что привело к значительному росту их популярности в последнее время. Однако внедрение новых технологий всегда чревато новыми ошибками и уязвимостями. Поэтому такой риск требует такого же внимания, как и ручное развертывание, чтобы избежать наплыва уязвимостей, проникающих в ваше контейнерное и автоматизированное развертывание. Какие популярные ошибки в конфигурации делают контейнерные приложения уязвимыми для атак? Наиболее распространенным источником уязвимостей в таких технологиях, как Docker, Kubernetes и других технологиях автоматизации, таких как SaltStack, Ansible и Puppet, являются устаревшие версии программного обеспечения, а также отсутствие процедур усиления безопасности и надлежащего анализа конфигурации. Права Одна из самых основных форм неправильной конфигурации в Docker связана с повышением прав пользователя. В таких случаях контейнеры Docker, запускаемые от имени root, представляют гораздо более серьезную угрозу безопасности, чем контейнеры, запускаемые не от имени root. Если контейнер запускается под пользователем root и существуют уязвимости безопасности для данной версии Docker, то, например, в прошлом существовали уязвимости, которые позволяли злоумышленникам проникнуть на хост через уязвимое или неправильно сконфигурированное программное обеспечение, запущенное в самом контейнере. Такое уязвимое программное обеспечение также позволяло злоумышленникам выйти из контейнера и проникнуть на хост-сервер, на котором запущен контейнер. Именно поэтому настоятельно рекомендуется запускать контейнеры под управлением пользователей с нужным количеством разрешений и доступа. Docker поддерживает работу в режиме пользователя rootless/non-root, что позволяет значительно повысить уровень безопасности, конфигурацию которого можно увидеть в официальном руководстве по Docker. Безопасность данных/конфигурации Место хранения данных – важный момент при работе с контейнерами, такими как Docker, как и знание того, что хранение данных внутри контейнеров часто имеет больше недостатков, чем преимуществ. Настоятельно рекомендуется хранить любые пользовательские данные вне контейнера; в случае обнаружения уязвимостей контейнер можно уничтожить, обновить и развернуть из чистого состояния. Это позволяет автоматизировать работу с CVE, поскольку данные не находятся внутри контейнера. Хранение учетных данных – еще одна частая ошибка конфигурации. Как и в случае с хранением данных, рекомендуется избегать хранения учетных данных внутри самого контейнера, чтобы в случае возникновения уязвимости контейнер можно было легко обновить и снова запустить без утечки учетных данных. Монтирование данных вне контейнера легко выполняется с помощью Docker. Рассмотрим следующую команду Docker run: docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started В этом примере данные хранятся вне контейнера по пути /etc/todos – таким образом, контейнер работает независимо, позволяя создавать, уничтожать или перемещать контейнер, сохраняя данные как есть и в отдельном пути. Автоматизация безопасности Такие технологии, как Ansible, SaltStack и Puppet, используются для автоматизации задач, которые необходимо выполнять на большом количестве серверов. Эти технологии используют файлы конфигурации, называемые “плейбуки”, которые содержат информацию о том, что и где должно быть выполнено. Для работы этих плейбуков необходим доступ к серверам через SSH или аналогичный доступ на уровне консоли. Однако выполнение этих задачот имени root и/или хранение паролей root в открытом виде в этих конфигурациях может привести к инцидентам, связанным с безопасностью, в случае утечки конфигураций. Рассмотрим следующий пример. Чтобы установить MySQL с помощью Ansible: - hosts: webservers user: vagrant sudo: true vars_files: - vars.yml tasks: - name: Install MySQL action: apt pkg=$item state=installed with_items: - mysql-server-core-5.5 - mysql-client-core-5.5 - libmysqlclient-dev - python-mysqldb - mysql-server - mysql-client - name: Start the MySQL service action: service name=mysql state=started - name: Remove the test database mysql_db: name=test state=absent - name: Create deploy user for mysql mysql_user: user="deploy" host="%" password={{mysql_root_password}} priv=*.*:ALL,GRANT - name: Ensure anonymous users are not in the database mysql_user: user='' host=$item state=absent with_items: - 127.0.0.1 - ::1 - localhost - name: Copy .my.cnf file with root password credentials template: src=templates/.my.cnf dest=/etc/mysql/my.cnf owner=root mode=0600 - name: Update mysql root password for all root accounts mysql_user: name=root host={{item}} password={{mysql_root_password}} with_items: - 127.0.0.1 - ::1 - localhost Как показано выше, мы можем использовать Ansible для установки определенной версии MySQL (5.5), запуска службы, удаления всех тестовых баз данных, добавления пользователя, удаления всех анонимных пользователей, копирования существующего файла my.cnf и обновления пароля root. Поскольку пароль root MySQL, различная другая конфиденциальная информация (например, версия MySQL) и имя развернутого пользователя MySQL хранятся прямо в конфигурационном файле, безопасность становится насущной проблемой. Раскрытие конфигурации/файлов Конфигурация/файлы Docker могут быть идеальной демонстрацией такого рода неправильной конфигурации. Давайте рассмотрим пример базового официального файла Docker compose (docker-compose.yml), используемого для установки WordPress с MySQL: version: "3.9" services: db: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on: - db image: wordpress:latest volumes: - wordpress_data:/var/www/html ports: - "8000:80" restart: always environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: db_data: {} wordpress_data: {} Здесь мы видим, что MySQL 5.7 установлен из последнего образа WordPress, доступного на Docker Hub, а также пароль корня MySQL, имя базы данных, имя пользователя и пароль пользователя. Поскольку конфигурация контейнера Docker перечисляется в виде обычного/человекочитаемого текста, включая пароли к базе данных, пути к данным и файлам, необходимо убедиться не только в надежности хранения файлов, но и в том, что любая часть автоматизированных процессов развертывания обеззараживается при использовании для развертывания контейнеров. Обнаружение подобных проблем с конфигурацией позволяет blue team предотвратить утечку конфиденциальных данных, которые впоследствии могут быть использованы для осуществления более сложных атак на облачную инфраструктуру. Раскрытие Kubernetes Rancher – это мультикластерная платформа оркестровки с открытым исходным кодом, которая позволяет операционным командам развертывать, управлять и обеспечивать безопасность корпоративных Kubernetes. Это программное обеспечение для оркестрации часто становится жертвой неправильной конфигурации; например, учетные данные администратора по умолчанию часто полностью раскрываются, что, в свою очередь, используется злоумышленниками. Раскрытие консоли Kubernetes Консоль Kubernetes (или дашборд) является важной частью настройки Kubernetes. Она позволяет получить полный обзор всех контейнеров, управляемых кластером Kubernetes, включая их состояние, использование памяти, других ресурсов, а также различные функции управления. Раскрытие этой консоли может привести к различным типам атак. В прошлом открытые консоли использовались для организации майнинга криптовалюты, что может привести к финансовым потерям и замедлению работы приложений из-за потребления ресурсов процессами майнинга криптовалюты. Раскрытие Kubernetes Kustomization Инструмент Kubernetes Kustomization используется для настройки объектов Kubernetes с помощью файла “Kustomization”. Со страницы проектов Kustomize позволяет настраивать необработанные, свободные от шаблонов YAML-файлы для различных целей, оставляя исходный YAML нетронутым и пригодным для использования как есть. В свою очередь, такая возможность настройки конфигураций делает новые файлы Kustomization довольно мощными, позволяя объединять различные существующие файлы конфигурации Kubernetes. Однако доступ к этим файлам может привести к утечке большого количества конфиденциальных данных из вашей организации, поэтому очень важно обеспечить постоянную безопасность и дезинфекцию этих файлов. А как насчет уязвимостей программного обеспечения для оркестрации контейнеров? Правильная настройка этих инструментов необходима для обеспечения безопасности развертывания контейнерных приложений. В конце концов, недостатки безопасности в этих инструментах могут быть как простыми, например, приборная панель позволяет обходить аутентификацию, так и сложными, например, приборная панель имеет уязвимости безопасности, позволяющие проводить инъекционные атаки shell. Учитывая уязвимость CVE-2020-16846, затрагивающую SaltStack Salt, программное обеспечение для управления инфраструктурой и оркестровки контейнеров, CVE позволяла осуществлять атаки shell injection при отправке определенных веб-запросов к API SaltStack. Проще говоря, поскольку уязвимости возможны в стеке управления вашей контейнерной инфраструктурой, безопасность всего вашего контейнерного приложения, вероятно, также находится под угрозой. Заключение Наряду с неизбежным переходом на контейнерные приложения, используемые в организациях для обеспечения более простого управления, быстрого развертывания и эффективного масштабирования веб-приложений, возникают определенные критические проблемы безопасности, которые часто упускаются из виду при рассмотрении различных преимуществ (а иногда и сложностей) управления этими кластерами контейнеров. Хотя контейнеры доказали, что они помогают обеспечить согласованность, сократить время развертывания и другие проблемы, связанные с версиями и конфигурациями программного обеспечения для разработчиков и производственных инстансов, они также создают извечную проблему обеспечения правильной и безопасной конфигурации. Это особенно актуально для конфигурационных файлов, содержащих детали, касающиеся каждого аспекта развертываемого программного обеспечения: пути к данным, пароли баз данных и другие учетные данные доступа.

Хотите узнать, где находятся образы, контейнеры и тома Docker? В типичной среде Linux образы Docker и данные контейнеров можно найти в: /var/lib/docker/ Если на вашем сервере не хватает места, вам обязательно следует заглянуть в этот каталог. В основном, все связанные с Docker сущности находятся в /var/lib/docker. Но давайте рассмотрим его более конкретно, на примере образа и контейнера Alpine. Расположение образов Docker Всякий раз, когда вы используете команду docker pull или запускаете docker-compose up -d для подготовки запуска приложений, именно здесь хранятся образы на сервере Ubuntu: /var/lib/docker/overlay2 Здесь Overlay2 является драйвером хранилища Docker по умолчанию в Ubuntu. Вы можете подтвердить это, выполнив команду docker info и поискав Storage Driver: ... Storage Driver: overlay2 ... Если оно отличается от вашего, значит, вы используете другой драйвер хранения для Docker. Аналогично, расположение каталога будет названо в соответствии с тем же драйвером хранения. Доступность драйвера хранилища зависит от поддержки ядра. Определенные местоположения образов Если вы ищете местоположение конкретных образов, вы можете использовать команду inspect в Docker для извлеченного образа. Скажем, например, я извлек образ alpine с помощью команды docker pull alpine. Выполните следующую команду для его проверки: $ docker inspect alpine После выполнения команды вы заметите три поля в подразделе Data в разделе GraphDriver: ... "GraphDriver": { "Data": { "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged", "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff", "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work" }, ... Вышеуказанные каталоги – это физическое расположение данных вашего контейнера внутри хост-системы. Помните большую директорию с хэш-именем: 64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a525ab9e365e из раздела Docker Images? Каталог под ним называется diff, как вы можете видеть в разделе LowerDir после :, который теперь является точкой монтирования контейнера – полученной из базового образа UpperDir! Эти каталоги будут оставаться доступными даже после остановки контейнера. Итак, полный путь, который является общим между образом (MergedDir, UpperDir и WorkDir) и контейнером (точка монтирования LowerDir), следующий: /var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/ После присвоения контейнеру до уровня LowerDir цель образа является смежной, поэтому четыре поля выделяются и основываются на другом каталоге (с новым хэшем) из-за динамической природы последнего, который становится: /var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/ Расположение томов Docker В отличие от образов и контейнеров Docker, физическое расположение томов довольно простое. Тома располагаются по адресу: /var/lib/docker/volumes/ Конкретные места расположения томов В этом случае существует два типа томов. Первый – обычные тома Docker, а второй – bind mounts. Тома Docker Если вы ищете местоположение определенных томов, вы можете сначала использовать команду docker volume ls и проверить имя или ID тома. Например, я запустил контейнер alpine с помощью следующей команды с томом: $ docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine Теперь автоматически будет создан том с именем test-data. Теперь давайте создадим файл test.md в этом месте: ~$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md" Убедитесь, что файл действительно был создан: $ docker exec -ti alpine-container sh / # ls /var/lib/app/content/ test.md / # exit Когда вы запустите docker volume ls, в списке появится том с именем test-data: $ docker volume ls DRIVER VOLUME NAME local d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1 local e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b local test-data Наконец, вы можете подтвердить фактическое расположение файла на вашей хост-системе: $ sudo ls -l /var/lib/docker/volumes/test-data/_data total 0 -rw-r--r-- 1 root root 0 Oct 6 23:20 test.md Поэтому путь для смонтированного тома всегда находится в каталоге с именем _data внутри соответствующего каталога тома. Вы также можете проверить такие пути используя команду docker volume inspect с последующим указанием имени или ID тома и просмотрев параметр Mountpoint в выводе: $ docker volume inspect test-data [ { "CreatedAt": "2021-10-06T23:20:20+05:30", "Driver": "local", "Labels": null, "Mountpoint": "/var/lib/docker/volumes/test-data/_data", "Name": "test-data", "Options": null, "Scope": "local" } ] Монтирование на хосте Расположение привязанных монтирований довольно очевидно и даже более просто, поскольку вы монтируете том непосредственно из расположения на стороне хоста: $ mkdir /home/avimanyu/test-data $ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine В этом случае смонтированный том с именем test-data станет доступен на стороне контейнера как /var/lib/app/content. Заключение В этом кратком руководстве я использовал общий подход на базе Linux, чтобы показать физическое расположение образов Docker, контейнеров и томов, расположенных на вашем Linux-сервере (в данном случае Ubuntu 20.04) на уровне хоста.

Docker – это технология упаковки компонентов вашего стека в виде изолированных контейнеров. Обычная практика – запускать каждый процесс в отдельном контейнере, создавая чистое разделение между компонентами. Это повышает модульность и позволяет использовать преимущества масштабируемости, которые дает контейнеризация. Тем не менее, могут возникнуть ситуации, когда вы захотите запустить несколько сервисов в одном контейнере. Хотя это не является естественным в экосистеме Docker, мы покажем несколько различных подходов, которые можно использовать для создания контейнеров с более чем одним долгоживущим процессом. Определение проблемы Контейнеры Docker запускают один процесс переднего плана. Это определяется инструкциями ENTRYPOINT и CMD образа. ENTRYPOINT задается в Dockerfile образа, а CMD может быть переопределена при создании контейнеров. Контейнеры автоматически останавливаются, когда завершается их процесс переднего плана. Вы можете запускать другие процессы из CMD, но контейнер будет работать только до тех пор, пока жив исходный процесс переднего плана. Сохранение работоспособности контейнера в течение всего срока службы двух независимых сервисов напрямую невозможно с помощью механизма ENTRYPOINT/CMD. Обертывание нескольких процессов Скрипты-обертки – это самое простое решение проблемы. Вы можете написать скрипт, который запускает все ваши процессы и ждет их завершения. Установив этот скрипт в качестве Docker ENTRYPOINT, вы запустите его как процесс переднего плана контейнера, и контейнер будет работать до тех пор, пока один из обернутых скриптов не завершится. #!/bin/bash /opt/first-process & /opt/second-process & wait -n exit $? Этот скрипт запускает бинарные файлы /opt/first-process и /opt/second-process внутри контейнера. Использование & позволяет скрипту продолжать работу, не дожидаясь завершения каждого процесса. wait используется для приостановки работы сценария до тех пор, пока один из процессов не завершится. Затем скриптзавершается с кодом состояния, выданным завершенным сценарием. Эта модель приводит к тому, что контейнер запускает и первый, и второй процессы до тех пор, пока один из них не завершится. В этот момент контейнер остановится, несмотря на то, что другой процесс может быть еще запущен. Чтобы использовать этот скрипт, измените ENTRYPOINT и CMD вашего образа Docker, чтобы сделать его процессом переднего плана контейнера: ENTRYPOINT ["/bin/sh"] CMD ["./path/to/script.sh"] Опция –init контейнера Одна из проблем управления контейнерными процессами – эффективная очистка после их завершения. Docker запускает ваш CMD как процесс с идентификатором 1, что делает его ответственным за обработку сигналов и устранение зомби. Если ваш скрипт не обладает такими возможностями, вы можете оказаться с осиротевшими дочерними процессами, сохраняющимися внутри контейнера. Команда docker run имеет флаг –init, который изменяет точку входа, чтобы использовать tini в качестве PID 1. Это минимальная реализация процесса init, которая запускает ваш CMD, обрабатывает пересылку сигналов и постоянно пожинает зомби. Стоит использовать –init, если вы ожидаете породить много процессов и не хотите вручную заниматься их очисткой. Использование специализированного менеджера процессов Ручное выполнение скриптов быстро становится неоптимальным, если вам нужно управлять большим количеством процессов. Использование менеджера процессов – это еще один способ запуска нескольких служб внутри контейнеров Docker. Менеджер процессов становится вашим ENTRYPOINT и несет ответственность за запуск, обслуживание и очистку рабочих процессов. Существует несколько вариантов реализации этого подхода. supervisord является популярным выбором, который легко настраивается с помощью файла /etc/supervisor/conf.d/supervisord.conf: [program:apache2] command=/usr/sbin/apache2 -DFOREGROUND [program:mysqld] command=/usr/sbin/mysqld_safe Этот конфигурационный файл настраивает supervisord на запуск Apache и MySQL. Чтобы использовать его в контейнере Docker, добавьте все необходимые пакеты в образ, а затем скопируйте конфигурационный файл supervisord в нужное место. Установите supervisord в качестве CMD, чтобы он запускался автоматически при старте контейнера. FROM ubuntu:latest RUN apt-get install -y apache2 mysql-server supervisor COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf ENTRYPOINT ["/bin/sh"] CMD ["/usr/bin/supervisord"] Поскольку supervisord работает непрерывно, невозможно остановить контейнер при завершении одного из контролируемых процессов. Альтернативным вариантом является s6-overlay, который имеет такую возможность. Он использует декларативную модель сервисов, где вы размещаете скрипты сервисов непосредственно в файле /etc/services.d: # Добавим s6-overlay в образ ADD https://github.com/just-containers/s6-overlay/releases/download/v3.1.0.0/s6-overlay-noarch.tar.xz /tmp RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz RUN printf "#!/bin/shn/usr/sbin/apache2 -DFOREGROUND" > /etc/services.d/first-service/run RUN chmod +x /etc/services.d/first-service/run # Используйте s6-overlay в качестве entrypoint ENTRYPOINT ["/init"] Вы можете добавить исполняемый скрипт завершения в каталоги ваших сервисов для обработки остановки контейнера с помощью docker stop. s6-overlay будет автоматически запускать эти скрипты, когда его процесс получит сигнал TERM из-за команды stop. Скрипты завершения получают код завершения своего сервиса в качестве первого аргумента. Код устанавливается в 256, когда служба завершается из-за не пойманного сигнала. Скрипт должен записать код завершения в файл /run/s6-linux-init-container-results/exitcode; s6-overlay считывает этот файл и завершает работу с указанным в нем значением, в результате чего этот код будет использован в качестве кода остановки вашего контейнера. #!/bin/sh echo "$1" > /run/s6-linux-init-container-results/exitcode Когда следует запускать несколько процессов в контейнере? Эта техника лучше всего подходит для тесно связанных процессов, которые вы не можете разделить для запуска в качестве независимых контейнеров. У вас может быть программа, которая полагается на фоновую вспомогательную утилиту, или монолитное приложение, которое самостоятельно управляет отдельными процессами. Приведенные выше приемы помогут вам контейнеризировать такие типы программ. Придерживаясь одного процесса на переднем плане, можно добиться максимальной изоляции, предотвратить взаимодействие компонентов друг с другом и улучшить возможности отладки и тестирования отдельных частей. Вы можете масштабировать компоненты по отдельности с помощью контейнерной оркестрации, что дает вам возможность запускать больше экземпляров наиболее ресурсоемких процессов. Заключение Контейнеры обычно имеют один процесс на переднем плане и выполняются до тех пор, пока он жив. Эта модель соответствует лучшим практикам контейнеризации и позволяет получить максимальную выгоду от технологии. В некоторых ситуациях вам может понадобиться несколько процессов для запуска в контейнере. Поскольку все образы в конечном итоге имеют одну точку входа, необходимо написать скрипт-обертку или добавить менеджер процессов, который возьмет на себя ответственность за запуск целевых бинарных файлов. Менеджеры процессов предоставляют все необходимое, но раздувают образы дополнительными пакетами и конфигурацией. Скрипты-обертки более просты, но могут потребовать использования флага Docker –init для предотвращения разрастания зомби-процессов.

Почему Docker не работает с UFW? UFW задуман как очень простой брандмауэр. Проблема в том, что UFW и Docker пытаются изменить одни и те же базовые правила брандмауэра, и этот конфликт требует дополнительной настройки, если вы хотите запустить UFW и Docker вместе. Если вы настроите базовый брандмауэр UFW на запрет по умолчанию и разрешение HTTP и SSH, это будет выглядеть безопасным, но не будет блокировать запуск контейнеров Docker, привязанных к другим портам. Эту проблему может быть трудно поймать, поскольку UFW и Docker – это отдельные системы. Это может стать серьезной проблемой, если вы не решите ее. Например, возможно, вы хотите запустить дашборд администратора на порту 8000 и внести его в белый список для вашего собственного IP-адреса. Хотя это не самая безопасная настройка, обычно все в порядке, особенно если даш имеет дополнительную аутентификацию. Тем не менее, UFW покажет правило брандмауэра как правильно внесенное в белый список, и оно, конечно, будет видно вам с вашего места, внесенного в белый список. Но если оно запущено через Docker, то по умолчанию оно будет видно на порту 8000 из любого места. Исправление конфигурации Docker Есть решение, которое предлагает Docker: отредактируйте /etc/default/docker или /etc/docker/daemon.json и просто отключите функциональность iptables в Docker: DOCKER_OPTS="--iptables=false" Это работает, однако это лишь половинчатое решение. Это лишает Docker возможности управлять собственными сетями и может привести к тому, что контейнеры вообще не смогут получить доступ в интернет из коробки. Это все еще может работать, но вам придется вручную поддерживать правила iptables для контейнеров Docker и пользовательских сетей, что сложно, раздражает и лишает цель простоты UFW. Реальное решение сложное, но, к счастью, достаточно распространенное, поэтому на Github есть полезная публикация с подробным описанием проблемы и шагов по ее устранению. По сути, вам нужно изменить конфигурацию UFW в /etc/ufw/after.rules и добавить следующий блок в конце: # BEGIN UFW AND DOCKER *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] " -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER Вы можете сделать это вручную, но в этом репозитории есть хорошая утилита, которая автоматизирует это и предоставляет несколько полезных команд для проверки реального состояния брандмауэра. Вы можете загрузить ее из этого репозитория: sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker sudo chmod +x /usr/local/bin/ufw-docker Затем установите конфиг и перезапустите UFW. ufw-docker install sudo systemctl restart ufw После перезапуска изменения должны применяться автоматически, но если они не применяются, вам может потребоваться перезапустить Docker или вашу машину в целом. После включения все порты должны быть правильно заблокированы. Белые списки портов контейнеров Docker с помощью UFW Это решение потребует от вас немного другой конфигурации портов. В утилите ufw-docker есть команда, которая выборочно вносит порты в белый список для определенных контейнеров Docker. ufw-docker allow httpd 80 Однако если вы хотите использовать более продвинутое правило, например, белый список на основе IP, вам придется использовать ufw route allow ufw route allow proto tcp from 1.2.3.4 to any port 9443 Credits: Информация из интернета.