Добро пожаловать обратно, мои начинающие кибервоины!
Система доменных имён (DNS) — один из сетевых протоколов, на которых вращается мир. Без неё нам пришлось бы запоминать бесчисленное количество IP-адресов, чтобы просто зайти на наши любимые веб-сайты. Представьте, что вам нужно запомнить IPv4-адреса (32-битные) Facebook, Amazon и Hackers-Arise, чтобы посетить каждый из этих критически важных веб-сайтов (а 128-битные IPv6-адреса только усугубляют ситуацию).
Система DNS была разработана для преобразования доменного имени (которое люди довольно хорошо запоминают) в IP-адрес, то есть на языке интернет-маршрутизации. DNS можно представить как простое преобразование доменного имени в соответствующий ему IP-адрес. Таким образом, когда вы вводите в браузере домен, например, www.hackers-arise.com, он преобразуется в понятный компьютеру IP-адрес (23.236.62.147), который интернет может распознать и маршрутизировать.
В этом уроке по DNS мы рассмотрим:
I. Как работают доменные имена
II. Как работает DNS
III. Анализ DNS-запросов и ответов на уровне пакетов.
IV. Уязвимости и безопасность DNS.
V. Создайте свой собственный DNS-сервер в Linux.
I. Доменные имена
Доменные имена должны быть зарегистрированы в ICANN (Корпорации по управлению доменными именами и IP-адресами в Интернете), как правило, через посредника, такого как VeriSign или GoDaddy. К доменам верхнего уровня (TLD) относятся .com, .edu, .org и многие другие, которые обычно встречаются в конце полного доменного имени (FQDN).
DNS работает иерархически. Домены верхнего уровня (TLD) могут иметь несколько поддоменов. На схеме выше .redhat и .cnn являются частью домена верхнего уровня .com. Поддомен — это домен, являющийся частью более крупного домена. В этом примере redhat и cnn часто в обиходе называют просто доменом, но на самом деле это домены второго уровня (SLD) в зоне .com.
Затем, под этими SLD, или доменами, мы создаём множество поддоменов. Например, внутри и под доменом .redhat могут быть поддомены sales.redhat, engineering.radhat, development.redhat. Это способ деления домена на поддомены. Левая часть всегда самая конкретная, а правая — самая общая.
а. Полное доменное имя
Полное доменное имя (FQDN) — это то, что многие называют абсолютным доменным именем. Полное доменное имя (FQDN) определяет местоположение относительно абсолютного корня системы DNS.
Теперь, когда мы имеем базовое представление о доменных именах, следующим вопросом в понимании DNS является преобразование доменных имён в IP-адреса. Изначально клиенты использовали простой файл hosts на каждом клиенте.
б. Хост-файлы
Когда Интернет был очень-очень маленьким (в далёкой-далёкой вселенной…), сопоставление доменных имён с IP-адресами можно было уместить в один текстовый файл (ARPANET, предшественник и прототип Интернета, имел всего 4 сайта). Этот единственный текстовый файл тогда и сейчас называется файлом hosts . По мере роста Интернета этот файл hosts оказался неэффективным. Он был недостаточно большим и не мог постоянно обновляться по мере регистрации новых доменов и удаления или изменения старых. Несмотря на это, в вашей системе, вероятно, всё ещё есть файл hosts.
В вашей системе Kali Linux файл hosts находится в каталоге /etc, как показано ниже. Вы можете открыть его, введя:
kali> коврик для мыши /etc/hosts
Обратите внимание, что каждый IP-адрес находится на той же строке, что и соответствующий хост, в данном случае localhost или Kali. Всякий раз, когда вы вводите localhost в браузере, он преобразуется в ваш «домашний» IP-адрес или 127.0.0.1.
На четвертой строке моего файла hosts вы увидите связь частного IP-адреса 192.168.1.114 с доменом bankofamerica.com. Если этот файл hosts будет установлен, всякий раз, когда я введу www.bankofamerica.com в своем браузере, я буду перенаправлен на IP-адрес 192.168.56.101, а не на фактический IP-адрес Bank of America 171.159.228.150.
Я также могу это проверить, отправив команду ping на bankofamerica.com.
Как видите выше, когда я пытаюсь выполнить ping на www.bankofamerica.com, мой ping направляется на адрес, связанный с bankofamerica в моём файле hosts. Файл hosts имеет приоритет над DNS-запросами. Это может быть ключевой информацией при попытке DNS-спуфинга в локальной сети (см. ниже).
Именно так работал DNS, когда Интернет был очень и очень маленьким.
II. Как работает DNS
Теперь, когда Интернет содержит миллиарды IP-адресов и полных доменных имен (FQDN), файл hosts становится совершенно неэффективным. Встречайте DNS. Система DNS, впервые разработанная Полом Мокапетрисом (ныне входящим в Зал славы Интернета) в 1983 году, является одновременно распределённой и динамической, в отличие от нашего файла hosts.
DNS опирается не на один файл или сервер, а на множество файлов на множестве серверов по всему миру. Эти серверы организованы иерархически. Благодаря своей распределённой природе система DNS устойчива к сбоям одного или нескольких серверов.
Как мы можем видеть на диаграмме выше, пользователь запрашивает (просит) локальный DNS-сервер для доступа к download.beta.example.com . Локальный DNS-сервер не имеет этого ресурса, так как он новый. Затем он запрашивает корневой сервер. Корневой сервер отвечает «Я не знаю», но отсылает локальный DNS-сервер к IP-адресу полномочного сервера для домена верхнего уровня (TLD), в данном случае .com . Затем локальный DNS-сервер запросит у TLD-сервера .com и тот ответит полномочным сервером для домена, в данном случае example.com . Затем локальный DNS-сервер запросит у полномочного сервера beta.example.com. Если у него есть запись, он вернет ресурс (IP-адрес), а если нет, он ответит, что «не знает».
а. Компоненты DNS
Служба DNS состоит из четырех (4) компонентов:
1. DNS-кэш
2. Решатели,
3. Серверы имен,
4. Пространство имен.
1. DNS-кэш
Этот термин часто путают, поскольку он имеет как минимум два значения. Во-первых, DNS-кэш может означать список имён и IP-адресов, которые вы уже запросили, которые были преобразованы и кэшированы для вас, чтобы не создавать сетевой трафик для их преобразования (и это происходит гораздо быстрее). Второе значение относится к DNS-серверу, который просто выполняет рекурсивные запросы и кэширует, не являясь при этом авторитативным сервером.
2. Решатели
Резолверы — это любые хосты в Интернете, которым необходимо искать информацию о домене, например, компьютер, который вы используете для просмотра этого веб-сайта.
3. Серверы имен
Это серверы, которые содержат базу данных имен и IP-адресов и обслуживают DNS-запросы клиентов.
4. Пространство имен
Пространство имен — это база данных IP-адресов и связанных с ними имен.
б. Файлы и записи зоны
У каждой зоны DNS есть файл зоны. Этот файл зоны можно рассматривать как базу данных DNS.
Эти файлы зон содержат одну или несколько записей ресурсов. Эти записи DNS необходимо периодически обновлять по мере добавления, изменения и удаления новых доменов. Без этого процесса система останется неактивной и в конечном итоге полностью устареет. Поэтому крайне важно, чтобы DNS-сервер поддерживал передачу зон.
1. Записи ресурсов
Запись ресурса — это отдельная запись, описывающая только один фрагмент информации в базе данных DNS. Эти записи представляют собой простые текстовые строки, например:
Владелец TTL Класс Тип RDATA
Каждое из этих полей должно быть отделено как минимум одним пробелом.
2. Распространенные типы записей ресурсов
Записи SOA
Запись «Начало полномочий» (SOA) является обязательной во всех файлах зоны. Она должна быть первой реальной записью в файле (хотя выше могут быть указаны спецификации $ORIGIN или $TTL). Она также является одной из самых сложных для понимания. Поля включают в себя основной сервер имён, адрес электронной почты администратора, номер домена и таймеры обновления зоны.
NS Records
NS или сервер имен идентифицирует авторитетный DNS-сервер для зоны.
А Рекордс
Запись A (адрес) используется для сопоставления домена или поддомена с адресом IPv4. Например, hackers-arise.com указывает на 23.236.62147.
Записи AAAA указывают на запись IPv6.
CNAME (канонические) записи
CName или каноническое имя сопоставляет один домен или поддомен с другим доменным именем.
записи PTR
Записи PTR используются в обратных записях DNS (то есть от IP-адреса к имени хоста). PTR или Pointer указывает на каноническое имя, и в запросе возвращается только это имя. Их можно рассматривать как обратные записи A или AAAA.
MX Records
Запись MX направляет почту на конкретный почтовый сервер, ответственный за приём почты в зоне. Как и CNAME, запись MX всегда должна указывать на домен, а не на IP-адрес.
III. Анализ DNS-запросов на уровне пакетов
Протокол DNS, как и другие протоколы связи, используемые в наших сетях, имеет стандартную структуру пакета. Она довольно проста, и вы можете ознакомиться с ней ниже, не вдаваясь в подробности.
Если мы перехватим DNS-запросы с помощью Wireshark, мы увидим что-то похожее на показанное ниже. Обратите внимание, что DNS-запрос отправляется клиентом , а DNS-ответ приходит от DNS-сервера .
Также важно отметить, что эти запросы используют UDP, а не TCP (зонные передачи используют TCP).
Если развернуть DNS-пакеты, то можно увидеть, что они бывают двух видов: стандартный запрос, как показано ниже…
…и стандартный ответ на запрос, как показано здесь.
IV. Безопасность и уязвимости DNS
Служба доменных имён когда-то была очень хрупкой и уязвимой для атак. С годами система была укреплена, и атаки стали реже, но всё ещё происходят. В некоторых случаях хакеры/злоумышленники могут просто собирать информацию с DNS-серверов на целевой странице, например, путём сканирования DNS и DNS-разведки (см. раздел « Злоупотребление DNS для разведки »).
В локальных сетях (LAN) возможна подмена DNS с помощью таких инструментов, как DNS-Spoof, для перенаправления клиентского трафика на выбранную хакером локальную систему. Например, злоумышленник может перенаправить весь банковский трафик на свой вредоносный сайт и собрать там учётные данные.
А. Уязвимости DNS
Хотя к наиболее вредоносным атакам на DNS относятся смена вашего DNS-сервера (записи A) и изменение адреса, на который перенаправляется ваш клиент при запросе веб-сайта, такие атаки встречаются всё реже, но не являются чем-то из ряда вон выходящим (см. ниже примеры иранских DNS-атак). Всё чаще успешными атаками на DNS становятся атаки типа «отказ в обслуживании» (DOS).
Хотя DoS-атаки на большинство систем и протоколов представляют собой серьёзную проблему, для такой важной службы, как DNS, они могут быть разрушительными. Представьте, что DNS-сервер вашей компании или интернет-провайдера вышел из строя. Хотя интернет всё равно будет работать (вы сможете выполнить ping на любой IP-адрес), вы не сможете подключиться ни к одному сайту, не введя его полный IP-адрес (или не сменив DNS-сервер).
Если просмотреть список уязвимостей BIND (реализация DNS для Linux) в базе данных CVE, то можно увидеть, что подавляющее большинство уязвимостей за последние годы — это DoS-атаки.
Одной из самых вредоносных DNS-атак является передача зоны. Зона — это данные, сопоставляющие IP-адреса с доменами. Если злоумышленник сможет изменить эту информацию на DNS-сервере, весь интернет-трафик будет перенаправлен на его сайт, что может привести к серьёзным последствиям.
Б. Изменение настроек DNS-сервера
Другой тип атаки на систему DNS — это простое изменение настройки, которая перенаправляет DNS-запросы на другой вредоносный DNS-сервер. В некотором смысле, это технически не атака на DNS, а атака на внутренние учётные данные и серверы, например, почтовый сервер. Ниже вы можете ознакомиться с подробностями атаки, о которой US CERT предупреждал в начале 2019 года. Учётные данные системного администратора (или другого пользователя с полномочиями изменять записи DNS) перенаправляли DNS-запросы пользователей на вредоносный DNS-сервер.
Недавно группа иранских хакеров смогла атаковать DNS нескольких компаний, чтобы получить доступ к их учётным данным. Они сделали это как минимум тремя способами:
1. Злоумышленники изменяют DNS-записи почтового сервера жертвы, чтобы перенаправить его на свой сервер. Злоумышленники также используют сертификаты Let's Encrypt для поддержки HTTPS-трафика и балансировщик нагрузки для перенаправления жертв обратно на настоящий почтовый сервер после сбора учётных данных жертв на своём теневом сервере.
2. То же, что и первый, но разница заключается в том, где изменяются легитимные DNS-записи компании. В первом случае злоумышленники изменяли A-записи DNS через учётную запись управляемого DNS-провайдера, тогда как в этом случае злоумышленники изменяли NS-записи DNS через учётную запись поставщика доменных имен (TLD).
3. Иногда также используется в рамках первых двух методов. Суть этого метода заключается в развертывании «блока злоумышленников», который отвечает на DNS-запросы, содержащие перехваченную DNS-запись. Если DNS-запрос (к почтовому серверу компании) поступает изнутри компании, пользователь перенаправляется на вредоносный сервер, которым управляют злоумышленники, но если запрос поступает извне, он направляется на настоящий почтовый сервер.
C. Безопасность DNS или DNSSec
DNS по умолчанию НЕ является безопасным. DNS легко подделать, поскольку он основан на протоколе UDP, который не ориентирован на установление соединения. DNSSEC (расширения безопасности DNS) был разработан для усиления аутентификации в DNS с помощью цифровых подписей.
Каждая DNS-зона имеет открытый и закрытый ключи. Любой рекурсивный резолвер, просматривающий данные в зоне, также получает открытый ключ зоны, который можно использовать для проверки подлинности данных.
До появления DNSSec злоумышленники могли выполнять зонные передачи на DNS-серверах. Это приводило к порче данных и делало их ненадёжными. DNSSEC предотвращает это следующим образом:
1. Криптографическая проверка того, что получаемые данные действительно поступают из той зоны, из которой, по его мнению, они должны поступать;
2. Обеспечение целостности данных, чтобы данные не могли быть изменены в пути, поскольку данные должны быть подписаны цифровой подписью с помощью закрытого ключа зоны.
V. Реализация DNS (BIND) в Linux
Теперь, когда мы разобрались с основами работы DNS и тем, как злоумышленники могут использовать DNS в своих атаках, давайте настроим DNS-сервер в нашей системе Linux. BIND (Berkeley Internet Domain System) широко используется в системах Linux, является самым распространённым DNS-сервером в Интернете и входит в число лучших DNS-систем.
Хотя настройка и конфигурирование сервера BIND само по себе является профессией, здесь мы попытаемся настроить простой, базовый сервер BIND в нашей локальной сети (LAN), чтобы помочь вам понять функционирование этих серверов.
1. Для начала давайте скачаем и установим bind9 из репозитория.
kali > apt-get install bind9
Если bind9 отсутствует в вашем репозитории, вы можете получить его напрямую из репозитория ISC.org с помощью git clone.
kali > git clone https://gitlab.isc.org/isc-projects/bind9.git
2. Далее откроем файл конфигурации BIND по адресу /etc/bind/named.conf.options (все файлы конфигурации BIND находятся по адресу /etc/bind).
Кали > листовая панель /etc/bind/named.conf.options
Как вы видите, мы отредактировали выделенный абзац следующим образом:
прослушивание порта 53 с localhost и нашей локальной сети 192.168.1.0/24;
allow-query на локальном хосте и 192.168.1.0/24
использовать пересылку по адресу 75.75.75.75 (куда пересылать DNS-запросы, если ваш DNS-сервер не может разрешить запрос)
и включить рекурсию .
3. Далее откроем named.conf.local. В нём мы определим файлы зон для нашего домена.
Обратите внимание, что мы определили расположение файлов прямой и обратной зон поиска. Теперь нам нужно создать эти файлы.
Перейдём в каталог /etc/bind. Там вы увидите файл db.local. Это шаблон для нашего файла fowarder. Скопируем его в файл forward.hackers-arise.local.
kali > cp db.local forward.hackers-arise.local
Кали > листовая панель /etc/bind/forward.hackers-arise.local
Давайте откроем этот файл в Leafpad и внесем несколько изменений, указав наш домен (hackers-arise.com), IP-адрес нашего DNS-сервера (192.168.1.27), наш почтовый сервер и, наконец, IP-адреса веб-сервера и почтового сервера.
Теперь нам нужно создать файл обратного поиска. У нас снова есть шаблон в каталоге /etc/bind. В данном случае он называется db.127 . Скопируем его в файл reverse.hackers-arise.local.
kali > cp db.127 reverse.hackers-arise.local
Затем откроем этот файл с помощью Leafpad.
Кали > листовая панель /etc.bind/reverse.hackers-arise.local
Давайте теперь внесем несколько изменений.
В разделе «Ваш сервер имен» добавьте:
основной.ваш домен.локальный.
IP-адрес сервера имен
В разделе «Обратный поиск» добавьте:
последний октет IP-адреса NS и primary.your domain.local.
В разделе «Записи PTR» добавьте:
последний октет веб-сервера и www.ваш домен.локальный
последний октет почтового сервера и mail.your domain.local.
4. На последнем этапе нам просто нужно перезапустить службу, чтобы наши изменения вступили в силу и вступили в силу.
kali > перезапуск службы bind9
Для тех из вас, кто предпочитает новые команды systemd, это работает ничуть не хуже.
kali > systemctl restart bind9
Теперь наш сервер BIND готов разрешать DNS-запросы в нашей локальной сети!
Система доменных имён (DNS) — один из сетевых протоколов, на которых вращается мир. Без неё нам пришлось бы запоминать бесчисленное количество IP-адресов, чтобы просто зайти на наши любимые веб-сайты. Представьте, что вам нужно запомнить IPv4-адреса (32-битные) Facebook, Amazon и Hackers-Arise, чтобы посетить каждый из этих критически важных веб-сайтов (а 128-битные IPv6-адреса только усугубляют ситуацию).
Система DNS была разработана для преобразования доменного имени (которое люди довольно хорошо запоминают) в IP-адрес, то есть на языке интернет-маршрутизации. DNS можно представить как простое преобразование доменного имени в соответствующий ему IP-адрес. Таким образом, когда вы вводите в браузере домен, например, www.hackers-arise.com, он преобразуется в понятный компьютеру IP-адрес (23.236.62.147), который интернет может распознать и маршрутизировать.
В этом уроке по DNS мы рассмотрим:
I. Как работают доменные имена
II. Как работает DNS
III. Анализ DNS-запросов и ответов на уровне пакетов.
IV. Уязвимости и безопасность DNS.
V. Создайте свой собственный DNS-сервер в Linux.
I. Доменные имена
Доменные имена должны быть зарегистрированы в ICANN (Корпорации по управлению доменными именами и IP-адресами в Интернете), как правило, через посредника, такого как VeriSign или GoDaddy. К доменам верхнего уровня (TLD) относятся .com, .edu, .org и многие другие, которые обычно встречаются в конце полного доменного имени (FQDN).
DNS работает иерархически. Домены верхнего уровня (TLD) могут иметь несколько поддоменов. На схеме выше .redhat и .cnn являются частью домена верхнего уровня .com. Поддомен — это домен, являющийся частью более крупного домена. В этом примере redhat и cnn часто в обиходе называют просто доменом, но на самом деле это домены второго уровня (SLD) в зоне .com.
Затем, под этими SLD, или доменами, мы создаём множество поддоменов. Например, внутри и под доменом .redhat могут быть поддомены sales.redhat, engineering.radhat, development.redhat. Это способ деления домена на поддомены. Левая часть всегда самая конкретная, а правая — самая общая.
а. Полное доменное имя
Полное доменное имя (FQDN) — это то, что многие называют абсолютным доменным именем. Полное доменное имя (FQDN) определяет местоположение относительно абсолютного корня системы DNS.
Теперь, когда мы имеем базовое представление о доменных именах, следующим вопросом в понимании DNS является преобразование доменных имён в IP-адреса. Изначально клиенты использовали простой файл hosts на каждом клиенте.
б. Хост-файлы
Когда Интернет был очень-очень маленьким (в далёкой-далёкой вселенной…), сопоставление доменных имён с IP-адресами можно было уместить в один текстовый файл (ARPANET, предшественник и прототип Интернета, имел всего 4 сайта). Этот единственный текстовый файл тогда и сейчас называется файлом hosts . По мере роста Интернета этот файл hosts оказался неэффективным. Он был недостаточно большим и не мог постоянно обновляться по мере регистрации новых доменов и удаления или изменения старых. Несмотря на это, в вашей системе, вероятно, всё ещё есть файл hosts.
В вашей системе Kali Linux файл hosts находится в каталоге /etc, как показано ниже. Вы можете открыть его, введя:
kali> коврик для мыши /etc/hosts
Обратите внимание, что каждый IP-адрес находится на той же строке, что и соответствующий хост, в данном случае localhost или Kali. Всякий раз, когда вы вводите localhost в браузере, он преобразуется в ваш «домашний» IP-адрес или 127.0.0.1.
На четвертой строке моего файла hosts вы увидите связь частного IP-адреса 192.168.1.114 с доменом bankofamerica.com. Если этот файл hosts будет установлен, всякий раз, когда я введу www.bankofamerica.com в своем браузере, я буду перенаправлен на IP-адрес 192.168.56.101, а не на фактический IP-адрес Bank of America 171.159.228.150.
Я также могу это проверить, отправив команду ping на bankofamerica.com.
Как видите выше, когда я пытаюсь выполнить ping на www.bankofamerica.com, мой ping направляется на адрес, связанный с bankofamerica в моём файле hosts. Файл hosts имеет приоритет над DNS-запросами. Это может быть ключевой информацией при попытке DNS-спуфинга в локальной сети (см. ниже).
Именно так работал DNS, когда Интернет был очень и очень маленьким.
II. Как работает DNS
Теперь, когда Интернет содержит миллиарды IP-адресов и полных доменных имен (FQDN), файл hosts становится совершенно неэффективным. Встречайте DNS. Система DNS, впервые разработанная Полом Мокапетрисом (ныне входящим в Зал славы Интернета) в 1983 году, является одновременно распределённой и динамической, в отличие от нашего файла hosts.
DNS опирается не на один файл или сервер, а на множество файлов на множестве серверов по всему миру. Эти серверы организованы иерархически. Благодаря своей распределённой природе система DNS устойчива к сбоям одного или нескольких серверов.
Как мы можем видеть на диаграмме выше, пользователь запрашивает (просит) локальный DNS-сервер для доступа к download.beta.example.com . Локальный DNS-сервер не имеет этого ресурса, так как он новый. Затем он запрашивает корневой сервер. Корневой сервер отвечает «Я не знаю», но отсылает локальный DNS-сервер к IP-адресу полномочного сервера для домена верхнего уровня (TLD), в данном случае .com . Затем локальный DNS-сервер запросит у TLD-сервера .com и тот ответит полномочным сервером для домена, в данном случае example.com . Затем локальный DNS-сервер запросит у полномочного сервера beta.example.com. Если у него есть запись, он вернет ресурс (IP-адрес), а если нет, он ответит, что «не знает».
а. Компоненты DNS
Служба DNS состоит из четырех (4) компонентов:
1. DNS-кэш
2. Решатели,
3. Серверы имен,
4. Пространство имен.
1. DNS-кэш
Этот термин часто путают, поскольку он имеет как минимум два значения. Во-первых, DNS-кэш может означать список имён и IP-адресов, которые вы уже запросили, которые были преобразованы и кэшированы для вас, чтобы не создавать сетевой трафик для их преобразования (и это происходит гораздо быстрее). Второе значение относится к DNS-серверу, который просто выполняет рекурсивные запросы и кэширует, не являясь при этом авторитативным сервером.
2. Решатели
Резолверы — это любые хосты в Интернете, которым необходимо искать информацию о домене, например, компьютер, который вы используете для просмотра этого веб-сайта.
3. Серверы имен
Это серверы, которые содержат базу данных имен и IP-адресов и обслуживают DNS-запросы клиентов.
4. Пространство имен
Пространство имен — это база данных IP-адресов и связанных с ними имен.
б. Файлы и записи зоны
У каждой зоны DNS есть файл зоны. Этот файл зоны можно рассматривать как базу данных DNS.
Эти файлы зон содержат одну или несколько записей ресурсов. Эти записи DNS необходимо периодически обновлять по мере добавления, изменения и удаления новых доменов. Без этого процесса система останется неактивной и в конечном итоге полностью устареет. Поэтому крайне важно, чтобы DNS-сервер поддерживал передачу зон.
1. Записи ресурсов
Запись ресурса — это отдельная запись, описывающая только один фрагмент информации в базе данных DNS. Эти записи представляют собой простые текстовые строки, например:
Владелец TTL Класс Тип RDATA
Каждое из этих полей должно быть отделено как минимум одним пробелом.
2. Распространенные типы записей ресурсов
Записи SOA
Запись «Начало полномочий» (SOA) является обязательной во всех файлах зоны. Она должна быть первой реальной записью в файле (хотя выше могут быть указаны спецификации $ORIGIN или $TTL). Она также является одной из самых сложных для понимания. Поля включают в себя основной сервер имён, адрес электронной почты администратора, номер домена и таймеры обновления зоны.
NS Records
NS или сервер имен идентифицирует авторитетный DNS-сервер для зоны.
А Рекордс
Запись A (адрес) используется для сопоставления домена или поддомена с адресом IPv4. Например, hackers-arise.com указывает на 23.236.62147.
Записи AAAA указывают на запись IPv6.
CNAME (канонические) записи
CName или каноническое имя сопоставляет один домен или поддомен с другим доменным именем.
записи PTR
Записи PTR используются в обратных записях DNS (то есть от IP-адреса к имени хоста). PTR или Pointer указывает на каноническое имя, и в запросе возвращается только это имя. Их можно рассматривать как обратные записи A или AAAA.
MX Records
Запись MX направляет почту на конкретный почтовый сервер, ответственный за приём почты в зоне. Как и CNAME, запись MX всегда должна указывать на домен, а не на IP-адрес.
III. Анализ DNS-запросов на уровне пакетов
Протокол DNS, как и другие протоколы связи, используемые в наших сетях, имеет стандартную структуру пакета. Она довольно проста, и вы можете ознакомиться с ней ниже, не вдаваясь в подробности.
Если мы перехватим DNS-запросы с помощью Wireshark, мы увидим что-то похожее на показанное ниже. Обратите внимание, что DNS-запрос отправляется клиентом , а DNS-ответ приходит от DNS-сервера .
Также важно отметить, что эти запросы используют UDP, а не TCP (зонные передачи используют TCP).
Если развернуть DNS-пакеты, то можно увидеть, что они бывают двух видов: стандартный запрос, как показано ниже…
…и стандартный ответ на запрос, как показано здесь.
IV. Безопасность и уязвимости DNS
Служба доменных имён когда-то была очень хрупкой и уязвимой для атак. С годами система была укреплена, и атаки стали реже, но всё ещё происходят. В некоторых случаях хакеры/злоумышленники могут просто собирать информацию с DNS-серверов на целевой странице, например, путём сканирования DNS и DNS-разведки (см. раздел « Злоупотребление DNS для разведки »).
В локальных сетях (LAN) возможна подмена DNS с помощью таких инструментов, как DNS-Spoof, для перенаправления клиентского трафика на выбранную хакером локальную систему. Например, злоумышленник может перенаправить весь банковский трафик на свой вредоносный сайт и собрать там учётные данные.
А. Уязвимости DNS
Хотя к наиболее вредоносным атакам на DNS относятся смена вашего DNS-сервера (записи A) и изменение адреса, на который перенаправляется ваш клиент при запросе веб-сайта, такие атаки встречаются всё реже, но не являются чем-то из ряда вон выходящим (см. ниже примеры иранских DNS-атак). Всё чаще успешными атаками на DNS становятся атаки типа «отказ в обслуживании» (DOS).
Хотя DoS-атаки на большинство систем и протоколов представляют собой серьёзную проблему, для такой важной службы, как DNS, они могут быть разрушительными. Представьте, что DNS-сервер вашей компании или интернет-провайдера вышел из строя. Хотя интернет всё равно будет работать (вы сможете выполнить ping на любой IP-адрес), вы не сможете подключиться ни к одному сайту, не введя его полный IP-адрес (или не сменив DNS-сервер).
Если просмотреть список уязвимостей BIND (реализация DNS для Linux) в базе данных CVE, то можно увидеть, что подавляющее большинство уязвимостей за последние годы — это DoS-атаки.
Одной из самых вредоносных DNS-атак является передача зоны. Зона — это данные, сопоставляющие IP-адреса с доменами. Если злоумышленник сможет изменить эту информацию на DNS-сервере, весь интернет-трафик будет перенаправлен на его сайт, что может привести к серьёзным последствиям.
Б. Изменение настроек DNS-сервера
Другой тип атаки на систему DNS — это простое изменение настройки, которая перенаправляет DNS-запросы на другой вредоносный DNS-сервер. В некотором смысле, это технически не атака на DNS, а атака на внутренние учётные данные и серверы, например, почтовый сервер. Ниже вы можете ознакомиться с подробностями атаки, о которой US CERT предупреждал в начале 2019 года. Учётные данные системного администратора (или другого пользователя с полномочиями изменять записи DNS) перенаправляли DNS-запросы пользователей на вредоносный DNS-сервер.
Недавно группа иранских хакеров смогла атаковать DNS нескольких компаний, чтобы получить доступ к их учётным данным. Они сделали это как минимум тремя способами:
1. Злоумышленники изменяют DNS-записи почтового сервера жертвы, чтобы перенаправить его на свой сервер. Злоумышленники также используют сертификаты Let's Encrypt для поддержки HTTPS-трафика и балансировщик нагрузки для перенаправления жертв обратно на настоящий почтовый сервер после сбора учётных данных жертв на своём теневом сервере.
2. То же, что и первый, но разница заключается в том, где изменяются легитимные DNS-записи компании. В первом случае злоумышленники изменяли A-записи DNS через учётную запись управляемого DNS-провайдера, тогда как в этом случае злоумышленники изменяли NS-записи DNS через учётную запись поставщика доменных имен (TLD).
3. Иногда также используется в рамках первых двух методов. Суть этого метода заключается в развертывании «блока злоумышленников», который отвечает на DNS-запросы, содержащие перехваченную DNS-запись. Если DNS-запрос (к почтовому серверу компании) поступает изнутри компании, пользователь перенаправляется на вредоносный сервер, которым управляют злоумышленники, но если запрос поступает извне, он направляется на настоящий почтовый сервер.
C. Безопасность DNS или DNSSec
DNS по умолчанию НЕ является безопасным. DNS легко подделать, поскольку он основан на протоколе UDP, который не ориентирован на установление соединения. DNSSEC (расширения безопасности DNS) был разработан для усиления аутентификации в DNS с помощью цифровых подписей.
Каждая DNS-зона имеет открытый и закрытый ключи. Любой рекурсивный резолвер, просматривающий данные в зоне, также получает открытый ключ зоны, который можно использовать для проверки подлинности данных.
До появления DNSSec злоумышленники могли выполнять зонные передачи на DNS-серверах. Это приводило к порче данных и делало их ненадёжными. DNSSEC предотвращает это следующим образом:
1. Криптографическая проверка того, что получаемые данные действительно поступают из той зоны, из которой, по его мнению, они должны поступать;
2. Обеспечение целостности данных, чтобы данные не могли быть изменены в пути, поскольку данные должны быть подписаны цифровой подписью с помощью закрытого ключа зоны.
V. Реализация DNS (BIND) в Linux
Теперь, когда мы разобрались с основами работы DNS и тем, как злоумышленники могут использовать DNS в своих атаках, давайте настроим DNS-сервер в нашей системе Linux. BIND (Berkeley Internet Domain System) широко используется в системах Linux, является самым распространённым DNS-сервером в Интернете и входит в число лучших DNS-систем.
Хотя настройка и конфигурирование сервера BIND само по себе является профессией, здесь мы попытаемся настроить простой, базовый сервер BIND в нашей локальной сети (LAN), чтобы помочь вам понять функционирование этих серверов.
1. Для начала давайте скачаем и установим bind9 из репозитория.
kali > apt-get install bind9
Если bind9 отсутствует в вашем репозитории, вы можете получить его напрямую из репозитория ISC.org с помощью git clone.
kali > git clone https://gitlab.isc.org/isc-projects/bind9.git
2. Далее откроем файл конфигурации BIND по адресу /etc/bind/named.conf.options (все файлы конфигурации BIND находятся по адресу /etc/bind).
Кали > листовая панель /etc/bind/named.conf.options
Как вы видите, мы отредактировали выделенный абзац следующим образом:
прослушивание порта 53 с localhost и нашей локальной сети 192.168.1.0/24;
allow-query на локальном хосте и 192.168.1.0/24
использовать пересылку по адресу 75.75.75.75 (куда пересылать DNS-запросы, если ваш DNS-сервер не может разрешить запрос)
и включить рекурсию .
3. Далее откроем named.conf.local. В нём мы определим файлы зон для нашего домена.
Обратите внимание, что мы определили расположение файлов прямой и обратной зон поиска. Теперь нам нужно создать эти файлы.
Перейдём в каталог /etc/bind. Там вы увидите файл db.local. Это шаблон для нашего файла fowarder. Скопируем его в файл forward.hackers-arise.local.
kali > cp db.local forward.hackers-arise.local
Кали > листовая панель /etc/bind/forward.hackers-arise.local
Давайте откроем этот файл в Leafpad и внесем несколько изменений, указав наш домен (hackers-arise.com), IP-адрес нашего DNS-сервера (192.168.1.27), наш почтовый сервер и, наконец, IP-адреса веб-сервера и почтового сервера.
Теперь нам нужно создать файл обратного поиска. У нас снова есть шаблон в каталоге /etc/bind. В данном случае он называется db.127 . Скопируем его в файл reverse.hackers-arise.local.
kali > cp db.127 reverse.hackers-arise.local
Затем откроем этот файл с помощью Leafpad.
Кали > листовая панель /etc.bind/reverse.hackers-arise.local
Давайте теперь внесем несколько изменений.
В разделе «Ваш сервер имен» добавьте:
основной.ваш домен.локальный.
IP-адрес сервера имен
В разделе «Обратный поиск» добавьте:
последний октет IP-адреса NS и primary.your domain.local.
В разделе «Записи PTR» добавьте:
последний октет веб-сервера и www.ваш домен.локальный
последний октет почтового сервера и mail.your domain.local.
4. На последнем этапе нам просто нужно перезапустить службу, чтобы наши изменения вступили в силу и вступили в силу.
kali > перезапуск службы bind9
Для тех из вас, кто предпочитает новые команды systemd, это работает ничуть не хуже.
kali > systemctl restart bind9
Теперь наш сервер BIND готов разрешать DNS-запросы в нашей локальной сети!
