Инструментальные средства проверки TCP/IP-стека

Пример из жизни. Вбрасывание пакетов

Одной из особенностей хорошего брандмауэра является способность динамически открывать и закрывать порты для отдельных TCP-подключений. Вы можете использовать утилиту nemesis, чтобы проверить способность набора правил вашего брандмауэра к контролю состояний ( statefulness ). Это может быть важным тестом для предотвращения атак подмены пакетов ( packet spoofing ). Например, вы можете проверить правило, которое разрешает трафик NetBIOS (TCP-порт 139) только между двумя хостами: 10.0.0.27 и 192.168.0.90.

Когда начинается подключение, хост 192.168.0.90 посылает TCP SYN -пакет с порта 1066 на порт 139 адреса 10.0.0.27. Ниже приводится частичный перехват данных утилитой tcpdump из начального трафика.

19:34:48.663980 192.168.0.90.1066 > 10.0.0.27.139: S 847815674:847815674 (0)
 win 16384 < mss1460, nop, nop, sackOK > (DF)
19:34:48.664567 10.0.0.27.139 > 192.168.0.90.1066: S 4141875831:4141875831 (0)
 ack 847815675 win 17520 < mss 1460, nop, nop, sackOK > (DF)
19:34:48.665586 192.168.0.90.1066 > 10.0.0.27.139:. ack 1 win 17520 (DF)

В этой точке брандмауэр разрешает трафик, имеющий такую комбинацию IP-адресов и портов, которая обычно используется для установления соединения. Последующие TCP-пакеты несут ACK-флаг, пока подключение не будет закрыто флагами FIN или RST. Это то место, где вы тестируете брандмауэр с помощью утилиты nemesis-tcp.

Первый тест состоит в определении того, позволяет ли брандмауэр пройти произвольному пакету, несущему флаги FIN или RST.

# nemesis -tcp -S 192.168.0.90-D 10.0.0.27 -fF -x 1066 -y 139
# nemesis -tcp -S 192.168.0.90-D 10.0.0.27 -fR -x 1066 -y 139

Конечно, вы должны выполнять tcpdump с другой стороны брандмауэра (в сети 10.x), чтобы увидеть, проходят ли пакеты через набор правил. Брандмауэр должен блокировать эти пакеты, потому что номера TCP-пакетов неверны ( nemesis назначает их случайным образом). Если эти пакеты были разрешены брандмауэром, то атаки, вызывающие отказ в обслуживании, могли бы быть выполнены против адреса 10.0.0.27, наводняя его RST-пакетами, то есть никакие допустимые подключения не могли бы поддерживаться!

Затем вы увидите, как брандмауэр обрабатывает ACK-пакеты. Некоторые хакерские нелегальные инструментальные средства туннелируют связь полностью по этим пакетам (посмотрите AckCmd на сайте http://ntsecurity.nu или скрытые каналы связи stcpshell в лекции ""Черный ход и средства удаленного доступа"" ).

# nemesis -tcp-S 192.168.0.90-D 10.0.0.27 -fA -x 1066 -y 139

То же самое может быть сделано для UDP-подключений. Из-за ненадежной природы UDP-протокола, брандмауэры имеют тенденцию применять ограничение на срок бездеятельности, как только было установлено UDP-подключение. Вы можете проверить временное ограничение брандмауэра с помощью инструмента nemesis-udp. Используйте тот же сценарий, который использовали ранее, но тестируйте UDP-порт 135 (также используемый для трафика NetBIOS). Во-первых, установите подключение между адресами 192.168.0.90 и 10.0.0.27; Netcat работает отлично. Затем выполните следующую команду, чтобы протестировать 5-минутное время ожидания. Команда sleep берет в качестве аргумента количество секунд; 300 секунд равно 5 минутам.

# sleep 300; nemesis -udp -S 192.168.0.90 -D 10.0.0.27 -x 1066 -y 135

Теперь выполните tcpdump с другой стороны брандмауэра. Если ваш сеанс утилиты tcpdump перехватит UDP-трафик, это значит, что трафик от nemesis-udp пересек брандмауэр. Это подразумевает, что время ожидания брандмауэра, вероятно, более 5 минут.

Наконец, вы можете также протестировать то, как брандмауэр мог бы реагировать на программу туннелирования ICMP-типа Loki (см. лекции ""Черный ход и средства удаленного доступа"" ). Например, брандмауэр никогда не должен разрешать ответ ICMP, если запрос ICMP (сгенерированный утилитой ping, например) происходил не из внутреннего IP-адреса.

# nemesis -icmp -S 192.168.0.90 -D 10.0.0.27 -i 0 -c 0

Можно протестировать все потенциальные 255 типов ICMP (хотя существует, приблизительно, только 40), чтобы увидеть, знает ли брандмауэр, как обработать определенные значения. К счастью, по умолчанию он блокирует пакет, вместо того чтобы разрешать ему вход в сеть 10.x.

#!/bin/sh
TYPE=0
while [ $TYPE -le 255 ] ; do
    nemesis-icmp -S 192.168.0.90 -D 10.0.0.27 -i $TYPE -c 0
    TYPE="expr $TYPE + 1 "
done

Наконец, вы можете испробовать заключительный тест, чтобы проконтролировать, как брандмауэр обрабатывает SNMP-запросы GET. Следующая методика была бы также удобна для более точного метода сканирования портов для служб SNMP. При нормальном UDP-сканировании пустой пакет посылается на порт 161, и ожидается ответ SNMP службы, которого может и не быть, так как пакет неправильный. В данном случае, вы фактически посылаете полный SNMP-запрос. Сначала вы должны создать файл полезной нагрузки, который содержит UDP-данные. Используйте сетевой анализатор потоков ( sniffer ), чтобы перехватить SNMP-трафик и иметь ориентировочные пакеты (см. лекцию ""Анализаторы сетевых потоков"" ). В нашем Perl-скрипте имеется SNMP-запрос GET для строки сообщества "public". Числа, записанные полужирным шрифтом, представляют строку public в шестнадцатеричной записи.

#!/usr/bin/perl
# snmp.pl
# mps -     Generate data for an SNMP GET "public"
$snmp =     "302c02010004067075626c6963a01f020426805d1e0201" .
            "000201003011300f060b2a8648ce340301020102010500";
print pack("H*", $snmp);

Далее, создайте файл полезной нагрузки и выполните утилиту nemesis-udp.

$ ./snmp.pl snmp.payload
$ nemesis-udp -S 192.168.0.179 -D 192.168.0.241 -x 2001 -y 161 
   -P snmp.payload

Этот программный код посылает SNMP-запрос GET с порта 2001 адреса 192.168.0.179 к порту 161 по адресу 192.168.0.241. Мы должны использовать утилиту tcpdump, чтобы наблюдать за ответом.

$ tcpdump-n udp