DNS *

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

Почти с самого начала существования Поиска VPS на нем был раздел с точками Looking Glass. О нем я написал в январе 2014 года и на тот момент на карте были расположены 23 точки. Функционал был довольно скудный, точки периодически “умирали”, а времени следить за ними не было. Плюс уже довольно давно есть скрипт для организации своей точки Looking Glass, которым пользуются многие хостеры. Однако у этого скрипта есть 2 недостатка: во-первых, хостерам нужно самостоятельно устанавливать его на сервер (да, это тоже недостаток), а во-вторых, нет централизованной базы, в которой собрана информация обо всех точках от разных хостеров. В этом году я решил заняться данным разделом, и в результате получился сайт, аналогов которого я не видел, и с радостью хочу представить проект LOOKING.HOUSE.

Изначально я хотел назвать этот пост «игра в 0 строк HTML, JS и CSS», вдохновлённый этим постом, но это было бы слишком громко. Так или иначе, сильно ухудшив UX, я получил крестики-нолики, работающие исключительно силой DNS протокола.



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

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

Компания Cloudflare представила публичные ДНС на адресах:

• 1.1.1.1
• 1.0.0.1
• 2606:4700:4700::1111
• 2606:4700:4700::1001

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

Сервис интересен тем, что кроме обычного DNS предоставляет возможность использовать технологий DNS-over-TLS и DNS-over-HTTPS, что здорово помешает провайдерам по пути запросов подслушивать ваши запросы — и собирать статистику, следить, управлять рекламой. Cloudflare утверждает, что дата анонса (1 апреля 2018, или 04/01 в американской нотации) была выбрана не случайно: в какой еще день года представить "четыре единицы"?

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

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

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

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

Представляем вашему вниманию очень эмоциональный рассказ Льва Николаева (@maniaque) о том, как надо настраивать DNS и особенно, как делать не надо. Вот прямо после каждого пункта можете мысленно добавлять: «Пожалуйста, не делайте этого!» В своем докладе Лев так и говорит.

Статья будет состоять из трех частей:

1. Как сделать резольвер (unbound, bind)

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

2. Как держать зоны (PowerDNS)

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

3. Как взболтать, но не смешивать (PowerDNS + unbound)

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

Представим, что атакуемая компания владеет доменом organization.org, и внутри этой компании используется внутренний ресурс portal.organization.org. Цель злоумышленника -получить учётные данные пользователя, и для этого он присылает ссылку через e-mail или используемый в компании мессенджер.



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

Абсолютной «защиты от дурака» тут придумать не получится, но можно пробовать перехватить эту атаку на этапе разрешения имени через dns-запрос.

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

Домен, как объект права, отсутствует в Гражданском кодексе РФ, он не является результатом интеллектуальной деятельности (объектом исключительных прав), не является вещью или иным имуществом, законодатель не установил ни специальных правовых норм об условиях и субъектах “доменных” правоотношений, ни специальных процедур разрешения споров, связанных с доменами. Юристы часто отождествляют доменные имена с товарными знаками. Все же, доменные имена имеют иную правовую природу, ведь они не индивидуализируют ни продукцию, ни услуги. Домен несет в себе маркетинговую ценность для его обладателя и является его нематериальным активом. Рассмотрим некоторые правовые аспекты доменного пространства в России и мире.

Сегодня все мы живем в мире «подобного». Подобных услуг IP-транзита, нейтрализации DDoS, в общем и целом практически любому цифровому сервису можно найти аналогичный. То есть факт — на рынке существует множество поставщиков услуг. И при сравнении предлагаемых ими услуг между собой у потенциального клиента зачастую небольшой круг возможностей. В итоге потребитель вынужден сравнивать между собой исключительно маркетинговые материалы разных компаний, то есть фактически собственные интерпретации компаний по поводу своих же услуг. Это, как минимум, странно и далеко от объективного сравнения даже по такому простому соотношению как «цена/качество».

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

Однако ситуация меняется и в последнее время стали появляться возможности всё-таки провести бесплатно количественную, и качественную оценку желаемого сервиса до его покупки. И один из лучших таких механизмов — это RIPE Atlas.

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

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

Если при попытке отправить сообщение на почтовые сервера Gmail вы вдруг получили ошибку типа «Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.», то это почти всегда значит, что на вашем почтовом сервере не настроены DKIM, SFP и DMARC. Крупные почтовые серверы (Gmail, mail.ru, Яндекс) требуют наличие данных записей. Сегодня мы расскажем, как это сделать в Zimbra Collaboration Suite.

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

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

Как это обычно бывает, появляется новая задача, вы её обдумываете и останавливаетесь на каком то решении. Дальше, это решение необходимо воплотить в жизнь и вот тут то начинается самое интересное…

Передо мной встала большая задача перевести инфраструктуру компании и её проектов на автоматизированное управление. Впоследствии длительной мозговой деятельности, было последовательно выбрано использовать ansible и как веб интерфейс к нему jenkins. По мере понимания всех бизнес-процессов и системы работы серверов и сервисов, я уже чётко видел всю картину IaC (Infrastructure as Сode — инфраструктура как код). После пилотных плейбуков и ролей пора было начинать частичное внедрение, для ансибл есть замечательная возможность динамически собирать списки серверов которыми нам требуется управлять. Для хранения большого числа серверов и всех необходимых переменных для них решил на первых этапах использовать наши собственные ДНС серверы почерпнув идею у badoo(чтоб вам икалось ребята).

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

CAA (Certification Authority Authorization) — это новый тип DNS-записи, предназначенный для определения центров сертификации, которым разрешен выпуск SSL/TLS-сертификатов для определенного доменного имени или субдомена.

Крупнейшие и наиболее популярные центры сертификации договорились, что начиная с 8 сентября 2017 года в обязательном порядке строго следовать инструкциям, указанным в CAA-записях доменного имени или субдомена для которого запрашивается выпуск сертификата.

Использование CAA-записи позволит повысить уровень безопасности в сети Интернет и сократить случаи неавторизованного получения сертификатов для сторонних доменных имен.

Я подготовил подробную инструкцию, которая разъясняет возможности CAA-записи и формат ее использования.

Классический DNS, который специфицирован в rfc1034 не пинает только ленивый. При весьма высокой эффективности работы, он действительно никак не защищён, что позволяет злоумышленникам переводить трафик на подставные сайты, путём подмены DNS-ответов для промежуточных кеширующий серверов (отравление кэша). Как-то с этой напастью борется https с его SSL-сертфикатами, которые позволяют обнаружить подмену сайта. Но пользователи обычно ничего не понимают в SSL, и на предупреждения о несоответствии сертификата автоматически кликают «продолжить», вследствие чего время от времени страдают материально.

В предыдущей статье мы обсуждали захват доменных расширений .na, .co.ao и .it.ao разными хитростями с DNS. Сейчас рассмотрим угрозу компрометации домена верхнего уровня (TLD) и как нужно действовать злоумышленнику, чтобы достичь поставленной цели. Одним из довольно простых методов видится регистрация доменного имени одного из авторитативных серверов имён этой TLD. Поскольку в TLD авторитативные серверы могут размещаться на произвольных доменах, то есть вероятность зарегистрировать такой домен, воспользовавшись ошибкой из-за неправильной конфигурации, истечения срока действия или других ошибок. Затем этот сервер можно использовать для выдачи новых DNS-записей в целой доменной зоне.

Приведу здесь соответствующую цитату из предыдущей статьи:

Такой вариант казался верной дорогой к победе, так что я потратил много времени на разработку инструментария для проверки ошибок этого типа. По сути, этот процесс состоит в записи всех хостов серверов имён для данного домена — и проверке, когда истечёт срок регистрации какого-нибудь из корневых доменов и он станет доступен для регистрации. Основная проблема в том, что многие регистраторы не говорят, что домен полностью свободен, пока вы реально не попробуете его купить. Кроме того, было несколько случаев, когда у сервера заканчивался срок регистрации, но по какой-то причине домен был недоступен для регистрации, хотя не был помечен как зарезервированный. В результате такого сканирования удалось зафиксировать много перехватов доменов в закрытых зонах (.gov, .edu, .int и др.), но не самих TLD.

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

Начиная с 6 июня, на части DNS, обслуживающих российские доменные зоны, разрешен трансфер (AXFR), который позволяет получить полный список доменных имен зон .ru, .su, .tatar, .рф и .дети.

AXFR-запрос доступен на следующих серверах:

• a.dns.ripn.net
• b.dns.ripn.net
• d.dns.ripn.net

Server Name Indication (SNI) — расширение компьютерного протокола TLS[1], которое позволяет клиентам сообщать имя хоста, с которым он желает соединиться во время процесса «рукопожатия».

Проблема SNI была в том что имя сайта идёт в открытом виде. И провайдер используя его может заблокировать сайт или анализировать интересы пользователей.

ESNI — тот же SNI только зашифрованный открытым ключом хостинг провайдера.

О нём уже было пара статей на хабре:

1. CloudFlare реализовала поддержку Encrypted SNI
2. Стандарт Encrypted SNI реализован в Firefox Nightly