аудит файрволлов и средств обнаружения вторжений (IDS)

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

преимущества пакетного тестирования (packet crafting)

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

тестирование файрволла - первый пример

Сейчас мы начнем с нескольких примеров того, как проверить ваш файрволл в различных условиях. Вначале нужно проверить, виден ли 80 порт через файрволл. Второй пример проверит, открыт ли 53 порт.
Пожалуйста, обратите внимание на то, что эти тесты проводились на SuSE Linux Professional 9.0 со стандартным набором правил iptables. Я не привожу здесь пример синтаксиса iptables, т.к. вместо него вы можете использовать ipchains, какой-либо другой файрволл (возможно, коммерческий) или даже другой тип решения. Также, было бы сложно убрать правило, от которого зависят все остальные, что и послужило основной причиной не приводить здесь примеры синтаксиса правил. И, наконец, каждая проверка будет объясняться, чтобы вы могли понять, в каком контексте происходит тестирование.
Пример ниже показывает пакет, посланный на 80 порт. Как и должно быть в соответствии с конфигурацией нашего файрволла, пакет блокируется.
Ниже показана информация, скопированная из окна моего терминала и синтаксис запуска hping. Я опишу параметры hping, задействованные в этом примере, и далее, если не будет больших различий в синтаксисе, уточнять их не буду.

hping -S 192.168.1.108 -p 80 -c 1

Где:
-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 –nXvs 0 tcp and host 192.168.1.100 and 192.168.1.108 и от 192.168.1.108

-n - указываем, что IP адрес будет в числовом формате;
-X - указываем, что представлять информацию нужно в HEX- и ASCII-формате;
-v - более подробный вывод: показывать всю информацию о пакете;
-s0 - включаем перехват пакетов определенной длинны, если вы укажете 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 - число скачков (хопов, hops), за которое пакет должен достигнуть получателя;
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.

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

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