Материал: Логико-лингвистические модели атак на компьютерные системы. Остапенко Г.А., Дмитриева Е.Ю

Утилита Genius позволяет выявлять как попытки обычного сканирования, т.е. с установлением TCP-соединения, так и SYN-сканирования (рисунок 2.26).

Рисунок 2.26 - Окно предупреждения о сканировании порта

Еще одним детектором сканирования для системы Windows, является программа ZoneAlarm хорошо подходит для платформы Windows и может применяться в качестве средства IDS на уровне брандмауэра.

Чтобы злоумышленнику помешать реализовать сканирование портов на защищаемом компьютере, необходимо свести к минимуму связанный с этим риск. Для этого нужно заблокировать все службы, в работе которых нет необходимости. В среде UNIX данная задача решается с помощью добавления символов комментария в соответствующие строки файла /etc/inetd. corif, а также отключения автоматического запуска ненужных служб в сценарии начальной загрузки.

В системе Windows также целесообразно отключить все ненужные службы. Это можно реализовать, запустив аплет Services панели управления.

3 Анализ сетевого трафика

3.1 Анализ сетевого трафика сети Internet

В сети Internet основными базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol). TELNET - это протокол виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к серверам Internet в режиме ВТ. FTP - протокол, предназначенный для передачи файлов между удаленными хостами. Для получения доступа к серверу по данным протоколам пользователю необходимо пройти на нем процедуру идентификации и аутентификации. В качестве информации, идентифицирующей пользователя, выступает его идентификатор (имя), а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, что пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде. Таким образом, необходимым и достаточным условием для получения удаленного доступа к хостам по протоколам FTP и TELNET являются имя и пароль пользователя.

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

3.1.1 Ложные arp-ответы

Для перехвата трафика между узлами А и В, расположенными в одной IP-сети, злоумышленник использует протокол ARP. Он рассылает сфальсифицированные ARP-сообщения так, что каждый из атакуемых узлов считает MAC-адрес злоумышленника адресом своего собеседника, (рисунок 3).

Рисунок 3 - Схема ARP-атаки

План атаки:

1. Злоумышленник определяет MAC-адреса узлов А и В:

% ping IP(A); ping IP(B); arp —a

2. Злоумышленник конфигурирует дополнительные логические IP-интерфейсы на своем компьютере, присвоив им адреса А и В и отключив протокол ARP для этих интерфейсов, чтобы их не было «слышно» в сети, например:

# ifconfig hme0:1 inet IP(A) -arp

# ifconfig hme0:2 inet IP(B) -arp

Затем он устанавливает статическую ARP-таблицу:

# arp —s IP(A) MAC(A)

# arp —s IP(B) MAC(B)

и разрешает ретрансляцию IP-датаграмм (переводит компьютер в режим маршрутизатора).

3. Злоумышленник отправляет на МАC-адрес узла А кадр со сфабрикованным ARP-ответом, в котором сообщается, что IP адресу В соответствует MAC-адрес Х. Аналогично узлу В сообщается, что IP адресу А соответствует тот же MAC-адрес Х (рисунок 9.1). Для формирования сообщений можно использовать библиотеку libnet. Так как ARP — протокол без сохранения состояния, то узлы А и В примут ARP-ответы, даже если они не посылали запросов. Далее злоумышленник периодически (достаточно это делать раз в 20–40 секунд) повторяет посылку сфальсифицированных ARP-ответов для обновления сфабрикованных записей в ARP-таблицах узлов А и В, чтобы удерживать эти узлы в неведении относительно истинных адресов и не дать им сформировать соответствующие ARP-запросы.

4. Введенные в заблуждение узлы А и В пересылают свой трафик через узел Х, полагая, что сообщаются друг с другом непосредственно. Злоумышленник может просто прослушивать трафик или изменять передаваемые данные в своих интересах.

Узел В может быть шлюзом сети, в которой находится узел А. В этом случае злоумышленник может перехватывать весь трафик между узлом А и Интернетом.

Также злоумышленник может вообще не передавать кадры узла А узлу В, а выдавать себя за узел В, фабрикуя ответы от его имени и отсылая их в А.

Разделение сети на сегменты с помощью коммутаторов, очевидно, не является препятствием для описанной ARP-атаки.

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

Для обнаружения ARP-атак администратор должен вести базу данных соответствия MAC- и IP-адресов всех узлов сети и использовать программу arpwatch, которая прослушивает сеть и уведомляет администратора о замеченных нарушениях. Если сеть разделена на сегменты коммутаторами, то администратор должен настроить их таким образом, чтобы в сегмент, где находится станция администратора, перенаправлялись кадры из всех сегментов сети вне зависимости от того, кому они предназначены.

Использование статических ARP-таблиц, по крайней мере — на ключевых узлах (серверах, маршрутизаторах), защитит их от ARP-атаки, правда, за счет накладных расходов на поддержку этих таблиц в актуальном состоянии.

Пользователю на атакуемом хосте, не снабженном статической ARP-таблицей, крайне сложно заметить, что он подвергся ARP-атаке, поскольку представляется маловероятным, что пользователь помнит MAC-адреса других узлов своей сети и периодически проверяет ARP-таблицу своего компьютера. Возможно, что операционная система отслеживает изменения в ARP-таблице и вносит в лог-файл записи вида «arp info for 0x11223344 overwritten by 01:02:03:04:05:06», однако, в общем случае, для отслеживания ARP-атак следует полагаться на администратора сети и программу arpwatch.

3.1.2 Навязывание ложного маршрутизатора

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

Ложное сообщение ICMP Redirect

Как правило, навязывание ложного маршрутизатора выполняется с помощью фальсифицированных ICMP-сообщений Redirect, так как документ RFC-1122 требует, чтобы хосты обязательно обрабатывали такие сообщения. В подложном сообщении злоумышленник объявляет свой собственный адрес в качестве адреса маршрутизатора (рисунок 3.1).

Рисунок 3.1 - Навязывание ложного маршрутизатора с помощью ICMP Redirect

Напомним действия хоста А при получении сообщения Redirect. Хост А считает, что Redirect является реакцией на ранее отправленную датаграмму некому хосту В, причем заголовок и первые 64 бита этой датаграммы возвращаются внутри полученного сообщения. Из возвращенного заголовка хост А определяет, что он должен сделать перенаправление для датаграмм, направленных в В, и вносит в свою таблицу маршрутов частный маршрут к хосту В через маршрутизатор, указанный в сообщении Redirect. Следует обратить внимание, что все сообщения Redirect обрабатываются одинаково независимо от кода сообщения — таким образом, посылка Redirect с кодом 0 («перенаправление для сети получателя») не вызовет изменения маршрута в сеть, в которой находится получатель, а приведет к установке частного маршрута к хосту В, как и в случае сообщения с кодом 1.

Сообщение Redirect должно быть отправлено маршрутизатором, который в таблице маршрутов хоста А является следующим маршрутизатором на пути в В, при этом хост В не должен находиться в той же IP-сети, что и А, а новый объявленный маршрутизатор Х, наоборот, обязан находиться в одной IP-сети с хостом А.

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

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

Несмотря на такой «половинчатый» перехват, злоумышленник может просматривать и модифицировать данные, направляемые из А в В, а если он находится в одном сегменте с хостом А или маршрутизатором, то и наблюдать за ответами узла В, направляемыми в А. Более того, злоумышленник может вообще не пересылать датаграммы в узел В, а отвечать на них сам, фабрикуя датаграммы от имени узла В.

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

Для пользователя атакуемого узла не составит особого труда раскрыть замысел злоумышленника: полученное сообщение Redirect отобразится в виде неожиданно появившейся строки в таблице маршрутов, направляющей данные для хоста В через узел Х2. Кроме того, программа traceroute скорее всего покажет дополнительный промежуточный узел на пути к В. К сожалению пользователи обычно не заглядывают в таблицу маршрутов и не запускают traceroute, если поведение сетевых программ не вызывает у них подозрений, поэтому злоумышленник имеет хорошие шансы остаться незамеченным.

2Узел Х может и не быть узлом злоумышленника. Затратив определенные усилия на программирование, тот может создать узел-фантом, присвоив ему свободный IP-адрес Х и свободный MAC-адрес. Фабрикуя ARP-ответы от имени узла Х, злоумышленник обеспечит доставку кадров, предназначенных этому узлу, в свой сегмент Ethernet, откуда он может их получить, настроив свою сетевую карты на вымышленный MAC-адрес Х, или извлечь с помощью прослушивания. Использование такой схемы не может скрыть наличия Redirect-атаки, но весьма затрудняет обнаружение злоумышленника.