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

Разное

• As codified in RFC 6555 Happy Eyeballs is the idea that you should try to look for both an IPv4 and IPv6 address when doing a DNS lookup. Whichever returns first, wins.
• К Google DNS можно обратится через WEB сайт dns.google и получить результат в виде json, в том числе получить разные типы записей (A, AAAA, MX, etc)

  https://dns.google/query?name=weril.me
  {
  "Status": 0 /* NOERROR */,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
  {
  "name": "weril.me.",
  "type": 1 /* A */
  }
  ],
  "Answer": [
  {
  "name": "weril.me.",
  "type": 1 /* A */,
  "TTL": 21600,
  "data": "95.217.180.203"
  }
  ],
  "Comment": "Response from 2a00:f940:4::47."
  }

  https://dns.google/query?name=redkin.net&rr_type=MX&ecs=
  {
  "Status": 0 /* NOERROR */,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
  {
  "name": "redkin.net.",
  "type": 15 /* MX */
  }
  ],
  "Answer": [
  {
  "name": "redkin.net.",
  "type": 15 /* MX */,
  "TTL": 21600,
  "data": "10 mx.yandex.net."
  }
  ],
  "Comment": "Response from 194.58.117.14."
  }

• символ @ ampersand это обозначение самого домена

It's the root, or in your example it's mydomain.com.

• public DNS, список самых популярных с response time тут; использовать рекомендуется только для траблшутинга без DNSSec (DNS-over-HTTPS или DNS-over-TLS) т.к. с большей вероятностью (количество хопов) возможен снифинг или даже перехват незашифрованного DNS запроса и подмена DNS ответа

# Russia 
77.88.8.8,88,7  # Yandex Basic, Secure, Child
77.88.8.1,2,3   # Yandex Basic, Secure, Child
85.21.192.3 Beeline 
85.21.192.5 Beeline 
213.234.192.7 Beeline 
213.234.192.8 Beeline

# World
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)   # проверка работы umbrella
208.67.220.220 OpenDNS (Cisco Umbrella)   # проверка работы umbrella
2620:119:35::35 OpenDNS (Cisco Umbrella)  # проверка работы umbrella
2620:119:53::53 OpenDNS (Cisco Umbrella)  # проверка работы umbrella

• Популярные сервера:
  • BIND
  • UNBOUND
  • Cisco CNR
• 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 TTL игнорировать! , reddit), которые запрашивают резолв домена из зоны. Кеш так же есть и на обычных ПК, поэтому запросы 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. Тут указывается почтовый сервер (MTA), на который нужно перенаправлять почту для этого DNS домена. Именно MX записи резолвят почтовые клиенты.
• Запись SPF (Sender Policy Framework) — это список IP-адресов в виде буквенного кода, который прописывается в настройках домена и содержит информацию о серверах, с которых владелец разрешает отправлять письма. Я для своих доменов настроил spf на яндекс.

v=spf1 redirect=_spf.yandex.net

На всякий случай уточню такой нюанс: SPF-запись для домена в DNS делается только одна. И в неё уже включаются все IP-адреса, с которых допустима отправка писем.

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).

• Запись 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. Используется в почте для проверки адресата.

Файл hosts

Есть во всех ОС. Может быть полезен и в легитимных целях (как ни странно :)) – например, доступ к клону тестируемого сервера по домену. Файл hosts в Windows/Linux не поддерживает wildcard домены в виде *.example.com. Для обхода проблемы рекомендовано использовать dnsmasq.

# Windows
   c:\windows\system32\drivers\etc\hosts
      192.168.0.246 google.ru

# Linux
   /etc/hosts

DNS Cache (кеш)

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

https://www.ibm.com/docs/en/was-zos/8.5.5?topic=SS7K4U_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tprf_tunetcpip.html

You should ensure that your DNS configuration is optimized so that lookups for frequently-used servers and clients are being cached.

Caching is sometimes related to the name server's Time To Live (TTL) value. On the one hand, setting the TTL high will ensure good cache hits. However, setting it high also means that, if the Daemon goes down, it will take a while for everyone in the network to be aware of it.

когда dns использует tcp

• Большинство DNS-запросов происходит с использованием протокола UDP. При этом есть ряд исключений:
  • Если клиент не получает ответ от DNS, он должен повторно отправить данные с помощью TCP через 3–5 секунд интервала.
  • TCP используется для передачи зоны (zone transfer)
  • Протокол TCP должен использоваться для обмена данными размером более 512 байт – если сообщения/запросы DNS превышают размер 512 байт ((Возможно это уже частично не актуально – появился EDNS0 и 512 байт уже не актуально, как минимум для клиентов, которые это расширение поддерживают (после 2013го))

Из канала https://t.me/network_quiz

✍️ Разбор квиза: NQ DNS на TCP
Вопрос: При каких условиях DNS переходит на работу по TCP?
Объяснение от автора вопроса Surgeon: Всем известно, что DNS работает по UDP на порту 53. Но IANA для DNS выделила 53 порт и для UDP, и для TCP. Зачем для DNS протокол TCP и когда он работает поверх UDP? Напомним, что в отличие от TCP, у UDP нет функции сегментации трафика при превышении MTU, что ведёт к фрагментации такого трафика и проблемам. Более того, размер UDP датаграммы ограничен 512 байтами (хотя современная реализация протокола и позволяет использовать больший размер, DNS по умолчанию до сих пор использует ограничение в 512 байт). Становится очевидным, что DNS переключается на TCP при превышении размера ответа в 512 байт. Как и когда это происходит?1️⃣ По умолчанию, запрос передачи зоны AXFR работает поверх TCP, так как необходимо передать большое количество данных.
2️⃣ При отсутствии EDNS0, при превышении ответа в 512 байт, сервер отправляет неполный ответ с флагом TC (truncated), тем самым заставляя клиента переключиться на TCP. Подобного типа ответы могут быть на запрос записей типа TXT, для работы DNSSec. Пример:  
dig google.com +trace +bufsize=0

В дампе можно увидеть ТС=1 и переключение клиента на TCP. Значение +bufsize=0 отключает EDNS0 на стороне клиента.
3️⃣ При наличии опции EDNS0, клиент отправляет информацию о том, что он готов принять больший размер датаграммы, что значительно снижает вероятность переключения на TCP.
В этом случае сервис переключается на TCP, если размер ответа превышает значение размера, отправленного клиентом. #netquiz_explanation #netquiz_dns
Источники: RFC 5966, RFC 1123, RFC 2671, RFC 5625

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
nameserver 8.8.8.8
nameserver 8.8.4.4

NSLOOKUP & DIG & host

$ nslookup pornhub.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: pornhub.com
Address: 66.254.114.41

$ nslookup pornhub.com 77.88.8.3
Server: 77.88.8.3
Address: 77.88.8.3#53
pornhub.com canonical name = safe2.yandex.ru.
Name: safe2.yandex.ru
Address: 93.158.134.250

$ 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.

dig @8.8.8.8 A example.com

Host – simple lookup, по умолчанию предоставляет все ключевые записи (A, AAAA, MX) для домена, которые есть.

# host weril.me
weril.me has address 95.217.180.203

# host redkin.net
redkin.net has address 95.217.180.203
redkin.net mail is handled by 10 mx.yandex.net.

# host ya.ru
ya.ru has address 5.255.255.242
ya.ru has address 77.88.55.242
ya.ru has IPv6 address 2a02:6b8::2:242
ya.ru mail is handled by 10 mx.yandex.ru.

DNS Security

Почему DNS безопасность важна:

• According to Palo Alto Networks Unit 42 threat research team, almost 80 percent of malware uses DNS to initiate command-and-control (C2) procedures. Unfortunately, security teams lack basic visibility into how threats use DNS to maintain control of infected devices.
• PaloAlto (так же как и Fortinet) DNS безопасность/безопасность на базе ML реализует на основе облачных решений, не в коробке NGFW, частично это связано с ресурсо-интенсивностью задачи и требованиям к задержкам трафика и сервисными моделями подписки, но во многом так же и тем, что основывать решения только на анализе одного запроса в конкретном месте менее точно, чем имея информацию с разных мест (подробнее ниже – напр. rate statistics).

Provide limitless protection against malicious domains with a cloud-based database for infinite scale. Your protections are always up to date, whether 10,000 or 100,000,000 new malicious domains are created in a single day. As part of the cloud-based service, all DNS queries are checked against our infinitely scalable, cloud-based database in real time to deter- mine appropriate enforcement action.

Seamlessly take advantage of the latest DNS security innovations through our extensible, cloud-based architecture. The DNS Security service is built on a modular, cloud-based architecture to seamlessly add new detection, prevention, and analytics capabilities with zero customer impact. We will continue to use our rich shared threat intelligence and native enforcement capabilities to deliver new innovations against attacks using DNS.

Protection Without Performance Impact
Advanced security is seamlessly applied to DNS queries in real time with no business impact. The service is hosted on our global security service delivery network to provide the low latency and high performance necessary to minimize impact to DNS traffic on customer networks.

• Статистика OpenDNS

  91.3% of malware uses DNS
  68% of organizations don’t monitor it

Источники:

• Пример техник обеспечения безопасности DNS от PaloAlto.
• Пример практической работы DNS защиты (так же от PA).

Overview

Функционал PaloAlto по обнаружению опасных DNS доменов/операций. Часть (туннелирование, DGA) детально описано ниже в отдельных разделах.

• • Command and Control Domains
    • DNS Tunnel Detection
    • DGA Domain Detection
    • NXNSAttack
    • DNS Rebinding
    • DNS Infiltration
  • Dynamic DNS Hosted Domains
  • Malware Domains
    • Malware Compromised DNS
  • Newly Registered Domains
  • Phishing Domains
  • Grayware Domains
  • Parked Domains
  • Proxy Avoidance and Anonymizers

Разное

DNS tunneling

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.

DGA

DGA – Domain generation algorithms – генерация доменных имен на основе rand/date/time/dictionary/etc, в последующем один их этих доменов (при регистрации хакером) может использоваться как C&C.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/threat-prevention/dns-security/domain-generation-algorithm-detection
Domain generation algorithms (DGAs) are used to auto-generate domains, typically in large numbers within the context of establishing a malicious command-and-control (C2) communications channel. DGA-based malware (such as Pushdo, BankPatch, and CryptoLocker) limit the number of domains from being blocked by hiding the location of their active C2 servers within a large number of possible suspects, and can be algorithmically generated based on factors such as time of day, cryptographic keys, or other unique values. While most domains generated by a DGA do not resolve as a valid domain, they must all be identified to fully defend against a given threat. DGA analysis determines whether a domain is likely to have been generated by a machine, rather than a person, by reverse-engineering and analyzing other frequently used techniques found in DGAs. Palo Alto Networks then uses these characteristics to identify and block previously unknown DGA-based threats in real-time.
You can analyze the sinkholed DNS queries by viewing the threat logs (Monitor > Logs, then select the log type from the list):

Использование DGA увеличивает вероятность связи с C&C сервером в сравнении с вариациями hardcoded IP, hardcoded domains fastflux.

Обычно анализ DGA работает совместно с whitelist/репутационными списками для минимизации FP.

Palo Alto Networks also generates and maintains a list of explicitly allowable domains based on metrics from PAN-DB and Alexa. These allow list domains are frequently accessed and known to be free of malicious content.

Чаще всего используемые в методах подходы для генерации псевдо-рандомных доменных имен.

DGA:
1) seed domain
2) dictionary
3) pseudorandom/hash

Защита от DGA в целом основывается на базе Nxdomain lookups & Spike/Query rate statistics, “N-gram” analysis, Entropy analysis, SPRank/NLPRank, machine learning – пример алгоритмов/техник, на основе которых могут быть приняты решения о принадлежности к DGA.

https://www.cisco.com/c/dam/m/sl_si/events/2016/cisco_dan_inovativnih_resitev/pdf/new_advanced_cisco_security_solutions_-_opendns.pdf
https://umbrella.cisco.com/blog/mysterious-dga-lets-investigate-sgraph
https://www.elastic.co/blog/supervised-and-unsupervised-machine-learning-for-dga-detection

For the past two weeks, since Oct 9th, we’ve observed a high volume of periodic nxdomain lookups in our DNS traffic to a number of Domain Generation Algorithm (DGA) domains.

On Oct 16th we observed the emergence of about 570+ related DGA domains that received lookups during the entire 24 hours of the day before dropping to no activity. On each of the following days, from Oct 17th to Oct 21st, we saw about 2100+ DGA domains display the same traffic pattern of constant lookups lasting exactly 24 hours then complete drop. Each day, there was a completely new set of DGA domains. In total, we saw 12000+ unique DGA domains in our DNS traffic over a period of 2 weeks.

“N-gram” analysis - Do sets of adjacent letters match normal language patterns?
Entropy analysis - Does the probability distribution of letters appear random?
SPRank detects domains showing as a sudden surge, or a spike, in DNS queries machine learning.

Anomaly detection job  may be useful for finding sources with aggregate high amounts of DGA activity rather than alerting on individual DGA scores one by one.

All of these domains are linked together via the related domains model, meaning they are looked up by the same set of client IPs during a short time period. Assuming these DGAs are malicious, this is an indication that they are likely generated by a single or similar malware samples. After careful empirical verification to make sure we are catching DGA domains that fit in our target set, we only keep domains that meet a certain traffic profile. This profile corresponds to a specific volume of traffic that spans only 24 hours. This filtering heuristic turns out to be efficient as no false positives were observed.

При этом не все DGA-lookups являются злыми – самые простые примеры с CDN, более сложные примеры с Chrome и легитимный DNS tunneling. False positives неизбежны.

No machine learning model is perfect! Some benign domains will be mistakenly labeled as false positives. These may come in the form of CDN traffic or custom domains that appear to be malicious but that are actually normal in the environment. 

However, not all DGA-like domains are necessarily malware related.

Exceptions can be added to the rules in order to ignore false positives such as content distribution network (CDN) domains that may use pseudorandom domain names.
For example, Chrome connects at startup to random domains to determine if you’re currently on a network that intercepts and redirects requests for nonexistent hostnames [1].
Or a seemingly random domain could be used as a form of DNS-tunneling where a request is encoded in the domain name, and depending on the DNS query type, a specific response is sent back to the client [2].

https://www.cisco.com/c/dam/m/sl_si/events/2016/cisco_dan_inovativnih_resitev/pdf/new_advanced_cisco_security_solutions_-_opendns.pdf
https://umbrella.cisco.com/blog/domain-generation-algorithms-effective

Although these requests to the NXdomains do not resolve, at OpenDNS, we still see the attempted request in our DNS query logs. Recently, I have found that analyzing these sessions of DGA requests in our logs has proven effective at surfacing other types of malicious domains that are queried in the event.
https://data.netlab.360.com/dga/
https://github.com/360netlab/DGA
https://github.com/PowerDNS/pdns

Our DGA Detecting System sifts through our massive pdns data and malware samples for the latest suspicious DGAs in real time.

https://www.elastic.co/blog/supervised-and-unsupervised-machine-learning-for-dga-detection
DNS events being enriched

event.category:network and 
network.protocol:dns and 
ml_is_dga.malicious_probability > 0.98

Cisco Umbrella, OpenDNS

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

• • OpenDNS хорош для родительского контроля или защиты не разбирающихся в ИТ членов семьи – детей, пожилых родителей. Аналогичные сервисы так же предлагает и CloudFlare – CloudFlare for Families.
  • 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 – подробнее ниже

Contrary to popular belief,[41] foreign DNS resolvers such as Google Public DNS IP address 8.8.8.8 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 (investigate.umbrella.com) – предоставляет организациям единый доступ к скореллированным вместе глобальным данным (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 для блокировки файлов с известными сигнатурами.

1 – запрос к Umbrella (Resolver)

2 – проксирование трафика к gray domain (Proxy)

Распределение нагрузки между батареей SIG в Cloud Cisco.

Umbrella API

Настройка OpenDNS

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

• • прописываем DNS адреса Cisco Umbrella (OpenDNS)

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)

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

dns poisoning

• hijacking/poisoning/redirection/spoofing – подмена DNS запросов, например, используется в Китайском Great Firewall. Если видим в запросе DNS заблокированный ресурс – можем даже не блокировать ответ, а ответить раньше, чем это сделает реальный сервер (аналогия rogue DHCP).
• Ниже многое на основе статьи блога Varonis

DNS cache poisoning — повреждение целостности данных в системе DNS путём заполнения кэша DNS-сервера данными, не исходящими от авторитетного DNS-источника.