Аудит Брандмауэров и Средств обнаружения вторжений (IDS). Часть вторая.
Это вторая часть статьи, в которой описываются различные методы тестирования надежности вашего брандмауэра и IDS, используя низкоуровневые методы и утилиты манипуляции TCP/IP пакетами. В первой части было показано несколько примеров тестирования брандмауэра (80 TCP порт и 53 UDP порт) с использованием утилит hping и tcpdump. Сейчас мы продолжим дискуссию третьим тестированием брандмауэра, используя упомянутые выше утилиты, а затем продвинемся дальше, чтобы проверить сигнатуры и способности обнаружения вашего IDS. Обратите внимание, что все действия производятся в Linux среде, но будут такими же и в других Unix-подобных окружениях брандмауэров/IDS.
Введение
Это вторая часть статьи, в которой описываются различные методы тестирования надежности вашего брандмауэра и IDS, используя низкоуровневые методы и утилиты манипуляции TCP/IP пакетами. В первой части было показано несколько примеров тестирования брандмауэра (80 TCP порт и 53 UDP порт) с использованием утилит hping и tcpdump.
Сейчас мы продолжим дискуссию третьим тестированием брандмауэра, используя упомянутые выше утилиты, а затем продвинемся дальше, чтобы проверить сигнатуры и способности обнаружения вашего IDS. Обратите внимание, что все действия производятся в Linux среде, но будут такими же и в других Unix-подобных окружениях брандмауэров/IDS.Пожалуйста, ознакомьтесь с первой частью этой статьи перед тем, как продолжить чтение.
Тестирование вашего брандмауэра - третий пример, ICMP эхо запросПример, показанный ниже, это простой ICMP эхо запрос для проверки жива ли машина, в данном случае, это наш тестируемый компьютер.
Также как и в первой части этой статьи, мы будем использовать hping и tcpdump, чтобы провести тестирование. Синтаксис и вывод hping для простейшего ICMP это запроса показан ниже:monkeylabs:/home/don # hping -1 192.168.1.108 -c 1 HPING 192.168.1.108 (eth0 192.168.1.108): icmp mode set, 28 headers + 0 data bytes len=46 ip=192.168.1.108 ttl=64 id=122 icmp_seq=0 rtt=0.4 ms --- 192.168.1.108 hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.4/0.4 msНа этот раз, как видно выше, пакет получен и показано время прохождения пакета туда и обратно. В дополнение к этому, похоже, что наш ICMP эхо запрос действительно проходит через брандмауэр.
Ниже обратите внимание на пакет, отправленный с нашей hping машины. Вывод показывает, что на тестируемой машине пакет был получен от компьютера, с которого мы производили пинг.
Ниже еще раз показан синтаксис вызова tcpdump:monkeylabs:/home/don # tcpdump -nXvs 0 ip and host 192.168.1.100 and host 192.168.1.108 tcpdump: listening on eth0 11:10:37.458058 192.168.1.100 > 192.168.1.108: icmp: echo request (ttl 64, id 51585, len 28) 0x0000 4500 001c c981 0000 4001 2d3f c0a8 0164 E.......@.-?...d 0x0010 c0a8 016c 0800 5dd0 9a2f 0000 ...l..]../.. 11:10:37.458260 192.168.1.108 > 192.168.1.100: icmp: echo reply (ttl 64, id 117, len 28) 0x0000 4500 001c 0075 0000 4001 f64b c0a8 016c E....u..@..K...l 0x0010 c0a8 0164 0000 65d0 9a2f 0000 0000 0000 ...d..e../...... 0x0020 0000 0000 0000 0000 0000 0000 0000 ..............Из двух вышеупомянутых ICMP пакетов мы можем сделать вывод, что, так как мы получили ответ, брандмауэр тестируемого компьютера действительно пропускает ICMP пакеты. Я не показал, как тестируемый компьютер получает пакет, поскольку мы успешно доказали, что брандмауэр принимает наши испытательные критерии. И при этом отсутствует какая-либо реакция брандмауэра, что показывает, что наши действия не вызвали срабатывания ни одного из правил брандмауэра.
Тестирование сигнатуры IDS - проверка зарезервированных флагов
Теперь мы начнем тестирование нашего IDS, в данном случае это Snort. Тесты проводились с набором правил Snort по умолчанию.Первый тест, который мы проведем, необходим для того, чтобы посмотреть, правильно ли отреагирует наш IDS, получив пакет с установленными ECN и CWR флагами в тринадцатом байте TCP заголовка.
Синтаксис вызова hping:monkeylabs:/home/don # hping -X -Y 192.168.1.108 -p 80 -c 1 HPING 192.168.1.108 (eth0 192.168.1.108): XY set, 40 headers + 0 data bytes --- 192.168.1.108 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 msПакет, который был отправлен с машины, с которой мы производим тестирование:
/home/don # tcpdump -nXvs 0 tcp and host 192.168.1.100 and 192.168.1.108 tcpdump: listening on eth0 08:42:00.081599 192.168.1.100.1215 > 192.168.1.108.80: WE [tcp sum ok] win 512 (ttl 64, id 29279, len 40) 0x0000 4500 0028 725f 0000 4006 8450 c0a8 0164 E..(r_..@..P...d 0x0010 c0a8 016c 04bf 0050 460e ae8b 6c89 fe96 ...l...PF...l... 0x0020 50c0 0200 c43a 0000 P....:..Обратите внимание на флаги WE в вышеупомянутом пакете. Они показывает, что в этом пакете установлены ECN и CWR флаги.
Теперь взгляните на пакет, пришедший с машины, тестирующей IDS:
/home/don # tcpdump -nXvs 0 tcp and host 192.168.1.108 and 192.168.1.100 tcpdump: listening on eth0 08:40:58.589496 192.168.1.100.1215 > 192.168.1.108.80: WE [tcp sum ok] win 512 (ttl 64, id 29279, len 40) 0x0000 4500 0028 725f 0000 4006 8450 c0a8 0164 E..(r_..@..P...d 0x0010 c0a8 016c 04bf 0050 460e ae8b 6c89 fe96 ...l...PF...l... 0x0020 50c0 0200 c43a 0000 0000 0000 0000 P....:........Пакет такой, каким и должен быть: копия пакета, посланного компьютером, на которой он был создан.
Теперь давайте посмотрим на вывод Snort. Ниже, вы можете увидеть, что Snort при получении пакета выводит некоторую информацию. Вы увидите, что в выводе присутствуют цифры 1 и 2. Они означают, что установлены соответствующие биты в байте. В нашем случае это бит 128 (10000000 в двоичной системе счисления, т.е. 1 бит, флаг CWR -- примечание переводчика) и 64 (01000000 в двоичной системе счисления, т.е. 2 бит, флаг ECE -- примечание переводчика) в тринадцатом байте TCP заголовка. Это байт, содержащий флаги, другими словами флаги типа SYN, FYN, PSH и т.д.
В логе Snort содержится много информации. Я объясню значение полей, начиная с первой строки и продвигаясь слева направо. Мы начнем с поля даты и времени, завершающиеся микросекундами (также как и в tcpdump). Далее находится MAC адрес отправителя и получателя. Затем поле типа, стандартное для DoD Ethernet, а затем и непосредственно длинна пакета. Далее располагается IP адрес и порт отправителя, за которым следуют IP адрес и порт получателя. Далее вы видите надпись "TCP", означающую TCP пакет и время жизни пакета, равное 64. Тип сервиса равен нулю. Затем идет число IP идентификатора, равное 29729, а после него длинна IP заголовка - 20 байтов. DgmLen стандартное для длинны датаграммы. Как было сказано выше, 1 и 2 означают, что в этом пакете установлены биты с позицией 128 и 64. Далее идет позиционный номер и номер подтверждения. Завершают эту информацию размер окна и длинна TCP заголовка.Вывод Snort из нашего первого примера:
03/03-08:40:58.589496 0:C:6E:8C:D4:61 -> 0:50:DA:C5:9D:8B type:0x800 len:0x3C 192.168.1.100:1215 -> 192.168.1.108:80 TCP TTL:64 TOS:0x0 ID:29279 IpLen:20 DgmLen:40 12****** Seq: 0x460EAE8B Ack: 0x6C89FE96 Win: 0x200 TcpLen: 20В файле /var/log/snort/alert, после проверки пакета Snort'ом, в результате совпадения сигнатуры, появилась приведенная ниже информация:
linux:/var/log/snort # more alert [**] [111:1:1] (spp_stream4) STEALTH ACTIVITY (unknown) detection [**] 03/03-08:40:58.589496 0:C:6E:8C:D4:61 -> 0:50:DA:C5:9D:8B type:0x800 len:0x3C 192.168.1.100:1215 -> 192.168.1.108:80 TCP TTL:64 TOS:0x0 ID:29279 IpLen:20 DgmLen:40 12****** Seq: 0x460EAE8B Ack: 0x6C89FE96 Win: 0x200 TcpLen: 20Наш пример был использован для того, чтобы посмотреть, среагирует ли, и запишет ли IDS Snort предупреждение в лог, при получении пакета с флагами ECN и CWR. Как мы видим, все сработало так, как должно.
Тестирование второй сигнатуры IDS - LSRR пакеты
Теперь проверим другую сигнатуру IDS. А именно, мы посмотрим, действительно ли Snort обнаруживает LSSR (Loose Source Record Route, больше известные как гибко маршрутизированные от источника) пакеты так, как предполагается.Синтаксис вызова hping:
monkeylabs:/home/don # hping -S --lsrr 192.168.1.108 192.168.1.102 -p 25 -c 1 HPING 192.168.1.102 (eth0 192.168.1.102): S set, 40 headers + 0 data bytes --- 192.168.1.102 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 msПакеты, как они выглядели при отправке с hping машины:
monkeylabs:/home/don # tcpdump -nXvs 0 ip and host 192.168.1.100 and 192.168.1.108
tcpdump: listening on eth0
09:23:35.134313 192.168.1.100.1636 > 192.168.1.108.25: S [tcp sum ok]
384787509:384787509(0) win 512 (ttl 64, id 57275, len 48, optlen=8 LSRR{192.168.1.102#} EOL)
0x0000 4700 0030 dfbb 0000 4006 7b22 c0a8 0164 G..0....@.{"...d
0x0010 c0a8 016c 8307 08c0 a801 6600 0664 0019 ...l......f..d..
0x0020 16ef 6435 3ac2 97be 5002 0200 d59f 0000 ..d5:...P.......
Вывод Snort показывает, что IDS видело пакет:
03/03-09:22:33.600331 0:C:6E:8C:D4:61 -> 0:50:DA:C5:9D:8B type:0x800 len:0x3E 192.168.1.100:1636 -> 192.168.1.108:25 TCP TTL:64 TOS:0x0 ID:57275 IpLen:28 DgmLen:48 IP Options (1) => LSRR ******S* Seq: 0x16EF6435 Ack: 0x3AC297BE Win: 0x200 TcpLen: 20Ниже мы видим информацию из alert-файла, находящегося в /var/log/snort/:
[**] [1:501:2] MISC source route lssre [**] [Classification: Potentially Bad Traffic] [Priority: 2] 03/03-09:22:33.600331 0:C:6E:8C:D4:61 -> 0:50:DA:C5:9D:8B type:0x800 len:0x3E 192.168.1.100:1636 -> 192.168.1.108:25 TCP TTL:64 TOS:0x0 ID:57275 IpLen:28 DgmLen:48 IP Options (1) => LSRR ******S* Seq: 0x16EF6435 Ack: 0x3AC297BE Win: 0x200 TcpLen: 20 [Xref => http://www.whitehats.com/info/IDS420][Xref => http://cve.mitre.org/ cgi-bin/cvename.cgi?name=CVE-1999-0909][Xref => http://www.securityfocus.com/bid/646]То, что мы получили на тестируемой машине:
linux:/home/don # tcpdump -nXvs 0 ip and host 192.168.1.108 and 192.168.1.100
tcpdump: listening on eth0
09:22:33.600331 192.168.1.100.1636 > 192.168.1.108.25: S [tcp sum ok]
384787509:384787509(0) win 512 (ttl 64, id 57275, len 48, optlen=8
LSRR{192.168.1.102#} EOL)
0x0000 4700 0030 dfbb 0000 4006 7b22 c0a8 0164 G..0....@.{"...d
0x0010 c0a8 016c 8307 08c0 a801 6600 0664 0019 ...l......f..d..
0x0020 16ef 6435 3ac2 97be 5002 0200 d59f 0000 ..d5:...P.......
Как вы видим, IDS Snort детектировала наши LSSR пакеты. Теперь, мы можем быть уверены, что даже набор правил Snort по умолчанию работает так, как обещают разработчики.
Рассеивание нескольких мифов
Наконец, я хотел бы уделить немного времени тому, чтобы рассеять несколько мифов о пакетном тестировании. Первый миф - о переполнении буфера. Вы не можете спровоцировать переполнение буфера, используя утилиту для создания пакетов, потому что установление TCP/IP соединения осуществляется в три этапа, каждый из которых должен быть выполнен, чтобы эксплойт сработал. Это является причиной того, что код должен быть скомпилирован и содержать в себе системные вызовы для осуществления трех шагов установления TCP/IP соединения.Сегодня, в большинстве стеков, позиционный номер псевдослучаен и поэтому трудно предсказуем, что делает атаку предсказания ISN непрактичной, хотя и не невозможной. Таким образом, любые данные, которые вы помещаете в пакет, будут игнорироваться получателем, если вы успешно не завершили установление TCP/IP соединения.
Заключение
Надеюсь, теперь вы видите неоспоримые плюсы пакетного тестирования, и какую пользу оно может принести вам и состоянию вашей защиты. Кроме этого, вы также ознакомитесь с важными вопросами низкоуровневого функционирования TCP/IP. Примеры, которые были приведены в этой и первой части данной статьи являются лишь отправной точкой - настройки сети каждого человека могут быть уникальны и набор правил брандмауэра и сигнатур IDS будут другими. Это заставит вас использовать полученные знания для активного тестирования вашей собственной защищенности.
Я искренне надеюсь, что эта серия статей была вам полезна. Не стесняйтесь контактировать со мной, если у вас есть какие-либо вопросы или пожелания.Собираем и анализируем опыт профессионалов ИБ