Network: заметки о DNS, OpenDNS (Cisco Umbrella)

  • public DNS, использовать рекомендуется только для траблшутинга т.к. в теории возможен перехват запроса и подмена DNS ответа, если запрос не зашифрован (чаще всего) CloudFlare Google Google Level3 (от до OpenDNS (Cisco Umbrella) OpenDNS (Cisco Umbrella)
2620:119:35::35 OpenDNS (Cisco Umbrella)
2620:119:53::53 OpenDNS (Cisco Umbrella)
  • DNS запросы/ответы обычно передаются в виде UDP, но если ответ слишком большой, то DNS сервер может отправить ошибку клиенту, после которой клиент подключится к серверу по TCP.
  • A DNS sinkhole, also known as a sinkhole server, Internet sinkhole, or Blackhole DNS is a DNS server that gives out a false result for a domain name. A sinkhole is a DNS provider that supplies systems looking for DNS information with false results, allowing an attacker to redirect a system to a potentially malicious destination. DNS sinkholes have also historically been used for non-malicious purposes.
  • DNS tunneling – когда мы передаем поверх DNS что-то отличное от DNS трафика. Причем это не всегда (но чаще всего) злонамеренное поведение, DNS tunneling by design используется для ААА в аэропортах/отелях при получении доступа в интернет, при обновлении сигнатур антивируса. Подробнее о DNS tunneling можно почитать на сайте Cisco Umbrella (они знают многое о DNS). Примеры злонамеренного поведения – data exfiltration, command and control callbacks, guest WiFi abuse, IT policy avoidance
What is DNS tunneling? DNS tunneling utilizes the DNS protocol to communicate non-DNS traffic over port 53. It sends HTTP and other protocol traffic over DNS. There are various, legitimate reasons to utilize DNS tunneling. For example, DNS tunneling is often used as a login mechanism for hotspot security controls at airports or hotels to access internet. DNS tunneling is also used by antivirus to look up signatures for files. However, there are also malicious reasons to use DNS Tunneling VPN services. 

The following are the most common types of DNS abuse:
• Data exfiltration - attackers encode data in outbound DNS requests to specialized infrastructure. These queries are decoded and joined to reconstruct the exfiltrated data. The payload initiates thousands of unique DNS record requests to the attacker’s domain with each string as a part of the domain name (e.g. 3KJ242AIE9.BADGUY[.] RU). Depending on the attacker’s patience and stealth, requests can be spaced out over days or months to avoid suspicious network activity.
• Command and control callbacks - attackers send commands in DNS responses to compromised systems, allowing remote management of an infected device. Malware that communicates using DNS Tunneling often uses components of open source DNS Tunneling software which is modified to accept commands from the C2 server through DNS responses (e.g. open remote access, log keystrokes, laterally move to a connected system, download new payloads, send spam, participate in a DDoS attack, or other common malicious activities). These responses are received by the malware, which rebuilds the command and the compromised system acts on it.
• Guest WiFi abuse && IT policy avoidance - users install a free DNS tunneling tool, such as Iodine or Tunnel Guru, to bypass the network authorization infrastructure in order to obtain free internet access in hotels and airports (see figure 3) or bypass IT policies and/or monitoring. *Note: Different types of DNS record requests may be used based on how much information needs to be communicated. The most common record types are ‘A’ or ‘AAAA’ to store IPv4 or IPv6 addresses, respectively. But many other types (e.g. TXT, CNAME, SRV, ANY) are available to store more information. Transmission speeds up to 100 kbps are possible using ‘TXT’ DNS records. With these DNS abuse types the user installs a commercially available DNS tunneling VPN application. Then they use the app to establish a VPN tunnel via DNS, bypassing corporate security measures including policy and monitoring.

Overall, DNS traffic has become more complex with the widespread adoption of extended DNS, DNSSEC, content delivery networks, and other technologies. Therefore, next-gen firewalls (NGFW) or intrusion prevention systems (IPS) often cannot detect DNS tunneling over port 53. Simplistic defenses, such as blocking all ‘TXT’ DNS records, can disrupt legitimate protocols (e.g. SPF, DKIM) and attackers may use other common record types (e.g. CNAME). And as soon as mobile employees leave your network, NGFW/IPS and other defenses are entirely bypassed.

Umbrella terminates resolution so that malicious DNS requests are never sent to the attacker. 
Optionally, security teams can leverage Umbrella’s simple integration with Amazon S3 to retain all DNS logs, including record type, for months or years. SIEMs (e.g. Splunk) with pre-built Amazon S3 integrations can process these DNS logs using their security analytics to detect suspicious activity such as DNS tunneling.
  • DNS требует 12-байтного заголовка и наличия одгого или нескольких вопросов в этом запросе

DNS is a request/reply protocol. Its queried consist of a 12-byte fixed-size header followerd by one or more questions.

  • Никогда не забываем что host файл смотрится перед запросом к DNS, причем даже на телефонах
  • DNSSEC – безопасный DNS. Подробнее в security.
  • Многие реализуют отказоустойчивость на базе подмены записи в DNS: в случае нарушения работоспособности основного сервера DNS запись переключается на резервный сервер.

Типы DNS серверов (любой DNS может выполнять все роли) и зон:

  • Recursive – выполняют full-resolution (начиная от Root, кончая Authoritive) DNS-запрос для резолва имени в IP. Обычно это сервера ISP/LAN, чаще всего роли recursive и cashing выполняются на одном сервере.
  • Cashing – сохраняют информацию из ответа на какое-то время в памяти, чтобы не делать full-resolution DNS-запрос при обращении к тому-же домену. Обычно это сервера ISP/LAN, чаще всего роли recursive и cashing выполняются на одном сервере. Время хранение записи о FQDN можно ограничить используя DNS TTL – администратор сайта может в конфигурации зоны задать максимальное количество секунд (обычно счет в минутах для сайтов типа google/yandex/amazon, часах и реже днях для обычных) хранения записей в cash до удаления на DNS-серверах, которые запрашивают резолв домена из зоны. Кеш так же есть и на обычных ПК, поэтому запросы DNS могут совсем отсутствовать после заполнения кеша. Посмотреть TTL можно используя nslookup в интерактивном режиме и установив set debug.
  • Root – корневые сервера, отвечают за за root зону, отдают в ответе на запрос адреса серверов доменов верхнего (Top level domain (TLD) like .com, .net, .ru). Их формально всего 13 штук, посмотреть непосредственно на сайте или в wiki.
  • TLD (top level domain) – сервера доменов верхнего уровня, отвечают за конкретную TLD зону, отдают в ответе на запрос адреса серверов домена второго уровня (Authoritive like,
  • Authoritive – отвечают за резолв домена и нижестоящих доменов (напр.,, За домены третьего уровня ( уровня может отвечать как один сервер, так и специальный сервер для каждого домена (основной сервер выдает с помощью SOA записи сервер, ответственный за нижестоящую зону).

DNS записи бывают разных типов. Используя nslookup можно запросить не только A-запись, но и другие. Весь список DNS-записей можно посмотреть тут, ниже самые популярные:

  • Запись А – указывает IPv4 для доменного имени. Основная запись. В общем случае под DNS-запросом имеется именно запрос А записи. В базовом случае одна А-запись указывает на один домен, но может быть и несколько А-записей для одного домена. Несколько записей позволяют реализовать DNS round robin (balancing, redundancy) – список серверов для каждого клиента будет один, но в разном порядке (1-2-3-4, 2-3-4-1, 3-4-1-2, etc).
Вообще Round Robin используется во многих системах, например в QoS очереди могут диспетчеризироваться по алгоритму Round Robin. Но чаще используется Weighted Round Robin (WRR), который позволяет указывать вес каждой очереди (напр. на 3 пакета очереди №1 отдает 1 пакет очереди №2). К этому может добавляется Priority Queuing - при получения пакета из этой очереди он в любом случае отдается первым, а остальное на основе WRR. В результате рождается конструкция 1 PQ + 3 WRR. Цифры обозначают количество очередей.
  • Запись AAAA (quad A) –  аналог Записи A, только возвращает IPv6 адрес для доменного имени.

  • Запись MX (mail exchange) – указывает способ маршрутизации mail. Тут указывается почтовый сервер (MTA), на который нужно перенаправлять почту для этого DNS домена.
  • Запись CNAME – используется для перенаправления с одного домена на другой, в том числе в кейсе -> (можно сделать две или несколько A-записей, но проще и лучше одну CNAME)
  • Запись SRV – service record, используется для указания местоположения разных конкретных сервисов (не только для почты, как MX). Например сервер SIP, CalDAV, etc.
  • Запись TXT – изначально предполагалось использование как описание для домена, но произвольная форма позволила использовать его в других назначениях – передавать данные, которые не относились изначально к роли DNS. Например, настройки конфигурации, верификации сайтов, дополнительной информация о электронном письме. Его так же используют для передачи домена от одного хозяина домена или регистратору другому – настроив в TXT нужную информацию для регистратора/админа-приемника, регистратор/админ-приемник понимает, что ты управляешь доменом и соглашаешься на его миграцию.
  • Записи SOA (Start Of Authority) – используется в файле dns-конфига для указания сервера, ответственного за какую-то зону.
  • Запись NS – указывает на дополнительные DNS сервера, которые отвечают за запрашиваемую зону, используется для отказоустойчивости
  • Запись PTR (Pointer Resource Record) – хранит информацию для Reverse lookup. Reverse lookup позволяет получить по IP хоста его FQDN. Используется в почте для проверки адресата.


Linux DNS

Настроить DNS-сервера, которые будут использоваться локальной системой для разрешения доменных имен в IP адреса легко с помощью resolvconf сервиса, читающего конфигурацию из /etc/resolv.conf (модификации пользователя делаются в head файле). Подробнее тут.

sudo apt install resolvconf
sudo systemctl start resolvconf.service
sudo systemctl enable resolvconf.service
sudo systemctl status resolvconf.service

vi /etc/resolvconf/resolv.conf.d/head



nslookup без всего на FQDN  выдает А запись для домена через DNS сервер по умолчанию. Аналог nslookup – dig.
Используя интерактивный режим можно изменить это поведение:
1) задав переменную server (просто прописав в интерактивном режиме server x.x.x.x) можно поменять DNS для резолва
2) задав set type=MX/AAAA/TXT/NS можно запросить информацию по конкретному типу
3) задав set debug можно увидеть все-все
Пример разбора запроса-ответа на A record.
$ sudo tcpdump -i eth0 -vn host and port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:02:36.484819 IP (tos 0x0, ttl 64, id 32534, offset 0, flags [none], proto UDP (17), length 68) > 64482+ [1au] A? (40)
21:02:36.486077 IP (tos 0x0, ttl 115, id 11509, offset 0, flags [none], proto UDP (17), length 84) > 64482$ 1/0/1 A (56)

The first packet is the DNS query, which is our question (from the second terminal) going to the server. Note that, in this case, the traffic is UDP. Tcpdump's analysis of the DNS query begins right after the UDP checksum field. It starts with the DNS ID number, followed by some UDP options, then the query type (in this case A? which means we're asking for an A record). Next is the domain name we're interested in ( The second packet is the response from the server, which includes the same DNS ID from the original query, followed by the original query. After this is the answer to the query, which contains the IP address associated with the domain name.
Запрашиваем A запись о домене у DNS
dig @ A



Файл hosts

Есть во всех ОС. Может быть полезен и в легитимных целях (как ни странно :)) – например, доступ к клону тестируемого сервера по домену.



Cisco Umbrella, OpenDNS

Cisco Umbrella – enterprise решение на основе OpenDNS.

    • OpenDNS хорош для родительского контроля или защиты не разбирающихся в ИТ членов семьи – детей, пожилых родителей.
    • Umbrella по сути тот же продукт, но заточен под корпоративный сегмент.
Ключевые характеристики, модули и описание работы
  • Анализ DNS запросов – это то, на что полностью полагается Cisco Umbrella (OpenDNS) при решении о блокировке/разрешении/перенаправлении на proxy (secure internet gateway) трафика на определенный домен.
    • Примеры того, что может быть выявлено на основе запроса пользователя (User request patterns):
      • Compromised systems – компроментированные системы
      • Command and control callbacks – вызовы СС
      • Malware and phishing attampts – домены
      • Algorithm-generated domains – сгенерированные алгоритмом домены
      • Domain co-occurences – совпадения доменов
      • Newly registered domains – новые домены
    • Анализ множества запросов позволяет выявить следующие проблемы (Authoritative DNS logs):
      • Newly staged infrastructures – недавно скомпрометированную инфраструктуру
      • Malicious domains, IPs, ASNs – опасные адреса
      • DNS hijacking/poisoning/redirection/spoofing – подмена DNS запросов, например, используется в Китайском Great Firewall. Если видим в запросе DNS заблокированный ресурс – можем даже не блокировать ответ, а ответить раньше, чем это сделает реальный сервер (аналогия rogue DHCP).
Contrary to popular belief,[41] foreign DNS resolvers such as Google Public DNS IP address are reported to work correctly inside the country;[42] however, these DNS servers are also subject to hijacking as their connections aren't encrypted: DNS queries do reach the DNS server, but if the request matches a banned keyword, the firewall will inject a fake DNS reply before the legitimate DNS reply arrives.
Typical circumvention methods include modifying the Hosts file, typing the IP address instead of the domain name in a Web browser or using DNS over TLS/HTTPS.
      • Fast flux domains – быстро изменяющиеся домены
      • Related domains – связанные (опасные или наоборот) домены

  • В основе решения используется anycast ip адреса, анонсируемые из большого количества (десятки) датацентров со всего мира с пирингом по BGP для обмена BGP маршрутами с основными ISP и CDN сетями (более 500 соседств) для реализации эффективной маршрутизации запросов. Это позволяет реализовать CDN с использованием ближайшего сервера для клиентов и реализовать отказоустойчивость. Все сервера обрабатывают более 100 млрд запросов в день.
  • При получении запроса OpenDNS (Umbrella)
    • сначала определяет источник/клиента запроса для определения политик (списки вайтлистов и блеклистов могут быть уникальны).
    • далее OpenDNS классифицирует запрос – определяет на основе данных Talos, Web Reputation System (security intelligence) и определенных ранее политик клиента является ли запрос
      • безопасным (green, whitelisted, trusted) – они маршрутизируются без дальнейших проверок
      • небезопасным (red, blacklisted, malicious) – они блокируются (резолвинг на block page) без дальнейших проверок
      • неопределенным (gray, risky) – они могут быть смаршрутизированы на cloud based proxy (Secure Internet Gateway) для глубокой инспекции. Это могут быть домены, которые хостят как опасный, так и не опасный контент, например facebook, reddit, pastebin, github и проч, которые позволяют пользователям заливать контент.
  • Umbrella позволяет увидеть многие атаки даже до того, как приложения организуют свою связь, что помимо защиты так же позволяет уменьшить нагрузку на другие средства безопасности.
  • Umbrella может использоваться на любых устройствах, включая IoT за счет простоты своей работы. Причем настройка DNS не обязательно должна затрагивать каждый хост – запросы к Umbrella может перенаправлять корпоративный DNS сервер, когда запросы относятся к не-корпоративным доменам.
  • Так же можно использовать Umbrella VM для шифрования запросов в облаков из корпоративной сети или (как понимаю) шифровать запросы к umbrella с использованием Cisco Anyconnect Umbrella (roaming client for windows/osx) или Cisco Security Connector для IOS.
  • Cisco Umbrella Investigate ( – предоставляет организациям единый доступ к скореллированным вместе глобальным данным (global intelligence) talos и другим intelligence (напр. whois, cve, reputation, asn, etc ниже), которые могут обогатить эвенты по безопасности данными или предоставить вам дополнительные данные во время инцидента (для устранения, предотвращения или предупреждения атак). Функционал требует отдельную лицензию. Доступ к данным investigate возможен как через web консоль, так и через API. Так же отсюда можно получить данные Cisco Treat Grid. Investigate:
    • Passive DNS Database – хранит историю DNS
    • Malware File Analysis – интегрирован AMP Threat Grid для детектирования malware
    • Autonomous System Number (ASN) – IP to ASN mappings
    • WHOIS Record Data
    • IP Geolocation
    • Domain and IP Reputation Scores – оценка опасности домена
    • Domain Co-Occurrences – возвращает список доменных имен, которые резолвятся (looked up) в одно время с доменом, который проверяется. Оценка рядом с доменным именем – это мера запросов от клиентских IP для соответсвующих доменов (related domains). Co-Occurrences за предыдущие семь дней показываются независимо от того является ли Co-Occurrence подозрительным или нет.
    • Anomaly Detection – позволяет обнаружить fast flux domains, automated generated domains – оценка от 100 (подозрительно) до 0 (не подозрительно) которая расчитывается как вероятность того, что домен сгенерирован автоматически.
    • DNS Request Patterns and Geo Distribution of Requests – позволяет увидеть всплески глобальных запросов к определенным доменам
  • Umbrella Secure Internet Gateway (SIG) – cloud base прокси, на который перенаправляется только часть трафика, в отличии от классических прокси, которые работают со всем трафиком (что требует явно больше ресурсов, вносят задержку и для явно легитимных запросов). Принцип того, что перенаправляется через прокси у SIG простой – перенаправляется трафик при запросах в «серые» зоны (risky/gray domains). Подробнее о зонах (красные/зеленые/серые) выше. Итоговое разрешение или не разрешение трафика зависит так же как при определении категории запроса от security intelligence (talos, web reputation score by third parties) данных применительно к url и контенту ответа: причем сначала SIG анализирует URL и только есть решение о разрешении/блокировке не принято на основе URL (т.е. запрос так и остался в категории risky) осуществляет проксирование запроса и анализ ответа ((хотя в ролике про это ничего не сказали, но думаю это так)). Так же SIG оценивает репутацию файлов с исользованием антивирусных движков и AMP для блокировки файлов с известными сигнатурами.
Настройка OpenDNS

Простейшая по факту настройка:

    • прописываем DNS адреса Cisco Umbrella (OpenDNS) OpenDNS (Cisco Umbrella) OpenDNS (Cisco Umbrella)
2620:119:35::35 OpenDNS (Cisco Umbrella)
2620:119:53::53 OpenDNS (Cisco Umbrella)
    • выбираем свою сеть (для /32 белого IP достаточно подтвердить этот адрес)
      • опционально ставим утилиту OpenDNS-Dynamic-IP-updater-client, которая путем периодических проверок на сервере будет обновлять динамически меняющийся белый IP
    • накладываем политики на эту сеть – запрещенные категории (используя профиль или вручную настраивая категории) или конкретные сайты
      • опционально кастомизируем баннер для сети (можно указать свой логотип/описание причин блокировки)
      • опционально включаем статистику для сети

Leave a Reply