Носов В.В. "Технології аудиту інформаційних систем"
Лекція 4. Методи і засоби попереднього збору інформації про комп'ютерну мережу: сервера DNS, топологія мережі
Навчальні питання
1.Система доменних імен DNS
2.Дослідження серверів DNS
3.Визначення топології мережі
Час: 2 акад. ч.
Література
1.Мамаев М., Петренко С. Технологии защиты информации в Интернете. Специальный справочник. – СПб.: Питер, 2002. – 848 с.
2.B!rd Feathery. DNS. Копаем глубоко. Журнал "Xakep", №069, стр. 26-28.
3.Мак-Клар Стюарт, Скрембрей Джоел, Курц Джордж. Секреты хакеров.
Безопасность сетей – готовые решения. : Пер. с англ. – М.: Издательский дом
"Вильямс", 2002. с. 29 – 52.
Вступ
После сбора сведений из открытых источников и формирования запросов к базе whois можно приступать к исследованию серверов DNS.
1. Система доменних імен DNS
Каждый компьютер в Интернете должен иметь свой собственный уникальный адрес, позволяющий связаться с ним любому другому компьютеру сети. Адреса компьютеров в Интернете (их называют IP-адресами) имеют две формы записи: числовой адрес и доменное имя.
Числовой IP-адрес представляет собой 32-битовый идентификатор компьютера. Для удобства записи он обычно разделяется на 4 октета по 8 битов в каждом, и каждый октет записывается в десятичной системе счисления; значения октетов разделяются точками. Например, IP-адрес
11000010 01010100 01111100 00110011
записывается как 194.84.124.51.
Числовой IP-адрес часто сопровождается также маской подсети (subnet mask или netmask), имеющей такую же структуру, как и адрес, и несущей дополнительную служебную информацию.
Числовая форма адреса используется компьютерами и специальным оборудованием обслуживания сети, для людей числовой адрес неудобен, плохо запоминается и несет мало смысловой информации. Люди обычно пользуются доменными именами, причем каждое доменное имя, как и числовой IP-адрес, определяет только один компьютер в Интернете.
Доменное имя состоит из нескольких слов или сокращений, разделенных точками, например: jet.vvsu.ru. Доменное имя несет полезную информацию о местонахождении компьютера. Крайняя правая часть имени обозначает домен верхнего уровня, то есть самую большую группу компьютеров, в которой находится данный компьютер. В нашем примере это ru - сокращение от Russia, Россия; этот домен верхнего уровня объединяет компьютеры, подключенные к Интернету в России. Внутри ru есть поддомены - области меньших размеров, например, msk.ru (Москва), nsu.ru (Новосибирский госуниверситет), primorsky.ru (администрация Приморского края); в нашем примере это vvsu.ru - компьютеры, подключенные к Интернету во Владивостокском госуниверситете экономики и сервиса. Крайняя левая часть доменного имени обозначает имя компьютера (jet) внутри своего поддомена (рис. 1).
Доменное имя не всегда имеет три части, но в любом случае крайняя правая часть обозначает домен верхнего уровня, крайняя левая - имя собственно компьютера, остальные, справа налево, - набор вложенных друг в друга поддоменов, где каждый следующий является
1
Носов В.В. "Технології аудиту інформаційних систем"
частью предыдущего. Например, sky.inp.nsk.su - Советский Союз (su), Новосибирск (nsk),
Институт ядерной физики (inp, Institute for Nuclear Physics), компьютер sky. Или ns.nsk.su -
Советский Союз, Новосибирск, компьютер ns. Интересно, что в географии Интернета Советский Союз все еще существует.
Домены верхнего уровня бывают двух типов. Первый представляет собой двухбуквенное сокращение названия страны, например, ru - Russia, Россия, su - Soviet Union, бывший Советский Союз, fr - Франция и т. д. Все сокращения являются стандартными и определены Международной организацией по стандартизации (ISO). Второй тип доменов верхнего уровня - общие домены - имеют трехбуквенные обозначения «по роду занятий». Изначально эти домены объединяли компьютеры, находящиеся в США (двухбуквенный домен us - United States - встречается довольно редко). Однако в последнее время общие домены com, org и net широко распространились за пределы Америки. В табл. 1 приведен список общих доменов верхнего уровня.
(root)
.ru |
|
.edu |
|
Домен .ru .com |
|
|
|
Узел
example.ru
.example |
|
.msu |
.spb |
|
|
|
|
.gw |
|
|
Узел |
.ns |
ns.example.ru |
||
|
|
|
|
Домен
example.ru
|
Рис. 1. Доменные имена |
|
Таблица 1. Общие домены верхнего уровня |
Домен |
Тип организации |
com |
Коммерческие организации (например, www.ibm.com - адрес компьютера в фирме |
|
IBM) |
edu |
Вузы США (например, strawb.mit.edu - адрес компьютера в Массачусетсом |
|
технологическом институте) |
gov |
Правительственные организации США (например, whitehouse.gov - сеть Белого дома) |
mil |
Военная сеть США (например, ns-hawaii.navy.mil - один из серверов ВМФ США) |
org |
Другие организации (например, isoc.org - сеть Общества Интернета) |
net |
Провайдеры Интернета и другие организации, имеющие отношение к |
|
функционированию сети (например,www.ripn.net - сервер Российского НИИ развития |
|
общественных сетей) |
int |
Международные организации, например www.nato.int |
Преобразование доменного имени в числовой IP-адрес осуществляется специальной службой Интернета, которая называется DNS (Domain Name System - Система доменных имен). Компьютеры, выполняющие такое преобразование, называются DNS-серверами. У каждого домена есть обслуживающий его DNS-сервер.
2
Носов В.В. "Технології аудиту інформаційних систем"
Во времена сети ARPANET имена компьютеров хранились в одном текстовом файле, который лежал на одной машине, обновлялся вручную, а затем рассылался на
все компьютеры в сети. Но сеть увеличивалась, файл становился очень большим, и совсем скоро стало ясно, что содержать и пересылать такой гигантский объем
информации очень неудобно и медленно. И в первой половине 80-х годов четверо аспирантов университета Беркли занялись реализацией распределенной системы, которая смогла бы поддерживать и динамически обновлять информацию об именах
компьютеров в сети. Итогом этой работы стал пакет программ BIND (Berkley Internet Name Domain), реализованный для UINX-систем. Именно от названия этой программы
пошло сленговое слово «забиндить». Теоретическая основа для создания этой системы была продумана чуть раньше и отражена в RFC882 и RFC883. А спустя 4 года появились еще два документа: RFC 1034 и RFC 1035. Они до сих пор остаются базовыми
описаниями DNS.
Итак, система DNS определяет:
-иерархически организованное пространство имен компьютеров, то есть то, как устроены и как соотносятся друг с другом имена машин;
-таблицу имен компьютеров в виде распределенной базы данных;
-библиотеку функций, осуществляющих запросы к базе;
-средства маршрутизации электронной почты;
-протокол обмена информацией между серверами DNS;
Хосту, подключенному к Интернету, система DNS нужна для полноценного участия
в работе Сети. Любая организация, имеющая свой сервер, так или иначе, должна хранить свой кусочек информации об именах машин. Все вместе они составляют
всемирную базу DNS. Эта информация хранится как минимум в двух текстовых файлах.
Файлы состоят из строчек (записей). Каждая запись имеет свой тип и состоит из нескольких полей.
К примеру, строки img IN A 213.180.194.65 и IN MX 67 mx1.yandex.ru в
файле зоны прямого преобразования и строка 65 IN PTR img.yandex.ru в файле зоны обратного преобразования говорят о том, что между именем img.yandex.ru и адресом 213.180.194.65 установлено соответствие.
DNS - это так называемая клиент-серверная система. Это значит, что часть
компьютеров являются серверами и хранят у себя в памяти информацию об именах
хостов, а также предоставляют ее по запросу остальным машинам (клиентам). Клиентами могут являться как хосты из внутренней сети, так и внешние компьютеры, не
входящие в структуру домена, который обслуживается сервером.
Все пространство имен DNS имеет древовидную структуру и называется деревом доменов. Корнем дерева является точка. Из корня «вырастают» домены первого уровня (RU, COM, NET, INFO и т.д.). У них, в свою очередь, есть свои «дети»: yandex.ru, icq.com, php.net и т.д. Одна половина дерева доменов содержит сведения для преобразования имен в IP-адреса, а другая, наоборот, - IP-адресов в имена хостов. В
первом случае говорят о прямом преобразовании, а во втором - об обратном.
Соответствующие названия носят и файлы: файл зоны прямого и обратного преобразования.
По идее, чтобы указать, что доменное имя является абсолютным, а не связанным с
некоторым доменом, отличным от корневого, в конце имени нужно ставить точку.
Например, если хост имеет имя «servak» в домене domain.ru и существует хост ya.domain.ru (вот такое длинное имя - домен четвертого уровня), то запрос с такого хоста по адресу ya.ru приведет вовсе не на сервер Яндекса, а на хост ya.domain.ru. Чтобы попасть на настоящий сервер Яндекса, нужно писать ya.ru. (с точкой в конце). Но такая ситуация с конфликтами доменных имен крайне маловероятна, в особенности
для обычного пользователя. Поэтому точку почти никогда не ставят.
3
Носов В.В. "Технології аудиту інформаційних систем"
Один компьютер может иметь несколько имен. К примеру, имена server.com и ftp.server.com имеет одна и та же машина. Вообще, называть хосты в соответствии с теми функциями, которые они выполняют, - очень распространенная практика: www.server.com, ftp.server.com, mail.server.com. Кроме того, бывает так, что одно и то же имя соответствует (резолвится) разным адресам. К примеру, имя mx1.yandex.ru имеют несколько разных серверов. Это сделано для того, чтобы
распределить нагрузку между всеми компьютерами и избежать обвала сервера под шквалом обращений к нему.
Типы DNS-серверов
Серверы различаются по:
-источнику данных (авторитетный, кэширующий, главный, подчиненный),
-пути прохождения запроса (переадресующий),
-типу выдаваемого ответа (рекурсивный, нерекурсивный)
-и нескольким другим параметрам.
Вкаждой зоне 1 (зоной называется домен без своего поддомена) обязательно
должны присутствовать как минимум два сервера. Эти серверы называются авторитетными. Администратор домена заносит в них информацию об именах машин внутри зоны (грубо говоря, о всех компьютерах с адресами тра-та-та.имя.ком), и эта
информация признается официальной и единственно правильной. Отсюда и название - авторитетный. Один из серверов получает статус главного. Именно его база корректируется, когда администратору нужно добавить или изменить какие-нибудь хосты
внутри домена. Второй сервер обязательно подчиненный. Он хранит точную копию базы
спервого сервера и нужен для повышения надежности. Если главный сервер почему-то недоступен, обращения идут подчиненному. Администратору нет необходимости
вручную корректировать базу подчиненного сервера. База сама периодически
обновляется с главного сервера посредством протоколов DNS. Такая операция называется переносом зоны.
DNS-серверы должны уметь выдерживать огромные нагрузки. Например, на серверы доменов первого уровня (типа RU) приходят десятки тысяч запросов в секунду. А на корневые (эти 13 серверов - популярнейшая мишень хакерских атак) - и того больше.
Чтобы разгрузить основные сервера, были введены кэширующие сервера. Их
функция такая же, как у кэш-памяти в компьютере. Кэширующий сервер загружает адреса серверов корневого домена из файла, а все остальные данные получает сам,
накапливая ответы на выдаваемые им запросы. Когда такой сервер получает запрос, он
сначала смотрит, нет ли у него в буфере ответа. Если есть, то он выдает этот ответ, если же нет - обращается к корневым серверам, чтобы получить информацию у них.
У каждого домена в его зонных данных обычно присутствует информация о DNSсерверах для каждого его поддомена. Такая структура позволяет DNS-клиентам
опускаться по цепочке серверов от самого крупного к самому мелкому в поисках какого-
либо узла.
Например, поиск домена mail.yandex.ru мог бы проходить следующим образом. Сначала опрос корневого сервера, который бы перенаправил запрос к одному из
серверов домена RU. Тот, в свою очередь, перенаправил бы к серверам домена yandex.ru (ns1.yandex.ru, ns2.yandex.ru, ns3.yandex.ru), которые и дали бы адрес mail.yandex.ru (213.180.194.65).
Серверы бывают рекурсивными и нерекурсивными.
1 Зона — логический узел в дереве имён. Право администрировать зону может быть передано третьим лицам, за счёт чего обеспечивается распределённость базы данных. При этом персона, передавшая право на управление в своей базе данных хранит информацию только о существовании зоны (но не подзон!), информацию о персоне (организации), управляющей зоной, и адрес серверов, которые отвечают за зону. Вся дальнейшая информация хранится уже на серверах, ответственных за зону.
4
Носов В.В. "Технології аудиту інформаційних систем"
Если нерекурсивный сервер располагает информацией о запрашиваемом имени, он дает соответствующий ответ. В противном случае такой сервер вернет клиенту
ссылку на авторитетные серверы, которые знают (или должны знать) ответ. Клиент в этом случае должен уметь распознать ссылку на другой сервер и послать свой запрос
ему. Такие перенаправления могут происходить до тех пор, пока не будет найден нужный сервер.
Рекурсивный сервер не дает ссылок на другие сервера в ответах, а сообщает, что
хост не может быть найден. Он сам находит и опрашивает нужный сервер, после чего отвечает исходному запросу клиента. Но за такие удобства приходится платить. Во-
первых, процедура обработки запроса становится дольше, а во-вторых, в локальном кэше сервера накапливается множество ответов промежуточных серверов.
Взаимодействие DNS-серверов
Все серверы, как минимум, должны знать адреса и имена корневых серверов, которые, в свою очередь, знают о доменах первого уровня RU, COM, NET, ORG и других.
Сервер домена RU знает о существовании домена xakep.ru, сервер домена COM знает о домене livejournal.com. Каждая зона может делегировать (то есть передавать)
полномочия по управлению своими поддоменами другим серверам.
Пример. Необходимо узнать адрес сервера img.yandex.ru (у Яндекса
действительно есть отдельный сервер, оптимизированный для хранения картинок).
Предположим, что в кэше нашего DNS-сервера никаких данных об img.yandex.ru нет.
Наш локальный DNS-сервер обращается к корневому серверу. Корневой сервер
отправляет нас к серверу зоны RU, в которой находится запрашиваемый адрес. Сервер
зоны RU определяет по своей базе, что домен yandex.ru является делегированным и вся информация по его субдоменам хранится в DNS Яндекса (ns1.yandex.ru и другие),
а не у него самого (как было бы в случае отсутствия делегирования), и отправляет нас к
соответствующим серверам. И только после этого ns1.yandex.ru дает ответ, что адресом img.yandex.ru является 213.180.193.30.
Кэширование запросов. Сначала кэшировались только положительные ответы, т.е. связанные с существующими именами и адресами хостов. Но относительно недавно,
в 1998 году, было предложено кэшировать еще и отрицательные ответы - информацию о
том, что тех или иных хостов не существует в природе. Это резко снизило количество обращений к корневым серверам.
Опрос DNS-сервера
Для большинства пользователей операции с запросами, ответами, пересылками и другими резолвами (resolve - операция конвертации доменного имени в IP-адрес) остается вне поля зрения. Операционная система следит за адекватным преобразованием адресов, и редко какое приложение само обращается к DNS-серверу. Реализация клиентской части DNS уже давно стала частью стека протоколов TCP/IP в операционных системах.
Nslookup. Тем не менее, существует небольшая консольная программа nslookup.
У программы есть два режима работы: командный и интерактивный. Первый используется, когда просто нужно узнать IP хоста по его имени.
Сначала программа сообщает свои текущие настройки. Server - DNS-сервер, к которому она будет обращаться за информацией, ns1.misp.ru - основной сервер
моего провайдера, а 10.22.10.20 - его адрес.
Строка «Non-authoritative answer» говорит о том, что данные берутся из какого-то промежуточного кэширующего сервера, скорее всего, из самого ns1.misp.ru. Далее идут запрошенное нами доменное имя и собственно адрес.
C:\Documents and Settings\root>nslookup www.xakep.ru
Server: ns1.misp.ru
Address: 10.22.10.20
Non-authoritative answer:
5
Носов В.В. "Технології аудиту інформаційних систем"
Name: www.xakep.ru
Address: 62.213.71.217
Гораздо больше информации можно получить, используя nslookup в интерактивном режиме. Для этого запускаем программу без параметров и вводим: «?».
> ?
Commands: (identifiers are shown in uppercase, [] means optional)
NAME |
- print info about the host/domain NAME using default server |
NAME1 NAME2 |
- as above, but use NAME2 as server |
help or ? |
- print info on common commands |
set OPTION |
- set an option |
all |
- print options, current server and host |
[no]debug |
- print debugging information |
[no]d2 |
- print exhaustive debugging information |
[no]defname |
- append domain name to each query |
[no]recurse |
- ask for recursive answer to query |
[no]search |
- use domain search list |
[no]vc |
- always use a virtual circuit |
domain=NAME |
- set default domain name to NAME |
srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc. |
|
root=NAME |
- set root server to NAME |
retry=X |
- set number of retries to X |
timeout=X |
- set initial time-out interval to X seconds |
type=X |
- set query type (ex. A,ANY,CNAME,MX,NS,PTR,SOA,SRV) |
querytype=X |
- same as type |
class=X |
- set query class (ex. IN (Internet), ANY) |
[no]msxfr |
- use MS fast zone transfer |
ixfrver=X |
- current version to use in IXFR transfer request |
server NAME |
- set default server to NAME, using current default server |
lserver NAME |
- set default server to NAME, using initial server |
finger [USER] |
- finger the optional NAME at the current default host |
root |
- set current default server to the root |
ls [opt] DOMAIN |
[> |
FILE] - list addresses in DOMAIN (optional: output to FILE) |
-a |
- |
list canonical names and aliases |
-d |
- |
list all records |
-t TYPE |
- |
list records of the given type (e.g. A,CNAME,MX,NS,PTR etc.) |
view FILE |
|
- sort an 'ls' output file and view it with pg |
exit |
- exit the program |
|
В первую очередь нас интересует команда «set type». Она определяет тип информации, которую мы планируем получить.
Какие же типы записей бывают в зонных файлах сервера? Есть четыре основных
типа.
Тип первый. Зонные записи
Запись типа SOA (Start Of Authority - начало полномочий) определяет начало
зоны - группы записей о ресурсах, расположенных в одной области пространства имен.
Для каждой зоны создается своя запись типа SOA, которая содержит имя зоны, ее
порядковый номер, почтовый адрес администратора домена и главный DNS-сервер
зоны. Порядковый номер исполняет роль уникального идентификатора и служит для корректного обновления информации о зоне на других серверах.
>set type=SOA
>yandex.ru
Server: ns1.misp.ru
Address: 10.22.10.20
Non-authoritative answer: yandex.ru
primary name server = ns1.yandex.ru responsible mail addr = sysadmin.yandex-team.ru
serial |
= 2009061909 |
||
refresh |
= 1800 (30 mins) |
||
retry |
= |
900 (15 |
mins) |
expire |
= |
2592000 |
(30 days) |
6
Носов В.В. "Технології аудиту інформаційних систем"
default TTL = 900 (15 mins)
Адрес администратора записывается через точку, а не через @
(sysadmin.yandex-team.ru). Кроме этого, запись содержит значения интервалов
времени, определяющие, как долго данные могут находиться в кэше других серверов и
вообще путешествовать по Сети без обновления. Это нужно для постоянного обновления данных, распределенных по всей Сети. Обычно, при регистрации нового домена предупреждают, что домен станет доступен в течение суток. Это время как раз и
нужно для того, чтобы данные были распределены по Сети. Максимальная длина имени зоны (от точки до точки) не может превышать 63 байта.
Основные серверы домена yandex.ru
> set type=NS > yandex.ru
Server: ns1.misp.ru Address: 10.22.10.20
Non-authoritative answer:
yandex.ru |
nameserver = ns4.yandex.ru |
yandex.ru |
nameserver = ns5.yandex.ru |
yandex.ru |
nameserver = ns1.yandex.ru |
yandex.ru |
nameserver = ns2.yandex.ru |
ns1.yandex.ru |
internet address = 213.180.193.1 |
ns2.yandex.ru |
internet address = 213.180.199.34 |
ns4.yandex.ru |
internet address = 77.88.19.60 |
ns5.yandex.ru |
internet address = 213.180.204.1 |
> |
|
Записи NS (Name Server) определяют основные серверы имен для зоны. У Яндекса целых четыре основных сервера для домена.
Тип второй. Базовые записи
A-запись (Address). A (Address) — указание IP-адреса. Имя: имя хоста. Если имя
является не полностью уточненным (на конце нет точки), то к нему присоединяется
доменное имя зоны. Данные: IP-адрес.
Пример (запись в базе данных зоны exmpl.ru):
gw |
IN |
A |
1.16.195.1 |
ns |
IN |
A |
1.16.195.98 |
wildcat |
IN |
A |
1.16.195.4 |
IN – обозначение того, что запись относится к классу Интернет.
PTR-запись. PTR (Pointer) – указатель на другой узел в дереве DNS. Используется
для выполнения обратного преобразования - IP-адрес в доменное имя. Чтобы не
выбиваться из общей концепции устройства DNS (древовидной структуры,
распределенности и т.д.) и не перебирать все дерево доменных имен Интернета в поисках имени, которому приписан интересующий IP-адрес, был придуман специальный
домен in-addr.arpa. Хосты в нем именуются очень похоже на IP-адреса, только в
обратную сторону. К примеру, IP-адресу 216.239.37.25 будет соответствовать домен 25.37.239.216.in-addr.arpa, информация о котором хранится в DNS-серверах
внешнего домена 37.239.216.in-addr.arpa. И уже они, серверы внешнего домена,
определяют, что поддомену с именем «25» (то есть IP-адресу 216.239.37.25)
соответствует имя testmx1.google.com.
>set type=PTR
>216.239.37.25
Server: ns1.misp.ru
Address: 10.22.10.20
Non-authoritative answer: |
name = testmx1.google.com |
25.37.239.216.in-addr.arpa |
37.239.216.in-addr.arpa nameserver = ns1.google.com
7
Носов В.В. "Технології аудиту інформаційних систем"
37.239.216.in-addr.arpa nameserver = ns2.google.com 37.239.216.in-addr.arpa nameserver = ns3.google.com 37.239.216.in-addr.arpa nameserver = ns4.google.com ns3.google.com internet address = 216.239.36.10
MX-запись (Mail eXchanger) — указывает на сервер для приёма электронной
почты, приходящую на адреса в указанном домене (вида <имя_ящика>@<домен>). Если у домена не прописана MX-запись, SMTP-сервер направляет запрос на определение IP-
адреса домена (A-запись) и почта отправляется на этот IP-адрес.
Когда, например, посылается письмо на адрес magazine@real.xakep.ru, то сервер исходящей почты сначала обращается к DNS’ам домена xakep.ru, чтобы узнать IP-адрес сервера, принимающего почту для адресов @real.xakep.ru. За это и отвечают записи МХ. Кстати, хоста real.xakep.ru в природе не существует. Т.е. у него нет IP-адреса. А вся почта, согласно записям MX DNS-сервера домена xakep.ru,
поступает либо на сервер smtp.gameland.ru, либо на post.gameland.rmt-net.ru.
И уже они обрабатывают письма. Какой конкретно сервер выбрать для доставки,
определяет параметр «MX preference» - приоритет узла. Сначала выбирается сервер
с наименьшим значением параметра. Если соединиться с ним не получилось, то
выбирается следующий.
> set type=MX > real.xakep.ru
Server: ns1.misp.ru Address: 10.22.10.20
Non-authoritative answer:
real.xakep.ru |
MX preference = 20, mail exchanger = smtp.gameland.ru |
real.xakep.ru |
MX preference = 10, mail exchanger = post.gameland.rmt-net.ru |
xakep.ru |
nameserver = ns.gameland.ru |
xakep.ru |
nameserver = ns4.nic.ru |
xakep.ru |
nameserver = ns8.nic.ru |
ns4.nic.ru |
internet address = 194.226.96.8 |
ns8.nic.ru |
internet address = 193.232.130.14 |
CNAME-запись (Canonical NAME) — позволяет присваивать хосту псевдоним (алиас). Запись представляет собой ссылку на другое доменное имя (указывающее на A-
запись). Эта ссылка используется вместо A-записи с реальным IP-адресом и позволяет
связать несколько имен домена с одним реальным хостом, на котором, например, хранятся странички сайта.
Самая распространенная CNAME-запись — www. Например, если клиент хочет,
чтобы его ресурс example.com был доступен также пользователям, которые наберут в
браузере www.example.com, необходимо создать для имени www.example.com запись типа CNAME, в которой указать, что данное имя является псевдонимом имени webserver.example.com. В таком случае, если изменится IP-адрес хоста
(webserver.example.com), то придется поменять только одну A-запись для имени webserver.example.com.
www.example.com. |
CNAME webserver.example.com |
Тип третий. Записи аутентификационные
Протокол DNS изначально создавался открытым. Любой человек, имеющий
клиентскую программу вроде nslookup, мог исследовать устройство зоны, порою даже получая полный дамп DNS-базы. Для устранения этого недостатка был разработан механизм, названый TSIG. Он использовал симметричную схему шифрования и
позволял организовать безопасное взаимодействие между серверами. Для безопасного
обмена ключами был создан протокол TKEY, генерирующий ключи для двух хостов по алгоритму обмена ключами Диффи-Хеллмана. Чуть позже родился протокол DNSSEC
(защищенный DNS), который с помощью методов шифрования с открытым ключом обеспечивал аутентификацию и целостность передаваемых данных. Все это было
8
Носов В.В. "Технології аудиту інформаційних систем"
сделано для того, чтобы клиент мог удостовериться, что данные действительно поступили от владельца зоны и не были искажены.
Тип четвертый. Факультативные (необязательные) записи
На данный момент трудно найти домен, где были бы указаны следующие данные:
LOC - географические координаты и физические размеры объектов DNS. SRV - расположение основных сервисов внутри домена.
HINFO – информация о хосте.
WKS – информация о предоставляемых сервисах.
2. Дослідження серверів DNS
После идентификации всех доменов можно приступать к работе с серверами DNS. DNS — это распределенная база данных, предназначенная для преобразования IPадресов в имена узлов и наоборот. Если сервер DNS не настроен на обеспечение
максимальной степени защиты, то с его помощью можно получить информацию о внутренней сети организации.
Перенос зоны сервера DNS
Популярность |
9 |
Простота |
9 |
Опасность |
3 |
Степень риска |
7 |
Одна из самых серьезных ошибок администратора при настройке параметров сети состоит в предоставлении взломщику возможности переноса зоны DNS.
При переносе зоны (zone transfer) вторичный сервер DNS может обновить собственную базу данных зоны на основании данных, полученных от первичного DNSсервера. Это позволяет обеспечить избыточность в работе службы DNS, которая необходима для тех случаев, когда первичный сервер по каким-то причинам становится
недоступным. В общем случае вполне достаточно, чтобы перенос зоны выполнялся
только вторичным DNS-сервером.
Однако многие DNS-серверы настроены таким образом, что предоставляют копию
зоны любому узлу Internet по первому же запросу. В этом нет ничего плохого при
условии, что предоставляемая информация содержит лишь сведения о компьютерах, непосредственно подключенных к Internet. Однако такая возможность таит в себе опасность того, что полученные взломщиком сведения могут облегчить его задачу проникновения в сеть. Эта угроза реализуется в полной мере, когда в организации не используется механизм разделения DNS-информации на общедоступную и закрытую. Если это так, то любой желающий без особых проблем может получить сведения об
именах узлов и IP-адресах внутренней сети. Предоставление информации о внутренних
IP-адресах кому попало можно сравнить лишь с предоставлением полной схемы
внутренней сети организации.
Рассмотрим несколько методов переноса зоны, а также выясним, какие сведения можно получить из этих данных. Из всего множества различных инструментов, которые
можно применять для выполнения данной операции, рассмотрим лишь самые
распространенные.
Один из самых простых методов переноса зоны состоит в использовании клиента nslookup, который обычно входит в комплект поставки большинства версий UNIX и NT. Воспользуемся этой утилитой и введем следующие данные.
[bash]$ nslookup
Default Server: ns1.example.net Address: 10.10.20.2
> server ns2.tellurian.net Default server: ns2.tellurian.net Address: 216.182.1.52#53
9
Носов В.В. "Технології аудиту інформаційних систем"
>set type=any
>ls -d Tellurian.net. >> /tmp/zone_out
Первая введенная команда — это запуск утилиты nslookup в интерактивном
режиме. После запуска утилита сообщает, какой сервер имен в данный момент
используется по умолчанию. Обычно таким сервером является DNS-сервер вашей организации или DNS-сервер провайдера. Поскольку используемый в данном примере
DNS-сервер (10.10.20.2) не обслуживает интересующий нас домен, нам нужно перейти на другой сервер, на котором мы сможем найти необходимую информацию о внутренней сети. Таким образом, утилите nslookup необходимо явно сообщить о том, к какому серверу DNS ей нужно обратиться. В нашем примере мы будем использовать основной сервер сети Tellurian Networks с адресом 216.182.1.52. Вспомните, что его адрес мы узнали из регистрационной базы данных доменов на предыдущем этапе.
Затем мы устанавливаем тип записи any. Это означает, что в список выбранных
записей будут отобраны все записи из базы данных DNS-сервера. (Подробнее о
параметрах утилиты nslookup можно узнать с помощью команды man nslookup.)
И, наконец, для получения всех записей, соответствующих заданному критерию,
воспользуемся командой ls. Параметр -d служит для включения режима вывода всех
записей домена. В конце доменного имени добавлен символ ".", как это требуется для явного задания полностью определенного имени (fully qualified domain name). Однако в большинстве случаев точку можно не использовать. Кроме того, мы переназначили вывод в файл /tmp/zone_out, чтобы обеспечить возможность дальнейшего анализа полученных данных.
После выполнения переноса зоны можно открыть созданный файл и посмотреть,
содержится ли в нем информация, которая может помочь нам в выборе какой-то
конкретной системы в качестве плацдарма для проникновения в сеть. Вот фрагмент такого файла.
[> ls -d e2e.ru. |
|
|
|
[e2e.ru] |
SOA |
ns1.e2e.ru aad.management.ru. (2008083005 |
|
e2e.ru. |
|||
14400 7200 3600000 86400) |
MX |
0 |
e2e.ru |
e2e.ru. |
|||
e2e.ru. |
NS |
ns1.e2e.ru |
|
e2e.ru. |
NS |
ns2.e2e.ru |
|
e2e.ru. |
A |
67.15.60.41 |
|
*.e2e.ru. |
A |
67.15.60.41 |
|
ars02.e2e.ru. |
A |
89.248.238.48 |
|
www.ars02.e2e.ru. |
A |
89.248.238.48 |
|
cpanel.e2e.ru. |
A |
67.15.60.41 |
|
duh-real.e2e.ru. |
A |
88.212.196.173 |
|
duh02.e2e.ru. |
A |
88.212.196.173 |
|
www.duh02.e2e.ru. |
A |
88.212.196.173 |
|
duh03.e2e.ru. |
A |
88.212.196.173 |
|
www.duh03.e2e.ru. |
A |
88.212.196.173 |
|
duh04.e2e.ru. |
A |
88.212.197.136 |
|
*.duh04.e2e.ru. |
A |
88.212.197.136 |
|
ftp.e2e.ru. |
A |
67.15.60.41 |
|
kate.e2e.ru. |
A |
67.15.60.41 |
|
localhost.e2e.ru. |
A |
127.0.0.1 |
|
mail.e2e.ru. |
CNAME |
e2e.ru |
|
messenger.e2e.ru. |
A |
78.47.29.91 |
|
*.messenger.e2e.ru. |
A |
78.47.29.91 |
|
mit45.e2e.ru. |
A |
88.212.197.140 |
|
*.mit45.e2e.ru. |
A |
88.212.197.140 |
|
ns1.e2e.ru. |
A |
67.15.61.195 |
|
ns2.e2e.ru. |
A |
64.246.50.53 |
|
poliklinika.e2e.ru. |
A |
78.47.29.91 |
|
*.poliklinika.e2e.ru. |
A |
78.47.29.91 |
|
robotic.e2e.ru. |
A |
88.212.196.174 |
|
10