Атака на Internet
Шрифт:
Отказ в обслуживании
Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа к данному объекту с любого объекта сети: каждый субъект (пользователь) системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях такая возможность реализуется следующим образом: на объекте РВС в сетевой ОС запускается ряд программ-серверов, входящих в состав телекоммуникационных служб предоставления удаленного сервиса (например, FTP-сервер, WWW-сервер и т. д.). Задача сервера – находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. При получении подобного сообщения сервер должен по возможности передать запросившему ответ, разрешая подключение или не разрешая. По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер.
Очевидно, что сетевая операционная система способна поддерживать ограниченное число открытых виртуальных соединений, а также отвечать на ограниченное число запросов (ограничена длина очереди запросов на подключение, тайм-аут очистки очереди и число одновременно открытых соединений). Эти ограничения устанавливаются индивидуально для каждой
Суть второй разновидности реализации этой типовой угрозы заключена в передаче с одного адреса стольких запросов на атакуемый объект, сколько позволит пропускная способность канала передачи (направленный шторм запросов; от англ. «flooding» – наводнение). Если в системе не предусмотрено ограничение числа принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может быть нарушение работы системы от возможного переполнения очереди запросови отказа одной из телекоммуникационных служб, вплоть до полной остановки компьютера из-за того, что система не может заниматься ничем другим, кроме обработки запросов.
Типовая удаленная атака «отказ в обслуживании» является активным воздействием (класс 1.2), осуществляемым с целью нарушения работоспособности системы (класс 2.3), относительно объекта атаки (класс 3.3). Данная атака является однонаправленным (класс 4.2) внутрисегментным (класс 5.1) или межсегментным воздействием (класс 5.2), осуществляемым на канальном (класс 6.2), сетевом (класс 6.3), транспортном (класс 6.4) и прикладном (класс 6.7) уровнях модели OSI.
Для моделирования механизмов реализации данной типовой угрозы воспользуемся графовой моделью взаимодействия объектов РВС в проекции на канальный и сетевой уровни модели OSI (рис. 3.10).
Рис. 3.10. Графовая модель взаимодействия объектов РВС при реализации типовой угрозы «отказ в обслуживании» в проекции на канальный и сетевой уровни модели OSI
Пусть объект Xk взаимодействует с объектом XM. Пусть с объекта X1 осуществляется данное воздействие с целью нарушить работоспособность объекта Xk. Тогда с объекта X1 осуществляется направленный шторм (или мини-шторм) запросов на объект Xk от имени любых объектов в сети (lsxik). Если атака достигла цели, на сетевом уровне нарушается взаимодействие объекта Xk с объектом XM, а на канальном уровне может нарушиться взаимодействие Xk с ближайшим роутером GM+k. Следовательно, на графе взаимодействия объектов РВС пропадают однонаправленные линии связи lskM и kskM+k.
Глава 4 Удаленные атаки на хосты Internet
Многое
Наша Земля повидала,
Но не видала
Такого скандала!
Б. Заходер. География всмятку
Анализ сетевого трафика Internet
В Internet базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol). TELNET – это протокол виртуального терминала (ВТ), позволяющий с удаленных хостов подключаться к серверам Internet в режиме ВТ. FTP – протокол, предназначенный для передачи файлов между удаленными хостами. Для получения доступа к серверу по данным протоколам пользователю необходимо пройти процедуры идентификации и аутентификации. В качестве информации, идентифицирующей пользователя, выступает его имя, а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, что пароли и идентификаторы пользователей передаются по сети в открытом, незашифрованном виде. Таким образом, необходимым и достаточным условием для получения удаленного доступа к хостам по протоколам FTP и TELNET являются имя и пароль пользователя.
Одним из способов получения таких паролей и идентификаторов в Internet является анализ сетевого трафика. Этот анализ осуществляется с помощью специальной программы-анализатора пакетов (sniffer), перехватывающей все пакеты, передаваемые по сегменту сети, и выделяющей среди них те, в которых передаются идентификатор пользователя и его пароль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET разбивает пароль на символы и пересылает их по одному, помещая каждый символ пароля в соответствующий пакет, а FTP, напротив, пересылает пароль целиком в одном пакете.
Рис. 4.1. Схема осуществления анализа сетевого трафика
У внимательного читателя, наверное, уже возник вопрос, почему разработчики базовых прикладных протоколов Internet не предусмотрели возможностей шифрования передаваемых по сети паролей пользователей. Даже во всеми критикуемой сетевой ОС Novell NetWare 3.12 пароли пользователей никогда не передаются по сети в открытом виде (правда, указанная функция этой ОС не особенно помогает [11]). Видимо, проблема в том, что базовые прикладные протоколы семейства TCP/IP разрабатывались очень давно, в период с конца 60-х до начала 80-х годов, и с тех пор абсолютно не изменились. При этом точка зрения на построение глобальных сетей стала иной. Инфраструктура Сети и ее протоколы разрабатывались исходя, в основном, из соображений надежности связи, но не из соображений безопасности. Мы, пользователи Internet, вынуждены сейчас прибегать к услугам этой устаревшей с точки зрения защищенности глобальной сети. Совершенно очевидно, что вычислительные системы за эти годы сделали колоссальный скачок в своем развитии, существенно изменился и подход к обеспечению информационной безопасности распределенных ВС. Были разработаны различные протоколы обмена, позволяющие защитить сетевое соединение и зашифровать трафик (например, протоколы SSL, SKIP и т. п.). Однако новые протоколы не сменили устаревшие и не стали стандартом для каждого пользователя (за исключением, может быть, SSL, да и то лишь применительно к некоторым Web-транзакциям). К сожалению, процесс перехода на эти протоколы может длиться еще многие годы, так как в Internet централизованное управление сетью отсутствует. А на сегодняшний день подавляющее большинство пользователей продолжают работать со стандартными протоколами семейства TCP/IP, разработанными более 15 лет назад. В результате, как показывают сообщения американских центров по компьютерной безопасности (CERT, CIAC), в последние годы анализ сетевого трафика в сети Internet успешно применяется кракерами, и, согласно материалам специального комитета при конгрессе США, с его помощью в 1993–1994 годах было перехвачено около миллиона паролей для доступа в различные информационные системы.
Ложный ARP-сервер в сети Internet
Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. Как правило, такой пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из заголовка и поля данных. В заголовок пакета обычно заносится служебная информация, необходимая для адресации пакета, его идентификации, преобразования и т. д.; такая информация определяется используемым протоколом обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного
1. Заголовок Ethernet.
2. Заголовок IP.
3. Заголовок TCP.
4. Данные.
Иерархия протоколов сети Internet в проекции на модель OSI приведена на рис. 4.2.
Данный рисунок требует некоторого уточнения. Здесь показано, на каких протоколах (TCP или UDP) обычно – по умолчанию – реализованы прикладные службы. Но это отнюдь не означает, что не существует, например, реализаций FTP на базе UDP – в стандартном файле /etc/services в ОС FreeBSD дается перечень возможных реализаций прикладных служб как на основе протокола TCP, так и протокола UDP.
Рассмотрим схему адресации пакетов в Internet и возникающие при этом проблемы безопасности. Как известно, базовым сетевым протоколом обмена в Internet является протокол IP (Internet Protocol). Протокол IP – это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку сети. Для адресации на сетевом уровне (IP-уровне) в Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на хост в IP-заголовке пакета в поле Destination Address необходимо указать IP-адрес данного хоста. Однако, как видно из структуры TCP-пакета, IP-пакет находится внутри аппаратного пакета (если среда передачи – Ethernet, IP-пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми протоколами обмена в конечном счете посылается на аппаратный адрес сетевого адаптера, непосредственно осуществляющего прием и передачу пакетов в сети (в дальнейшем мы будем рассматривать только Ethernet-сети).
Из всего вышесказанного следует, что для адресации IP-пакетов в Internet кроме IP-адреса хоста необходим еще либо Ethernet-адрес его сетевого адаптера (в случае адресации внутри одной подсети), либо Ethernet-адрес маршрутизатора (в случае межсетевой адресации). Первоначально хост может не иметь информации о Ethernet-адресах других хостов, находящихся с ним в одном сегменте, в том числе и о Ethernet-адресе маршрутизатора. Следовательно, хост должен найти эти адреса, применяя алгоритмы удаленного поиска (о них мы говорили в главе 3). В сети Internet для решения этой задачи используется протокол ARP (Address Resolution Protocol), который позволяет получить взаимно однозначное соответствие IP-и Ethernet-адресов для хостов, находящихся внутри одного сегмента. Это достигается следующим образом: при первом обращении к сетевым ресурсам хост отправляет широковещательный ARP-запрос на Ethernet-адрес FFFFFFFFFFFFh, где указывает IP-адрес маршрутизатора и просит сообщить его Ethernet-адрес (IP-адрес маршрутизатора является обязательным параметром, который всегда устанавливается вручную при настройке любой сетевой ОС в Internet). Этот широковещательный запрос получат все станции в данном сегменте сети, в том числе и маршрутизатор. Получив такой запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP-таблицу, а затем отправит ARP-ответ, в котором сообщит свой Ethernet-адрес. Полученный в ARP-ответе Ethernet-адрес будет занесенв ARP-таблицу, находящуюся в памяти операционной системы на запросившем хосте и содержащую записи соответствия IP-и Ethernet-адресов для хостов внутри одного сегмента. Отметим, что в случае адресации к хосту, расположенному в той же подсети, также используется ARP-протокол, и рассмотренная выше схема полностью повторяется. Как указывалось ранее, при использовании в распределенной ВС алгоритмов удаленного поиска существует возможность осуществления в такой сети типовой удаленной атаки «ложный объект РВС». Анализ безопасности протокола ARP показывает, что, перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP-запрос, можно послать ложный ARP-ответ, в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем активно контролировать сетевой трафик дезинформированного хоста, воздействуя на него по схеме «ложный объект РВС».
Рассмотрим обобщенную функциональную схему ложного ARP-сервера (рис. 4.3):
1. Ожидание ARP-запроса.
2. При получении такого запроса – передача по сети на запросивший хост ложного ARP-ответа, где указывается адрес сетевого адаптера атакующей станции (ложного ARP-сервера) или тот Ethernet-адрес, на котором будет принимать пакеты ложный ARP-сервер. Совершенно необязательно указывать в ложном ARP-ответе свой настоящий Ethernet-адрес, так как при работе непосредственно с сетевым адаптером его можно запрограммировать на прием пакетов на любой Ethernet-адрес.
3. Прием, анализ, воздействие на пакеты обмена и передача их между взаимодействующими хостами.
Данная схема атаки требует некоторого уточнения. На практике мы столкнулись с тем, что даже очень квалифицированные сетевые администраторы и программисты часто не знают или не понимают тонкостей работы протокола ARP. При обычной настройке сетевой ОС, поддерживающей протоколы TCP/IP, не требуется настройка модуля ARP (нам не встречалось ни одной сетевой ОС, где нужно было бы создавать ARP-таблицу «вручную»), поэтому протокол ARP остается как бы «прозрачным» для администраторов. Необходимо обратить внимание и на тот факт, что у маршрутизатора тоже имеется ARP-таблица, в которой содержится информация об IP-и соответствующих им Ethernet-адресах всех хостов из сегмента сети, подключенного к маршрутизатору. Информация в эту таблицу на маршрутизаторе также обычно заносится не вручную, а при помощи протокола ARP. Именно поэтому так легко в одном сегменте IP-сети присвоить чужой IP-адрес: выдать команду сетевой ОС на установку нового IP-адреса, потом обратиться в сеть – сразу же будет послан широковещательный ARP-запрос, и маршрутизатор, получив такое сообщение, автоматически обновит запись в своей ARP-таблице (поставит Ehternet-адрес вашей сетевой карты в соответствие с чужим IP-адресом), в результате чего обладатель данного IP-адреса потеряет связь с внешним миром (все пакеты, адресуемые на его бывший IP-адрес и приходящие на маршрутизатор, будут направляться им на Ethernet-адрес атакующего). Правда, некоторые ОС анализируют все передаваемые по сети широковещательные ARP-запросы. Например, ОС Windows 95 или SunOS 5.3 при получении ARP-запроса с указанным в нем IP-адресом, совпадающим с IP-адресом данной системы, выдают предупреждающее сообщение о том, что хост с таким-то Ethernet-адресом пытается присвоить себе (естественно, успешно) данный IP-адрес.
Из анализа механизмов адресации, описанных выше, становится ясно: так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP-и Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, он будет передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема передачи пакетов в этом случае будет следующая:
1. Атакованный хост передает пакеты на ложный ARP-сервер.
2. Ложный ARP-сервер посылает принятые от атакованного хоста пакеты на маршрутизатор.
3. Маршрутизатор, в случае получения ответа на запрос, адресует его непосредственно на атакованный хост, минуя ложный ARP-сервер.
В этом случае последняя фаза, связанная с приемом, анализом, воздействием на пакеты обмена и передачей их между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а в режиме «полуперехвата» (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую сторону, обязательно проходит через ложный сервер (мост); в режиме «полуперехвата» маршрут пакетов образует петлю (рис. 4.4). Петлевой маршрут может возникнуть и при рассмотренной ниже атаке на базе протоколов DNS и ICMP.