Атаки на службу Simple TCP/IP. Методы противодействия

Размещено на http://www.allbest.ru/

Курсовая работа

"Атаки на службу Simple TCP/IP. Методы противодействия"



Введение

Протоколы семейства IP являются основой построения сетей intranet и глобальной сети Internet. Несмотря на то, что разработка TCP/IP финансировалась Министерством обороны США, TCP/IP не обладает абсолютной защищенностью и допускает различные типы атак, рассмотренные в данной работе.

Для того, чтобы предпринять подобные атаки, злоумышленник должен обладать контролем над одной из систем, подключенной к Internet. Это возможно, например, в случае, когда он взломал какую-то систему или использует собственный компьютер, имеющий соединение с Internet (для многих атак достаточно иметь PPP-доступ).

сетевой атака команда протокол



1.Ознакомление с протаколом TCP/IP

Стек протоколов TCP/IP (англ.Transmission Control Protocol/Internet Protocol-- протокол управления передачей)-- набор сетевых протоколов разных уровней модели сетевого взаимодействия DOD, используемых в сетях. Протоколы работают друг с другом в стеке (англ.stack, стопка)-- это означает, что протокол, располагающийся на уровне выше, работает «поверх» нижнего, используя механизмы инкапсуляции. Например, протокол TCP работает поверх протокола IP.

Стек протоколов TCP/IP основан на модели сетевого взаимодействия DOD и включает в себя протоколы четырёх уровней:

с прикладного (application),

с транспортного (transport),

с сетевого (network),

с канального (data link).

Протоколы этих уровней полностью реализуют функциональные возможности модели OSI. На стеке протоколов TCP/IP построено всё взаимодействие пользователей в IP-сетях. Стек является независимым от физической среды передачи данных.

1.1 Основные службы TCP/IP

После прочтения этой главы и выполнения упражнений вы сможете:

понять, как работают протоколы и службы Прикладного уровня TCP/IP;

разобраться в возможностях, типах сообщений и структурах запроса/ответа множества основных служб TCP/IP, включая FTP, Telnet, SMTP и HTTP;

усвоить операции других основных служб TCP/IP, среди которых Echo,Quoteof the Day, Chargen, Whois,TFTP, Finger, RPC (Remote Procedure Call, удаленный вызов процедуры), службы NetBIOS over TCP/IP (также известные под именем NBT), а также SNMP;

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

1.2 Виды атак на сетевом уровне TCP/IP

Атаки на TCP/IP можно разделить на два вида: пассивные и активные.

Пассивные атаки на уровне TCP

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

Подслушивание

Атака заключаются в перехвате сетевого потока и его анализе (от англ. "sniffing").

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

Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях).

Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.

Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell) или использование одноразовых паролей (например, S/KEY).

Другой вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей.

У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров -- общеизвестный tcpdump.

Активные атаки на уровне TCP

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

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

Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.

Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.

Предсказание TCP sequence number

Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.

Описание

Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так:



Рис.

После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.

Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыток и с поправкой на скорость соединения) предсказать sequence number для следующего соединения.

Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.

Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.

Первая задача крэкера - ввести систему 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 крэкеру по электронной почте.

Представим это в виде схемы:



Рис.

Детектирование и защита

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

В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты?

Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).

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

Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы).

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

IP Hijacking

Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing'а.

Описание

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

Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.

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

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

Есть два способа рассинхронизировать соединение:

Ранняя десинхронизация

Соединение десинхронизируется на стадии его установки.

с Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.

с Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.

с Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет.

с Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.

с Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована.

Представим это в виде схемы:



Рис.

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

Десинхронизация нулевыми данными

В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.

ACK-буря

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии, вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.

К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает".

Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.

Детектирование и защита

Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения.

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

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

Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровне протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP.

Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сессии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.

Пассивное сканирование

Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру.

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

Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).

Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать:

с резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST);

с прием от клиента RST-пакета в ответ на SYN/ACK.

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

В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.

Затопление ICMP-пакетами

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

Данная атака требует от крэкера доступа к быстрым каналам в Интернет.

Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета.

При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию.

Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.

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

Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкой заполнение канала "жертвы".

Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP).

В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к ping.

Локальная буря

Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю высылается строка знакогенератора) и других (date etc).

В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности.

Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов.

Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов).

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

Затопление SYN-пакетами

Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие заняться этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.

Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течение заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED.

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

Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.

В различных системах работа с очередью реализована по-разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет, и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше.

После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD).

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

Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы.

Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его внутрь сети.



2. Методы защиты протакола TCP/IP

Защита в TCP/IP

В TCP/IP предусмотрены некоторые специальные средства защиты. Эти средства (команды TCP/IP и защищенные процессы TCP/IP) в сочетании с описанными выше средствами защиты операционной системы, обеспечивают защиту данных в TCP/IP.

Защита команд TCP/IP

Некоторые команды TCP/IP выполняются в защищенной среде. Это такие команды, как ftp, rexec и telnet. Команда ftp обеспечивает защиту при передаче файлов. Команда rexec обеспечивает защищенную среду выполнения команд на внешнем хосте. Команда telnet (TELNET) обеспечивает защиту при входе в систему внешнего хоста.

Эти команды обеспечивают защиту только во время выполнения. Они не настраивают защищенную среду для выполнения других команд. Для этого предназначена команда securetcpip. Эта команда обеспечивает защиту системы, отключая непроверенные демоны и приложения, и давая возможность защитить протокол IP.

Команды ftp, rexec, securetcpip и telnet поддерживают следующие формы защиты системы и данных:

ftp Команда ftp обеспечивает защиту при передаче файлов. После установления соединения ftp с внешним хостом появляется приглашение для ввода ИД пользователя. При этом в соответствующем поле указан ИД пользователя по умолчанию, то есть текущий ИД пользователя на локальном хосте. После ввода ИД появляется приглашение для ввода пароля.

Процесс автоматического входа в систему передает удаленному хосту идентификатор и пароль пользователя из его файла $HOME/.netrc. Для обеспечения защиты права доступа к файлу $HOME/.netrc должны быть равны 600 (чтение и запись разрешены только владельцу). В противном случае автоматический вход в систему завершится неудачно.

Примечание: Пароли в файле .netrc хранятся в незашифрованном виде, поэтому функция автоматического входа в систему недоступна при работе с командой ftp, если система не была предварительно настроена с помощью команды securetcpip. Для подключения этой функции удалите команду ftp из раздела tcpip: файла /etc/security/config.

При передаче файлов команда ftp использует два соединения TCP/IP: одно для управления протоколом FTP, а другое для передачи данных. Соединение протокола считается основным. Оно защищено, так как устанавливается между двумя защищенными портами связи. Вспомогательное соединение необходимо для фактической передачи данных. Локальный и удаленный хосты проверяют, что это соединение установлено с тем же хостом, что и основное соединение. Если основное и вспомогательные соединения установлены с разными хостами, то команда ftp отправляет сообщение об ошибке, говорящее о том, что идентификация завершилась неудачно, а затем завершает работу. Такая проверка вспомогательного соединения позволяет предотвратить ситуацию, когда третий хост перехватывает данные, предназначенные другому хосту.

securetcpip Команда securetcpip включает средства защиты TCP/IP. После выполнения этой команды запуск непроверенных команд в системе будет запрещен. Командой securetcpip запрещается доступ к следующим командам:

rlogin и rlogind

rcp, rsh и rshd

tftp и tftpd

trpt

Команда securetcpip используется для повышения уровня защиты системы. Если только вы не переустанавливали TCP/IP, то команду securetcpip повторно вызывать не требуется.

rexec Команда rexec обеспечивает защищенную среду выполнения команд на внешнем хосте. У пользователя запрашивается имя и пароль.

Если применяется автоматический вход в систему, то команда rexec ищет ИД пользователя и пароль для внешнего хоста в локальном файле $HOME/.netrc. Для обеспечения защиты права доступа к файлу $HOME/.netrc должны быть равны 600 (чтение и запись разрешены только владельцу). В противном случае автоматический вход в систему завершится неудачно.

Примечание: Пароли в файле .netrc хранятся в незашифрованном виде, поэтому функция автоматического входа в систему недоступна при выполнении команды rexec, если система работает в защищенном режиме. Для подключения этой функции удалите запись rexec из раздела tcpip: файла /etc/security/config.

telnet или tn Команда telnet (TELNET) обеспечивает защиту при входе в систему внешнего хоста. У пользователя запрашивается имя и пароль. При этом считается, что терминал пользователя непосредственно подключен к хосту, поэтому доступ к терминалу управляется с помощью бит прав доступа. У всех остальных пользователей и групп нет прав доступа на чтение данных с терминала, но если владелец разрешит запись, то они смогут выводить сообщения в окно терминала. Команда telnet с помощью ключа защиты (SAK) предоставляет доступ к защищенной оболочке в удаленной системе. Предназначенная для этого ключевая последовательность отличается от ключевой последовательности для вызова локального защищенного пути и ее можно определить в команде telnet.

Ограничение удаленного выполнения команд (/etc/hosts.equiv)

Пользователи хостов, перечисленных в файле /etc/hosts.equiv, могут выполнять некоторые команды в вашей системе без указания пароля.



Таблица

Задачи удаленного выполнения команд
Процедура	Команда быстрого доступа из SMIT	Команда или имя файла	Среда Web-администратора системы
Просмотреть список удаленных хостов, у которых есть права на выполнение команд	smit lshostsequiv	view /etc/hosts.equiv	Программное обеспечение --> Сеть --> TCPIP (IPv4 и IPv6) --> Настройка протокола TCPIP --> TCP/IP --> Настроить TCP/IP --> Вручную --> Файл hosts --> Содержимое файла /etc/hosts.
Добавить удаленный хост к списку хостов, у которых есть права на выполнение	smit mkhostsequiv	*edit /etc/hosts.equiv	Программное обеспечение --> Сеть --> TCPIP (IPv4 и IPv6) --> Настройка протокола TCPIP --> TCP/IP --> Настроить TCP/IP --> Вручную --> Файл hosts. В окне Добавить/изменить запись для хоста заполните следующие поля: IP-адрес, Имя хоста, Псевдонимы и Комментарий. Нажмите кнопку Добавить/изменить запись, затем кнопку OK.
Удалить хост из списка удаленных хостов, у которых есть права на выполнение	smit rmhostsequiv	*edit /etc/hosts.equiv	Программное обеспечение --> Сеть --> TCPIP (IPv4 и IPv6) --> Настройка протокола TCPIP --> TCP/IP --> Настроить TCP/IP --> Вручную --> Файл hosts. Выберите хост в поле Содержимое файла /etc/host. Щелкните на Удалить запись --> OK.

Ограничение доступа по протоколу FTP (/etc/ftpusers)

Пользователям, перечисленным в файле /etc/ftpusers, запрещен удаленный доступ через FTP. Предположим, что пользователь A вошел в удаленную систему, причем он знает пароль пользователя B в этой системе. Если в файле /etc/ftpusers есть запись о пользователе B, то A не сможет передать файлы по соединению FTP пользователю B или от него, даже зная его пароль.

Таблица

Задачи удаленных пользователей FTP
Процедура	Команда быстрого доступа из SMIT	Команда или имя файла	Среда Web-администратора системы
Просмотреть список пользователей, доступ к которым по FTP ограничен	smit lsftpusers	view /etc/ftpusers	Программное обеспечение --> Пользователи --> Все пользователи.
Добавить пользователя, доступ к которому по FTP ограничен	smit mkftpusers	*edit /etc/ftpusers	Программное обеспечение --> Пользователи --> Все пользователи --> Выбранное --> Добавить пользователя в группу. Выберите группу и нажмите OK.
Удалить пользователя, доступ к которому по FTP ограничен	smit rmftpusers	*edit /etc/ftpusers	Программное обеспечение --> Пользователи --> Все пользователи --> Выбранное --> Удалить.



Защищенные процессы

Защищенная программа или процесс - это сценарий оболочки, демон или программа, которые удовлетворяют определенным стандартам защиты. Стандарты защиты устанавливаются и поддерживаются Министерством обороны США, которое также сертифицирует некоторые защищенные программы.

Для разных программ могут быть установлены различные уровни защиты. Предусмотрены уровни защиты A1, B1, B2, B3, C1, C2 и D, где уровень A1 соответствует самому высокому уровню защиты. На каждом уровне защиты предъявляются определенные требования. Например, на уровне C2 применяются следующие стандарты:

целостность программы Означает, что процесс выполняет в точности то, что предполагается.

модульность Означает, что исходный код программы разбит на независимые модули.

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

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

В TCP/IP предусмотрено несколько защищенных и множество незащищенных демонов. Защищенные демоны были специально протестированы, что позволило гарантировать, что они удовлетворяют определенным стандартам защиты.

Ниже перечислены некоторые защищенные демоны:

ftpd

rexecd

telnetd

Ниже перечислены некоторые незащищенные демоны:

rshd

rlogind

tftpd

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

Сетевая защищенная компьютерная база (NTCB)

В сети предусмотрены как аппаратные, так и программные средства защиты. В данном разделе описаны компоненты Сетевой защищенной компьютерной базы, относящиеся к TCP/IP.

Аппаратные средства защиты сети обеспечиваются сетевыми адаптерами, которые применяются для соединений TCP/IP. Эти адаптеры должны получать только данные, предназначенные для локальной системы, и распространять путем оповещения те данные, которые должны быть получены всеми системами.

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

Таблица

Каталог /etc
Имя	Владелец	Группа	Режим	Права доступа
gated.conf	root	система	0664	rw-rw-r--
gateways	root	система	0664	rw-rw-r--
hosts	root	система	0664	rw-rw-r--
hosts.equiv	root	система	0664	rw-rw-r--
inetd.conf	root	система	0644	rw-r--r--
named.conf	root	система	0644	rw-r--r--
named.data	root	система	0664	rw-rw-r--
networks	root	система	0664	rw-rw-r--
protocols	root	система	0644	rw-r--r--
rc.tcpip	root	система	0774	rwxrwxr--
resolv.conf	root	система	0644	rw-rw-r--
services	root	система	0644	rw-r--r--
3270.keys	root	система	0664	rw-rw-r--
3270keys.rt	root	система	0664	rw-rw-r--

Таблица

Каталог /usr/bin
Имя	Владелец	Группа	Режим	Права доступа
host	root	система	4555	r-sr-xr-x
hostid	bin	bin	0555	r-xr-xr-x
hostname	bin	bin	0555	r-xr-xr-x
finger	root	система	0755	rwxr-xr-x
ftp	root	система	4555	r-sr-xr-x
netstat	root	bin	4555	r-sr-xr-x
rexec	root	bin	4555	r-sr-xr-x
ruptime	root	система	4555	r-sr-xr-x
rwho	root	система	4555	r-sr-xr-x
talk	bin	bin	0555	r-xr-xr-x
telnet	root	система	4555	r-sr-xr-x

Таблица

Каталог /usr/sbin
Имя	Владелец	Группа	Режим	Права доступа
arp	root	система	4555	r-sr-xr-x
fingerd	root	система	0554	r-xr-xr--
ftpd	root	система	4554	r-sr-xr--
gated	root	система	4554	r-sr-xr--
ifconfig	bin	bin	0555	r-xr-xr-x
inetd	root	система	4554	r-sr-xr--
named	root	система	4554	r-sr-x--
ping	root	система	4555	r-sr-xr-x
rexecd	root	система	4554	r-sr-xr--
route	root	система	4554	r-sr-xr--
routed	root	система	0554	r-xr-x---
rwhod	root	система	4554	r-sr-xr--
securetcpip	root	система	0554	r-xr-xr--
setclock	root	система	4555	r-sr-xr-x
syslogd	root	система	0554	r-xr-xr--
talkd	root	система	4554	r-sr-xr--
telnetd	root	система	4554	r-sr-xr--

Таблица

Каталог /usr/ucb
Имя	Владелец	Группа	Режим	Права доступа
tn	root	система	4555	r-sr-xr-x
Каталог /var/spool/rwho
Имя	Владелец	Группа	Режим	Права доступа
rwho (каталог)	root	система	0755	drwxr-xr-x



Заключение

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



Список литературы

1.TCP/IP. Для профессионалов. 3-е издание / Т. Паркер, К. Сиян -СПб.: Питер, 2004

2.Персональные компьютеры в сетях TCP/IP / Крейг Хант; перев. с

англ. - BHV-Киев, 1997.

3.Высокопроизводительные сети. Энциклопедия пользователя / Марк А.Спортак и др.; перев. с англ. - Киев, ДиаСофт, 1998

4.Сети ЭВМ: протоколы, стандарты, интерфейсы / Ю. Блэк; перев. с

англ. - М.: Мир, 1990.

Размещено на Allbest.ru