Начнем изучение полей IP-заголовка. При рассмотрении каждого поля будет описано его предназначение, представлены сведения о его нормальных и необычных значениях; о чем можно узнать по информации этого поля, и каким образом осуществляются атаки при манипуляциях со значениями этого поля.

Номер версии протокола IP

Единственными действительными версиями протокола IP являются версии 4 и 6. Наиболее распространенная версия в настоящее время - версия IPv4. IPv6 постепенно внедряется на магистральных линиях Internet.

Значение поля версии протокола IP проверяется хостом-получателем и, если номер недействителен, дейтаграмма отбрасывается без какого-либо уведомления отправителя (согласно RFC 1121). Поэтому создание дейтаграмм с недействительным номером версии IP не имеет никакого смысла, разве что позволяет проверить соблюдение получателем требований RFC.

Пакет с указанием неверной версии IP также будет отброшен на маршрутизаторе без уведомления отправителя. Таким образом, провести атаку со вставкой будет очень сложно, если только злоумышленник не находится в одной сети с системой обнаружения вторжений. В последнем случае злоумышленник может отправить интересующему хосту несколько пакетов с неверными номерами версии IP, и если система обнаружения вторжений их не отбросит, то это можно назвать атакой со вставкой - какие-то пакеты, пропускаемые NIDS, затем отклоняются конечным хостом или маршрутизатором.

Протокол

В поле “Протокол” указывается номер, обозначающий протокол, который был использован при создании вложенного пакета. Список всех возможных номеров протоколов этого поля можно получить по адресу www. iana . org/assignments/ protocol-numbers. В последних версиях программы nmap подерживается возможность сканирования удаленных хостов на предмет поддерживаемых протоколов (все 256 различных вариантов). Для этого применяется параметр командной строки -sO. Протокол считается поддерживаемым, если не возвращается ICMP-сообщение “protocol unreachable”. Ниже представлен пример команды сканирования на предмет поддерживаемых протоколов и результат выполнения этой команды, nmap -sO target

Starting nmap V. 2.54BETA1 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Interesting protocols on myhost.net (192.168.5.5):

(The 250 protocols scanned but not shown below are in state: closed)

Protocol State Name

1 open icmp

2 open icmp

6 open tcp

17 open udp

Теперь рассмотрим отчет о зарегистрированном трафике при данном сканировании.

07:30:31.405513 scanner.net > target.com: ip-proto-124 0 (DF) 07:30:31.405581 scanner.net > target.com: ip-proto-100 О (DF) 07:30:31.405647 scanner.net > target.com: ip-proto-166 0 (DF) 07-.30-.31.405899 target.com > scanner.net: icmp: target.com protocol 124 'Ъ unreachable (DF)

07:30:31.788701 scanner.net > target.com: ip-proto-132 0 (DF) 07:30:32.119538 target.com > scanner.net: icmp: target.com protocol 166 unreachable (DF)

07:30:34.098715 scanner.net > target.com: ip-proto-236 0 (DF) 07:30:34.098782 scanner.net >,target.com: ip-proto-129 0 (DF) 07:30:34.098849 scanner.net > target.com: ip-proto-229 0 (DF) 07:30:32.779583 target.com > scanner.net: icmp: target.com protocol 236 unreachable (DF)

07:30:34.099557 target.com > scanner.net: icmp: target.com protocol 109 'Ъ unreachable (DF)

При сканировании nmap проверяются 256 возможных типов протоколов. Сканируемый хост должен отвечать ICMP-сообщением “protocol unreachable” для любого неподдерживаемого им протокола.

Этот тип сканирования также позволяет выявить активные хосты. Это скрытое сканирование, которое не всегда выявляется системами обнаружения вторжений. Однако, если на маршрутизаторе- шлюзе локальной сети с сетью Internet - предусмотрена выдача сообщений во внешние интерфейсы “no ip unreachables” (“недоступных протоколов нет”) или просто блокируется весь исходящий ICMP-трафик, то данное сканирование не даст никакого полезного результата.

Есть определенный недостаток в используемом программой nmap методе для определения поддерживаемого протокола. Заключение делается на основе отсутствия сообщения “protocol unreachable”. Но в случае блокирования исходящего ICMP-трафика эти сообщения не поступят. Кроме того, возможна потеря пакетов и ошибочная реакция nmap. Поэтому создатель nmap постарался учесть подобные проблемы. Для устранения возможности случайной потери пакетов и проверки каждого протокола отправляется по несколько пакетов. Кроме того, если не вернулось ни одного ICMP-сообщения о недоступности протокола, nmap предполагает фильтрацию исходящего трафика для сканируемого хоста и выдает соответствующее уведомление.

Простая аналогия

Программа nmap использует отсутствие уведомления как подтверждение использования протокола. Как мы убедились, такой подход имеет определенные недостатки.

Эта ситуация напоминает мне пример из реальной жизни, когда в лечебном учреждении нужно сдать анализ крови. Поскольку и у врачей, и у медсестер очень много работы, то после анализа они обычно говорят, что сообщат вам, если что-то будет не в порядке. Таким образом, отсутствие уведомления является подтверждением того, что вы абсолютно здоровы.

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

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

Тип обслуживания

С момента своего первоначального появления в составе IP-заголовка байт “Тип обслуживания” (Type of Service - ToS) претерпел несколько изменений. Одним из них стало предусмотренное в документе RFC 2481 и более новом RFC 3168 использование двух младших битов этого байта для хранения явного уведомления о перегрузке (Explicit Congestion Notification - ECN). Это связано с использованием некоторыми маршрутизаторами метода случайного раннего обнаружения (Random Early Detection - RED) или активного управления очередями с вероятностью потери пакетов.

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

Существует два возможных значения битов ECN, которые сообщают о поддержке уведомления о перегрузке хостом-отправителем: 01 и 10 (рис. 8.3). Если отправитель поддерживает явное уведомление о перегрузке (ECN), маршрутизатор, использующий метод RED, старается не отбрасывать пакет, а отправить его с уведомлением о возникновении перегрузки (Congestion Experienced - СЕ). Для этого значения обоих младших битов байта “Тип обслуживания” устанавливаются равными единице (11). Хост-отправитель должен отреагировать на получение пакета с этим уведомлением снижением скорости передачи информации. Мы рассмотрим эту тему более подробно при изучении полей TCP-заголовка в следующей главе.

Рис. 8.3. Байт поля “Тип обслуживания”, содержащий биты ECN

Флаг DF

Флаг DF (Don’t Fragment - не фрагментировать) устанавливается в заголовке IP-дейтаграммы для запрещения ее фрагментации. Если маршрутизатор определяет необходимость фрагментации дейтаграммы, но установлен флаг DF, то такая дейтаграмма отбрасывается, и отправителю возвращается ICMP-уведомление “unreachable - need to frag <размер MTU>". Большинство современных маршутизаторов возвращают в этом сообщении размер максимальной единицы передачи данных (MTU) участка сети, на котором требуется фрагментация.

Фрагментация приводит к непроизводительным издержкам, поэтому ее следует избегать. При потере одного из фрагментов должна быть заново отправлена вся последовательность фрагментов. Поэтому при отправке данных некоторыми версиями стека TCP/IP сначала отправляется пробный пакет с установленным флагом DF. Если этот пакет достигнет адреса назначения без возвращения ICMP-уведомлений об ошибках, то для последующих пакетов устанавливается этот же размер дейтаграммы. Если же возвращается ICMP-сообщение “unreachable - need to frag”, содержащее значение MTU, размер пакета уменьшается настолько, чтобы обеспечить доставку пакета без фрагментации (предполагается, что входящий ICMP-трафик не блокируется).

В стеках TCP/IP некоторых операционных систем флаг DF устанавливается по умолчанию для определенных типов пакетов, и программа пшар использует это свойство для определения операционной системы удаленного хоста. Кроме того, нарушитель может установить флаг DF для проведения атаки со вставкой. В этом случае система обнаружения вторжений должна быть установлена в сети с большей MTU, чем сеть, в которой установлен хост-получатель. Атакуемому хосту отправляется набор пакетов, среди которых в одном или нескольких установлен флаг DF. Система обнаружения вторжений получает этот пакет, учитывает его содержимое и отбрасывает его. Таким образом, атакуемый хост не получит этот “лишний” для атаки пакет (или пакеты).

Флаг MF

Установленный флаг MF (More Fragments - следующий фрагмент) указывает, что за этим фрагментом следует еще один или несколько фрагментов. Этот флаг устанавливается во всех фрагментах, кроме последнего. Хост-получатель распознает фрагментированный трафик по наличию этого флага или по значению поля смещения фрагмента IP-заголовка (отличного от нуля).

Сканирование сети с помощью отдельных фрагментов

Один из методов составления схемы сети основан на получении ICMP-сообщения “reassembly time exceeded” (“превышено время на повторную сборку пакета”) от хостов сканируемой сети. Для этого сканируемым хостам может отправляться незавершенная последовательность фрагментов. Хост-получатель должен ожидать запросов на сканируемый порт, если трафик представляет собой TCP- или UDP-пакеты. Когда сканируемый хост получает первый фрагмент, он запускает таймер. Если время ожидания превышает установленный предел, а хост так и не получил все фрагменты, он возвращает отправителю ICMP-сообщение об ошибке “IP reassembly time exceeded”.

Важно, что (согласно RFC 792) для отправки этого ICMP-сообщения обязательно должен быть получен первый фрагмент последовательности. В противном случае хост-получатель не запускает таймер. По рекомендациям RFC 1122 лимит времени таймера должен составлять от 60 с до 2 мин, но, как мы увидим, это не всегда соблюдается.

hping2 -S -р 139 -х win98

06:49:36.986218 verbo.2509 > win98.netbios-ssn: S 198 0 004 944:198 00 04 944(0) ^win 512 (frag 38912:2000+)

06:50:41.636506 win98 > verbo: icmp: ip reassembly time exceeded

hping2 -S -p 21 -x linux

11:56:04.064978 verbo.2450 > linux.ftp: S 119842 3 806:1198423 806(0) win 512 ^(frag 3 9067 : 2 0@0 + )

11:56:34.056813 linux > verbo: icmp: ip reassembly time exceeded [tos OxcO]

Утилита hping2 является бесплатным программным средством, которое используется для генерации различных типов трафика. В первом случае запуск команды hping2 позволяет отправить SYN-пакет (параметр -S) на порт получателя 139(-р 139) с установленным флагом MF ( - х). Первый пакет отправляется хосту win98, который работает под управлением Windows 98 и ожидает запросов на ТСР-порт 139.

Отправленный пакет представляет собой полный SYN-пакет: 20 байт IP-заголовка и 20 байт TCP-заголовка. Никаких данных не передается, но хост получатель ничего об этом не знает, так как установлен флаг MF (об этом говорит знак + в отчете TCPdump). Хост win9 8 ожидает приблизительно около одной минуты, пока истечет лимит времени на сборку последовательности фрагментов. Затем он возвращает ICMP-сообщение “IP reassembly time exceeded”.

Второй пакет, отправленный утилитой hping2, используется для проверки хоста под управлением Linux (версия ядра 2.2), на котором запущена служба FTP. Этот хост ожидает около 30 с, чтобы получить оставшиеся фрагменты на свой порт 21.

1Р-адреса

В двух 32-битовых полях IP-заголовка содержатся IP-адреса отправителя и получателя. Значение IP-адреса отправителя содержится в 12-15-ом байтах IP-заголовка, а значение IP-адреса получателя - в 16- 19-ом байтах.

Какие подложные значения IP-адреса отправителя могут быть указаны во входящих пакетах? Например, если во входящем в локальную сеть пакете указан 1Р-адрес одного из хостов этой же локальной сети, то, очевидно, проводится атака. Скорее всего, кто-то сформировал пакет с подложным IP-адресом. Устройство фильтрации пакетов должно блокировать такой трафик. Кроме того, во входящих пакетах в качестве IP-адреса отправителя никогда не должен содержаться ни адрес петли обратной связи 127.0.0.1, ни один из адресов диапазонов, зарезервированных IANA для частных сетей (определены в RFC 1918). Полный перечень этих адресов доступен по адресу www.iana.org/assignments/ipv4-address-space.

В пакетах исходящего трафика должны быть указаны IP-адреса отправителя, одного из хостов адресного пространства, выделенного для данной локальной сети. Если в пакете, исходящем из локальной сети, содержится неизвестный IP-адрес отправителя, то либо IP-адрес был подменен, либо неверно выполнена настройка хостов этой сети. В любом случае такой исходящий трафик должен быть заблокирован. Это предотвратит использование хостов вашей сети в распределенных атаках отказа в обслуживании, так как подчиненные хосты (зомби-хосты) обычно используют подмененные IP-адреса. Также будут заблокированы исходящие попытки скрытого сканирования чужих сетей с использованием подмены IP-адреса. Кроме того, из вашей сети не должны отправляться пакеты с IP-адресами отправителя 127.0.0.1 (адрес петли обратной связи локального хоста) или IP-адресами, зарезервированными для использования в локальных сетях.

И в завершение следует блокировать и входящий, и исходящий трафик с широковещательными адресами получателя. Такие адреса обычно используются для быстрого сканирования сетей или при проведении атаки Smurf.

Идентификатор

Значение идентификатора хранится в 4-м и 5-м байтах IP-заголовка. Для каждой новой отправляемой хостом дейтаграммы должен генерироваться уникальный идентификатор. Это значение обычно увеличивается на 1, хотя в некоторых случаях на 256 для каждой новой дейтаграммы.

Это уникальное значение требуется при фрагментации дейтаграммы. Всем фрагментам одной дейтаграммы присваивается одинаковый идентификатор. Поэтому часто такое поле называют идентификатором фрагмента. С помощью значения идентификатора хост-получатель сможет повторно собрать фрагменты одной дейтаграммы.

Возможные значения идентификатора лежат в диапазоне от 1 до 65535, так как это 16-битовое поле (значение 0, как правило, не используется). Когда достигается максимальное значение 65535, значение обнуляется и отсчет опять начинается с 1. Очевидно, что в пакетах из различных источников последовательности идентификаторов должны различаться. Поэтому, если регистрируется подозрительный трафик и, несмотря на то, что указаны различные IP-адреса отправителя, все равно сохраняется последовательное увеличение значений идентификаторов, то, скорее всего, осуществляется подмена IP-адресов отправителя.

Как и любое другое значение поля IP-заголовка, значение идентификатора может быть подменено хакером. Например, если злоумышленник использует программу, которая отправляет все пакеты с одинаковым идентификатором, то вы не сможете получить по значению этого поля какую-либо информацию о хосте нарушителя. Для отображения значений поля идентификатора и поля TTL в программе TCPdump предназначен параметр командной строки - w.

Поле TTL

В поле TTL (Time to Live - время жизни) содержится 8-битовое значение, которое устанавливается отправителем. Начальное значение TTL зависит от варианта стека TCP/IP, используемого на конкретном хосте (табл. 8.1). Узнать варианты начальных значений различных операционных систем можно по адресу project.honeynet.org/papers/finger/traces. Как уже указывалось, каждый маршрутизатор на пути следования пакета уменьшает значение этого поля на 1. Если значение становится равным 0, то пакет отбрасывается, и отправителю возвращается ICMP-сообщение “time exceeded in-transit”. Это позволяет удалить пакеты, которые попали в замкнутый цикл передачи. Значение поля TTL может использоваться для проведения атаки со вставкой, если система обнаружения вторжений учитывает этот пакет, хотя значение поля TTL не позволит этому пакету достигнуть хоста-получателя.

Как можно проверить, что пакет пришел именно от указанного отправителя? Можно узнать значение поля TTL принятого пакета, посмотреть на начальное значение этого поля (см. табл. 8.1) и, отняв от второго значения первое, получить ко личество переходов на пути пакета к сети получателя. Затем можно воспользоваться программой Traceroute и проверить количество переходов на обратном маршруте к хосту с подозрительным IP-адресом. Полученное значение может отличаться от количества переходов (hop count) при доставке подозрительного пакета по причине динамического характера маршрутизации. Но обычно эти значения не слишком различаются, если не было каких-либо серьезных проблем с маршрутизаторами или перегрузки в сети во время передачи одного из двух пакетов.

Таблица 8.1. Начальные значения поля ТТЬ для различных операционных систем

Операционная система

Версия

Платформа

TTL

Windows

9x/NT

Intel

32

AIX

4.3.x

IBM/RS6000

60

AIX

4.2.x

IBM/RS6000

60

Cisco

11.2

7507

60

IRIX

6.x

SGI

60

Linux

2.2.x

Intel

64

OpenBSD

2.x

Intel

64

Solaris

8

Intel/Sparc

64

Windows

9x/NT

Intel

128

Windows

2000

Intel

128

Cisco

12.0

2514

255

Solaris

2.x

Intel/Sparc ‘

255

Если пакеты поступают от различных отправителей, существует большая вероятность того, что значения поля ТТЕ в поступивших пакетах будут различными. Если же одновременно от разных отправителей поступают пакеты с одинаковым значением поля ТТЬ, то это похоже на подмену 1Р-адреса отправителя.

Будьте готовы к тому, что некоторые программы сканирования специально устанавливают случайные начальные значения поля ТТЬ, чтобы устранить возможность отслеживания по этому значению источника дейтаграммы.

Обнаружение подмены 1Р-адреса по значениям идентификатора и поля ТТЬ

Давайте рассмотрим следующий отчет.

07:31:57.250000 somewhere.de > 192.168.104.255: icmp: echo request ^ (ttl 246, id 5134)

07:34:18.090000 somewhere.jp > 192.168.104.255: icmp: echo request ^ (ttl 246, id 5137)

07:35:19.450000 somewhere.ca > 192.168.104.255: icmp: echo request ^ (ttl 246, id 5141)

В этом отчете показаны пакеты, поступившие от трех различных отправителей к одному хосту-получателю. Временные метки свидетельствуют о доставке пакетов через несколько минут один после другого. Обратите внимание на значения идентификаторов дейтаграмм. Чем же необычны эти значения полей идентификатора и для чего предназначен этот трафик?

Странно то, что значения идентификаторов постепенно увеличиваются, хотя пакеты как будто поступают от различных источников на один IP-адрес получателя - 192 .168 .104 . 255. В подсети 192 .168 .104 активных хостов нет, поэтому данный трафик становится еще более подозрительным. Хотя это может быть редким стечением обстоятельств, но, скорее всего, все эти эхо-запросы ICMP отправляются с одного хоста.

Напомним, что возможное значение поля идентификатора IP-заголовка находится в диапазоне от 1 до 65535. Поэтому вероятность случайного поступления трех пакетов от различных отправителей с идентификаторами в диапазоне от 5134 до 5141 за несколько минут крайне мала. Если предположить, что номера идентификаторов не были подменены, то похоже, что пакеты отправляет один, не очень производительный, хост (возможно, простой персональный компьютер).

Как и при изучении любого неизвестного трафика, ответить на вопрос что значительно проще, чем на вопрос зачем. Может, это попытка сканирования, и указан один действительный IP-адрес, а два IP-адреса подменены? Это позволяет хакеру создать “дымовую завесу”: даже если сканирование будет замечено, возможно, не удастся выявить его истинный источник.

Теперь давайте проанализируем тот же трафик, но с точки зрения значений поля TTL. Странно, что все значения поля TTL в разных пакетах совпадают. Это еще больше подтверждает наше предположение об отправке всех трех пакетов с одного хоста. Какова вероятность того, что у трех различных отправителей начальным значением этого поля было 255, и каждый пакет, предназначенный одному и тому же получателю, прошел по девять переходов, и все они поступили приблизительно одновременно?

С помощью параметра командной строки - w программы TCPdump в отчетах дополнительно отображается информация двух полей, которая может послужить для проверки подозрительного трафика.

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

traceroute somewhere.de

arriving TTL: 246

probable initial TTL: 255

expected hop count back: 9

actual hop count back: 13

traceroute somewhere.jp

arriving TTL: 246

probable initial TTL: 255

expected hop count back: 9

actual hop count back: 13

traceroute somewhere.ca

arriving TTL: 24 6

probable initial TTL: 255

expected hop count back: 9

actual hop count back: 12

В данном случае использование ТгасетоШе не позволяет сделать окончательный вывод. Для обратной доставки пакета каждому из отправителей потребовалось или 12, или 13 переходов. Но это не позволяет однозначно определить подмену или истинность указанных 1Р-адресов отправителей.

Число переходов на обратном маршруте (12 или 13) довольно близко к ожидаемому числу переходов (9). Тем не менее информация полей идентификатора и TTL указывает на вероятную подмену IP-адресов. Лучшим доказательством этой подмены послужило бы значительное расхождение между ожидаемым и действительным количеством переходов, получаемым с помощью Traceroute.

Нужно дать несколько предупреждений относительно использования Traceroute как средства экспертизы. Во-первых, работа этой программы может быть остановлена из-за блокирования маршрутизатором или устройством фильтрации пакетов ICMP-трафика, в частности сообщений “time exceeded intransit” и “port unreachable”. Во-вторых, помните, что выполнение команды traceroute по отношению к реальному IP-адресу хоста хакера нежелательно, так как явно указывает на интерес к этому хосту.

Контрольная сумма

С помощью контрольных сумм обеспечивается проверка целостности информации, передаваемой по сети. Данные IP-заголовка разбиваются на 16-битовые поля. Для каждого 16-битового поля вычисляется поразрядное дополнение до единицы. Подсчитывается сумма этих поразрядных дополнений, которая и является контрольной суммой.

Контрольная сумма сохраняется в 10-м и 11-м байтах IP-заголовка. Контрольная сумма гарантирует целостность полей только IP-заголовка. Она отличается от контрольных сумм, подсчитанных в заголовках вложенных пакетов, и проверяется на каждом маршрутизаторе на пути следования IP-дейтаграммы, а также на хосте-получателе. Контрольные суммы в заголовках вложенных пакетов (TCP, UDP или ICMP) проверяются только на хосте-получателе.

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

Формула подсчета контрольной суммы IP-заголовка используется для подсчета. всех других контрольных сумм заголовков вложенных пакетов. Итак, сначала IP-заголовок разделяется на 16-битовые поля. Так как длина IP-заголовка всегда кратна 4 байт, то она всегда будет делиться без остатка.

Затем для каждого поля вычисляется поразрядное дополнение до единицы. Эта операция заключается в зеркальном отображении значений битов. Затем значения отдельных дополнений суммируются. Приведем пример.

4

5

0

0

Шестнадцатеричный формат

0100

0101

0000

0000

Двоичный формат

1011

1010

1111

1111

Поразрядное дополнение до единицы

Выше приведены первые 16 бит стандартного 1Р-заголовка. Каждое шестнадцатеричное значение представляется четырьмя двоичными битами, и каждый из этих битов отображается зеркально, что и является поразрядным дополнением до 1. Это коммутативная операция, поэтому можно сначала сложить шестнадцатеричные значения 16-битовых полей, а затем подсчитать поразрядное дополнение до единицы этой суммы. Результат контрольной суммы от этого не изменится.

Контрольная сумма IP-заголовка проверяется на каждом промежуточном маршрутизаторе на пути следования IP-дейтаграммы. Если значение остается правильным, то маршрутизатор уменьшает значение поля TTL на единицу и передает дейтаграмму далее. Такая проверка действительно имеет смысл. В самом худшем случае в результате доставки пакета хост-получатель будет выведен из строя. Поэтому нет смысла передавать искаженный пакет, так как искажение может затронуть и содержимое пакета.

Хотя с помощью контрольных сумм IP-заголовка и заголовков вложенных пакетов проверяется целостность большинства пакетов, но все же возможны исключения. Например, если поменять местами 16-битовые поля исходной дейтаграммы, контрольная сумма искаженного пакета останется неизменной.

4500 003с 4500 = 0100 0101 0000 0000 1011 1010 1111 1111

003с = 0000 0000 ООН 1100 1111 1111 1100 0011

1011 1010 1100 0010

003с 4500

003с = 0000 0000 0011 1100 1111 1111 1100 0011

4500 = 0100 0101 0000 0000 1011 1010 1111 1111

1011 1010 1100 0010

Рассмотрим этот пример. Мы поменяли местами два первых 16-битовых поля (4500 003с) IP-заголовка. Контрольная сумма для правильной последовательности этих 16-битовых полей равна 1011 1010 1100 0010. Но если переставить эти поля местами и снова подсчитать контрольную сумму, то результат получится тем же. Очевидно, что смысл дейтаграммы при обмене местами полей будет совершенно иным. Это недостаток алгоритма вычисления контрольной суммы.

Почему же не использовать более сложный и надежный алгоритм подсчета контрольных сумм? Ответ прост. Не забывайте, что вычисление контрольной суммы выполняется для каждого пакета на каждом маршрутизаторе. Чем проще вычисление, тем оно быстрее выполняется. Данный алгоритм позволяет очень быстро и достаточно надежно провести вычисления, так как простая перестановка 16-битовых полей встречается крайне редко. Более подробную информацию о контрольных суммах можно прочесть в RFC 1071.

Резюме

Хотя системы обнаружения вторжений позволяют значительно увеличить безопасность работы в сети, они не являются панацеей и не способны выявить любой вредоносный трафик. Так, атаки со вставкой и скрытые атаки приводят к неправильной интерпретации передаваемого потока информации. Существует множество вариантов этих атак, и сетевые системы обнаружения вторжений не в состоянии определить, как будет реагировать на пакет конкретный хост-получатель, так как не известны все нюансы используемого на нем стека протоколов TCP/IP. Кроме того, системы обнаружения вторжений не располагают сведениями о топологии защищаемой сети, поэтому возможны атаки, при которых пакеты с небольшими значениями поля TTL не достигают хоста получателя. По этому вместо сетевых систем обнаружения вторжений используют системы обнаружения вторжений для защиты конкретного хоста.

Квалифицированный аналитик сетевого трафика обязан знать типы полей и возможные значения этих полей 1Р-заголовка. Это позволит ему быстро обнаруживать необычный трафик. Выявление необычных значений полей часто не позволяет ничего сказать о предназначении вредоносного пакета, но должно служить сигналом опасности.

Атаки со вставкой и скрытые атаки | Обнаружение нарушений безопасности в сетях | Анализ заголовков вложенных пакетов


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июль
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс