Война с брандмауэрами
Не волнуйтесь, в данном разделе мы Не будем рассматривать чудодейственные способы вывода из строя действующих брандмауэров. Мы лишь познакомимся с несколькими приемами, которые позволяют собрать некоторую важную информацию о различных путях проникновения через брандмауэры и их обхода.
Передача тестовых пакетов
Утилита hping, написанная Сальватором Санфилиппо (Salvatore Sanfilippo), передает TCP-пакеты на порт назначения и сообщает о том, какие ответные пакеты были получены. В зависимости от многочисленных условий эта утилита предоставляет самые разнообразные сведения. Каждый отдельный пакет и все пакеты в целом способны предоставить довольно ясное представление об используемых на брандмауэрах списках управления доступом. Например, с помощью утилиты hping можно выявить открытые и заблокированные порты, а также потерянные и отвергнутые пакеты.
В следующем примере утилита hping сообщила о том, что открыт порт 80, который готов установить соединение. Такое заключение можно сделать на основании того, что мы получили пакет с установленным флагом SA (пакет SYN/ACK).
[root]# hping 192.168.51.101 -с2 -S -р80 -n
HPING www.yourcomapany.com (ethO 172.30.1.20): S set, 40 data bytes
60 bytes from 172.30.1.20: flags=SA seq=0 ttl=242 id=65121 win=64240
time=144.4 ms
Теперь нам известен открытый порт на пути к желанной цели, однако мы еще ничего не знаем о брандмауэре. В следующем примере утилита hping сообщает о том. что с узла 192.168.70.2 ею получен ICMP-пакет типа 13 (Destination Unreachable — получатель недостижим). В главе 2 упоминалось, что такой пакет обычно передается маршрутизатором с фильтрацией пакетов типа Cisco IOS, на котором взаимодействие с определенными портами административно запрещено.
[root]# hping 192.168.51.101 -с2 -S -p23 -n
HPING 192.168.51.101 (ethO 172.30.1.20): S set, 40 data bytes
ICMP Unreachable type 13 from 192.168.70.2
С этого момента наше предположение подтвердилось: узел 172.168.70.2, скорее всего, является брандмауэром. Кроме того, нам известно, что на нем явно блокируется порт 23. Другими словами, если узел представляет собой маршрутизатор Cisco, то в его конфигурационном файле наверняка имеется следующая строка.
access- list 101 deny tcp any any 23!telnet
В приведенном ниже примере мы получили ответный пакет RST/ACK, что свидетельствует о выполнении одного из двух возможных условий: (1) пакет прошел через брандмауэр и на целевом узле заданный порт не находится в состоянии ожидания запросов или (2) брандмауэр отверг пакет (что вполне возможно, если на брандмауэре Checkpoint действует правило REJECT).
[root]# hping 192.168.50.3 -с2 -S -p22 -n
HPING 192.168.50.3 (ethO 192.168.50.3): S set, 40 data bytes
60 bytes from 192.168.50.3:flags=RA
seq=0 ttl=59 id=0 win=0 time=0.3 ms
Поскольку ранее был получен ICMP-пакет типа 13, можно сделать вывод о том, что брандмауэр (192.168.70.2) позволяет пакетам проходить дальше по маршруту, однако на целевом узле опрашиваемый порт не находится в состоянии ожидания запросов.
Если при сканировании портов на пути к цели оказался брандмауэр Checkpoint, то утилита hping сообщит IP-адрес целевого узла, однако на самом деле пакет будет отправлен с внешнего сетевого адаптера брандмауэра CheckPoint. В данном случае хитрость заключается в том, что брандмауэр CheckPoint генерирует ответный пакет вместо внутреннего узла, помещая в этот пакет его ложный адрес. Однако если взломщик столкнется с подобной ситуацией в Internet, то ему никогда не удастся узнать об этом, поскольку на его компьютер МАС-адрес никогда не попадет.
И наконец, если брандмауэр вообще блокирует пакеты, передаваемые на заданный порт, как правило, в ответ не будет получено никакой информации.
[root]# hping 192.168.50.3 -с2 -S -p22 -n
HPING 192.168.50.3 (ethO 192.168.50.3): S set,40 data bytes
Такой результат утилита hping может предоставить по двум причинам: (1) пакет не смог достичь источника назначения и был утерян в процессе передачи или (2) наиболее вероятно, пакет был отброшен устройством (возможно, брандмауэром — 192 .168. 70.2) в соответствии с установленными правилами ACL.
Контрмеры: защита от тестовых пакетов
Предотвращение
Предотвратить атаки с использованием утилиты hping очень трудно. Лучше всего просто заблокировать передачу сообщений ICMP с типом 13 (как описано в разделе, посвященному утилите nmap).
Утилита firewalk
Утилита firewalk является небольшим прекрасным средством, которое, подобно программам-сканнерам, позволяет исследовать порты узлов, расположенных позади брандмауэра. Она написана Майком Шифманом (Mike Schiffman) и Дэйвом Гольдсмитом (Dave Goldsmith). С помощью этой утилиты можно просканировать такие узлы и получить установленные на них правила. Причем вся процедура выполняется без реального "прикосновения" к целевой системе.
Утилита firewalk генерирует IP-пакеты с параметром TTL, который вычисляется так, чтобы время жизни пакета истекло в следующем за брандмауэром сегменте маршрута. Теоретические предпосылки такого подхода заключаются в том, что если пакет пропускается брандмауэром, то по истечении времени его жизни будет получено сообщение ICMP TTL, expired in transit (время жизни истекло в процессе передачи). В то же время, если пакет блокируется на основании заданного списка ACL брандмауэра, то этот пакет будет отвергнут. В результате либо вообще не будет получено никакого ответного сообщения, либо будет получен ICMP-пакет с типом 13.
[root]# firewalk -pTCP -S135-140 10.22.3.1
192.168.1.1
Ramping up hopcounts to binding host...
probe: 1 TTL: 1 port 33434: expired from [exposed.acme.com]
probe: 2 TTL: 2 port 33434: expired from [rtr.isp.net]
probe: 3 TTL: 3 port 33434: Bound scan at 3 hops [rtr.isp.net]
port 135: open
port 136: open
port 137: open
port 138: open
port 139: *
port 140: open
Относительно утилиты firewalk необходимо упомянуть об одной проблеме, которая заключается в том, что ее результаты могут оказаться непредсказуемыми. Некоторые брандмауэры способны выявить истечение времени жизни пакета до проверки своего списка ACL, что приводит к передаче ответного ICMP-сообшения TTL EXPIRED в любом случае. В результате утилитой firewalk все порты будут считаться открытыми.
Контрмеры: защита от утилиты firewalk
Предотвращение
На уровне внешнего интерфейса можно заблокировать передачу ICMP-пакетов TTL EXPIRED, однако это может отрицательно сказаться на производительности, поскольку легитимные клиенты никогда не смогут узнать, что же произошло с их соединением.
Сканирование с исходного порта
Традиционные брандмауэры с фильтрацией пакетов типа IOS Cisco имеют один существенный недостаток: они не сохраняют состояние! Для большинства читателей этот факт выглядит вполне очевидным, не так ли? Однако проанализируйте его еше раз. Если брандмауэр не может поддерживать состояние, то он не может определить, с внутренней или с внешней стороны было установлено соединение. Другими словами, такие брандмауэры не могут полностью управлять некоторыми потоками данных. Как следствие, в качестве исходного можно задать порт, который обычно является "легитимным", например TCP 53 (перенос зоны) и TCP 20 (FTP), а затем для получения ценной информации приступить к сканированию (или к атаке).
Для того чтобы определить, позволяет ли брандмауэр выполнять сканирование с заданного исходного порта 20 (канала данных FTP), воспользуйтесь утилитой nmap с параметром -д.
nmap -sS -Р0 -д 20 -р 139 10.1.1.1
При задании статического исходного порта в качестве параметра утилиты шпар необходимо воспользоваться методом сканирования с неполным открытием сеанса или с использованием сообщений SYN.
Если сканируемые порты оказались открытыми, то, очевидно, вы имеете дело с уязвимым брандмауэром, который расположен между вашим компьютером и целевым узлом. Для лучшего понимания описываемого процесса проанатазируйте приведенную ниже диаграмму.
Если обнаружится, что брандмауэр не сохраняет состояние соединений, то можно воспользоваться этим преимуществом и приступить к атаке уязвимых узлов, расположенных за этим брандмауэром. С помощью модифицированной утилиты перенаправления портов, например Fpipe от группы Foundstone, можно задать исходный порт 20, а затем приступить к атаке целевого узла через брандмауэр.
Контрмеры: защита и сканирования с исходного порта Предотвращение
Решить описанную проблему очень просто, однако это решение выглядит не очень эффектным. Необходимо запретить любые сетевые взаимодействия, для которых требуется комбинация из нескольких портов (FTP), либо перейти к промежуточным программным брандмауэрам или тем, которые сохраняют состояние соединений. При этом можно значительно повысить управляемость входящими и исходящими соединениями, а также реально контролировать весь процесс.
