DNS *

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

Надо было мне разобраться получше с iptables и ansible, а для этого нужна задачка. Задачка была выбрана такая: поднять свой VPN сервер с возможностью резки рекламы и прочего spyware.

Суть происходящего при резке рекламы с помощью DNS сервера состоит в том, что когда клиент спрашивает сервер какой IP адрес сопоставлен имени хоста, то DNS сервер отвечает ему 0.0.0.0 В итоге клиент ходит сам к себе и быстро получает отказ, так что не пользуется для этого модемом связи в случае с телефоном. Что экономит батарейку не просто на процент, а при моем режиме использования телефона время автономной работы выросло с 8-10 часов до 23.5. Специально засекал и был мягко говоря удивлен. Как показала практика 85% запросов от телефона это spyware.

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

В качестве DNS сервера с возможностью резать телеметрию и прочую гадость был выбран Pi-hole DNS. Просто потому, что он очень не требователен к ресурсам и мне хватает на амазоне t3.nano ноды, которую мне дали бесплатно на год. При этом я видел на DigitalOcean готовый дрополет Pi-hole VPN, но он прибит к этому провадйеру, а мой плейбук я пробовал уже на двух разных и он просто пашет, плюс там видно все, что он делает. Плюс ко всему при установке он закачивает более 5млн бан записей в DNS что бы не искать их потом.

Всем нам нравится писать в строке бровсера https://habr.com/. Никому не
захотелось бы писать там https://178.248.237.68/. К тому же, IP-адрес может
измениться, если Хабр решит перейти на другой хостинг.

Служба Интернета, которая превращает удобные всем имена в IP-адреса,
называется DNS, Domain Name System, "система доменных имен".

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

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

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

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

Для примера возьмём DNS. Мы пользуемся DNS с 80-х (больше 35 лет!). Он применяется на каждом веб-сайте Интернета. И он довольно стабилен – во многих смыслах он работает точно так же, как делал это тридцать лет назад.

Но мне понадобились ГОДЫ, чтобы понять, как с уверенностью отлаживать проблемы с DNS, и я видела множество программистов, тоже испытывавших трудности с отладкой проблем DNS. Что же происходит?

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

(В этом посте я не буду глубоко объяснять DNS, подробности о его работе см. в моём посте Implement DNS in a Weekend или в других моих постах о DNS.)

Все естественно помнят, что существуют базовые проверки почты:

SPF "Sender Policy Framework" (фреймворк политики отправителя) - это метод проверки электронной почты, который позволяет проверять, действительно ли отправитель имеет право отправлять электронные письма от имени определенного домена.

DKIM "DomainKeys Identified Mail" (идентификация почты с помощью домена) - это метод проверки электронной почты, который используется для подтверждения подлинности сообщений, отправленных с определенного домена.

DMARC "Domain-based Message Authentication, Reporting and Conformance" (доменная аутентификация сообщений, отчетность и соответствие) - это метод проверки электронной почты, который позволяет проверять, соответствуют ли SPF и DKIM домену отправителя, и определяет, что делать с сообщениями, которые не соответствуют этим проверкам.

Всем привет, дамы и господа. Ну-с начнем.

Предисловие

В одной из обслуживаемых организаций N возникла непонятная ситуация, а именно: на границе стоит некоторая модель Mikrotik с прошивкой 7.7, и вот этот самый Mikrotik самостоятельно генерирует исходящий трафик до 8.1Мбит\с, при этом из локальной сети ничего не выходит.

использование интернета Starlink и протокола WireGuard позволяет обойти цензуру и ограничения доступа к информации, что особенно важно для жителей стран с жесткими режимами. Как отмечает Илон Маск: "Я считаю, что любой, кто желает свободу, должен иметь возможность получить ее" . Для нас важно поддерживать свободу интернета и обеспечивать безопасность передачи данных, поэтому мы решили использовать интернет Starlink и протокол WireGuard для создания VPN сети

Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.

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

В самом начале на графиках нагрузочного тестирования я увидел очень плохие результаты: случайным образом абсолютно все запросы нагрузочного теста таймаутились, но сервер, который был под нагрузкой, никак не реагировал на проблему. Как выяснилось позже, по чистой случайности я допустил ошибку в конфигурации нашего плагина Pandora, и в итоге он сам ходил в DNS на каждый запрос, чтобы узнать ip адрес тестируемого сервера. Возможно, это сыграло мне на руку и помогло найти первую из проблем, а потом и вовсе задало вектор поисков остальных багов. А в Unbound их накопилось достаточно.

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

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

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

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

Первая Часть

Предыдущая часть закончилась неудачной балансировкой, которая не решает практически никаких проблем. В комментариях кто-то спросил, почему я не использовал балансировку на уровне DNS. Так вот, я ее использовал. Оказалось, что c помощью DNS записей можно организовать балансировку Round Robin. Для этого в конфигурации Wireguard всего лишь нужно использовать доменное имя вместо IP адреса.

Привет, Хабр!

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

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

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

Но есть время не продлять домены разбрасывать камни, а есть время извиниться за сделанную ошибку. Все, кому сервис был полезен, кто им пользовался и однажды заметил что он (localhost.tools) не резолвится — приношу свои извинения, и исправляю ситуацию (лучше поздно чем никогда, верно?).

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

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

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

Протокол DNS (Domain Name System Protocol) является одним из важнейших инфраструктурных протоколов для поддержки сети Интернет и первоначально он разрабатывался для максимальной производительности и возможности распределенного хранения неограниченного числа доменных зон. DNS может функционировать поверх UDP-протокола и это уменьшает накладные расходы на установку соединения и избыточный трафик в сети. Но одной из важнейших проблем стала безопасность обмена данными, поскольку клиент в первоначальном варианте протокола не может проверить достоверность информации и это может приводить к подмене ip-адресов злоумышленниками с переадресацией клиента на фишинговый сайт.

Для решения этой проблемы были введены расширения DNSSEC для генерации цифровой подписи ответа. Но сам запрос и ответ при этом не шифровались, что могло быть использовано для ограничения доступа к определенным доменам или для получения на транзитных узлах статистики доступа к хостам. Частично эту проблему решило использование инкапсуляций DNS-over-TLS (DoT, использует TLS для шифрования UDP-дэйтаграмм) и DNS-over-HTTPS (DoH, передает запросы и ответы поверх HTTPS-подключения), которые функционируют поверх TCP. В первом случае запрос более компактный (но может быть обнаружен по анализу трафика), во втором DNS-диалог неотличим от подключения к сайту или веб-сервисам, но при этом существенно увеличивает избыточной трафик (даже при использовании HTTP/2), а также вынужденно добавляет заголовки (которые могут использоваться для трекинга и перехвата cookies). Но можно ли как-то объединить преимущества UDP и DoH? Встречаем DNS-over-QUIC, который был утвержден в RFC9250 как Proposed Standard.

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

Я попробовал поискать в Google доступную информацию, но и там ничего не нашёл, кроме новостей, приказов об основании этой системы и редких ссылок на инструкцию по подключению, вот например на labs.ripe.net в PDF и с подписями. На сайте Роскомнадзора мои усилия тоже закончились ничем. Я подозреваю что какие-то документы есть внутри ЦМУ ССОП, но туда заходить я не стал.

При всём при этом НСДИ остаётся публичной системой, воспользоваться которой может, как минимум, каждый пользователь Интернет в России. Кроме того, за год накопились данные мониторинга с RIPE Atlas на созданных мною измерениях, используя которые мы и посмотрим к чему мы пришли. Мы не выйдем структурно за рамки прошлой статьи и наш взгляд будет всё равно поверхностный, но имея гораздо больший объём данных сможем посмотреть на это чуть пошире.