Русский
Русский
English
Статистика
Реклама

Dns

Перевод Минимизация рисков использования DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH)

16.10.2020 08:10:13 | Автор: admin
Минимизация рисков использования DoH и DoTМинимизация рисков использования DoH и DoT

Защита от DoH и DoT

Организации вкладывают много времени, денег и усилий в обеспечение безопасности своих сетей. Однако, одной из областей, которой часто не уделяется должного внимания, является DNS. Контролируете ли вы свой DNS трафик?

Серьезность проблемы в том, что по данным Palo Alto Networks Unit 42 Threat Research, примерно 85% вредоносных программ используют DNS для установления канала управления и контроля, позволяя злоумышленникам легко внедрять вредоносные программы в вашу сеть, а также похищать данные. С момента своего создания трафик DNS в основном был незашифрованным и его легко можно было анализировать защитными механизмами NGFW.

Появились новые протоколы для DNS, направленные на повышение конфиденциальности DNS соединений. Они активно поддерживаются ведущими поставщиками браузеров и другими поставщиками программного обеспечения. Скоро в корпоративных сетях начнется рост зашифрованного DNS-трафика. Зашифрованный трафик DNS, который не анализируется средствами должным образом и разрешен, представляет угрозу безопасности для компании. Например, такой угрозой являются криптолокеры, которые используют DNS для обмена ключами шифрования. Атакующие сейчас требуют выкуп в несколько миллионов долларов за восстановление доступа к вашим данным. В компании Garmin, например,заплатили10 миллионов долларов.

При правильной настройке NGFW могут запрещать или защищать использование DNS-over-TLS (DoT) и могут использоваться для запрета использования DNS-over-HTTPS (DoH), что позволяет анализировать весь трафик DNS в вашей сети.

Что такое зашифрованный DNS?

Система доменных имен (DNS) преобразует удобочитаемые человеку доменные имена (например, адресwww.paloaltonetworks.com) в IP-адреса (например, в 34.107.151.202). Когда пользователь вводит доменное имя в веб-браузере, браузер отправляет DNS-запрос на DNS-сервер, запрашивая IP-адрес, связанный с этим доменным именем. В ответ DNS-сервер возвращает IP-адрес, который будет использовать этот браузер.

Запросы и ответы DNS пересылаются по сети в виде обычного текста в незашифрованном виде, что делает его уязвимым для шпионажа или изменения ответа и перенаправления браузера на вредоносные сервера. Шифрование DNS затрудняет отслеживание DNS-запросов или их изменение во время передачи. Шифрование DNS запросов и ответов защищает вас от атаки Man-in-the-Middle, выполняя при этом те же функции, что и традиционный протокол DNS (система доменных имен) с открытым текстом.

За последние несколько лет были внедрены два протокола шифрования DNS:

  1. DNS-over-HTTPS (DoH)

  2. DNS-over-TLS (DoT)

Эти протоколы имеют одну общую черту: намеренно прячут DNS-запросы от любого перехвата... и от безопасников организации в том числе. Протоколы в основном используют протокол TLS (Transport Layer Security) для установления зашифрованного соединения между клиентом, выполняющим запросы, и сервером, разрешающим запросы DNS, через порт, который обычно не используется для трафика DNS.

Конфиденциальность запросов DNS является большим плюсом этих протоколов. Однако, они создают проблемы безопасникам, которые должны следить за сетевым трафиком и обнаруживать и блокировать вредоносные соединения. Поскольку протоколы различаются по своей реализации, методы анализа будут отличаться у DoH и DoT.

DNS over HTTPS (DoH)

DNS внутри HTTPSDNS внутри HTTPS

DoH использует хорошо известный порт 443 для HTTPS, для которого в RFC специально указано, что задача состоит в том, чтобы смешать трафик DoH с другим трафиком HTTPS в одном и том же соединении, затруднить анализ трафика DNS и, таким образом, обойти меры корпоративного контроля (RFC 8484 DoH, раздел 8.1). Протокол DoH использует шифрование TLS и синтаксис запросов, предоставляемый общими стандартами HTTPS и HTTP/2, добавляя запросы и ответы DNS поверх стандартных запросов HTTP.

Риски, связанные с DoH

Если вы не можете отличить обычный HTTPS-трафик от запросов DoH, то приложения внутри вашей организации могут (и будут) обходить локальные настройки DNS, перенаправляя запросы на сторонние сервера отвечающие на запросы DoH, что обходит любой мониторинг, то есть уничтожает возможность контроля за DNS трафиком. В идеале вы должны контролировать DoH используя функции расшифрования HTTPS.

ИGoogle, и Mozilla реализовали возможности DoHв последней версии своих браузеров, и обе компании работают над использованием DoH по умолчанию для всех запросов DNS.Microsoft также разрабатывает планыпо интеграции DoH в свои операционные системы. Минусом является то, что не только уважаемые компании-разработчики программного обеспечения, но и злоумышленники начали использовать DoH как средство обхода традиционных мер корпоративного межсетевого экрана. ( Например, просмотрите следующие статьи:PsiXBot теперь использует Google DoH,PsiXBot продолжает развиваться с обновленной инфраструктурой DNSианализ бэкдора Godlua.) В любом случае, как хороший, так и вредоносный трафик DoH останется незамеченным, оставив организацию слепой к злонамеренному использованию DoH в качестве канала для управления вредоносным ПО (C2) и кражи конфиденциальных данных.

Обеспечение видимости и контроля трафика DoH

В качестве наилучшего решения для контроля DoH мы рекомендуем настроить в NGFW расшифровку трафика HTTPS и блокировку трафика DoH (название приложения: dns-over-https).

Во-первых, убедитесь, что NGFW настроен для расшифровки HTTPS, согласноруководству по лучшим методам расшифровки.

Во-вторых, создайте правило для трафика приложения dns-over-https, как показано ниже:

Правило Palo Alto Networks NGFW для блокировки DNS-over-HTTPSПравило Palo Alto Networks NGFW для блокировки DNS-over-HTTPS

В качестве промежуточной альтернативы (если ваша организация не полностью реализовала расшифрование HTTPS) NGFW можно настроить для применения действия запретить к идентификатору приложения dns-over-https, но эффект будет ограничен блокировкой определенных хорошо известных серверов DoH по их доменному имени, так как без расшифрования HTTPS трафик DoH не может быть полностью проверен (см.Applipedia от Palo Alto Networks и выполните поиск по фразе dns-over-https).

DNS over TLS (DoT)

DNS внутри TLSDNS внутри TLS

В то время как протокол DoH стремится смешиваться с другим трафиком на том же порту, DoT вместо этого по умолчанию использует специальный порт, зарезервированный для этой единственной цели, даже специально запрещая использование того же порта для традиционного незашифрованного трафика DNS (RFC 7858 , Раздел 3.1).

Протокол DoT использует протокол TLS для обеспечения шифрования, инкапсулирующего стандартные запросы протокола DNS, с трафиком, использующим хорошо известный порт 853 (RFC 7858, раздел 6). Протокол DoT был разработан, чтобы упростить организациям блокировать трафик по порту, либо соглашаться на его использование, но включить расшифровку на этом порту.

Риски, связанные с DoT

Google реализовал DoT в своем клиентеAndroid 9 Pie и более поздних версиях, при этом по умолчанию включена настройка автоматического использования DoT, если он доступен. Если вы оценили риски и готовы к использованию DoT на уровне организации, то нужно, чтобы сетевые администраторы явно разрешали исходящий трафик на порт 853 через свой периметр для этого нового протокола.

Обеспечение видимости и контроля трафика DoT

В качестве наилучшей методики контроля за DoT мы рекомендуем любое из вышеперечисленного, исходя из требований вашей организации:

  • Настройте NGFW для расшифрования всего трафика для порта назначения 853. Благодаря расшифрованию трафика, DoT будет отображаться как приложение DNS, к которому вы можете применить любое действие, например, включить подпискуPalo Alto Networks DNS Securityдляконтроля DGA доменовили уже имеющийсяDNS Sinkholingи anti-spyware.

  • В качестве альтернативы можно полностью заблокировать движком App-ID трафик 'dns-over-tls' через порт 853. Обычно он заблокирован по умолчанию, никаких действий не требуется (если вы специально не разрешили приложение 'dns-over-tls' или трафик через порт 853).

Подробнее..

Популярные сайты все еще уязвимы для массовой DDoS-атаки

03.12.2020 16:09:25 | Автор: admin
Четыре года назад Twitter, Slack, Pinterest и другие популярные интернет-сервисы вышли из строя на один день из-за масштабной DDoS-атаки на DNS-серверы провайдера Dyn. Недавно группа исследователей решила проверить, какие уроки были вынесены жертвами. Спойлер: никакие.



DDoS от электрочайника


Четыре года назад, 21 октября 2016-го, провайдер Dyn стал жертвой массированной DDos-атаки. Она продолжалась в течение почти всего дня и в результате значительная часть популярных мировых интернет-сервисов была недоступна. Среди них Amazon, Airbnb, CNN, Netflix, PayPal, Spotify, Visa и многие другие. Все они использовали в качестве провайдера DNS только решение от Dyn и не имели никакого резервного варианта на случай неполадок.

Считается, что атака была организована достаточно хитроумно, через ботнет MIrai, который включал в себя множество устройств интернета вещей чайников, кофеварок, телевизоров и так далее. Доступ к ним удалось получить по причине того, что большинство пользователей не изменили стандартные пароли к ним. Нагрузка в 1,2 терабита в секунду позволяет оценивать атаку, как одну из самых масштабных в истории. Эта атака фактически уничтожила Dyn и буквально через месяц, в ноябре, она была куплена компанией Oracle.

Вынесены ли уроки


Чтобы выяснить это, группа ученых из университета КарнегиМеллона исследовала 100 000 самых популярных мировых веб-сайтов из рейтинга Alexa. Их интересовало, какой процент сайтов до сих пор зависит от одного поставщика DNS.

Итоги они озвучили на недавней конференции Internet Measurement Conference. По их данным, в 2020-м, 89,2 % всех проанализированных ими веб-ресурсов пользуются услугами DNS-провайдера, а не разворачивают собственный сервер. А 84,8 % сайтов работают с одним DNS-провайдером, у них нет никакого запасного варианта на случай сбоя или атаки.

Число зависимых от одного DNS-поставщика ресурсов за четыре года выросло на 4,7%. Похоже, что никаких выводов после атаки сделано не было. Одна из самых характерных цифр с 2006 года только два сайта из Топ-100 Alexa добавили резервные DNS-серверы. Что касается небольших сайтов, они продолжают использовать одного провайдера, и в целом, большинство ресурсов пользуется услугами известного вендора. То есть, ситуация сегодня очень похожа на ту, которая была перед атакой в октябре 2016 года.

Зависимость от трех сервисов


По результатам исследования выяснилось три самых популярных провайдера среди Топ-100 000 сайтов из рейтинга Alexa. Это Cloudflare (24%), Amazon Web Services (12%) и GoDaddy (4%). Причем 38% этих сайтов используют только один из них, без какой-либо подстраховки.

Любые неполадки, как злонамеренные, так и случайные, могут положить значительную часть глобальной сети. И похоже, что именно это регулярно происходит. Например, атаки время от времени выводят из строя сервисы AWS.

Также исследователи проанализировали сайты, использующие CDN (сети доставки контента) и CA (центры сертификации). Результаты получились похожими многие ресурсы пользуются единственным сервисом, без какого-либо резервирования.

Что делать


Авторы исследования планируют использовать накопленную информацию для создания сервиса, который будет анализировать веб-сайты и давать рекомендации, что и как сделать, чтобы минимизировать урон при потенциальной DDoS-атаке. На основе анализа ресурсу будет присваиваться уровень защищенности для него планируют создать определенную метрику. Также озвучен еще более амбициозный план они могут провести исследования на предмет опасных зависимостей от одного поставщика в областях электронной коммерции, образования, государственного сектора и так далее.

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



Блог ITGLOBAL.COM Managed IT, частные облака, IaaS, услуги ИБ для бизнеса:



Подробнее..

VPN ещё раз просто о сложном

21.12.2020 16:08:05 | Автор: admin

Вы сталкивались с ошибкой Это видео не доступно для просмотра в Вашей стране? Пробовали заходить на LinkedIn? Подобные ограничения можно обойти с помощью включения VPN на своем девайсе. В последнее время огромное количество людей было вынуждено перейти на дистанционный формат работы и многие работодатели обязали своих сотрудников пользоваться VPN для защищенного доступа к корпоративным сервисам. Сегодня мы постараемся разобраться в том, что такое VPN и как это работает.

Disclaimer: я искала на Хабре базовую статью о VPN, но нашла из базы только часть цикла "Сети для самых маленьких". Это очень крутая работа, но она сразу не выпадает. Поэтому я решила обобщить все собранные мной определения, знания и структуры, а в начале дать ссылку на "Сети". Надеюсь, это поможет другим пользователям Хабра.

Ну и немного освежила тему - в нашем 2020 VPN многим пригодился.

Что такое VPN?

VPN Virtual Private Network виртуальная частная сеть.

Это совокупность технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет).

Расшифровка названия: сеть объединение нескольких устройств каким-либо видом связи, позволяющее обмениваться информацией. Виртуальная неосязаемая, не физическая, то есть не важно, по каким именно каналам связи она проложена. Физическая и логическая топологии могут как совпадать, так и отличаться. Частная в эту сеть не может войти посторонний пользователь, там находятся только те, кому разрешили доступ. В частной сети надо маркировать участников и их трафик, чтобы отличить его от остальной, чужой информации. Также в такой сети обеспечивается защита данных криптографическими средствами, попросту говоря, шифруется.

Приведем еще одно определение: VPN это сервис, позволяющий защитить приватные данные при пользовании Интернетом.

Зачем нужен VPN?

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

  • Чтобы объединить разные части одной компании. Офисы могут быть удалены друг от друга на любое расстояние.

  • Внутри компаний для объединения и изоляции отделов.

  • При подключении к Wi-fi в кафе, метро и т.д., чтобы хакеры не могли украсть ваши данные. При пользовании публичной сетью безопасно, разве что просматривать сайты в браузере. А вот если использовать соц.сети, злоумышленник может не только перехватить вашу конфиденциальную информацию, но и использовать ее в своих целях, авторизовавшись в этой самой соц.сети от Вашего имени. Еще хуже, если ему удастся взломать почту. Тогда атаке подвергнутся все приложения, привязанные к этому почтовому ящику. Но самой неприятной может оказаться утечка данных вашей банковской карты, если вы решили перевести кому-то деньги, подключившись к бесплатному Wi-fi.

  • Для получения доступа к сайтам, которые заблокированы на определенной территории. Приведем пример: Teen Spirit снимает передачу Орёл и Решка и продает ее двум телеканалам: российской Пятнице и украинскому Интеру. Обычно телеканалы на следующий день после выхода премьеры по телевидению, выкладывают выпуск на свой ютуб-канал, чтобы те, кто не успел посмотреть передачу по телевизору, имели возможность сделать это в интернете и, конечно же, для того, чтобы заработать дополнительно на встроенной в ютуб рекламе. На Украине выпуски выходят на день раньше, чем в России. Соответственно, Интер выкладывает видео на ютуб, когда по Пятнице передачу еще не показали. Поэтому в России в этот день запрещен доступ к этому видео.

  • Для обеспечения анонимности. Нельзя вычислить, какие сайты вы посещали, каким браузером пользуетесь, где находитесь и т.д. Надобность скрыть свою геолокацию может может возникнуть в путешествиях. Например, в Турции запрещен YouTube и WhatsApp. Значит, просто так зайти в привычные соц.сети не получится, а с VPN это сделать вполне возможно.

  • Чтобы в браузере оставалась история поиска, на основе которой создается таргетированная реклама

  • Чтобы сэкономить, например, при покупке авиабилетов. Авиакомпании устанавливают разные цены на одни и те же билеты для покупателей из разных регионов. А VPN позволяет изменить информацию о геолокации.

Как можно пользоваться VPN?

Итак, мы поняли, что VPN полезный сервис, но как именно можно его включить? Если Вы работаете за компьютером и хотите посетить заблокированный сайт, используя браузер, то можно или установить специальную программу на ПК (так называемый VPN-клиент), или добавить расширение для браузера, или использовать встроенный в Opera VPN. Все эти способы просты в исполнении, но имеют некоторые недостатки. Так, VPN-клиент выдает случайный IP-адрес, то есть нет возможности выбрать страну. Еще один неудобство заключается в необходимости постоянного запуска программы, однако, существуют программы, которые запускаются одновременно с ОС. Теперь рассмотрим следующий способ добавление расширения для браузера через Webstore. Нужно будет зарегистрироваться, после чего одним кликом можно выбрать страну, к VPN-серверу которой Вы хотите подключиться.

Использование VPN на смартфонах и айфонах реализуется через мобильные приложения. Самые популярные из них это OpenVPN для Android и Cloak для iOS.

О плюсах VPN и о том, как его можно установить уже Вы прочитали. Самое время поговорить о минусах.

Чем приходится платить за безопасность в Интернете?

  1. Низкая скорость интернета. На дополнительное шифрование требуется время. Также часто трафик проходит большее расстояние, что связано с удаленностью расположения VPN-сервера.

  2. Периодический разрыв VPN-подключения, внезапный выход трафика в публичную сеть. Часто можно не заметить разрыв подключения и утечку данных, также VPN-соединение может не восстанавливаться автоматически, что не удобно. Во современных ОС на базе Windows предусмотрена функция VPN Reconnect. Если ее нет, то придется использовать особые программы или специальные настройки маршрутизации, которые контролируют VPN-соединение и в случае его разрыва сначала блокируют передаваемую информацию, закрывают приложения, потом обновляют VPN-подключение.

  3. К сожалению, IPv6 почти никогда не поддерживается VPN. Следовательно, когда в публичной сети используется IPv6, и в интернет-ресурсе он также поддерживается, трафик пойдет по умолчанию по открытой IPv6 сети. Чтобы такого не произошло можно просто отключить IPv6 в ОС.

  4. DNS-протечки: на практике часто DNS-запросы обрабатываются DNS-серверами публичной сети (а не виртуальной, защищенной). В случае их некорректного ответа можно получить поддельный адрес запрашиваемого домена. Так, ничего не подозревающие пользователи могут быть перенаправлены, например, на сайты мошеннических онлайн-банков. Также по DNS-серверам можно определить примерную геолокацию и интернет-провайдера пользователя.

  5. Присутствуют также разнообразные юридические аспекты. Во-первых, это отличия в законодательстве разных государств. VPN-клиент и VPN-сервер часто находятся в разных странах. Также трафик может проходить через третью страну транзитом. Таким образом существует возможность сохранить себе копию передаваемых данных для дальнейшей расшифровки и изучения.

Существует не только вопрос что шифровать, но и как. Далеко не все криптографические средства разрешены. Из-за этого производители сетевого оборудования (в том числе для организаций VPN) при экспорте в другие страны вынуждены отключать в своей продукции ряд алгоритмов шифрования, а также уменьшать максимально возможную длину ключа.

Проблема кроется еще и в том, что сами мировые стандарты шифрования могут быть уязвимыми. Так, в 2013 году NIST (The National Institute of Standards and Technology организация, утверждающая стандарты шифрования в США) обвинили в том, что он разрешил включить в новый стандарт уязвимую версию генератора псевдослучайных чисел. Это позволило сильно упростить расшифровку информации, защищенной с применением этого генератора. Более того, составителей стандартов нередко обвиняют в сознательном усложнении описаний стандартов.

А законно ли вообще использовать VPN в России? В России действует закон Яровой, направленный против терроризма и экстремизма. С другой стороны его можно рассматривать как шаг в сторону регулирования и контролирования интернета, потому что этот закон обязует операторов связи хранить всю информацию о деятельности в интернете . Но если провайдер не сохраняет логи, то штрафовать будут его, а не конечных пользователей. Поэтому сейчас существует довольно много VPN-провайдеров, в том числе и бесплатных.

Как работает VPN?

Соединение VPN это, так называемый, туннель между компьютером пользователя и компьютером-сервером. Каждый узел шифрует данные до их попадания в туннель.

Вы подключаетесь к VPN, система идентифицирует вашу сеть и начинает аутентификацию (сравнивает введенный пароль с паролем в своей базе данных).

Далее сервер Вас авторизует, то есть предоставляет право на выполнение определенных действий: чтение почты, интернет-серфинг и т.д. После установления соединения весь трафик передается между вашим ПК и сервером в зашифрованном виде. Ваш ПК имеет IP-адрес, предоставленный интернет-провайдером. Этот IP блокирует доступ к некоторым сайтам. VPN сервер меняет ваш IP на свой. Уже с VPN-сервера все данные передаются к внешним ресурсам, которые вы запрашиваете. Теперь можно просматривать любые ресурсы и не быть отслеженным.

Однако, следует помнить, что не вся информация шифруется. У разных VPN-провайдеров могут отличаться такие характеристики как степень шифрования, сокрытие факта подключения к серверу, хранение логов (журнал, в который сохраняется информация о посещаемых сайтах, реальный IP адреси т.п.) и сотрудничество при выдаче информации третьим лицам.

Если VPN-провайдер вообще не записывает логи, то передавать третьим лицам просто нечего. А сокрытие факта подключения к серверу уже более редкая услуга. При некорректном подключении или резком разрыве соединения может произойти утечка части данных. Решить проблему поможет технология Multihop VPN, которая предполагает соединение с сайтом сразу через несколько серверов.

Рассмотрим популярные VPN:

PPTP Point-to-Point Tunneling Protocol

+ поддерживается всеми ОС

+ не требует много вычислительных мощностей

- плохая защищенность. Методы шифрования устарели, плохая архитектура, есть ошибки в реализации протокола от Microsoft. Нет шифрования по умолчанию, на взлом требуется менее суток.

Используется, когда защита данных не очень важна или когда нет других вариантов.

L2TP Layer 2 Tunneling Protocol

+ более эффективен для построения виртуальных сетей

- более требователен к вычислительным ресурсам

- не предполагает шифрования по умолчанию

Работает совместно с другими протоколами, чаще всего IPSec.

Используется интернет-провайдерами и корпоративными пользователями.

IPSec Internet Protocol Security группа протоколов и стандартов для безопасных соединений.

+ хорошая архитектура

+ надежность алгоритмов

- сложен в настройке (следовательно, снижение защиты, если настроить неправильно)

- требует много вычислительных ресурсов

+ этот недостаток компенсируется путем аппаратного ускорения алгоритма шифрования АЕС

Часто используется совместно с другими технологиями.

SSL Secure Sockets Layer & TLS Transport Layer Security группа методов, включающая в себя протоколы SSL и TLS и другие методы защиты.

+ беспрепятственно пропускаются большинством публичных сетей

- довольно низкая производительность

- сложность в настройке, необходимость установки дополнительного ПО

используется на веб-сайтах, URL которых начинается с https (там еще виден зеленый замочек)

некоторые реализации: OpenVPN, Microsoft SSTP.

+ OpenVPN имеет открытый код, реализован практически для всех платформ, считается очень надежным.

Заключение

VPN комплекс технологий, позволяющих создать логическую сеть поверх физической. Используется для обеспечения защиты трафика от перехвата злоумышленниками и безопасной деятельности в интернете. VPN открывает доступ к заблокированным ресурсам, так что многие готовы мириться с более низкой скоростью интернета и возможными логами программ. Хотя VPN использует довольно надежные алгоритмы шифрования, включение VPN-клиента на вашем ПК не гарантирует 100% сохранности конфиденциальной информации, поэтому следует внимательно отнестись к выбору VPN-провайдера.

Ссылки:

https://blog.themarfa.name/kak-rabotaiet-vpn-i-pochiemu-eto-luchshie-tor-ili-proxy/

https://help-wifi.com/poleznoe-i-interesnoe/chto-takoe-vpn-dlya-chego-on-nuzhen-i-kak-polzovatsya/

https://www.kaspersky.ru/blog/vpn-hardships/11622/

https://www.kaspersky.ru/blog/vpn-implementations/11156/

https://www.kaspersky.ru/blog/vpn-explained/10635/

https://ru.wikipedia.org/wiki/VPN

https://pcsecrets.ru/internet/dlya-chego-nuzhen-vpn-i-kak-on-rabotaet-plyusy-i-minusy.html

https://www.youtube.com/watch?v=VDJXSrS8TCc

Подробнее..

Ахтунг бесплатный антивирус от RU-CENTER (NIC.RU)

05.02.2021 10:09:34 | Автор: admin

Астрологи объявили очередной сезон развода на деньги клиентов RU-CENTER (nic.ru). Схема развода примитивна, неоднократно описана (в том числе здесь же на Хабре!), но может сработать при вашей невнимательности:


  • Менеджеры RU-CENTER, по известным лишь им критериям, решают что пора бы вас немного постричь, и добавляют в услуги "Профессиональный антивирус". Разумеется, совершенно бесплатно.
  • Если вы не догадаетесь за месяц ее отключить услуга продлится (вероятно, на год), и с вас спишут деньги за ее использование.
  • Чтобы усложнить процедуру отключения кнопкой из ЛК это сделать нельзя. Нужно писать письмо в поддержку.

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


И попадете на деньги.


В любом случае, рекомендуется прямо сегодня зайти в ЛК nic.ru и проверить состав подключенных услуг.

Подробнее..

Перевод Как я угнал национальный домен Демократической Республики Конго

25.02.2021 16:13:17 | Автор: admin
Примечание: проблема решена. Сейчас национальный домен .cd уже не делегирует полномочия скомпрометированному нейм-серверу

TL;DR Представьте, что может произойти, если национальный домен верхнего уровня (ccTLD) суверенного государства попадет в чужие руки. Однако я (@Almroot) купил доменное имя, которое указано для делегирования NS в национальном домене Демократической Республики Конго (.cd), и временно принял более 50% всего DNS-трафика для этой TLD. На моём месте мог оказаться злоумышленник, который использовал бы эту возможность для MITM или других злоупотреблений.



Вступление


За неделю до Рождества я решил провести анализ всех записей NS для всех TLD в мире. И моё внимание привлекло одно обстоятельство. У домена scpt-network.com был указан код статуса EPP redemptionPeriod. Это означает, что владелец не перечислил деньги за продление домена. Если владелец продолжит игнорировать оплату, то у него отберут собственность и домен поступит в свободную продажу.

Довольно проблематичная ситуация, поскольку он входит в список NS-серверов, управляющих зоной .cd:

almroot@x:~$ dig NS +trace cd | grep "cd."cd.172800INNSns-root-5.scpt-network.com.cd.172800INNSigubu.saix.net.cd.172800INNSsangoma.saix.net.cd.172800INNSns-root-2.scpt-network.com.cd.172800INNSsabela.saix.net.cd.172800INNSns-root-1.scpt-network.com.

Я решил на всякий случай написать bash-скрипт, который уведомит меня при любом изменении EPP-статуса.

К моему удивлению, примерно через неделю пришло уведомление, что домен перешёл в статус pendingDelete.

Я осознавал всю серьёзность ситуации. Доменное имя вскоре выставят на продажу для всех желающих, то есть любой человек может элементарно завладеть нейм-сервером .cd.

Я изменил скрипт и начал поминутно пинговать регистратора на предмет дальнейших изменений статуса.

Вечером 30 декабря пришло уведомление. Я открыл ноутбук и купил доменное имя, чтобы оно не попало в чужие руки.



Поскольку оставались ещё три записи делегирования на SAIX (South African Internet eXchange, Южноафриканская точка обмена трафиком), национальный домен сохранил работоспособность (хотя скорость резолвинга любых доменов немного уменьшилась).

Завладев scpt-network.com, я мог настроить любой поддомен на своё усмотрение. Например, если создать новый поддомен ns-root-1 с A-записью, которая указывает на IP-адрес 1.3.3.7, то на этот адрес 1.3.3.7 пойдут DNS-запросы для зоны .cd. Любой DNS-ответ на эти запросы будет принят как легитимный.



Если не ответить на запрос, то абонент словит таймаут с кодом состояния SERVFAIL. Это хорошо, потому что при получении такого кода он попытается связаться с любым другим сервером имён (NS record) для этой зоны. Так он в конечном итоге попадёт в одну из нормальных записей SAIX и будет соответствующим образом перенаправлен в нужное место назначения.

Потенциальное влияние


Захват национального домена верхнего уровня суверенного государства имеет серьёзные негативные последствия, особенно если этот домен попадёт в руки киберпреступников или иностранного противника. Демократическая Республика Конго (ДРК) немаленькая страна. Это примерно 90 миллионов человек, не говоря о многочисленных международных компаниях и организациях, работающих в этой доменной зоне.

Угон DNS-записи TLD целой страны явление редкое, но не новое. Например, десять лет назад киберпреступники захватили домен бывшего Советского Союза (.su), а в 2015 году вьетнамские сайты Lenovo и Google (.vn) также стали жертвами угона DNS. Перенаправление DNS-трафика с легальных сайтов .cd на фишинговый сайт одна из очевидных возможностей для злоупотреблений, но есть и другие:

  • Пассивный перехват DNS-трафика
    для слежки или эксфильтрации данных
  • Создание новых доменных имён из воздуха
    представьте себе возможности для быстрой генерации новых доменных имён с переключением ботнета на новые командные серверы каждые несколько минут, так что их никто не успевает заблокировать (техника fast flux)
  • Атаки с удалённым выполнением кода (RCE) в локальных сетях
    жертвами станут компании, которые используют протокол WPAD (протокол автоматической настройки прокси)
  • Поддельные DNS-ответы на законные DNS-запросы
    полный захват корневых доменов в зоне .cd или проведение DDoS-атаки.

Например, я мог написать эксплоит для захвата конкретного домена в зоне .cd. Представьте, что для любых NS-запросов к google.cd я всегда возвращаю ответы ns-root-1.scpt-network.com (вместо этих четырёх: [ns1,ns2,n3,ns4].google.com). Абонент получит такой ответ, и отправит любые последующие DNS-запросы к ns-root-1.scpt-network.com.

Это также заставило меня задуматься: а что, если отвечать на все NS-запросы ссылкой на себя. Тогда для любого запроса, на который ответит 1.3.3.7, все поиски домена в конечном итоге пойдут по этой ссылке. И весь последующий сетевой трафик будет перенаправлен на 1.3.3.7, что может привести к DDoS-атаке.

На самом деле это также повлияет на доступность всей TLD, ведь 50% DNS-ответов станут неправильными. Силу (обеих) DoS-атак можно увеличить путём установки высокого TTL в ответах DNS.

Сделаем ещё один шаг вперёд. Скажем, я конкретно подделываю TXT-записи для сервера google.cd. С помощью поддельных текстовых файлов я обманываю
систему проверки DNS-01 у регистратора Lets Encrypt и получаю действительный сертификат для google.cd, после чего эффективно взламываю зашифрованный канал SSL/TLS.

Поскольку я могу контролировать делегирование NS-серверов для любого домена .cd и получить валидные сертификаты, то могу провести MITM-атаку даже если жертва использует SSL/TLS.

Примечание переводчика. Некоторые описанные методы доступны государственным службам, которые контролируют национальные домены в своих странах.

В то время как Google применяет различные контрмеры против таких злоупотреблений, можно с уверенностью сказать, что это не относится ко всем корневым доменам в зоне .cd. Дополнительную информацию о том, как удостоверяющие центры проверяют право собственности на домены, см. в BR 1.7.3.

И последнее, но не менее важное: имея привилегированный доступ на вышестоящий хост с контролем DNS, я могу проникнуть в локальные сети компаний (пример на скриншоте ниже), которые отправляют DNS-запросы для WPAD можно отслеживать их запросы, подделать ответы и перенаправить жертву для загрузки и выполнения вредоносной конфигурации прокси-сервера на JS. У протокола WPAD своя куча проблем, включая уязвимости RCE, как рассказывали хакеры из команды Project Zero в Google.



Исправление проблемы


7 января 2021 года я связался с административными и техническими контактами, указанными для зоны .cd на странице IANA. Первоначально я хотел передать домен оператору .cd.

Хотя один из контактов ответил и направил меня к коллеге, на момент написания этой статьи я не получил письменного подтверждения, что они устранили проблему. Но вскоре DNS-трафик перенаправили на scpt-network.net.

8 января я также отправил отчёт по программе Internet Bug Bounty в HackerOne, которая предлагает вознаграждение за ответственный взлом инфраструктуры интернета.

Заключение


Угон DNS-сервера несёт крайне негативные последствия, особенно если у злоумышленника плохие намерения. Эта уязвимость затрагивает не только один сайт, поддомен или один корневой домен. Жертвой фишинга, MITM или DDoS может стать абсолютно любой сайт .cd, включая сайты крупных международных компаний, финансовых учреждений и других организаций. А это вторая по численности страна Африки и популярная доменная зона.

На момент написания этой статьи я всё ещё владею доменным именем scpt-network.com хотя делегирование NS-запросов из зоны .cd прекратились примерно 8 января 2021 года после того, как я с ними связался. Эту операцию я провёл для того, чтобы предотвратить захват злоумышленниками доменной зоны Демократической Республики Конго, когда любой желающий мог угнать доменное имя одного из серверов, управляющих ccTLD. К счастью, в этом случае всё обошлось.
Подробнее..

Перевод Угон домена Perl.com

05.03.2021 10:06:07 | Автор: admin

Прим. перев.: в конце января стало известно о том, что один из основных доменов языка программирования Perl Perl.com был угнан. Это вызвало смешанную реакцию в сообществе как любителей языка, так и его противников. Теперь, когда всё уже позади и справедливость восстановлена, один из самых известных сторонников Perl brian d foy рассказал о том, что же произошло и как сообщество добилось положительного исхода событий. Представляем вниманию перевод его заметки.

На неделю мы потеряли контроль над доменом Perl.com. Теперь, когда проблема устранена, можно подробно рассказать о том, что произошло и как мы с этим справились. Инцидент затронул только домен Perl.com, никакие другие ресурсы сообщества не пострадали. Сам сайт никуда не делся, но DNS выдавал другие IP-адреса.

Во-первых, следует отметить, что проблема не связана с продлением домена. Для нас подобная забывчивость была бы даже лучше, поскольку есть так называемый grace period (в течение месяца после expiration его владелец все еще может продлить прим. перев.).

Во-вторых, хочу подчеркнуть, что я всего лишь редактор сайта, который использует домен Perl.com. То есть юридически меня нельзя назвать пострадавшей стороной. Владельцем домена является Tom Christiansen, и если делу будет дан ход, мне или кому-либо другому вовсе не обязательно знать все подробности. Однако я общался со многими людьми, вовлеченными в процесс.

Реакция на инцидент

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

Ранним утром 27 января Perl NOC (Network Operations Center) в рамках повседневного мониторинга заметил, что с доменом происходит нечто странное. Параллельно пользователи начали жаловаться, что сайт недоступен. По мере обновления записей DNS по всему миру все большее число пользователей сообщали о проблемах. Мы понятия не имели, что происходит и почему.

Я начал негласно собирать информацию об инциденте и написал твит с просьбой о помощи. В тот момент мы не представляли, что именно происходит, а просто наблюдали за последствиями. На ранних стадиях реагирования важно отфильтровать слухи от достоверной информации, и отделить тех, кто что-то знает, от тех, кто просто распространяет слухи. Как обычно, именно пустословы доминируют на информационном поле: ведь их история обычно гораздо более интересная, ведь они могут выдумать все, что угодно, и манипулировать фактами. Поэтому главная задача работать с информацией, а не со спекуляциями, то есть разобраться, что действительно известно, а что лишь догадки.

Я завел Google-документ и пригласил нужных людей. Мы начали заполнять детали, классифицируя их с помощью цвета: зеленого, янтарного, красного. Зеленым помечалась информация, которую мы считали достоверной например, прямое взаимодействие с регистратором; янтарный обозначал непроверенную информацию, которая могла быть правдивой, а красным маркировались недостоверные сведения. Вся информация сопровождалась временем и источником. Первое правило борьбы со слухами запоминать, от кого и когда вы их услышали. Когда это все сведено в документ, любой имеет возможность сравнить имеющуюся у него информацию с общедоступной и понять, является ли она более ценной и актуальной. Иногда информация, которая считалась правдивой, оказывалась недостоверной. Тогда мы вносили изменения в документ.

Также был составлен список дел, и все, кто мог, занялись ими. Например, мы начали проверять другие ресурсы сообщества. Elaine Ashton проверила регистрацию cpan.org (там была странность в контактной информации, но после телефонного разговора с регистратором все оказалось в порядке). Robert Spier, участник Perl NOC, проверил различные сетевые аспекты, хронологию и т.п. Rik Signes вызвался завести закрытый список рассылки на TopicBox (в конце концов, он же CTO). Тонкость здесь в том, чтобы не делать работу, которую может сделать кто-то другой (и часто лучше). Аналогичным образом, если кто-то уже что-то делает, не стоит тратить свое время впустую, переделывая за ним или заново "изобретая велосипед". Децентрализация это классно, но ей необходим координатор. В этом случае координатором стал я, поскольку очень многое вложил в сайт Perl.com. Кроме того, я отлично сработался с Томом, ведь до этого мы целый год трудились над книгой Programming Perl.

Мой твит и комментарии в Reddit привлекли внимание обеих сторон в "регистрационном уравнении", так что на самом старте процесса я смог переговорить как с Network Solutions, так и с Key Systems. Нам очень повезло, что Perl штука довольно известная, а мы с Tom Christiansen, в свою очередь, занимаем не последнее место в сообществе Perl. Первое правило успеха уже быть успешным. Сотрудники различных вовлеченных в процесс организаций предлагали нам свою помощь и давали советы. Увы, другим жертвам повезло меньше, и помощи они не дождались. Все эти организации, вероятно, на определенных этапах своего существования использовали Perl, и с теплотой вспоминали старые добрые времена.

Я в основном отвечал за связь с Томом и помогал ему управляться со всеми игроками. В таких случаях огромный объем работы частенько подавляет людей, и у тех попросту опускаются руки. Тому надо было сосредоточиться на взаимодействии с регистраторами, так что я взял на себя максимум остальной работы, чтобы не отвлекать его.

Почти сразу стало понятно, что когда используешь проблемный домен в качестве своего email-контакта, никто не сможет с тобой связаться в случае трудностей с этим доменом. Больше всего сил мы потратили на подтверждение того, что наши контрагенты это действительно те, за кого они себя выдают. Впрочем, в доменном бизнесе все эти фигуры хорошо известны: ведь они занимаются этим давно и постоянно. Мы позаботились о том, чтобы не перегружать их обращениями от коллег, задающих один и тот же вопрос. Координация контактов помогает избежать избыточности коммуникаций и позволяет ответственным лицам делать свою работу, а не комментировать без конца одни и те же вопросы.

Как только все стороны обменялись актуальной контактной информацией, процесс пошел как по маслу. Мы не были уверены, что все получится, но по мере развития ситуации наша убежденность крепла. Впрочем, уверенность это субъективная информация. Какой смысл говорить о том, что, по вашему мнению, может или должно произойти, если в процесс постоянно вмешиваются всевозможные задержки и заминки?

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

Поэтому мы решили публиковать всю актуальную информацию в одном месте в блоге The Perl NOC. Иногда между получением информации и ее публикацией проходило несколько часов мы внимательно проверяли все сведения. Пользователям не было необходимости рыскать по социальным сетям и т.п. в поисках новостей, поскольку все они были собраны в одном месте. Мы по-прежнему транслировали обновления на всех доступных ресурсах, при этом ссылаясь на первоисточник блог NOC. Единый источник информации очень помогает.

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

Также отслеживались люди и публикации. Кто и какую позицию занимает в той или иной компании, какие журналисты пишут об инциденте, что пишут на форумах. Некоторые участники форумов зависали на них исключительно ради забавы (и это было очевидно), другие публиковали ценные и действенные подробности (то есть были знакомы с ситуацией изнутри). Опять же, для классификации использовалась комбинация зеленый / янтарный / красный.

Это не первое мое "родео", и я взял на себя роль пресс-секретаря. Несмотря на кропотливую работу по проверке всего и вся, многие люди со стороны просто выдумывали всякую ерунду. Что ж, бывает и такое (что вполне предсказуемо). Издательский принцип "Если мать говорит, что любит тебя, найди второй источник" не применим в эпоху Twitter. Часто не нужен даже первый источник.

Важно, чтобы сообщество представлял один человек. Авторы доброй половины "новостных" публикаций не потрудились провести базовые исследования, а у некоторых из них отсутствовала контактная информация (серьезно? Журналист, с которым нельзя связаться?). Некоторые авторы исправили свои материалы, поговорив со мной.

The Register с самого начала выдавал точную информацию, как и Paul Ducklin на сайте Sophos.

Примерно через неделю после изменений на серверах имен, я пришел к заключению, что возврат домена после взлома может растянуться на несколько недель. Поскольку в него были вовлечены разные страны со своими законами и правилами, процесс продвигался гораздо медленнее, чем нам хотелось. В эпоху Интернета "завтра" равносильно "вечности". David Farrell выдвинул идею о переименовании сайта, и мы стали использовать perldotcom.perl.org в качестве временного домена. Robert смог все быстро настроить, и мы классно провели время, анализируя pull request'ы от сообщества. В них пользователи указывали на некоторые моменты, которые мы за'hardcode'или, хотя не должны были (любой человек может предложить PR по любому поводу, имеющему отношение к сайту!). Основой для всей этой работы выступал процесс на базе GitHub, который разработал David (нам приятно получать даже самые незначительные PR от сообщества!).

Затем, в начале февраля, обходными путями я получил надежную (зеленую) информацию о том, что домен вернется к нам через пару дней. Я сперва не поверил, но это действительно произошло! Опять же, нам очень повезло: люди, в сердцах которых Perl занимает особое место, сильно нам помогли. Все стороны понимали, что Perl.com принадлежит Тому, и воплотить это понимание в жизнь было несложно. Владельцам менее известного доменного имени было бы гораздо труднее доказать свои права на него.

Впрочем, с возвращением домена история не закончилась. Пока домен был скомпрометирован, различные продукты в сфере безопасности внесли Perl.com в черный список, а некоторые DNS-серверы занесли его в sinkhole. Мы решили, что постепенно все придет в норму, и отложили празднование возвращения Perl.com до более подходящих времен. Хотелось, чтобы он стал доступен для всех. И, наконец, этот знаменательный момент наступил! Если у кого-то проблемы с Perl.com, пожалуйста, заведите issue, чтобы мы знали, что для некоторой части интернета домен не работает.

Что, по нашему мнению, произошло

В этой части мы поделимся некоторыми догадками (кстати, Perl.com оказался не единственной жертвой). По всей видимости, имела место атака социальной инженерии на Network Solutions, включающая подделку документов и т.п. У Network Solutions нет причин раскрывать мне какие-либо подробности (опять же, я не являюсь потерпевшей стороной), но я поговорил с другим владельцами доменов, и те рассказали мне о наиболее вероятной схеме.

John Berryhill опубликовал в Twitter результаты своего расследования, которое показало, что взлом на самом деле произошел в сентябре. В декабре домен был передан регистратору BizCN, но серверы имен остались прежними. В январе домен вновь был передан другому регистратору Key Systems, GmbH. Подобная задержка помешала выявлению проблемы на ранних этапах, а передача домена от одного регистратора другому значительно осложнила его восстановление.

Обратите внимание на длительную задержку до момента первой передачи. Домен взломан в сентябре, а передача произошла в декабре. Для этого имеется веская причина: 60-дневное правило ICANN. Домен нельзя передать в течение 60 дней после обновления контактной информации. Мы думаем, что регистрация была изменена злоумышленниками одновременно с продлением домена на несколько лет (первоначально домен истекал в 2029 году).

После передачи домена Key Systems в конце января, новый владелец-мошенник выставил его (и другие домены) на продажу на Afternic (рынок доменов). Perl.com можно было купить за 190 тыс. долларов. После запросов The Register домен был снят с продажи.

Некоторые уроки

Очевидно, ситуация неприятная, но ее нельзя назвать уникальной. Домен был зарегистрирован в начале 1990-х, вскоре после этого Tom Christiansen получил над ним контроль, и с тех пор продолжал платить сборы за продление. Как обычно бывает, ничего не менялось "пока гром не грянул". Механизмы вроде двухфакторной авторизации, пожалуй, избавили бы нас от большей части проблем (хотя атаки социальной инженерии умудряются обходить защитные меры).

Я уже упоминал об ошибке, когда для контактов по домену используется сам домен. В результате при возникновении проблемы связаться с владельцем домена невозможно. Поэтому всегда указывайте запасной контакт, не привязанный к домену.

Очень важно вести переговоры с одним и тем же человеком, иначе вы рискуете посеять путаницу из-за многообразия сообщений, даже если в них говорится одно и то же. Также необходимо демонстрировать уверенность и компетентность, чтобы озвучиваемая вами информация воспринималась как достоверная; если разные каналы озвучивают разные послания, риск ошибок возрастает. Perl Foundation настоял на публикации собственного заявления вместо подготовленного нами. Хотя оно было крайне лаконичным, ссылка на блог Perl NOC не работала несколько дней. Не рискуйте понапрасну.

Кроме того, всегда хорошо иметь друзей и поддерживать добрые отношения с людьми, способными помочь. Сотрудники Network Solutions и Key Systems очень помогли нам с восстановлением, как и другие специалисты, поддерживающие работу интернета. Я хотел бы назвать их имена, но уверен, что они предпочтут не афишировать себя и просто делать свою работу.

Текущее состояние дел

Домен Perl.com был благополучно возвращен Tom Christiansen. Ведутся работы над различными мерами, способными предотвратить повторение подобной ситуации. Сайт вернулся к нормальной жизни и стал чуть ярче благодаря всей той помощи, которую мы получили.

В рамках реагирования на инцидент The Perl Foundation Infrastructure Working Group изучила другие важные домены сообщества. Будет проведена соответствующая работа по их защите. Желающие помочь могут связаться с ними.

P.S. от переводчика

Читайте также в нашем блоге:

Подробнее..

Перевод Битсквоттинг сайта Windows.com

05.03.2021 12:10:54 | Автор: admin


Недавно я вернулся к мысли о возможности совершения битсквоттинга. В статье по ссылке эта тема рассматривается очень глубоко, поэтому здесь я объясню в очень общих чертах:

Когда вы пытаетесь получить доступ к сайту по его домену, этот домен хранится в памяти вашего компьютера, устройства и т.д. в структуре, выглядящей примерно так:

01110111 01101001 01101110 01100100 01101111 01110111 01110011
w i n d o w s

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

01110111 01101000 01101110 01100100 01101111 01110111 01110011
w h n d o w s

О нет! Теперь в памяти хранится значение whndows.com, а не windows.com! Что же произойдёт, когда придёт время создания подключения к этому домену?

nslookup whndows.com

*** cant find whndows.com: Non-existent domain

Домен не резолвится в IP-адрес!
Оказалось, что из 32 возможных доменных имён, находящихся в одной замене бита от windows.com, 14 имён были доступны для покупки! Это довольно редкий случай обычно такие имена покупаются компаниями, например, Microsoft, чтобы предотвратить их использование в целях фишинга. Итак, я их купил. Все. Примерно за 126 долларов.

(Если вы являетесь верифицируемо ответственным лицом, то я с радостью передам вам владение этими доменами. В противном случае я придержу их и продолжу сливать деньги.)

windnws.com
windo7s.com
windkws.com
windmws.com
winlows.com
windgws.com
wildows.com
wintows.com
wijdows.com
wiodows.com
wifdows.com
whndows.com
wkndows.com
wmndows.com

Теперь нам нужно, чтобы эти домены на что-то указывали. Я арендовал VPS, сконфигурировал IPv4/IPv6 и создал подстановочные DNS-записи, чтобы указывать на них.

Подстановочные DNS работают следующим образом: я создаю запись, сообщающую, что whndows.com указывает на 123.123.123.123, и когда кто-нибудь запрашивает abs.xyz.whndows.com, он получит в качестве ответа ту же DNS-запись 123.123.123.123. Поскольку в этом исследовании мы имеем дело с инвертированием битов, это позволяет мне перехватывать любые DNS lookup поддомена windows.com, в которых инвертировано несколько битов.

Настроив DNS, мы используем tshark для выполнения перехвата пакетов через публичный интерфейс нашего VPS и подождём, пока не произойдёт что-нибудь интересное.

Ниже приведена краткая выжимка интересных вещей, которой можно поделиться без возможности идентификации пользователей.

Чтобы отличить оппортунистическое сканирование от ситуации инвертирования битов, я использовал GreyNoise.io. Это отличный продукт!

NTP UDP port 123 time.windows.com


UDP-пакеты, предназначенные для порта 123, пытаются задать время на часах компьютера с помощью Network Time Protocol (NTP).

time.windows.com это стандартный NTP-сервер, настроенный для всех машин под Windows и они регулярно сверяют по нему время. Если им не удаётся получить время, то они пробуют снова, и снова, и снова.

В сумме, на протяжении 14 дней мой сервер получил 199 180 подключений NTP-клиентов с 626 уникальных IP-адресов.

NTP-клиент для ОС Windows не имеет внутренней верификации аутентичности, поэтому злоумышленнику ничего не стоит сообщить всем этим компьютерам, что сейчас время после 03:14:07 вторника 19 января 2038 года и посеять хаос, поскольку для переполнения значения времени в памяти хранится знаковое 32-битное число.

Однако, как оказалось, примерно у 30% этих компьютеров подобные действия ничего не изменят для их пользователей, потому что их часы уже и так сломаны.

С помощью фильтра tshark ntp.xmt мы можем извлечь Transmit Timestamp, то есть текущее по мнению компьютера время на момент обновления времени.

tshark -r capture.pcap -T fields -e ntp.xmt -2 -R ntp.xmt | sort -u

Sep 28, 1984 19:41:12.638290998 EDT
Sep 28, 2012 11:59:42.976403314 EDT
Sep 28, 2029 21:50:47.552079831 EDT
Sep 28, 2100 18:13:09.180229791 EST
Sep 29, 1975 08:36:52.200231052 EDT
Sep 29, 1980 23:44:14.142299217 EDT
Sep 29, 2036 11:54:11.410350275 EDT
Sep 29, 2038 06:18:34.082394858 EDT
Sep 29, 2046 16:00:00.102963544 EST
Sep 29, 2050 06:39:18.880921186 EST
Sep 29, 2074 07:31:58.701524704 EST
Sep 30, 1999 00:29:32.120677896 EDT
Sep 30, 2009 02:54:33.318870579 EDT
Sep 30, 2049 00:14:59.396552253 EST
Sep 30, 2075 13:56:14.492526678 EST
Sep 30, 2081 01:56:58.477295064 EST

HTTP TCP port 80 sg2p.w.s.windows.com


Для настоящего домена sg2p.w.s.windows.com отсутствуют активные DNS-записи.

Однако, судя по User-Agent и времени запросов, можно понять, что эта активность напрямую связана с тем же приложением, которое сгенерировало показанный ниже трафик для client.wns.windows.com и skydrive.wns.windows.com

GET / HTTP/1.1
Host: sg2p.w.s.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 client.wns.windows.com


Похоже, они напрямую связаны с сервисами Windows Push Notification Services (WNS), позволяющими сторонним разработчикам отправлять toast-, tile-, badge- и raw-обновления с собственного облачного сервиса. DNS-запись это CNAME для wns.notify.trafficmanager.net.

DNS-записи:

client.wns.windows.com. IN CNAME wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN A 52.177.166.224

HTTP-запрос:

GET / HTTP/1.1
Host: client.wns.wkndows.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 skydrive.wns.windows.com


Словом Skydrive до смены имени назывался OneDrive.

DNS-записи:

skydrive.wns.windows.com. IN CNAME client.wns.windows.com.
client.wns.windows.com. IN CNAME wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN A 52.179.224.121

HTTP-запрос:

GET / HTTP/1.1
Host: skydrive.wns.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 time.windows.com


Понятия не имею, откуда пришёл этот запрос и почему HTTP запрашивается с сервера, который должен быть NTP-сервером. WHOIS по IP, сделавшему этот запрос, показан ниже:

inetnum: 123.112.0.0 123.127.255.255
netname: UNICOM-BJ
descr: China Unicom Beijing province network
descr: China Unicom
country: CN
admin-c: CH1302-AP
tech-c: SY21-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CNCGROUP-BJ
mnt-routes: MAINT-CNCGROUP-RR
mnt-irt: IRT-CU-CN

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

Вскоре после этого запроса произошла ещё более странная ситуация! Baidu это один из крупнейших китайских поисковых движков. Не забывайте, что я сконфигурировал свои DNS-сервера для резолвинга в режиме подстановки. Существует очень малое количество способов, которыми Baiduspider мог бы узнать о существовании time.wiodows.com. Особенно учитывая, что ранее к этому домену был выполнен только один запрос (показанный выше).

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

HTTP tcp port 80 windows.com/stopcode


При возникновении синего экрана смерти в Windows пользователю предлагается посетить https://www.windows.com/stopcode. Естественно, если компьютер завис, он не может просто открыть ссылку. Большинство людей, скорее всего, просто отсканировали бы QR-код, но те, кто ввёл адрес с опечаткой, оказались здесь.


GET /stopcode HTTP/1.1
Host: wildows.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 5.0.1; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.111 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Особенно любопытен следующий запрос. Из-за характера запроса я укажу некоторые подробности обобщённо или полностью отцензурирую, потому что не совсем понятно, что происходит.

IP из диапазона 113.96.0.0 113.111.255.255 (CHINANET-GD) делает запрос с телефона под Android.

GET /topode HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 7.1.2; M6 Note Build/N2G47H; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/77.0.3865.120 MQQBrowser/6.2 TBS/045223 Mobile Safari/537.36 MMWEBID/9551 MicroMessenger/7.0.14.1660(0x27000E37) Process/tools NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 wechatdevtools
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Host: wintows.com
Via: 1.1 TENCENT64.site (squid/3.5.20)
X-Forwarded-For: <Department of Defence IP>
Cache-Control: max-age=259200
Connection: keep-alive

Похоже, какой-то пользователь из Китая использует squid для инъецирования HTTP-заголовков в каждый запрос, исходящий из его сети, в том числе и со своего мобильного телефона. На его компьютере возникает синий экран смерти, поэтому пользователь пытается поискать код STOP-ошибки на windows.com/stopcode с телефона. Он вводит URL с ошибкой и оказывается на моём сервере, где я вижу, что он инъецирует HTTP-заголовок для X-Forwarded-For, пытающийся представить запрос так, как будто он отправлен с IP, принадлежащего Министерству обороны США.

Когда я поискал исходный IP на GreyNoise, то узнал следующее: Этот IP-адрес оппортунистически сканировал Интернет и совершил полное TCP-соединение. Спуфинг зафиксированной активности невозможен. GreyNoise определил, что этот IP-адрес сканирует Интернет через следующие порты: 443 / TCP.

Наблюдая за тем, что мой трафик получается по 80 / TCP, могу предположить, что это не предусматривалось.

HTTP TCP port 80 windows.com/?fbclid


Как и можно было ожидать, кто-то в Facebook обязательно должен был опечататься в адресе windows.com, из-за чего создалась ссылка с уникальным токеном ?fbclid=xyz. Краулер Facebook пытается запросить адрес, то же самое делает и Bing, если он на другом языке, после чего пытается перевести его.

GET /?fbclid=IwAR28VIBcDUlzO4XQOk9R-EWYLsnjUf-SrrKKZyAdOvrV2Mtv5JoJVO3PSUQ HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Host: wintows.com
Connection: keep-alive

Подведём итог


Нас не должно удивлять, что сервис NTP, работающий на всех машинах c Windows в мире, использующий в стандартной конфигурации time.windows.com, генерировал больше всего трафика, вызванного инвертированием битов. Я по-прежнему получаю кучу трафика. Больше всего меня удивило то, сколько трафика я получал от доменов, ошибочно указанных пользователями при вводе URL.

Выводы:

  • Битсквоттинг домена с большими объёмами трафика по-прежнему очень практичная в реализации атака.
  • Интегрированные в ОС автоматизированные сервисы создают много битсквоттингового трафика.
  • Пользователи по-прежнему часто делают опечатки в именах доменов.




На правах рекламы


VDSina предлагает VDS с посуточной оплатой. Возможно установить любую операционную систему, в том числе из своего образа. Каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Подробнее..

Перевод Путаница зависимостей. Как я взломал Apple, Microsoft и десятки других компаний

02.04.2021 20:22:21 | Автор: admin

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

pip install package_name

В некоторых языках программирования, таких как Python, это простой, более или менее официальный способ установки зависимостей для ваших проектов. Такие установщики обычно привязаны к публичным репозиториям кода, куда каждый может свободно загружать пакеты кода для использования другими пользователями.

Вы, наверное, уже слышали о таких инструментах у Node есть менеджер npm и реестр npm, система управления пакетами pip языка Python использует PyPI (Python Package Index), а систему gems для языка Ruby можно найти на сайте RubyGems.

Загрузив и установив пакет из любого из этих источников, вы, по сути, доверяете его издателю, запуская соответствующий код на своём компьютере. Так может ли эта слепая вера быть использована злоумышленниками?


Конечно, может.

Ни одна из служб размещения пакетов не может гарантировать, что весь код, загружаемый её пользователями, не содержит вредоносных программ. Прошлое исследование показало, что typosquatting атака с использованием версий имён популярных пакетов с опечатками может быть невероятно эффективной при получении доступа к случайным компьютерам по всему миру.

Другие хорошо известные пути атаки цепочек зависимостей включают использование различных методов компрометации существующих пакетов или загрузку вредоносного кода под именами зависимостей, которых больше не существует.

Идея

Пытаясь взломать PayPal вместе со мной летом 2020 года, Джастин Гарднер поделился интересным фрагментом исходного кода Node.js, найденного в GitHub.

Код предназначался для внутреннего использования в PayPal, и в его файле package.json, по-видимому, содержалась смесь публичных и частных зависимостей публичные пакеты от npm, а также имена непубличных пакетов, скорее всего, размещённых внутри PayPal. В то время этих имён не было в публичном реестре npm.

С логикой, диктующей, какой пакет должен быть получен из неясного здесь источника, возникло несколько вопросов:

  • Что произойдёт при загрузке в npm вредоносного кода с этими именами? Возможно ли, что некоторые внутренние проекты PayPal начнут по умолчанию переходить на новые публичные пакеты вместо частных?

  • Начнут ли разработчики или даже автоматизированные системы выполнять код внутри библиотек?

  • Если это сработает, сможем ли мы получить за это вознаграждение?

  • Сработает ли такая атака и против других компаний?

Без лишних церемоний я стал разрабатывать план, чтобы ответить на эти вопросы.

Идея заключалась в загрузке собственных вредоносных пакетов Node в реестр npm под всеми невостребованными именами, которые будут звонить домой с каждого компьютера, на котором они были установлены. Если какой-либо из пакетов в итоге устанавливается на серверах, принадлежащих PayPal, или в любом другом месте, то содержащийся в них код немедленно уведомляет меня.

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

Это всегда DNS

К счастью, npm позволяет при установке пакета автоматически выполнять произвольный код, что облегчает создание пакета Node, который собирает некоторую базовую информацию о каждом компьютере, на котором он установлен, с помощью своего сценария preinstall.

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

Остался только вопрос: как мне вернуть эти данные?

Зная, что большинство возможных целей находится глубоко внутри хорошо защищённых корпоративных сетей, я решил, что кража данных DNS это правильный путь.

Отправка информации моему серверу по протоколу DNS не была важна для работы самого теста, но она указывала на меньшую вероятность блокировки трафика и его обнаружения на выходе.Данные в шестнадцатеричной кодировке использовались как часть DNS-запроса, который достигал моего собственного полномочного сервера доменных имён напрямую или через промежуточные сопоставители. Сервер был настроен для регистрации каждого полученного запроса, по сути, сохраняя запись каждого компьютера, в который были загружены пакеты.

Чем больше, тем лучше

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

Первая стратегия заключалась в поиске альтернативных экосистем для атаки. Поэтому я перенёс код как на Python, так и на Ruby, чтобы можно было загружать аналогичные пакеты в PyPI (Python Package Index) и RubyGems соответственно.

Однако, возможно, самой важной частью этого теста был поиск максимально возможного количества значимых имён зависимостей.

Несколько полных дней поиска имён частных пакетов, принадлежащих некоторым целевым компаниям, показали, что многие другие имена можно найти в GitHub, а также в основных службах размещения пакетов во внутренних пакетах, которые были случайно опубликованы, и даже в сообщениях на различных интернет-форумах.

Однако, оказалось, что лучше всего искать имена частных пакетов... в файлах JavaScript.

Видимо, довольно часто внутренние файлы package.json с именами зависимостей проектов JavaScript, встраиваются в общедоступные файлы сценариев во время их сборки, раскрывая имена внутренних пакетов. Точно так же получаемые по каналам утечки внутренние пути или вызовы require() в таких файлах также могут содержать имена зависимостей. Apple, Yelp и Tesla это лишь несколько примеров компаний, у которых внутренние имена были раскрыты таким образом.

Во второй половине 2020 года, благодаря помощи пользователя @streaak и его замечательным навыкам реконструкции, мы смогли автоматически просканировать миллионы доменов, принадлежащих целевым компаниям, и извлечь сотни дополнительных имён пакетов JavaScript, которые ещё не были заявлены в реестре npm.Затем я загрузил свой код в службу размещения пакетов под всеми найденными именами и стал ждать обратных вызовов.

Результаты

Успех был просто поразительным.

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

На тот момент уязвимость этого типа, которую я начал называть путаницей зависимостей, была обнаружен более чем в 35 организациях, во всех трёх тестируемых языках программирования. У подавляющего большинства затронутых компаний больше 1000 сотрудников, что, скорее всего, отражает более высокую распространённость внутреннего использования библиотек в более крупных организациях.

Поскольку имена зависимостей JavaScript легче найти, почти 75% всех зарегистрированных обратных вызовов исходили из пакетов npm, но это не обязательно означает, что Python и Ruby менее восприимчивы к такой атаке. На самом деле, несмотря на то что во время моих поисков мне удалось идентифицировать лишь внутренние имена gem для Ruby, принадлежащие восьми организациям, четыре из этих компаний оказались уязвимыми для путаницы зависимостей посредством RubyGems.

Одна такая компания канадский гигант электронной коммерции Giant Shopify, система сборки которой автоматически устанавливала пакет gem для Ruby с именем shopify-cloud всего лишь через несколько часов после того, как я его загрузил, а затем попытался выполнить код внутри него. Специалисты Shopify подготовили исправление в течение дня, а за обнаружение ошибки была присуждена награда в размере 30000 долларов.

Ещё одна награда в размере 30000 долларов была получена от Apple после того, как код в пакете Node, который я загрузил в npm в августе 2020 года, был выполнен на нескольких компьютерах внутри сети этой компании. Затронутые проекты оказались связаны с системой аутентификации Apple, известной за пределами компании как Apple ID.

Когда я подал идею о том, что эта ошибка, возможно, позволяла злоумышленникам внедрять бэкдоры в Apple ID, в компании Apple не посчитали, что этот уровень воздействия точно отражает проблему, и заявили:

Реализация бэкдора в оперативной службе требует более сложной последовательности событий, и это очень специфический термин, который несёт в себе дополнительные коннотации.

Однако в компании Apple подтвердили возможность удалённого выполнения кода на серверах Apple с помощью этой технологии пакетов npm. Судя по потоку установок пакетов, проблема была исправлена в течение двух недель после моего отчёта, но премия за обнаружение ошибки была присуждена менее чем за день до этой публикации.

Такое же использование пакетов npm, устанавливаемых как на внутренние серверы, так и на ПК отдельных разработчиков, наблюдалось и в нескольких других успешных атаках на другие компании, причём некоторые установки часто выполнялись через часы или даже минуты после загрузки пакетов.

О, а имена PayPal, с которых всё началось? Они тоже сработали, что привело к ещё одной награде в размере 30 000 долларов. Фактически размер большинства присужденных премий за обнаружение ошибки был максимально разрешённым в рамках политики каждой программы, а иногда и превышал максимум, подтверждая в целом высокую серьезность уязвимости путаница зависимостей.

К затронутым компаниям также относятся Netflix, Yelp и Uber.

Это не баг, это фича

Несмотря на получение большого количества результатов по уязвимости путаница зависимости, одна деталь была и в определённой степени остаётся до сих пор неясной: почему это происходит? Каковы основные первопричины уязвимости такого рода?

Большинство затронутых организаций неохотно делились дальнейшими техническими подробностями о своих первопричинах и стратегиях смягчения последствий, но несколько интересных деталей всё же появилось во время моих исследований и общения со специалистами по безопасности.

Например, главный виновник путаницы зависимостей в Python, это, по-видимому, неправильное использование небезопасного по своей конструкции аргумента командной строки --extra-index-url. Если, используя этот аргумент с командой pip install library, указать собственный индекс пакета, можно обнаружить, что он работает ожидаемым образом, но то, что pip на самом деле делает за кулисами, выглядит примерно так:

  • проверяет существование library в указанном (внутреннем) индексе пакетов;

  • проверяет существование library в публичном индексе пакетов (PyPI);

  • устанавливает любую найденную версию. Если пакет существует в обоих индексах, то по умолчанию он устанавливается из источника с более высоким номером версии.

Поэтому загрузка пакета с именем library 9000.0.0 в PyPI приведёт к захвату зависимости в приведённом выше примере.

Хотя такое поведение уже было широко известно, простого поиска в GitHub выражения --extra-index-url было достаточно, чтобы найти несколько уязвимых сценариев, принадлежащих крупным организациям, включая ошибку, влияющую на компонент Microsoft .NET Core. Данная уязвимость, которая, возможно, позволила бы добавлять бэкдоры в .NET Core, к сожалению, была обнаружена вне рамок программы вознаграждения за нахождение ошибок в .NET.

В Ruby команда gem install --source работает аналогичным образом, но мне не удалось подтвердить, было ли её использование основной причиной каких-либо моих находок.

Конечно, замена --extra-index-url на --index-url быстро и прямо исправляет уязвимость, но снизить риск некоторых других вариантов уязвимости путаница зависимостей оказалось гораздо труднее.

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

В JFrog, как сообщается, знают об этой проблеме, но рассматривает её возможное исправление как запрос функции без расчётного времени его реализации, в то время как некоторые клиенты компании прибегли к изменению системной политики управления зависимостями, чтобы уменьшить риск путаницы зависимостей.

Компания Microsoft также предлагает аналогичную службу размещения пакетов под названием Azure Artifacts. По результатам одного из моих отчётов в эту службу были внесены некоторые незначительные улучшения, чтобы она могла гарантированно предоставить надёжный путь обхода уязвимостей путаница зависимостей. Как ни странно, эта проблема была обнаружена не в результате тестирования самой службы Azure Artifacts, а, скорее, путём успешной атаки на облачную систему Microsoft Office 365, в результате чего за этот отчёт была получена самая высокая награда Azure в размере 40 000 долларов.

Более подробную информацию о первопричинах и рекомендациях по профилактике можно найти в техническом документе Microsoft 3 Ways to Mitigate Risk When Using Private Package Feeds (Три способа снижения риска при использовании каналов частных пакетов).

Будущие исследования?

Хотя многие крупные технологические компании уже осведомлены об уязвимости этого типа и либо исправили её в своей инфраструктуре, либо работают над внедрением мер по смягчению последствий, у меня сохраняется ощущение, что есть ещё что-то, что нужно обнаружить.

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

Тем не менее я искренне призываю вас, независимо от вашего уровня опыта, потратить некоторое время и проработать эту идею в глубине своего сознания, независимо от того, связана она с безопасностью управления зависимостями или нет.

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Как хакеры подменяют DNS-запросы с помощью отравления кэша

30.04.2021 20:15:00 | Автор: admin


Подмена сервера доменных имен (DNS) это кибератака, с помощью которой злоумышленник направляет трафик жертвы на вредоносный сайт (вместо легитимного IP-адреса). Злоумышленники используют метод отравления кэша DNS для перехвата интернет-трафика и кражи учетных данных или конфиденциальной информации. Отравление кэша DNS и подмена DNS тождественные понятия, часто используемые как синонимы. Хакер хочет обманом заставить пользователей ввести личные данные на небезопасном сайте. Как ему этого добиться? С помощью отравления кэша DNS. Для этого хакер подменяет или заменяет данные DNS для определенного сайта, а затем перенаправляет жертву на сервер злоумышленника вместо легитимного сервера. Таким образом хакер добивается своей цели, ведь перед ним открываются широкие возможности: он может совершить фишинговую атаку, украсть данные или даже внедрить в систему жертвы вредоносную программу.


Что такое подмена DNS и отравление кэша?




Прежде чем начать разговор об отравлении кэша DNS, сначала давайте вспомним, что такое DNS и кэширование DNS. DNS это всемирный каталог IP-адресов и доменных имен. Можно сказать, что это своеобразный телефонный справочник интернета. DNS переводит удобные для пользователей адреса, такие как varonis.com, в IP-адреса, например 92.168.1.169, которые используются компьютерами для работы в сети. Кэширование DNS это система хранения адресов на DNS-серверах по всему миру. Для ускорения обработки ваших DNS-запросов разработчики создали распределенную систему DNS. Каждый сервер хранит список известных ему DNS-записей, который называется кэшем. Если на ближайшем к вам DNS-сервере нужный IP-адрес отсутствует, он запрашивает вышестоящие DNS-серверы до тех пор, пока адрес веб-сайта, на который вы пытаетесь попасть, не будет найден. После этого ваш DNS-сервер сохраняет эту новую запись в вашем кэше, чтобы в следующий раз получить ответ быстрее.

Примеры и последствия отравления кэша DNS


Концепция DNS не приспособлена к специфике современного интернета. Конечно, со временем DNS был усовершенствован, однако сейчас по-прежнему достаточно одного неправильно настроенного DNS-сервера, чтобы миллионы пользователей ощутили на себе последствия. Пример атака на WikiLeaks, когда злоумышленники с помощью отравления кэша DNS перехватывали трафик, перенаправляя его на собственный клон сайта. Целью этой атаки было увести трафик с WikiLeaks, и она достигла определенного успеха. Отравление кэша DNS весьма непросто обнаружить обычным пользователям. В настоящее время система DNS построена на доверии, и это является ее слабым местом. Люди чересчур сильно доверяют DNS и никогда не проверяют, соответствует ли адрес в их браузере тому, что им в действительности нужно. Злоумышленники же пользуются этой беспечностью и невнимательностью для кражи учетных данных и другой важной информации.

Как работает отравление кэша DNS?





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

Перехват трафика локальной сети с помощью подмены протокола ARP


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

Одна из распространенных проблем сотрудники, работающие удаленно. Можно ли быть уверенными, что их сеть Wi-Fi защищена? Хакеры могут взломать слабый пароль от сети Wi-Fi за считанные часы.

Еще одна проблема открытые порты Ethernet, доступные всем желающим в коридорах, вестибюлях и других общественных местах. Просто представьте: посетитель может подключить к своему устройству кабель Ethernet, предназначенный для дисплея в вестибюле. Как хакер может использовать доступ к вашей локальной сети, полученный одним из перечисленных выше способов? Во-первых, он сможет создать фишинговую страницу для сбора учетных данных и другой ценной информации. Затем он может разместить этот сайт либо в локальной сети, либо на удаленном сервере, и для этого ему потребуется всего-навсего одна строка кода на Python. После этого хакер может начать следить за сетью с помощью специальных инструментов, таких как Betterrcap. На этом этапе хакер изучает сеть и производит рекогносцировку, но трафик все еще проходит через маршрутизатор. Затем злоумышленник может совершить подмену протокола разрешения адресов (ARP), чтобы изнутри изменить структуру сети. Протокол ARP используется сетевыми устройствами для связывания MAC-адреса устройства с IP-адресом в сети. Bettercap будет отправлять сообщения, заставляя все устройства в сети считать компьютер хакера маршрутизатором. Благодаря этой уловке хакер сможет перехватывать весь сетевой трафик, проходящий через маршрутизатор. Достигнув перенаправления трафика, злоумышленник может запустить модуль Bettercap для подмены DNS. Этот модуль будет искать любые запросы к целевому домену и отправлять жертве ложные ответы. Ложный ответ содержит IP-адрес компьютера злоумышленника, переправляя все запросы к целевому сайту на фишинговую страницу, созданную хакером. Теперь хакер видит трафик, предназначенный для других устройств в сети, собирает вводимые учетные данные и внедряет вредоносные загрузки.
Если же хакер не может получить доступ к локальной сети, он прибегнет к одной из следующих атак.

Подделка ответов с помощью атаки дней рождения


DNS не проверяет подлинность ответов на рекурсивные запросы, поэтому в кэше сохраняется первый ответ. Злоумышленники используют так называемый парадокс дней рождения, чтобы попытаться предугадать и отправить поддельный ответ запрашивающей стороне. Для предугадывания атака дней рождения использует математику и теорию вероятностей. В этом случае злоумышленник пытается угадать идентификатор транзакции вашего DNS-запроса, и в случае успеха поддельная запись DNS попадает к вам раньше легитимного ответа. Успех атаки дней рождения не гарантирован, но в конце концов злоумышленник сможет подложить в кэш поддельный ответ. После того как атака увенчается успехом, хакер сможет видеть трафик от поддельной записи DNS до окончания жизненного цикла (TTL) записи DNS.

Эксплойт Каминского


Эксплойт Каминского является разновидностью атаки дней рождения. Обнаруживший эту уязвимость Дэн Каминский впервые представил ее на конференции BlackHat в 2008 году. Суть эксплойта заключается в том, что сначала хакер отправляетDNS-резолверу запрос для несуществующего домена, например fake.varonis.com. Получив такой запрос, DNS-резолвер перенаправляет его на авторитетный сервер имен, чтобы получить IP-адрес ложного субдомена. На этом этапе злоумышленник перегружает DNS-резолвер огромным количеством поддельных ответов в надежде, что один из этих поддельных ответов совпадет с идентификатором транзакции исходного запроса. В случае успеха хакер подменяет в кэше DNS-сервера IP-адрес, например, как в нашем примере с varonis.com. Резолвер продолжит отвечать всем запрашивающим, что поддельный IP-адрес varonis.com является настоящим, пока не истечет жизненный цикл записи DNS.

Как обнаружить отравление кэша DNS?


Как обнаружить, что кэш DNS отравлен? Для этого нужно следить за вашими DNS-серверами в поисках индикаторов возможной атаки. Однако ни у кого нет вычислительных мощностей, чтобы справиться с такими объемами DNS-запросов. Лучшим решением будет применить к вашему мониторингу DNS аналитику безопасности данных. Это позволит отличить нормальное поведение DNS от атак злоумышленников.
Внезапное увеличение активности DNS из одного источника в отношении одного домена свидетельствует о потенциальной атаке дней рождения.
Увеличение активности DNS из одного источника, который запрашивает у вашего DNS-сервера многочисленные доменные имена без рекурсии, свидетельствует о попытке подобрать запись для последующего отравления.
Помимо мониторинга DNS необходимо также вести мониторинг событий Active Directory и поведения файловой системы, чтобы вовремя обнаружить аномальную активность. А еще лучше будет использовать аналитику для поиска взаимосвязи между всеми тремя векторами. Это позволит получить ценную контекстную информацию для усиления стратегии кибербезопасности.

Способы защиты от отравления кэша DNS





Помимо мониторинга и аналитики вы можете внести изменения в настройки DNS-сервера:
  • ограничьте рекурсивные запросы, чтобы защититься от потенциального целевого отравления кэша;
  • храните только данные, относящиеся к запрашиваемому домену;
  • ограничьте ответы только теми, которые касаются запрашиваемого домена;
  • требуйте у клиентов использовать протокол HTTPS.

Убедитесь, что вы используете последние версии программного обеспечения BIND и DNS и, таким образом, имеете все актуальные исправления уязвимостей. Если возможно, например, в случае с удаленными сотрудниками, организуйте работу так, чтобы все удаленные компьютеры были подключены через VPN. Это защитит трафик и DNS-запросы от локального отслеживания. Кроме того, стимулируйте сотрудников создавать надежные пароли для сетей Wi-Fi, чтобы также снизить риски.

И, наконец, используйте зашифрованные DNS-запросы. Модули безопасности службы доменных имен (DNSSEC) это протокол DNS, который использует подписанные DNS-запросы для предотвращения их подмены. При использовании DNSSEC, DNS-резолверу необходимо проверить подпись на уполномоченном DNS-сервере, что замедляет весь процесс. Вследствие этого DNSSEC пока не получил широкого распространения.

DNS поверх HTTPS (DoH) и DNS поверх TLS (DoT) являются конкурирующими спецификациями для следующей версии DNS и, в отличие от DNSSEC, предназначены для обеспечения безопасности DNS-запросов без ущерба скорости. Тем не менее эти решения не идеальны, поскольку могут замедлить или полностью сделать невозможным локальный мониторинг и анализ DNS. Важно отметить, что DoH и DoT могут обходить родительский контроль и другие блокировки на уровне DNS, установленные в сети. Несмотря на это, Cloudflare, Quad9 и Google имеют общедоступные DNS-серверы с поддержкой DoT. Многие новые клиенты поддерживают эти современные стандарты, хотя их поддержка и отключена по умолчанию. Вы можете найти более подробную информацию об этом в нашем посте по безопасности DNS.

Подмена DNS заменяет легитимный IP-адрес сайта на IP-адрес компьютера хакера. Обнаружить подмену очень непросто, ведь с точки зрения конечного пользователя он вводит в браузере абсолютно нормальный адрес сайта. Несмотря на это остановить подобную атаку можно. Риски снизить можно, используя мониторинг DNS, например, от Varonis, а также стандарт шифрования DNS поверх TLS (DoT).

Отравление кэша: часто задаваемые вопросы


Ознакомьтесь с распространенными вопросами о подмене DNS и ответами на них.

Отравление кэша DNS и подмена кэша DNS (спуфинг) это одно и то же?


Да, отравлением кэша и подменой кэша называют один и тот же тип кибератаки.

Как работает отравление кэша DNS?


Отравление кэша обманывает ваш DNS-сервер, сохраняя на нём поддельную запись DNS. После этого трафик перенаправляется на сервер, выбранный хакером, и там осуществляется кража данных.

Какие меры безопасности можно применять для защиты от отравления кэша DNS?


Владельцы сайта могут осуществлять мониторинг и аналитику для выявления подмены DNS. Кроме того, можно обновить DNS-серверы, чтобы использовать модули безопасности службы доменных имен (DNSSEC) или другую систему шифрования, например DNS поверх HTTPS или DNS поверх TLS. Повсеместное использование полного сквозного шифрования, такого как HTTPS, также может предотвратить подмену DNS. Брокеры безопасного облачного доступа (CASB) чрезвычайно полезны для этих целей. Конечные пользователи могут сбросить потенциально подделанный кэш DNS, периодически очищая кэш DNS своего браузера, или после подключения к небезопасной или общедоступной сети. Использование VPN может защитить от подмены DNS в локальной сети. Избегайте подозрительных ссылок. Это поможет избежать риска заражения кэша вашего браузера.

Как проверить, подверглись ли вы атаке с отравлением кэша?


После того как кэш DNS был отравлен, это сложно обнаружить. Куда лучшая тактика осуществлять мониторинг ваших данных и защищать систему от вредоносных программ, чтобы уберечься от утечек данных в следствие отравления кэша DNS. Посетите нашу интерактивную лабораторию кибератак, чтобы увидеть, как мы используем мониторинг DNS для обнаружения реальных угроз кибербезопасности.

Как работает связь DNS?


Когда конечный пользователь вводит URL-адрес, например Varonis.com, в свой браузер, происходит следующее:
  1. Сначала браузер проверит свой локальный кэш на наличие уже сохраненных данных DNS.
  2. Если эти данные отсутствуют, он запросит вышестоящий DNS-сервер, которым, как правило, является ваш маршрутизатор в локальной сети.
  3. Если маршрутизатор в своем кэше тоже не содержит требуемой записи DNS, то запрос отправится дальше, к вышестоящим поставщикам DNS, таким как Google, Cloudflare или Quad9.
  4. Этот вышестоящий сервер получит DNS-запрос и проверит свой кэш.
    4.1. Если данных в кэше нет, запустится рекурсивный DNS-резолвер, и сначала будут запрошены корневые серверы DNS с вопросом кто обрабатывает .com.
    4.2. Затем резолвер отправит запрос серверу домена верхнего уровня .com, чтобы узнать кто обрабатывает Varonis.com, на который домен верхнего уровня отвечает полномочным сервером имен для данного URL.
    4.3. После этого резолвер отправляет запрос полномочному серверу имен вопрос какой IP-адрес у Varonis.com, на который полномочный сервер отвечает IP-адресом домена.
  5. Затем данные DNS отправляются обратно по цепочке, пока не попадут на устройство конечного пользователя. На всем пути следования каждый из DNS-серверов запишет полученный ответ в свой кэш для дальнейшего использования.


Как злоумышленники отравляют кэш DNS?


Способов отравления кэша много, и вот самые распространенные из них: принудить жертву нажать на вредоносную ссылку, использующую встроенный код для изменения кэша DNS в браузере пользователя; взлом локального DNS-сервера с помощью атаки через посредника. Вышеупомянутая атака через посредника использует подмену протокола разрешения адресов (ARP) для перенаправления DNS-запросов на DNS-сервер, контролируемый злоумышленником.

Что такое отравление кэша DNS?


Отравление кэша DNS это действия по замене записи в базе данных DNS на IP-адрес, ведущий на вредоносный сервер, контролируемый злоумышленником.

Как выполняется подмена DNS?


Хакер выполняет атаку с подменой DNS, получая доступ и изменяя кэш DNS или перенаправляя запросы DNS на свой собственный DNS-сервер.

Что подразумевается под подменой DNS (спуфингом)?


Понятие подмена DNS (спуфинг) значит, что URL, вводимый пользователем в браузере, например varonis.com, на самом деле не ведет на нужный официальный IP-адрес, соответствующий этому URL. Вместо этого пользователь перенаправляется на вредоносный сервер, контролируемый хакером.

Чем опасна подмена DNS?


Подмена DNS представляет опасность, потому что по своей природе служба имен доменов (DNS) считается надежной, поэтому зачастую ее не защищают каким-либо шифрованием. Это приводит к тому, что хакеры могут подменять записи в кэше DNS для дальнейшей кражи данных, внедрения вредоносных программ, фишинга и блокировки обновлений.
Основная угроза, которую представляет атака подменой DNS, заключается в краже данных через фишинговые страницы. Помимо этого существует риск внедрения вредоносной программы под видом загружаемых файлов, которые выглядят настоящими. Также, если обновление системы производится через интернет, злоумышленник может блокировать обновление, изменяя записи в DNS так, чтобы они не вели на нужный сайт.
Подробнее..

Цензура в интернете. Надо что-то делать

23.02.2021 12:21:01 | Автор: admin

Я устал от того, что власть имущие упыри делают с нашим интернетом:

  1. Нас лишают доступа в интернет, когда им удобно

  2. Ресурсы лишают статуса СМИ

  3. Ресурсы блокируют

  4. Ресурсы называют экстремистскими за освещение реального положения дел

  5. Журналисты, выполняющие свою работу, получают реальные тюремные сроки

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

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

Ликбез. Как работает интернет?

В протоколах TCP иUDP, поверх которых работает семейство протоколов HTTP, нет понятия имя хоста / имя ресурса. Вместо этого они оперируют IP-адресами. Для того, чтобы преобразовать имя хоста в IP-адрес (или отрезолвить имя хоста), применяются DNS-сервера. Только после успешного преобразования имени хоста в IP-адрес происходит соединение с ресурсом

Схематично основные этапы установки соединенияСхематично основные этапы установки соединения

Цензура нарушает ход вещей. Механизмы цензуры атакуют инфраструктуру сети Интернет и нарушают доступность и работоспособность ресурсов

Как работает цензура?

Некоторые вектора атаки:

  1. DNS-сервер может вернуть совсем не то, что вы бы хотели. Это называется подменой DNS

  2. Допустим, мы смогли отрезолвить хост верно (или получили правильный IP-адрес целевого хоста). Далее происходит попытка подключения. На этом этапе ваш запрос может быть отфильтрован провайдером. Это называется фильтрацией по IP-адресу

  3. Допустим, соединение установлено. Провайдер может принять решение его оборвать на основании анализа вашего трафика

1. Подмена DNS

Классика прописать вручную DNS-сервера google8.8.8.8 и cloudflare1.1.1.1. Но я отказался от такой конфигурации в пользу DoH DNS-over-HTTPS, так как протокол DNS не защищён ни от прослушивания, ни от подмены, ни от фильтрации трафика по протоколу. Для DoH такое сделать сложнее без cloudflare солидная часть интернета ляжет

Наконец, за реализацию механизма DNS-over-HTTPS в Британии компанию Mozilla назвали злодеем года это о чём-то говорит

Firefox + DoH

Технология DNS-over-HTTPSвпервые появилась в Firefox 73 в 2018 году. Убедитесь, что версия Вашего браузера Firefox не ниже 73

Со значением всех настроек можно подробнее ознакомиться в документации наsupport.mozilla.org иwiki.mozilla.org. Совет обязательно проверяйте, какие именно настройки вы устанавливаете в соответствии с документацией. Я могу ошибиться, школьник Петя может накрутить отсебятины, работающей только в его богатом воображении, а товарищ майор Василий Мусоров может и вовсе написать крайне убедительную статью про настройку браузера, с предсказуемым для Вас финалом

  1. В адресной строке браузера набираемabout:config

  2. В открывшемся окне в строке поиска настроек набираемnetwork.trr

  3. Находим настройкуnetwork.trr.mode. Я её установил в значение2

  4. Находим настройкуnetwork.trr.excluded-domains, и там указываемonion,i2p

Настройка DoH в FirefoxНастройка DoH в Firefox

2. Фильтрация по IP-адресу

Тут идея достаточно простая пустить трафик не на заблокированный узел, а куда-нибудь в обход через proxy-сервер. Хотелось бы сделать это по-умному, минимизировав объём трафика через дохлый proxy-сервер. Какой смысл гонять через proxy тот же youtube? Объём трафика просто положит proxy-сервер

SmartProxy создаём эффективные правила проксирования

Хорошая новость для тех, кто пользуется Chrome: SmartProxy доступен как дляFirefox, так и дляChrome

Устанавливаем SmartProxy. Разрешаем его работу в приватном режиме

Активация SmartProxyАктивация SmartProxy

Открываем панельку дополнения и активируем. После кликаем Settings, и там находим Прокси Сервера

Proxy-сервераProxy-сервера

Ручное добавление Proxy сервера

Чуть дальше я расскажу об автоматическом добавлении серверов. Не торопитесь бросаться добавлять сервера руками. Понимание процесса Вам потребуется, а вот ручная работа нет

Списки proxy-серверов можно найти, например, наhidemy.name или наfree-proxy.cz. Это ни в коем случае не все сайты, где можно найти списки proxy-серверов

Обращаю Ваше внимание если Вы включили DNS-over-HTTPS, вам хватит SOCKS4, которых очень много. В противном случае Вам остаётся использовать только SOCKS5, которые поддерживают резолв имени хоста на стороне proxy, а найти быстрый рабочий SOCKS5-прокси квест

Следует понимать, что наличие proxy-сервера не гарантирует его работоспособность. Адрес можно просто добавить в список proxy и попытаться зайти на интересующий ресурс через него. Это работает. Но все эти манипуляции занимают кучу времени. Намного быстрее проверить proxy-сервер через curl:

$ curl --socks4 111.22.33.44:5555 api.ipify.org
Добавление нового proxy-сервераДобавление нового proxy-сервера

Важно: после нажатия на кнопку Save / Сохранить вы попадаете обратно к списку proxy-серверов. В самом низу нужно нажать синюю кнопку Save Changes / Сохранить изменения. Если этого не сделать изменения применены НЕ будут, и добавленные сервера исчезнут при закрытии вкладки

Автоматическое добавление Proxy серверов

Очень скоро ручное добавление proxy-серверов надоест. Я остановился на варианте, когда вручную добавлены только proxy-сервера специального назначения, а остальное я выгребаю через подписку

Гугление по запросу socks4 txt вывело меня нарепозиторий. Это ни в коем случае не единственный список proxy-серверов в интернете

Подписки на списки proxy-серверовПодписки на списки proxy-серверовСоздаём подписку на список proxy-серверовСоздаём подписку на список proxy-серверов

Почему именно такие значения? URL написаны в README воттут. 10080 минут для периода обновления это раз в неделю. Я посчитал это достаточным, но это не значит, что это единственно правильное значение. Протокол в имени файла со списком серверов

После добавления можно нажать кнопку Test. Если всё настроено правильно SmartProxy скажет, сколько серверов было добавлено. После сохранения не забываем нажать синюю кнопку Save Changes / Сохранить изменения. Если этого не сделать вы повторите мой подвиг Так, а куда они пропали? Только что ж были

Правила проксирования

Мы добавили сервера, но без правил проксирования эти сервера лежат просто мёртвым грузом. Перейдём на вкладку Proxy Rules / Правила проксирования

Список правил проксированияСписок правил проксирования

Давайте попробуем добавитьlurkmore.to он точно заблокирован

Добавляем правило для lurkmoreДобавляем правило для lurkmore

Немного объясню, почему правило именно такое. Поле Rule Type / Тип Правила определяет, что правило будет применяться для всех URL указанного сайта и всех его поддоменов. Rule Source Domain указывает, что правило действует только для доменаlurkmore.to и его поддоменов, и ни на что больше. Поле Proxy Server имеет значение[General] это значит, что для текущего ресурсаlurkmore.to будет применён текущий активный proxy-сервер. О выборе активного сервера следующий раздел. Можно также указать конкретный proxy-сервер из списка proxy-серверов, который мы наполняли ранее руками или по подписке

После сохранения правила не забываем нажать синюю кнопку Save Changes / Сохранить изменения. Иначе ну вы поняли

Пытаемся зайти на сайт

Тут немного нетривиальной магии. Я просто тыкаю рандомный IP из списка и пытаюсь зайти на сайт. Не удалось следующий IP

Выбираем активный proxy-серверВыбираем активный proxy-сервер

Магии тут немного. Автор дополнения хотел разместитьфлаг страны, где располагается proxy-сервер, но столкнулся с некоторыми трудностями. Я попросил его разместить хотя бы трёхбуквенный код страны для каждого proxy-сервера. Математика проста чем ближе страна, тем меньше задержка. Также будет очень глупо попасть на proxy-сервер страны, где ресурс заблокирован

3. Анализ вашего трафика

Шифрование сильно усложняет анализ трафика, но не делает его невозможным. По возможности, следите, чтобы использовался протокол https. Воспользуйтесь дополнением HTTPS Everywhere дляChrome иFirefox, который позволяет определить правила автомагического редиректа с протокола HTTP на протокол HTTPS

ESNI

Для шифрования HTTP-трафика и таким образом преобразования его в HTTPS применяется протокол TLS. Проблема протокола TLS в том, что он позволяет на одном сервере запустить лишь один HTTPS-сервер прямо как старый добрый HTTP 1.0. Для решения этой проблемы разработан протоколSNI. И вот тут была допущена ошибка имя хоста передаётся в открытом виде. Это имя хоста перехватываетDPI провайдера и принимает решение о разрыве соединения. ИдеяESNI проста зашифровать SNI

Firefox первый браузер, реализовавший поддержку ESNI. Включаем:

  1. В адресной строке браузера набираемabout:config

  2. В открывшемся окне в строке поиска настроек набираемnetwork.security.esni.enabled

  3. Двойным кликом мышки устанавливаем в значениеtrue

Включение ESNI в FirefoxВключение ESNI в Firefox

Проверить, работает ли ESNI в браузере, можнотут

ESNI очень не понравился власть имущим упырям, и его полностью блокируют вРоссии и Китае прям знак качества

Подробнее..

Кабысдох DoH-припарка от русского firewall

23.01.2021 00:18:58 | Автор: admin
# wtf cf-hls-media.sndcdn.comcf-hls-media.sndcdn.com is an alias for d1ws1c3tu8ejje.cloudfront.net.d1ws1c3tu8ejje.cloudfront.net has address 13.33.240.123 13.33.240.123 заблокирован

С в очередной раз замолчавшего радио и начался тот день, когда я допилил DNS-over-HTTPS сервер для облегчения фантомных болей от творчества Роскомнадзора.

Боли эти хорошо описаны @ValdikSS в статье В России сохраняются проблемы с доступностью сайтов, но никто их не замечает.

Думать особо не приходится, суть проблем проста и решение тоже не очень сложно: достаточно выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN. Такое издевательство над DNS позволяют как минимум Cloudflare и Amazon Cloudfront.

Например, если в условном DNS-ответе от AKAMAI пришли адреса 23.1.14.0 и 23.1.20.2, а первый из них заблокирован РКН, то в таком случае DNS-сервер может отдать клиенту только один адрес из двух, и браузер не будет тупить в попытке установить соединение с заблокированным IP. Это не обход блокировок, скорее наоборот. Но оно измеримо уменьшает боль. Я был бы рад такую конструкцию увидеть у Яндекс.DNS в Безопасном режиме, но всё же не думаю, что Яндекс готов реализовать такую в меру серую фичу.

Валить в панике из страны? Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции. Можно ещё попытаться что-то починить, да посмеяться над тем, что осталось.

Но хочу предупредить, модель такого DNS-сервера по имени kabysdoh.gulag.link запущена на виртуалке в Санкт-Петербурге, поэтому её использование из других регионов России может добавить существенную задержку к вашим DNS-запросам. При наличии архива XML-выгрузок Роскомнадзора, можно взять исходный код с GitHub и запустить Unbound в подходящей локации. Поддержку Knot Resolver я с @ValdikSS допилю в каком-нибудь обозримом будущем.

Мобильные устройства на Android поддерживают DNS-over-TLS, который доступен по адресу kabysdoh.gulag.link, а Mozilla Firefox поддерживает DNS-over-HTTPS по адресу https://kabysdoh.gulag.link/dns-query. Скриншоты примерной конфигурации можно увидеть ниже (про все возможные опции DoH в Firefox можно прочитать на wiki):

У меня на сегодня всё! Надеюсь, кому-то данная конструкция будет полезна. И помните, once you step into the waters of modifying in-flight DNS messages it seems like crocodiles all the way down.

Подробнее..

Конференция ENOG17 состоится online

19.09.2020 00:21:00 | Автор: admin

В этом году ENOG17 и Региональная Встреча RIPE NCC будут проходить с 9 по 13 ноября в форме виртуального мероприятия.

Традиционно, главными темамиENOGявляются технологии интернет, передовые подходы к управлению сетями, взаимодействие сетей, а также вопросы сотрудничества и координации между игроками Интернет-рынка.

Впервые конференция ENOG прошла в 2011 году в Москве. С тех пор она проводилась в разных городах и странах: России (Москва, Санкт-Петербург и Казань), Украине (Киева и Одесса), Азербайджане (Баку), Армении (Ереван), Беларуси (Минск), Грузии (Тбилиси). В онлайн-формате конференция проводится впервые, хотя формат удаленных докладов для неё не нов (например, в 2018 году Женя Линькова из Google в Москве рассказывала про IPv6 в корпоративных сетях из Австралии).

Сейчас продолжается прием докладов для выступления на конференциюENOG17:К настоящему времени мы уже получили ряд хороших заявок, но свободные места в программе всё ещёесть.

Программному комитету конференции ищет доклады о проблемах, инструментах, опыте работы и тенденциях в таких областях, как:

  • Ключевые интернет- и сетевые технологии

    • Новые протоколы и технологии: сегментная маршрутизация, QUIC, 5G и др.

    • Протоколы внутренней и внешней маршрутизации

    • Опыт внедрения новых технологий (например, IPv6 и DNSSEC), тенденции и статистика

    • Программно-определяемые сети и автоматизация сети

    • Интернет вещей (IoT)

  • Тенденции развития интернета

    • Новые технологии, области их использования и эволюция экосистем Интернета

    • Интернет-измерения, аналитика и прогнозы развития Интернета

  • Координация, управление и регулятивная практика в интернете

    • Относящееся к Интернету законодательство и его влияние, многосторонняя модель, препятствия и возможности

    • Общественные инициативы и проекты в области управления использованием Интернета, координации, исследования и внедрения новых технологий

  • Пиринг и точки обмена трафиком

    • Коммерческие, технические и социальные аспекты сетевого взаимодействия

  • Эксплуатация сетей и сетевая безопасность

    • Практический опыт и лучшие передовые методы, тенденции в сетевой безопасности и сопутствующих технологиях, обзор рисков.

    • Предотвращение DDoS-атак

  • Доставка контента (CDN)

    • Технологии, архитектура и бизнес-модели

Если вы хотите предложить свой доклад для включения в программуENOG17, пожалуйста, предоставьте тезисы доклада и черновой вариант презентации с помощью онлайн-системы:
https://www.enog.org/ru/submit-topic/submission-form/.

Докладчики должны указать, сколько времени требуется на доклад. Обычно время выделяется согласно формату доклада:

  • Пленарный доклад: 20-25 минут презентации и 5-10 минут обсуждения

  • Учебные курсы и мастер-классы: до трех часов

  • BoF-сессия: приблизительно один час в вечернюю сессию

  • Блиц-доклад: 10 минут в сумме на презентацию и обсуждение

(Конечно, при необходимости можно обсудить и создание нового формата)

В случае возникновения сомнений, к какому именно формату относится ваш доклад, не стесняйтесь обращаться за уточнениями в Программный комитет.

Правила подачи заявок и форматы презентаций опубликованы здесь.

Для участия с докладом в пленарной части конференции или семинаром просим вас прислать тезисы не позднее 11 октября. Тезисы и доклады принимаются на русском и английском языках. Во время конференции обеспечивается синхронный перевод всех пленарных докладов. Доклады рекламного или коммерческого характера не принимаются.

Если вы можете порекомендовать интересный доклад и докладчика, пришлите, пожалуйста, свое предложение в Программный комитет.

Подробнее..

Доменный регистратор, или Туда и обратно

30.11.2020 12:14:44 | Автор: admin

Короткая история

В сентябре 2017 года в компании, где я работала, пошли разговоры о том, что планируется создание доменного регистратора. Как очень молодой специалист (20 лет и начало 3 курса бакалавриата), я быстро распознала в нём проект, который может дать мне проявить себя. И к моему счастью, то ли в меня настолько поверили, то ли проект не посчитали перспективным, но он достался именно мне, почти целиком и полностью. На момент начала работы я предполагала, что материала будет мало даже для бакалаврского диплома. Я никогда так не ошибалась. Всё, начиная от понимания схемы работы системы, до её проектирования и написания, заняло очень много времени. Было переосмыслено много теории по Сетям, паттернам проектирования и вообще о работе.

Что такое домен?

Думаю, очень многие представляют себе, что такое домен, или доменное имя. Это некоторое слово, которое заменяет настоящий адрес интернет-сервера. Например, "habr.com" - доменное имя, состоящее из домена верхнего уровня "com" и домена второго уровня "habr".

Иерархическая организация доменных имён (reg.ru)Иерархическая организация доменных имён (reg.ru)

Каждой доменной зоной кто-то владеет и заведует. Доменная зона .com принадлежит компании Virisign (ранее Network Solutions). Это означает, что эта компания выдаёт разрешения на пользование доменами .com, в том числе habr.com. При покупке домена на год (в реальности аренде), запрос в конечном итоге уходит на сервера данной компании.

В данной статье мы будем рассматривать другую доменную зону - .ru и .рф. Администратором этих зон является Координационный центр национального домена сети Интернет. Это особый, национальный домен, и это накладывает некоторые ограничения на то, кто может покупать поддомены в этой области.

Доменные регистраторы

Если доменными зонами кто-то владеет, почему они не продают их людям? Потому что этим занимаются доменные регистраторы.

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

На данной картинке доменный регистратор - человечек слева. Казалось бы, пара видов запросов и получение уведомлений.

Что касается российской системы - там тоже представлена документация, но сильно менее подробная и ориентированная на подготовленного пользователя.

Фрагмент из документации Фрагмент из документации

Чтобы стать доменным регистратором, надо получить аккредитацию у администратора доменной зоны и пройти специальные технические испытания, доказывающие, что инструмент рабочий. После получения аккредитации компания появляется в списке аккредитованных регистраторов. Если это звание не подтвердить в течение определённого срока успешным прохождением технических испытаний, организация лишается аккредитации.

Профит

Выгоду от работы доменного регистратора можно получить очень даже хорошую. Дело в том, что все домены стоят одинаково при отдаче денег администратору доменной зоны - что vk.com, что mihail-petrovich-santehnik.ru, и стоят не много. Цены же у доменных регистраторов варьируются от 0 до миллионов рублей. Очевидно, если домен стоит 200 рублей, а за него взяли несколько миллионов, разница будет приятна. Однако это не деньги из воздуха.

Аукцион доменов

Многие хотят получить "красивое" доменное имя, ведь оно хорошо запоминается, что для бизнеса крайне важно. Например, "vk.com" является лакомым кусочком, ведь он состоит из двух символов. За короткие и красивые домены идёт борьба.

Как видим, желаемый bank.ru уже занят, а какой-то банк.рус (?) стоит уже 3млн. Домен bank.ru однажды освободится, и тогда на него будет много желающих.

Каждый месяц ТЦИ вывешивает список освобождающихся доменов. И в определённый час любой доменный регистратор может подать заявку на покупку освободившегося домена.

Если у вас один клиент, который хочет один домен, вы легко заполучите желаемое, отправив самым первым запрос на покупку. В данном случае успех операции зависит лишь от того, будет ли ещё какой-нибудь регистратор ломиться первым за данным доменом. Если нет - домен ваш.

Однако если у вас несколько клиентов и несколько доменов, задача усложняется. Вы сначала отправите запрос на покупку A.ru, потом cat.ru, и так далее. Шансы на успех покупки каждого последующего домена уменьшаются, так как кто-то мог поставить для себя покупку домена cat.ru первым приоритетом. Тогда этот домен достанется ему, а вы вернёте деньги покупателю и разочаруете его.

По этой причине нужно выстраивать приоритет покупок - какой домен из востребованных будет запрошен первым, какой вторым и так далее. Очевидный способ регулировать это - аукцион. Если пользователь предложит большое вознаграждение за товар, это будет наивысший приоритет для доменного регистратора.

Что касается высоких цен на свободные домены - их определяет исключительно спрос.

Взаимодействие с Системой регистрации

В упрощённом виде взаимодействие выглядит примерно так. Есть стандартный веб-сайт, через который пользователь может обращаться за услугами регистрации/продления/трансфера. Веб-сайт обращается к своим базам данных, чтобы не слишком нагружать сеть и запрашивать всё у регистратора, а также обращается к Системе регистрации, чтобы совершать операции по изменению объектов в реестре.

Регистратор отправляет запросы в реестр, используя EPP поверх TCP. Команды формируются с помощью XML. ПО Регистратора должно как составлять XML-запросы, так и иметь синтаксический анализатор XML для интерпретации ответов от Реестра. EPP в свою очередь функционирует только через аутентификацию Регистратора для безопасности, которая достигается путём использования TLS в шифровании сессии. Можно использовать как коммерческую, так и свободную реализацию TLS, например, OpenSSL.

Система также общается с банком, но данный момент будет упущен в статье для упрощения.

Объекты реестра

Основные объекты реестра - Контакт, Домен, Хост и Регистратор. Регистратор - это мы. Отправляя все запросы на покупки и регистрации, мы оставим там свой след - id своего регистратора.

Наиболее интересным объектом реестра является Домен. Он имеет свой жизненный цикл, и за операции с ним тратятся деньги.

Когда домен зарегистрирован, можно спокойно жить 11 месяцев. После чего есть время на продление без потери прав обладания, затем права теряются, однако домен ещё не освобождён, даётся шанс на его перепокупку. Если и этот шанс упущен - домен удаляется и становится доступным для всех желающих.

К счастью, Система регистрации отправляет уведомления регистратору о том, что скоро истекает срок регистрации, а регистратор в свою очередь напоминает об этом пользователю.

Также интересна операция трансфера домена от доменного регистратора. При попытке другого доменного регистратора забрать наш домен, генерируется специальный пароль, который пользователь должен ввести как в одном, так и в другом сервисе. Этим он подтверждает чистоту своих намерений.

Проектирование библиотеки

Registry

Взаимодействие со всей библиотекой происходит через класс-регистратуру. В ней создаются объекты для взаимодействия с любым классом системы. Конструктор реализован паттерном Singleton (Одиночка) для максимального переиспользования как объектов Домен/Контакт/Хост, так и для поддержания сохранности доменной зоны, id клиента, пароля, ssl-сертификата и его ключа, а также языка взаимодействия, объекта curl для отправки запросов.

В этом же классе реализованы функции для работы с XML. Реализация каждого из двух методов составила около 20 строк, что значительно легче готовых библиотек для работы с XML. Более того, это обеспечило гибкость появилась возможность собственного представления вложенных структур для объектов, которые легко собираются в XML.

Registrar, Host, Domain, Contact

Основные классы реестра - прослойка логики между входом (регистратурой) и отправкой запросов. Тут выбирается метод, который необходимо вызвать у объекта, проверяются входные POST-параметры. Если параметры не валидные, выбрасывается исключение. Помимо данных методов в каждом классе хранятся регулярные выражения, которые не используют другие классы (например, флаги о закрытой информации для Контакта-организации, больше они нигде не нужны).

Poll

Поскольку, например, в случае трансфера домена, инициатором общения с Реестром становился он сам, был необходим также класс для обработки сообщений от него. Помимо данных сообщений Реестр может присылать сообщения об окончании срока регистрации или об удалении домена. Данные сообщения представляют собой очередь. Регистратор может получить только верхнее сообщение из очереди. Чтобы получить следующие сообщения, необходимо пометить прочитанным текущее.

R

Классы R (от англ. Regexp) классы проверки, в основном на регулярных выражениях. В них проходит та самая валидация, которая вызывается в основных классах. Есть R в пространстве имён RU это те функции и выражения, которые не понадобятся в других зонах. Например, номер телефона и ИНН (телефон в РФ особенный, ИНН существует только в РФ). R в пространстве имён Registrar будет применим ко всем будущим доменным зонам и к текущей.

Base

В базовых классах реализован логин в системе регистрации и сохранение сессии. Также тут генерируется XML со всеми необходимыми параметрами, поступившими из основных классов. Тут же получается ответ от системы и проверяется на успешность операции.

Хранение данных

Как упоминалось выше, все объекты пришлось хранить и у себя в системе для адекватной работы.

Данные хранятся в двух системах управления базами данных. Основная информация содержится в MariaDB. В ней хранятся все контакты, хосты и домены, а также ведётся журнал транзакций для отслеживания успешности всех процедур. Примечательным является то, что для хранения данных используется тип text, который на самом деле является типом JSON. По данному полю можно свободно совершать поиск без временных потерь, хоть данный тип оптимизирован не так хорошо, как в MySQL. Данное решение позволило увеличить гибкость хранимых данных и значительно ускорило скорость разработки.

В СУБД ClickHouse находятся логи всех операций. Регистратор обязан хранить все операции, совершённые им за весь период деятельности. Схема данной таблицы слишком проста, поэтому не будет тут представлена. Это тело запроса, ответа, время и пользователь. ClickHouse был выбран для данной задачи из-за высокой степени сжатия, которая не отнимает качества поиска.

Технические испытания

Технические испытания можно проходить, ещё не имея адекватной интерфейсной части. Проверяется способность регистратора реагировать на сообщения системы. На сайте ТЦИ находится пример тестов для технических испытаний. Это очень похоже на контрольную работу. В указанное время вы получаете задания, выполняете их, и система сама проверяет, правильно ли вы их выполнили.

Заключение

Проект был сдан вовремя, и сейчас успешно представлен на рынке. А благодаря талантливейшему дизайнеру, он ещё и самый красивый из всех ныне существующих.

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

Желаю удачи!

Подробнее..

Отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived

24.10.2020 20:17:25 | Автор: admin

Сегодня я расскажу о том, как быстро собрать отказоустойчивый кластер с балансировкой нагрузки с помощью keepalived на примере DNS-серверов.


Итак, предположим, что у нас есть сервер, который должен работать без перебоев. Его нельзя просто так взять и выключить посреди рабочего дня клиенты или пользователи не поймут. Тем не менее любой сервер время от времени надо обслуживать, ставить обновления, менять аппаратную конфигурацию или сетевые настройки. Кроме того, нужно быть готовым к росту нагрузки, когда мощности сервера перестанет хватать. У сервера должна быть предусмотрена возможность быстрого масштабирования. Если вы озаботились этими проблемами, то вам нужно организовать отказоустойчивый кластер.


Чаще всего такие задачи приходится делать с HTTP-серверами. Я сегодня покажу сборку кластера на примере DNS, потому что опробовал технологию именно на нем, но с минимальными изменениями то же самое можно сделать и с серверами, работающими по TLS или HTTP.


Лирическое отступление о проблемах DNS


В принципе, DNS задуман так, чтобы необходимости городить огород с кластерами не возникало. В каждой зоне можно прописать множество NS-записей, в каждой сети можно раздать список DNS-серверов с помощью DHCP. DNS-сервера умеют реплицировать зоны, поэтому они хорошо масштабируются. Однако на практике это плохо работает. Когда я попробовал добавить 2-й DNS-сервер, то обнаружил, что


  1. Половина пользователей сидят со статическими настроенными адресами DNS-серверов. Ставят себе 4 восьмерки в качестве primary и локальный DNS в качестве secondary.
  2. Многие Linux-сервера не умеют из коробки корректно обновлять настройки DNS. Там такой зоопарк из glibc, nsswitch.conf, resolv.conf, NetworkManager, resolvconf, systemd-resolved, hosts, dhclient.conf и т. п., которые конфликтуют между собой, что рассчитывать на автоматическое обновление по DHCP просто не приходится.
  3. Windows шлет запросы одновременно на все сервера, но обязательно дожидается ответа или таймаута от 1-го
  4. Linux сначала обращается к 1-му DNS в списке и только в случае ошибки переходит к следующему.

Если долгое время в сети используется DNS-сервер с определенным IP, то он оказывается прописан в десятках разных мест. Например:


  • Директива resolver в nginx.conf
  • daemon.json в docker
  • В настройках docker-контейнеров
  • В конфигах модных нынче систем вроде kubernetes или openshift во внутренних файлах на каждой ноде и еще там же в конфигах dnsmasq.
  • В конфигах почтовых серверов.
  • В настройках VPN-серверов.

Никакими плейбуками и DHCP-декларациями это все обновить просто нереально. Поэтому было бы очень хорошо, если бы собираемый кластер можно было повесить на 1 уже существующий IP. Тогда для пользователей ничего не изменится, и софт перенастраивать не понадобится.


Поэтому я выбрал решение с keepalived и протоколом VRRP.


Подготовка


Собирая кластер из нескольких серверов, желательно уметь их различать на стороне клиента, чтобы не бегать искать по логам серверов, какой запрос, куда попал. Я для этого в bind9 завел вот такую зону.


/var/named/zones/load.balance.zone
$ORIGIN load.balance.$TTL 1hload.balance. 86400 IN SOA ns.mydomain.ru. dnsmaster.mydoamin.ru. (     1603065098 3600 1800 604800 30)load.balance. IN NS ns.mydomain.ru.health IN TXT =nameserver-1=

На 1-м сервере ресурсная запись TXT для health.load.balance содержит текст =nameserver-1=, на 2-м сервере =nameserver-2=, и т. д. Таким образом, отправляя запрос в кластер, я по ответу могу определить, какой сервер мне ответил, что очень удобно для отладки.


Если у вас HTTP-сервер, то поместите эту информацию в HTTP-заголовок. Например, для nginx я использую вот такую директиву


add_header serega-trace "$hostname" always;

Убедитесь, что ваши сетевые файерволлы не блокируют IP-трафик протокола 112 по адресу 224.0.0.18. Этот адрес будут использовать ваши сервера, чтобы договариваться между собой о том, кто из них MASTER, а кто BACKUP.


Открыть VRRP в iptables
iptables -t filter -I INPUT -p vrrp -d 224.0.0.18 -j ACCEPTiptables -t filter -I OUTPUT -p vrrp -d 224.0.0.18 -j ACCEPT

При организации DNS нужно выделить мастер-сервер, на который не будут идти клиентские запросы. DNS-мастер используется только для управления. Он реплицирует свои зоны на slave-сервера, которые уже видны пользователям, и именно на них идет нагрузка. Далее речь будет идти о кластеризации именно DNS-slave.


Уровень 1 (Easy)


Если вам просто достаточно резервирования на случай аварии, то рекомендую рассмотреть самый быстрый и простой вариант. 2 одинаковых сервера разделяют между собой общий виртуальный IP (далее буду называть его VIP). У кого в данный момент в сетевом интерфейсе прописан VIP, тот сервер и работает. 2-й сервер следит за мастером (имеется в виду мастер VRRP, а не DNS), и как только обнаруживает, что он перестал вещать, сразу объявляет мастером себя и поднимает VIP на своем сетевом интерфейсе.


Меня приятно удивило то, как быстро удалось поднять кластер по такому варианту. Несмотря на то, что раньше я никогда не имел дело с keepalived, уже через час все работало. Так что если вам нужно решить задачу быстро, то уровень 1 вам подойдет в самый раз.


Сбор информации


Для успешного развертывания вам понадобится собрать следующую информацию. Здесь я привожу значения для примера. У вас эти значения должны быть свои.


Параметр Возможное значение Описание
vip 10.2.1.5 виртуальный IP, на который шлют запросы клиенты
dev0 eth0 1-й сетевой интерфейс на узлах кластера
ip01 10.2.1.2 IP 1-го узла кластера на 1-м сетевом интерфейсе
ip02 10.2.1.3 IP 2-го узла кластера на 1-м сетевом интерфейсе
net0 10.2.1.0/24 подсеть, которой принадлежат ip01 и ip02

Установите keepalived и snmpd. SNMP ставить необязательно, но мне кажется, что, если серверов с виртуальными IP будет много, он будет полезен.


setenforce 0 # если вдруг у вас selinuxdnf install -y keepalived nmap-ncat net-snmp net-snmp-utilssystemctl enable keepalivedsystemctl enable snmpd

Netcat нужен для диагностики и healthcheck-ов.


В файл /etc/sysconfig/keepavlied добавьте опцию -x. Она нужна для взаимодействия keepalived с snmpd. Если вы не собираетесь поднимать SNMP, то этот шаг можете пропустить.


Отредактируйте файл /etc/snmp/snmpd.conf следующим образом:


/etc/snmp/snmpd.conf
master agentxrocommunity public

В /etc/keepalived положите вот такой скрипт keepalived-notify.sh:


/etc/keepalived/keepalived-notify.sh
#!/bin/shumask -S u=rwx,g=rx,o=rxexec echo "[$(date -Iseconds)]" "$0" "$@" >>"/var/run/keepalived.$1.$2.state"

Этот скрипт будет вызываться демоном keepalived при изменении состояния кластера. Он запишет в каталог /var/run статусный файл, который удобно использовать для диагностики.


Отредактируйте основной конфигурационный файл keepalived.conf следующим образом:


global_defs {    enable_script_security}vrrp_script myhealth {    script "/bin/nc -z -w 2 127.0.0.1 53"    interval 10    user nobody}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }    track_script {        myhealth    }}

Блок global_defs содержит единственную необходимую настройку enable_script_security, которая по умолчанию отключена.


Блок vrrp_script описывает скрипт, который демон keepalived будет использовать для определения работоспособности своего сервера. Если этот скрипт вернет ошибку, то демон перейдет в состояние FAIL, и не будет претендовать на роль MASTER. В этом же блоке описывается периодичность выполнения healthchek-ов и указывается пользователь, от имени которого запускается скрипт. В нашем случае используется утилита netcat, которая устанавливает соединение c локальным DNS-сервером по TCP-порту 53. Можно использовать разные проверки, например, прозвонить UDP-порт 53 утилитой dig.


В блоке VRRP_INSTANCE задаются настройки 1 экземпляра сервера с виртуальным IP.


  • state задает начальное состояние сервера BACKUP или MASTER. В режиме nopreempt единственное допустимое значение BACKUP.
  • interface указывает, на каком сетевом интерфейсе будет поднят VIP
  • virtual_router_id уникальный идентификатор роутера VRRP. Возможные значения от 1 до 255. У всех узлов кластера это значение должно быть одинаковым. Рекомендуется в качестве router_id использовать последний байт VIP, чтобы не запутаться, когда у вас таких виртуальных адресов будет много.
  • priority задает приоритет данного экземпляра при выборе мастера. Мастером назначается сервер, у которого значение параметра priority выше. Если у нескольких серверов priority одинаковый, то мастер будет выбран случайным образом.
  • advert_int определяет, с какой периодичностью мастер должен сообщать остальным о себе. Если по истечению данного периода сервера не получат от мастера широковещательное уведомление, то они инициируют выборы нового мастера.
  • nopreempt означает, что если мастер пропал из сети, и был выбран новый мастер с меньшим приоритетом, то по возвращении старшего мастера, он останется в состоянии BACKUP. Т. е. если вы перезагрузили мастер, то он больше мастером не станет, пока новый мастер не отвалится. Если вы предпочитаете, чтобы мастером был какой-то конкретный сервер, то замените настройку nopreempt на preempt_delay.
  • notify задает хук-скрипт, который будет вызываться при каждом изменении состояния сервера, и имя пользователя, от имени которого данный скрипт будет выполняться.
  • authentication задает пароль, длиной до 8 символов, который будет защищать кластер от случайных коллизий с другими серверами в локальной сети.
  • virtual_ipaddress задает VIP
  • track_script указывает на описание скрипта, осуществляющего healthcheck.

Выполните указанные настройки на обоих серверах кластера и запустите сервисы:


systemctl start snmpdsystemctl start keepalived

Проверьте логи и статусные файлы на наличие ошибок.


journalctl -u snmpdjournalctl -u keepalivedtail /var/run/keepalived.INSTANCE.VI_1.state

Если у вас используется selinux, не забудьте по данным audit.log обновить политики и вернуть enforcing mode командой set enforce 1.


Проверка


Если в логах ошибок нет, можно проверять. Поскольку мы кластеризовали DNS, то будем использовать dig. Для проверки HTTP-сервера подойдет curl.


Запустите на клиенте такой скрипт


while true; do    dig -4 +short +notcp +norecurse +tries=1 +timeout=1 \        -q health.load.balance. -t txt @10.2.1.5;     sleep 1;done

Этот скрипт будет раз в секунду выдавать ресурсную запись health.load.balance/IN/TXT, которая содержит идентификатор сервера. В нашей конфигурации это будет тот сервер, который сейчас VRRP-мастер.


Зайдите на этот сервер и убедитесь, что в файле /var/run/keepalived.INSTANCE.VI_1.state в последней строке указано MASTER.


Перезапустите на мастере сервис keepalived. Если у вас все сделано правильно, то мастер поменяется. На 1-м сервере в файле keepalived.INSTANCE.VI_1.state появятся строки STOP и BACKUP, на втором сервере в этом же файле появится строка MASTER, а клиентский скрипт станет выдавать ресурсную запись с идентификатором нового мастера.


[2020-10-13T10:48:00+00:00] /etc/keepalived/keepalived-notify.sh INSTANCE VI_1 BACKUP 100[2020-10-13T11:26:29+00:00] /etc/keepalived/keepalived-notify.sh INSTANCE VI_1 MASTER 100

"=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-2=""=nameserver-2="

Все, кластер готов. Теперь можно перезагружать сервера по одному в любое время, не нужно откладывать обновления на выходные, не нужно работать по ночам, не нужно рассылать пользователям предупреждения о том, что возможны перебои в связи с регламентными работами.


Если у вас все получилось, значит вы успешно прошли 1-й уровень кластеризации. Он обладает следующими плюсами:


  • очень легко и быстро настраивается,
  • практически невозможно что-либо сломать,
  • на всех узлах кластера одинаковая конфигурация, что сильно сокращает трудоемкость администрирования.

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


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


Уровень 2 (c балансировкой нагрузки)


Чтобы задействовать все сервера кластера, нужно научить VRRP-мастер, на сетевом интерфейсе которого прописан VIP, не только принимать трафик для своих локальных сервисов, но и направлять часть трафика на остальные сервера. Демон keepalived как раз умеет это делать.


Отредактируйте конфиг keepalived.conf, приведя его к следующему виду:


/etc/keepalived/keepalived.conf
global_defs {    enable_script_security}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }}virtual_server 10.2.1.5 53 {    protocol UDP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.2 53 {        DNS_CHECK {            type txt            name health.load.balance.        }    }    real_server 10.2.1.3 53 {        DNS_CHECK {            type txt            name health.load.balance.        }    }}virtual_server 10.2.1.5 53 {    protocol TCP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.2 53 {        TCP_CHECK {            connect_timeout 3        }    }    real_server 10.2.1.3 53 {        TCP_CHECK {            connect_timeout 3        }    }}

Начало конфигурации аналогично предыдущему варианту без балансировки, только из блока vrrp_instance исчез track_script, соответственно за ненадобностью был удален блок vrrp_script.


Главное отличие в новой конфигурации заключается в блоках virtual_server. Для DNS требуется 2 виртуальных сервера, для 53-го порта TCP и для 53-го порта UDP. В случае HTTP-сервера аналогично потребуются сервера для 80-го и 443-го портов TCP.


Каждый виртуальный сервер идентифицируется 3 значениями: IP, порт и протокол. IP и порт через пробел указываются в заголовке блока virtual_server, а протокол определяется параметром protocol внутри блока. Допустимые протоколы TCP и UDP. В случае DNS как раз нужны оба.


Параметр delay_loop задает периодичность, с которой балансировщик опрашивает бэкенды для определения их состояния.


Самые важные параметры в виртуальном сервере это lvs_sched и lvs_method. lvs_sched задает алгоритм, по которому балансировщик определяет, куда отправить очередной IP-пакет. lvs_method задает механизм, который использует балансировщик для направления пакетов в выбранный пункт назначения.


В приведенном примере lvs_sched равен rr, что означает round robin, т. е. балансировка равномерно по очереди. lvs_method используется NAT. Кроме NAT доступны также механизмы DR (direct routing) и TUN (tunneling). На мой взгляд, NAT единственный рабочий вариант. Остальные методы работают только в очень специфических условиях.


Каждый виртуальный сервер состоит из нескольких реальных серверов, что отражено в соответствующих вложенных блоках real_server. Внутри блока real_server надо описать способ опроса его состояния, т. е. healthcheck.


После такой настройки keepalived работает следующим образом:


  1. Принимает IP-пакет с адресом получателя равным VIP.
  2. Выбирает real_server, куда необходимо направить пакет, анализируя протокол, порт, lvs_sched и результаты healthcheck-ов.
  3. Заменяет в IP-пакете адрес получателя на IP-адрес выбранного реального сервера и отправляет его дальше.

Только для работы этого недостаточно. Выбранный реальный сервер отправит ответный IP-пакет, в котором адрес отправителя будет равен его собственному IP-адресу. Клиент дропнет такой пакет, потому что он отправлял запрос на VIP и ожидает ответы от VIP, а не с IP-адреса реального сервера.


Чтобы решить эту проблему, нужно заставить реальный сервер отправить ответ не на IP клиента, а на IP мастера, чтобы тот выполнил обратную подстановку реального IP на виртуальный.


Для этого понадобится itpables и некоторые настройки ядра.


dnf -y install iptables iptables-servicessystemctl enable iptablessystemctl start iptables

echo "net.ipv4.ip_forward=1" >>/etc/sysctl.d/99-sysctl.confecho "net.ipv4.vs.conntrack=1" >>/etc/sysctl.d/99-sysctl.confsysctl -w net.ipv4.ip_forward=1sysctl -w net.ipv4.vs.conntrack=1

Добавьте в iptables следующее правило:


iptables -t nat -I POSTROUTING 1 -d 10.2.1.0/24 -j SNAT --to-source 10.2.1.5service iptables save

Действие SNAT означает, что после маршрутизации в IP-пакете IP-адрес источника будет заменен на IP-адрес to-source. Вместо SNAT можно также использовать действие MASQUERADE, которое делает то же самое, только определяет исходящий IP автоматически.


Поскольку были внесены изменения в такие вещи как iptables и параметры ядра, рекомендуется перезагрузить сервер и убедиться, что ничего из этого не потерялось.


Выполните описанные действия на обоих серверах кластера. Проверьте логи и статусные файлы. Если ошибок нет, то выполните проверку работы кластера способом, описанным выше. Теперь должен получиться вот такой вывод:


"=nameserver-1=""=nameserver-2=""=nameserver-1=""=nameserver-2=""=nameserver-1="

Поскольку в балансировщике задан алгоритм round robin, то сервера отвечают строго по очереди друг за другом.


Остановите named на 2-м сервере, и получите:


"=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-1=""=nameserver-1="

Снова запустите на 2-м сервере named, и на клиенте снова начнется чередование ответов.


Не забудьте про корректировку политик selinux, о которой рассказано выше.


Поздравляю. Только что мы с вами прошли 2-й уровень кластеризации.


Теперь наш кластер не только отказоустойчивый, но и масштабируемый.


Тем не менее, данная конструкция имеет и большой минус. Из-за трансляции адресов на подчиненные сервера запросы приходят с VIP, и невозможно по логам определить, какой запрос от какого клиента пришел. Возможность вычислить клиента по IP очень полезна для решения различных проблем. Поэтому, мой совет не останавливаться на 2-м уровне и, по возможности, перейти на 3-й.


Уровень 3 (Expert)


3-й уровень кластеризации подразумевает, что вы уже находитесь на 2-м, и все у вас работает как надо. Необходимо только обеспечить проброс клиентского IP-адреса до реальных серверов.


Принцип проброса следующий: все пакеты, приходящие на сервер, содержат IP реального клиента, а ответы на них отправляются на VIP. Т. е. VIP для реального сервера является шлюзом по умолчанию. Причем на этот шлюз направляются даже те пакеты, получатель которых находится в локальной подсети.


Но у серверов уже есть шлюз по умолчанию, и заменить его нельзя. Если убрать стандартный шлюз по умолчанию, то балансировка может быть и будет работать, однако все остальное сетевое взаимодействие у сервера сломается, и на него нельзя будет даже зайти по SSH.


Решение заключается в создании на сервере 2-го сетевого интерфейса. На 1-м сетевом интерфейсе будет производиться стандартный сетевой обмен, а на 2-м как раз и будет настроен VIP в качестве шлюза по умолчанию. Соответственно, у серверов вместе с дополнительным сетевым интерфейсом должен будет появиться и дополнительный IP-адрес.


Итак, добавьте на сервера кластера дополнительные сетевые интерфейсы и назначьте им IP-адреса.


Соберите информацию, необходимую для дальнейшей настройки. В нашем примере будут использоваться следующие значения:


Параметр Возможное значение Описание
vip 10.2.1.5 виртуальный IP, на который шлют запросы клиенты
dev0 eth0 1-й сетевой интерфейс на узлах кластера
dev1 eth1 2-й сетевой интерфейс на узлах кластера
ip01 10.2.1.2 IP 1-го узла кластера на 1-м сетевом интерфейсе
ip02 10.2.1.3 IP 2-го узла кластера на 1-м сетевом интерфейсе
ip11 10.2.1.6 IP 1-го узла кластера на 2-м сетевом интерфейсе
ip12 10.2.1.7 IP 2-го узла кластера на 2-м сетевом интерфейсе
net0 10.2.1.0/24 подсеть, которой принадлежат ip01 и ip02

Скорректируйте конфигурацию keepalived по указанному образцу.


/etc/keepalived/keepalived.conf
global_defs {    enable_script_security}vrrp_instance VI_1 {    state BACKUP    interface eth0    virtual_router_id 5    priority 100    advert_int 1    nopreempt    notify /etc/keepalived/keepalived-notify.sh root    authentication {        auth_type PASS        auth_pass KPSjXfRG    }    virtual_ipaddress {        10.2.1.5    }}virtual_server 10.2.1.5 53 {    protocol UDP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.6 53 {        DNS_CHECK {            connect_ip 10.2.1.2            type txt            name health.load.balance.        }    }    real_server 10.2.1.7 53 {        DNS_CHECK {            connect_ip 10.2.1.3            type txt            name health.load.balance.        }    }}virtual_server 10.2.1.5 53 {    protocol TCP    delay_loop 10    lvs_sched rr    lvs_method NAT    real_server 10.2.1.6 53 {        TCP_CHECK {            connect_ip 10.2.1.2            connect_timeout 3        }    }    real_server 10.2.1.7 53 {        TCP_CHECK {            connect_ip 10.2.1.3            connect_timeout 3        }    }}

От предыдущей конфигурации новая отличается тем, что для реальных серверов указаны IP с дополнительных сетевых интерфейсов, но healthcheck-и отправляются на IP основных сетевых интерфейсов. Обратите внимание на этот момент. Все сервера кластера опрашивают друг друга, но на дополнительных сетевых интерфейсах будут настроены маршруты на VIP, поэтому узлы, которые сейчас в состоянии BACKUP, не смогут получить ответ от новых IP-адресов.


Теперь необходимо прописать правильные маршруты для дополнительных сетевых интерфейсов.


Добавьте в файл /etc/iproute2/rt_tables 2 новых таблицы маршрутизации. В примере ниже добавлены таблицы table0 и table1.


/etc/iproute2/rt_tables
## reserved values#255     local254     main253     default0       unspec## local##1      inr.ruhep20      table021      table1

По документации к NetworkManager и CentOS 8 статические маршруты и правила следует помещать в файлы /etc/syconfig/network-scripts/route-eth0 и rule-eth0. На многих моих серверах именно так и сделано. Только почему-то на серверах, поднятых из одного и того же образа, формат этих файлов оказался разным. На большинстве серверов route-eth0 выглядит так:


route-eth0 здорового человека
192.168.1.0/24 via 192.168.1.1172.10.1.0/24 via 172.10.1.1

но почему-то на моих серверах DNS эти же файлы содержат вот это:


route-eth0 курильщика
ADDRESS0=192.168.1.0NETMASK0=255.255.255.0GATEWAY0=192.168.1.1ADDRESS1=172.10.1.0NETMASK1=255.255.255.0GATEWAY1=172.10.1.1

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


Поскольку сохранить маршруты в специальных системных файлах не удалось, пришлось сделать костыль.


/etc/keepalived/routes.sh
#!/bin/sh# https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.htmlvip="10.2.1.5"dev0="eth0"ip0="10.2.1.2" # "10.2.1.3"dev1="eth1"ip1="10.2.1.6" # "10.2.1.7"ip route add 10.2.1.0/24 dev "$dev0" src "$ip0" table table0ip route add default via 10.2.1.1 table table0ip rule add from "$ip0" table table0ip route add "$vip/32" dev "$dev1" src "$ip1"ip route add default via "$vip" table table1ip route add "$vip/32" dev "$dev1" src "$ip1" table table1ip rule add from "$ip1" table table1

В комментарии в скрипте указаны значения, которые надо скорректировать при переносе скрипта на другой сервер.


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


systemctl edit keepalived

[Service]ExecStartPre=/etc/keepalived/routes.sh

Не самое элегантное решение, но работает нормально, поэтому можете спокойно использовать, если не знаете, как можно сделать лучше.


Принципы задания правил маршрутизации описаны в Linux Advanced Routing & Traffic Control HOWTO. Идея заключается в том, что создается 2 независимые таблицы маршрутизации, в каждой свой шлюз по умолчанию. В зависимости от того, с какого сетевого интерфейса отправляется пакет, с помощью правил ip rule выбирается либо одна таблица, либо другая.


Удалите из iptables правило SNAT в цепочке POSTROUTING, добавленное при прохождении 2-го уровня. Сохраните состояние iptables.


iptables -t nat -D POSTROUTING -d 10.2.1.0/24 -j SNAT --to-source 10.2.1.5service iptables save

Проверьте результат. Клиент должен получать ответы от каждого сервера поочередно, в логах на серверах должны писаться реальные IP клиентов.


Теперь имеется отказоустойчивый кластер, в котором все живые узлы принимают нагрузку и видят IP-адреса своих клиентов. Единственный небольшой минус у этой конфигурации заключается в том, что есть 1 скрипт, который на разных серверах должен иметь разные параметры. Небольшое усложнение администрирования, которое с лихвой окупается полученными преимуществами.


Сложность Масштабирование Единые настройки IP клиента
Уровень 1 Easy Нет Да Да
Уровень 2 Normal Да Да Нет
Уровень 3 Expert Да Нет Да
Подробнее..

Пошаговая стратегия или установка Entware и DNSCrypt на модемы Zyxel Keenetic

10.05.2021 02:20:41 | Автор: admin

Что понадобится и предварительные действия

  • ZyXEL Keenetic с USB-портом, любой кроме моделей 4GII/III - одна штука

  • Usb Flash - одна штука

Флешка может быть любой. В моем случае это поддельный Kingston, в котором из 8Гб реально нашлось только 256Мб

Проверяем версию прошивки в дешбоарде. Для установки Entware нужна версия прошивки NDMS v2.07 (2.08) и выше. Если у вас она такова - сразу переходите к пункту 2. Установка Entware

Мой опытный образец Zyxel Keenetic DSL с прошивкой 2.05. Без повышения версии прошивки установка Entware на нём преждевременно прекращается с сообщением Opkg::Manager: /opt/etc/init.d/doinstall: FATAL: kernel too old.

Поэтому

  1. Обновляем прошивку на версию 2.11 из канала legacy

    1. Соединяемся с роутером
      telnet your_router_ip
      вводим логин/пароль админ юзера

    2. Переключаем канал на legacy:
      components sync legacy - для прошивок до 2.06
      components list legacy - для прошивок 2.06 и выше

    3. В веб-интерфейсе идем System -> Update
      Проверяем, что в поле "Use" появилось значение "Debug version". Жмем кнопку "Update" и ждём.

    4. После установки модем ребутнётся. Проверяем в дешбоарде версию.
      NDMS version: 2.11.D.9.0-1 - Значит, всё получилось.

  2. Установка Entware

    1. Качаем установщик для Keenetic DSL, LTE, VOX, DSL (KN-2010), DUO (KN-2110) ( http://bin.entware.net/mipssf-k3.4/installer/mips-installer.tar.gz)
      для остальных интернет-центров Keenetic - mipsel-installer.tar.gz

    2. Берём любую чистую флешку. Я форматировал в FAT32. У флешки обязательно должна быть метка тома (любая, кроме пустой). Вставляем её в роутер.

    3. Проверяем что в System->Update установлены компоненты FTP и OPKG. Если нет - устанавливаем

    4. Если у вас еще не настроен FTP, то заходим в Applications->FTP, включаем FTP сервер, разрешаем анонимный доступ (или не разрешаем, тогда нужно указать, каким пользователям роутера разрешено пользоваться FTP)

    5. Заходим по FTP на роутер (анонимно или нет - см п 2.4), далее в каталог с именем метки нашей флешки (cм п 2.2)

    6. Создаём каталог install и заходим в него

    7. Копируем установщик из п 2.1 в каталог install

    8. Заходим в Applications->OPKG, Ставим галку "Enable", в "Use external storage" выбираем метку нашей флешки, жмём кнопку "Apply"

    9. Переходим в System->Log, ждём сообщения
      "installer[5/5] Установка системы пакетов "Entware" завершена! Не забудьте сменить пароль и номер порта!"
      Теперь можно логиниться на порт 22 или 222 с логином root и паролем keenetic
      Не забываем сменить пароль и номер порта ;)
      порт - в файле /opt/etc/config/dropbear.conf
      пароль - командой passwd

    10. Если FTP сервер не нужен - не забываем его выключить.
      Ну, по крайней мере, закрыть анонимный доступ :)

  3. Установка DNSCrypt2
    Проверяем DNS на утечку перед установкой (в данном случае утечка - это когда ваш браузер лазит к вашему провайдеру чтобы резолвить DNS. И это пока еще нормально, но скоро мы от этого вылечимся)
    https://dnsleaktest.com/
    https://browserleaks.com/dns
    https://whatleaks.com/
    или аналогичные

    1. Заходим в Entware по SSH

    2. Устанавливаем DNSCrypt2
      opkg update
      opkg install dnscrypt-proxy2

    3. Устанавливаем немного дополнительных пакетов
      opkg install ca-certificates cron iptables

    4. Редактируем /opt/etc/dnscrypt-proxy.toml
      нас интересует строка
      listen_addresses = ['127.0.0.1:53']
      разрешаем слушать любые адреса:
      listen_addresses = ['0.0.0.0:53']

    5. Стартуем DNSCrypt2
      /opt/etc/init.d/S09dnscrypt-proxy2 start

    6. Подменяем DNS резолвер прошивки
      ВНИМАНИЕ! Здесь мы подключаемся к роутеру через telnet (не в Entware по SSH) - см п 1.1 и там выполняем
      opkg dns-override
      system configuration save

    7. Идём в вебморду Home Network -> Segments
      Ищем сегмент со своим Wifi подключением, редактируем в секцию DHCP server: прописываем в
      DNS 1 IP роутера
      DNS 2 оставляем пустым

    8. Идем в вебморду Internet -> Connections Выбираем своё исходящее подключение: прописываем в
      DNS 1 IP роутера
      DNS 2 и 3 оставляем пустыми

    9. Идем в вебморду Internet -> Extra Проверяем, чтобы в секции DNS servers не было никаких других серверов кроме IP нашего роутера. Если есть - удаляем.

    10. Переподключаемся к роутеру (по WiFi или проводу) Заодно перепроверяем настройки подключения к роутеру своих устройств, чтобы в них не было принудительно установленных DNS-серверов

    11. Здесь всё (почти работает). Но утечки всё еще возможны. Поэтому мы сейчас запретим весь трафик, который уходит наружу через 53 порт.
      Для чего логинимся в Entware по ssh и создаем скрипт
      /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh

      ВНИМАНИЕ!
      Замените 10.1.1.1 на IP вашего роутера

      #!/bin/sh
      [ "$type" == "ip6tables" ] && exit 0
      [ "$table" != "nat" ] && exit 0
      [ -z "$(iptables -nvL -t nat | grep "to:10.1.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.1.1.1:53
      exit 0

      Это можно сделать, например, вот так:

      ВНИМАНИЕ! Замените 10.1.1.1 на IP вашего роутера

      echo -e '#!/bin/sh\n[ "$type" == "ip6tables" ] && exit 0\n[ "$table" != "nat" ] && exit 0\n[ -z "$(iptables -nvL -t nat | grep "to:10.1.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 10.1.1.1:53\nexit 0' >> /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh

    12. Делаем 10-ClientDNS-Redirect.sh исполняемым:
      chmod +x /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh

    13. Ребутим роутер (без этого пункта https://browserleaks.com/dns периодически светил мои родные DNS сервера)

    14. Проверяемся на утечки.

Отныне используемые DNS сервера будут находится рандомно по всему миру, а трафик к ним будет шифроваться.

Ссылки по теме

https://forum.keenetic.net/announcement/5-где-взять-тестовые-сборки/ https://help.keenetic.com/hc/ru/articles/115002060049
https://forum.keenetic.net/topic/4299-entware/?do=findComment&comment=50640
https://forum.keenetic.net/topic/4755-защищаем-dns-запросы-с-помощью-dnscrypt-proxy2-бонусом-блокировка-рекламы/

Подробнее..

Перевод Инструмент для отслеживания DNS-запросов dnspeep

07.05.2021 18:23:01 | Автор: admin

Недавно я создала небольшой инструмент под названием dnspeep, который позволяет понять, какие DNS-запросы отправляет ваш компьютер и какие ответы он получает. Всего мой код занял 250 строк на Rust. В этой статье я расскажу о коде, объясню, для чего он нужен, почему в нём возникла необходимость, а также расскажу о некоторых проблемах, с которыми я столкнулась при его написании. И, конечно, вы сами сможете попробовать код в действии.


Что нужно для начала работы с кодом

Чтобы было удобнее работать с кодом, я подготовила несколько бинарных файлов.

Команды для Linux (x86):

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-linux.tar.gztar -xf dnspeep-linux.tar.gzsudo ./dnspeep

Команды для Mac:

wget https://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-macos.tar.gztar -xf dnspeep-macos.tar.gzsudo ./dnspeep

Коду необходим доступ ко всем отправляемым компьютером пакетам DNS, поэтому его необходимо запускать от имени root. По этой же причине утилиту tcpdump также нужно запускать от имени root: код использует libpcap ту же библиотеку, что и tcpdump. Если вам по какой-либо причине не захочется загружать бинарные файлы и запускать их от имени root, вы можете воспользоваться моим исходным кодом и создать на его основе собственный.

Что получается в результате

Каждая строка представляет собой DNS-запрос и соответствующий запросу ответ.

$ sudo dnspeepquery   name                 server IP      responseA       firefox.com          192.168.1.1    A: 44.235.246.155, A: 44.236.72.93, A: 44.236.48.31AAAA    firefox.com          192.168.1.1    NOERRORA       bolt.dropbox.com     192.168.1.1    CNAME: bolt.v.dropbox.com, A: 162.125.19.131

Эти запросы отражают мои визиты на сайт neopets.com в браузере, а запрос bolt.dropbox.com возник потому, что у меня запущен агент Dropbox, и, как я полагаю, время от времени он заходит на свой сайт для синхронизации.

Зачем создавать ещё один инструмент DNS?

Я считаю, что в таком инструменте есть смысл, так как с его помощью можно лучше представить, как работает DNS без этого инструмента довольно сложно понять, как ведёт себя DNS на компьютере.

Ваш браузер (и другие компьютерные программы) постоянно отправляет DNS-запросы. Если знать, какие запросы отправляет компьютер и какие ответы он получает, можно получить более реальную картину "жизни" компьютера.

Написанный мною код я также использую как инструмент отладки. На вопросы типа: "А не связана ли моя проблема с DNS?" ответить иногда бывает довольно сложно. Пользователи, не зная всей информации, зачастую, чтобы найти проблему, используют метод проб и ошибок или просто строят догадки, хотя, казалось бы, стоит просто проанализировать ответы на получаемые компьютером DNS-запросы, и проблема будет решена.

Можно увидеть, какое программное обеспечение "тайно" выходит в Интернет

Мне нравится в этом инструменте, что он даёт представление о том, какие программы моего компьютера пользуются Интернетом! Например, я обнаружила, что какая-то утилита на моём компьютере время от времени по непонятной причине отправляет запросы на ping.manjaro.org, вероятно, чтобы проверить, подключён ли мой компьютер к Интернету.

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

Если вы раньше не работали с tcpdump, поначалу может быть непонятно, что делает эта утилита

Рассказывая людям об отправляемых с компьютера DNS-запросах, я почти всегда хочу добавить: "Всю информацию можно получить через tcpdump!" Что делает утилита tcpdump? Она осуществляет разбор пакетов DNS! Например, вот как выглядит DNS-запрос incoming.telemetry.mozilla.org.:

11:36:38.973512 wlp3s0 Out IP 192.168.1.181.42281 > 192.168.1.1.53: 56271+ A? incoming.telemetry.mozilla.org. (48)11:36:38.996060 wlp3s0 In  IP 192.168.1.1.53 > 192.168.1.181.42281: 56271 3/0/0 CNAME telemetry-incoming.r53-2.services.mozilla.com., CNAME prod.data-ingestion.prod.dataops.mozgcp.net., A 35.244.247.133 (180)

Сначала эта информация может показаться "тёмным лесом", но её при некоторых навыках можно научиться читать. Давайте для примера разберём такой запрос:

192.168.1.181.42281 > 192.168.1.1.53: 56271+ A? incoming.telemetry.mozilla.org. (48)
  • A? означает DNS-запрос типа A;

  • incoming.telemetry.mozilla.org. это имя объекта, к которому осуществляется запрос;

  • 56271 это идентификатор DNS-запроса;

  • 192.168.1.181.42281 исходный IP/порт;

  • 192.168.1.1.53 IP/порт назначения;

  • (48) длина DNS-пакета.

Ответ выглядит следующим образом:

56271 3/0/0 CNAME telemetry-incoming.r53-2.services.mozilla.com., CNAME prod.data-ingestion.prod.dataops.mozgcp.net., A 35.244.247.133 (180)
  • 3/0/0 количество записей в ответе: 3 ответа, 0 полномочий, 0 дополнительно. Исходя из моего опыта, tcpdump выводит только количество ответов на запрос.

  • CNAME telemetry-incoming.r53-2.services.mozilla.com, CNAME prod.data-ingestion.prod.dataops.mozgcp.net. и A 35.244.247.133 это те самые три ответа

  • 56271 идентификатор ответов, соответствующий идентификатору запроса. По этому идентификатору можно понять, что это ответ на запрос из предыдущей строки.

С таким форматом, конечно, работать довольно сложно, ведь человеку нужно просто посмотреть на трафик DNS, к чему все эти нагромождения? И вот ему приходится вручную сопоставлять запросы и ответы, к тому же не всегда находящиеся на соседних строках. Здесь в дело вступают компьютерные возможности!

Я решила написать небольшую программку dnspeep, которая будет сама выполнять такое сопоставление, а также удалять определённую (на мой взгляд, лишнюю) информацию.

Проблемы, с которыми я столкнулась при написании кода

При написании кода я столкнулась с рядом проблем.

  • Мне пришлось несколько изменить библиотеку pcap, чтобы заставить её правильно работать с Tokio на Mac OS вот эти изменения. Это была одна из тех ошибок, на поиск которой ушло много часов, а всё исправление уложилось в одну строку.

  • Разные дистрибутивы Linux, по всей видимости, используют разные версии libpcap.so, поэтому мне не удалось воспользоваться непосредственно бинарным файлом, динамически компонующим libpcap (у других пользователей возникала такая же проблема, например здесь). Поэтому компилировать библиотеки libpcap в инструмент на Linux мне пришлось статически. Я до сих пор не понимаю, как такое правильно организовать на Rust, но я добилась, чего хотела, и всё заработало я скопировала файл libpcap.a в каталог target/release/deps, а затем просто запустила cargo build.

  • Используемая мною библиотека dns_parser поддерживает не все типы DNS-запросов, а только некоторые самые распространённые. Возможно, для разбора DNS-пакетов можно было использовать другую библиотеку, но я не нашла подходящей.

  • Поскольку интерфейс библиотеки pcap выдает набор "голых" байтов (в том числе для данных Ethernet-фреймов), мне пришлось написать код, который определял, сколько байтов нужно отсечь от начала строки, чтобы получить IP-заголовок пакета. Но я уверена, что в моей задаче ещё остались "подводные камни".

Кстати, вы даже не представляете, каких сложностей мне стоило подобрать название для своей утилиты ведь инструментов для работы с DNS великое множество, и у каждого своё название (dnsspy! dnssnoop! dnssniff! dnswatch!) Сначала я хотела включить в название слово spy (шпион) или его синонимы, а затем остановилась на показавшемся мне забавным названии, которое о чудо! ещё никто не занял для собственного DNS-инструмента.

У моей утилиты есть один недостаток: она не сообщает, какой именно процесс отправил DNS-запрос, но выход есть используйте инструмент dnssnoop. Этот инструмент работает с данными eBPF. Судя по описанию, он должен работать нормально, но я его ещё не пробовала.

В моём коде наверняка ещё много ошибок

Мне удалось его протестировать только на Linux и Mac, и я уже знаю как минимум об одной ошибке (из-за того, что поддерживаются не все DNS-запросы). Если найдёте ошибку, пожалуйста, сообщите мне!

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

Мне нравится составлять небольшие учебные материалы

В последнее время я получаю огромное удовольствие от написания небольших учебных материалов по DNS. Вот ссылки на мои предыдущие статьи:

  • Простой способ составления DNS-запросов;

  • Рассказывается, что происходит внутри компьютера при отправке DNS-запроса;

  • Ссылка на dnspeep.

Ранее в своих постах я просто объясняла, как работают существующие инструменты (например dig или tcpdump), а если и писала собственные инструменты, то довольно редко. Но сейчас для меня очевидно, что выходные данные этих инструментов довольно туманны, их сложно понять, поэтому мне захотелось создать более дружественные варианты просмотра такой информации, чтобы не только гуру tcpdump, но любые другие пользователи могли понять, какие DNS-запросы отправляет их компьютер.

А если вы хотите не только понимать, что происходит с запросами и ответами DNS на вашем компьютере, но и писать собственные протоколы для своих приложений, обратите внимание на профессии C++ разработчик или Java-разработчик, позволяющие с нуля освоить эти языки или прокачать своё владение ими. Приходите опытные менторы и эксперты своего дела с удовольствием поделяться с вами своими знаниями.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Настройка собственного почтового сервера

26.02.2021 20:18:58 | Автор: admin

Есть три основных шага, чтобы установить и настроить собственный почтовый сервер.

  • Настройка IP и DNS

  • Выбор и запуск приложения почтового сервера

  • Добавление своего почтового сервера в белые списки

Настройка IP и DNS

Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR

Это основные требования для запуска собственного почтового сервера.

  • Публичный статический IP-адрес
    IP-адрес почтового сервера должен быть общедоступным и постоянным во времени. Убедиться в этом можно у хостинг или Интернет-провайдера.

  • Доменное имя указывает на IP
    DNS-запись публичного доменного имени почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS провайдера доменного имени.

  • IP указывает на доменное имя
    Самое главное, обратная DNS-запись (именуемая PTR) должна указывать на доменное имя почтового сервера по IP-адресу. Можно попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его. Его можно легко проверить по IP-адресу онлайн (например, тут), или с помощью команды nslookup в Windows и команды host в системах на основе UNIX.

Настройка MX записи в DNS

Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.

Например, если наш домен - mycompany.com, почтовый сервер - mail.mycompany.com, то запись DNS для mycompany.com будет:

Type

Host

Value

Priority

TTL

MX

@

mail.mycompany.com

10

1 min

где:

  • Priority (приоритет) используется, когда в домене более одного почтового сервера.

  • TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при отладке настроек.

Настройка DKIM записи в DNS

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

Понадобятся приватный и открытый ключи. Их можно создать с помощью онлайн-инструментов, например Power DMARC Toolbox - DKIM Record Generator, или с помощью команд OpenSSL (приведен пример для Windows):

  • Создать приватный ключ
    openssl.exe genrsa -out private.key 2048

  • Создать публичный ключ из приватного
    openssl.exe rsa -in private.key -pubout -outform der 2>nul | openssl base64 -A > public.key.txt

И запись DNS будет выглядеть так:

Type

Host

Value

TTL

TXT

selector._domainkey

v=DKIM1; k=rsa; p=public_key

1 min

где:

  • selector - самостоятельно выбранный идентификатор (например, mysrv), который будет использоваться в приложении почтового сервера (смотрите ниже).

  • public_key - открытый ключ, закодированный алгоритмом base64 (содержимое public.key.txt).

  • TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Настройка SPF записи в DNS

Инфраструктура политики отправителя (SPF) это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.

Тут запись DNS будет выглядеть так:

Type

Host

Value

TTL

TXT

@

v=spf1 a mx include:relayer_name -all

1 min

где:

  • relayer_name - имя необязательного внешнего почтового сервера-ретранслятора (смотрите ниже). Если не нужно - убирается вместе с "include:".

  • TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Можно использовать удобный онлайн-генератор записи SPF.

Дополнительные записи DNS

Некоторые поля не обязательны, но желательно иметь.

  • DMARC
    Запись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.

  • BIMI
    Индикаторы бренда для идентификации сообщений (BIMI) это новый стандарт, созданный для того, чтобы упростить отображение логотипа рядом с сообщением. Кроме того, BIMI предназначен для предотвращения мошеннических электронных писем и улучшения доставки.

  • TLS-RPT
    TLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.

Все эти записи могут быть созданы с помощью Power DMARC Toolbox.

Выбор и запуск приложения почтового сервера

Конечно, хостинг должен позволять устанавливать программное обеспечение. Можно использовать любое подходящее приложение для почтового сервера. Например, есть бесплатный hMailServer для Windows, который предоставляет все необходимые функции с минимальным использованием ресурсов. Для систем на базе UNIX существует множество бесплатных почтовых серверов, таких как Exim Internet Mailer или iRedMail.

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

Инициализация

Когда программное обеспечение выбрано и установлено, самое время его настроить.

  • Домен и пользователи
    Нужно добавить домен и начальный набор пользователей почтового сервера.

  • Безопасность
    Чтобы обеспечить соответствующий уровень безопасности, мы должны добавить сертификат SSL для домена.

  • Подпись сообщений
    Далее, следует настроить DKIM. Нужно указать полученные выше приватный ключ и селектор. Кроме того, методы заголовка и тела должны быть установлены на расслабленный, алгоритм подписи должен быть установлен на SHA256, иначе на некоторых SMTP серверах не проходит проверка (например, google).

  • Защита от спама
    Наконец, нужно настроить антиспам-проверку специальными узлами черных списков, такими как spamhaus.org, чтобы защитить пользователей почтового сервера от нежелательных сообщений.

Протоколы электронной почты

Нужно настроить три протокола электронной почты, которые необходимы для её отправки и получения.

SMTP

SMTP используется для приема входящей и исходящей почты с/на другие почтовые серверы. И это позволяет пользователям домена отправлять свои сообщения.

  • 25 порт
    Этот порт необходим для управления входящими подключениями от других почтовых серверов. Метод безопасности следует установить в STARTTLS.

  • 587 порт
    Он нужен для почтовых клиентов собственного почтового сервера. Метод безопасности следует установить в STARTTLS.

  • 465 порт
    Он не является официальным и может потребоваться для старых почтовых клиентов. И метод безопасности следует установить в SSL/TLS.

POP3, IMAP

POP3 и IMAP используются отдельными почтовыми клиентами, такими как Outlook на ПК или любой почтовый клиент на мобильных телефонах. Это позволяет пользователям домена управлять своими сообщениями.

Порт 993 следует использовать для защищенных соединений IMAP, а порт 995 - для POP3. Для обеспечения совместимости с большинством клиентов метод безопасности следует установить в SSL/TLS (не STARTTLS).

Также можно настроить порты 143 для IMAP и 110 для POP3, но они не шифруются и сейчас их уже мало кто использует.

Проверка

Итак, когда все настроено, нужно протестировать почтовый сервер, отправив письмо кому-нибудь из списка пользователей. Кроме того, в некоторых почтовых приложениях есть функция самодиагностики (см. ниже пример от hMailServer).

Теперь пора проверить отправку на внешний адрес.

Аккаунт Gmail.com

Если есть учетная запись Gmail.com (что наверняка), можно отправить тестовое письмо на свой адрес Gmail. Затем открываем свою электронную почту в браузере и нажимаем Показать подробности.

Если есть подписано: домен, подпись DKIM настроена правильно. Если есть отправлено по почте: домен, SPF в порядке.

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

Также, в Outlook можно видеть те же заголовки в свойствах сообщения.

Специальные онлайн-сервисы

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

  • AppMailDev
    Этот сервис позволяет тестировать конфигурацию почтового сервера, такую как DKIM и SPF, отправляя электронное письмо на указанный сгенерированный почтовый адрес. Нужно просто следовать инструкциям на экране и результаты теста будут отображены там же.

  • DKIMValidator
    Предоставляет те же функции, что и предыдущая служба. Результаты тестирования будут отправлены на адрес отправителя.

  • HAD Email Auth Tester
    Чтобы проверить отправку сообщения здесь, нужно отправить специальное сообщение на tester@email-test.had.dnsops.gov. Результаты тестирования будут отправлены на адрес отправителя.

  • PowerDMARC
    Этот сервис предоставляет только облегченную проверку всех атрибутов, но у него есть удобные инструменты, указанные в ссылках выше.

Итак, если всё настроено правильно, но сервер присутствует в чёрных списках спама, нужно внести его в белый список.

Добавление почтового сервера в белые списки

Итак, если всё вышеперечисленное настроено правильно, другие почтовые серверы по-прежнему могут отмечать сообщения как спам и отклонять их. Это бывает, когда IP (или его диапазон) домена попадает в какой-то черный список. Чаще всего причиной этого является использование соседних IP-адресов для рассылки спам-сообщений.

Внесение в белый список в публичных источниках

Итак, сначала проверим IP (и, если необходимо, домен) онлайн на наличие в каких-либо черных списках. Его можно проверить в любом онлайн-чекере, который можно найти через поиск. Например, MXToolBox проверяет самые популярные черные списки. Также, multirbl.valli.org показывает много источников черного списка и доверие к каждому из них.

Затем нужно последовательно просмотреть каждый элемент в результатах и прочитать рекомендации о том, как внести IP-адрес в белый список в конкретном источнике черного списка. Но не все из них могут позволить это сделать бесплатно, например, немецкий UCEPROTECT-Network.

Кстати, на тут на habr обсуждалась автоматизация мониторинга IP в блэклистах.

Внесение в белый список определенных почтовых серверов

Некоторые серверы, такие как Outlook, имеют свои собственные черные списки. Проверка проста - приложение почтового сервера уведомит о неудачной доставке в почтовом клиенте. Большинство почтовых серверов предоставляют в ответе URL-адреса разблокировки. Таким образом, нужно открыть такой URL и следовать инструкциям, например, как этот.

Обход черных списков

Если какой-то официальный черный список не разрешает добавление в исключения или когда-нибудь почта перестает отправляться на определенный домен - можно использовать внешние службы ретрансляции SMTP. Они позволяют использовать их в качестве шлюзов (или прокси) при отправке почты.

  • MailerSend
    Один из самых дешевых - позволяет бесплатно отправлять 20 тысяч писем в месяц и имеет низкую стоимость дополнительной отправки. Но есть особенность: поля CC и BCC пока не поддерживаются.

  • SendInBlue
    Это еще один хороший сервис, который позволяет бесплатно отправлять 9 тысяч писем в месяц с лимитом 200 в день. Но есть нюансы: встроенное отслеживание электронной почты нельзя отключить и высоковатая цена сверх бесплатного лимита.

В каждой службе нужно зарегистрироваться и получить подтверждение почтового домена. После подтверждения, каждый из них дает указания на то, что должно быть настроено для DNS (DKIM, SPF и DMARK) и почтового приложения (адрес сервера ретрансляции SMTP, порт и учетные данные).

Заключение

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

Подробнее..

Суверенный DNS уже здесь, а вы и не заметили

03.03.2021 22:15:39 | Автор: admin

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

Совсем недавно, буквально "на днях", в новостях проскакивали сообщения о недоступности страницы публичного DNS от Cloudflare ( https://1.1.1.1 ) из сетей российских провайдеров, например, Ростелекома, что навело меня на мысль вернуться к изучению вопроса.

Быстрый поиск по профильным ресурсам связистов показал, что уже много месяцев происходит процесс осувереннивания российского сегмента сети. Например, Роскомнадзор строит свой аналог базы RIPE для российских провайдеров и пользователей интернета. И, внезапно, национальную систему доменных имён. На форуме НАГ попадался даже документ с инструкциями по перенастройке провайдерских DNS на суверенный манер, со страшным названием "Инструкция по подключению операторов связи и владельцев АС к Национальной системе доменных имен (НСДИ).

Беглое изучение этого документа приводит к следующим выводам: НСДИ уже активно применяется. В документе приводятся несколько вариантов использования НСДИ, в том числе с возможной подменой корневых DNS (см. статью в wikipedia). С большой вероятностью настройки DNS, которые выдает провайдер вашему устройству, уже используют НСДИ. Другой вывод: в настоящее время функционирование НСДИ обеспечивается мощностями MSK-IX , что следует из принадлежности IP адресов в "Инструкции".

На момент написания статьи сервера НСДИ отдают ту же информацию, что есть в файле root.hints в современных ОС (оригинал файла находится по адресу https://www.internic.net/domain/named.root ). У меня не сложилось однозначного понимания, как НСДИ поможет осуверенниванию и какие плюсы и минусы этого решения. Прошу прокомментировать тех, кто разобрался в вопросе глубже.

Подробнее..

Национальная система доменных имён первый взгляд

15.06.2021 10:13:02 | Автор: admin

С начала этого года в России стала эксплуатироваться Национальная Система Доменных Имён - НСДИ, о чём уже можно почитать на Хабр, а провайдерам и владельцем автономных систем РКН рассылает письма с требованиями к ней подключиться. По своей сути это набор из публичных DNS серверов, доступный всем желающим и предлагаемый к использованию как провайдерам так и конечным пользователям Интернет. К своему сожалению, я слабо представляю как конкретно организована и функционирует глобальная система доменных имён, или как организована работа серверов обслуживающих, например, зону RU., и надеюсь это статьёй, в том числе, привлечь внимание к этому вопросу людей которые в этом разбираются или участвуют в этом процессе - это должно быть очень интересно и познавательно, для того чтобы об этом рассказать всем. Поэтому мой первый взгляд будет про адресацию, маршрутизацию, задержки, для чего будет использованы, в том числе, средства RIPE Atlas, и, конечно, про DNS, но ровно настолько насколько я в этом понимаю. Отличительной особенностью именно этой национальной системы является её доступность для исследований, поэтому надеюсь мой первый взгляд, будет продолжен и подхвачен, чтобы рассмотреть этот вопрос со всех сторон.

Из уже упомянутой выше статьи по ссылкам можно найти оригинальное письмо РКН, из которого мы знаем что существуют:

  • 194.85.254.37 - корневой DNS сервер позволяющий, помимо прочего, выполнять запрос AXFR, то есть получать корневую зону "как есть", но для этого надо попасть в список доверенных серверов и такой возможности у меня нет

  • a.auth-nsdi.ru, b.auth-nsdi.ru - тоже корневые DNS, позволяющие не рекурсивно запрашивать записи из корневой зоны

  • a.res-nsdi.ru, b.res-nsdi.ru - рекурсивные резолверы, позволяющие запрашивать любую запись

Сразу обращу ваше внимание на то, что система находится в очень подвижном состоянии, как и положено любой системе на начальном этапе эксплуатации, да и вообще системе в Интернет. И дотошный читатель наверняка уже нашёл, что существуют, например, c.auth-nsdi.ru и d.auth-nsdi.ru, пока не отвечающие на запросы. Но это значит, что через пару месяцев или недель ситуация, как она описывается в этой статье, может поменяться кардинально. Помните об этом.

Корневые серверы

194.85.254.37 принадлежит блоку 194.85.254.0/24, который появился отдельной строчкой в RIR и тогда же стал анонсироваться в глобальную таблицу Интернет маршрутизации меньше года назад - в августе 2020 года, источником анонсов является AS62135. Отвечает на CHAOS TXT запросы:

  • version.bind - "PowerDNS Authoritative Server 4.4.0-alpha3.125.master.g6835270cd (built Nov 16 2020 18:13:24 by root@b6b5979d40d3)"

  • id.server - mu.cmu.msk-ix.ru

Есть поддержка NSID - "mu.cmu.msk-ix.ru", и насколько можно судить по данным RIPE Atlas этот сервер представлен в единственной точке присутствия в центральной европейской части России.

Расположение

NSID

Время ответа (мс)

Калининград

mu.cmu.msk-ix.ru

39,5

Санкт-Петербург

mu.cmu.msk-ix.ru

10,7

Ростов-на-Дону

mu.cmu.msk-ix.ru

19,1

Волжский

mu.cmu.msk-ix.ru

24,1

Самара

mu.cmu.msk-ix.ru

3,2

Казань

mu.cmu.msk-ix.ru

14,0

Пермь

mu.cmu.msk-ix.ru

20,4

Екатеринбург

mu.cmu.msk-ix.ru

25,4

Челябинск

mu.cmu.msk-ix.ru

32,2

Омск

mu.cmu.msk-ix.ru

44,3

Новосибирск

mu.cmu.msk-ix.ru

50,3

Чита

mu.cmu.msk-ix.ru

81,4

Хабаровск

mu.cmu.msk-ix.ru

101,9

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

a.auth-nsdi.ru и b.auth-nsdi.ru представлены в IPv4 и IPv6 и входят в блоки 195.208.6.0/24, 2a0c:a9c7:a::/48,195.208.7.0/24 и 2a0c:a9c7:b::/48, которые появились отдельными строчками в RIR и начали анонсироваться в конце осени, начале зимы 2020. Все от имени AS41740 c as-name NDNS. Всего с той же AS анонсируется 12 префиксов, которые мы ещё встретим дальше:

193.232.147.0/24, 193.232.253.0/24, 195.208.5.0/24, 195.208.4.0/24, 195.208.6.0/24, 195.208.7.0/24, 2a0c:a9c7:a::/48, 2a0c:a9c7:253::/48, 2a0c:a9c7:147::/48, 2a0c:a9c7:b::/48, 2a0c:a9c7:9::/48, 2a0c:a9c7:8::/48

Также поддерживается NSID и запрос CHAOS TXT id.version. На основе которых по отчётам RIPE Atlas (30376498, 30376499, 30376500, 30376501) можно сделать выводы что задействовано несколько точек присутствия и механизмы распределения трафика между ними.

Расположение

a.auth-nsdi.ru

b.auth-nsdi.ru

NSID

Время ответа (мс)

NSID

Время ответа (мс)

Калининград

IPv4/IPv6

auth1-spb.ix.ru, auth2-spb.ix.ru

28.3

auth1-khouse.ix.ru, auth2-khouse.ix.ru

36,6

auth1-khouse.ix.ru, auth2-khouse.ix.ru

40,0

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

41,3

Санкт-Петербург

IPv4/IPv6

auth1-spb.ix.ru, auth2-spb.ix.ru

1,4

auth2-spb.ix.ru, auth1-spb.ix.ru

1,3

auth2-kzn.ix.ru, auth1-kzn.ix.ru

76.4

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

229,0

Ростов-на-Дону

IPv4/IPv6

auth2-rnd.ix.ru, auth2-khouse.ix.ru, auth1-rnd.ix.ru, auth1-khouse.ix.ru

0,8

auth1-rnd.ix.ru, auth2-rnd.ix.ru, auth2-khouse.ix.ru

0,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-rnd.ix.ru, auth1-rnd.ix.ru

0,7

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-rnd.ix.ru

0,7

Волжский

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

23,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru

23,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru

21,3

auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

21,4

Самара

IPv4/IPv6

auth1-kzn.ix.ru, auth2-kzn.ix.ru

17,1

auth1-khouse.ix.ru, auth2-khouse.ix.ru

2,6

auth2-kzn.ix.ru, auth1-kzn.ix.ru

16,9

auth1-spb.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

5,4

Казань

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

13,6

auth1-khouse.ix.ru, auth2-khouse.ix.ru

13,6

auth2-kzn.ix.ru, auth1-kzn.ix.ru

91,8

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

244,4

Пермь

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

21,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru

21,1

auth1-khouse.ix.ru, auth2-khouse.ix.ru

19,2

auth1-nsk.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru

27,9

Екатеринбург

IPv4/IPv6

auth1-ekt.ix.ru, auth2-ekt.ix.ru

2,1

auth1-ekt.ix.ru, auth2-ekt.ix.ru

2,1

auth2-ekt.ix.ru, auth1-ekt.ix.ru

1,8

auth1-ekt.ix.ru, auth2-spb.ix.ru, auth2-ekt.ix.ru

1,8

Челябинск

IPv4/IPv6

auth1-ekt.ix.ru, auth2-ekt.ix.ru

4,0

auth1-khouse.ix.ru, auth2-khouse.ix.ru

30,3

auth2-kzn.ix.ru, auth1-kzn.ix.ru

58,1

auth1-nsk.ix.ru, auth2-khouse.ix.ru, auth2-nsk.ix.ru, auth2-vlv.ix.ru

116,2

Омск

IPv4/IPv6

auth2-khouse.ix.ru, auth1-khouse.ix.ru

43,8

auth1-khouse.ix.ru, auth2-khouse.ix.ru

43,7

auth1-khouse.ix.ru, auth2-khouse.ix.ru

38,5

auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-nsk.ix.ru

35,4

Новосибирск

IPv4/IPv6

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru

6,5

auth2-nsk.ix.ru, auth1-nsk.ix.ru, auth1-khouse.ix.ru

6,5

auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth1-nsk.ix.ru

6,6

auth1-nsk.ix.ru, auth2-rnd.ix.ru, auth2-nsk.ix.ru

6,6

Чита

IPv4/IPv6

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru, auth1-khouse.ix.ru

36,1

auth1-nsk.ix.ru, auth2-nsk.ix.ru, auth2-khouse.ix.ru

36,0

auth1-khouse.ix.ru, auth2-khouse.ix.ru

80,4

auth1-rnd.ix.ru, auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

81,0

Хабаровск

IPv4/IPv6

auth2-khouse.ix.ru, auth2-ekt.ix.ru, auth1-ekt.ix.ru, auth1-nsk.ix.ru, auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth1-vlv.ix.ru, auth2-nsk.ix.ru

34,5

auth2-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru

100,8

auth1-khouse.ix.ru, auth2-vlv.ix.ru, auth2-nsk.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-khouse.ix.ru

39.0

auth1-nsk.ix.ru, auth2-vlv.ix.ru, auth1-vlv.ix.ru, auth1-khouse.ix.ru, auth2-khouse.ix.ru, auth2-spb.ix.ru

100.9

Здесь мы уже видим подвижность. Несколько NSID в ответах в разное время, даже за не очень большой период сбора данных. Полужирным шрифтом отмечен последний из ответов NSID. Вторая ячейка это ответы на IPv6 запросы где тоже видим разницу по сравнению с IPv4. Что-то можно будет списать на отличную от IPv4 связность в IPv6, не всё ещё с этим в порядке, а где-то, вероятно, это особенности реализации, время ответов и выбор серверов, иногда, уж очень сильно отличаются. Впрочем, запросы к разным серверам НСДИ и разные NSID, даже в IPv4, могут возникнуть по причинам маршрутизации и связности в Интернет, а не по причинам изменений внутри НСДИ, но для этого нужен более детальный анализ нежели мы здесь приводим. Всего попалось 14 разных идентификатора, с говорящими названиями.

auth1-ekt.ix.ru, auth1-khouse.ix.ru, auth1-kzn.ix.ru, auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-ekt.ix.ru, auth2-khouse.ix.ru, auth2-kzn.ix.ru, auth2-nsk.ix.ru, auth2-rnd.ix.ru, auth2-spb.ix.ru, auth2-vlv.ix.ru

Несмотря на то, что у меня нет возможности сделать AXFR запрос и сравнить корневые зоны на идентичность Root Zone File, можно сделать обычные запросы по каждой из записей в корневой зоне и сравнить результаты. Несколько однострочников в Bash, чтобы убедиться что корневая зона отдаваемая серверами НСДИ идентична эталонной. В этом мне помогла одна особенность на которую я обратил внимание, возможно, присущую конкретной версии используемых серверов и которая касается DNSSEC и записей NSEC. Не все корневые серверы, возвращают эту запись по прямому запросу, а только в случае NXDOMAIN,корневые НСДИ серверы - возвращают. Таким образом задача решается одним запросом dig +dnssec для каждой строчки из Root Zone File с последующим сравнением. Совсем чуть-чуть придётся поработать с представлением отдаваемых данных, например, привести адреса IPv6 к одному формату, в эталонном файле они приводятся без применения правил сокращения, запретить dig форматировать base64 строчки +nosplit и ещё не забыть про IDN - +noidnout. Результат, насколько я могу судить, не отличается от эталонного. Конечно, интересно было бы следить за этим постоянно, измерять, например, задержки между публикациями зоны и распределением её по серверам НСДИ, но оставим это для следующих авторов.

Рекурсивные резолверы

a.res-nsdi.ru и b.res-nsdi.ru - тоже представлены в IPv4 и IPv6: 195.208.4.0/24, 2a0c:a9c7:8::/48,195.208.5.0/24 и 2a0c:a9c7:9::/48 уже знакомой нам AS41740. В анонсах появились также в конце 2020. Поддерживается только CHAOS TXT id.version, NSID - нет. Но так как это рекурсивные серверы то можно воспользоваться сервисом предоставляемым PowerDNS, чтобы определить с какого реального адреса был отправлен запрос. Это даёт нам технически более строгий способ, так как мы выявляем адреса непосредственно участвующие в запросах со стороны НСДИ, а не идентификаторы, которые можно менять без каких-либо последствий. Опять смотрим на RIPE Atlas (30376488, 30376489, 30376490, 30376491, 30376492, 30376493, 30376494, 30376495).

Расположение

a.auth-nsdi.ru

b.auth-nsdi.ru

Адрес запроса

Время ответа (мс)

Адрес запроса

Время ответа (мс)

Калининград

IPv4/IPv6

res1-spb-lb.ix.ru, res2-spb-lb.ix.ru

26,8

res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res1-khouse-lb.ix.ru

39,1

res2-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-khouse-lb.ix.ru, res2-khouse-lb.ix.ru

38,1

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

39,7

Санкт-Петербург

IPv4/IPv6

193.232.139.82, res1-rnd-lb.ix.ru, res1-spb-lb.ix.ru, res2-spb-lb.ix.ru

1,3

res1-khouse-lb.ix.ru ,res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

7,0

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru

81,5

193.232.139.82, res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

172,0

Ростов-на-Дону

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

17,2

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-rnd-lb.ix.ru

1,3

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

18,5

193.232.139.82, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

1,3

Волжский

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

23,3

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

23,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

21,3

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru, res2-spb-lb.ix.ru

21,5

Самара

IPv4/IPv6

res1-kzn-lb.ix.ru, res1-spb-lb.ix.ru, res2-kzn-lb.ix.ru, res2-spb-lb.ix.ru

16,0

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

2,6

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru

12,1

res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

12,9

Казань

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

30,1

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

13,7

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru

97,6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

187,4

Пермь

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

27,6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

20,9

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

30,2

res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

30,4

Екатеринбург

IPv4/IPv6

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru, res2-nsk-lb.ix.ru

9,1

193.232.231.82, res1-ekt-lb.ix.ru, res2-ekt-lb.ix.ru

2,0

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru

10,5

193.232.231.82, res1-ekt-lb.ix.ru, res2-ekt-lb.ix.ru, res2-spb-lb.ix.ru

1,8

Челябинск

IPv4/IPv6

193.232.231.82, res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-ekt-lb.ix.ru

13,5

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru

31,1

res1-kzn-lb.ix.ru, res1-spb-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

82,6

res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-vlv-lb.ix.ru

86,2

Омск

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

37,9

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-rnd-lb.ix.ru

44,6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

34,7

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

25,4

Новосибирск

IPv4/IPv6

193.232.139.82, 193.232.231.82, res1-ekt-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-spb-lb.ix.ru, res2-ekt-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

6,5

res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru

6,5

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru

9,2

res1-nsk-lb.ix.ru, res2-nsk-lb.ix.ru

6,6

Чита

IPv4/IPv6

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru

66,0

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res2-nsk-lb.ix.ru, res2-vlv-lb.ix.ru

36,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-spb-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru

81,4

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

82,8

Хабаровск

IPv4/IPv6

193.232.139.82, res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-vlv-lb.ix.ru

95,9

res1-khouse-lb.ix.ru, res1-msk-lb.ix.ru, res2-khouse-lb.ix.ru, res2-vlv-lb.ix.ru

101,9

res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

100,3

res1-nsk-lb.ix.ru, res1-vlv-lb.ix.ru, res2-khouse-lb.ix.ru, res2-nsk-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

61,4

Отметим ещё один момент.AAAA запросы используют IPv6 в качестве адреса источника, даже если обращения было сделано на клиентский публичный IPv4 адрес сервера. Для A запросов на IPv6 адрес это тоже верно. В таблице приведены уже преобразованные к доменным именам адреса, там где они были в PTR, каждый из них имеет и A и AAAA запись. Всего получилось 17 уникальных адресов доменных имён у каждого в наличии IPv4 и IPv6. Для двух адресов видимо забыли завести записи в обратную зону, хотя в прямой они есть (я их привёл в скобках).

193.232.139.82(res2-rnd-lb.ix.ru), 193.232.231.82(res2-ekt-lb.ix.ru), res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-smr-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-smr-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

Для примера, надеюсь остальное многие посмотрят сами, сошлюсь на RIPE DB для сети 193.232.139.0/24, запись о которой и маршруты появились в марте этого года, когда уже фактически провайдеры обязаны были использовать НСДИ в своей работе, что во многом говорит что мы находимся в моменте внедрения и обкатки системы, пусть и на хорошей базе. Не знаю какие планы в дальнейшем, но явно в некоторых точках страны видно провалы по задержкам ответов, другими словами есть много что ещё делать.

Для этих серверов уже действует ограничение на выдачу ресурсов присутствующих в списке запрещённых - NXDOMAIN в ответ.

На этом - всё. Как я уже сказал в самом начале, цель этой статьи начать техническое обсуждение построенной системы. Можно свободно использовать те измерения которые я реализовал в RIPE Atlas и ссылки на которые есть в статье, они останутся настолько долго, насколько не потеряют актуальность. Совсем незатронутым остался вопрос DNSSEC, также как и возможные пересечения с существующей системой поддержки национальных TLD. Можно порассуждать про обратные зоны в ARPA., которые не менее важны чем прямые, но они не реализованы в НСДИ, в отличие от прямой корневой зоны. Вопрос устойчивости и работы под нагрузкой, вопрос безопасности... Другими словами больше осталось за кадром, чем в статье - много интересной работы и вопросов, надеюсь, что кого-то я этим заинтересовал.

Подробнее..

MikroTik основы настройки DNS

18.03.2021 18:13:59 | Автор: admin

Если в магазине вас угораздило купить роутер MikroTik себе домой и вы не знаете зачем он вам, а отравление DNS кэша вашим провайдером не дает вам спать по ночам, то этот пост для вас.

Можно не мучаться и поставить DNS от Yandex, Google, Adquard и прочее, а можно пойти более сложным путем:

Открываем сайтhttps://root-servers.orgи ищем свой город, смотрим какие там есть корневые сервера DNS

В Питере их 5

Если их несколько, выбираем какой больше нравится вам :)

Далее находим официальный сайт данной компании, в моем случае этоhttps://www.verisign.com и на сайте ищем раздел с публичным DNS.

В данном случае нас перенаправляют на сайтhttps://www.publicdns.neustar, идем туда и копируем адреса в блокнот :)

Открываем WinBox или через http, кому как больше нравится.

1. Первым делом удаляем автополучение DNS провайдера:

открываем настройки интерфейса и убираем галочку "use peer dns"

2. В настройке DNS (IP -> DNS), вводим IP DNS сервера (начиная с сервера который у вас в городе). Размер кэша укажите сколько не жалко (учитывайте свободное место).

На этом можно было бы закончить, но мы пойдем далее.

Помимобелыхофициальных DNS резолверов есть еще итемная сторонаальтернативные корневые серверы DNS, например, выберем OpenNIC (остальные добавляются подобным образом). Нас интересуют поддерживаемые доменыhttps://www.opennic.org:

и IP адресаhttps://wiki.opennic.org/#anycast_tier_2_dns_resolvers

Далее открываем терминал и добавляем статические маршруты

/ip dns static add comment="OpenNIC" forward-to=185.121.177.177,169.239.202.202,2a05:dfc7:5::53::1,2a05:dfc7:5::5353::1 regexp=".*(\\.bbs|\\.chan|\\.cyb|\\.dyn|\\.geek|\\.gopher|\\.indy|\\.libre|\\.neo|\\.null|\\.o)\$" type=FWD

/ip dns static add comment="OpenNIC" forward-to=185.121.177.177,169.239.202.202,2a05:dfc7:5::53::1,2a05:dfc7:5::5353::1 regexp=".*(\\.oss|\\.oz|\\.parody|\\.pirate|\\.opennic.glue|\\.dns\\.opennic\\.glue)\$" type=FWD

Проверяем

В настройках DNS делаем очистку кэша.

Если пользуетесь Microsoft Edge, отключаем "улучшайзеры", в других браузерах аналогично.

Ребутим все что можно отребутить :)

и наслаждаемсяhttps://www.dnsleaktest.com

Что мне это дало? Нормально заработали уведомления от mihome, перестали "тупить" китайские лампочки :) Ну и немного ощущаешь себякулхацкеромчуть более независимым от своего провайдера :)

Подробнее..
Категории: Mikrotik , Чулан , Dns

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru