DNS *

Классический 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

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат.

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

CAA (Certification Authority Authorization – авторизация центров сертификации), определенная в RFC 6844 в 2013 г., была предложена, чтобы усилить экосистему PKI (Public Key Infrastructure) при помощи нового средства контроля за тем, какой именно центр сертификации может выдавать сертификат данному конкретному домену.

Несмотря на то, что САА введена уже более 4 лет назад, она все еще мало известна сегодня, и на данный момент только 100 или, может быть, около 200 сайтов ее используют. Однако предстоят значительные перемены, потому что форум центров сертификации и разработчиков браузеров (форум CA/Browser) утвердил CAA в качестве обязательной – в рамках стандартного набора базовых условий для выпуска сертификата безопасности. Новая норма начнет действовать с сентября 2017 года.

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



Что это такое: альтернативная система доменных имён с распределённым хранением DNS-записей в блокчейне Emercoin, что исключает возможность их централизованного отключения кем-либо по чьему бы то ни было запросу в принципе. Этот способ успешно используется библиотекой «Флибуста» и сами-знаете-что-за-сайтом Pornolab, которые используют зеркала в доменной зоне .lib.

Служба DNS, невидимая обычному пользователю, периодически оказывается в фокусе интереса IT-специалистов. По разным поводам. Особенно актуальной эта тема становится в периоды, когда основные провайдеры DNS подвергаются DDoS-атакам. Именно тогда, когда DNS становится частично неработоспособной, приходит понимание, что DNS – это основа, костяк всей структуры интернета.

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

• Реестры доменов
• Глобальные домены верхнего уровня (gTLD)
• Различные национальные домены верхнего уровня (ccTLD)
• И растущий с каждым годом список всех прочих доменов высшего уровня (.space, .photography и так далее)

Все это делает и так не простую систему еще более сложной.

Злоумышленники, для заражения компьютеров пользователей, очень часто применяют методы, направленные на обман пользователей, набирающих в строке браузера адрес интересующего их сайта. Например, typosquatting (он же URL hijacking), то есть использование ошибок пользователей, которые могут ошибиться в написании домена на клавиатуре. Например, если в написании домена cisco.ru ошибиться и вместо первой буквы «c» набрать стоящую на клавиатуре рядом букву «v», то мы попадем не на сайт Cisco, а на домен, который в данный момент находится в продаже.


А если, например, ввести вместо «sberbank.ru» домен «sbrrbank.ru» (спутав стоящие рядом «e» и «r»), то мы попадем на вот такой ресурс.

Система DNS — это фундаментальный технологический продукт. Обработка практически всех сетевых запросов верхнего уровня и поисковых запросов в Интернете, пересылка интернет-трафика и электронной почты, а также многие другие операции становятся возможными благодаря установке определенных соответствий при поиске DNS (преобразованию таких имен, как some.domain.org, в IP-адреса или имена других доменов).

Приветствую, Хабр! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.

Хроническая эпидемия расстройства восприятия лиц у жителей Метрополиса, из-за которой никто не замечает, что Кларк Кент и чудаковатый летающий пришелец, похожий на него как две капли воды, — это в действительности одно и то же лицо, распространяется и на технический сектор, где мы постоянно спорим о том, насколько строго нужно различать протоколы SSL и TLS.

Серьезной проблемой современности являются сетевые угрозы ИБ, то есть классы угроз, реализуемых с использованием протоколов межсетевого взаимодействия. Одним из таких протоколов является протокол системы доменных имен — DNS.

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

Отследить модификацию пакетов DNS-транзакций, при потенциально высокой опасности реализации в информационных системах атак довольно непросто, поэтому становятся возможными такие атаки как:

• анализ сетевого трафика;
• подмена доверенного объекта сети;
• навязывание ложного маршрута;
• внедрение ложного объекта сети.

Тема заражения кэша DNS-серверов провайдеров уже давно изъезжена, однако на практическом примере покажем, как довольно просто заставить «ходить» клиентов конкретного интернет-провайдера по нужному нам IP-адресу, вместо правильного, для заданного домена, ничего при этом не взламывая и не заражая троянами, тем самым давая нам полный контроль над трафиком, связанным с конкретной DNS-зоной.

Долго искал, как безболезненно настроить SSL сертификат от Let's Encrypt на Microsoft Azure. В рунете с этим оказались проблемы, но на просторах большого интернета нашлась очень и очень годная статья, по которой мне удалось настроить это шайтанство. Думаю, для новичков, у которых проблемы с иностранными языками (бывает такое, но все мы учимся), перевод статьи пригодится.

Мне страшно представить, с каким стрессом связана работа ИТ-специалистов Ким Чен Ына, так как он, скорее всего, из тех руководителей, которые все время наблюдают за твоей работой из-за плеча, постоянно касаются экрана и с нехорошим выражением лица намекают на «исчезновение» всех твоих родственников в трех поколениях, если при развертывании исправлений будет допущена хоть одна ошибка.

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

Совсем недавно мы рассказали о том, как команда нашего IaaS-провайдера автоматизировала работу с DNS-записями в хостинг-панели.

Опыт создания новой услуги по предоставлению бесплатного сервиса DNS-хостинга сподвиг нас к беглому анализу публикаций на Хабре, которые затрагивали те или иные аспекты работы DNS. Мы собрали эти материалы вместе с англоязычными дополнениями в очередной «ультимативный» дайджест от 1cloud.

В прошлых выпусках мы собрали практические материалы в SSL-и VPN-дайджест.

Не добрый день, коллеги по цеху. В текущий момент наблюдается недоступность DNS-серверов, отвечающих за зону ntp.org. С серверами pool.ntp.org синхронизируются миллиарды устройств по всему миру и теперь они испытывают проблему в получении точного времени.

UPD. В связи с тем, что многие комментаторы не читают полностью, напишу здесь краткую суть проблемы: для .RU не очищаются Glue Records при изменении делегирования домена. Как минимум, для доменов, управляемых через Ru-Center и Reg.ru. Сама статья — это «история из жизни» о том, какие проблемы может вызвать такая «особенность» зоны .RU, как они были диагностированы и решены.

---

«Один мой друг» (с) рассказал историю про свои приключения с DNS.

Предыстория

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

Глава 1

Еще раз проверяем DNS зоны, убеждаемся, что нигде нет старых адресов и очень давно. Проверяем из разных регионов запросами на каждый из своих NS. Везде всё отдаётся правильно. Берем tcpdump и смотрим запросы на 53 порт на старыx DNS. Оказывается, что запросов к ним удивительно много. И это при том, что IP адреса этих серверов уже много месяцев нигде не фигурируют!

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

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

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

Итак, задача: необходимо поднять окружение разработчика для одновременной работы с несколькими веб-проектами висящими на доменах вида example.app. При этом данные домены должны быть доступны из контейнеров, с хоста, а также, например, из эмулятора Genymotion. Кроме того, из контейнеров должен быть доступен и внешний интернет. Все это усугубляется корпоративным Intranet со своим внутренним DNS сервером.