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

Разное
  • DNS запросы/ответы обычно передаются в виде UDP, но если ответ слишком большой, то TCP сервер может отправить ошибку клиенту, после которой клиент подключится к серверу по TCP.
  • 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.
  • public DNS, использовать рекомендуется только для траблшутинга т.к. в теории возможен перехват запроса и подмена DNS ответа, если запрос не зашифрован (чаще всего)
1.1.1.1 CloudFlare
8.8.8.8 Google
8.8.4.4 Google
4.2.2.4 Level3 (от 4.2.2.1 до 4.2.2.6)
208.67.222.222 OpenDNS (Cisco Umbrella)
208.67.220.220 OpenDNS (Cisco Umbrella)
2620:119:35::35 OpenDNS (Cisco Umbrella)
2620:119:53::53 OpenDNS (Cisco Umbrella)
  • DNS является тем, на что полностью полагается Cisco Umbrella (OpenDNS) при решении о блокировке/разрешении/перенаправлении на proxy (secure internet gateway) трафика на определенный домен. Настройка Cisco Umbrella простейшая
    • прописываем DNS адреса Cisco Umbrella (OpenDNS)
    • выбираем свою сеть (для /32 белого IP достаточно подтвердить этот адрес)
      • опционально ставим утилиту, которая путем периодических проверок на сервере будет обновлять динамически меняющийся белый IP
    • накладываем политики на эту сеть – запрещенные категории (используя профиль или вручную настраивая категории) или конкретные сайты
      • опционально кастомизируем баннер для сети (можно указать свой логотип/описание причин блокировки)
      • опционально включаем статистику для сети

  • Многие реализуют отказоустойчивость на базе подмены записи в 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 штук, посмотреть непосредственно на сайте http://root-servers.org или в wiki.
  • TLD (top level domain) – сервера доменов верхнего уровня, отвечают за конкретную TLD зону, отдают в ответе на запрос адреса серверов домена второго уровня (Authoritive like weril.me, redkin.net).
  • Authoritive – отвечают за резолв домена и нижестоящих доменов (напр. weril.me, life.weril.me, 11.22.33.weril.me). За домены третьего уровня (life.weril.me) уровня может отвечать как один сервер, так и специальный сервер для каждого домена (основной сервер выдает с помощью 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. Тут указывается почтовый сервер, на который нужно перенаправлять почту для этого DNS домена.
  • Запись CNAME – используется для перенаправления с одного домена на другой, в том числе в кейсе www.example.com -> example.com (можно сделать две или несколько 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.
NSLOOKUP & DIG
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 8.8.8.8 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)
10.0.0.2.40596 > 8.8.8.8.53: 64482+ [1au] A? example.com. (40)
21:02:36.486077 IP (tos 0x0, ttl 115, id 11509, offset 0, flags [none], proto UDP (17), length 84)
8.8.8.8.53 > 10.0.0.2.40596: 64482$ 1/0/1 example.com. A 93.184.216.34 (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 (example.com). 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 запись о домене example.com у DNS 8.8.8.8
dig @8.8.8.8 A example.com

Leave a Reply