Диплом: Обеспечение информационной безопасности в сетях IP 
Если реализация TCP/IP использует специальный алгоритм для определения
порядкового номера, то он может быть выяснен с помощью посылки нескольких
десятков пакетов серверу и анализа его ответов.
Итак, предположим, что система A доверяет системе B, так, что пользователь
системы B может сделать "rlogin A"
[20] и оказаться на A, не вводя пароля. Предположим, что крэкер расположен
на системе C. Система A выступает в роли сервера, системы B и C - в роли
клиентов.
Первая задача крэкера - ввести систему B в состояние, когда она не сможет
отвечать на сетевые запросы. Это может быть сделано несколькими способами, в
простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких
минут, в течении которых она будет неработоспособна, должно хватить. Другой
вариант - использование описанными в следующих разделах методов.
После этого крэкер может попробовать притвориться системой B, для того, что
бы получить доступ к системе A (хотя бы кратковременный).
Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для
выяснения текущего состояния порядкового номера сервера.
Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже
адрес системы B.
Система A отвечает пакетом с порядковым номером, который направляется системе
B. Однако система B никогда не получит его (она выведена из строя), как,
впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой
порядковый номер был выслан системе B
Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с
предполагаемым S-ACK (заметим, что если системы располагаются в одном
сегменте, крэкеру для выяснения порядкового номера достаточно перехватить
пакет, посланный системой A). После этого, если крэкеру повезло и порядковый
номер сервера был угадан верно, соединение считается установленным.
Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже
содержать данные. Например, если атака была направлена на rsh, он может
содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по
электронной почте.
Представим это в виде схемы:
Рис. 6 IP-spoofing
Детектирование и защита
Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами,
пришедшие из внешнего мира. Программное обеспечение маршрутизатора может
предупредить об этом администратора. Однако не стоит обольщаться - атака
может быть и изнутри Вашей сети.
В случае использования более интеллектуальных средств контроля за сетью
администратор может отслеживать (в автоматическом режиме) пакеты от систем,
которые находятся в недоступном состоянии. Впрочем, что мешает крэкеру
имитировать работу системы B ответом на ICMP-пакеты?
Какие способы существуют для защиты от IP-spoofing? Во-первых, можно
усложнить или сделать невозможным угадывание порядкового номера (ключевой
элемент атаки). Например, можно увеличить скорость изменения порядкового
номера на сервере или выбирать коэффициент увеличения порядкового номера
случайно (желательно, используя для генерации случайных чисел
криптографически стойкий алгоритм).
Если сеть использует межсетевой экран firewall (или другой фильтр IP-
пакетов), следует добавить ему правила, по которым все пакеты, пришедшие
извне и имеющие обратными адресами из нашего адресного пространства, не
должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие
машин друг другу. В идеале не должны существовать способа, напрямую попасть
на соседнюю машину сети, получив права суперпользователя на одной из них.
Конечно, это не спасет от использования сервисов, не требующих авторизации,
например, IRC – чат (крэкер может притвориться произвольной машиной Internet
и передать набор команд для входа на канал IRC, выдачи произвольных сообщений
и т.д.).
Шифрование TCP/IP-потока решает в общем случае проблему IP-спуфинга (при
условии, что используются криптографически стойкие алгоритмы).
Для того, чтобы уменьший число таких атак, рекомендуется также настроить
firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих
адреса, не принадлежащие нашему адресному пространству. Это защитит мир от
атак из внутренней сети, кроме того, детектирование подобных пакетов будет
означать нарушение внутренней безопасности и может помочь администратору в
работе.
6.2.2 IP Hijacking – Нападение на IP
Если в предыдущем случае крэкер инициировал новое соединение, то в данном
случае он перехватывает весь сетевой поток, модифицируя его и фильтруя
произвольным образом. Метод является комбинацией 'подслушивания' и IP-
спуфинга.
Описание
Необходимые условия - крэкер должен иметь доступ к машине, находящейся на
пути сетевого потока и обладать достаточными правами на ней для генерации и
перехвата IP-пакетов.
Напомним, что при передаче данных постоянно используются порядковый номер и
номер подтверждения (оба поля находятся в IP-заголовке). Исходя из их
значения, сервер и клиент проверяют корректность передачи пакетов.
Существует возможность ввести соединение в "десинхронизированное состояние",
когда присылаемые сервером порядковый номер и номер подтверждения не будут
совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер,
"прослушивая" линию, может взять на себя функции посредника, генерируя
корректные пакеты для клиента и сервера и перехватывая их ответы.
Метод позволяет полностью обойти такие системы защиты, как, например,
одноразовые пароли, поскольку крэкер начинает работу уже после того, как
произойдет авторизация пользователя.
Есть два способа рассинхронизировать соединение
§ Ранняя десинхронизация
Соединение десинхронизируется на стадии его установки.
Крэкер прослушивает сегмент сети, по которому будут проходить пакеты
интересующей его сессии
Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST
(сброс), конечно, с корректным порядковым номером, и, немедленно, вслед за
ним фальшивый C-SYN-пакет от имени клиента
Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с
новым порядковым номером, после чего посылает клиенту новый S-SYN-пакет.
Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает
серверу S-ACK-пакет от имени клиента.
Итак, клиент и сервер находятся в установленом состоянии ESTABLISHED
(установлено), однако сессия десинхронизирована.
Представим это в виде схемы:
Рис.7. Ранняя десинхронизация
Естественно, 100% срабатывания у этой схемы нет, например, она не
застрахована от того, что по дороге не потеряются какие-то пакеты, посланные
крэкером. Для корректной обработки этих ситуаций программа должна быть
усложнена.
§ Десинхронизация нулевыми данными
В данном случае крэкер прослушивает сессию и в какой-то момент посылает
серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут
проигнорированы на уровне прикладной программы и не видны клиенту.
Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия
переходит в десинхронизированное состояние.
ACK-буря
Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в
момент, когда сессия находится в десинхронизированном состоянии вызывает так
называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он
является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот
неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до
бесконечности.
К счастью (или к сожалению?) современные сети строятся по технологиям, когда
допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных,
повторных передачи не происходит и "буря стихает".
Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя -
на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа
SLIP[21] - ненамного больше.
Детектирование и защита
Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут
контролировать переход в десинхронизированное состояние, обмениваясь
информацией о порядковом номере/номере подтверждения. Однако в данному случае
мы не застрахованы от крэкера, меняющего и эти значения.
Поэтому более надежным способом является анализ загруженности сети,
отслеживание возникающих ACK-бурь. Это можно реализовать при помощи
конкретных средств контроля за сетью.
Если крэкер не потрудиться поддерживать десинхронизированное соединение до
его закрытия или не станет фильтровать вывод своих команд, это также будет
сразу замечено пользователем. К сожалению, подавляющее большинство просто
откруют новую сессию, не обращаясь к администратору.
Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование
TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола -
IPsec). Это исключает возможность модификации сетевого потока. Для защиты
почтовых сообщений может применяться PGP.
Следует заметить, что метод также не срабатывает на некоторых конкретных
реализациях TCP/IP. Так, некоторые системы генерируют встречный RST-пакет.
Это делает невозможным раннюю десинхронизацию.
6.2.3 Пассивное сканирование
Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких
TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-
сканер последовательно открывает соединения с различными портами. В случае,
когда соединение устанавливается, программа сбрасывает его, сообщая номер
порта крэкеру.
Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно
прерваным после установки соединением, или с помощью использования
специальных программ. Лучшие из таких программ обладают некоторыми попытками
внести элементы искуственного элемента в отслеживание попыток соединения с
различными портами.
Однако крэкер может воспользоваться другим методом - пассивным сканированием
(английский термин "passive scan"). При его использовании крэкер посылает
TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму).
Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет,
как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты.
Проанализировав данные ответ, крэкер может быстро понять, на каких портах
работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-
пакетами (cброс), показывая, что процесс установки соединения продолжен не
будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация
крэкера, если он не предпримет специальных мер).
Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-
соединение не устанавливается. Однако (в зависимости от поведения крэкера)
можно отслеживать
§ резко возросшее количество сессий, находящихся в состоянии
SYN_RECEIVED. (SIN пакет принят) при условии, что крэкер не посылает в ответ
RST)
§ прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении крэкера (например, сканирование с
низкой скоростью или проверка лишь конкретных портов) детектировать пассивное
сканирование невозможно, поскольку оно ничем не отличается от обычных попыток
установить соединение.
В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы,
доступ к которым не требуется извне.
6.2.4 Затопление ICMP-пакетами
Традиционный англоязычный термин - "ping flood". Появился он потому, что
программа "ping", предназначенная для оценки качества линии, имеет ключ для
"агрессивного" тестирования. В этом режиме запросы посылаются с максимально
возможной скоростью и программа позволяет оценить, как работает сеть при
максимальной нагрузке. Данная атака требует от крэкера доступа к быстрым
каналам в Интернет.
Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST
(запрос отклика ICMP), выставляя в нем время и его идентификатор. Ядро
машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY (ответ
на отклик ICMP) . Получив его ping выдает скорость прохождения пакета.
При стандартном режиме работы пакеты выслаются через некоторые промежутки
времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP
echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее
способности передавать полезную информацию.
Естественно, случай с ping является частным случаем более общей ситуации,
связанный с перегрузкой каналов. Например, крэкер может посылать множество
UDP-пакетов[22] на 19-й порт
машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м
UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.
Заметим, что крэкер может также подделывать обратный адрес подобных пакетов,
затрудняя его обнаружение. Отследить его поможет разве что скоординированная
работа специалистов на промежуточных маршрутизаторах, что практически
нереально.
Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным
адресом, указывающем на жертву, на широковещательные-адреса крупных сетей. В
результате каждая из машин ответит на этот фальшивый запрос, и машина-
отправитель получит больше количество ответов. Посылка множество echo
requests от имени "жертвы" на широковещательные-адреса крупных сетей, можно
вызвать резкой заполненение канала "жертвы".
Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение
количество специфических пакетов (таких, как ICMP).
В качестве защиты можно порекомендовать настройку маршрутизаторов, при
которых они будут фильтровать тот же ICMP трафик, превышающие некоторую
заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться,
что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к
ping.
Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим
"локальные бури" на пример UDP-бури. Как правило, по умолчанию системы
поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет
отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет
отправителю выслается строка знакогенератора) и других.
В данном случае крэкер может послать единственный UDP-пакет, где в качестве
исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве
адреса получателя и отправителя будут указаны, к примеру, две машины вашей
сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая
попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так
до бесконечности.
Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную
нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как
недавно стало известно, данная атака временно выводит из строя (до
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
|
