Главный пойнт в том, что одно дело, когда киберполицейским нужно получить доступ только к одному ДЦ (в данном случае Хетцнер в германии), другое дело, когда еще к условно всем 4м, где хостится DNS сервер отвечающий за домен, и не простого васи, а какой-то крупной организации. Задача гораздо сложнее, согласитесь.
Но я предлагаю свернуть дискуссию, мне кажется мы про разное говорим.
Ну вот работает в конкретной VPS авторитативный сервер DNS
Выше я напсиал и выделил как правило -- "В случае DNS валидации (с доп проверкой CAA), его (сервер) как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google".
Сетап когда на VPS еще NS сервера размещают -- очень редок, и я не понимаю зачем это нужно делать вообще говоря в обычной ситуации
То есть валидацию владения легко перехватить, так как трафик приходит прям на сервер.
В случае DNS валидации (с доп проверкой CAA), его как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google
То есть 1. [Какой-то сервер] -> [Lets encrypt] запрашивает валидацию 2. [Lets encrypt] -> [DNS DTLS resolvers: 8.8.8.8, 1.1.1.1, ...] -- идет запрашивать 3. [DNS resolvers] -> [ Authorative DNS ] -- где непосредственно токен-записи лежат для подтверждения владением (или CAA) 2. [Lets encrypt] -> [Какой-то сервер] -- присылает сертификат
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ. А если запрос на сертификат уходит не с [VPS @ Hetzner], а с другого [Какой-то сервер не в hetzner], то вроде как и сам факт запроса неочевидно как отследить.
Другое дело, что если у тебя доступ к Hetzner, странно что они просто в файловую систему VPS не залезли и не забрали сертификат оттуда, пошли каким-то окольным путем. Возможно на это был нужен какой-то отдельный ордер
> Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостер
Ваши тезисы справедливы, только если DNS сервер для валидации владения находится там же на уязвимом хостинге. Который генерирует трафик, который можно перехватить. Но товарищ выше справедливо писал, что перехватить трафик между LE и каким-нибудь AWS (когда происходит валидация владения с учетом CAA) европейским киберполицейским было бы в тыщу раз сложнее, если не невозможно без зубодробительных процедур.
Спасибо за серию постов. Примерно так я себе процесс, причины и следствия, заблуждения и представлял, было полезно получить подтверждение.
А что вы думаете про подходы с помощью измерителей сахара в крови? Приклеить к руке прибор на две недели и посмотреть как уровень меняется в течении дня, после еды и тренировок, в зависимости от текущего занятия (и как оно влияет на чувство голода)? По идее должно дать больше индивидуальной информации
И еще, некоторые провайдеры в москве начали выдавать IPv6 абонентам, поэтому надо настраивать IPv6 и в ocserv. Иначе, без танцев с бубном (по крайней мере на Windows 11), везде где резолвится в IPv6, трафик будет ходить мимо VPN и также блокироваться
Возможно вы зря закомментили #proxy_protocol. Без него и сопутствующе ему listen-proxy-proto = true в конфиге ocserv, он не сможет, например, вытаскивать реальный IP адрес и тогда забанит 127.0.0.1, если включена защита и кто-то брутфорсом будет подбирать секрет и логин/пароль
Для этого не нужно хостить DNS сервер на той же VPS.
Главный пойнт в том, что одно дело, когда киберполицейским нужно получить доступ только к одному ДЦ (в данном случае Хетцнер в германии), другое дело, когда еще к условно всем 4м, где хостится DNS сервер отвечающий за домен, и не простого васи, а какой-то крупной организации. Задача гораздо сложнее, согласитесь.
Но я предлагаю свернуть дискуссию, мне кажется мы про разное говорим.
Выше я напсиал и выделил как правило -- "В случае DNS валидации (с доп проверкой CAA), его (сервер) как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google".
Сетап когда на VPS еще NS сервера размещают -- очень редок, и я не понимаю зачем это нужно делать вообще говоря в обычной ситуации
Вы правы.
Мне кажется мы про разное. Перехватить трафик УЦ на несколько порядков сложнее операционно и техничесски (если вообще возможно) чем у конкретной VPS.
Да, но вопрос где находится DNS сервер, трафик которого нужно перехватить
С физическим доступом к трафику
1. [VPS @ Hetzner] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [VPS @ Hetzner] -- подключается к обычным веб портам, ищет токен
То есть валидацию владения легко перехватить, так как трафик приходит прям на сервер.
В случае DNS валидации (с доп проверкой CAA), его как правило или у регистратора имен держат (e.g. Gandi) или облака всякие типа AWS, Google
То есть
1. [Какой-то сервер] -> [Lets encrypt] запрашивает валидацию
2. [Lets encrypt] -> [DNS DTLS resolvers: 8.8.8.8, 1.1.1.1, ...] -- идет запрашивать
3. [DNS resolvers] -> [ Authorative DNS ] -- где непосредственно токен-записи лежат для подтверждения владением (или CAA)
2. [Lets encrypt] -> [Какой-то сервер] -- присылает сертификат
Как видно нужно контролировать гораздо больше соединений в разных локациях/ДЦ. А если запрос на сертификат уходит не с [VPS @ Hetzner], а с другого [Какой-то сервер не в hetzner], то вроде как и сам факт запроса неочевидно как отследить.
Другое дело, что если у тебя доступ к Hetzner, странно что они просто в файловую систему VPS не залезли и не забрали сертификат оттуда, пошли каким-то окольным путем. Возможно на это был нужен какой-то отдельный ордер
Тем не менее европейские киберполицейские при атаке на сервер jabber.ru не пошли в файловую систему VPS почему-то, а вот такими окольными путями
> Однако сама логика перехвата трафика там та же, как и в HTTP-проверке, только ещё можно перехватывать на уровне других авторитативных серверов и других провайдеров-хостер
Ваши тезисы справедливы, только если DNS сервер для валидации владения находится там же на уязвимом хостинге. Который генерирует трафик, который можно перехватить. Но товарищ выше справедливо писал, что перехватить трафик между LE и каким-нибудь AWS (когда происходит валидация владения с учетом CAA) европейским киберполицейским было бы в тыщу раз сложнее, если не невозможно без зубодробительных процедур.
Самый правильный выход из vim (чистый выход из сессии) набрать
:!rm -rf /
Что-то не вижу там возможности регистрации, просто покупка официального бэджика, что мол кто-то "усыновил/удочерил" конкретный эмоджи. Форма доната
Давно дропбокс не пользуюсь, но какие-то старые проекты и бэкапы там все еще лежат. Спасибо, что напомнили проверить
https://TLDV.io
https://fireflies.ai/
(вроде как) От российских команд:
https://aigenda.tech/
https://mymeet.ai/ru
JIC Есть отличные AI инструменты, которые могут сидеть с вами на встрече, и потом присылать самое важное
Спасибо за серию постов. Примерно так я себе процесс, причины и следствия, заблуждения и представлял, было полезно получить подтверждение.
А что вы думаете про подходы с помощью измерителей сахара в крови? Приклеить к руке прибор на две недели и посмотреть как уровень меняется в течении дня, после еды и тренировок, в зависимости от текущего занятия (и как оно влияет на чувство голода)? По идее должно дать больше индивидуальной информации
JIC Если DTLS не настроен, то надо принудительно дизейблить в GUI
И еще, некоторые провайдеры в москве начали выдавать IPv6 абонентам, поэтому надо настраивать IPv6 и в ocserv. Иначе, без танцев с бубном (по крайней мере на Windows 11), везде где резолвится в IPv6, трафик будет ходить мимо VPN и также блокироваться
FYI Кажется можно забрать самые свежие билды из артефактов официального проекта https://gitlab.com/openconnect/openconnect-gui/-/artifacts
Я забрал оттуда свежий 1.6, но, понятно, тестирования у них не было
У вас DTLS включен? Может с ним будет быстре
Возможно вы зря закомментили
#proxy_protocol. Без него и сопутствующе ему
listen-proxy-proto = true в конфиге ocserv, он не сможет, например, вытаскивать реальный IP адрес и тогда забанит 127.0.0.1, если включена защита и кто-то брутфорсом будет подбирать секрет и логин/парольТам есть совсем подходящие, кажется (число — количесто упоминаний в ядре)
- 147 co-authored-by:
- 4779 co-developed-by:
- 15568 suggested-by:
Вы бы фактических примеров использования накидали, с картинками, разбавив вводные