Аудит Брандмауэров и Средств обнаружения вторжений (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 будут другими. Это заставит вас использовать полученные знания для активного тестирования вашей собственной защищенности.

Я искренне надеюсь, что эта серия статей была вам полезна. Не стесняйтесь контактировать со мной, если у вас есть какие-либо вопросы или пожелания.