Повышение интереса к TCP/IP-сетям обусловлено бурным рос-том сети Internet. Однако это заставляет задуматься над тем, как защитить свои информационные ресурсы от атак из внешней се-ти. Если вы подключены к Internet, Ваша система может быть ата-кована. Протоколы семейства IP являются основой построения сетей Intranet и глобальной сети Internet. Несмотря на то, что раз-работка TCP/IP финансировалась Министерством обороны США, TCP/IP не обладает абсолютной защищенностью и допускает различные типы атак, рассмотренные в данной главе. Для осуще-ствления подобных атак потенциальный злоумышленник должен иметь контроль хотя бы над одной из систем, подключенной к Internet. Одним из подходов к анализу угроз безопасности компь-ютерных систем является выделение в отдельный класс угроз, присущих только компьютерным сетям. Данный класс угроз назо-вем - класс удаленных атак. Этот подход к классификации пред-ставляется правомочным из-за наличия принципиальных особен-ностей в построении сетевых ОС. Основной особенностью любой сетевой операционной системы является то, что ее компоненты распределены в пространстве, и связь между ними физически осуществляется при помощи специальных сетевых соединений (коаксиальный кабель, витая пара, оптоволокно и т.д.) и про-граммно - при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые одной компо-нентой сетевой ОС другой компоненте, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность и является основной причиной появления нового класса угроз - удаленных атак. При данном типе атак злоумышленник взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соответствующий инструментарий. Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак. Удаленные атаки можно классифицировать по типу воздействия: активное или пассивное. Активные атаки можно разделить на две части. В первом случае злоумышленник предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состояние. При пассивных атаках злоумышленники никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сво-диться к наблюдению за доступными данными или сессиями свя-зи. Хотя пассивные атаки могут нарушать политику безопасности сети. Идея выявления атаки проста: любой атаке соответствует определённый сетевой трафик, поэтому, анализ трафика позво-ляет определить атаку и засечь "следы" атакующего, т.е. опреде-лить IP-адреса с которых осуществлялось информационное воз-действие. Таким образом, выявление атак осуществляется мето-дом контроля информационных потоков, что достигается путём анализа сетевого трафика.

Краткие описания сетевых атак

Следует помнить, что грубые методы типа пингования большими пакетами или SYN flooding, могут заваливать любую Internet ма-шину или подсеть, независимо от конфигурации.

Фрагментация данных

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

Передача фрагментированных IP пакетов c общим объемом более 64KB

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

Атака Ping flooding

Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестиро-вания. В этом режиме запросы посылаются с максимально воз-можной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке. Данная атака требует от зло-умышленника доступа к быстрым каналам в Internet. Вспомним, как работает 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.

PingOfDeath или SSPing

Сущность его в следующем: на машину жертвы посылается силь-но фрагментиpованный ICMP пакет большого pазмеpа (64KB). Реакцией Windows-систем на получение такого пакета является безоговорочное повисание, включая мышь и клавиатуру. Про-грамма для атаки широко доступна в сети в виде исходника на C и в виде запускаемых файлов для некоторых версий Unix. Любо-пытно, что в отличие от WinNuke жертвой такой атаки могут стать не только Windows машины, атаке подвержены MacOS и некото-рые веpсии Unix. Преимущества такого способа атаки в том, что обычно firewall пропускает ICMP пакеты, а если firewall и настроен на фильтрацию адресов посылателей, то, используя нехитрые приемы spoofing, можно обмануть и такой firewall. Недостаток PingOfDeath в том, что для одной атаки надо переслать более 64KB по сети, что делает вообще его говоря малопpименимым для шиpокомасштабных дивеpсий.

UDP bomb

Передаваемый пакет UDP содержит неправильный формат слу-жебных полей. Некоторые старые версии сетевого ПО приводят при получении подобного пакета к аварийному завершению сис-темы.

SYN flooding

Затопление SYN -пакетами - самый известный способ "забить" информационный канал. Вспомним, как работает 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 . Для того, что бы узнать, если к Вашей системе за-щита от SYN-затопления, обратитесь к поставщику системы. Дру-гой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить syn-затопление и не пропустить его внутрь сети. Эта атака относится к атакам запрещения обслуживания, резуль-татом которой является невозможность предоставления услуг. Атака обычно направлена на определённую, конкретную службу, например telnet или ftp. Она заключается в передаче пакетов ус-тановления соединения на порт, соответствующий атакуемой службе. При получении запроса система выделяет ресурсы для нового соединения, после чего пытается ответить на запрос (по-слать "SYN-ACK") по недоступному адресу. По умолчанию NT версий 3.5-4.0 будет пытаться повторить подтверждение 5 раз - через 3, 6, 12, 24 и 48 секунд. После этого еще 96 секунд система может ожидать ответ, и только после этого освободит ресурсы, выделенные для будущего соединения. Общее время занятости ресурсов - 189 секунд.

Нестандартные протоколы, инкапсулированные в IP

Пакет IP содержит поле, определяющее протокол инкапсулиро-ванного пакета (TCP, UDP, ICMP). Злоумышленники могут ис-пользовать нестандартное значение данного поля для передачи данных, которые не будут фиксироваться стандартными средст-вами контроля информационных потоков.

Применение протокола TFTP

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

Атака smurf

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

Атака Land

Атака Land использует уязвимости реализаций стека TCP/IP в некоторых ОС. Она заключается в передаче на открытый порт компьютера-жертвы TCP-пакета с установленным флагом SYN, причем исходный адрес и порт такого пакета соответственно рав-ны адресу и порту атакуемого компьютера. Это приводит к тому, что компьютер-жертва пытается установить соединение сам с собой, в результате чего сильно возрастает загрузка процессора и может произойти "подвисание" или перезагрузка. Данная атака весьма эффективна на некоторых моделях маршрутизаторов фирмы Cisco Systems, причем успешное применение атаки к маршрутизатору может вывести из строя всю сеть организации.
Противодействие: защититься от данной атаки можно, напри-мер, установив фильтр пакетов между внутренней сетью и Internet, задав на нём правило фильтрации, указывающее подав-лять пакеты, пришедшие из Internet, но с исходными IP адресами компьютеров внутренней сети.

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

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

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

Из схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache. То есть, в том случае, если DNS-сервер не имеет све-дений о запрашиваемом хосте, то он пересылает запрос далее, а значит, теперь сам DNS-сервер является инициатором удаленно-го DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными в предыдущем пункте методами, направить свою атаку на DNS-сервер. То есть, в качестве цели атаки теперь бу-дет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер. При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответст-вия имен и IP-адресов хостов. В том числе в кэш заносится дина-мически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера. То есть, если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на сле-дующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу в память. Таким образом, при получении следующе-го запроса DNS-серверу уже не требуется вести удаленный по-иск, так как необходимые сведения уже находятся у него в кэш-таблице. Из анализа только что подробно описанной схемы уда-ленного DNS-поиска становится очевидно, что в том случае, если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соот-ветствующая запись с ложными сведениями и, в дальнейшем, все хосты, обратившиеся к данному DNS-серверу, будут дезин-формированы и при обращении к хосту, маршрут к которому ата-кующий решил изменить, связь с ним будет осуществляться че-рез хост атакующего по схеме "ложный объект ВС". И с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уров-ней, а, следовательно, все больше хостов в Internet будут дезин-формированы и атакованы. Очевидно, что в том случае, если атакующий не может перехватить DNS-запрос от DNS-сервера, то для реализации атаки ему необходим "шторм" ложных DNS-ответов, направленный на DNS-сервер. При этом возникает сле-дующая основная проблема, отличная от проблемы подбора пор-тов в случае атаки, направленной на хост. Как уже отмечалось ранее DNS-сервер, посылая запрос на другой DNS-сервер, иден-тифицирует этот запрос двухбайтовым значением (ID). Это зна-чение увеличивается на единицу с каждым передаваемым запро-сом. Узнать атакующему это текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому, ничего кроме перебора 2 16 возможных значений ID предложить что-либо достаточно сложно. Зато исчезает проблема перебора пор-тов, так как все DNS-запросы передаются DNS-сервером на 53 порт. Следующая проблема, являющаяся условием осуществле-ния этой удаленной атаки на DNS-сервер при направленном "шторме" ложных DNS-ответов состоит в том, что атака будет иметь успех, только в том случае, если DNS-сервер пошлет за-прос на поиск определенного имени (которое содержится в лож-ном DNS-ответе). DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос в том случае, если на него прийдет DNS-запрос от какого-либо хоста на поиск данного имени и этого имени ни окажется в кэш-таблице DNS-сервера. В прин-ципе этот запрос может прийти когда угодно и атакующему может быть придется ждать результатов атаки сколь угодно долго. Од-нако ни что не мешает атакующему, не дожидаясь никого, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спро-воцировать DNS-сервер на поиск указанного в запросе имени. Тогда эта атака с большой вероятностью будет иметь успех прак-тически сразу же после начала ее осуществления.

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

В данном случае это удаленная атака на базе стандартной типо-вой удаленной атаки, связанной с ожиданием поискового DNS-запроса. Перед тем, как рассмотреть алгоритм атаки на службу DNS необходимо обратить внимание на следующие тонкости в работе этой службы. Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и исполь-зование протокола TCP) что, естественно, делает ее менее за-щищенной, так как протокол UDP в отличие от TCP вообще не предусматривает средств идентификации сообщений. Для того, чтобы перейти от UDP к TCP администратору DNS - сервера прийдется очень серьезно изучить документацию. Кроме того, этот переход несколько замедлит систему, так как, во-первых, при использовании TCP требуется создание виртуального соедине-ния и, во-вторых, конечные сетевые ОС вначале посылают DNS-запрос с использованием протокола UDP и в том случае, если им в придет специальный ответ от DNS-сервера, то тогда сетевая ОС пошлет DNS-запрос с использованием TCP. Во-вторых, сле-дующая тонкость, на которую требуется обратить внимание, со-стоит в том, что значение поля "порт отправителя" в UDP-пакете вначале принимает значение 1023(?) и, затем увеличивается с каждым переданным DNS-запросом. В-третьих, значение иден-тификатора (ID) DNS-запроса ведет себя следующим образом. В случае передачи DNS-запроса с хоста его значение зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос. Эксперименты автора показали, что в случае передачи запроса из оболочки командного интерпретатора операционных систем Linux и Windows '95 (например, ftp nic.funet.fi) это значение всегда равняется единице. В том случае, если DNS-запрос пере-дается из Netscape Navigator, то с каждым новым запросом сам броузер увеличивает это значение на единицу. В том случае, ес-ли запрос передается непосредственно DNS-сервером, то сервер увеличивает это значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса. Для реализации ата-ки путем перехвата DNS-запроса атакующему необходимо пере-хватить DNS-запрос, извлечь из него номер UDP-порта отправи-теля запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и, затем, послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в ка-честве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить и активно воздействовать по схеме "Ложный объект РВС" на тра-фик между "обманутым" хостом и сервером. Рассмотрим обоб-щенную схему работы ложного DNS - сервера: o ожидание DNS-запроса; o получив DNS-запрос, извлечение из него необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в кото-ром указывается IP-адрес ложного DNS-сервера; o в случае по-лучения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть, ложный DNS-сервер ведет работу с сервером от своего имени); o в случае получения пакета от сервера, измене-ние в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер). Необходимым условием осу-ществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий на-ходится либо на пути основного трафика либо в сегменте на-стоящего DNS-сервера. Выполнение одного из этих условий ме-стонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и тем более в межсегментный канал связи атакующему скорее всего не удастся). Однако в случае выполнения этих усло-вий возможно осуществить межсегментную удаленную атаку на сеть Internet . Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов. В случае, если FTP-клиент на хосте подключился к удаленному FTP-серверу через ложный DNS-сервер, то оказывалось, что ка-ждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле дан-ных TCP-пакета номера порта и IP-адреса клиентского хоста (особый смысл в этих действиях трудно найти - зачем каждый раз передавать на FTP-сервер IP-адрес клиента)! Это приводило к тому, что если на ложном DNS-сервере не изменить передавае-мый IP-адрес в поле данных TCP-пакета и передать этот пакет на FTP-сервер по обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервер и, что самое интересное, этот пакет будет воспринят как нормальный пакет, и, в дальнейшем, ложный DNS-сервер поте-ряет контроль над трафиком между FTP-сервером и FTP-клиентом! Это связано с тем, что обычный FTP-сервер не преду-сматривает никакой дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и соединения на более низкий уровень - уровень TCP.

Атака DNS flooding

DNS flooding - это атака, направленная на сервера имён Internet. Она заключается в передаче большого числа DNS запросов и приводит к тому, что у пользователей нет возможности обра-щаться к сервису имен и, следовательно, обеспечивается невоз-можность работы обычных пользователей.
Противодействие: для выявления данной атаки необходимо анализировать загрузку DNS сервера и выявлять источники запросов.

Атака DNS spoofing

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

Атака IP spoofing (syslog)

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

Навязывание пакетов

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

Sniffing - прослушивание канала (возможно только в сегменте локальной сети)

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

Перехват пакетов на маршрутизаторе

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

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

В сети Internet существует протокол ICMP (Internet Control Message Protocol), одной из функцией которого является инфор-мирование хостов о смене текущего маршрутизатора. Данное управляющее сообщение носит название redirect. Существует возможность посылки с любого хоста в сегменте сети ложного redirect-сообщения от имени маршрутизатора на атакуемый хост. В результате у хоста изменяется текущая таблица маршрутиза-ции и, в дальнейшем, весь сетевой трафик данного хоста будет проходить, например, через хост, отославший ложное redirect-сообщение. Таким образом возможно осуществить активное на-вязывание ложного маршрута внутри одного сегмента сети Internet.

WinNuke

Hаpяду с обычными данными пеpесылаемыми по TCP соедине-нию cтандаpт пpедустатpивает также пеpедачу сpочных (Out Of Band) данных. Hа уpовне фоpматов пакетов TCP это выpажается в ненулевом urgent pointer. У большинства PC с установленным Windows пpисутствует сетевой пpотокол NetBIOS, котоpый ис-пользует для своих нужд 3 IP поpта: 137, 138, 139. Как выясни-лось, если соединиться с Windows машиной в 139 поpт и послать туда несколько байт OutOfBand данных, то pеализация NetBIOS-а не зная что делать с этими данными попpосту подвешивает или пеpезагpужает машину. Для Windows 95 это обычно выглядит как синий текстовый экpан, сообщающий об ошибке в дpайвеpе TCP/IP и невозможность pаботы с сетью до пеpезагpузки ОC. NT 4.0 без сеpвис паков пеpезагpужается, NT 4.0 со втоpым сеpвис паком выпадает в синий экpан. Аналогичная посылка данных в 135 и некоторые другие порты приводит к значительной загрузке процессора RPCSS.EXE. На NTWS это приводит к существенному замедлению работы, NTS практически замораживается.

Ложный ARP сервер

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

Предсказание TCP sequence number (IP-spoofing)

В данном случае цель злоумышленника - притвориться другой системой, которой, например, "доверяет" система-жертва. Метод также используется для других целей - например, для использо-вании SMTP жертвы для посылки поддельных писем. Установка TCP-соединения происходит в три стадии: клиент вы-бирает и передает серверу 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 для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принад-лежащие нашему адресному пространству.

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

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

IP Hijacking

Метод является комбинацией 'подслушивания' и IP-spoofing'а. Необходимые условия - злоумышленник должен иметь доступ к машине, находящейся на пути сетевого потока и обладать доста-точными правами на ней для генерации и перехвата IP-пакетов. Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов. Существует возможность ввести соединение в "десинхронизированное состояние", когда присы-лаемые сервером sequence number и acknowledge number не бу-дут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае злоумышленник, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позво-ляет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку злоумышленник начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение. o Ранняя десин-хронизация. Соединение десинхронизируется на стадии его уста-новки. Злоумышленник прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии. Дождавшись пакета S-SYN от сервера, злоумышленник высылает серверу па-кет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет. Клиент игнорирует S-SYN-пакет, однако злоумышленник, прослушивающий линию, высыла-ет серверу S-ACK-пакет от имени клиента. Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхро-низирована. Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеря-ются какие-то пакеты, посланные злоумышленником. Для кор-ректной обработки этих ситуаций программа должна быть услож-нена. o Десинхронизация нулевыми данными. В данном случае злоумышленник прослушивает сессию и в какой-то момент посы-лает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной про-граммы и не видны клиенту (например, для 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-пакет. Это делает не-возможным раннюю десинхронизацию.