Поиск

DWG - UI Обсуждение DWG » | DWG-CLI » | DWG-UI » | DWG-DARK » | DWG [multi] » Информация носит ознакомительный характер. Пожалуйста не нарушайте действующего законодательства вашей страны. Сборка DWG-UI включает в себя: Веб интерфейс для управления клиентами Wireguard - WG Easy. Контейнер c Unbound предоставляет собственный DNS сервер с кэшированием DNS и дополнительными параметрами конфиденциальности. Контейнер c AdGuard Home (более современный аналог чем PiHole) используется для блокировки рекламы, аналитических трекеров и редактирования списка используемых DNS серверов к которым обращается Unbound. Имеет очень полезную функцию параллельных запросов, DNS которой нет в PiHole. Контейнер с WireGuard используется непосредственно для запуска серверной части Wireguard VPN Основные репозитории с обновлениями на GitHub: GitHub - DigneZzZ/dwg: dwg-universal GitHub - DigneZzZ/dwg-ui: Combination Wireguard + Adguard Home + Unbound (DoH include) Требования: Чистый пустой сервер. Первым делом нам нужно арендовать хороший и быстрый сервер. Берем какой вам подходит лучше по скорости и получаем бонус 15% (если пополнить в первые 24часа регистрации) на пополнение баланса: https://aeza.net/?ref=377137 Замерить скорости можно здесь: Aéza (aeza.net) Поддерживаемые операционные системы (где проверена работоспособность): Ubuntu 20.04, 22.04, 23.10, Debian 11, 12, Centos 8,9 Скрипт устанавливает все автоматически. Все комментарии по скрипту внутри в комментариях. Команда установки: 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!!! Адреса веб-интерфейсов: WG-Easy web-ui: yo.ur.ip.xx:51821 #вместо yo.ur.ip.xx введите IP своего сервера, пароль введите тот что присвоили при установке Доступ в web-ui из сети WG: http://10.2.0.3:51821 AdGuard HOME: http://10.2.0.100/ Логин: admin Пароль: admin # Скрипт для смены пароля AGH bash <(wget -qO- https://raw.githubusercontent.com/DigneZzZ/dwg/main/change.sh)

Вторая часть про мониторинг proxmox Вступление, или не будем ждать проблем, когда они придут В один не слишком прекрасный день я осознал, что то, что когда-то началось как одна Яндекс.Лайт-станция, за год превратилось в достаточно крупную и сложную распределенную домашнюю систему. В ней участвуют порядка четырех мини-серверов и пяти роутеров, разбросанных по трем локациям, а также нескольких удаленных серверов. В момент прозрения меня посетила мысль: нужно как-то контролировать всю эту инфраструктуру, следить за температурой (ведь лето близко!) и свободными дисковыми и оперативными ресурсами. Изначально, когда я только начинал строить свой умный дом на базе Home Assistant, я старался втянуть в него всё, включая статистику. Однако со временем до меня дошло, что это не очень удобно (на каждой локации статистика собиралась в своем Home Assistant) и не слишком надежно (ведь HA не самая стабильная из всех систем, особенно при установке на базе Armbian). Более того, в умном доме не всегда нужны такие обширные данные, а то, что действительно важно, можно собирать более точечно. Сразу оговорюсь, что я не считаю своё мнение единственно верным в данном вопросе. Большая часть моих знаний по администрированию основана на собственном опыте, который можно сравнить с хождением по граблям. Требования к системе и результаты поиска Мои размышления привели к тому, что я решил развернуть отдельную систему мониторинга для всей домашней инфраструктуры, и начали поиски... Но сначала граничные условия: Использование docker. Я являюсь приверженцем использования docker контейнеров по максимуму так как это позволяет легко и быстро разворачивать и обновлять систему не заботясь о зависимостях. Легковесность. В планах было запустить основной (резервный, но об этом дальше) мониторинг на свободной железке tv-box под управлением armbian c 1Gb ОЗУ. Универсальность. Зоопарк систем не самый впечатляющий но он есть, и не хотелось сильно ограничивать себя в дальнейшем. Гибкость настроек, желательно с возможностью использования шаблонов. Первый мой выбор пал на систему Zabbix, это профессиональный инструмент мониторинга серверов с гибкой настройкой и большим количеством возможностей. Но проблема Zabbix в его перегруженности, да это отличный профессиональный инструмент с большим количеством возможностей. В моих изысканиях я столкнулся со следующими проблемами: Развертывание в докере хоть и описано но работает очень плохо, приведенный вариант docker compose переусложнен и стартует не всегда (пробовал и в виртуалке Debian и на armbian), документация по установке докера хоть и описана но мягко говоря оставляет желать лучшего (не описаны некоторые очень важные параметры запуска docker compose для полноценной работы). Система тяжелая. Изначально я все разворачивал на своей мини машинке armbian и думал что проблема в первую очередь с ней, но даже при переезде на виртуалку с выделенными 2Gb озу Zabbix их съел и просил еще, а в тот момент был подключен только 1 сервер для мониторинга… Усложненные настройки и не самый очевидный интерфейс. Увы но мы живем в эпоху упрощения UI, и сотни настроек и параметров Zabbix для неподготовленного пользователя выглядят страшно. Zabbix agent в докере работает очень странно… Следующим этапом стал новый поиск вариантов реализации, который привел к стеку Telegraf + InfluxDB + Garfana. Скажу сразу данный вариант показался мне более интересным и удобным, не только из за красивой визуализации графаны (которую можно и к Zabbix прикрутить) но скорее из за возможностей InfluxDB. InfluxDB — система управления базами данных с открытым исходным кодом для хранения временных рядов; написана на языке Go и не требует внешних зависимостей. Основной фокус — хранение больших объёмов данных с метками времени, и их обработка в условиях высокой нагрузки на запись Я сразу разворачивал вариант на базе influxDB v2 которая в сравнении с версией 1 про которую написано больше всего материалов в сети намного, прям на очень много интересней. Да и это уже не только база данных а нечто большее… После разворачивания influxDB поднимает web api и интерфейс, в котором можно: Управлять доступом Создавать и управлять корзинами (изолированными базами) Просматривать данные с помощью запросов и конструктора Настраивать уведомления путем запросов (в open source варианте доступно только slack и http из интерфейса, но есть способ отправлять и в телеграмм) Настройка дашбордов для мониторинга данных через запросы (или конструктором) Конструктор настроек для агентов сбора данных с возможностью хранения Красивый интерфейс… ну а куда без этого в наше время. Немного примеров интерфейса: Общая схема работы системы У influxDB в принципе очень хорошая документация, но вот примеры в других источниках в основном рассчитаны все таки на старую версию influxdb v1, в некоторых аспектах это может приводить к сложностям настройки, но в основном обратная совместимость осталась. В принципе все системы мониторинга работают по похожей схеме Host -> Агент -> База данных -> Визуализация. В данной системе influxDB является краеугольным камнем, а для него основной (и рекомендуемый) вариант агента является telegraf. Это удобный и универсальный инструмент который позволяет как собирать данные с текущего устройства так и выступать в роли некоего прокси который будет собирать данные с удаленных устройств и передавать их дальше (сразу в базу или в другие варианты вывода). Grafana используется для визуализации и уведомления по условия, фактически при использовании influxDB v2 явной необходимости в ней уже нет, но под нее еще много удобных шаблонов так что пока пусть будет. Сразу оговорю так как система распределенная я постараюсь уточнять что и где мы устанавливаем, но основная идея следующая: InfluxDB + Grafana установлены на сервере мониторинга (в моем примере 192.168.0.135) Агент для мониторинга серверов linux установлены на каждом наблюдаемом устройстве Агент в роли прокси (для сбора данных с роутеров) установлен на сервере мониторинга (но может быть размещен в любой точке сети) Разворачивание и первоначальная настройка InfluxDB v2 Вступление получилось слишком долгим так что поехали. Начнем с установки influx + Grafana. Для этого использую следующий docker compose шаблон: version: '3.6' services: influxdb: image: influxdb:latest container_name: influxdb restart: always ports: - '8086:8086' volumes: - /docker/influxdb/data:/var/lib/influxdb2 - /docker/influxdb/config:/etc/influxdb2 grafana: image: grafana/grafana container_name: grafana-server restart: always depends_on: - influxdb environment: - GF_SECURITY_ADMIN_USER=admin - GF_SECURITY_ADMIN_PASSWORD=admin links: - influxdb ports: - '3000:3000' volumes: - grafana_data:/var/lib/grafana volumes: grafana_data: {} Обратите внимание что графана сохраняет свои файлы в volumes а не в монтируемые папки, только в такой вариации у меня получилось запустить ее с монтированием папок на диск. Так же можно использовать дополнительные переменные для инициализации подробнее описано тут: https://hub.docker.com/_/influxdb Но я советую все же для удобства использовать первичную настройку. Запускаем докер контейнер командой и заходим на веб интерфейс influxdb по адресу http://<IP Serever>:8086 Нас встречает приветственное меню Influx для первоначальной настройки Заполняем данные, инициализации. Тут отдельно надо уточнить про поля организации и корзины. Фактически influx делит все ваши данные на изолированные базы на верхнем уровне организации и на более низком уровне корзины bucket, если проводить аналогии с первой версией bucket это старые вариации базы данных, именно в них попадают данные. При сборе данных нам будет важны эти параметры, но bucket можно спокойно создавать и удалять сколько надо из интерфейса. На следующей странице будет токен для api администратора, обязательно его сохраните это важно!!! Обратите внимание кнопка копирования может не сработать! Только с использованием токена можно работать через командную строку с базой, но токен можно сгенерировать новый через веб. В принципе на этом вся настройка закончена… на главной странице есть инструкция как настроить использование influxdb cli (работает через api) и приведены инструкции и ссылки на документацию с видео. Первоначальная настройка Grafana и подключение к InfluxDB Заходим по адресу http://<IP Serever>:3000 где нас встречает окно авторизации. Если не были заданы пароль и пользователь по умолчанию при инициализации то заходим с данными admin\admin и меняем пароль. Для настройки пользователей переходим в раздел Administration – Users and access - Users Для подключения Grafana к influxdb создаем токен доступа к корзине данных. Для этого возвращаемся в influxdb в меню идем Load Data – API Tokens и создаем Custom API Token даем ему право только на чтение (если не собираетесь запросами графаны менять данные) и даете понятное название. Больше нечего давать не надо. Сохраняем себе токен, он понадобиться для настройки Grafana. Обратите внимание кнопка копирования может не сработать!!! Возвращаемся в Grafana и добавляем новый источник данных. Для этого переходим в connections и выбираем новый источник данных influxdb. Вторая версия InfluxDB использует как основной вариант языка запросов flux но многие существующие шаблоны используют старый вариант на базе influxQL, но в самой Grafana при использовании такого варианта нет возможности авторизации по токену, а авторизация во второй версии является обязательной. Для этого необходимо отдельно добавит строку Custom HTTP Headers. Альтернатива использовать логин и пароль для InfluxDB Details, но это не рекомендуемый вариант. Заполняем настройки: Имя советую давать по именам корзин\bucket к которым даете доступ что бы не путаться. В поле url можно указать ip вашего сервера, но лучше использовать вариант с доменным именем контейнера. Авторизацию выключаем Добавляем Custom HTTP Headers в поле Header указываем Authorization в поле value пишем так: Token <ВашТокенДляЧтенияИзInflux> Пробел после Token обязателен В поле database указываем имя корзины HTTP метод GET Ниже пример настроек: Для варианта с языком flux все несколько проще: В поле токен пишем только сам токен без каких-либо дополнений. Фактически настройка самой системы мониторинга на этом закончена дальше необходимо создавать дашборд панели и события, но нам все еще надо собрать данные о системе и с этим нам поможет telegraf. Сбор данных о сервере с помощью telegraf Перед запуском нам надо получить файл telegraf.conf в интернете есть достаточно много примеров о том как его составлять и подробно описаны какие модули есть, но нам на помощь снова придет influxdb v2. Заходим в inffluxdb по адресу http://<IP Serever>:8086, нас интересует пункт меню telegraf Создаем новую конфигурацию и выбираем что хотим собирать и куда складывать данные. В конструкторе изначально есть возможность выбрать только один вариант, после создания есть возможность добавить дополнительные модули или заменить на готовый файл конфигурации. Получим шаблон настроек, который заменяем на нужный нам: Текст шаблона для получения основных показателей: [[inputs.cpu]] percpu = false totalcpu = true collect_cpu_time = false report_active = false # Read metrics about disk usage by mount point [[inputs.disk]] ## By default stats will be gathered for all mount points. ## Set mount_points will restrict the stats to only the specified mount points. mount_points = ["/"] ## Ignore mount points by filesystem type. # ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"] [[inputs.diskio]] devices = ["sd?", "nvme?", "nvme?n?"] # Get kernel statistics from /proc/stat #[[inputs.kernel]] # collect = ["psi"] # Provides Linux sysctl fs metrics [[inputs.linux_sysctl_fs]] # no configuration # Read metrics about memory usage [[inputs.mem]] # no configuration [[inputs.nstat]] # interfaces = ["en*", "eth*", "ib*", "wl*"] [[inputs.netstat]] # no configuration # Get the number of processes and group them by status [[inputs.processes]] # no configuration # Read metrics about swap memory usage [[inputs.swap]] # no configuration # Read metrics about system load & uptime [[inputs.system]] # no configuration [[inputs.temp]] # no configuration Сохраняем после замены указав понятное название шаблону. Если мы планируем запускать без докера нам приводится инструкция как все быстро запустить. Копируем себе токен из первого поля все что идет после export INFLUX_TOKEN= Почему мы используем этот вариант для докера если у нас не получиться быстро загрузить конфиг по ссылке? Все очень просто теперь у нас всегда есть заготовленный шаблон конфига в самой системе influxdb. Нажимаем на название конфига и у нас открывается окно с полным шаблоном конфига, нам надо найти секцию [[outputs.influxdb_v2]] и в ней указать token который получили раньше. Формально это не рекомендуется и в продакшен все же так делать не стоит но у нас этот токен и так строго ограничен на запись одной конкретной корзины данных, так что пойдет. Так же в конфиге надо указать hostname в секции [agent] для того что бы корректно различать с какого хоста нам поступили данные. Сохраняем себе конфиг и идем на сервер, который хотим подключить. Нам надо поместить наш полученный файл по пути который указан в докере telegraf в моем примере /docker/telegraf/telegraf.conf Важный момент выходов, как и входов у telegraf может быть несколько в том числе и однотипных. Таким образом мы можем одновременно передавать данные в две базы influxdb или, например публиковать на сервер mqtt для использования в системе умного дома. Я в своей реализацию использую два сервера influxdb для сбора статистики одновременно, один для визуализации второй как резервная статистика на базе armbian tv box. Создаем docker compose файл по шаблону: version: "3" services: watchtower: image: telegraf:latest container_name: telegraf environment: - HOST_ETC=/hostfs/etc - HOST_PROC=/hostfs/proc - HOST_SYS=/hostfs/sys - HOST_VAR=/hostfs/var - HOST_RUN=/hostfs/run - HOST_MOUNT_PREFIX=/hostfs - TZ=Europe/Moscow volumes: - /:/hostfs:ro - /docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro После размещения конфига запускаем контейнер и проверяем что данные начали поступать в базу. Для этого идем в influxdb – data explorer Все теперь данные собираются и пишутся в базу, а Grafana уже может эти данные получать и визуализировать. Визуализация данных Покажу визуализацию на примере шаблона https://grafana.com/grafana/dashboards/20762-telegraf-system-metrics/ Чаще всего в шаблонах описано все что нам надо, но в первую очередь обращаем внимание на источник данных если не уточняется то по умолчанию считается что надо источник influx v1 это первый вариант подключения. Идем в меню Grafana пункт Dashboards Создаем новый путем импорта шаблона, можно использовать или номер шаблона или json. Указываем источник, для данного примера нам надо вариант обычный вариант Вот и все мы молодцы и имеем красивую панель мониторинга со всей информацией по серверу Несколько полезных советов по импорту: Если что то не работает в первую очередь проверьте в настройках импортируемого дашборада переменные что они корректно заданы под ваши настройки, иногда шаблоны не самого лучшего качества имеют захардкоженые имена корзин. Если хотите добавить новый блок удобней составлять запрос в Influxdb конструктором и взять от туда готовый вариант запроса для консоли. На этом основные настройки закончены, из Grafana можно настроить уведомления по условиям запросов практически в любой меседжер. Можно бесконечно совершенствовать таблицу или объединять данные с разных серверов на сводную таблицу, возможностей уйма но основная задача данного материала это базовая настройка. В дальнейшем расскажу как настроить мониторинг proxmox и роутеров на базе keenetic и openwrt. Вторая часть про мониторинг proxmox P.S. Делитесь хорошими и удобными панелями для Grafana или influxDB

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 Первым делом нам нужно арендовать хороший и быстрый сервер. Берем какой вам подходит лучше по скорости и получаем бонус 15% (если пополнить в первые 24часа регистрации) на пополнение баланса: https://aeza.net/?ref=377137 Замерить скорости можно здесь: Aéza (aeza.net) Скрипт устанавливает все автоматически. Все комментарии по скрипту внутри в комментариях Самая быстрая установка - 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 и добавлением в исключение.

ShadowSocks решения: Marzban Quick | Marzban Full | Marzban Node | x-ui | 3x-ui | 3x-ui Docker Всем привет В продолжении прошлой темы. Решил опубликовать набор самых основных настроек и установки в докер. Первым делом нам нужно арендовать хороший и быстрый сервер. Например можно рассмотреть: 1. Aeza: получаем бонус 15% (если пополнить в первые 24часа регистрации) на пополнение баланса: https://aeza.net/?ref=377137 2. На крайний случай 4vps: 4VPS.su (2Гб\с сервера) 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

Вступление, или очередная проблема из неоткуда Система бэкапов Proxmox (PBS) является достаточно мощным и удобным инструментом для создания резервных копий виртуальных машин Proxmox, но она имеет одну проблему, которая мешала мне для организации задуманной мной системы домашнего сервера. PBS не может делать синхронизацию с удаленным каталогом по протоколу SAMBA. Синхронизация бэкапов в PBS доступна только между несколькими экземплярами самого сервера бэкапов, то есть для переноса бэкапов на другое устройство там должен быть установлен Debian с пакетом PBS. Альтернативой может являться создание хранилища данных в удаленной папке, созданной по протоколу NFS. В моем случае стояла задача восстановить исходную схему резервирования бэкапов, которая была реализована до перехода на создание бэкапы с помощью PBS, когда резервные копии также переносились на мой основной компьютер, откуда отправлялись на внешний диск. Так как основной компьютер работает под управлением Windows, возникли неожиданные сложности. NFS не поддерживается не серверными версиями Windows, остаются только сторонние варианты реализации. Но и в такой ситуации есть ряд подводных камней, фактически NFS будет являться просто сетевой папкой, куда складываются бэкапы, следовательно для резервного копирования в момент выполнения задачи компьютер с данной папкой должен быть включен. В результате моих поисков было найдено два основных варианта для решения поставленной задачи: 1. Запустить виртуальную машину с PBS 2. Запустить PBS в Docker-контейнере В дальнейшем я выбрал вариант запуска через Docker-контейнер, так как он для меня оказался более удобным и менее прожорливым по ресурсам (вся система Docker с запущенным PBS потребляет до 700 Мб ОЗУ). Также мне было откровенно лень разбираться с пробросом портов из виртуальной машины и еще пачкой ненужных задач. Для виртуальных машин Proxmox - ван лав. Так же данный способ подойдет для запуска на NAS. Установка и запуск PBS в докере Данный способ является не рекомендуемым и явно не поддерживаемым, для большей стабильности рекомендую использовать вариант запуска через виртуальную машину. Настройка синхронизации между двумя экземплярами PBS будет описана в следующем разделе. Для установки PBS на Debian в виртуалке приведен на оффициально сайте: https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-debian Для запуска докер в Windows необходимо установить docker desktop с официального сайта https://www.docker.com/products/docker-desktop/ для полноценной работы потребуется регистрация на докер хаб. После установки и первого запуска попадаем в стартовое окно docker desktop которое на самом деле очень бесполезное, в дальнейшем он нам понадобиться только для администрирования контейнера. В принципе этой установки должно быть достаточно, но лучше так же установить WSL если не был установлен ранее. Идем в Microsoft Store (да на удивление он все еще живой, сам в шоке) и находим там Windows Subsystem for Linux. Данная подсистема предназначена для запуска Linux системы прямо в Windows без использования стороннего софта для виртуализации, а так же его использует докер. Переходим в настройки докера и включаем запуск при старте Windows и включаем WSL2/ В принципе данных настроек должно быть достаточно для запуска необходимого нам контейнера. Но дополнительно настроим что бы докер не съедал наши ресурсы до бесконечности, по умолчанию потребление. Идем в основную папку пользователя: C:\Users\UserName И создаем там файлик со следующим именем: .wslconfig Открываем файл через любой текстовый редактор (рекомендую Notepad ++) И вставляем следующий конфиг: [wsl2] memory=1GB processors=1 Данная настройка вступит в силу после перезагрузки компьютера. Таким образом мы ограничиваем работу докера что бы он мог использовать не более 1Гб озу и не более одного виртуального ядра, чего для наших задач достаточно. Отдельно отмечу что минимальный объем может быть 1Гб так как происходит округление до целых значений. Данное ограничение действует на весь WSl в целом. Подробней о данном конфиг файле можно почитать тут: https://learn.microsoft.com/ru-ru/windows/wsl/wsl-config На этом предварительный этап закончен, приступаем непосредственно к запуску PBS. Сам проект задумывался для того что бы запускать PBS на NAS с поддержкой докера что в принципе является не плохим решением. Подробней с ним можете ознакомиться по ссылке: https://github.com/ayufan/pve-backup-server-dockerfiles Приступаем к запуску, для этого создадим папку в которой будет храниться конфиги и все данные нашего PBS (при желании можно развести их по разным папкам путем модификации docker compose). Нам потребуется вот такая структура папок: Создаем в корнейвой папке новый файл с именем docker-compose.yml и вставляем следующий конфиг: version: '2.1' services: pbs: image: ayufan/proxmox-backup-server:latest container_name: pbs hostname: hostName mem_limit: 128Mb environment: - TZ=Europe/Moscow volumes: - D:\Proxmox Backup Server\etc:/etc/proxmox-backup - D:\Proxmox Backup Server\logs:/var/log/proxmox-backup - D:\Proxmox Backup Server\lib:/var/lib/proxmox-backup - D:\Proxmox Backup Server\backups:/backups ports: - 8007:8007 tmpfs: - /run restart: unless-stopped stop_signal: SIGHUP Изменяем параметры volumes на свои а так же устанавливаем hostname для адекватного отображения имени хоста в интерфейсе PBS. Сохраняем файл и открываем консоль windows. Вводим стандартную команду запуска docker compose docker compose up -d В моем случае произошёл перезапуск контейнера, при первом запуске будет вывод о загрузке и сборке image. Возвращаемся в окно docker desktop и видим появившийся новый контейнер и потребление выделенных ресурсов. Фактическое потребление (зарезервировано) для системы в моем случае: На это этап запуска PBS в докере закончен, приступаем к непосредственной настройке синхронизации. Настройка нового экземпляра PBS Заходим в веб морду нашего нового экземпляра PBS по адресу: https://<Ip-pc>:8007/ По умолчанию доступен один пользователь: admin с паролем pbspbs Заходим в систему и приступаем к настройке. Нам необходимо создать хранилище данных, для этого нажимаем «Добавить хранилище данных». Путь к хранилищу указываем на папку, которую прокинули из компьютера для хранения бэкапов. Тут же настроим задание проверки резервных копий на целостность. Следующим шагом необходимо настроить права для работы с полученным хранилищем. Идем в радел управление доступом и создаем нового пользователя: Нам необходимо создать нового пользователя и сменить пароль для существующего. Так же выдаем права пользователю: В моем примере хранилище данных называется deniom-pc. В хранилище данных должно быть так: Настройка синхронизации между экземплярами PBS Основные настройки будут происходить на вторичном PBS который будет вытягивать бэкапы из PBS на хосте proxmox. Данные настройки выполняем под пользователем admin так как могут быть проблемы с правами. Подключаться мы так же будет через root пользователя к основному серверу. В идеале необходимо разграничивать права и использовать ограниченного пользователя. Переходим в удаленные хранилища, и добавляем новое подключение Заполняем данные для авторизации на основном сервере PBS. Отдельно надо отметить поле отпечаток, он нужен для установки ssl соединения между нашими системами. Что бы его получить возвращаемся в интерфейс PBS основного сервера PBSи на вкладке панелью мониторинга нажимаем показать отпечаток. Переходим в хранилище данных и настроим синхронизацию В данной настройке будет выполняться попытка синхронизации каждых два часа. Заключение На этом настройка фактически завершена, на самом деле мы имеем практически полноценный экземпляр PBS. Так же мы можем подключить данный экземпляр PBS напрямую к proxmox и делать бэкапы прямо в него, данное решение будет удобно для установки на NAS. Спасибо за внимание.

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 контейнеров отнимет у вас много времени и сил. Для подключения к VPN используется бесплатный WireGuard клиент доступный для Windows, MacOS, IOS, Android, Linux. С помощью DWG вы сможете разворачивать собственные полные или разделенные туннели WireGuard VPN с возможностями блокировки рекламы и трекеров (через Pihole или AdGuard Home) и собственным DNS сервером Unbound с дополнительными параметрами конфиденциальности. В дальнейшем могут появиться сборки с новым функционалом. Требования: Только что установленная операционная система Ubuntu 20.04, 22.04; Debian 11, Centos 8,9 Данная страница является общей для обсуждения сборок DWG. Любые идеи и новые реализации сборок Docker Wireguard приветствуются

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

Всем привет Периодически получаю запросы на помощь, как открыть доступ к контейнеру после установки 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 Это правило разрешает входящий трафик на порт 8080 для сети network1. sudo ufw allow in on network2 to any port 8080 proto tcp Это правило разрешает входящий трафик на порт 8080 для сети network2. sudo ufw allow in on network1 from network2 Это правило разрешает входящий трафик из сети network2 в сеть network1. sudo ufw allow in on network2 from network1 Это правило разрешает входящий трафик из сети network1 в сеть network2. 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" Здесь разберем каждый атрибут команды для понимания их значения: docker run: Эта часть команды используется для запуска контейнера Docker. -it: Данный флаг указывает на выделение терминала и интерактивный режим. --rm: Этот флаг означает, что контейнер будет удален после завершения его работы. --privileged: Данный флаг предоставляет контейнеру привилегированный доступ, позволяя выполнять привилегированные операции. --pid=host: Этот параметр позволяет контейнеру использовать PID хост-системы. debian: Это имя образа контейнера, который будет запущен. nsenter: Эта команда позволяет войти в пространство имен другого процесса. -t 1: Данный аргумент указывает на PID процесса, в контексте которого будет выполнена команда (в данном случае, PID 1, который является процессом init). -m -u -n -i: Эти флаги означают, что nsenter будет входить в пространства имен mount, UTS, network и IPC соответственно. sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward": Эта часть команды выполняет команду внутри контейнера, в данном случае, устанавливает значение 1 для параметра ip_forward в файле /proc/sys/net/ipv4/ip_forward, что активирует маршрутизацию между сетями. Эта команда запускает контейнер с привилегиями, необходимыми для изменения параметров ядра. Она активирует маршрутизацию между сетями. 3. Тестирование соединения между контейнерами: docker exec -it container1 bash # apt-get update && apt-get install -y curl # curl container2:8080 Эти команды выполняются в контейнере container1. Они обновляют пакеты и устанавливают утилиту curl, затем выполняется запрос к контейнеру container2 на порт 8080. docker exec -it container2 bash # apt-get update && apt-get install -y curl # curl container1:8080 Аналогичные команды выполняются в контейнере container2 для проверки соединения с container1. После выполнения этих шагов контейнеры должны успешно обмениваться данными между собой. Важно также убедиться, что правила файрвола настроены корректно и не блокируют доступ между контейнерами.

Концепция контейнеров 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: Информация из интернета.