Идентификация пакетов DNS - PullRequest
       6

Идентификация пакетов DNS

9 голосов
/ 27 сентября 2011

При поиске байт-кода пакета, как бы вы определили пакет DNS. Поле протокола заголовка IP сообщило бы, что следует кадр UDP, но внутри кадра UDP нет поля протокола, чтобы указать, что будет дальше, и, как я вижу, внутри кадра нет ничего, что бы однозначно идентифицировало бы его как пакет DNS. .

Ответы [ 2 ]

12 голосов
/ 27 сентября 2011

Кроме того, что он находится на порту 53, есть несколько вещей, которые вы можете посмотреть, которые могут дать подсказку , что вы смотрите на трафик DNS.

Я буду ссылаться на имена полей, используемые в §4.1 из RFC 1035 , здесь много:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Как вы можете видеть выше, заголовок имеет длину 12 байтов - 2 байта ID, 2 байта флагов и 4 x 2 байта отсчетов.

В любом DNS-пакете поле QDCOUNT будет ровно одним (0x0001). Технически протокол допускает другие значения, но на практике они никогда не используются.

В запросе (QR == 0) значения ANCOUNT и NSCOUNT будут точно равны нулю (0x0000), а ARCOUNT обычно будет 0, 1 или 2, в зависимости от того, EDNS0 (RFC 2671) и TSIG (RFC 2845) используются. RCODE также будет нулем в запросе.

Определить ответы несколько сложнее, если только вы не наблюдаете обе стороны разговора и не можете сопоставить каждый ответ с запросом, который его вызвал.

Очевидно, что бит QR будет установлен, и, как указано выше, QDCOUNT все равно должен быть равен единице. Остальные счетчики, тем не менее, будут иметь много различных вариантов. Однако чрезвычайно маловероятно, что какой-либо из счетчиков будет больше 255, поэтому вы должны полагаться на то, что байты 4, 6, 8 и 10 равны нулю.

После заголовков вы начнете находить записи ресурсов, первым из которых будет фактический вопрос, который был задан (§4.1.2). К сожалению, здесь разработчики протокола сочли целесообразным включить переменную длину поле метки (QNAME) перед двумя фиксированными полями (QTYPE и QCLASS).

[Чтобы еще больше усложнить ситуацию, метки можно сжать , используя указатель назад куда-то еще в пакете. К счастью, вы почти никогда не увидите сжатую метку в разделе «Вопросы», поскольку по определению вы не можете вернуться назад оттуда. Технически извращенный разработчик может отправить указатель сжатия обратно в заголовок, но этого не должно происходить].

Итак, начните читать каждый байт длины, а затем пропустите столько байтов, пока не достигнете нулевого байта, а затем следующие два 16-битных слова будут QTYPE и QCLASS. Существует очень мало допустимых значений для QCLASS, и почти все пакеты будут содержать значение 1 для IN («Интернет»). Вы можете иногда видеть 3 для CH (Хаос).

Пока это все - если я что-нибудь еще подумаю, я добавлю это позже.

0 голосов
/ 27 сентября 2011

Как насчет проверки номера порта?Должно быть 53 для исходного и целевого порта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...