Повышение интереса к 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 Drop. Для того, что бы узнать, если к Вашей системе защита от 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: • постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с различными ID, от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера - хоста атакующего; • в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть, ложный сервер ведет работу с сервером от своего имени - со своего IP-адреса); • в случае получения пакета от сервера, изменение в 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 - сервера: • ожидание DNS-запроса; • получив DNS-запрос, извлечение из него необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; • в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть, ложный DNS-сервер ведет работу с сервером от своего имени); • в случае получения пакета от сервера, изменение в 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 не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае злоумышленник, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку злоумышленник начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение. • Ранняя десинхронизация. Соединение десинхронизируется на стадии его установки. Злоумышленник прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии. Дождавшись пакета S-SYN от сервера, злоумышленник высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет. Клиент игнорирует S-SYN-пакет, однако злоумышленник, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента. Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована. Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные злоумышленником. Для корректной обработки этих ситуаций программа должна быть усложнена. • Десинхронизация нулевыми данными. В данном случае злоумышленник прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние. ACK-буря Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ. И так до бесконечности. К счастью современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает". Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше. Детектирование и защита Есть несколько путей. Например, можно реализовать TCP/IP-стек, который будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данном случае мы не застрахованы от злоумышленника, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью. Если злоумышленник не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.

Обнаружение атак и защита от них

• Для обнаружения атак можно анализировать широковещательную активность - это пакеты UDP, NBF, SAP. • Для защиты внутренней сети, подключенной к Internet'у, не стоит пропускать из внешней сети входящие пакеты, источником в которых стоит внутренний сетевой адрес. Можно разрешить проходить пакетам только на порт 80. • Ставьте фильтрацию пакетов, если необходимо (не стоит пренебрегать даже
Control Panel\Network\Protocols\Properties\Advanced в Windows NT).

Методы сканирования

Использование протокола ARP

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

Сканирование сети посредством DNS

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

UDP bomb

Сканирование сети методом ping sweep

Ping sweep или выявление целей с помощью протокола ICMP является эффективным методом.

Противодействие: для определения факта ping-сканирования целей, находящихся внутри подсети, необходимо анализировать исходные и конечные адреса ICMP пакетов.

Сканирование TCP портов

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

Сканирование UDP портов

Другой вид сканирования портов основывается на использовании протокола UDP и заключается в следующем: на сканируемый компьютер передаётся UDP пакет, адресованный к порту, который проверяется на предмет доступности. Если порт недоступен то в ответ приходит ICMP сообщение о недоступности (destination port unreachable), в противном случае ответа нет. Данный вид сканирования достаточно эффективен. Он позволяет за короткое время сканировать все порты на компьютере-жертве. Противодействие: противодействовать сканированию данного рода возможно путём передачи сообщений о недоступности порта на компьютер злоумышленника.

Stealth-сканирование

Метод основан на некорректном сетевом коде, поэтому нельзя поручиться что он будет нормально работать в какой-либо конкретной обстановке. Используются TCP-пакеты с установленными ACK- и FIN-флагами. Их надо использовать, т.к. если такой пакет послать в порт при неоткрытом соединении, всегда возвратиться пакет с флагом RST. Существует несколько методов, использующих этот принцип: • Послать FIN-пакет. Если принимающий хост возвращает RST, значит порт неактивен, если RST не возвращается, значит порт активен. Данный метод работает в большинстве операционных систем. • Послать ACK-пакет. Если TTL возвращаемых пакетов меньше, чем в остальных полученных RST-пакетах, или если размер окна больше нуля, то скорее всего порт активен.

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

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

Приглашение системы и опасность содержащейся в нем информации

Необходимо убирать "приглашения системы", отображаемые центральными компьютерами на терминалах удаленного доступа для входа пользователя в систему. Данное требование обусловлено следующими причинами: • "приглашение системы", как правило, содержит информацию, позволяющую нарушителю идентифицировать тип и версию операционной системы центрального компьютера, вид программного обеспечения удаленного доступа и др. Такая информация может существенно упростить задачу проникновения в систему, поскольку нарушитель сможет применить средства незаконного доступа, использующие слабости конкретной системы; • "приглашение системы" обычно указывает на ведомственную принадлежность системы. В случае, когда система принадлежит секретному ведомству или финансовой структуре, заинтересованность нарушителя может значительно возрасти; • состоявшееся недавно судебное разбирательство отклонило иск компании к лицу, незаконно проникшему в сеть компании, поскольку он мотивировал свои действия надписью на терминале удаленного доступа к центральному компьютеру "Welcome to..." ("Добро пожаловать в ...").

Несколько советов при исследования сети

• Просканировать сервер на предмет открытых портов и сервисов. • Попробовать зайти на сервер под именем IUSR_<имя машины с шарами> • Попытаться спереть SAM._ из /REPAIR (пароли из SAM достаются командой expand). • Директории /scripts и /cgi-bin, как известно наверное многим, в НТ можно запускать любые файлы из этих директорий, поэтому следует закрывать к этим директориям доступ. Запуск осуществляется примерно такой командой (если исполняемый файл в /scripts) из бровзера - http://www.idahonews/scripts/getadmin.exe?test. Можно получить админовские права следующим образом - проги-то из /scripts запускаются не под юзернеймом пользователя, а с того самого web-аккаунта, из чего можно сделать вывод, что пароли админа можно элементарно сдампить из реестра с помощью PWDUMP.exe. • Следует помнить, что программы из /SCRIPTS запускаются под Web-аккаунтом, а не под аккаунтом запустившего пользователя. Поэтому можно попытаться сдампить пароли из реестра с помощью PWDUMP.EXE. Пароли будут закодированные. В этом случае следует сохранить страницу в виде текстового файла и попытаться раскодировать пароли с помощью программы BRUTEFORCE. • Под администраторским аккаунтом можно поменять алиасы на ftp и http.

Некоторые другие способы получения информации

• Используя whois или NSLookUp для выяснения альтернативных имен выяснить, кому принадлежит сеть. Запомнить диапазон ip-адресов для последующего их сканирования. • Пойти на ближайший роутер и что-либо выяснить. Для нахождения роутера нужно протрассировать путь до любого ip-адреса из обнаруженного диапазона. Ближайший роутер определяется по времени отклика. • Попробуйте зайти на роутер telnet'ом. • Запустить сканер диапазона ip-адресов для обнаружения запущенных на PC служб.

Дыры и ошибки администрирования в Windows NT

• Рассмотрим уязвимость, связанную с ошибкой в реализации системы. Данная уязвимость приводит к возможности атаки, называемой GetAdmin . Уязвимым является системный сервис NtAddAtom, не проверяющий параметры, переданные ему, и устанавливающий бит 0 по адресу NtGlobalFlag + 2. Для этого необходимо открыть файл ntoskrnl.exe и найти точку входа в NtAddAtom. Установка данного бита отключается проверка привилегий отладчика в NtOpenProcess и NtOpenThread. Таким образом, любой пользователь имеет право открыть любой процесс в системе. Атака открывает процесс Winlogon процесс и встраивает dll к нему. Так как данный сервис имеет привилегии SYSTEM, он может добавить пользователя к группе Administrator или удалить его из данной группы. Теоретически возможны и другие нарушения безопасности системы. • Один из популярных методов проникновения в систему - подбор пароля. Для борьбы с этим обычно устанавливают блокировку учетной записи пользователя после определенного числа неудачных попыток входа. Приятным исключением является учетная запись администратора. И если он имеет право доступа на вход через сеть, это открывает лазейку для спокойного угадывания пароля. Для защиты рекомендуется переименовать пользователя Administrator, установить блокировку учетных записей, запретить администратору вход в систему через сеть, запретить передачу SMB пакетов через TCP/IP (порты 137,138,139), установить протоколирование неудачных входов.

Спам

Спаммеры подыщут для начала рассылки своего почтового мусора не просто ISP, а, скорее всего, выберут корпорацию, т.к. провайдеру Internet легче понять, что произошло, и он, вероятно, сможет быстрее избавиться от таких сообщений. Периодически повторяющийся спамминг может нарушить работу законных пользователей из-за перегрузки сервера электронной почты. Проблема состоит в том, что подключиться к SMTP-серверу не так уж трудно. Для этого необходимо знать лишь 7-8 команд, чтобы SMTP-сервер стал распространять Ваши сообщения. Для ограждения от этого можно осуществлять проверку адресов поступающих сообщений по базе данных зарегистрированных пользователей сервера. Если адрес посылающего сообщение или один из запрошенных им адресов в списке отсутствует, электронная почта передаваться не будет.

Как уберечь почтовую систему от спаммеров

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

Как работают спаммеры

• Мишень выбрана - спаммер производит случайный выбор доменного имени компании и затем отгадывает имя хоста постового SMTP-сервера. Если сервер примет почту, спаммер просит его распространить сообщение по списку адресов. • Сервер исполняет запрос, создавая впечатление, что сообщения уходят с IP-адреса компании-жертвы.

Дыры IIS, WWW, FTP

• Отправитель может оставить свой фальшивый адрес следующим образом: отправитель может сам соединиться с SMTP-портом на машине, от имени которой он хочет отправить письмо, и ввести текст письма.

• Служба FTP позволяет устанавливать пассивные соединения на основе адреса порта, указанного клиентом. Это может быть использовано злоумышленником для выдачи опасных команд службе FTP. Реестр содержит ключ: <HKLM\System\CurrentControlSet\Services\MSFTPSVC\Parameters> со значением <EnablePortAttack: REG_DWORD: > Убедитесь, что значение установлено в '0', а не '1'. • Если соединиться через telnet с портом 80, команда "GET ../.." приведет к краху IIS и сообщению "The application, exe\inetinfo.dbg, generated an application error The error occurred on date@ time The exception generated was c0000005 at address 53984655. • Адрес 'http://www.domain.com/scripts..\..\scriptname" позволяет выполнить указанный скрипт. По умолчанию пользователь Guest или IUSR_WWW имеет права на чтение всех файлов во всех каталогах. Так что эти файлы могут быть просмотрены, скачаны и запущены. • Директории \script\cgi-bin следует закрывать, т.к. из этих директорий можно запускать любые файлы прямо из окна browser'а. • Пpи запpосе у IIS очень длинного URL (4 - 8KB) сервер повисает и не реагирует на дальнейшие запpосы. Пpоблема в том, что точный размер URL зависит от конкретного сервера, поэтому пpогpаммы-убийцы начиная с некоторого базового размера запроса и постепенно увеличивая размер пытаются найти ту кpитическую точку, что подвесит сеpвеp-жеpтву. • Пользователям Outlook Express 98 приходится считаться с тем, что этот мейлер позволяет обрабатывать, в том числе и на исполнение, Visual-Basic-скрипты, которые легко могут быть скрыты в письме. Подобный скрипт имеет полный доступ к файловой системе. Реальной защитой может стать лишь установка "уровня безопасности" в Outlook на "максимум". • Если в чате разрешен ввод тегов html, никто не помешает вставить в свое сообщение что-то типа <img src="http://www.mysite.com/cgi-bin/sniffer.cgi">. В итоге все присутствующие в чате (даже не зарегистрировавшиеся) будут, сами того не ведая, вызывать скрипт. • Ограничивайте доступ к порту 25 только для некоторых пользователей.

Дата створення/оновлення: 25.05.2018

Back