Как проверить конфигурацию брандмауэра с помощью Nmap и Tcpdump

Анализаторы пакетов могут использоваться для детального отслеживания всего сетевого трафика, проходящего через интерфейс. Большинство анализаторов пакетов имеют возможность работать в режиме реального времени, отображать пакеты по мере их отправки или получения или записывать информацию о пакетах в файл и обрабатывать ее позднее. Пакетный анализ дает нам возможность детально увидеть, какие типы ответов наши целевые машины отправляют обратно на хосты в открытой сети.

Для целей нашего руководства мы будем использовать инструментtcpdump. Это хороший вариант, потому что он мощный, гибкий и довольно распространенный в системах Linux. Мы будем использовать его для захвата необработанных пакетов при выполнении наших тестов на случай, если нам понадобится расшифровка для последующего анализа. Некоторые другие популярные варианты - это Wireshark (илиtshark, его кузен из командной строки) иtcpflow, которые могут организованно объединять целые TCP-разговоры.

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

В этом руководстве мы будем использовать инструмент сопоставления сети и сканирования портовnmap. Мы можем использоватьnmap для отправки пакетов разных типов, чтобы попытаться выяснить, какие службы находятся на нашей целевой машине и какие правила брандмауэра ее защищают.

Перед сканированием мы настроимtcpdump для захвата трафика, генерируемого тестом. Это поможет нам более подробно проанализировать отправленные и полученные пакеты позже, если потребуется. Давайте создадим каталог в~/scan_results, чтобы мы могли хранить вместе файлы, связанные с нашим сканированием SYN:

Мы можем запустить захватtcpdump и записать результаты в файл в нашем каталоге~/scan_results/syn_scan с помощью следующей команды:

По умолчаниюtcpdump будет работать на переднем плане. Чтобы запустить сканированиеnmap в том же окне, нам нужно приостановить процессtcpdump, а затем перезапустить его в фоновом режиме.

Мы можем приостановить запущенный процесс, нажавCTRL-Z:

Это приостановит запущенный процесс:

Теперь вы можете перезапустить задание в фоновом режиме, набравbg:

Вы должны увидеть похожую строку вывода, на этот раз без метки «Остановлено» и с амперсандом в конце, чтобы указать, что процесс будет выполняться в фоновом режиме:

Команда теперь выполняется в фоновом режиме, наблюдая за любыми пакетами, проходящими между нашей аудиторской и целевой машинами. Теперь мы можем запустить наше сканирование SYN.

Когдаtcpdump записывает наш трафик на целевую машину, мы готовы запуститьnmap. Мы будем использовать следующие флаги, чтобы получитьnmap для выполнения необходимых нам действий:

Note

[.note] # Следует иметь в виду, что для проверки IPv6 вам нужно будет добавить к вашим командам флаг-6. Поскольку большинство обязательных учебных пособий не принимают трафик IPv6, мы пропустим IPv6 для этого руководства. Добавьте этот флаг, если ваш брандмауэр принимает трафик IPv6.
#

Вместе команда будет выглядеть примерно так:

Даже если для шаблона синхронизации установлено значение 4, сканирование, скорее всего, займет довольно много времени, поскольку оно проходит через 65 535 портов (мой тестовый запуск длился около сорока минут). Вы увидите результаты печати, которые выглядят примерно так:

После завершения сканирования мы можем вернуть наш процессtcpdump на передний план и остановить его.

Выделите его из фона, набрав:

Остановите процесс, удерживая клавишу управления и нажимая «c»:

Теперь у вас должно быть два файла в каталоге~/scan_results/syn_scan. Один с именемpackets, сгенерированный запускомtcpdump, и один, сгенерированныйnmap, называетсяnmap.results.

Давайте сначала посмотрим на файлnmap.results:

~/scan_results/syn_scan/nmap.results

Выделенная область выше содержит основные результаты сканирования. Мы видим, что порт 22 и порт 80 открыты на отсканированном хосте, чтобы разрешить трафик SSH и HTTP. Мы также видим, что 65 533 порта были закрыты. Другой возможный результат будет «отфильтрован». Отфильтрованный означает, что эти порты были определены как остановленные чем-то по сетевому пути. Это может быть брандмауэр на цели, но он также может фильтровать правила на любом из промежуточных хостов между аудитом и целевыми машинами.

Если мы хотим увидеть фактический пакетный трафик, который был отправлен и получен от цели, мы можем прочитать файлpackets обратно вtcpdump, например:

Этот файл содержит весь разговор, который состоялся между двумя хостами. Вы можете фильтровать несколькими способами.

Например, чтобы просмотреть только трафикsent к цели, вы можете ввести:

Аналогично, чтобы просмотреть только ответный трафик, вы можете изменить «dst» на «src»:

Открытые порты TCP будут отвечать на эти запросы пакетом SYN. Мы можем напрямую искать ответы для этого типа с помощью фильтра:

Это покажет вам только успешные ответы SYN и должны соответствовать портам, которые вы видели при запускеnmap:

Вы можете сделать больше анализа данных, как считаете нужным. Все это было захвачено для асинхронной обработки и анализа.

Еще раз, давайте создадим каталог для хранения наших результатов:

Снова запустите захватtcpdump. На этот раз запишите файл в новый каталог~/scan_results/udp_scan:

Приостановите процесс и поместите его в фон:

Теперь мы готовы запустить сканирование UDP. Из-за природы протокола UDP это сканирование обычно занимает наsignificantly больше времени, чем SYN-сканирование. На самом деле, это может занять более одного дня, если вы сканируете каждый порт в системе. UDP - это протокол без установления соединения, поэтому получение ответа не может означать, что целевой порт заблокирован, что он был принят или пакет был потерян. Чтобы попытаться различить их,nmap должен повторно передать дополнительные пакеты, чтобы попытаться получить ответ.

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

Верните процессtcpdump на передний план на своей машине аудита, набрав:

Остановите захват пакета, удерживая кнопку управления и нажав «c»:

Теперь мы можем взглянуть на сгенерированные файлы.

Полученный файлnmap.results должен выглядеть примерно так, как мы видели ранее:

~/scan_results/udp_scan/nmap.results

Ключевое различие между этим результатом и ранее полученным результатом SYN, вероятно, будет заключаться в количестве портов, отмеченныхopen|filtered. Это означает, чтоnmap не может определить, означает ли отсутствие ответа, что служба приняла трафик, или он был отброшен каким-то межсетевым экраном или механизмом фильтрации на пути доставки.

Анализ выводаtcpdump также значительно сложнее, потому что нет флагов соединения и потому что мы должны сопоставлять ответы ICMP с запросами UDP.

Мы можем увидеть, какnmap должен был отправить много пакетов на порты, которые были указаны какopen|filtered, запросив просмотр UDP-трафика на один из указанных портов:

Скорее всего, вы увидите что-то похожее на это:

Сравните это с результатами, которые мы видим на одном из отсканированных портов, который был отмечен как «закрытый»:

Мы можем попытаться вручную восстановить процесс, который проходитnmap, сначала составив список всех портов, на которые мы отправляем UDP-пакеты, используя что-то вроде этого:

Затем мы можем увидеть, какие ICMP-пакеты мы получили обратно, говоря, что порт недоступен:

Затем мы можем увидеть эти два ответа и посмотреть, какие UDP-пакеты никогда не получали ответ ICMP, набрав:

Это должно в основном соответствовать списку портов, о которых сообщилnmap (он может содержать некоторые ложные срабатывания из-за потерянных возвратных пакетов).

Мы можем попытаться угадать версии служб, работающих на цели, с помощью процесса, известного как дактилоскопия. Мы получаем информацию с сервера и сравниваем ее с известными версиями в нашей базе данных.

tcpdump не будет слишком полезным в этом сценарии, поэтому мы можем пропустить его. Если вы хотите захватить его в любом случае, следуйте процессу, который мы использовали в прошлый раз.

Сканированиеnmap, которое нам нужно использовать, запускается флагом-sV. Поскольку мы уже выполняли сканирование SYN и UDP, мы можем передать точные порты, которые мы хотим просмотреть, с помощью флага-p. Здесь мы рассмотрим 22 и 80 (порты, которые были показаны при нашем сканировании SYN):

Если вы просматриваете полученный файл, вы можете получить информацию о работе службы в зависимости от того, насколько «болтливым» или даже уникальным является ответ службы:

~/scan_results/versions/service_versions.nmap

Здесь вы можете увидеть, что тест смог определить версию сервера SSH и дистрибутив Linux, который его упаковал, а также принятую версию протокола SSH. Он также распознал версию Nginx и снова определил, что она соответствует пакету Ubuntu.

Мы можем попытаться угадатьnmap операционную систему хоста на основе характеристик ее программного обеспечения и ответов. Это работает так же, как управление версиями сервисов. И снова мы не будем использовать запускtcpdump в этом тесте, но вы можете выполнить его, если хотите.

Флаг, который нам нужен для выполнения обнаружения операционной системы, --O (заглавная буква «O»). Полная команда может выглядеть примерно так:

Если вы просмотрите выходной файл, вы можете увидеть что-то похожее на это:

~/scan_results/versions/os_versions.nmap

Мы видим, что в этом случаеnmap не догадывается об операционной системе на основе увиденной подписи. Если бы он получил больше информации, он, вероятно, показал бы различные проценты, которые указывают, как сигнатура целевой машины совпадает с сигнатурами операционной системы в ее базах данных. Вы можете увидеть подпись отпечатка пальца, которуюnmap получил от цели, под линиейTCP/IP fingerprint:.

Идентификация операционной системы может помочь злоумышленнику определить, какие эксплойты могут быть полезны в системе. Настройка брандмауэра для реагирования на меньшее количество запросов может снизить точность некоторых из этих методов обнаружения.