Для этого в скрипт запуска виртуалки в опции настройки сети добавим параметры `hostfwd=udp::15353-:53,hostfwd=tcp::15353-:53`, в результате чего в теории 53 порт внутри виртуалки будет замэплен на порт 15353 хост машины и по TCP и по UDP.
Проделав это перезапустим виртуалку.
-9. Тестирование извне виртуалки
+#### 5. Тестирование извне виртуалки
Зайдя в виртуалку запускаем DNS-свервер как в п.1
Далее командой `natch replay` снимаем трассу между первым и вторым снепшотом и загружаем ее в snatch.
-### Анализ результатов.
+### Анализ результатов
Данные пришедшие в систему 53 TCP или UDP порта, были помечены, и при помощи программы визуализации snatch можно посмотреть как они распространялись по системе

+заглянув внутрь узла `pdns_server/sockets` мы можем увидеть, что помеченные данные читаются из tcp или udp сокета (в зависимости от того на результаты какого эксперимента мы смотрим) и более ни в какие другие сокеты и файлы не направлялись
+
+
+
+
+
+Если нажать на подсвеченный голубым сокет, то в появившейся справа панели можно увидеть, что помеченные данные из сокета читаются, и потом обратно в него частично пишутся, и при этом пределы pdns_server'а не покидают, например не участвуют в запросе к базе данных.
+Интересно, как им это удалось? Вся база записей оказывается загруженной в память и сервер делает `strcmp` с содержимым памяти?
+
+
+
+Так же можно увидеть, что сервер по адресу 10.0.2.3 (адрес сетевого интерфейса виртуальной машины) сервер сам себе посылает udp-пакет с неким запросом `security-status`.
+Это явно должно насторожить безопасников, этот механизм должен быть как минимум исследован, и возможно, если результаты исследования окажутся неудовлетворительными, то отключен.
+
+
+
+#### Call Graph
+##### TCP
+
+В графе вызовов снятом для случая передачи данных по TCP соединению хорошо виден алгоритм обработки входящего запроса.
+После ряда вызовов посвященных получению данных из сокета, вызывается большой метод отвечающий за разбор входящего пакета `DNSPacket::parse`, после чего происходит обработка входящего запроса `AuthPacketCache::get` (не совсем четко понятно что он делает, надо код читать) и `PacketHandler::doQuestion`, после чего происходит отправка ответа: `ResponseStats::submitResponse`.
+Первичной целью для фаззинга совершенно очевидно следует выбрать функцию `DNSPacket::parse`, которая оказывается первой на острее атаки. Для более глубокого фаззинг исследования следует в качестве цели выбрать всю последовательность обработки запроса включая парсинг и обработку запроса, но не включая отправку ответа.
+
+
+
+
+##### UDP
+
+Для случая UDP соединения мы видим те же самые функции `DNSPacket::parse`, `AuthPacketCache::get`, `PacketHandler::doQuestion` и `ResponseStats::submitResponse` перемежающиеся вызовами обеспечивающими работу с UDP-сетевым соединением, и завернутые в два потока выполнения.
+По какой-то причине для работы с UPD-соединением была выбрана многопоточная архитектура. Видимо в этом был какой-то практический смысл.
+Принципиально новых элементов в поверхность атаки при обработке UDP-соединения обнаружено не было.
+
+
+
+
+### Выводы
+
+Natch достаточно хорошо показал себя как инструмент для начального знакомства с ранее неизвестным продуктом, а так же позволил быстро проанализировать потенциальную поверхность атаки.
+Natch должен быть незаменимым инструментом для организаций занимающихся исследованием безопасности большого количества стороннего кода.