Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга
Иногда нужно исследовать работу бэкенда мобильного приложения. Хорошо, если создатели приложения не заморачивались и все запросы уходят по «голому» HTTP. А что, если приложение для запросов использует HTTPS, и отказывается принимать сертификат вашего корневого удостоверяющего центра, который вы заботливо внедрили в хранилище операционной системы? Конечно, можно поискать запросы в декомпилированом приложении или с помощью реверс-инжиниринга вообще отключить применение шифрования, но хотелось бы способ попроще.
Что такое certificate pinning?
Даже при использовании HTTPS пользователь не защищен от атак «Человек посередине», потому что при инициализации соединения злоумышленник может подменить сертификат сервера на свой. Трафик при этом будет доступен злоумышленнику.
Справиться с такой атакой поможет certificate pinning. Эта защитная мера заключается в том, что разработчик «зашивает» в приложение доверенный сертификат. При установке защищенного соединения приложение проверяет, что сертификат, посылаемый сервером, совпадает с (или подписан) сертификатом из хранилища приложения.
Обход certificate pinning
В качестве подопытного выберем приложение Uber. Для анализа HTTP-трафика будем использовать Burp Suite. Также нам понадобится JDK и Android SDK (я использую все последней версии). Из Android SDK нам понадобится только утилита zipalign, так что при желании можно не скачивать весь SDK, а найти ее на просторах интернета.
Заранее облегчим себе жизнь, добавив следующие пути к нужным утилитам в переменную окружения PATH:
Открываем Burp, заходим в Proxy – Options – Add и добавляем Proxy Listener на интерфейсе, который будет доступен подопытному Android-устройству (или эмулятору). На устройстве в свою очередь настраиваем используемую Wi-Fi сеть на использование только что включенного прокси.
Скачаем apk-файл через apkpure.com, установим приложение на устройство и попытаемся войти в свой аккаунт – приложение зависнет на этапе аутентификации.
В логах Burp Suite (вкладка Alerts) при этом мы увидим множественные отчеты о неудачных SSL-рукопожатиях. Обратите внимание на первую строчку – именно через сервер cn-geo1.uber.com в моем случае осуществляется аутентификация, поэтому и не удается войти в приложение.
Дело в том, что Burp Suite при перехвате HTTPS-соединений (а мы помним, что все соединения устройства проксируются через него) подменяет сертификат веб-сервера на свой, который, естественно, не входит в список доверенных. Чтобы устройство доверяло сертификату, выполняем следующие действия. В Burp заходим в Proxy – Options и нажимаем Import/export CA certificate. Далее в диалоге выбираем Export Certificate. Копируем сертификат на устройство, переходим в Настройки – Безопасность – Установить сертификаты и устанавливаем наш сертификат в качестве сертификата для VPN и приложений.
Опять пытаемся войти в свой аккаунт. Сейчас приложение Uber сообщит нам только о неудачной попытке аутентификации – значит прогресс есть, осталось только обойти certificate pinning.
Откроем приложение в вашем любимом архиваторе как zip-архив. В папке res/raw можно заметить файл с говорящим названием ssl_pinning_certs_bk146.bks.
По его расширению можно понять, что Uber использует хранилище ключей в формате BouncyCastle (BKS). Из-за этого нельзя просто заменить сертификат в приложении. Сначала нужно сгенерировать BKS-хранилище. Для этого качаем jar для работы с BKS.
Теперь генерируем BKS-хранилище, которое будет содержать наш сертификат:
На вопрос о доверии сертификату отвечаем «yes». Опять открываем apk в архиваторе и заменяем оригинальное хранилище на наше (сохраняем при этом оригинальное название).
Но на этом все не заканчивается. Каждый apk должен быть подписан сертификатом разработчика. К счастью, это делается не для обеспечения безопасности, а для идентификации приложений, поэтому для наших исследовательских целей мы вполне можем использовать и недоверенный сертификат.
Удаляем из apk папку META-INF со старой подписью приложения и приступаем к генерации новой.
Создаем хранилище ключей и генерируем в нем ключ для подписи apk:
Подписываем только что сгенерированным ключом наш APK:
Теперь осталось выровнять данные в архиве по четырехбайтной границе:
Что такое Traffic Inspector и с чем его едят
Система Traffic Inspector уже давно завоевала популярность среди системных администраторов благодаря своей гибкости, модульной архитектуре, простоте администрирования и мощным функциям для контроля сетевой активности. Такие возможности Traffic Inspector, как защита сети, контроль интернет-трафика, статистика доступа, работа с VPN, NAT, прокси-сервером и Active Directory, блокировка сайтов и фильтрация контента, интеллектуальная маршрутизация и динамическая балансировка нагрузки, сделали это решение ключевым элементом сетевой безопасности во многих организациях малого, среднего и крупного бизнеса.
Однако, как показывает практика, даже профессиональные сисадмины, которые не первый год работают в Traffic Inspector, знают далеко не обо всех возможностях нашего продукта. Поэтому в этой статье мы хотели бы привести полный перечень возможностей системы и кратко прокомментировать наиболее интересные из них. Надеемся, что здесь найдут для себя что-то новое все читатели — и новички, которые еще только присматриваются к Traffic Inspector’у, и опытные сетевые инженеры, которые активно используют Traffic Inspector для управления ИТ-инфраструктурой компании.
Внутренние и внешние сети
• Внутренние сети в Traffic Inspector разделяются на локальные (например, внутриофисная сеть) или публичные (например, внутридомовая сеть), причем для каждой сети можно настроить уникальную политику доступа. Перехват трафика пользователей через другие сервера внутренней сети может осуществляться в специальном режиме сниффера («прослушки»), о котором мы расскажем в следующих статьях. Что касается внешних сетей, то сервер Traffic Inspector способен работать сразу с несколькими внешними интерфейсами (т.е. можно создать несколько одновременных подключений к Интернету), а также корректно разделяет входящий и исходящий трафик на этих интерфейсах (например, при спутниковом подключении). Если внешние интерфейсы являются динамическими, Traffic Inspector автоматически выберет для них оптимальный режим.
• Сервер Traffic Inspector может работать с несколькими внутренними интерфейсами в локальной сети со сколь угодно сложной топологией. В частности, сервер поддерживает работу с 802.3 (Ethernet), 802.11 (Radio Ethernet), WAN PPP и WAN VPN (PPTP, L2TP).
• Имеется поддержка NAT и RAS-сервера, причем для NAT поддерживаются соединения RAS (Dial-out), VPN (PPTP, L2TP) и PPPoE, а для RAS можно использовать модемные и VPN-подключения (PPTP, L2TP).
• Среди дополнительных функций стоит отметить возможность работы клиентов на терминальном сервере и встроенную поддержку протокола IEEE 802.1Q (Tag based VLAN), который служит для передачи информации о принадлежности трафика к определенной виртуальной сети.
• Авторизация пользователей в Traffic Inspector может осуществляться по IP-адресу и/или MAC-адресу, по диапазону IP-адресов, по имени и паролю (в том числе с разных доменов), по адресам электронной почты (используется в SMTP-шлюзе) или через API (для сторонних приложений). В качестве дополнительно параметра авторизации можно также использовать идентификатор виртуальной сети. Всего поддерживается 8192 пользователей и 256 групп.
• Если пользователь еще не авторизован (например, вошел в сеть впервые), система может автоматически перенаправить его на специальную информационную страницу встроенного веб-сервера. Это особенно удобно для сетей Wi-Fi, а также при подключении новых клиентов во внутридомовых сетях.
• Traffic Inspector автоматически отслеживает нарушения правил авторизации. Обнаружив нарушение, система делает запись о нем в сетевой статистике и журнале, а затем оповещает об инциденте администраторов по электронной почте.
Ограничение работы пользователей
• Продолжительность работы пользователей и доступность определенных сетевых ресурсов можно регламентировать несколькими способами: по дате, по расписанию (для всех сразу или для определенных пользователей или их групп), по уровню доступа (с помощью групповых и общих фильтров на запрет или разрешение, которые применяются на сетевом уровне для любого трафика или на прикладном уровне для программ, работающих через прокси-сервер), по IP- и/или MAC-адресам клиента, по доступу к службам (NAT, роутинг, прокси-сервер, SOCKS-сервер), а также по количеству TCP-сеансов (как для трафика через SOCKS, так и для прямого трафика)
• Подсистема Virus Flood Protect для защиты сети и сервера от перегрузки. Эта подсистема анализирует входящий и исходящий трафик пользователя и блокирует доступ при переполнении сетевой статистики или при подозрении на вирус.
• Имеется возможность отключения порта управляемого оборудования по SNMP-протоколу с помощью скриптов в случае изменения состояния клиента.
• Traffic Inspector поддерживает различные варианты учета трафика: по входящему объему, исходящему объему, сумме входящего и исходящего объемов или по максимальному объему между входящим и исходящим.
• В Traffic Inspector можно тарифицировать время работы клиентов и при необходимости задавать объем предоплаченного (бесплатного) трафика. Абонентская плата может начисляться посуточно или поминутно либо предоставляться в кредит, а сами тарифы могут быть изменены задним числом (при каждом их изменении система автоматически пересчитывает статистику биллинга). Дополнительно можно ввести скидки на кэшированный, почтовый или любой другой трафик в соответствии заданными критериями фильтрации либо задать лимиты трафика на сутки, неделю, месяц или особый период.
• Все настройки тарификации могут быть сделаны индивидуальными, групповыми или общими, что позволяет одновременно использовать множество тарифных планов.
• Текущий статус клиента со всеми его параметрами тарификации отображается в реальном времени, а все изменения статуса клиентов записываться в журнал для последующей обработки и формирования отчетов (в том числе групповых).
Контроль внешнего трафика
• Для учета общего трафика, потребляемого у провайдера, имеются контролируемые счетчики, которые описываются как IP-сети. Настроив несколько таких счетчиков, можно вести раздельный учет разных видов трафика (например, платного, льготного и бесплатного). Для контролируемых счетчиков задаются лимиты (общий и дневной), при превышении которых генерируется оповещение от администратора и/или блокируется трафик. При срабатывании блокировок на внешних счетчиках может быть запущено любое внешнее приложение. Данные по внешним счетчикам могут отображаться как в реальном времени и записываться в журнал для формирования отчетов.
• Для дополнительного анализа общего потребляемого трафика могут быть заданы и внешние информационные счетчики, которые могут дополнительно анализировать трафик по IP-протоколу и портам.
• Для пользователей и внешних счетчиков Traffic Inspector может собирать сетевую статистику об IP-адресах, протоколах, портах и DNS-именах, причем администратор может настроить интервал анализа и количество активных соединений. Собранная статистика записывается либо во внутреннюю СУБД, которая при необходимости синхронизируется с внешней базой MSSQL 2005, MySQL или PosrgreSQL.
• Текущая статистика может отображаться в реальном времени и записываться в журнал для последующего анализа и формирования отчетов.
• Встроенный в Traffic Inspector прокси-сервер работает по протоколам HTTP/1.1, FTP и SOCKS 4/5. Аутентификация может быть BASIC (по открытому паролю) или интегрированная через домен Windows (NTLM v. 1/2).
• Прокси-сервер включает в себя мощные функции кэширования для экономии трафика и позволяет назначать отдельным ресурсам гибкие настройки параметров кэширования. Весь кэш хранится в одном файле СУБД, причем его внутренняя фрагментация полностью исключена. Все индексы кэша хранятся в оперативной памяти, что обеспечивает высокую скорость чтения и записи.
• Для фильтрации контента прокси-сервер Traffic Inspector использует общие с IP-фильтрами списки, но для него есть возможность также задавать тип контента и вести анализ протокола и URL вплоть до контекстного поиска по регулярным выражениям, что позволяет, например, легко «вырезать» баннеры.
• Имеется также поддержка метода HTTP CONNECT – через прокси-сервер в этом режиме может работать любое приложение, поддерживающее SSL, FTP или TCP, а также работу через HTTP-туннель.
• Поддержка FTP over HTTP (метод GET) – прокси-сервер генерирует HTML-страницы, позволяя работать с FTP-серверами в режиме чтения, и автоматически переключается между активным и пассивным режимами для протокола FTP.
• По умолчанию прокси-сервер использует сквозную авторизацию, но если пользователь не авторизовался до входа на прокси-сервер, то запрашивается аутентификация через прокси-сервер или SOCKS.
• Автоматическое конфигурирование веб-браузеров согласно действующим в компании стандартам. Прокси-сервер предоставляет клиентам стандартный JAVA-скрипт WPAD.DAT для их конфигурирования, причем в этом скрипте можно указать LAT (таблицу локальных адресов). Кроме того, браузеры можно принудительно настроить с помощью клиентского агента.
• При необходимости прокси-сервер Traffic Inspector способен блокировать HTTP-трафик, а также перенаправлять HTTP-запросы на другой прокси-сервер.
• Клиент, со своей стороны, может оперативно управлять режимами фильтрации и кэширования.
• Кроме того, прокси-сервер может вести журнал обработанных им запросов.
• SMTP-шлюз, встроенный в Traffic Inspector, публикует снаружи один внутренний SMTP-сервер, проверяет достоверность доменов в адресах отправителей, а также запрещает открытые «пересылки» (relay), что позволяет использовать внутри сети простейшие почтовые сервера.
• Имеется проверка хостов отправителей с помощью служб RBL на основе DNS. Многопоточная реализация позволяет задействовать большое количество служб без замедления работы. Через RBL также могут также проверяться и все промежуточные SMTP-серверы.
• SMTP-шлюз ведет «черные списки» хостов отправителей, которые могут заполняться как автоматически, так и вручную. Автоматическое занесение в «черные» списки хостов, отфильтрованных через RBL, позволяет существенно экономить трафик и эффективно бороться со спамом. Кроме того, имеются и «белые» списки, включающие в себя отправителей, для которых фильтрация сообщений применяться не будет.
• Для анализа отфильтрованной почты ведется подробный журнал, а также предусмотрена массовая рассылка для администраторов.
• Поддерживается тарификация входящей почты для известных получателей (пользователей Traffic Inspector). С целью экономии трафика прием почты для неизвестных получателей может быть запрещен.
• Поддерживается интеграция модуля защиты от нежелательной почты Traffic Inspector AntiSpam.
• По умолчанию закрывает все запросы извне, при этом прозрачно разрешая исходящий TCP, UDP и ICM-трафик, поэтому настройка службы практически не требуется.
• Осуществляет динамическую UDP-фильтрацию, что позволяет корректно отличать входящие UDP-запросы от исходящих, прозрачно разрешая исходящие UDP-трафик.
• Предусмотрена динамическая фильтрация FTP-DATA. Производится анализ FTP команд PORT и PASV и выставление временных разрешений в firewall. Это позволяет удобно работать как с активным режимом (клиент), так и пассивным (публикуемый сервер).
• Для управления работой различных серверных приложений или других протоколов можно отдельно задать список разрешающих и запрещающих правил.
• На информационных счетчиках можно вести раздельный учет и анализ отфильтрованного входящего трафика (анализ флуда, сканирования портов и др.).
• Для защиты самого сервера внутри сети также можно включить внутренний фаервол, функциональность которого аналогична внешнему фаерволу. Внутренний фаервол поддерживает индивидуальные настройки для локальных и публичных внутренних сетей.
• Реализована возможность запрета неавторизованого трафика, идущего с самого сервера.
• Шейпер работает с любым трафиком, проходящим через сервер, в том числе через прокси-сервер и SOCKS.
• Шейпер может ограничить индивидуальную скорость работы клиента на прием и/или передачу. Кроме того, ограничение может быть динамическим, когда назначается суммарная максимальная скорость для группы (отдельно на прием и передачу), а также основываться на количестве пакетов, если необходимо предотвратить перегрузку сети во время вирусной эпидемии.
• Шейпер также позволяет задавать в фильтрах тип трафика, который следует исключить из контроля, а также ограничения скорости для каждого типа (однако эти ограничения не распространяются на данные из кэша прокси-сервера и на локальный веб-сервер статистики).
• Кроме того, каждому типу трафика можно назначить приоритет, чтобы менять очередность обработки пакетов во внутренней очереди шейпера и передавать эти данные с минимальными задержками.
• Для всех правил может быть назначено расписание, что позволяет динамически изменять настройки службы этой в зависимости от времени.
• С помощью функций расширенной интеллектуальной маршрутизации можно настроить условное или безусловное перенаправление трафика через заданный внешний интерфейс для группы пользователей, причем при работе через прокси-сервер можно задать также тип HTTP-содержимого.
• Кроме того, поддерживается перенаправление исходящих от клиента TCP-соединений, когда в локальной сети работает сторонний прокси-сервер или когда нужно переадресовать клиента на другой онлайн-ресурс.
Клиентский агент — это специальное приложение, которое устанавливается на компьютеры пользователей и позволяет пользователям самостоятельно выполнять следующие действия:
• Просматривать текущий баланс и настраивать оповещения о недостаточном количестве средств на счете.
• Переключать уровни фильтрации контента для экономии трафика.
• Переключать режимы кэширования прокси-сервера, чтобы быстро просматривать обновляемые ресурсы с минимальными затратами трафика.
• Быстро входить в личный кабинет с помощью контекстного меню агента.
• Изменять свой пароль через агент, если администратор не отключил такую возможность в Traffic Inspector.
• Использовать настольную или онлайн-версию агента (веб-агент). Веб-агент поддерживает все функции настольной версии и доступен на специальной странице сервера Traffic Inspector.
• Получать оповещения от администратора в режиме реального времени.
• Поддержка удаленного управления по стандартной технологии DCOM. Консоль управления выполнена в виде оснастки MMC, что позволяет легко интегрировать ее с другими инструментами администратора.
• Ограничение доступа: можно задать группу администраторов в домене Windows или использовать встроенную аутентификацию по паролю.
• Распределение доступа: можно создать администраторов с ограниченными правами, например, только для добавления клиентов, только для пополнения счетов или только для работы с определенной группой клиентов.
• Поддерживается мониторинг работы клиентов и сетевой статистики в реальном времени.
• Можно просматривать статистику клиентов и пополнять их счета в веб-интерфейсе.
Отчеты
• В Traffic Inspector можно сформировать несколько десятков видов отчетов по трафику, биллингу и сетевой статистике. Все отчеты могут быть импортированы и сохранены в различных видах и форматах – как табличных, так и графических.
• При необходимости, набор отчетов можно расширить при помощи интерфейса автоматизации.
Traffic Inspector – это современное комплексное решение для организации и контроля интернет-доступа. Для его внедрения не нужно приобретать дорогостоящее серверное оборудование или расширять штат системных администраторов. Благодаря своей неприхотливости, гибким правилам тарификации, надежной сетевой защите, эффективной балансировке нагрузки, точному учету и фильтрации трафика, эта система не только защитит вашу корпоративную инфраструктуру, но и сэкономит немало сил, денег и нервов. Дополнительную информацию о Traffic Inspector можно найти на нашем официальном сайте.
Введение в Traefik 2.0
Traefik — это обратный прокси-сервер с открытым исходным кодом, обеспечивающий простую работу с микросервисами и/или просто контейнерами с вашими приложениями.
Обратный прокси-сервер (reverse proxy, реверс-прокси) служит для ретрансляции запросов из внешней сети к каким-либо серверам/сервисам внутренней сети (например веб-сервера, БД или файловые хранилища) и позволяет:
В статье будет описываться использование Traefik в Docker в качестве реверс-прокси для других контейнеров Docker, а также не контейнеризированных сервисов.
Введение
Traefik позиционируется разработчиками как “Edge Router”, то есть можно направить его непосредственно в глобальную сеть одной стороной и во внутреннюю другой. Если у читателя создалось впечатление что таким образом создается единая точка отказа всей системы, то так и есть, но есть несколько моментов: во-первых, Traefik имеет развитый функционал для автоматического восстановления при сбоях; во-вторых, существует Traefik EE — платная версия, в которой помимо прочих преимуществ имеется HA (Hight Availability, Высокая доступность), что подразумевает распределение нагрузки между несколькими экземплярами сервиса (узлами), таким образом при отказе одного его задачи перераспределяются на другие узлы, а отказавший узел отключается и затем немедленно вводится обратно в эксплуатацию. В качестве примечания отметим, что в статье будет рассматриваться бесплатная версия Traefik.
Одним из основных достоинств Traefik является возможность изменения его конфигурации без приостановки работы (“на лету”) при применении любого из поддерживаемых бэкэндов, называемых провайдерами.
Список основных провайдеров:
В рамках этой статьи будут рассмотрены первый и последний провайдеры из этого списка.
Вероятно, не знакомому с темой читателю будет не понятно, чем является провайдер с именем — “File”, это некоторый файл (или папка с файлами), в котором описана конфигурация какого-либо сервиса, не связанного с другими провайдерами, но который должен быть скрыт за реверс-прокси. Остальные же провайдеры являются различными системами оркестрации контейнеров.
Файл конфигурации Traefik, а также файлы для провайдера “File” могут быть написаны на TOML либо YAML, в статье будут приведены примеры на YAML так как этот синтаксис больше нравится автору, а какой-либо функциональной разницы между ними нет, а также не составляет трудности переписать файлы на другой формат конфигурации. Traefik будет развернут в Docker. Для развертывания будет использоваться docker-compose, для обеспечения простоты повторного развертывания.
*В статье будут приведены команды для ОС Linux.
Деплой Traefik
Предполагается что у читателя установлены и настроены docker и docker-compose, их установка выходит за рамки этой статьи.
Для развертывания (деплоя) Traefik создадим файл docker-compose.yml и отредактируем его в любом удобном вам редакторе. Для начала этот файл будет иметь следующий вид:
Во внешний мир будут смотреть порты 80 и 443 для HTTP и HTTPS соответственно. Также пробросим в контейнер сокет демона Docker для работы механизма автоматической конфигурации. Конфигурацию Traefik будем описывать в файле traefik.yml находящемся в папке data в текущей директории.
Если для разделения внешней и внутренней сетей используются networks Docker-а, то Traefik должен иметь доступ к внешней сети и ко всем внутренним в которых находятся целевые сервисы.
Создадим и будем постепенно наполнять этот файл.
Для начала опишем точки входа в наш прокси (те самые порты, которые смотрят во внешний мир):
Здесь http и https это просто названия (могут быть любыми, хоть a и b ) и были выбраны так для удобства.
Теперь добавим первого провайдера — Docker, это делается следующим образом:
Параметром указываем что Traefik не должен брать все контейнеры подряд, далее будет объяснено каким образом мы будем сообщать какие контейнеры нас интересуют. Также здесь видно зачем мы пробрасывали сокет в контейнер — именно через него Traefik будет получать сведения о запускаемых контейнерах на этом хосте (можно подключиться и к демону на другом хосте).
Следующим шагом развернем весь HTTP трафик в HTTPS (почему это было сделано именно таким образом будет описано дальше):
Здесь мы встречаем два из трех основных элементов роутинга в Traefik 2 routers (роутеры) и middlewares(промежуточные обработчики), рассмотрим их подробнее.
Роутеры
Рассмотрим на примере описанного выше роутера:
Подробнее о различных видах правил можно прочитать в документации.
Промежуточные Обработчики
Подробнее о различных обработчиках можно прочитать в документации (дальше в статье будет описан ещё один обработчик — BasicAuth).
Таким образом мы получим первую рабочую конфигурацию. Выполняем
Let’s Encrypt
Поскольку мы хотим использовать HTTPS нам нужно где-то взять SSL сертификаты для сервисов, есть возможность использовать свои сертификаты, но мы настроем автоматическое получение бесплатных сертификатов от Let’s Encrypt.
Добавим в конфигурацию ( traefik.yml ) новый блок:
Docker провайдер
HTTPS настроен, пришло время поднять первый сервис, пусть это будет дашборд самого Traefik, так как Traefik у нас в Docker, воспользуемся этим провайдером.
Для описания конфигурации в Docker Traefik использует метки (labels) контейнеров. Допишем в наш файл docker-compose.yml :
Дашбоард надо включить, для этого добавим в файл traefik.yml :
На данном этапе можно пересоздать контейнер (нужно так как мы меняли docker-compose.yml ):
Когда всё поднимется можно перейти на traefik.example.com (тут на самом деле должен быть ваш домен, который направлен на хост с Traefik) и увидеть дашборд.
Дашбоард это хорошо, но мы не хотим, чтобы все пользователи интернета имели к нему доступ, закроем его от внешнего мира с помощью BasicAuth, для это в Traefik есть специальный middleware.
Для начала сгенерируем для нас строку с логином и паролем (admin/password)^
Теперь добавим в наш docker-compose.yml новые строчки:
Теперь при попытке доступа к дашборду у нас спросят логин и пароль.
Приведем также кофигурацию некого другого сервиса, развернутого через docker-compose (аналогично работает и для обычного docker):
File провайдер
С контейнерами работает, а как быть если есть какой-то сервис работающий на выделенном хосте (пускай IP 192.168.1.222 и порт 8080) и мы его хотим пропустить через этот же прокси, заодно закрыв его с помощью HTTPS. Для этого есть решение.
Добавим в docker-compose.yml ещё один volume :
Пускай описания таких хостов у нас будут лежать в data/custom/ (а что, вдруг ещё появятся).
Добавим в traefik.yml конфигурацию file провайдера для этих файлов:
Перезапускаем Traefik и теперь можно создать файл с описанием нашего отдельного хоста ( data/custom/host.yml ):
Роутер описывался раньше, тут добавилось только service: service-host — связь с нашим сервисом, и конфигурация для TLS.
Описание для сервиса имеет вид:
Дополнительно мы указываем параметр passHostHeader: true чтобы тот хост думал, что он на самом деле смотрит в сеть и прокси нет.
Заключение
Приведем содержание файлов с полученными конфигурациями:
В статье было описано как настроить Traefik в качестве обратного HTTP прокси при использовании провайдеров Docker и File. Было настроено использование бесплатных SSL сертификатов от Let’s Encrypt, настроено принудительное перенаправление клиентов на протокол HTTPS, а также приведен пример настройки аутентификации клиентов прокси перед доступом к сервисам.
Режимы TCP и UDP прокси настраиваются похожим образом с небольшими изменениями (подробнее можно прочитать в документации, например — TCP), эти режимы позволяют проксировать практически любой трафик, создавая возможность сделать Traefik действительно единственным сервисом смотрящим в глобальную сеть.
Бонус. Мониторинг
Traefik позволяет собирать сведения о своей работе в различных форматах, рассмотрим, как это делается при использовании Prometheus.
Добавим новую точку входа:
data/traefik.yml :
И добавим возможность собирать с этого порта метрики для Prometheus, data/traefik.yml :
Приведем содержание файлов с полученными конфигурациями:
