Часть первая.
Дон Паркер, перевод Владимир Куксенок
С сегодняшним уровнем угрозы из внешней среды, наличия брандмауэра и 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 со стандартным набором правил.
Ниже показана информация, скопированная из окна моего терминала и синтаксис запуска 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, используя методы описанные здесь. Будьте защищенными.16 августа 2004
Часть вторая.
Введение
Это вторая часть статьи, в которой описываются различные методы тестирования надежности вашего брандмауэра и 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 будут другими. Это заставит вас использовать полученные знания для активного тестирования вашей собственной защищенности.
Я искренне надеюсь, что эта серия статей была вам полезна. Не стесняйтесь контактировать со мной, если у вас есть какие-либо вопросы или пожелания.