Отправляет email-рассылки с помощью сервиса Sendsay

Сообщество системных администраторов Litl-Admin.ru

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 141 RSS
←   Декабрь 2013   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
10.12.2013
06:02:16
14:58:20
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
25.12.2013
05:56:29
09:35:59
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://litl-admin.ru
Открыта: 26-01-2012

Автор
seqular

Статистика

141 подписчиков
0 за неделю
←   Все выпуски   →

Сообщество системных администраторов Litl-Admin.ru Уроки Wireshark: Смотрим на DNS-трафик


Ссылка на материал

Привет всем! Пришла пора посмотреть на трафик DNS через увеличительное стекло WireShark-а.

Напоминаю, что протокол DNS служит для преобразования понятного людям символьного имени, такого как, к примеру, litl-admin.ru в IP адрес, на который выполняется запрос.

Качаем файл трафика.Открываем его в WireShark и смотрим:

Образец трафика DNS

Образец трафика DNS

Как видим, протокол DNS (в выделенной зоне он самый нижний — domain name system) является надстройкой в протокол UDP, лежащий на 4-ом уровне. То есть без установки постоянного соединения, а простой отправкой пакетов (дэйтаграмм). Как и TCP, протокол UDP имеет порты. Для DNS это порт с номером 53, что легко прослеживается в дереве протоколов.

Спускаемся ещё ниже, UDP протокол опирается на IP — протокол передачи между сетями. В настоящее время — основной протокол передачи данных в сети Internet. На этом уровне у нас имеется информация об IP-адресах источника и назначения. Ну и так же сведения об инкапсулированном пакете UDP.

В качестве адреса источника будет наша машина (запросившая информацию по DNS), а в качестве IP адреса назначения — сам DNS сервер, который (подразумевается), должен иметь базу данных таких соответствий.

В этой базе данных хранятся записи нескольких видов:

  • A (host) — связывает имя узла и его IP адрес;
  • AAAA (host) — связывает имя узла и его IPv6 адрес;
  • CNAME (alias) — связывает имя узла и его псевдоним, для перенаправления на другое имя узла;
  • MX (mail exchange) — указывает на IP адрес почтового сервера, обрабатывающего этот домен;
  • NS (name server) — указывает на DNS-сервер, обслуживающим данный домен;
  • SOA (start of authority) — указывает на начальную зону для этого домена, содержит IP основного DNS-сервера, адрес и контактные данные лица, владельца домена, временные метки и т.д.;
  • PTR (pointer) — указатель на обратную связь, преобразующую IP адрес в каноническое имя;
  • SRV (server) — указатель на различные сервисы;
  • Полный список записей можно посмотреть наhttp://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

Итак, вернёмся к нашему запросу. Рассматриваем первый пакет:

Стандартный запрос

Стандартный запрос

Как видим, если развернуть дерево информации в анализе пакета, то видно, что поступил запрос (Queries), получения стандартной записи хоста (Type: A) по имени (Name: www.iana.org). То есть в переводе с DNS на русский будет так:

«Эй, 68.87.76.178! Сообщи-ка мне, какой IP у чувака по имени www.iana.org, хочу ему кое-что сообщить».

Вот такие у них беседы протекают. На что сервер ему отвечат (пакет 2):

Вот такой ответ приходит

Вот такой ответ приходит

Здесь мы видим ответ на вопрос. Иначе говоря, DNS-сервер отвечает хосту, отправившему запрос:

«Эй, 71.198.243.158, ты спрашивал какой адрес у www.iana.org, так вот, его адрес 192.0.34.162!, теперь пиши ему напрямую»

Детально тут так же следовало бы обратить внимание на поля Flags, которые показывают характеристики запросов и ответов:

Характеристики запроса

Характеристики запроса

Здесь я снова обратился к 1-ому пакету, в котором происходит запрос на сервер.

Обратите внимание на Transaction ID: Это числовое значение должно повториться в ответе, что будет означать, что ответ именно на этот запрос.

Далее, поля флагов. Они различны для запроса и для ответа. WireShark весьма неплохо их интерпретировал, так что всё должно быть понятно:

Стандартное двухбайтовое поле, значения которого складываются из бит:

  • первый бит (1)показывает, что это запрос;
  • 2-5 биты (4) — что это стандартный запрос;
  • 7 бит (1) — что это не обрезанный запрос;
  • 8 бит (1) — рекурсивный запрос (т.е. если наш ДНС-сервер не знает IP хоста, который мы запросили, он сам уже будет опрашивать другие DNS-сервера, пока не найдёт ответ;
  • 10 бит (1) — зарезервирован;
  • 12 бит (1) — принимать неавторитетные ответы. Авторитетным называется ответ от сервера, если тот заявляет, что сам обслуживает данную зону. Если же сервер получил ответ от других серверов, то такой ответ для нас является неавторитетным.

Теперь рассмотрим флаги ответа:

Флаги ответа

Флаги ответа

Обратите внимание на ID транзакции. Она совпадает с ID предыдущего пакета.

  • Первый бит (1) — что это ответ;
  • 2-5 биты (4) — стандартный ответ;
  • 6 бит (1) — авторитетность ответа, если сервер сам обслуживает эту зону — вернётся «1″, если получил ответ из другого места — будет «0″;
  • 7 бит (1) — укороченный пакет. На тот случай, если ответ не умещается в размер UDP датаграммы (512 байт);
  • 8 бит (1) — желательно использование рекурсивных запросов. Если флаг будет стоять в «0″, то в ответе клиент получит список других серверов, от которых он может попытаться узнать нужную информацию.
  • 9 бит (1) — сервер делает рекурсивные запросы;
  • 10 бит (1) — зарезервирован;
  • 11 бит (1) — получен авторитетный ответ, то есть сервер сам обслуживает эту зону;
  • 12 бит (1) — принимать неавторитетные ответы?
  • 13-16 биты (4) — код ошибки. Если 0, то всё в порядке.

Ну в целом разобрались со стандартными вопросами-ответами по DNS.

Кстати, существовал троян, который похищал данные с компьютера, отправляя их в виде DNS-запросов на сервер. Представляете себе, как это. Большинство файрволлов разрешает DNS, это ведь нормальная работа клиентского компьютера. А червяк под видом DNS-запросов отсылал на «левый» DNS-сервер приватные данные. Мол, «эй, сервер хозяина, скажи мне IP узла с именем «почта xxx@xxx.xx, пароль yyyyy»?». А сервер фиксировал запросы и мог отправлять ничего не значащие ответы, тем самым записывая все запросы в какой-то файл. Количество DNS-запросов был большим и под их видом можно было передать мегабайты данных совершенно незаметно для пользователя. Если специально не прослушивать трафик, то утечку данных обнаружить не реально.
В избранное