caddy Настройка реверс прокси Caddy и Fail2Ban в docker

[Deniom]

Вступление, или немного о том зачем и почему

В моей домашней системе за последнее время накопилось значительное число сервисов,  для того что бы их использовать в какой то момент стало банально не удобно и не рационально использовать доступ по http и порту. Кроме того существует ряд сервисов которое в принципе не будут работать без использования шифрования. Первоначально в моей системе использовался реверс прокси nginx proxy manager с бесплатными duckdns адресами. Со временем я перешел на использование своего домена.

Важной особенностью моего сценария использования являлось то что реверс прокси использовалось только внутри локальной\впн сети и не имело внешнего доступа на 80/443 порту в сеть. Для получения сертификата обычными средствами необходимо что бы сервер мог оставить запись на 80 порту, но такой сценарий не выполним если у вас нет белого ip или возможности пробросить порты. Сценарий со временным открытием портов для обновления так же мной был признан не самым удобным по причине того что можно банально забыть. Благо для такого есть решение под названием dns challenge. При использовании такого метода подтверждения подлинности сайта выполняется путем изменения dns записи с использованием api. Такой сервис предоставляет ряд провайдеров dns, из подходящих под мои задачи это cloudflare и duckdns.

Для использования многих сервисов cloudflare таких как api и защита от ddos не обязательно покупать у них домен, достаточно просто перенести управление в cloudflare.

Все бы было хорошо система работала с использованием nginx proxy manager, а для внешнего доступа к ресурсам использовалась встроенная публикация сервисов keenetic. Но в один не особо прекрасный момент использования реверс прокси я столкнулся с проблемой что перестали обновляться автоматически сертификаты. Проблема как оказалось достаточна старая и исправления к ней полноценного не было, да и сам npm как по мне казался несколько избыточным и перегруженным для моего сценария использования.

Таким образом началось изучение альтернативных решений для организации реверс прокси. Две самые популярные альтернативы из доступных решений это traefik и caddy.

traefik - это достаточно интересное и универсальное решение, но оно в первую очередь делает упор на динамически изменяемые системы. Очень хорошо работает с докер контейнерами путем установки настроек в метках контейнеров. Но в моем кейсе использования динамическое масштабирование не планировалось и существовало много сервисов которые были запущены без использования докера.

caddy в свою очередь является очень легким в настройке сервисом с большим количеством различных модулей на все случаи жизни. Единственным минусом можно выделить отсутствие интерфейса для настройки, все настройки задаются в файле (но об этом дальше).

В данной статье я не планирую проводить сравнение возможностей traefik и caddy подобных сравнений на просторах сети достаточно, для моей задачи больше подошел caddy.

Все дальнейшее развертывание будет показано с использованием docker-compose. Запуск контейнеров и сборка контейнеров выполнялась в portainer, но вы можете просто создать свой docker-compose файл и запустить без использования portainer.

Базовый вариант настройки Сaddy

Отдельно стоит отметить что сам по себе caddy крайне легковесный но и ограниченный в функционале, значительная часть возможностей предложена в дополнительных модулях. Эти модули можно как добавлять самому при сборке докер контейнера или при запуске apt пакета так и использовать готовые сборки docker с включенными модулями.

На самом деле настройка реверс прокси в Caddy это крайне простая задача. Запустим докер контейнер с использованием следующего docker-compose

version: '3.8'
services:
  caddy:
    image: 'slothcroissant/caddy-cloudflaredns:latest'
    container_name: caddy
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
    environment:
      ACME_AGREE: true
      CLOUDFLARE_API_TOKEN: "aaaaaaaaadssssssssssssssssss"
      CLOUDFLARE_EMAIL: "[email protected]"
    volumes:
      - /docker/caddy/data:/data
      - /docker/caddy/config:/config
      - /docker/caddy/Caddyfile:/etc/caddy/Caddyfile

В данном примере использован готовый caddy контейнер для получения сертификатов с использованием dns challenge cloudflare. Так же существуют готовые сборки для других провайдеров например вот тут предложена неплохая подборка самых распространенных сборок. 

Для получения с сертификата через dns chelenge необходимо создать api ключ на cloudflare, подробней об этом приведено тут.

Теперь создадим файл конфигурации на основании которого будет работать наш сервер. Этот файл называется Caddyfile он не имеет расширения и должен располагаться по пути /docker/caddy/Caddyfile (для данного варианта docker-compose).

nextcloud.mydomain.ru {
  tls [email protected] { 
    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
  }
  reverse_proxy 192.168.0.101:1234
}

Фактически у нас есть всего две секции tls и reverse_proxy. 

Секция tls отвечает за получение сертификата, email можно не указывать он необходим для получения напоминаний от acme о продлении сертификатов.

Секция reverse_proxy описывает сами правила переадресации, для подавляющего большинства сервисов такого варианта настройки будет достаточно, но бывают исключения например vaultwarden.

vaultwarden.mydomain.ru {
  tls [email protected] { 
    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
  }
  reverse_proxy 192.168.0.132:10380 {
	header_up X-Real-IP {remote_host}
  }
}

Обычно если сервис требует особых настроек для реверс прокси в документации приводятся примеры для самых популярных решений, в том числе и caddy.

Для применения изменений необходимо перезапустить докер контейнер.

На этом простой вариант настройки caddy закончен, если вы не планируете использовать его для публикации в интернет то можно использовать как есть и наслаждаться. Главное не забыть правильно указать dns записи.

Если в настройках доменов в cloudflare указать внутренний ip например 192.168.0.132 тогда при использовании их dns можно обойтись без перезаписи и ходить только внутри своей локальной сети по https.

А теперь все становиться чуточку сложнее... настройка Caddy для публикации в интернет

Для использования fail2ban нам необходимо настроить правильное и удобное логирование в caddy. Сам по себе caddy формирует логи в формате json которые в принципе достаточно удобно парсятся но с ними не очень удобно работать для fail2ban, в таком случаем нам на помощь приходит модуль transform-encoder данный модуль позволяет указать шаблон форматирования для логов.

Готового решения докер контейнера caddy-dns/cloudflare и caddyserver/transform-encoder увы найти мне не удалось так что будем создавать свой докер образ. Для этого нам понадобиться следующий Dockerfile.

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/caddyserver/transform-encoder \
    --with github.com/abiosoft/caddy-exec

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Dockerfile размещаем в той же папке где и наш docker-compose файл со следующим содержимым

version: '3.9'
services:
  caddy:
    image: caddy-cloudflare-transform:latest
    build:
     context: .
     dockerfile: ./Dockerfile
    container_name: caddy
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - 80:80
      - 443:443 
    environment:
      ACME_AGREE: true
      CLOUDFLARE_API_TOKEN: "aaaaaaaaassdsadfasfasf"
      CLOUDFLARE_EMAIL: "[email protected]"
      DOMAIN: mydomain.ru
    volumes:
      - /docker/caddy/data:/data
      - /docker/caddy/config:/config
      - /docker/caddy/logs:/logs
      - /docker/caddy/Caddyfile:/etc/caddy/Caddyfile
      

Или можно воспользоваться моим собранным образом размещенным в репозитории https://github.com/Deniom3/caddy-cloudflare-transform

Тогда docker-compose файл будет иметь вид

version: '3.9'
services:
  caddy:
    image: ghcr.io/deniom3/caddy-cloudflare-transform:latest
    container_name: caddy
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - 80:80
      - 443:443 
    environment:
      ACME_AGREE: true
      CLOUDFLARE_API_TOKEN: "aaaaaaaaassdsadfasfasf"
      CLOUDFLARE_EMAIL: "[email protected]"
      DOMAIN: mydomain.ru
    volumes:
      - /docker/caddy/data:/data
      - /docker/caddy/config:/config
      - /docker/caddy/logs:/logs
      - /docker/caddy/Caddyfile:/etc/caddy/Caddyfile
      

Отдельно обращаю внимание на environment  DOMAIN она нам нужна для более простого (и безопасного) формирования Caddyfile.

Создадим Caddyfile с такой структурой:

(common) {
	header /* {
	-Server
	}
}

(cloudflare) {
	import common
	tls { 
		dns cloudflare {env.CLOUDFLARE_API_TOKEN}
	}
}

(local) {
	@allowed remote_ip 192.168.0.0/24
	handle {
		respond 401
	}
}

{
	log access-log {
		include http.log.access
		output file /logs/access.log {
		  roll_keep_for 48h
		}
		format transform `{ts} {request>headers>X-Forwarded-For>[0]:request>remote_ip} {request>host} {request>method} {request>uri} {status}` {
			time_format "02/Jan/2006:15:04:05"
		}
	}
}

jackett.{env.DOMAIN} {
	import local
	import cloudflare
	
	log
	
	handle @allowed {
		reverse_proxy 192.168.0.134:9117
	}
}

home-assistant.{env.DOMAIN} {
	import cloudflare
	
	log
	
	reverse_proxy 192.168.0.125:8123
}

vaultwarden.{env.DOMAIN} {
	import cloudflare
	
	log
	
	reverse_proxy 192.168.0.132:10380 {
		header_up X-Real-IP {remote_host}
	}
}

Пройдемся немного по блокам что бы понимать для чего каждый из них нужен.

Секции которые объявляются в скобках () являются импортируемым, это настройки которые мы определяем один раз и можем использовать для наших остальных настроек путем вызова через import. При этом каждый такой блок может импортировать в себя другие, тем самым создавая сложные структуры.

Секция common отвечает за удаление из ответа сервера имени сервера в нашем случае Caddy, это небольшая перестраховка для того что бы злоумышленники не могли по виду сервера использовать его уязвимости.

Секция cloudflare отвечает за настройки получения сертификата с использованием dns challenge.

Секция local служит для ограничения доступности к опубликованному сайту. В remote_ip указываются подсети или ip для которых доступ должен быть РАЗРЕШЕН, все остальные будут блокироваться и получать ответ указанный в handle respond в данном случае 401. Эта секция позволяет нам разделить и использовать один реверс прокси для внешней публикации и внутренней локальной сети.

Еще одна важная секция необходимая для работы f2b это секция описания логов и их преобразования. Переопределение настроек логирования без указания конкретных hostname применяет эту настройку на все.

В данном примере файл храниться в /logs/access.log внутри контейнера который соответствует на сервере /docker/caddy/logs Логи будут храниться 48 часов.

Теперь рассмотрим более подробно добавление конкретных сайтов, если нам надо использовать  реверс прокси только для локальной сети используем import local и запись как на примере с jackett, при этом домен можно подставлять путем автозамены как в примере, так как мы его передавали в переменные окружения при запуске контейнера.

Если нам надо что бы наш реверс прокси пускал не только с ограниченного списка сетей то используем запись как в примере home-assistant, тут у нас нет секции local и простая запись reverse_proxy без проверки допустимых сетей.

Если для сайта необходимо включить fail2ban обязательно указываем что должны вестись логи путем добавления записи log.

На этом основная настройка закончена, прокидываем 443 порт с роутера на наш сервер через переадресацию портов и наслаждаемся нашествием китайских ботов.

Кыш ботнет, или настройка f2b в докере для caddy

Для своей работы f2b использует логи которые предоставляют другие сервисы, на предыдущем этапе мы настроили логи caddy для их использования с f2b теперь запустим сам docker контейнер с f2b.

version: "3.9"
 
services:
  fail2ban:
    image: crazymax/fail2ban:latest
    container_name: fail2ban
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    environment:
      F2B_LOG_LEVEL: INFO
      F2B_LOG_TARGET: STDOUT
      F2B_DB_PURGE_AGE: 1d
    volumes:
      - /docker/fail2ban/data:/data
      - /docker/caddy/logs/access.log:/docker/caddy/logs/access.log:ro
    restart: unless-stopped

Обязательно даем право на чтение файла логов доступа caddy 

- /docker/caddy/logs/access.log:/docker/caddy/logs/access.log:ro

Если данного файла еще нет то может возникнуть ошибка в работе так как docker создаст вместо файла папку с именем access.log Для исправления необходимо зайти на несколько сайтов через реверс прокси и проверить что логи создаются.

Теперь настроим параметры работы f2b

В папке /docker/fail2ban/data/filter.d размещаем файл caddy-custom.conf со следующими настройками. При такой настройке все обращения которые получили ответ 401 будут попадать в бан лист.

# data/filter.d/caddy-custom.conf
 
[Definition]
# catch all lines that terminate with an unauthorized error
failregex = <HOST> \S+ \S+ \S+ (401)$
ignoreregex =

В папке /docker/fail2ban/data/jail.d файл caddy.conf

[caddy]
backend = auto
enabled = true
chain = FORWARD
protocol = tcp
port = http,https
filter = caddy-custom
maxretry = 3
bantime = 86400
findtime = 43200
logpath = /docker/caddy/logs/access.log
ignoreip = 192.168.0.0/24

Запись ignoreip служит для того что бы наша локальная сеть в случае каких то ошибок с нашей стороны не улетела в бан.

Перезапускаем контейнер и наслаждаемся спокойной жизнью. Но это не точно....

Подсказки и заметки на полях

Некогда не удаляет файл логов при работе caddy, в некоторых случаях система может повести себя крайне не адекватно и файл больше не создастся. Если это необходимо перед удалением обязательно останавливать контейнер. Ротация логов настраивается отдельно в Caddyfile

Для того что бы разбанить кого то в f2b при использовании в докере нам необходимо для стандартных команд добавлять команды по обращению внутрь контейнера:

Выводим статус fail2ban

docker exec -it fail2ban fail2ban-client status

 Выводим статус конкретной цепочки (имя цепочки берётся из Jail list предыдущей команды)

docker exec -it fail2ban fail2ban-client status ИМЯ_ИЗ_JAIL_LIST

Разблокируем требуемый IP-адрес из соответствующей цепочки

docker exec -it fail2ban fail2ban-client set ИМЯ_ИЗ_JAIL_LIST unbanip IP_ДЛЯ_РАЗБЛОКИРОВКИ

Для случая с использованием caddy команда разбана будет выглядеть так

docker exec -it fail2ban fail2ban-client set caddy unbanip IP_ДЛЯ_РАЗБЛОКИРОВКИ

 

Спасибо за внимание