Comments 61
Почти, держать уц на сервере так себе решение, лучшим решением будет держать бд уц у себя, выписывать сертификаты или wildcard на сервис, выстроить полноценную цепочку, root > sub > fqdn.crt, использовать crl списки, сроки любые год, два, три и тд. Я пользуюсь для этого XCA и OpenVPN веду там в другом sub, а дальше просто подключаешь сертификат как обычно, маршрутизация и все работает. Для сертификатов сайта кривая prime256v1 для openvpn secp384r1.
На примере mTLS будет не сложно выпустить для сайта https://habr.com/ru/articles/904038/
А почему не стоит держать УЦ у себя на сервере?
Смысл был в том, чтобы другие люди тоже могли им пользоваться (ведь какой может быть суверенный Интернет без пользователей), как, например, мы все пользуемся Lets Encrypt. Конечно, в статье CA не торчит в интернет (так как это туториал и мне показалось это совсем лишним), но сразу может быть CA, для того чтобы потом это можно было открыть для всех желающих. По поводу constraints - согласен, это упущение, можно улучшить
Ни тут ни там, кажется, не упомянуто использование address/name constraints в CA сертификатах. Их не все либы и программы учитывают, но добавлять сильно стоит. Уменьшает риск того, что в случае кражи корня злодеи смогут сделают рабочие сертификаты для MitM не только для твоей зоны, но и для всего остального интернета.
Смотря как держать, это всё тож самое про хранение приватных токенов. Можно было бы просто vault посоветовать, он умеет в LE, если мне не изменяет память, и там хотя бы защищает unseal.
Как увидел Cloud.ru так глаз задергался! Вы вначале сделайте чтобы ваша свистопуколка работала и не падала от каждого чиха, а потом уж людей учите.
Стараемся улучшать качество наших сервисов! Тут я скорее делюсь своим личным опытом, а не корпоративным - эти эксперименты мало имеют отношения к развёрнутому облачному сервису, но в любом случае было бы здорово, если бы вы рассказали, что мы можем улучшить, быть может я смогу помочь в улучшении определённого сервиса
systemd-resolved убирать не нужно, оно вполне нормально с локальным днс работает, просто настроить надо
установку корневых сертификатов от Минцифры, чтобы в критической ситуации вам все равно были доступны эти сервисы без рисков компрометации информации
В критической ситуации можно пользоваться и самоподписанными сертификатами, и неподтвержденными - на то она и критическая.
Тут ключевой вопрос - доверие к центру сертификации.
То есть, если сервер blabla.ru защищен валидным сертификатом - то мы как бы доверяем тем, кто выпустил и подписал для него сертификат.
А доверяем мы ему или нет - зависит от того, установили ли мы в систему корневые сертификаты этого удостоверяющего центра.
Но тут есть риск злоупотребления: если кто-то хочет нас обмануть и подсунуть вместо blabla.ru другой сайт, с подделанным DNS-именем и подделанным сертификатом, который тем не менее подписан доверенным удостоверяющим центром - то мы об этом не узнаем просто так. Мы же доверяем этому УЦ?
- Верьте мне! - как бы говорит он.
А что, если УЦ и мошенники в сговоре? Ну например, они считают, что нам не нужно показывать настоящий blabla.ru, а нужен другой, хороший, правильный blabla.ru, одобренный?
И вот так мы приходим к вопросу репутации, и как это, аффилированности ...
Полностью согласен! Под критической ситуацией имелось ввиду, например, отзыв сертификатов от зарубежных УЦ (это же и есть официальная причина, почему надо ставить сертификаты Минцифры)
В реальности отзыв сертификатов для веба практически нигде не работает.
Новые не выдадут, если захотят.
это же и есть официальная причина, почему надо ставить сертификаты Минцифры
После чего (по причине зависимости ВСЕХ российских провайдеров) google.com может стать удивительно похожим на yandex.ru, причем с валидным сертификатом, подписанным Минцифры ))
Знаете, это все познавательно и интересно, но у меня, как не очень давно погрузившегося в Линукс платформу, есть некоторые вопросы: вот в yaml в одно месте andyshinn/dnsmasq:2.83, а в другом traefik:v3.5- как понять как правильно? Почему используется в качестве volume var/run/docker.sock:/var/run/docker.sock?
Где то используется environments, где то labels, где то command. Rtfm? В целом конструкт понятен, но вот почему в одном случае так, а в другом по другому - не понятно. Возможно, я про основы спрашиваю, но хотелось бы вектор обучения узнать.
По тем местам, где различается:
1. andyshinn/dsnmasq:2.83 и traefik:v3.5 - это разные образы (читайте - разные приложения). Разные они потому, что каждый файл - это описание отдельного приложения
2. В traefik в volume прокидывается /var/run/docker.sock, чтобы приложение traefik могло настраивать доступы через сеть (как nginx, apache и т.д.) к другим приложениям
3. environments, labels и command - это разные опции. environments - переменные окружения, labels - метки контейнера (именно их использует traefik при настройки и именно поэтому ему нужен /var/run/docker.sock), command - это команда, которая запускается в контейнере
Думаю, здесь можно даже попробовать закинуть статью в какую-нибудь LLM и прямо ваш вопрос ей задать, чтобы получить быстрый ответ, ну а вообще все эти конфиги - это основа Docker и Docker Compose, копайте в эту сторону
Как сложно жить стало. Без докера никуда. Раньше две строчки в текстовом конфиге поправишь и всё работает, а теперь надо пор тянку табулированную наваять и образ собрать...
Хмм... Мне намного проще с докером чем настраивать сервера под несколько задач....
---
Я вот представил одну вещь и меня ужас охватил. Администрирование 40 хостов с разными конфигурациями и под разные нужды, и все это дело ручками... Да ну... 4 сервера - докер сварм, 40 контейнеров, под этим всем. И я вообще не парюсь... За два года был один инцидент. 2 недели в отпуску был. Место закончилось на одном хосту на менеджере, пол дня восстанавливал кластер, можно сказать с нуля. Да, технология сложная по началу, но лучше так чем bare-metal в чистом виде.
Однако вот тут автора поддержим: докер позволяет поправить две строчки в одном конфиге - и не поломать при этом 122 в конфигах основной системы.
Особенно если приходится работать директором зоопарка: тут Убунта, там Альт, здесь, прости господи, Астра - и у всех всё по-разному настраивается.
А так - накатил один образ и не заморачиваешься более.
А так - накатил один образ и не заморачиваешься более.
А потом в каком-нибудь openssl или libregex находится дырка и ты, вместо того, чтобы обновить один пакет и успокоится (потому что все с ним слинковано и автоматически начинает использовать новую версию) начинаешь чесать затылок, как это весь заопарк работающих образов обновить.
если приспичило:
docker exec -ti containername apt update
docker exec -ti containername apt upgrade
Повторить N раз. Всё.
И размер контейнеров улетит в космос. И это если ещё ничего не поломается, так как там под капотом часто сборище костылей, на которое ни в коем случае нельзя накатывать стандартные версии.
Не улетит. Хотя смотря что считать космосом.
Я для себя так и делаю: самостоятельная сборка нового контейнера на базе дебиана, именно для того чтобы потом получить тиражируемый образ.
docker commit containername newimagename
docker save newimagename | gzip > newimagename.gz
Это не по фен-шую, но работает, вполне приемлемо.
Поддерживать намного проще, чем обновлять хост-систему, а потом внезапно столкнуться с тем, что очередная очень нужная программа не ставится из-за сломанных зависимостей, и нужно переустанавливать всё, на новую версию с нуля, с риском нарваться на несовместимости с рабочим софтом.
Ну, это неплохой компромисс. Я и сам так стараюсь делать. Но это люто против трендов и лучших практик, и очень мало кто делает. И контейнер получается заметно тяжелее "стандартных". Хотя если всё на одном базовом образе делать, то в сумме даже вполне экономия. Но когда вы это обновлять начнёте...
Либо всё сразу пересобирать на обновлённый образ, а ровно тот же гемор и риски, что что-то не заработает (и вы об этом даже не сразу узнаете). И это ни разу не проще чем если всё на одной реальной системе было.
Либо обновлять по одному контейнеру, раздельно, что приводит к взрывному и непредсказуемому росту занимаемого объёма и потребления памяти. Получить 10x к объёму на диске и потреблению памяти после первого такого обновления можно совершенно элементарно.
если приспичило:
Работает только при условии, что внутри контейнеров нечто дебианобразное. Что совсем не гарантируется.
Если вы сами под себя собрали - в чем проблема?
В том, что когда в инструкции по установке предлагают ставить приложение контенером - это далеко не всегда означает 'собрать приложение в контенер'. Скорее, наоборот, предлагается тащить чей-то образ.
Если же организация сама все эти образы собирает для раскатывания по своей инфраструктуре и в случае патчей все пересобирает - то тут у меня возражений нет. Хотя и в данном случае внутри образов может быть 'тут Убунта, там Альт, здесь, прости господи, Астра + еще полдюжины базовых образов' (ну потому что каждый постовщик приложения свою базовый образ любит) - и со всем этим придется отдельно разбираться.
Часто при установке приложения на бареметалл предлагается запустить скрипт из Интернета, чтобы стянуть заранее собранный бинарник. Всё простое - это всегда менее безопасное и стабильное, вопрос выбора каждого.
Как docker образы можно собрать с нуля, так и бинарники можно скомпилить самостоятельно и поставить, и наоборот, и то и другое можно взять готовое и установить
Хмм… вот смотрите (как бы всем адресовано кто отвечал под моим клиентом). У меня Docker Swarm, оверлей-сети, один админ — а не несколько человек. Да, есть чужие образы — около 20 (Grafana, Prometheus и всё вокруг них). Обновления хостов и доставка образов идут через Ansible-плейбуки. Собственные веб-сервисы общаются только через API. Наружный и внутренний выходы разделены через Traefik. Доступы — через самоподписанные сертификаты. NFS между хостами тоже на сертификатах. Оверлей-сети чётко ограничивают, кто и с кем может общаться.
Я прекрасно понимаю, что Docker — не панацея. Но в сравнении с bare-metal это в моём случае реально проще и надёжнее. На чистом железе пришлось бы вручную обслуживать десятки конфигураций, ловить несовместимости, обновлять зависимости, контролировать окружения — и всё это без изоляции. У меня же весь стек предсказуемый: единые образы, единые сценарии развертывания, автоматизация, минимизация ручного вмешательства. Для моей архитектуры это полностью оправдано. Которую сам с нуля поднял это лучше чем...
Для моих задач Swarm — более чем достаточно, без лишней сложности и без ненужных уровней абстракции.
Отдельно по сертификатам: хочу поставить свой CA под всю инфраструктуру, но раньше с этим не работал, поэтому и решил почитать, что советуют люди, которые в теме.
Отдельно по сертификатам: хочу поставить свой CA под всю инфраструктуру, но раньше с этим не работал, поэтому и решил почитать, что советуют люди, которые в теме.
Тут такое дело - сертификат своего CA все равно надо как-то раскидывать. Да еще, как сейчас утвреждают, сертификаты должны быть нужен короткоживущими, т.е. раскидывать надо часто. Т.е. есть автоматизация.
А если есть автоматизация - то почему бы пачку self-signed не раскидывать "да, вот конкретно этом сертификатам мы доверяем".
Польза именно от CA тут становится не очень очевидна.
Хмм.. мысленный процес запущен... systemd + ansible. Но пока непонятно как сервисами быть. Volume == bind. Дёшево и сердито))) теперь осталось только на этом компоуз файле это прописать. Хмм... Для домашних этот способ не подойдёт. Там NixOs и апдейты через colmena, там что-то другое должно быть... Спасибо.
На самом деле на голом железе при правильной организации трудоёмкость была бы примерно такой же, если не меньше. Все уже забыли, как это правильно делать. А по факту там тоже анально огороженный firewall, пользователи, разворачивание и настройка всего скриптами и т.п.
Я сейчас для личных проектов вернулся к голому железу и местами это даже проще и позволяет очень быстро и понятно создавать сложные конфигурации. А обновление и вовсе намного проще, чем в docker. Обновить контейнеры - та ещё задача, и в случае несовместимости новые версий количество проблем получается даже больше, чем на голом железе.
Реальные сложности начинаются только в случае, если зоопарк систем, но кроме совсем уже корпоративщины, сейчас нет смысле держать зоопарк систем - всё можно на базе какого-то одного дистрибутива делать.
С
Часто при установке приложения на бареметалл предлагается запустить скрипт из Интернета, чтобы стянуть заранее собранный бинарник.
"А если все прыгнут - вы тоже прыгнете?". Зачем повторять плохое, да еще и основывать на нем свое оправдание? За такое очень больно бьют по рукам, потому что в бинарных дистрибутивах линукса (подавляющее большинство) есть ровно один один способ установки ПО - пакеты!
Так а в чём разница с тем, чтобы запускать контейнер на основе образа? В том, что вы не знаете, на основе какого образа он собран? Соберите сами, зачем повторять плохое, да ещё и основывать на нём своё оправдание? Нужна безопасность - контролируйте весь процесс от и до. Заметьте, я не говорю, что вы обязаны пользоваться докер контейнерами, но вот что я не понимаю, почему мне говорят, что я обязан не использовать докер образы?
Чаще обратная задача решается: в одном пакете обновилось и всё остальное сломалось.
При правильной поставленном процессе cicd обновить все образы занимает от 1 часа до рабочего дня, причем большее время просто ждешь пока оно обновится.
Многократно поддерживаю! Люди с ума посходили с этими докерами....пихают без применения мозгов куда надо и куда не надо.
Удобно же.
Развертывание в один клик. Все в конфиге кубера (для больших масштабов), или просто в гитлабе как docker-compose (для малышей и домашних конфигов), заезжает через раннеры.
Безопасность. Дырявое/зараженое приложение должно вылезти сначала за пределы докера, потом за пределы виртуалки... Почти невозможно при должной настройке. Плюс контейнерам можно легко обрезать доступ в интернет, что еще повысит защищенность решения. Плюс свои репы контейнеров (снова гитлаб, либо нексус) с ручной синхронизацией - даже если что-то глобально поломалось, было взломано или пропал доступ - у вас останется рабочая версия. Конейнер можно обрезать в минимум, и при его взломе там делать будет нечего - не будет ни прав рута, ни даже базовых утилит linux и оболочки.
Не нужно бекапить сервера приложений. Упал - поднимается пуском нужного пайплайна, так как все конфиги в гитлабе. Очень важная тема, так как поднять классический сервер даже при наличии бекапа не всегда реально без приключений.
Изоляция. Порты видны только те, которые мы указали. Изменения в одном контейнере не влияют на остальные... Как вспомню настройку домашнего сервера на 5-7 приложений (зоопарк - нода, питон, пхп, жава) без контейнеров - волосы шевелятся. Сейчас приложений около 50, на трех нодах - вообще никакого головняка.
Кейсы, где контейнеры неприменимы, есть, но это редкость, и чаще всего глупость - например продовую БД точно не надо совать в контейнер.
1 Зато мониторинг ставится в десять раз увлекательнее.
2 Если вы не заморачиваетесь rootless контейнерами, то в случае уязавимости в приложении "почти невозможно" превращается в "достаточно тривиально". А учитывая, что на машине там докер сервис от рута крутится и через сокет управляется, то у атакующего случается просто праздник какой-то. На реальной машине нужно было бы ещё рута получить.
3 Но если вы хотите ещё и VPN и маршрутизацию сложную на этом сервере иметь, то всё становится очень интересно.
Интересная карта по ссылке
Hidden text
dnsmasq по умолчанию слушает на всех интерфейсах. С проброшенным портом 53 - любой снаружи может использовать этот сервер как открытый рекурсивный Dns и он будет отвечать на запросы и слать ответы куда скажут злоумышленники.
1.1.1.1 и 8.8.8.8 это Cloudflare и Google.
На этих ИП личный DNS всё равно зависит от внешних публичных резолверов.
Пароли хранятся в чистом виде и легко доступны, если взломают смогут выпускать любые сертификаты.
Клиент тоже может подделать сертификат
Сроки действий сертификатов
docker compose -f ... up без -d и без restart:
после перезагрузки сервисы могут не подняться
Правка /etc/resolv.conf на клиентах может конфликтовать с NetworkManager/systemd-resolved и периодически отъезжать.
Также стоит посмотреть на файрвол на своём зосте, порты же открыты остаются
почему не развернуть адгвард днс ? тоже самое и блок рекламы
к тому же в Украине обход блокировки запрещенных сайтов
а теперь пытаемся открыть этот самый "суверенный" через провайдера с белым списком... или cloud.ru туда внесен?
Если говорить про белый список, то практически со 100% вероятностью Cloud.ru там будет
А если говорить про "суверенность" и независимость, то расписанная мной схема возможна только в том случае, если вы отказываетесь от провайдера и сами им становитесь. Хоть я и привёл ссылку на гайд, как стать настоящим провайдером в РФ, думаю, есть ещё один путь - это сделать свою локальную сеть с соседями и это тоже можно назвать "суверенным" решением, в нём вы сами и провайдер, и УЦ, и DNS
игры со словами
Будет сайт cloud.ru или будут все размещенное у них?
Если второе - злобный_дроновод (списки ж у нас от дронов официально?) берет VPS'ку и ставит там VPN (а следом за ним - также поступают 100500 пользователей кому хочется Youtube'а но размещают не VPN (который нельзя) а Технические Средства Предотвращения Угроз Цензуры)
Так спрашиваете у меня, как будто я лично рецензирую этот "белый список") Эх, если бы у меня была такая власть...
Насчёт того, что Cloud.ru будет в этом белом списке я уверен потому, что вряд ли можно не внести хостера, у которого крутится ГигаЧат, Сбербанк и которым пользуются другие крупные российские компании. Но опять же, ещё нет уверенности, что этот "белый список" будет, делим шкуру неубитого медведя.
Свою же сеть можно строить где угодно, не обязательно на мощностях Cloud.ru, но так как я очень не хотел описывать ещё и построение хоумлабы и статья выпущена в корпоративном блоге, то предложение, конечно, воспользоваться услугами облачного провайдера
привёл ссылку на гайд, как стать настоящим провайдером в РФ
А вы сами свою ссылку читали прежде чем ее приводить? Там ни слова о специфике РФ, зато:
немало непереведенных терминов и местами машинный перевод;
скрины с сайтами исключительно на английском;
этим скринам судя по верстке, ценам и скоростям ("Pro - 3Mbps $24.95")лет 15 как минимум;
судя по упоминанию DSL специфика явно не РФ.
Вообще не про РФ, а веб-архив подсказывает что этот полумашинный перевод - из 2014 года (оригинальная статья на английском как минимум из 2011го).
Заголовок - кликбейт, хоть бы сделали вид что знаете что прежде всего - маршрутизация. Или хотя бы Reticulum рассмотрели какой-нибудь.
Извините, не собираюсь делать вид, почему "суверенный" должен сразу означать, что мы должны с нуля пересоздавать протоколы и делать свою маршрутизацию, плюс мне казалось, что в заголовке очень явно написал, что в статье будет разобрано - о маршрутизации ни слово.
По поводу Reticulum - это очень интересно, но непонятно, как это будет работать в рамках закона КоАП РФ 13.4.
что мы должны с нуля пересоздавать протоколы и делать свою маршрутизацию
Reticulum я привел лишь в качестве примера, довольно радикального. Можно и нерадикально - несколько роутеров, BGP/OSPF какой-нибудь и вот.
мне казалось, что в заголовке очень явно написал
Вы правы, погорячился, в заголовке действительно не указано что будет маршрутизация.
как это будет работать в рамках закона
Использует нелицензируемые частоты, LoRa работает в рамках закона.
О, как раз этой штукой занимался пару недель назад при настройке хоумлабы :)
Тема интересная, но везде есть свои нюансы. К примеру - CA не всегда работает так, как хотелось бы. Из личной практики - у меня есть Caddy, который выступает и как реверс-прокси, и как локальный CA. Эта штука работает, но приколы начинаются на уровне клиента - в случае использования Android устройства сайты в том же Chrome открываются нормально, HTTPS работает, но стоит начать использовать стороннее приложение - так оно начинает игнорировать пользовательские корневые сертификаты :)
Конкретно в моем случае - личный nextcloud отлично открывался через chrome, но при попытке использовать плагин remotely save в obsidian для синхронизации базы знаний через WebDAV - obsidian ругался на невозможность установить защищённое соединение, и это все связано с тем, что obsidian игнорирует пользовательские сертификаты :)
но стоит начать использовать стороннее приложение - так оно начинает игнорировать пользовательские корневые сертификаты :)
В андроиде, очень похоже, разделение на системные и пользовательские специально сделано так, чтобы согнать всех в публичные СА и фактически запретить внутренние локальные СА. С одной стороны правильно сделано, ибо ломает возможность для правительств разных стран выпускать "православные" серты местечкового разлива и проксировать траф, с другой - сильно осложняет жизнь корпоративному юзеру и домашним инсталляциям.
В том же айфоне серты можно просунуть через "офлайновый" mdm (без подписок, инфраструктуры, и прочего, тупо официальное приложение на мак), а вот в андроиде, насколько помню, без инфраструктуры mdm не работает.
с другой - сильно осложняет жизнь корпоративному юзеру и домашним инсталляциям.
Да где уж осложняет-то? Говоришь поставить - ставит. Вполне оффлайново, если хочется. Через штатный системыный диалог.
При загрузке, правда, говорит, что такой есть. А то что в описанном примере WebDAV не понял - то это то ли разработчики клиента забыли в конфигурации еще и клиентское хранилище сертификатов подключить, то ли просто традиция в WebDAV такая устоялась - конфигурировать "этому ключику/серверу мы верим" отдельно. Потому что в детсктопных клиентах я видел то же самое. Руками добавлять/разрешать/позволять запомнить приходилось. Единсвенный, что смотрел на системные - это, кажется, только тот, что встроенный в винду и который меделенно выпиливают (или уже выпилили, не помню).
Поставить в системные нельзя без рута. Поставить в пользовательские можно, но бесполезно, так как для работы пользовательских сертов надо специально делать поддержку этого списка в приложении. Чего никто не делает, конечно же, за ооочень редким исключением, а большинство разработчиков и не знает про разделение, пока не столкнется... Это и есть подвох, в самом дизайне системы.
Собственный суверенный интернет: настраиваем DNS, CA и TLS своими руками