Аудит Брандмауэров и Средств обнаружения вторжений (IDS). Часть первая.

Дон Паркер, перевод Владимир Куксенок

С сегодняшним уровнем угрозы из внешней среды, наличия брандмауэра и IDS (Intrusion Detection System - Средство Обнаружения Вторжений) у домашнего или корпоративного пользователя это больше не роскошь, а скорее необходимость. И все же, многие люди не уделяют время для проверки того, что эти средства защиты действительно работают правильно. В конце конов очень просто дискредитировать весь набор правил вашего маршрутизатора, создав всего одно непродуманное правило. То же самое можно сказать о вашем брандмауэре, из-за одного слабого правила, например для вашего iptables, вы может остаться уязвимы. Правильно ли вы настроили некоторые опции вашего брандмауэра? На этот вопрос можно ответить, и что более важно проверить самому с помощью пакетного тестирования. Это позволит вам вручную проверить, правильно ли сконфигурированы ваш брандмауэр и IDS.

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

Эта статья - первая из двух частей, описывает различные способы проверки надежности вашего брандмауэра и IDS, используя низкоуровневые утилиты и методы создания TCP/IP пакетов. Я использовал Linux систему, но все описанное будет так же работать и на других Unix-подобных системах.

Преимущества Пакетного тестирования (Packet Crafting)

Существуют некоторые дополнительные выгоды при изучения способов аудита вашего брандмауэра и IDS, используя пакетное тестирование. Что бы научиться эффективно использовать утилиты типа hping и правильно интерпретировать их данные, вы заставляете себя больше изучать TCP/IP. Глубокое изучение основы компьютерных коммуникаций, пакетов, является хорошей целью для любого, желающего увеличить свои знания о компьютерах. Сказав это, я не буду предполагать, что все читатели этой статьи имеют хорошие знания о TCP/IP. По ходу этой статьи, информация, полученная от используемых программ, будет детально объясняться. Весь вывод Snort и tcpdump будет описан ясно и кратко. Вы можете сказать, что здесь могло бы быть больше информации для углубленного понимания TCP/IP, но эта статья о том, как научиться тестировать правила вашего брандмауэра и IDS.

Будет показано несколько примеров и для брандмауэра и для IDS. Поскольку этот документ предназначен для того, чтобы показать, как работать с hping, Snort и tcpdump, будет присутствовать несколько универсальных примеров. Поэтому, нижеупомянутые примеры - хорошая отправная точка. Упражняясь с нижеизложенной информацией, вы должны чувствовать себя достаточно комфортно, чтобы эффективно протестировать ваш собственный брандмауэр и IDS. Обратите внимание, что есть автоматизированные утилиты, которые могут сделать все это за вас. Тем не менее, очень важно, чтобы вы могли сделать все сами, и были способны контролировать и анализировать результаты. Это даст вам чувство уверенности, знание, что защита вашего периметра работает так, как рекламировалась.

Тестирование вашего брандмауэра - первый пример

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

Допущение
Пожалуйста, обратите внимание на то, что эти тесты проводились на SuSE Linux Professional 9.0 со стандартным набором правил iptables. Я не привожу здесь пример синтаксиса IPTables, т.к. вместо него вы можете использовать IPChains, какой-либо другой брандмауэр, возможно коммерческий брандмауэр или даже другой тип решения. Также, было бы сложно убрать правило, от которого зависят все остальные, что и послужило основной причиной не приводить здесь примеры синтаксиса правил. И, наконец, каждая проверка будет объясняться, чтобы вы могли понять, в каком контексте происходит тестирование. Во второй части мы рассмотрим Snort 2.1.0 со стандартным набором правил.

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

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

hping 			Имя программы, для создания пакетов
-S 			Говорим hping отослать SYN пакет
192.168.1.108 		Указываем адрес получателя, на который будет отправлен SYN 
пакет

-p 80 			Указываем порт на компьютере получателя, в нашем случае это
 порт 80

-c 1 			Этот параметр задает количество отправляемых пакетов, в 
нашем случае это 1

Обратите внимание на вывод hping. В нем показан только адрес получателя, то, что установлен флаг S (SYN пакет), что размер пакета 40 байт (стандартный размер TCP/IP заголовка) и 0 байт данных в пакете.

Оставшаяся часть вывода hping это, как показано ниже, статистика пакета, созданного вами с помощью hping. Здесь говорится, что был отправлен 1 пакет, 0 пакетов было получено назад, и что 100% пакетов были потеряны. Также указано время пути туда и обратно, если хотя бы 1 пакет был отправлен назад.

monkeylabs:/home/don # hping -S 192.168.1.108 -p 80 -c 1
HPING 192.168.1.108 (eth0 192.168.1.108): S 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

Используя вышеупомянутую команду, смотрите ниже, как выглядит пакет, созданный с помощью hping и отсылаемый с локальной машины. Теперь опишем синтаксис вызова tcpdump.

tcpdump			Имя программы
-n 			Указываем, что IP адрес будет в числовом формате
X 			Указываем, что представлять информацию нужно в HEX и ASCII формате.
v 			Более подробный вывод: показывать все информацию о пакете
s 			Включаем перехват пакетов определенной длинны
0 			Если вы укажете 0, tcpdump будет захватывать пакеты с 
длинной по умолчания для вашего компьютера. В моем случае это 1518.

tcp 			Указываем, что хотим перехватывать только TCP пакеты, не 
UDP или ICMP, только TCP.

and host 192.168.1.100 	Указываем, что хотим перехватывать пакеты от 192.168.1.100
and 192.168.1.108 	и от 192.168.1.108

Использование двух вышеупомянутых IP адресов с указанными параметрами вызова tcpdump позволяет перехватывать только пакеты, проходящие между 192.168.1.100 и 192.168.1.108. Это позволит не перехватывать ненужные нам пакеты, например, от DNS сервера вашего ISP или ARP пакеты вашего коммутатора. Чтобы помочь вам в чтении данных вывода tcpdump, ниже я опишу все поля пакета, так же как я описывал синтаксис вызова tcpdump. Мы увидим, что означает каждое поле, начиная с поля времени.

10:07:30.171332 	Время, когда пакет был получен
192.168.1.100.1321 	IP адрес и порт отправителя
192.168.1.108.80 	IP адрес и порт получателя
S 			Указывает на то, что мы посылаем SYN пакет
[tcp sum ok] 		Контрольная сумма правильная
1907499058:1907499058 	Позиционный номер TCP (TCP sequence)
(0) 			Количество байт данных в пакете
win 512 		Размер окна
[tos 0x8]		Тип сервиса
ttl 64 			Число перемещений, за которое пакет должен достигнуть 
получателя
id 45106 		Идентификационный номер пакета, используется для сборки 
пакета после фрагментации
len 40 			Длинна пакета

/home/don # tcpdump -nXvs 0 tcp and host 192.168.1.100 and 192.168.1.108
tcpdump: listening on eth0

10:07:30.171332 192.168.1.100.1321 > 192.168.1.108.80: S [tcp sum ok] 
1907499058:1907499058(0) win 512 [tos 0x8]  (ttl 64, id 45106, len 40)
0x0000   4508 0028 b032 0000 4006 4675 c0a8 0164        E..(.2..@.Fu...d
0x0010   c0a8 016c 0529 0050 71b2 2032 53e1 85d2        ...l.).Pq..2S...
0x0020   5002 0200 b8b0 0000                                    P.......

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

Mar 2 10:06:40 linux kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= 
MAC=00:50:da:c5:9d:8b:00:0c:6e:8c:d4:61:08:00 SRC=192.168.1.100 
DST=192.168.1.108 LEN=40 TOS=0x08 PREC=0x00 TTL=64 ID=45106 PROTO=TCP  
SPT=1321 DPT=80 WINDOW=512 RES=0x00 SYN URGP=0 

Это пакет, достигший тестируемой машины. Как мы видим, все нормально:

/home/don # tcpdump -nXvs 0 tcp and host 192.168.1.108 and 192.168.1.100
tcpdump: listening on eth0

10:06:40.474204 192.168.1.100.1321 > 192.168.1.108.80: S [tcp sum ok] 
1907499058:1907499058(0) win 512 [tos 0x8] (ttl 64, id 45106, len 40)
0x0000   4508 0028 b032 0000 4006 4675 c0a8 0164       E..(.2..@.Fu...d
0x0010   c0a8 016c 0529 0050 71b2 2032 53e1 85d2       ...l.).Pq..2S...
0x0020   5002 0200 b8b0 0000 0000 0000 0000              P.............

Итак, мы можем наблюдать, как пакет был отослан, получен тестируемой машиной, но, однако был заблокирован.

Тестирование вашего брандмауэра - второй пример, исследование 53 UDP порта

Теперь мы будем исследовать 53 UDP порт. Обратите внимание на синтаксис вызова hping, а также на его вывод:

monkeylabs:/home/don # hping -2 192.168.1.108 -p 53 -c 1

HPING 192.168.1.108 (eth0 192.168.1.108): udp mode set, 28 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
monkeylabs:/home/don #

Только что мы отослали пакет на 53 UDP порт, что посмотреть, заблокирует ли его брандмауэр. Как мы можем видеть из вывода hping и информации от брандмауэра ниже, пакет был заблокирован, т.к. 53 UDP порт закрыт.

Mar  2 10:24:30 linux kernel: SuSE-FW-DROP-DEFAULT IN=eth0 OUT= 
MAC=00:50:da:c5:9d:8b:00:0c:6e:8c:d4:61:08:00 SRC=192.168.1.100 
DST=192.168.1.108 LEN=28 TOS=0x10 PREC=0x00 TTL=64 ID=47873 
PROTO=UDP  SPT=2180 DPT=53 LEN=8 

Это пакет, который был получен на тестируемом компьютере:

/home/don # tcpdump -nXvs 0 udp and host 192.168.1.108 and 192.168.1.100 tcpdump: listening on eth0

10:24:30.172588 192.168.1.100.2180 > 192.168.1.108.53: [udp sum ok]  0 [0q] 
(0) [tos 0x10]  (ttl 64, id 47873, len 28)
0x0000   4510 001c bb01 0000 4011 3b9f c0a8 0164        E.......@.;....d
0x0010   c0a8 016c 0884 0035 0008 7304 0000 0000        ...l...5..s.....
0x0020   0000 0000 0000 0000 0000 0000 0000                .............

Это пакет, который был отправлен с компьютера, который мы используем для проверки защищенности брандмауэра:

monkeylabs:/home/don # tcpdump -nXvs 0 udp and host 192.168.1.100 and 192.168.1.108 
tcpdump: listening on eth0

10:25:19.887529 192.168.1.100.2180 > 192.168.1.108.53: [udp sum ok] [|domain] 
[tos 0x10]  (ttl 64, id 47873, len 28)
0x0000   4510 001c bb01 0000 4011 3b9f c0a8 0164        E.......@.;....d
0x0010   c0a8 016c 0884 0035 0008 7304                      ...l...5..s.

Нормальным поведением, в случае, когда UDP пакет отправлен на не прослушиваемый порт, является отправка ICMP сообщения о том, что порт недоступен. В нашем случае этого не происходит, потому что на тестируемом компьютере в конфигурации iptables установлена "тихая" блокировка этого типа пакетов (т.е. без отправки соответствующего ICMP сообщения об ошибке).

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

В заключение первой части

Мы рассмотрели два примера исследования вашего брандмауэра с использованием hping и tcpdump. В следующий раз, во второй части этой серии статей мы рассмотрим другой пример тестирования брандмауэра, а затем начнем тестирование IDS Snort, используя методы описанные здесь. Будьте защищенными.