Общий ЧаВо:
https://kb.vmware.com/s/article/86398
Симптомы
https://kb.vmware.com/s/article/86287
https://kb.vmware.com/s/article/86281
Предупреждение. Эта ошибка появляется не просто так. Возможно ваш компютер действительно небезопасен по каким-либо причинам, например, у вас заражение программой-шпионом.
В моем случае мне была точно известна причина - это установка на рабочий ноутбук фильтра трафика, который вне рабочей сети проводит весь поток трафика через свой сайт. Фильтр работает по принципу атаки Man in the Middle (MitM).При этом трафик подписывается сертификатом этого фильтра. Но предложенное решение исправило и другие проблемы с запросом дополнительного подтверждения перед открытием страницы, даже внутри корпоративной сети
Итак, на некоторых внутренних сайтах компании я получал такое сообщение
Warning: Potential Security Risk Ahead
Firefox detected a potential security threat and did not continue to
Сайт внутренний, подписан корпоративным сертификатом, причем не самоподписным, в вполне себе "нотариально заверенным" международным центром сертификации. Я воспринимал это как должное. Можно нажать кнопку "Advanced" и подтвердить согласие на открытие сайта и осознание рисков
Но пришла новая напасть. Некоторые сайты перестали открываться вообще. Это наблюдалось только при работе из внешней сети. Но сайты были не какие-то там подозрительные, а самые популярные вроде yandex.ru и google.com. И обойти блокировку было нельзя. При этом, например, Chrome открывал эти сайты без проблем. Ошибка была со следующим текстом:
Software is Preventing Firefox From Safely Connecting to This Site
www.google.com is most likely a safe site, but a secure connection could not be established. This issue
is caused by <3d party certificate>, which is either software on your computer or your network.
What can you do about it?
www.google.com has a security policy called HTTP Strict Transport Security (HSTS), which means
that Firefox can only connect to it securely. You can’t add an exception to visit this site.
В сообщении об отказе в открытии упоминается политика HTTP Strict Transport Security (HSTS)
Ответ есть в Вики Firefox
Проблема должна исчезнуть
Основано на новости "Firefox 85 перейдёт на ECH для скрытия домена в HTTPS-трафике"
От кого защищаемся - от провайдера, который может
1. Ограничивать трафик на определенные хосты по содержианию пакета ClientHello или по DNS-адресу.
2. Читать и запоминать, на какие сайты вы ходите.
Эта защита на уровне браузера. Рекомендуетися использовать DNS через TLS, как настроить кеширующий DNS-сервер с поддержкой TLS на Ubuntu я написал тутИтак, 4 настройки в браузере. Первые 3 делаются в меню "Options" ("Параметры")
1. Включаем HTTPS для всего трафика. В Интернете подавляющее большинство сайтов поддерживают протокол HTTPS. Но вот в локальной сети компании могут быть устаревшие сайты. Если какой-то сайт перестал открываться, вернитесь в эту настройку.
Выбираем слева раздел Privacy and Security, справа в самом низу окна настроек "HTTP-Only Mode". Самый безопасный вариант - "Enable HTTPS-Only Mode in all windows"
2. Включаем DNS через TLS для браузера. Слева раздел General, справа в самом внизу пункт "Network Settings"
Далее внизу нового диалогового окна поставить галочку напротив "Enable DNS over HTTPS". В ставшем активном выпадающем списке можно выбрать провайдера, например, CloudFlare или ввести настройки самому (Custom)
Спецификация ECH продолжает развитие ESNI и находится на стадии черновика, претендующего на роль стандарта IETF. Для организации работы на одном IP-адресе нескольких HTTPS-сайтов в своё время было разработано TLS-расширение SNI, осуществляющее передачу имени хоста в открытом виде в сообщении ClientHello, передаваемом до установки шифрованного канала связи. Подобная особенность даёт возможность на стороне интернет-провайдера выборочно фильтровать HTTPS-трафик и анализировать какие сайты открывает пользователь, что не позволяет добиться полной конфиденциальности при применении HTTPS.
<... >
В ответ на потребность в шифровании параметров любых TLS-расширений был предложен универсальный механизм ECH, главное отличие которого от ESNI в том, что вместо отдельного поля шифруется всё сообщение ClientHello. ECH подразумевает наличие двух типов сообщений ClientHello - шифрованное сообщение ClientHelloInner и незашифрованное базовое сообщение ClientHelloOuter. Если сервер поддерживает ECH и смог расшифровать ClientHelloInner, то он продолжает использовать данный тип для TLS-сеанса. В противном случае берутся данных из ClientHelloOuter.
В адресной строке браузера Firefox набираем about:config и наживаем Ввод. В строке поиска (см. рисунок) набираем "network.dns":
В списке находим два параметра: "network.dns.echconfig.enabled" и "network.dns.use_https_rr_as_altsvc". Если сделать двойной щелчок, то значение сменится на противоположенное. Нам надо для обоих поставить True. После изменений перезагрузить браузер.
На сегодня всё.
Размышлял, писать об этом статью или нет. Ведь если известен способ проверить данные о себе, то ничего не мешает проверить данные и о других. Но решил, что люди, ищущие информацию о других, куда опытнее меня и потенциальных читателей этом деле. Им мои подсказки не нужны. А вот простой пользователь может не знать как провести аудит. И именно он может быть под угрозой.
Статья написана в образовательных целях, прежде всего, чтобы пользователи почтового сервиса gmail.com могли проверить, не выставили ли они лишней информации в сеть.
Началось всё со статьи "Что можно узнать о человеке по адресу его почты на Gmail? Проверяем с помощью GHunt". Если у вас есть вопрос, а зачем вам нужна такая проверка, то прочтите статью и решите, может, и в самом деле, вас это не волнует. Ниже описание практической части, как поставить и запустить.
Проект GHunt гнездится на github.com - https://github.com/mxrch/GHunt. Адрес нам пригодиться для скачивания проекта.
Я использую Mac OS. На Linux будет всё примерно так же. Про Windows советов у меня нет. Не пробовал запускать на нем Docker. Да и с Python под Виндой не работал.
Еще одно уточнение. Автор скриптов предполагает, что у вас установлен Google Chrome. Я этому браузеру не доверяю (хотя бы история с включенным микрофоном), поэтому в моем описании используется Firefox (или Tor).
Проверка состоит из двух частей.
1. Создание новой учетной записи gmail.com. Это следует из рекомендации автора скриптов:
I suggest you make an empty account just for this or use an account where you never login because depending on your browser/location, re-logging in into the Google Account used for the cookies can deauthorize them.
2. Собственно подготовка и запуск самих скриптов.
По первой части есть два пути - простой и сложный. Простой:
Выходите из своей учетной записи Gmail, переходите по адресу https://www.google.com/gmail/about/, нажимаете "Create Account", заполняете поля (ФИ, желаемый адрес электройнной почты), на следующем экране вводите номер своего телефона и завершаете регистрацию.
Теперь сложный путь. Как обойтись без номера телефона. Мне помогла статья "How To Create Gmail Account Without Phone Number 2021". В ней дается 2 варианта - через браузер Chrome (мне не подходит) и через эмулятор Andoroid "Bluestacks". Я воспользовался им.
Алгоритм простой:
- Переходите на сайт Bluestacks и скачиваете эмулятор под свою ОС. Не удивляйтесь дизайну сайта (картинки из компьютерных игр). Эмулятор сделан для того, чтобы играть на компьютере в игры для смартфонов.
- Устанавливаете и запускаете эмулятор
После окончания регистрации сам эмулятор больше не нужен. Теперь в обычном браузере (Firefox, Tor, другое) заходите в новую учетную запись.
Я не понял предупреждения автора скриптов, почему надо заходить под учетной записью, под которой вы ни разу до этого не авторизовывались. И вообще, как это возможно?
Зайдя в почту вызываем консоль разработчика. В Firefox - клавиши Shift + F9.
- SID
- SSID
- APISID
- SAPISID
- HSID
Они потребуются для создания токенов. Не выходите из учетной записи, чтобы куки не протухли.
Всё, с первой частью разобрались. Теперь сами скрипты.
На этом этапе опять развилка. Можно скачать себе скрипты (если установлен Chrome), а можно использовать готовый контейнер Docker. Рассмотрю оба.
Путь 1. Docker.
1. С сайте https://www.docker.com/products/docker-desktop скачиваете и ставите Docker (если еще не стоит). Далее работаете в терминале ОС (Mac OS, Linux).
2. Скачиваете образ контейнера:
docker pull mxrch/ghunt
Запускаете первую команду:
docker run -v ghunt-resources:/usr/src/app/resources -ti mxrch/ghunt check_and_gen.py
docker run -v
Будет запрос на куки. копируете сохраненные значения, скопированные из консоли разработчика. система сгенерирует токены.
После это выполняете команду, подставив вместо <email_address> адрес своей настоящей электронной почты для ее аудита:
docker run -v ghunt-resources:/usr/src/app/resources -ti mxrch/ghunt hunt.py <email_address>
Путь 2. Без Docker'a.
Подготовка:
1. Скачиваем и устанавливаем последнюю версию Python (https://www.python.org/). Автор пишет, что нужно не ниже Python 3.7. Сам он пишет на Python 3.8.1. Все версии верны на момент написания статьи. Если у вас установлено несколько версий Python, убедитесь, что по умолчанию используется правильная версия. Как это сделать для Mac OS написано в этой статье.
2. Открываем терминал, Создаем папку, куда будем качать проект. Например,
MacBook$ mkdir ~/Downloads/ghunt/
MacBook$ cd ~/Downloads/ghunt/
3. Качаем проект:
MacBook$ git clone https://github.com/mxrch/GHunt
4. Ставим необходимые библиотеки для Python:
MacBook$ python -m pip install -r requirements.txt
5. Запустить скрипт "check_and_gen.py"
MacBook$ python check_and_gen.py
Будет запрос на куки. Копируете сохраненные значения, скопированные из консоли разработчика. система сгенерирует токены.
6. Наконец, запускаем команду сбора
MacBook$ python hunt.py <email_address>
Подставляем вместо <email_address> адрес своей настоящей электронной почты для ее аудита.
Будет примерно такой вывод:
MacBook$ docker run -v ghunt-resources:/usr/src/app/resources -ti mxrch/ghunt hunt.py username@gmail.com
.d8888b. 888 888 888
d88P Y88b 888 888 888
888 888 888 888 888
888 8888888888 888 888 88888b. 888888
888 88888 888 888 888 888 888 "88b 888
888 888 888 888 888 888 888 888 888
Y88b d88P 888 888 Y88b 888 888 888 Y88b.
"Y8888P88 888 888 "Y88888 888 888 "Y888
[+] Docker detected, profile pictures will not be saved.
[+] 1 account found !
------------------------------
[-] Couldn't find name
[-] Default profile picture
Last profile edit : 2020/10/20 10:10:10 (UTC)
Email : username@gmail.com
Google ID : 111111111111111111111
Hangouts Bot : No
[-] Unable to fetch connected Google services.
Google Maps : https://www.google.com/maps/contrib/111111111111111111111/reviews
[-] No reviews
Google Calendar : https://calendar.google.com/calendar/u/0/embed?src=username@gmail.com
[-] No public Google Calendar.
На этом всё. Будьте аккуратны, следите за своими персональными данными.
Оригинал статьи "WhatsApp Soundly Beaten By Apple’s Stunning New iMessage Update"
И русская адаптация "Facebook Messenger и WhatsApp собирают критическое количество метаданных"
Добавка. А вот еще интересная статья про WhatsApp. "WhatsApp gives users an ultimatum: Share data with Facebook or stop using the app". Изменение в пользовательском соглашении. Вам необходимо согласиться, что персональная информация о вас, известная WhatsApp может быть и будет передана другим компаниям группы Facebook, а при некоторых обстоятельствах и сторонним организациям. Указано, что речь идет о следующих данных:
“As part of the Facebook family of companies, WhatsApp receives information from, and shares information with, this family of companies <...> We may use the information we receive from them, and they may use the information we share with them, to help operate, provide, improve, understand, customize, support, and market our Services and their offerings.”Если не соглашаетесь, то 8 февраля вас отключат.
Что входит в группу компания Facebook.
Полностью на русском языке соглашение тут.
Добавка 2. Смена лицении в WhatsApp перенесли на май 2021 года. В мае опять перенесут? Или откажутся от идеи? Или отделят WhatsApp от Facebook.
HTTPS - уже везде. Но как убрать от посторонних парсеров свои запросы к серверам DNS, которые идут без шифрования? Используем DNS over TLS.
В статье рассмотрен вариант настройки кеширующего DNS-сервера для локальной сети. Если требуется DNS через TLS только на самом компьютере (поддержка запросов от других устройств не нужна), то данное решение избыточно. Можно посмотреть эту или вот эту статьи.
За основу взял статью здесь. Ровно по статье сделать не удалось. Общая идея такая. Используем связку из stubby и unbound. Демон Stubby умеет принимать запросы от локальной машины, зашифровывать их и отправлять на DNS-сервер с поддержкой шифрования. Unbound - это DNS-сервер, он будет кеширующим DNS-сервером для нашей локальной сети. Запросы на еще не закешированные адреса он будет отдавать Stubby. Вместо Unbound может быть другой DNS-сервер. В Интернете есть примеры настройки. Используемая связка Stubby и Unbound - достаточно популярна.
Начинаем.
1. Устанавливаем сами приложения
microserver:~$ sudo apt install stubby unbound
Ставим инструменты тестирования:
microserver:~$ sudo apt install bind9-dnsutils net-tools
2. Отключаем системный DNS-клиент
microserver:~$ sudo systemctl disable systemd-resolved.service
Removed /etc/systemd/system/dbus-org.freedesktop.resolve1.service.
Removed /etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
microserver:~$ sudo service systemd-resolved stop
Теперь надо отредактировать файлы настроек
3. Настройки Unbound (файл "/etc/unbound.conf"). По умолчанию он содержит только 1 строку с include. Добавляем в файл следующие настройки
server:
interface: 192.168.1.254
interface: 127.0.0.1
access-control: 192.168.1.0/24 allow
use-syslog: yes
username: "unbound"
directory: "/etc/unbound"
minimal-responses: yes
qname-minimisation: yes
rrset-roundrobin: yes
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@8053
forward-addr: ::1@8053
Красным выделил значения, которые нужно исправить под свою сеть. "interface" - адрес вашей машины, на которой настраивается DNS-сервер. "access-control" - ваша подсеть маской (/24 эквивалентно маске 255.255.255.0, /16 эквивалентно маске 255.255.0.0). У автора оригинальной стать interface равен 0.0.0.0. У меня такая настройка вызывала ошибку запуска демона.
4. Теперь настройки для Stubby. Весь файл настроек длинный, целиком приводить не буду. Но правки нужны незначительные. В секцию "LISTEN ADDRES" надо добавить прослушиваемые адреса (выделил синим):
################################ LISTEN ADDRESS ################################
# Set the listen addresses for the stubby DAEMON. This specifies localhost IPv4
# and IPv6. It will listen on port 53 by default. Use <IP_address>@<port> to
# specify a different port
listen_addresses:
- 127.0.0.1@8053
- 0::1@8053
Выбираем, какие серверы DNS будут использоваться. Это секции:
############################ DEFAULT UPSTREAMS ################################
############################ OPTIONAL UPSTREAMS ###############################
По умолчанию открыты "Surfnet/Sinodun", "getdnsapi.net". Я еще открыл "Quad 9 'secure' service", "Cloudflare 1.1.1.1 and 1.0.0.1". Не большой специалист в различиях этих серверов. Знаю, что есть сравнения. Если руки дойдут прочитать, то сделаю обновление в статье.
Секция IPv6 у меня закомментирована.
####### IPv6 addresses #######
5. Перестартовываем демоны, настраиваем автозапуск
microserver:~$ sudo systemctl restart unbound
microserver:~$ sudo systemctl enable unbound
microserver:~$ sudo systemctl restart stubby
microserver:~$ sudo systemctl enable stubby
6. На этом этапе должно было бы заработать. Но оказывается, надо еще проверить файл "/etc/resolv.conf". В нем должен быть адрес сервера имен 127.0.0.1 (выделил синим).
microserver:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.1
7. Как проверить, что работает. В статье предлагается использовать wireshark. Но у меня сервер без монитора и клавиатуры, настройка идет по SSH. Поэтому используем средства командной строки. Проверка делится на несколько этапов.
7.1. Проверяем, что работает кеширующий DNS-сервер. На настраиваемой машине запускаем команду "ss":
microserver:~$ sudo ss -tuna | grep '\(State\|:53 \)'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:*
udp UNCONN 0 0 192.168.1.254:53 0.0.0.0:*
tcp LISTEN 0 256 127.0.0.1:53 0.0.0.0:*
tcp LISTEN 0 256 192.168.1.254:53 0.0.0.0:*
Видим, что порты прослушиваются.
Теперь на другой машине (Linux, Mac OS) в локальной сети запускаем программу nslookup, меняем сервер на наш настроенный и вводим любимое имя домена для проверки:
desktop$ nslookup
> server 192.168.1.254
Default server: 192.168.1.254
Address: 192.168.1.254#53
> mail.ru
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
Name: mail.ru
Address: 217.69.139.202
Name: mail.ru
Address: 94.100.180.200
Name: mail.ru
Address: 94.100.180.201
Name: mail.ru
Address: 217.69.139.200
> exit
Должны вернуться IP-адреса выбранного доменного имени.
7.2. Теперь проверяем, что запросы от нашего сервера идут через порт 853 на выбранные серверы DNS.
Проверяем, что Stubby на месте:
microserver:~$ sudo netstat -lnptu |grep stubby
tcp 0 0 127.0.0.1:8053 0.0.0.0:* LISTEN 921/stubby
udp 0 0 127.0.0.1:8053 0.0.0.0:* 921/stubby
теперь шлем запросы DNS и смотрим активность на портах. Нашел 2 способа.
На настраиваемой машине или на машине в локальной сети делаем запрос к нашему серверу средствами nslookup (см. выше) или dig:
microserver:~$ dig github.com
; <<>> DiG 9.16.1-Ubuntu <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com. IN A
;; ANSWER SECTION:
github.com. 52 IN A 140.82.121.3
;; Query time: 395 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Пн янв 04 02:19:08 MSK 2021
;; MSG SIZE rcvd: 55
Сразу после этого на настраиваемом сервере запускаем команду
microserver:~$ sudo ss -tuna | grep '\(State\|:853 \)'
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp TIME-WAIT 0 0 192.168.1.254:41080 145.100.185.16:853
Должен быть виден запрос на порт 853 одного из выбранных нами внешних DNS-серверов.
Тут есть нюанс. Наш DNS-сервер - кеширующий. Поэтому, если вы запросите разрешение одного имени несколько раз, то запрос на внешний DNS-сервер будет отправлен только первый раз, а остальные разы ответ будет взят из кеша, и команда "ss" активность на внешнем интерфейсе не покажет.
Второй вариант - длинная и страшная команда: "sudo tcpdump -tttt -nn -XX -vv -i <сетевой интерфейс> dst <адрес внешнего DNS-сервера> and port 853". <сетевой интерфейс> надо заменить на имя сетевого интерфейса настраиваемого сервера (в моем случае это em1). Узнать его можно командой ifconfig:
microserver:~$ ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255
ether d8:d3:85:b3:a7:7b txqueuelen 1000 (Ethernet)
RX packets 275855 bytes 29605256 (29.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 602983 bytes 866307263 (866.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Локальная петля (Loopback))
RX packets 11410 bytes 3637832 (3.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11410 bytes 3637832 (3.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
С <адрес внешнего DNS-сервера> тоже всё непросто. Если вы, как и я, выбрали для Stubby в "UPSTREAMS" несколько внешних DNS-серверов, то запросы будут отсылаться по всему списку внешних DNS-серверов по кругу. Поэтому в качестве <адрес внешнего DNS-сервера> надо выбрать один из IP-адресов в списке внешних DNS-серверов. А дальше отправлять несколько запросов на разрешение имен с разными именами домена (помним, что наш DNS-сервер кеширующий). Следить, к какому DNS-серверу был отправлен запрос на этот раз можно с помощью команды "ss" (см. выше)
Последовательность действий в тесте другая. Вначале запускаем команду tcpdump, она начинает слушать "разговоры", а потом в другом терминале или с другой машины выполняем запрос на разрешение имени в dig или nslookup. Если нас DNS-сервер работает верно, то tcpdump выдаст что-то вроде:
evgeniy@microserver:~$ sudo tcpdump -tttt -nn -XX -vv -i em1 dst 145.100.185.16 and port 853
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-01-04 01:08:58.402475 IP (tos 0x0, ttl 64, id 9505, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.254.41040 > 145.100.185.16.853: Flags [S], cksum 0x0d46 (incorrect -> 0xbaae), seq 998080101, win 64240, options [mss 1460,sackOK,TS val 2231476927 ecr 0,nop,wscale 7], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 003c 2521 4000 4006 0884 c0a8 01fa 9164 .<%!@.@........d
0x0020: b910 a050 0355 3b7d 7e65 0000 0000 a002 ...P.U;}~e......
0x0030: faf0 0d46 0000 0204 05b4 0402 080a 8501 ...F............
0x0040: a2bf 0000 0000 0103 0307 ..........
2021-01-04 01:08:58.450555 IP (tos 0x0, ttl 64, id 9506, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x8035), seq 998080102, ack 3565166824, win 502, options [nop,nop,TS val 2231476975 ecr 528108829], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2522 4000 4006 088b c0a8 01fa 9164 .4%"@.@........d
0x0020: b910 a050 0355 3b7d 7e66 d480 20e8 8010 ...P.U;}~f......
0x0030: 01f6 0d3e 0000 0101 080a 8501 a2ef 1f7a ...>...........z
0x0040: 4d1d M.
2021-01-04 01:08:58.451246 IP (tos 0x0, ttl 64, id 9507, offset 0, flags [DF], proto TCP (6), length 533)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0f1f (incorrect -> 0x99e2), seq 0:481, ack 1, win 502, options [nop,nop,TS val 2231476976 ecr 528108829], length 481
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0215 2523 4000 4006 06a9 c0a8 01fa 9164 ..%#@.@........d
0x0020: b910 a050 0355 3b7d 7e66 d480 20e8 8018 ...P.U;}~f......
0x0030: 01f6 0f1f 0000 0101 080a 8501 a2f0 1f7a ...............z
0x0040: 4d1d 1603 0101 dc01 0001 d803 03c8 f1ea M...............
0x0050: fcbe c3c9 dbd8 01ee c0f6 263b a4d1 4581 ..........&;..E.
0x0060: b851 838c 2e85 0fb3 bbab f789 0a20 4d9c .Q............M.
0x0070: e7ab 2589 c245 3a70 7535 9fbb c1b2 d6be ..%..E:pu5......
0x0080: 7266 85cf 092a c764 d92b 2a7f a91f 0014 rf...*.d.+*.....
0x0090: 1302 1303 1301 c02c c030 c02b c02f cca9 .......,.0.+./..
0x00a0: cca8 00ff 0100 017b 0000 001c 001a 0000 .......{........
0x00b0: 1764 6e73 6f76 6572 746c 7331 2e73 696e .dnsovertls1.sin
0x00c0: 6f64 756e 2e63 6f6d 000b 0004 0300 0102 odun.com........
0x00d0: 000a 000c 000a 001d 0017 001e 0019 0018 ................
0x00e0: 0023 00d0 5d82 2269 e2e6 8080 3ff2 1439 .#..]."i....?..9
0x00f0: e45e d872 662f befe f39c a5d4 3115 38d0 .^.rf/......1.8.
0x0100: c0d0 b8ea 38f1 4c07 40b0 1b7b 7515 9627 ....8.L.@..{u..'
0x0110: 71c8 8055 a51e f022 ad3c a73c 8ec7 11e5 q..U...".<.<....
0x0120: a5a3 586f 2867 e222 343f 7e0b 0158 245e ..Xo(g."4?~..X$^
0x0130: 2867 d209 66e4 09ff d652 edc0 7c90 ec53 (g..f....R..|..S
0x0140: 13ec b497 903b dc9c 03a0 382b 165e 8db0 .....;....8+.^..
0x0150: 4ce2 5e5c f965 2061 2d83 8030 f220 61b3 L.^\.e.a-..0..a.
0x0160: 2d33 d368 a3ef c8fc 5fd2 910d c76b 545b -3.h...._....kT[
0x0170: bac8 24e7 1825 fab2 40ab a331 fd79 3b74 ..$..%..@..1.y;t
0x0180: ee65 4fa6 c0af d853 c96c f12c 78e8 382f .eO....S.l.,x.8/
0x0190: 2eb3 12d2 4a9d 9574 aa12 8bcd 6837 7829 ....J..t....h7x)
0x01a0: 5cd7 c385 1fd5 da41 81e0 a70a 4e95 5640 \......A....N.V@
0x01b0: 5876 8f9e 0016 0000 0017 0000 000d 002a Xv.............*
0x01c0: 0028 0403 0503 0603 0807 0808 0809 080a .(..............
0x01d0: 080b 0804 0805 0806 0401 0501 0601 0303 ................
0x01e0: 0301 0302 0402 0502 0602 002b 0005 0403 ...........+....
0x01f0: 0403 0300 2d00 0201 0100 3300 2600 2400 ....-.....3.&.$.
0x0200: 1d00 209d db9a a404 bd4b 2675 03eb 8164 .........K&u...d
0x0210: 645e db98 d331 8d5b 17e0 3e92 7c98 2c85 d^...1.[..>.|.,.
0x0220: 9d8b 0d ...
2021-01-04 01:08:58.499724 IP (tos 0x0, ttl 64, id 9508, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x7d8f), seq 481, ack 138, win 501, options [nop,nop,TS val 2231477024 ecr 528108841], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2524 4000 4006 0889 c0a8 01fa 9164 .4%$@.@........d
0x0020: b910 a050 0355 3b7d 8047 d480 2171 8010 ...P.U;}.G..!q..
0x0030: 01f5 0d3e 0000 0101 080a 8501 a320 1f7a ...>...........z
0x0040: 4d29 M)
2021-01-04 01:08:58.500478 IP (tos 0x0, ttl 64, id 9509, offset 0, flags [DF], proto TCP (6), length 103)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0d71 (incorrect -> 0xaf2d), seq 481:532, ack 138, win 501, options [nop,nop,TS val 2231477025 ecr 528108841], length 51
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0067 2525 4000 4006 0855 c0a8 01fa 9164 .g%%@.@..U.....d
0x0020: b910 a050 0355 3b7d 8047 d480 2171 8018 ...P.U;}.G..!q..
0x0030: 01f5 0d71 0000 0101 080a 8501 a321 1f7a ...q.........!.z
0x0040: 4d29 1403 0300 0101 1603 0300 28e5 3ed0 M)..........(.>.
0x0050: 830d ad39 07f9 5171 417e 0a4b 0f19 e7fa ...9..QqA~.K....
0x0060: 7bfb 659b 9e07 0b26 8f8c 5fee e9e7 3dd9 {.e....&.._...=.
0x0070: a686 5f52 c1 .._R.
2021-01-04 01:08:58.585012 IP (tos 0x0, ttl 64, id 9510, offset 0, flags [DF], proto TCP (6), length 211)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0ddd (incorrect -> 0x6f00), seq 532:691, ack 138, win 501, options [nop,nop,TS val 2231477109 ecr 528108863], length 159
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 00d3 2526 4000 4006 07e8 c0a8 01fa 9164 ..%&@.@........d
0x0020: b910 a050 0355 3b7d 807a d480 2171 8018 ...P.U;}.z..!q..
0x0030: 01f5 0ddd 0000 0101 080a 8501 a375 1f7a .............u.z
0x0040: 4d3f 1703 0300 9ae5 3ed0 830d ad39 0804 M?......>....9..
0x0050: 835b ed3f d4a0 e0e4 cd33 7baa 3807 1992 .[.?.....3{.8...
0x0060: 4b2c 6c5e a1fd 7bde 7c35 e71d e173 99ff K,l^..{.|5...s..
0x0070: e135 5f60 1d53 e878 c935 f1ec f630 a99b .5_`.S.x.5...0..
0x0080: b5a2 f97f 13b3 7a5c ce2f c8f4 9465 5d0d ......z\./...e].
0x0090: fe8f e051 cd3d 012f 0f24 9bda f6dd eef6 ...Q.=./.$......
0x00a0: 8d18 24c6 2ad0 0823 2325 19ff 3d9d 38ef ..$.*..##%..=.8.
0x00b0: 34b0 f26c c78f e94b 4d8f 0265 2429 aaad 4..l...KM..e$)..
0x00c0: eeae 9dbf 77aa 9cfd 352d 6c9b 373f 9e1e ....w...5-l.7?..
0x00d0: 4b13 0c90 e7b3 5eca 8470 1e34 1f54 c4a2 K.....^..p.4.T..
0x00e0: fb .
2021-01-04 01:08:58.633697 IP (tos 0x0, ttl 64, id 9511, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x7a22), seq 691, ack 637, win 501, options [nop,nop,TS val 2231477158 ecr 528108875], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2527 4000 4006 0886 c0a8 01fa 9164 .4%'@.@........d
0x0020: b910 a050 0355 3b7d 8119 d480 2364 8010 ...P.U;}....#d..
0x0030: 01f5 0d3e 0000 0101 080a 8501 a3a6 1f7a ...>...........z
0x0040: 4d4b MK
2021-01-04 01:09:08.634244 IP (tos 0x0, ttl 64, id 9512, offset 0, flags [DF], proto TCP (6), length 83)
192.168.1.254.41040 > 145.100.185.16.853: Flags [P.], cksum 0x0d5d (incorrect -> 0x8b01), seq 691:722, ack 637, win 501, options [nop,nop,TS val 2231487159 ecr 528108875], length 31
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0053 2528 4000 4006 0866 c0a8 01fa 9164 .S%(@.@..f.....d
0x0020: b910 a050 0355 3b7d 8119 d480 2364 8018 ...P.U;}....#d..
0x0030: 01f5 0d5d 0000 0101 080a 8501 cab7 1f7a ...]...........z
0x0040: 4d4b 1503 0300 1ae5 3ed0 830d ad39 0992 MK......>....9..
0x0050: 5625 b6e6 9c5e 6832 16b2 1009 0c54 6eaa V%...^h2.....Tn.
0x0060: 69 i
2021-01-04 01:09:08.634394 IP (tos 0x0, ttl 64, id 9513, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [F.], cksum 0x0d3e (incorrect -> 0x52f1), seq 722, ack 637, win 501, options [nop,nop,TS val 2231487159 ecr 528108875], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 2529 4000 4006 0884 c0a8 01fa 9164 .4%)@.@........d
0x0020: b910 a050 0355 3b7d 8138 d480 2364 8011 ...P.U;}.8..#d..
0x0030: 01f5 0d3e 0000 0101 080a 8501 cab7 1f7a ...>...........z
0x0040: 4d4b MK
2021-01-04 01:09:08.681873 IP (tos 0x0, ttl 64, id 9514, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.254.41040 > 145.100.185.16.853: Flags [.], cksum 0x0d3e (incorrect -> 0x48f1), seq 723, ack 638, win 501, options [nop,nop,TS val 2231487206 ecr 528111387], length 0
0x0000: e894 f663 1dbe d8d3 85b3 a77b 0800 4500 ...c.......{..E.
0x0010: 0034 252a 4000 4006 0883 c0a8 01fa 9164 .4%*@.@........d
0x0020: b910 a050 0355 3b7d 8139 d480 2365 8010 ...P.U;}.9..#e..
0x0030: 01f5 0d3e 0000 0101 080a 8501 cae6 1f7a ...>...........z
0x0040: 571b W.
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Как бы всё.
И ссылки по теме:
1. Оригинальная статья "DNS over TLS: Protect your network with Ubuntu"
2. Альтернативный вариант - настройка прокси-сервера в облаке "How to Easily Set Up a DNS over TLS Resolver with Nginx on Ubuntu"
3. Настройка DNS over TLS на локальной машине (без кеширующего сервера) "DNS over TLS with systemd-resolved"
4. Еще один пример для локальной машины "Use DNS over TLS"
5. То же, что 3 и 4, "How to use DNS over TLS on Ubuntu Linux"
6. На одном сайте обзор решений по безопасности DNS "DNS Privacy Clients" и отдельно по Stubby "DNS Privacy Daemon - Stubby".
