| На сайте 100500 рефератов в 150 категориях | |
 Рефераты на 5 с плюсомС нашим сайтом написать реферат проще простого |
|
 |
|
|
||
Исследование протоколов TCP / IP
Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант - использование описанными в следующих разделах методов. После этого крэкер может попробовать притвориться системой B, для того что бы получить доступ к системе A (хотя бы кратковременный). Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера. Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B. Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла. Rhosts или отправки / etc / passwd крэкеру по электронной почте. Представим это в виде схемы 1: Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие пакеты, посланные крэкер. Для корректной обработки этих ситуаций программа должна быть усложнена. 2.5.Десинхронизация нулевыми данными В данном случае крэкер прослушивает сессию и в какой момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP ...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние. ACK-бурая Одна из проблем IP Hиjackиng заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на это неприемлимые уже для сервера пакет клиент снова получает ответ ... И так до бесконечности. К счастью (или к сожалению?) Современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторные передачи не происходит и "буря стихает". Как показали опыты, чем сильнее ACK-бурая, тем быстрее она "усмиряет" себя-на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLI - ненамного больше. 2.6.Детектирование и защита Есть несколько путей. Например, можно реализовать TCP / IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обменивая информацией о sequence number / acknowledge number. Однако в данном случае мы не застрахованы от крэкера, изменяющий и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать с помощью конкретных средств контроля за сетью. Если крэкер не потрудиться поддерживать десинхронизированное соединения до его или закрытии не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство простая откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP / IP-трафика (на уровне приложений - secure shell) или на уровне протокола - IPSec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Стоит заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP / IP. Так, несмотря на [rfc ...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию. Для более глубокого ознакомления с этой атакой рекомендуется обратиться к IP Hиjackиng (CERT). 2.7. Пассивное сканирование Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру. Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ имеют некоторые попытки внести элементы искуственного элемента в отслеживание попыток соединения с различными портами. Однако крэкер может воспользоваться другим методом-и пассивным сканированием (английский термин "passиve scan"). При его использовании крэкер посылает TCP / IP SYN-пакет на все порты подряд (или по какому заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN / ACK-пакет, как приглашение продолжить 3-way handshake. Другие вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN / ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP / IP-реализация крэкера, если он не начнет специальных мер) . Метод не детектируется предыдущими способами, поскольку реальное TCP / IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать резко возросло количество сессий, находящихся в состоянии SYN_RECEИVED (при условии, что крэкер не посылает в ответ RST) прием от клиента RST-пакета в ответ на SYN / ACK. К сожалению, при достаточно разумном поведении крэкера (например, сканирование с низкой или скоростью проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение. Как защиту можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не нужно извне. Вывод. Другие вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN / ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP / IP-реализация крэкера, если он не начнет специальных мер) . Метод не детектируется предыдущими способами, поскольку реальное TCP / IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать резко возросло количество сессий, находящихся в состоянии SYN_RECEИVED (при условии, что крэкер не посылает в ответ RST) прием от клиента RST-пакета в ответ на SYN / ACK. К сожалению, при достаточно разумном поведении крэкера (например, сканирование с низкой или скоростью проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение. Как защиту можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не нужно извне. Вывод. Читайте также: |
||||
|
|
|
версия для печати| Бесплатные рефераты, скачать бесплатно |
|