DNS *

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

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

Этот метод, пожалуй, самый эффективный. Однако встречались такие ситуации, когда целая подсеть /24 оставалась не найденной.

В наши дни появилось еще одно мощное средство — passive dns, которое позволяет сделать то же самое что и классический DNS-ресолв, но используя специальный API. Это может быть, к примеру, «virustotal» или «passive-total». Эти сервисы записывают DNS запросы и ответы, которые собираются с популярных DNS-серверов. Преимущество этого подхода в том, что нам не нужен брутфорс. Мы просто указываем IP-адрес и получаем все известные DNS записи. Или, наоборот, указывая DNS мы получаем все IP-адреса, которые ассоциированы с данным именем. У данного подхода есть неоспоримое преимущество — мы можем найти старые сервера сайтов, которые ресолвились раньше. Ведь в конце концов старые сайты наиболее вероятно будут содержать уязвимости.

Несмотря на описанные выше техники существует еще несколько чуть менее популярных, но всё же дающих результаты. В данной статье мы рассмотрим ещё две методики разведки — поиск IP-адресов по географическим данным (geo2ip) и нахождение IP-адресов по имени компании (reverse-whois).

Geo2ip

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

По роду своей деятельности я занимаюсь системным администрированием. Поскольку сам по себе я человек ленивый, я люблю максимально всё автоматизировать. Отсюда и любовь ко всяким средствам "Everything-as-Code".

Система доменных имен (DNS) является подобием телефонной книги, которая переводит удобные для пользователя имена, такие как «ussc.ru», в IP-адреса. Так как активность DNS присутствует практически во всех сеансах связи, независимо от протокола. Таким образом DNS логирование является ценным источником данных для специалиста по информационной безопасности, позволяющее им обнаруживать аномалии или получать дополнительные данные об исследуемой системе.

В 2004 году Флорианом Ваймером был предложен такой метод логирования, как Passive DNS, позволяющий восстанавливать историю изменений DNS данных с возможностью индексации и поиска, которые могут предоставлять доступ к следующим данным:

• Доменное имя
• IP-адрес запрошенного доменного имени
• Дату и время ответа
• Тип ответа
• и т.д.

Данные для Passive DNS собираются с рекурсивных DNS-серверов встроенными модулями или с помощью перехвата ответов от DNS-серверов, ответственных за зону.

Рисунок 1. Passive DNS (взят с сайта Ctovision.com)

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

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

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

-- Это ж-ж-ж неспроста! - сказала паранойя - надо что-то делать!

Если сервер у провайдера ломается, а сервер Гугля внезапно устаревает - надо решать проблему иначе.

Около трёх лет у меня возникали проблемы с моим обучающим сайтом Mess With DNS: периодически у него заканчивалась память и он перезагружался по OOM.

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

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

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

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

Введение

Написать данную статью меня побудили следующие обстоятельства:

Обновление ОС на своём роутере до OpenWrt 23.05, сломавшее мой предыдущий setup, где я делал роутинг по GeoIP.

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

Статья на Хабре, по которой я стал делать и понял, что так делать не надо.

Одним недавним летним вечером коротал я время за выпуском сертификатов Let's Encrypt (LE) в кубере, и долго не мог понять с какого перепугу сработало ограничение на количество сертификатов в неделю, т.е. 50 штук.

Быстрая проверка на https://crt.sh/ показала, что действительно для совершенно разных поддоменов было выпущено много странных сертификатов, и это, мягко говоря, удивило.

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

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

Consul — это open-source инструмент от HashiCorp, который обеспечивает сервис-дискавери, проверку состояния сервисов, балансировку нагрузки и глобально распределенное хранилище ключ-значение.

Параноики есть в каждом сообществе. Например, туристы порой превращаются в выживальщиков, постоянно готовящихся к БП – «Большому Происшествию», когда от их готовности будет зависеть жизнь родных, человечества в целом, и сохранность себя родимого. Нельзя однозначно заявить плохо это или хорошо, потому что не секрет, что БП застанет и тех, у кого не запасено 50 килограммов гречки, бензин и оружие. Среди опытных ай-тишников также развита профессиональная деформация личности, которая нередко подразумевает паранойю: тяжело спать спокойно, когда понимаешь технологии изнутри и хрупкость их бытия!

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