39976

Сравнение средств разграничения доступа к файлам в Unix и Windows

Контрольная

Информатика, кибернетика и программирование

Они включают в себя начальную интерактивную процедуру отображающую начальный диалог с пользователем на экране и удаленные процедуры входа которые позволяют удаленным пользователям получить доступ с рабочей станции сети к серверным процессам Windows. Угрозы безопасности в сети Интернет: анализ сетевого трафика и шторм ложных TCPзапросов 4. Анализ сетевого трафика сети Internet В сети Internet основными базовыми протоколами удаленного доступа являются TELNET и FTP File Trnsfer Protocol. Особенностью протоколов FTP и TELNET является то что...

Русский

2013-10-13

194.26 KB

9 чел.

4. Сравнение средств разграничения доступа к файлам в Unix и Windows

Права доступа в Unix

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

В ОС Unix считается, что информация, нуждающаяся в защите, находится главным образом в файлах.

По отношению к конкретному файлу все пользователи делятся на три категории:

  1. владелец файла;
  2. члены группы владельца;
  3. прочие пользователи.

Для каждой из этих категорий режим доступа определяет права на операции с файлом, а именно:

  1. право на чтение;
  2. право на запись;
  3. право на выполнение (для каталогов - право на поиск).

Право

Доступ к файлам

Доступ к каталогам

Чтение

R

Можно просматривать содержимое файлов, копировать файлы

Можно просматривать список файлов в каталоге (ls)

Запись

W

Можно менять содержимое файлов

При наличии прав WX можно добавлять и удалять файлы

Выполнение

X

Можно запускать файлы на исполнение

Можно «переходить» в данный каталог (cd)

Права в команде chmod могут быть записаны в двух форматах: в числовом и в символьном. Для понимания сути задания прав в Unix системах, нужно знать представление чисел в восьмеричной и двоичной системах счисления.

Права доступа в Windows

Права на чтение и выполнение – аналогично Unix.

Право на запись поделено на три самостоятельных:

  1. Запись данных / Создание файлов
  2. Дозапись данных / Создание каталогов
  3. Удаление

Дополнительные права:

  1. Смена владельца
  2. Чтение / изменение прав доступа
  3. Чтение / запись атрибутов и дополнительных атрибутов

Система защиты ОС Windows состоит из следующих компонентов:

Процедуры регистрации (Logon Processes), которые обрабатывают запросы пользователей на вход в систему. Они включают в себя начальную интерактивную процедуру, отображающую начальный диалог с пользователем на экране и удаленные процедуры входа, которые позволяют удаленным пользователям получить доступ с рабочей станции сети к серверным процессам Windows.

Подсистемы локальной авторизации (Local Security Authority, LSA), которая гарантирует, что пользователь имеет разрешение на доступ в систему. Этот компонент - центральный для системы защиты Windows. Он порождает маркеры доступа, управляет локальной политикой безопасности и предоставляет интерактивным пользователям аутентификационные услуги. LSA также контролирует политику аудита и ведет журнал, в котором сохраняются сообщения, порождаемые диспетчером доступа.

Менеджера учета (Security Account Manager, SAM), который управляет базой данных учета пользователей. Эта база данных содержит информацию обо всех пользователях и группах пользователей. SAM предоставляет услуги по легализации пользователей, применяющиеся в LSA.

Диспетчера доступа (Security Reference Monitor, SRM), который проверяет, имеет ли пользователь право на доступ к объекту и на выполнение тех действий, которые он пытается совершить. Этот компонент обеспечивает легализацию доступа и политику аудита, определяемые LSA. Он предоставляет услуги для программ супервизорного и пользовательского режимов, для того чтобы гарантировать, что пользователи и процессы, осуществляющие попытки доступа к объекту, имеют необходимые права. Данный компонент также порождает сообщения службы аудита, когда это необходимо.

Для сравнения прав доступа к файлам используются файловые системы UFS в ОС Solaris и NTFS в ОС Windows.

В Windows все права суммируются, запретительные права имеют приоритет над разрешительными.

В Unix какое из прав доступа будет задействовано определяется в зависимости от текущего идентификатора процесса по следующему алгоритму


7. Угрозы безопасности в сети Интернет: анализ сетевого трафика и "шторм" ложных TCP-запросов

4.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, напротив, пересылает пароль целиком в одном пакете.

У внимательного читателя, наверное, уже возник вопрос, почему разработчики базовых прикладных протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей. Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются в открытом виде по сети (правда, этой ОС это особенно не помогает - [9]). Видимо, проблема в том, что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно - в период с конца 60-х до начала 80-х и c тех пор абсолютно не изменились. При этом точка зрения на построение глобальных сетей стала иной. Инфраструктура сети Internet и ее протоколы разрабатывались в основном из соображений надежности связи и уж никак не из соображений безопасности. Мы - пользователи сети Internet - сейчас пожинаем плоды, оставленные нам разработчиками этой морально устаревшей с точки зрения безопасности глобальной сети. Совершенно очевидно, что вычислительные системы за эти годы сделали колоссальный скачок в своем развитии. Поэтому, конечно, за эти годы подход к обеспечению информационной безопасности распределенных ВС существенно изменился. Были разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик (например, протоколы SSL, SKIP и т. п.). Однако эти протоколы не сменили устаревшие и не стали стандартом для каждого пользователя (может быть, за исключением SSL). Вся проблема состоит в том, что для того, чтобы они стали стандартом, на эти протоколы должны перейти все пользователи сети, но, так как в Internet отсутствует централизованное управление сетью, то процесс перехода на эти протоколы может длиться еще многие годы. А на сегодняшний день подавляющее большинство пользователей используют стандартные протоколы семейства TCP/IP, разработанные более 15 лет назад. В результате, как показывают сообщения амеpиканских центpов по компьютеpной безопасности (CERT, CIAC), анализ сетевого трафика в сети Internet успешно пpименялся кракерами в последние годы, и, согласно матеpиалам специального комитета пpи конгpессе США, с его помощью в 1993-1994 годах было пеpе-хвачено около миллиона паpолей для доступа в различные информационные системы.

Рис. 4.1. Анализ сетевого трафика.

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

4.6. Нарушение работоспособности хоста в сети Internet при использовании направленного "шторма" ложных TCP-запросов на создание соединения, либо при переполнении очереди запросов

Из рассмотренной в предыдущем пункте схемы создания TCP-соединения следует, что на каждый полученный TCP-запрос на создание соединения операционная система должна сгенерировать начальное значение идентификатора ISN и отослать его в ответ на запросивший хост. При этом, так как в сети Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом отправителя сообщения, то невозможно отследить истинный маршрут, пройденный IP-пакетом, и, следовательно, у конечных абонентов сети нет возможности ограничить число возможных запросов, принимаемых в единицу времени от одного хоста. Поэтому возможно осуществление типовой УА "Отказ в обслуживании" (п. 3.2.4), которая будет заключаться в передаче на атакуемый хост как можно большего числа ложных TCP-запросов на создание соединения от имени любого хоста в сети (рис. 4.11). При этом атакуемая сетевая ОС в зависимости от вычислительной мощности компьютера либо - в худшем случае - практически зависает, либо - в лучшем случае - перестает реагировать на легальные запросы на подключение (отказ в обслуживании). Это происходит из-за того, что для всей массы полученных ложных запросов система должна, во-первых, сохранить в памяти полученную в каждом запросе информацию и, во-вторых, выработать и отослать ответ на каждый запрос. Таким образом, все ресурсы системы "съедаются" ложными запросами: переполняется очередь запросов и система занимается только их обработкой. Эффективность данной удаленной атаки тем выше, чем больше пропускная способность канала между атакующим и целью атаки, и тем меньше, чем больше вычислительная мощь атакуемого компьютера (число и быстродействие процессоров, объем ОЗУ и т. д.).

Рис. 4.1.1 Нарушение работоспособности хоста в Internet, использующее направленный шторм ложных TCP-запросов на создание соединения.

С нашей точки зрения, очевидность данной удаленной атаки была ясна еще лет двадцать назад, когда появилось семейство протоколов TCP/IP. Корни этой атаки находятся в самой инфраструктуре сети Internet, в ее базовых протоколах - IP и TCP. Но каково же было наше удивление, когда мыувидели на информационном WWW-сервере CERT (Computer Emergency Respone Team) первое упоминание об этой удаленной атаке, датированное только 19 сентября 1996 года! Там эта атака носила название "TCP SYN Flooding and IP Spoofing Attacks" - "навод-нение" TCP-запросами с ложных IP-адресов.

Другая разновидность атаки "Отказ в обслуживании" состоит в передаче на атакуемый хост нескольких десятков (сотен) запросов на подключение к серверу, что может привести к временному (до 10 минут) переполнению очереди запросов на сервере (см. атаку К. Митника из п. 4.5.2 и пример с ОС Linux 1.2.8 в конце данного пункта). Это происходит из-за того, что некоторые сетевые ОС устроены так, чтобы обрабатывать только первые несколько запросов на подключение, а остальные - игнорировать. То есть при получении N запросов на подключение, ОС сервера ставит их в очередь и генерирует соответственно N ответов. Далее, в течение определенного промежутка времени, (тайм-аут ? 10 минут) сервер будет дожидаться от предполагаемого клиента сообщения, завершающего handshake и подтверждающего создание виртуального канала с сервером. Если атакующий пришлет на сервер количество запросов на подключение, равное максимальному числу одновременно обрабатываемых запросов на сервере, то в течение тайм-аута остальные запросы на подключение будут игнорироваться и к серверу будет невозможно подключиться.

Эксперименты с данной удаленной атакой, проводимые на различных сетевых ОС в экспериментальных 10-мегабитных сегментах сети, выявили следующие интересные результаты, с которыми авторы считали бы необходимым вас ознакомить. В случае передачи по каналу связи максимально возможного числа TCP-запросов на создание соединения и нахождении атакующего в одном сегменте с целью атаки атакуемые системы вели себя следующим образом: ОС Windows '95, установленная на 486DX2-66 с 8 Мб ОЗУ, "замирала" и переставала реагировать на всяческие внешние воздействия (нажатия на клавиатуру, например); ОС Linux 2.0.0 на 486DX4-133 c 8 Мб ОЗУ тоже практически прекращала всякую работу и обрабатывала одно нажатие на клавиатуре примерно 30 секунд. Мало того, что к этим атакованным хостам было, естественно, невозможно получить удаленный доступ, но и локальный доступ был невозможен! Наилучший результат в процессе этого теста показал двухпроцессорный файрвол: удаленное подключение к нему было также невозможно, но осуществляемая атака на локальных пользователях никак не сказывалась (все-таки два процессора).

Не менее интересным было поведение атакуемых систем после снятия воздействия. ОС Windows '95 практически сразу же после прекращения воздействия начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ, по-видимому, переполнился буфер, и более получаса система не функционировала ни для удаленных, ни для локальных пользователей, а занималась передачей ответов на полученные ранее запросы. Двухпроцессорный файрвол сразу же после снятия воздействия стал доступен для удаленного доступа.

При нахождении с атакуемыми системами в соседних смежных сегментах выяснилось следующее: OC Windows '95 на Pentium100 с 16 Мб ОЗУ обрабатывала каждое нажатие на клавиатуре примерно секунду, ОС Linux 2.0.0 на Pentium100 с 16 Мб ОЗУ практически "повисла" - одно нажатие за 30 секунд, зато после снятия воздействия у локального пользователя немедленно появилась возможность нормальной работы.

Не нужно обманываться результатами этого теста и считать, что Windows '95 показала себя с лучшей стороны. Это связано только лишь с тем, что передаваемые TCP-запросы направлялись на FTP-порт, то есть это был запрос на подключение к FTP-серверу, а так как Windows '95 - принципиально клиентская операционная система и FTP-сервера под нее нет, то, следовательно, сохранять в памяти параметры запроса и дожидаться окончания handshake ей просто не было необходимости.

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

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

Приемлемых способов защиты от подобных атак в сети стандарта IPv4 нет, так как невозможен контроль за маршрутом сообщений. Для повышения надёжности работы системы можно использовать по возможности более мощные компьютеры, способные выдержать направленный шторм ложных запросов на создание соединения.


8. Угрозы безопасности в сети Интернет: ложный DNS-сервер и ложный маршрут с ICMP

4.3. Ложный DNS-сервер в сети Internet

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

В самом начале зарождения Internet для удобства пользователей было принято решение присвоить всем компьютерам в сети имена. Использование имен позволяет пользователю лучше ориентироваться в киберпространстве сети Internet - куда проще, понятней и наглядней для пользователя запомнить, например, имя www.ferrari.it, чем четырехразрядную цепочку IP-адреса. Использование в Internet мнемонически понятных для пользователей имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. На этапе раннего развития Internet, когда в сеть было объединено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и соответствующие им IP-адреса всех хостов в сети. Данный файл регулярно обновлялся и распространялся по всей сети. Но, по мере развития Internet, число объединенных в сеть хостов увеличивалось, и данная схема становилась все менее и менее работоспособной, поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название доменной системы имен - DNS (Domain Name System).

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

Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet:

  1.  хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти;
  2.  DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней указанного в запросе имени. В случае, если имя найдено, а, следовательно, найден и соответствующий ему IP-адрес, то на запросивший хост DNS-сервер отправляет DNS-ответ, в котором указывает искомый IP-адрес. В случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера root.cache, и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено).

Три возможных варианта удаленной атаки на эту службу.

4.3.1. Внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса

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

Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP) что, естественно, делает ее менее защищенной, так как протокол UDP в отличие от TCP вообще не предусматривает средств идентификации сообщений. Кроме того, этот переход несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения, и, кроме того, конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP. И только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP.

Во-вторых, следующая тонкость, на которую требуется обратить внимание, состоит в том, что значение поля "порт отправителя" в UDP-пакете вначале принимает значение >= 1023 и увеличивается с каждым переданным DNS-запросом.

В-третьих, значение идентификатора (ID) DNS-запроса зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос.

Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме "Ложный объект РВС".

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

4.3.2. Внедрение в сеть Internet ложного сервера путем создания направленного "шторма" ложных DNS-ответов на атакуемый хост

В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к полученному от DNS-сервера ответу, является, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера; во-вторых, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (в данном случае это первая проблема для атакующего), и, в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (а это вторая проблема).

4.3.3. Внедрение в сеть Internet ложного сервера путем перехвата DNS-запроса или создания направленного "шторма" ложных DNS-ответов на атакуемый DNS-сервер

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

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

Из анализа только что подробно описанной схемы удаленного DNS-поиска становится очевидно, что в том случае, если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС" ! И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней, а, следовательно, все больше хостов в Internet будут дезинформированы и атакованы!

В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из предыдущих пунктов, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой и так отнюдь не безопасной глобальной сети. Напомню, что, как указывал S. M. Bellovin в ставшей почти классической работе [14]: "A combined attack on the domain system and the routing mechanisms can be catastrophic"("Комбинация атаки на доменную систему и механизмы маршрутизации может привести к катастрофе" ).

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

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

4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора

Маршрутизация в сети Internet играет важнейшую роль для обеспечения нормального функционирования сети. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к глобальной сети Internet как минимум через один маршрутизатор, а, следовательно, все хосты в этом сегменте и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все сообщения, адресованные в другие сегменты сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети Internet для выбора оптимального маршрута используются специальные протоколы маршрутизации: RIP, OSPF и т. д.

Рассмотрим, что представляет из себя таблица маршрутизации хоста. В каждой строке этой таблицы содержится описание соответствующего маршрута. Это описание включает: IP-адрес конечной точки маршрута (Destination), IP-адрес соответствующего маршрутизатора (Gateway), а также ряд других параметров, характеризующих этот маршрут. Обычно в системе существует так называемый маршрут по умолчанию (поле Destination содержит значение 0.0.0.0, то есть default, а поле Gateway - IP-адрес маршрутизатора). Этот маршрут означает, что все пакеты, адресуемые на IP-адрес вне пределов данной подсети, будут направляться по указанному default-маршруту, то есть на маршрутизатор (это реализуется установкой в поле адреса назначения в Ethernet-пакете аппаратного адреса маршрутизатора).

Как говорилось ранее, в сети Internet существует управляющий протокол ICMP, одной из функций которого является удаленное управление маршрутизацией на хостах внутри сегмента сети. Удаленное управление маршрутизацией необходимо для предотвращения возможной передачи сообщений по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP-сообщения: Redirect Message. Исследование протокола ICMP показало, что сообщение Redirect бывает двух типов. Первый тип сообщения носит название Redirect Net и уведомляет хост о необходимости смены адреса маршрутизатора, то есть default-маршрута. Второй тип - Redirect Host - информирует хост о необходимости создания нового маршрута к указанной в сообщении системе и внесения ее в таблицу маршрутизации. Для этого в сообщении указывается IP-адрес хоста, для которого необходима смена маршрута (адрес будет занесен в поле Destination), и новый IP-адрес маршрутизатора, на который необходимо направлять пакеты, адресованные данному хосту (этот адрес заносится в поле Gateway). Необходимо обратить внимание на важное ограничение, накладываемое на IP-адрес нового маршрутизатора: он должен быть в пределах адресов данной подсети!

Анализ исходных текстов ОС Linux 1.2.8 показал, что ICMP-сообщение Redirect Net игнорируется данной ОС (это представляется логичным, так как динамическая смена маршрутизатора в процессе работы системы вряд ли необходима. Видимо, можно сделать вывод, что это сообщение игнорируют и другие сетевые ОС). Что касается управляющего сообщения ICMP Redirect Host, то единственным идентифицирующим его параметром является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений. Таким образом, ICMP-сообщения передаются на хост маршрутизатором однонаправлено, без создания виртуального соединения. Следовательно, ничто не мешает атакующему послать ложное ICMP-сообщение о смене маршрута от имени маршрутизатора.

Приведенные выше факты позволяют осуществить типовую удаленную атаку "Внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута" , рассмотренную в п. 3.2.3.1.

Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP Redirect Host сообщение, в котором указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Далее это сообщение передается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. В принципе, можно предложить два варианта данной удаленной атаки.

В первом случае атакующий находится в том же сегменте сети, что и цель атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать либо свой IP-адрес, либо любой из адресов данной подсети. Это даст атакующему возможность изменить маршрут передачи сообщений, направляемых атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между атакуемым хостом и интересующим атакующего сервером. После этого атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от "обманутого" хоста. Рассмотрим функциональную схему осуществления этой удаленной атаки (рис 4.7):

  1.  передача на атакуемый хост ложного ICMP Redirect Host сообщения;
  2.  отправление ARP-ответа в случае, если пришел ARP-запpос от атакуемого хоста;
  3.  перенаправление пакетов от атакуемого хоста на настоящий маршрутизатор;
  4.  перенаправление пакетов от маршрутизатора на атакуемый хост;
  5.  при приеме пакета возможно воздействие на информацию по схеме "Ложный объект РВС"(п. 3.2.3.3).

В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки. Тогда, в случае передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий уже не сможет получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста (см. описанную выше в этом пункте реакцию сетевой ОС на ICMP Redirect сообщение), поэтому использование данного варианта этой удаленной атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако, в этом случае атака достигает другой цели: нарушается работоспособность хоста. Атакующий с любого хоста в Internet может послать подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном хосте не проигнорирует данное сообщение, то связь между данным хостом и указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Схема этой атаки приведена на рис. 4.8.

Эксперимент показал, что оба варианта рассмотренной удаленной атаки удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux 1.2.8, ОС Windows '95 и ОС Windows NT 4.0. Остальные сетевые ОС, исследованные нами (Linux 2.0.0 и защищенный по классу B1 UNIX), игнорировали данное ICMP Redirect сообщение (что, не правда ли, кажется вполне логичным с точки зрения обеспечения безопасности!).

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

9. Угрозы безопасности в сети Интернет: ложный ARP-сервер и подмена субъекта TCP-соединения

4.2. Ложный ARP-сервер в сети Internet

Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В общем случае передаваемый по сети пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из заголовка пакета и поля данных. В заголовок пакета обычно заносится служебная информация, определяемая используемым протоколом обмена и необходимая для адресации пакета, его идентификации, преобразования и т. д. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спрое-цировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень). Следующая схема наглядно иллюстрирует как выглядит, например, TCP-пакет в сети Internet:

Ethernet-заголовок

IP-заголовок

TCP-заголовок

Данные

Рис.4.2. Структура TCP-пакета

Рассмотрим схему адресации пакетов в сети Internet и возникающие при этом проблемы безопасности. Как известно, базовым сетевым протоколом обмена в сети Internet является протокол IP (Internet Protocol). Протокол IP - это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку глобальной сети. Для адресации на сетевом уровне (IP-уровне) в сети Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на хост необходимо указать в IP-заголовке пакета в поле Destination Address IP-адрес данного хоста. Однако, как видно из рис. 4.2, IP-пакет находится внутри аппаратного пакета (в случае среды передачи Ethernet IP пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми протоколами обмена в конечном счете адресуется на аппаратный адрес сетевого адаптера, непосредственно осуществляющего прием и передачу пакетов в сеть (в дальнейшем мы будем рассматривать только Ethernet-сети).

Из всего вышесказанного видно, что для адресации IP-пакетов в сети Internet кроме IP-адреса хоста необходим еще либо Ethernet-адрес его сетевого адаптера (в случае адресации внутри одной подсети), либо Ethernet-адрес маршрутизатора (в случае межсетевой адресации). Первоначально хост может не иметь информации о Ethernet-адресах других хостов, находящихся с ним в одном сегменте, в том числе и о Ethernet-адресе маршрутизатора. Следовательно, перед хостом встает стандартная проблема, решаемая с помощью алгоритма удаленного поиска. В сети Internet для решения этой проблемы используется протокол ARP (Address Resolution Protocol). Протокол ARP позволяет получить взаимно однозначное соответствие IP- и Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это достигается следующим образом: при первом обращении к сетевым ресурсам хост отправляет широковещательный ARP-запрос на Ethernet-адрес FFFFFFFFFFFFh, в котором указывает IP-адрес маршрутизатора и просит сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным параметром, который всегда устанавливается вручную при настройке любой сетевой ОС в сети Internet). Этот широковещательный запрос получат все станции в данном сегменте сети, в том числе и маршрутизатор. Получив данный запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а затем отправит на запросивший хост ARP-ответ, в котором сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесен в ARP-таблицу, находящуюся в памяти операционной системы на запросившем хосте и содержащую записи соответствия IP- и Ethernet-адресов для хостов внутри одного сегмента. Отметим, что в случае адресации к хосту, расположенному в той же подсети, также используется ARP-протокол и рассмотренная выше схема полностью повторяется.

Из п. 3.2.3.2 следует, что в случае использования в распределенной ВС алгоритмов удаленного поиска существует возможность осуществления в такой сети типовой удаленной атаки "Ложный объект РВС" . Из анализа безопасности протокола ARP становится ясно, что, перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем активно контролировать и воздействовать на сетевой трафик "обманутого" хоста по схеме "Ложный объект РВС" (п. 3.2.3.3).

Рассмотрим обобщенную функциональную схему ложного ARP-сервера (рис. 4.3):

  1.  ожидание ARP-запроса;
  2.  при получении ARP-запроса передача по сети на запросивший хост ложного ARP-ответа, в котором указывается адрес сетевого адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на котором будет принимать пакеты ложный ARP-сервер (совершенно необязательно указывать в ложном ARP-ответе свой настоящий Ethernet-адрес, так как при работе непосредственно с сетевым адаптером его можно запрограммировать на прием пакетов на любой Ethernet-адрес);
  3.  прием, анализ, воздействие и передача пакетов обмена между взаимодействующими хостами (воздействие на перехваченную информацию см. п. 3.2.2.3).

Данная схема атаки требует некоторого уточнения. На практике авторы столкнулись с тем, что зачастую даже очень квалифицированные сетевые администраторы и программисты не знают либо не понимают тонкостей работы протокола ARP. Это, наверное, связано с тем, что при обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP (нам не встречалось ни одной сетевой ОС, где обязательно требовалось бы создание "вручную" ARP-таблицы). Поэтому протокол ARP остается как бы "прозрачным" для администраторов. Далее, необходимо обратить внимание на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация об IP- и соответствующих им Ethernet-адресах всех хостов из сегмента сети, подключенного к маршрутизатору. Информация в эту ARP-таблицу на маршрутизаторе также обычно заносится не вручную, а при помощи протокола ARP. Именно поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом обратиться в сеть - сразу же будет послан широковещательный ARP-запрос, и маршрутизатор, получив этот запрос, автоматически обновит запись в своей ARP-таблице (поставит в соответствии с чужим IP-адресом Ehternet-адрес вашей сетевой карты), в результате чего обладатель данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и приходящие на маршрутизатор, будут направляться маршрутизатором на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows '95 или SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной системы, выдают предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить себе (естественно, успешно) данный IP-адрес.

Теперь вернемся непосредственно к описанной ранее схеме атаки "ложный ARP-сервер" . Из анализа механизмов адресации, описанных выше, становится ясно, что, так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP- и Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, то он будет передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема передачи пакетов в этом случае будет следующая:

  1.  атакованный хост передает пакеты на ложный ARP-сервер;
  2.  ложный ARP-сервер передает принятый от атакованного хоста пакет на маршрутизатор;
  3.  маршрутизатор, в случае получения ответа на переданный запрос, передает его непосредственно на атакованный хост, минуя ложный ARP-сервер.

В этом случае последняя фаза, связанная с "приемом, анализом, воздействием и передачей пакетов обмена" между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а режиме "полупере-хвата" (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую стороны, обязательно проходит через ложный сервер-мост; а в режиме "полуперехвата" маршрут пакетов образует петлю, которую можно видеть на рисунке 4.3.4. Необходимо обратить внимание на эту петлевую схему перехвата информации ложным сервером, так как в дальнейшем будут рассмотрены еще два варианта атаки на базе протоколов DNS и ICMP, результат которых - перехват информации по схеме "Ложный объект РВС" , и там также может возникнуть петлевой маршрут.

Тем не менее довольно несложно придумать несколько способов, позволяющих функционировать ложному ARP-серверу по мостовой схеме перехвата (полный перехват). Например, можно, получив ARP-запрос, самому послать такой же запрос и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся остаться незамеченным, так некоторые сетевые ОС (например Windows '95 и SunOS 5.3), как отмечалось ранее, перехватив этот запрос, выдадут предупреждение об использовании их IP-адреса). Другой, значительно более предпочтительный способ: послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с маршрутизатором, так и с "обманутыми" хостами (кстати, это типичная proxy-схема).

В заключении рассказа об уязвимостях протокола ARP необходимо показать, как различные сетевые ОС используют этот протокол для изменения информации в своих ARP-таблицах. При исследовании различных сетевых ОС выяснилось, что в ОС Linux 1.2.8 при адресации к хосту, находящемуся в одной подсети с данным хостом, при отсутствии в ARP-таблице соответствующей записи о Ethernet-адресе передается ARP-запрос и при последующих обращениях к данному хосту посылки ARP-запроса не происходит. В SunOS 5.3, при каждом новом обращении к хосту происходит передача ARP-запроса, и, следовательно, ARP-таблица динамически обновляется. ОС Windows '95 при обращении к хостам, с точки зрения использования протокола ARP, ведет себя так же, как и ОС Linux, за исключением того, что эта операционная система периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора (видимо, программисты фирмы Microsoft считали, что маршрутизатор может постоянно менять свой Ethernet-адрес?!), и в результате в течение нескольких минут вся локальная сеть с Windows '95 с легкостью поражается с помощью ложного ARP-сервера. Что касается Windows NT 4.0, то эксперименты показали, что там также используется динамически изменяемая ARP-таблица и ARP-запросы о Ethernet-адресе маршрутизатора передаются с периодичностью около 10 минут.

Особый интерес вызвал следующий вопрос: а удастся ли осуществить данную удаленную атаку на UNIX-совместимую ОС, защищенную по классу B1 (мандатная и дискретная сетевая политики разграничения доступа плюс специальная схема функционирования SUID/SGID процессов), установленную на двухпроцессорной миниЭВМ. Эта система является одним из лучших в мире полнофункциональных файрволов. Так вот, в процессе анализа защищенности этого файрвола относительно удаленных воздействий, осуществляемых по каналам связи, при его тестировании выяснилось, что в случае базовой (после всех стандартных настроек) конфигурации ОС эта защищенная UNIX-система также поражается ложным ARP-сервером.

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

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

4.5. Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)

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

Для идентификации TCP-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия - Sequence Number (номер последовательности) и Acknowledgment Number (номер подтверждения).

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

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

Протокол TCP (Transmission Control Protocol) является одним из базовых протоколов транспортного уровня сети Internet. Этот протокол позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, и является протоколом с установлением логического соединения - виртуального канала. По этому каналу передаются и принимаются пакеты с регистрацией их последовательности, осуществляется управление потоком пакетов, организовывается повторная передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.

Для идентификации TCР-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия - Sequence Number и Acknowledgment Number. Также нас будет интересовать поле, называемое Control Bits.

Это поле размером 6 бит может содержать следующие командные биты (слева направо):

URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender

Далее рассмотрим схему создания TCP-соединения (рис 4.9).

Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на Вследующее сообщение:

Рис. 4.9. Схема создания TCP-соединения.

1. A - > B: SYN, ISSa

Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).

В отвечает:

2. B - > A: SYN, ACK, ISSb, ACK(ISSa+1)

В ответ на полученный от А запрос В отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В устанавливается свое начальное значение счетчика - ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.

А, завершая рукопожатие (handshake), посылает:

3. A - > B: ACK, ISSa+1, ACK(ISSb+1)

В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В считается установленным.

Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:

4. A - > B: ACK, ISSa+1, ACK(ISSb+1); DATA

Из рассмотренной выше схемы создания TCP-соединения видно, что единственными идентификаторами TCP-абонентов и TCP-соединения являются два 32-бит-ных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения - ISSa и ISSb. Проблема возможной подмены TCP-сообщения становится еще более важной, так как анализ протоколов FTP и TELNET, реализованных на базе протокола TCP, показал, что проблема идентификации FTP- и TELNET-пакетов целиком возлагается данными протоколами на транспортный уровень, то есть на TCP. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP- или TELNET-подклю-чение), послать пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени клиента), и данный пакет будет воспринят как верный! К тому же, так как FTP и TELNET не проверяют IP-адреса отправителей, от которых им приходят сообщения, то в ответ на полученный ложный пакет, FTP- или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий IP-адрес атакующего, то есть атакующий начнет работу с FTP- или TELNET-сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь, потеряет связь с сервером из-за рассогласования счетчиков!

Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.

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

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

Для защиты от таких атак необходимо использовать ОС, в которых начальное значение идентификатора генерируется действительно случайным образом. Также необходимо использовать защищённые протоколы типа SSL, S-HTTP, Kerberos и т.д.


 

А также другие работы, которые могут Вас заинтересовать

61933. Изготовление изделия из нетрадиционных материалов 19.31 KB
  Ребята вспомните кто является любимицей кота Матроскина А кто может сказать как ее звали Не можете вспомнить тогда я вам помогу загадав загадку: Каждый вечер так легко Она дает нам молоко. Ребята скажите из чего сделана наша коровка Какие геометрические фигуры спрятались на этой работе...
61934. Организация обучения математике учащихся специальной (коррекционной) школы VIII вида: Урок математики 23.25 KB
  Организация обучения математике учащихся специальной коррекционной школы VIII вида: Урок математики. Контроль и учёт состояния математической подготовки учащихся. Домашняя работа по математике содержание объем учет индивидуальных возможностей учащихся ее значение в системе математической подготовки школьников с нарушением интеллекта. готовность учащихся к уроку; четкость указаний учителя; организация внимания учащихся; продолжительность этапа; проверка знаний учащихся домашнее задание: сочетание фронтальной и углубленной проверки...
61936. Народная праздничная одежда 19.59 KB
  Сообщение темы урока Учитель: Красочна и нарядна русская народная одежда. Рассказ учителя и беседа с учениками Учитель: Ребята представьте себе такую картину. Учитель: Какие простые имена вы можете назвать Ответ: Машенька Дуняша Аленушка...
61937. Оркестрова інтермедія написана Миколою Римським-Корсаковим 15.75 KB
  Ласкавинки посилаємо Працювати починаємо Перевірка готовності до уроку Любі діти сьогодні на уроці вам нічого не знадобиться тож відкладіть усе зайве сядьте рівнесенько і налаштуйтесь на плідну працю Повідомлення теми і мети уроку Вступне слово вчителя...
61938. Русская классическая музыка 17.12 KB
  Она ему так понравилась что он ее использовал в своем более крупном произведении который называется Концерт может кто-то скажет что такое концерт ответы детей Это произведение в котором солист и оркестр как бы соревнуются между собой.
61939. Методические особенности использования музыки на уроках физкультуры в школе 14.77 KB
  Лучше всего этим требованиям отвечают учебные задания выполняемые учащимися во время разминки во вводной части урока во время совершенствования ранее изученных упражнений и специальных двигательных навыков в основной части а также во время выполнения...
61940. Формирование общественного мнения отделением информации и общественных связей Управления внутренних дел по Владимирской области 412 KB
  Основная цель дипломной работы заключается в комплексном социологическом исследовании связей с общественностью органов внутренних дел как функции управления, а также выработке научно-практических рекомендаций, направленных на повышение эффективности деятельности пресс-службы органов внутренних дел Владимирской области посредствам формирования развитой системы социальных коммуникации.
61941. На пороге Экологической катастрофы 31.88 KB
  Цели: расширить представление детей о взаимосвязях в природе, о способах сохранения и оказания помощи природе; ознакомить с фактами уничтожения природы в России; способствовать формированию положительной нравственной оценки таких качеств личности, как экологическая культура, экологическая грамотность...