Обычно внутри корпоративной сети нынче полно всяких приложений, и хотелось бы чтобы они работали по SSL. Можно, конечно, поднять свой УЦ, раздать сертификаты, прописать пользователям свой корневой сертификат - и это будет работать. А можно просто воспользоваться сервисом Let's Encrypt, раздав его сертификаты своим внутренним серверам, которые не видны из Интернета, причем сделать это просто и с минимумом трудозатрат на поддержку.
Необходимые условия
Наличие зарегистрированного домена, допустим, mycompany.ru и адресация внутренних серверов в нем.
Использование split-DNS, т.е. разрешение доменных имен mycompany.ru в разные IP адреса для внутренней сети и для всего Интернета. Делается либо через механизм View сервера BIND либо просто путем использования разных DNS серверов.
Внутренние сервера имеют доступ в Интернет по HTTPS - через маскирующий/NAT шлюз, файрвол, прокси, как угодно. Впрочем, это можно преодолеть, просто эту статью придется дочитать до конца, а поработать чуть больше.
Как это работает
Логика работы сервиса Let's Encrypt:
Сервер-претендент обращается к API Let's Encrypt по HTTPS, сообщает ему домены, для которых нужен сертификат. Например, server.mycompany.ru.
В ответ сервис формирует некий код, который должен быть размещен по запрошенному доменному адресу чтобы подтвердить принадлежность домена. Есть варианты: размещение файла с кодом на веб-сервере или добавление в DNS домена определенной записи. Мы будем использовать файл на веб-сервере.
"Проверялка" Let's Encrypt лезет простым GET запросом на адрес http://server.mycompany.ru/.well-known/acme-challenge/{а здесь сам код}, и если получает ожидаемый ответ - то считает, что домен проверен.
Let's Encrypt выпускает сертификат и предоставляет его серверу.
На самом деле все немного сложнее, но нам детали и не потребуются.
Что мы делаем и зачем
Нам понадобится один прокси-сервер (nginx) и правильная настройка DNS. Больше, удивительным образом, ничего. Прокси-сервер должен быть доступен из Интернет и иметь доступ во внутреннюю сеть (dual-homed).
Полагаем, что все наши сервера во внутреннем DNS прописаны по именам. Во внешнем DNS, в зоне mycompany.ru задаем имя для внешнего адреса прокси-сервера, пусть будет proxy. И там же для каждого сервера из внутренней сети делаем запись CNAME, указывающую на proxy.
Конфигурируем nginx, общая конфигурация самая обычная, нужные нам блоки server в контексте http выглядит так:
server {
listen 80;
server_name .mycompany.ru; # Принимаем любые имена в домене
location /.well-known {
if ($request_method != GET) { # Разрешаем только метод GET
return 444; # иначе - сбрасываем TCP соединение
}
resolver 10.0.0.2 10.0.1.2; # Обязательно ипользуем внутренние DNS
proxy_pass http://$host; # проксируется на сервер внутрь сети с тем же именем
}
location / { # Все остальные запросы -
return 444; # просто сбрасываем TCP соединение
log_not_found off; # и ничего не пишем в лог
access_log off;
}
}
server { # На все запросы по IP адресу без домена
listen 80 default_server; # отвечаем сбросом TCP соединения
server_name _;
return 444;
log_not_found off;
access_log off;
}
Кстати, если у вас уже есть dual-homed сервер с nginx для каких-то других задач, то эту конфигурацию можно просто добавить к нему, она не будет мешать обслуживанию других серверов даже с именами в том же домене.
Работает это очень просто:
Наш внутренний сервер посылает запрос, получает код авторизации и размещает его у себя как положено.
"Проверялка" Let's Encrypt разрешает запрошенное имя в адрес proxy и посылает туда запрос GET, естественно доменное имя указано в запросе.
Получив запрос, прокси еще раз разрешает доменное имя, но уже внутренним DNS и выполняет запрос на реальный сервер, получает ответ и отдает его "проверялке".
Проверка пройдена, наш внутренний сервер получает сертификат.
Вуаля! Все работает! Ставим на внутреннем сервере Certbot или активируем встроенную поддержку сертификатов Let's Encrypt у нужного нам софта - и погнали. Не забываем повесить задачу на автообновление сертификатов!
За, против и немного про безопасность
Преимущества:
Простота реализации. По плечу очень среднему админу.
Совместимость. Работают любые ACME-клиенты с проверкой по HTTP на всех платформах, в том числе родной Certbot, встроенные ACME клиенты (проверено на Proxmox), да и вообще нет ограничений по использованию ACME кроме верификации по HTTP. И да, работать должно не только с Let's Encrypt.
Минимальные усилия на изменения: чтобы Let's Encrypt стал доступен для любого сервера внутри - достаточно просто добавить CNAME для него во внешний DNS. Ну и сделать соответствующие ACME-настройки на самом сервере, конечно.
Недостатки:
Мы вроде как показываем имена внутренних серверов в Интернете. На самом деле - нет, если только внешний DNS настроен правильно и не позволяет кому попало забирать зону целиком, что является хорошей практикой независимо от целей.
UPDATE: Как правильно заметил в комментарии @HxShard , используя публичные сертификаты внутри сети мы неизбежно делаем доступными доменные имена узлов, для которых мы их получили, как минимум таким вот образом https://crt.sh/?q=habr.com. Тут уж придется каждому решить - насколько большой риск тем самым создается. Лично я оцениваю его как весьма небольшую цену за удобство, во всяком случае вряд ли именно это станет самым низким участком моего виртуального забора.Теоретически, прокси-сервер, как любой dual-homed, создает угрозу. Но и меры защиты - самые обычные. Если они непонятны и вы не можете правильно настроить защиту для Linux + Nginx - то вам вообще не стоит иметь дела с серверами, подключенными к Интернету. Позовите взрослых пожалуйста!
Опять же, теоретически, существует возможность DoS на внутренний сервер при условии что его имя получено - путем заваливания его запросами в каталог /.well-known. Крайне маловероятный сценарий, но его можно легко купировать, ограничив скорость запросов на прокси. Это же nginx!
Внутренние серверы должны иметь доступ в Интернет. Но если это для вас проблема - то ниже покажу как ее решить.
К сожалению, Let's Encrypt не поддерживает и не публикует список собственных IP-адресов, поэтому ограничить обращение внутренних серверов наружу и запросы извне по IP - не получится.
И все же, изолированные сервера, сделаем?
Ценою усложнения схемы - сделаем и это. Дело в том, что ACME-клиент посылает запрос по HTTPs. С одной стороны - его тоже можно проксировать, но при этом "ломается" сертификат, и скорее всего ACME-клиент выдаст ошибку. SSL соединение нормально проксируется только на уровне TCP, но к счастью nginx и это умеет.
Нам понадобится:
По два внутренних IP адреса на каждый ACME сервис (для основного и staging).
"Перехватить" домен сервиса - либо путем записей в hosts либо на своем внутреннем DNS.
Настроить nginx для проксирования на уровне TCP.
Кстати: адреса API разных ACME-сервисов можно взять из скрипта acme.sh
Ок, делаем, на примере Let's Encrypt. Будем считать, что для внутренних интерфейсов прокси выделены адреса 10.0.1.34 и 10.0.1.35.
Перехват DNS
Перехват через hosts проще, но его надо не забыть сделать на каждом внутреннем сервере, добавив в файл строки:
10.0.1.34 acme-v02.api.letsencrypt.org
10.0.1.35 acme-staging-v02.api.letsencrypt.orgПерехват внутренним DNS сервером сложнее, но зато сделать его надо один раз и работать он будет для всех серверов. Для этого на внутреннем DNS создаем зону api.letsencrypt.org, и заводим в ней нужные хосты, пример файла зоны для BIND:
;Перехват api.letsencrypt.org
; SOA
api.letsencrypt.org. 3600 IN SOA localhost. root.localhost. (
2022122900
28800
7200
604800
3600
)
;основной сервер
acme-v02 3600 IN A 10.0.1.34
;staging сервер
acme-staging-v02 3600 IN A 10.0.1.35Вне зависимости от способа, проверяем результат пингуя с внутреннего сервера по именам acme-v02.api.letsencrypt.org и acme-staging-v02.api.letsencrypt.org, пинги должны проходить на .34 и .35 адреса соответственно. Значит, перехват DNS удался.
Настройка Nginx
Обратите внимание, что эти директивы должны находиться в контексте main, в то время как все привычные файлы конфигурации виртуальных хостов в каталоге "из коробки" уже находятся в контексте http. Поэтому надо либо добавлять в основной файл конфигурации /etc/nginx/nginx.conf, либо в каталог либо в отдельный файл и в правильном месте ставить include.
stream {
resolver 8.8.8.8; # А вот здесь нам нужен DNS, способный разрешать имена в Интернете
server { # Проксируем 443 порт на .34 адресе и отправляем на основной сервер
listen 10.0.1.34:443;
proxy_pass acme-v02.api.letsencrypt.org:443;
}
server { # Проксируем 443 порт на .35 адресе и отправляем на stageing сервер
listen 10.0.1.35:443;
proxy_pass acme-staging-v02.api.letsencrypt.org:443;
}
}Ну вот и все! Теперь и серверы внутренние доступа наружу не имеют и Let's Encrypt на них работает.
P.S. Дед мой, добрая ему память, частенько говорил: "Кабы не клин да мох, да и плотник бы сдох!". Так и хочется перелицевать на "Кабы не nginx, да ???, так и сисадмин бы ???". Но вот что подставить? Предлагайте! :-)
Комментарии (63)
inkvizitor68sl
29.12.2022 18:53+2Или нам понадобится dns-плагин к certbot, одна штука.
pavlyuts Автор
29.12.2022 19:23А еще права писать в зону и некоторые нюансы, с которыми людям приходится разбираться часами.
Но в принципе, конечно, да.
Предлагаю написать альтернативный пошаговый гайд, и пусть каждый выбирает для себя ;)
dimsoft
29.12.2022 21:17+1использую acme.sh пишу в соседнюю специальную зону которую держу на Cloudflare, на которую есть в основной одна не меняемая cname.
inkvizitor68sl
29.12.2022 21:24+1Зачем людям с чем-то разбираться?
pavlyuts Автор
29.12.2022 21:38Ну, мануал, который начинается с:
sudo apt-get install openssl jq curl gitAfterwards, change into the directory you want the tools located at and issue the following command:
git clone --recurse-submodules https://github.com/loewexy/pdns-acmeНу, знаете, такое. На любителя. Я не любитель.
Я предпочитаю сделать один раз так чтобы потом вот вообще не париться вообще ничем. Самое сложное при написании статьи было вспомнить где же точно вертится прокся ))))
Ну а на любой машине -install certbot,certbot run/certonly -d xxxx, ВСЕ )))
А, забыл ещеsystemctl enable --now certbot-renew.timer
Ну или просто галочка в интерфейсе "использовать летсенкрипт", в прикладе оно сейчас на каждом шагу.
HxShard
29.12.2022 19:19+2На самом деле - нет, <…>
А точно нет? https://crt.sh/?q=habr.com
pavlyuts Автор
29.12.2022 19:23Хм... Спасибо!
Вы, конечно, тут правы.
Наверное, следует сделать апдейт ибо это значимая информация.
pavlyuts Автор
29.12.2022 21:56Я все же сделал ремарку со ссылкой на Вас по данному вопросу.
Ибо Вы абсолютно правы, хотя я и не вижу в этом действительно серьезных рисков.
aborouhin
29.12.2022 20:59+2Split-DNS нормально работает только в "корпоративном концлагере", где все устройства тоже корпоративные, состоят в домене, с урезанными правами пользователей и пр. В схеме BYOD всё более популярный и кое-где уже зашитый по умолчанию DoH, да и просто разумное желание пользователя прописать DNS от Google или Cloudflare, сводят полезность такой конфигурации к нулю.
У меня просто внешний (он же единственный) DNS отдаёт для внутренних серверов внутренние же адреса. А сертификаты через DNS-плагин к certbot обновляются, да.
pavlyuts Автор
29.12.2022 21:29Между "кговагым ынтырпрайзом" и живопыркой на троих есть еще примерно весь спектр разного размера инфраструктур -- как виртуальных, так и не очень. Поэтому широко обобщать я бы не стал.
DNS-плагин это прекрасно, как и вайлкарды. Но парадокс в том, что в моей схеме все и всегда работает а) из коробки б) без бубна в) без кучи дополнительных условий.
Включая весь спектр софта, в который АСМЕ вшито, и далеко не всегда там под капотом именно Certbot, а и когда он - возможность им управлять зачастую неочевидна.
Я люблю простые решения, которые работают как калаш. С абсолютным минимумом условий и потенциальных нестыковок.)
avelor
29.12.2022 22:43Простой вариант как калаш - один балансировщик-реверпрокси (тот же нжиникс или хапрокси или и то, и то - тут по вкусу) с терминацией ссл и вайлдкардами для нужных обслуживаемых доменов…
pavlyuts Автор
29.12.2022 23:08Кхм... У меня такое ощущение, что Вы не прочитали написанное мною или прочитали там что-то то свое.
Я вообще-то о внутренних ресурсах, предназначенных для внутренних пользователей (ну или пришедших через VPN, что одно и то же), и НЕ предназначенных для доступа из Интернета.avelor
29.12.2022 23:35всё правильно, внутренние ресурсы, для внутренних пользователей.
и один балансировщик. с терминацией ссл. смотрящий наружу (одной ногой условно для www.domain.name) и запрашивающий вайлдкард *.domain.name. обращения к внутренним сервисам - через этот балансировщик, по уже внутренней ноге. одна точка терминации, один сертбот.
заодно внутренни сервисы принимают подключения только с одного внутреннего адреса (ну если делать ha - c нескольких) что упрощает фаерволенг и сегментирование сети.в целом для внутренних клиентов обращаться по внешнему адресу тоже допустимо, но без настройки маршрутизации между внешними и внутренними адресами (например с полноценной DMZ и своей AS) - оно будет ну такое, на балансировщике внутренних адресов не увидите.
pavlyuts Автор
30.12.2022 07:53Все правильно, но есть нюанс: оправдано начиная с некоторого масштаба. Создает дополнительную точку отказа, куда сведены все приложения.
Немного повышает цену ошибки в том смысле что одно неверное движение - и вот все твои внутренние ресурсы немного опубликованы в Сеть.
Но концептуально идея зареверсить все внутренние ресурсы - понятная и по- своему богатая )))
aborouhin
29.12.2022 23:37В части получения сертификатов всё работает безусловно. А вот в части Split-DNS... подключается к нашей внутренней сети пользователь со своим смартфоном, в котором system-wide зашито использование DNS over HTTPS - и получает "внешние" адреса вместо внутренних. Далее одно из трёх. Либо мы такое вообще запрещаем, и тогда мы таки уже "кровавый энтерпрайз". Либо у нас нормально настроен доступ по внешним адресам из внутренней сети тоже (и тогда зачем нам в DNS внутренние адреса вообще). Либо как я предлагаю, раздавать внутренние адреса с внешнего DNS (особенно учитывая, что внешние адреса отнюдь не у всех серверов могут быть вообще, зачем они, прости Господи, какому-нибудь принтеру).
pavlyuts Автор
30.12.2022 07:57Кстати!
А что у нас за девайсы такие, которые возлагают болт на, допустим, профиль сети выданный им по DHCP и настойчиво используют DoH? Можно пару моделей? И что, это в принципе не лечится?
Ну так-то в принципе желание производителей смартфонов иметь покупателя всеобъемлюще - оно понятно. Другой вопрос что почти наверняка они будут криво работать не только в корпоративных сетях, но и во многих других случаях.
d-stream
30.12.2022 08:50+2Почти все броузеры по дефолту пытаются так работать.
pavlyuts Автор
30.12.2022 10:06Мда?
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
d-stream
30.12.2022 18:43"я вот давеча медку поел и не зажужжал")
Уж не знаю сами далёкие от техники юзеры понажимали или оно так было дефолтно или они согласились "сделать безопасно", но не единичные проблемы у людей были. Притом кому-то хватало в hosts прописать нужный адрес, кому-то отключать... Ну и в будущем думаю вектор направлен на безопасность по аналогии с https и таких ситуаций будет всё больше.
Так что splitDNS будет иметь проблемы и в будущем их будет больше.
pavlyuts Автор
31.12.2022 18:53Это очень частные проблемы и по многим причинам поддержка старого доброго ДНС будет продолжаться еще долгие, долгие годы ;)
Вас не удивляет что сохранился SMTP, который старше уже очень многих читателей хабра? ;)
Потому что некоторые вещи очень живучи в силу своей простоты и отработанности.d-stream
31.12.2022 20:50https пришел на смену http очень даже быстро и очень принудительно, так что ещё пара-тройка лет...
pavlyuts Автор
01.01.2023 15:28Искренне прошу прощения, минуснул коммент промазав мышой, а отменить это нельзя (((
Есть огромная разница, сравните сами: DNSsec вроде бы существует чудовищное количество времени, а с распространением у него - проблемы. Потому что он весьма и весьма сложен.
HTTPS на самом деле не отдельный протоков, а очень простая комбинация HTTP и SSL/TLS и связанных с ним базовых библиотек.
И "поперло" его тогда, когда была разрешена проблема "невидимости" имени http-сервера в момент SSL-хэндшейка и массово появилась поддержка SNI. Ну и дальше тот же самый Летсенкрипт и другие, кто давал сертификаты бесплатно, сделали для его распространение.C DNS ситуация другая: использовать TLS не стали, потому что так-то запрос-ответ - это UDP и два пакета, у TLS один хендшейк в разы больше требует - соответственно большие проблемы могут быть с таймингом рекурсивных запросов и еще много с чем. Сделали DNS-sec, но он оказался немного сложен "для среднего админа".
Ваше мнение о том, что DoH прямо быстро-быстро сменит DNS, кмк, основано на том, что его поддерживают большие корпорации для массово обслуживаемых ими клиентов. Но, к сожалению, есть еще и весь остальной мир ;)
aborouhin
30.12.2022 14:07Любой Андроид, если на уровне девайса. Любой современный браузер, если на уровне браузера. В последнем случае оно ещё где-то и по умолчанию было, ЕМНИП, но и желание включить DoH вручную вполне объяснимо, если домашний или мобильный провайдер использует апстрим сервера НСДИ (а он-таки использует), выдающие вместо достоверных данных зацензурированное сами знаете что.
pavlyuts Автор
30.12.2022 15:34Дубль:
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
aborouhin
30.12.2022 15:36Наверное, путаете ситуацию "оно хочет только DoH и не умеет использовать обычный DNS, полученный по DHCP" и ситуацию "оно не использует обычный DNS, полученный по DHCP, если в настройках включить DoH". А право пользователя включить этот самый DoH я понимаю, чту и уважаю, точно так же, как и его право использовать удобный ему почтовый клиент по IMAP, а не веб-интерфейс (из ветки комментов выше :)
pavlyuts Автор
30.12.2022 15:44Права пользователя заканчиваются там, где начинаются его обязанности ;) Это вообще-то базовый жизненный принцип трудовой деятельности )))
Концепция BYD, в моему понимании, заключается не в том, что пользователь делает что хочет и как ему удобно, а в том, что его устройство адаптируется ТАКЖЕ и под инфру работодателя - в разумных, но необходимых пределах.
Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Ну а так-то любому человеку работать неудобно. От работы кони дохнут, усталость и все такое )))
aborouhin
30.12.2022 15:53Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Мой корпоративный VPN (а в офисной сети и без VPN) просто позволяет и в Инстаграм ходить тоже :) Причём без ущерба хождению на российские сайты. Там вообще хитрая маршрутизация между 4 странами для минимизации ситуаций, когда хоть что-то не работает, поэтому пользователям нет смысла какими-то другими сервисами разной степени сомнительности пользоваться, что тоже позитивно сказывается на безопасности.
pavlyuts Автор
30.12.2022 17:11Про инстаграм - это был пример ;)
Я так понимаю, что сам тезис возражений все же не вызывает? )))
aborouhin
30.12.2022 17:16Сам тезис - вопрос уже слишком философский, и очень зависит от состава коллектива и специфики работы. Я предпочитаю от технических вопросов так далеко не отклоняться :)
pavlyuts Автор
30.12.2022 17:33Ну, тут уж извините, такой вопрос где техника прямо взаимодействует с управлением и людьми.
А вообще здорово когда технически возможно/нет и нет предмета для дискуссии )))
avelor
29.12.2022 22:40+1Отдавать наружу внутренние адреса чот ну такое. Мало того, что относительно публичны имена внутренних хостов, так ещё и ip их известны - а лучше отдавать наружу меньше инфы об инфраструктуре:)
aborouhin
29.12.2022 23:40Есть такая мысль, но данный риск был сочтён минимальным. А решать проблему нормального доступа к внутренним сервисам с устройств с разными системными настройками DNS на уровне системы или браузера как-то надо было, в комменте выше по ветке расписал варианты, которые были.
avelor
30.12.2022 00:38+1Ну, главное что риск оценен, взвешен и принят :) к слову, тут ещё возможны косяки (в теории и отаки, но вы вероятно тоже учли) при работе без впн, когда можно попасть по имени куда-то совсем не туда - вплоть до отправки чуйствительной информации вроде паролей плейнтекстом-куков и т.п.
Я как чувак, что ближе к кровавому тыртырпрайзу предпочитаю сплитднс при отсутствии возможности/желания работать с внешними адресами сервисов или реверс-прокси (подробнее про нюансы отож писал выше).
aborouhin
30.12.2022 00:49Ну в детали вдаваться не буду, но про риски такие думал, моделировал. Может, что-то и пропустил, конечно. Но всё, что принимает чувствительные данные, таки имеет те самые сертификаты, в отсутствие которых софт ничего никуда не отправляет и матерно ругается. Ну и специфика работы (наличие сотрудников, которых самих и их устройства ни разу в жизни в глаза не видишь) особо на сохранность пароля рассчитывать не позволяет в любом случае, классический стикер с паролем на крышке ноута куда больший, и не особо управляемый риск :) А вот доступ в VPN уже изрядно параноидален - логин/пароль через LDAP + индивидуальные сертификаты + OTP + мониторинг новых устройств, в общем, для достаточно мелкой конторы, насколько я себя успокаиваю, хватает :)
avelor
30.12.2022 01:28+1Подумайте над имплементацией в том или ином формате подхода zero trust security. Условно нам не важно, где комп - в локалке (в впн) или дома, мы одинаково защищаем сервисы. Оно хорошо ложится на byod-подход и в целом не особо затратно можно сделать без накручивания conditional access и client posture/profiling.
Как вариант имплементации (не факт что подойдёт вам, чисто вариант концепта) сервисы вывешиваем на внешний адрес, но помимо аутентификации и авторизации через ldap крутим mfa, и проверяем наличие клиентского сертификата выданного внутренним СА. Сертификатом спасаемся от всяких zero-day, mfa - на случай если и учётка и серт утекут (например стырили ноут, а он нешифрован и пароль на рабочем столе). Можно использовать и совместно с впн, например mfa запрашивать только при внешнем подключении (тут понадобится опять же сплит/дмз, но по крайней мере часть сотрудников не будет страдать от mfa). Mfa хорошо крутить с sso вроде самл/oauth (в один сервис зашёл, в другие в период n часов влетаешь без запросов).
aborouhin
30.12.2022 02:07Оно всё прекрасно, но спотыкается о почту, которая в грубом приближении бывает или Exchange (у меня - нет, по разным причинам), или IMAP, к которому MFA и прочие прелести не прикручиваются от слова "совсем". Посему она и прячется за VPN (либо локальной сетью с WPA Entreprise), который является основным рубежом защиты.
А поскольку почта диктует именно такую модель, то и остальное по тому же принципу.
SAML / OAuth в планах есть, но это всё легко и ненапряжно поднимается с использованием Azure AD / Onelogin / Okta и прочих облачных сервисов, которые в один прекрасный момент стали не очень доступны к покупке без обходных путей, а рисковать использованием обходных путей, которые могут в любой момент отвалиться, не хотелось. А поднимать это полностью у себя задачка нетривиальная, начинал, отложил на потом :)
avelor
30.12.2022 09:27Да, оно красивое на бумажке, но требует осмысления, доработки и изменений. Тот же imap можно объявить легаси и похоронить в пользу вебинтерфейса условной зимбры. Или прикрутить к нему mtls (так же закрыть на серт клиентский)..
Если винда - с adfs тож не особо сложно. Больше проблем с сервисами, что или заводят для галочки поддержку, или начинают считать что это суперентерпрайзно и хотеть множество деняк:)
pavlyuts Автор
30.12.2022 10:02+3Простите, но "чтобы тебе с почтой только через веб-интерфейс работать" - звучит как проклятие ;)
Не надо трогать аймап, пожалуйста. Для почты ничего лучше не придумано и придумано в обозримом будущем не будет. Нравится нам это или нет.
Ну и не надо забывать что защита должна быть соразмерна угрозам, а кривую зависимости защищенности и удобства никто не отменял ;)
Классика же:
Сисадмин спросил Учителя:
– В статье написано, что любое усиление безопасности снижает лояльность работников. Это правда?Инь Фу Во ответил:
– На самом деле усиление безопасности снижает удобство. Снижение удобства повышает усталость. Повышение усталости снижает добросовестность. А снижение добросовестности работников – это и есть то, чего следует избегать.– Тогда что же такое лояльность? – спросил Сисадмин.
– "Лояльность", – усмехнулся Инь Фу Во, – это японцы выдумали, чтоб денег не платить.
aborouhin
30.12.2022 14:12+2Вот тут поддержу. Стараюсь не делать пользователям ничего, что мне самому было бы неудобно. А поменять свой Thunderbird с тремя десятками любовно отобранных расширений на веб-интерфейс - ну такое... В основном народ, конечно, так не заморачивается, но даже обычный десктопный Outlook на порядок удобнее любого веб-интерфейса.
tuupic
31.12.2022 17:25Для конкретно thunderbird можно сделать плагин(нужно зашивать конкретные домены туда) для авторизации через oauth в dovecot. А oauth уже через keycloak и прочие штуки с MFA, отрубив нативные IMAP способы. Минус, что оно только для thunderbird
aborouhin
31.12.2022 22:31Даже если всех перевести на Thunderbird (чего не хотелось бы, ибо у непродвинутых пользователей будет больше вопросов, им привычный Outlook из коробки проще), остаётся доступ с мобильных устройств, который не менее важен. В итоге работающая более или менее везде почта с MFA - это практически без вариантов только Exchange.
lehha
29.12.2022 23:10+2Делайте проще через DNS-01 challenge и делегирование CNAME для домена на сторонний домен. Например, для внутреннего домена и всех поддоменов *.secret.ru сделать запись:
_acme-challenge.secret.ru CNAME _acme-challenge.publicdomain.ruВ записи _acme-challenge.publicdomain.ru сделать TXT со значением, который выдаст challenge.
Всё это дело упаковывается в скрипт, которому дать права на управление txt-записями доменам publicdomain.ru
В итоге у вас сертификат на все поддомены *.secret.ru, даже если к нему нет публичного доступа из вне (там конечно есть нюанс, что нужно будет указывать 2 домена при запросе сертификата: secret.ru и *.secret.ru, но wildcard поможет не светить все внутренности в логах crt.sh и подобных сканеров).
pavlyuts Автор
29.12.2022 23:30Ну по поводу "попроще" - это смело сказано! Там слова "скрипт" и "делегирование туда-сюда" и "дать права" прямо вопят о простоте реализации )))
Давайте сравним трудоемкость и, самое главное, вероятность ошибки для а) собрать всю схему и б) добавить еще одни сервер в) нигде ничего не поломать при изменениях
Кстати, забавный факт: я написал эту статью после того, как у одних моих, партнеров вдруг не смог зайти на один из их внутренних серверов - сертификат протух, а без него не пущает вообще - ибо запрещено. Ну, потрещали с админом - а там как раз Ваша схема - получает вайлдкард сертификат и потом скриптами разгоняет его по всем серверам. Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер. Ну и упс.
Это мы даже не говорим о примерно тыщще вариантов встройки ACME клиента в разный софт, где, конечно, можно и по Вашей схеме отработать, но обычно это требует отдельных танцев со специальными моделями бубнов ;)
aborouhin
29.12.2022 23:46Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер
Ну если никакой мониторинг по факту протухания сертификата не отсылает никакой алерт - то прозевать с одинаковым успехом можно и ошибку в работе централизованного скрипта (или плейбука Ansible, как в моём случае), и ошибку в обновлении сертификата с конкретного сервера.
pavlyuts Автор
30.12.2022 07:17Можно прозевать, да.
Но давайте поговорим о вероятностях. Чем сложнее и навороченнее схема, чем больше в ней кастомных скриптов, шагов и звеньев - тем больше вероятность возникновения проблемы при малейшем изменении условий.
Ну вот просто умозрительно, что имеет меньшую вероятность принести проблемы: тиражируемый софт, который запускается миллион раз в сутки по миру или самописный разлапистый скрипт, который даже протестировать толком на все возможные варианты раскладов нельзя - чисто по соображениям здравого смысла?Лично я считаю, что с точки зрения практической надежности любюе решение через конфигурирование серийных продуктов штатными средствами даст огромную фору самопису любого генеза )))
aborouhin
30.12.2022 14:09Ну так "конфигурирование штатными средствами" в 2022 году, чай, тоже не заходом на каждый сервер ручками по SSH и редактированием конфигов в Vim осуществляется, а каким-нибудь Ansible...
pavlyuts Автор
30.12.2022 15:31Ну например в Проксмокс ты нажимаешь кнопку "получить сертификат". А, ну емейл надо указать.
Дело в том, что помимо Цертбота сейчас куча всяких приложений "из коробки" поддерживает ACME, там просто опция включается и все.
И да, кстати, чтобы тот же цертбот по моей схеме запустить с примерно 100% успехом - никаких редактирований конфига не требуется. Требуется 1(одна) команда на получение сертификата и 1(одна) на запуск таймера его обновления.
Как бы все.Как альтернативу мне тут каждый первый предлагает набор скриптов. Кстати, надо будет спросить сколько примерно строк )))
lehha
29.12.2022 23:53В любом решении есть своя стоимость косяков)
Мы запилили внешний сервис, которому делегировали эти записи. Сервис сам выпускает и продлевает сертификаты и кладет их в хранилище. Клиент при сборке/запуске контейнера просто забирает актуальный сертификат, хоть каждые 5 минут со 100 нод одновременно. Обычный lets encrypt забанит за частный перевыпуск сертификата если вы его случайно потеряете.
pavlyuts Автор
30.12.2022 07:25Вопрос в масштабе. И выборе в соразмерного подхода.
Я прежде чем писать, почитал что понаписано в этих ваших энторнетах на эту тему. Была, в частности, шикарная статья про то, как раздавать Летсенктипт тысячами, сейчас не найду, но там смысл в динамическом одоменивании и так далее.
И да, если тебе надо много, если у тебя это важная часть процесса, то "запилили сервис" - это логично и правильно.
Но если у тебя еще примерно до пенсии не переделать разных других задач и надо раздать сертификаты на десяток-полтора хостов быстро, просто и надежно - то вот это как раз вариант, за час с нуля сделал и забыл про проблему навсегда )))
Поэтому мы оба правы в подходах, если, конечно, вы соразмерно подходите )))
LeKovr
30.12.2022 07:59А нет ли у вас конкретики о том, почему не подошел вариант "для своей сети поднимем свой CA и к нему прикрутим свой аналог LE"?
pavlyuts Автор
30.12.2022 08:04Это имеет смысл для достаточно большой компании, с способной содержать продвинутых админов и держать юзверей в крепком стойле, потому что:
Требует существенно большей квалификации на установку и настройку
Требует раскатки своего корневого сертификата в системы пользователей, в противном случай как минимум броузеры будут материться на невалидный серт, в наихудшем - не будут давать открывать ресурс вообще. Это легко сделать через всякие там полиси, но весьма геморройно руками.
Ну а у меня из серии "быстро, просто, доступно, не без недостатков, но за эти деньги...". Определенно это для НЕбольших компаний, и людей с НЕ слишком высокой квалификацией. Все максимально из-коробочно и прямолинейно.
KillJ0y
01.01.2023 13:10Я конечно все понимаю, но зачем такой оверхед?
Я все сделал проще (для домашних серверов) есть vps, он получает wildcard *.mydomain.ru (при всем этом нам не обязательно в панели dns создавать поддомены на общее обозрение, внутренний dns справиться) и далее переправка безопасным туннелем на внутренний сервер, и с внутреннего сервера все это раскидывается по машинам и контейнерам. Профит. Валидные сертификаты в локалке, без своего уц которой все равно есть.
pavlyuts Автор
01.01.2023 15:08Кхм... Т.е. несколько десятков строк в файлах конфигурации из которых содержательных - менее десятка, а остальные - скобочки да отбивки - это оверхед.
А целый набор кастомных скриптов для получения, обновления, раскатывания по серверам, рестарта на этих серверах сервисов после раскатки, и все это с авторизацией, кстати, - это не оверхед а так, дунуть-плюнуть, да?
Нуууу ок. Рискну предположить, что скриптинг - Ваша сильная сторона, поэтому она и является для Вас простейшим путем. У меня, к сожалению, на такие вещи тупо нет времени.
И если уж так, то вариант с реверс-проксированием всех внутренних сервисов через один SSL-терминирующий прокси выглядит намного более вменяемым, простым и работоспособным.KillJ0y
01.01.2023 15:17Bash родной язык - это да, и не только он.
А городить конструкции с прокси сайтами докер контейнерами не оверхед? Круто конечно прийти на все готовое запустил контейнер пару строк поменял и все. Изначально было написано на bash был оверхед да. Нужно было ещё безопасное туннелирование делать для этого openvpn использовался. В текущей реализации написан софт он то и делает большую часть работы. Шифрует файлы, пихает в tls передает, расшифровывает, кидает по местам меняет права рестартует. Если нужно добавить сервер в цепочку нужно скомпилировать клиента с настройками что куда положить, что рестартануть и откуда взять. Импровизированный с&с сервер и клиенты
KillJ0y
01.01.2023 15:23Дополню для авторизации на с&с используются УЦ, а все остальное что пытается стучатся на порт сервиса просто дропается, в принципе идея взята у openvpn с tls-crypt, при сканировании порт так же невидим, Профит.
pavlyuts Автор
01.01.2023 15:33Ну, если у вас внутри пасутся тучные стада стейтлесс контейнеров - тогда у вас своя атмосфера и все, написанное выше Вас не касается. Ну и Вы просто не целевая аудитория статьи ибо можете задачу из заголовка исполнить так, вот так, а еще под куполом на трапеции без страховки, и в гамаке на лыжах стоя )))
Я это писал для тех, у кого а) инфра довольно статична, а не буйство оркестрации б) ее сравнительно немного, а не многие десятки и сотни серверов в) у кого не так высока профильная квалификация и не так глубоко понимание ACME чтобы самому накатать решение.
KillJ0y
01.01.2023 15:59Я не спорю что данное решение это плохо, или ещё что то. Нет, как вы сказали у всех свои потребности и задачи.
Например у меня дома две серверные железки обе на proxmox (включая Вирт для сборок). и резервная машина старый пк в качестве точки бекапа. + 2 vps разной мощности и задачи. Рабочих серверов 2+1. В итоге написал такой софт который решает проблемы с сертификатами, сделал его проприетарным для защиты в том числе. Ну и что бы на работе его потом не свиснули. Подписываю своим ключом от своего уц мне не напряжно держать на всех своих машинах свои корневые сертификаты, это же не от минцифры... а для рабочих машин подписываю их уц. В процессе версия 2, с большим фунционалом. Когда нибудь я напишу статьи об этом.
pavlyuts Автор
01.01.2023 16:07Ну, Вы начали про "слишком большой оверхед" )))
Я, напомню, констатировал, что здесь все решение, которое работает (не без недостатков!) занимает примерно час-два на все про все, после чего про него забываем вообще - есть другие задачи ))) И что как раз "оверхед" для средней руки админа здесь совершенно минимальный.
Вы рассказываете о своем подходе, реализация которого явно потребовала сотни человеко-часов. Который делает, конечно, все лучше и правильное ;)
Но вот по поводу "зачем такой оверхед? Я сделал все проще..." я по-прежнему не согласен. Вы сделали намного сложнее и более трудоемко в реализации, с другими слабыми местами и под свое видение.
Собственно весь предмет дискуссии только в этом.
KillJ0y
01.01.2023 16:14Я не любитель использовать docker для чувствительной информации - это раз. Второе меньше чем за неделю была написана эта утилита изначально на с, в планах переписать на rust. И третье, ведь действительно если мало динамики контейнеры например сами не пересобираются, можно все было кинуть в bash скрипт и закинуть в cron (моя альфа версия так сказать), типо два скрипта сервер (где получаются сертификаты) и клиенты которые забирают сертификаты с сервера. Простым скриптом проверяем не истёк ли серт, если да то перевыпускаем, клиенты ходят на сервер по таймеру, видят что серт обновился забирают его раскидывают, а ночью рестарт сервисов.
KillJ0y
01.01.2023 16:16В серверной утилите реализованно шифрование этого самого wildcard сертификата и ключа, и хранится он на сервере зашифрованным, в открытом виде на диске файл ключа вообще не появляется. Профильное образование по криптографии не прошло даром
pavlyuts Автор
Я все же сделал ремарку со ссылкой на Вас по данному вопросу.
Ибо Вы абсолютно правы, хотя я и не вижу в этом действительно серьезных рисков.