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

Большинство современных систем обнаружения вторжений слишком часто извещают о ложных тревогах. Другими словами, они не способны принять обоснованные решения по вопросу опасности или безвредности проходящего по сети трафика. Поэтому сетевые системы обнаружения вторжений (Network Intrusion Detection System - NIDS) часто перестраховываются и сообщают о несуществующих опасностях. Тому есть много причин. Кратко объяснить это можно так, что в большинстве случаев сигнатуры и наборы правил, которые используют системы NIDS для выявления опасного трафика, слишком неконкретны. Если эти сигнатуры не могут быть определены более четко, или этого просто не сделано, то система обнаружения вторжений будет сообщать о ложных тревогах.

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

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

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

Личный пример ложной тревоги

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

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

Прошло немного времени и мои проблемы стали серьезнее и мне пришлось звонить в мастерскую по ремонту автомобилей. Я описал работнику мастерской симптомы, на что в ответ тот почти закричал: “Ты идиот!”. Несмотря на умение общаться с клиентами, ему не удалось сдержать свое возмущение моей глупостью. Он объяснил мне, что у меня сломался генератор тока, и что моя машина могла взорваться. Думаю, не нужно пояснять, почему я больше не стал искушать судьбу и отвез машину в ремонт.

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

Ожидаемый трафик

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

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

Запросы на комментарии

Базовая документация по работе в Internet содержится в документах RFC (Requests for Comments - запросы на комментарии). В них содержится описание стандартов отдельных протоколов. С логической точки зрения сеть Internet можно рассматривать как набор различных протоколов, задокументированных в одном или нескольких RFC. Опубликованные документы RFC никогда не изменяются, а усовершенствование протокола описывается в новом RFC. К наиболее важным для данного раздела документам RFC можно отнести следующие.

■ RFC 793. В этом RFC стандартизируется протокол TCP, описываются функции, реализуемые этим протоколом, использующие его программы и интерфейс взаимодействия протокола с программами или пользователями, которым требуются его возможности.

■ RFC 768. В этом RFC рассматривается использование протокола UDP, который не гарантирует доставки сообщений и не ориентирован на установление соединений.

■ RFC 791 определяет работу протокола IP - протокола, который позволяет организовать передачу данных между хостами в виде дейтаграмм.

■ RFC 792 описывает стандарт протокола ICMP, предназначенного для уведомления об ошибках в процессе доставки сообщений.

Более подробную информацию о документах RFC можно получить по адресу www.rfс-editor.org.

Воздействие-реакция при ТСР-трафике

В этом разделе изучаются ответы при попытке установить telnet-соединения в различных условиях, например, при закрытом порте службы telnet или при блокировании telnet-соединений маршрутизатором. Службу telnet можно считать стандартным TCP-приложением. Показаны различные варианты ответов на одинаковые запросы. Конечно, здесь не приведен весь утомительный перечень различных обстоятельств, возможных при установке TCP-соединения. Приведенные здесь ситуации позволяют проиллюстрировать наиболее типичные случаи.

Хост-получатель ожидает запросов на указанный порт

Пусть хост tel_client. com пытается установить telnet-соединение с хостом myhost. com, который ожидает запросов на порт службы telnet (ТСР-порт 23). Воздействие:

tel_client.com.38060 i myhost.com.telnet : S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)

На хосте myhost. com запущена служба telnet и он разрешает telnet-соединение.

Реакция:

myhost.com.telnet > tel_client.com.38060 : S 2009600000:2009600000 (0) ack b 3774957991 win 1024 <mss 1460>

В этом отчете TCPdump представлена ожидаемая реакция на попытку клиентского хоста tel_client.com установить соединение с портом службы telnet хоста-получателя myhost. com. Мы уже рассказывали о полной процедуре установления TCP-соединения. Как вы помните, клиент инициирует это соединение с помощью SYN-пакета. В данном случае SYN-пакет отправляется на порт службы telnet хоста myhost. com.

После этого, если данная служба запущена, установка соединения разрешается, о чем хост myhost. com уведомляет клиента пакетом, в котором установлены флаги SYN и АСК. Этот пакет свидетельствует о готовности хоста установить ТСР-соединение через запрошенный порт. Последним этапом процедуры установки со единения (здесь он не показан) является отправка хостом tel_client. com серверу пакета с установленным флагом АСК.

Хост-получатель не прослушивает указанный порт

Рассмотрим следующий отчет TCPdump, полученный при аналогичной попытке установить telnet-соединение. На этот раз хост myhost. com не ожидает запросов наТСР-порт 23. Ожидаемой реакцией является возврат сервером пакета с установленными флагами RESET и АСК с целью разрыва соединения. Воздействие:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)

Хост myhost. com не ожидает запросов на порт службы telnet.

Реакция:

myhost.com.telnet > tel_client.com.38060: R 0:0(0) ack 3774957991 win 0

В этом ответе хоста myhost.com номер подтверждения равен 3774957991, что на единицу больше значения последовательного номера из SYN-пакета. Таким образом, сервер подтвердил получение запроса и сообщил номер следующего ожидаемого байта данных. Однако символ R указывает на установленный флаг RESET - флаг разрыва соединения, так как myhost .com не прослушивает порт службы telnet. От клиента tel_client. com никакого ответа не ожидается.

Хост-получатель не существует

Что произойдет, если попытаться установить telnet-соединение с несуществующим хостом? Рассмотрим следующий пример. Зачастую, если хосты не могут ответить самостоятельно, за них отвечают маршрутизаторы. В данном случае маршрутизатор подсети (router.com), в которой должен работать хост myhost. com, с помощью ICMP-сообщения уведомляет клиента о недостижимости запрошенного хоста.

Воздействие:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)

Хост myhost. com не существует.

Реакция:

router.com > tel_client.com: icmp: host myhost.com unreachable

Предполагается, что IP-адрес хоста myhost. com зарегистрирован в системе DNS, но он больше недействителен, или хост временно не работает в силу неизвестных причин, или он неверно настроен и не может ответить на Запрос. Маршрутизатор router.com уведомляет отправителя о невозможности доставить сообщение указанному хосту.

Порт получателя заблокирован

Рассмотрим еще возможный вариант. Что если фильтрующий маршрутизатор блокирует запросы к порту службы telnet? Каким будет ответ? В этом случае маршрутизатор router. com снова уведомляет о недостижимости хоста и с помощью

ICMP-сообщения admin prohibited filter указывает причину - блокирование доступа. И в этом, и в предыдущем случае, указывая причину проблем, маршрутизатор оказывает информационные услуги, но при этом предоставляется ценная информация, особенно полезная хакеру при зондировании сети. Как уже говорилось в главе 4, “Протокол ICMP”, маршрутизатору Cisco можно запретить выдавать подобные уведомления, активизировав правило no ip unreachable в его списке контроля доступа для нужного интерфейса. Это позволит ограничить объем информации, разглашаемой маршрутизатором.

Воздействие:

tel_client.com.38060 > myhost.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)

На заблокированный запрос к службе telnet отвечает маршрутизатор. Реакция:

router.com > tel_client.com: icmp: myhost.com unreachable - admin prohibited ^ filter

Порт получателя заблокирован, маршрутизатор не отвечает

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

Воздействие:

17:14:18.726864 tel_client.com.38060 > myhost.com.telnet: S ^3774957990:3774957990(0) win 8760 <mss 1460> (DF)

Маршрутизатор не отвечает на заблокированный запрос к службе telnet. Реакция:

17:14:21.781140 tel_client.com.38060 > myhost.com.telnet: S ^>3774957990:3774957990(0) win 8760 <mss 1460> (DF)

17:14:27.776662 tel_client.com.38060 > myhost.com.telnet: S ^3774957990:3774957990(0) win 8760 <mss 1460> (DF)

17:14:39.775929 tel_client.com.38060 > myhost.com.telnet: S ^>3774957990:3774957990(0) win 8760 <mss 1460> (DF)

Тема повторных запросов более подробно рассмотрена в главе 9, “Анализ заголовков вложенных пакетов”.

Воздействие-реакция при UDP-трафике

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

Хост-получатель ожидает запросов к указанному порту

В следующем примере отчета TCPdump хост nslookip. com организует DNS-запрос к порту domain хоста myhost. com. В главе 6, “DNS”, подобные отчеты о DNS-запросах рассмотрены более подробно. Идентификационный номер DNS-сообщения (51007) используется для установления соответствий запросов ответам. Хост myhost. com получает запрос и отвечает на него, возвращая на порт domain (53) хоста nslookip. com пакет, идентификационный номер которого тоже равен 51007. Обозначение 1/0/0 в отчете TCPdump указывает, что: возвращается одна запись из базы данных DNS без единой записи о подтверждении полномочий, и нет никаких других записей. Как и в случае с протоколом TCP, здесь клиентом используется временный порт 45070, а также стандартный порт службы DNS-сервера. При ответе хоста myhost. com используются именно эти порты.

Воздействие:

nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF)

На хосте myhost. com запущена служба DNS, поэтому он отвечает на запрос. Реакция:

myhost.com.domain > nslookup.com.45070: 51007 1/0/0 (193) (DF)

Хост-получатель не прослушивает запрашиваемый порт

В следующем отчете TCPdump myhost. com отвечает ICMP-сообщением о недостижимости UDP-порта domain. Еще раз напомним, что предоставление таких ответов позволяет выявлять запущенные на компьютере службы. В данном случае лишнюю информацию предоставляет сам хост, а не маршрутизатор.

Воздействие:

nslookup.com.45070 > myhost.com.domain: 51007+ (31) (DF)

На хосте myhost. com не запущена служба domain, поэтому он отвечает на запрос ICMP-уведомением.

Реакция:

myhost.com > nslookup.com: icmp: myhost.com udp port domain unreachable

В главе 9, “Анализ заголовков вложенных пакетов”, рассказано, как программа nmap выполняет сканирование открытых UDP-портов. Вывод о работе службы на том или ином UDP-порту делается на основе отсутствия ICMP-сообщений “port unreachable”. Такой метод иногда называют “сканированием от обратного”, так как нет никаких прямых доказательств работы служб на этих портах.

В отличие от TCP-служб, которые отвечают на полученный запрос пакетом с установленными флагами SYN и АСК, большинство UDP-служб не предоставят никакого ответа на простой запрос. Например, на предыдущий DNS-запрос к UDP-порту 53 ответ был получен только из-за того, что взаимодействие осуществлялось выше уровня протокола- на уровне приложений. Стандартный DNS-запрос можно определить по полезной нагрузке дейтаграммы. При сканировании UDP-портов с помощью nmap полезная нагрузка равна 0 байт, и поэтому взаимодействие на уровне приложений невозможно.

Воздействие-реакция при ICMP-трафике

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

■ ICMP не использует портов для взаимодействия;

■ ICMP позволяет одностороннюю передачу сообщений об ошибках, при этом ответов не требуется;

■ ICMP-сообщение может быть запросом, на который требуется ответ.

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

Windows-команда tracert

В команде tracert пары эхо-запросов и эхо ответов ICMP (ping) используются для определения IP-адресов маршрутизаторов, участвующих в процессе доставки дейтаграммы на пути к получателю. Рассмотрим пример выполнения этой команды.

tracert target.my.com

Tracing route to target.my.com [1.2.3.1] over a maximum of 3 0 hops:

1 129 ms 126 ms 130 ms router.my.com [1.2.3.1]

1 229 ms 124 ms 118 ms target.my.com [1.2.3.1]

trace complete

С помощью команды tracert можно узнать промежуточные маршрутизаторы, через которые передается эхо-запрос ICMP. В этом примере есть только один такой маршрутизатор (router.my.com). Затем сообщение достигает хоста-получателя target. my. com.

Каждый маршрутизатор и хост-получатель получают по три отдельных эхо-запроса. Результат выполнения команды содержит время кругового обращения (туда и обратно) каждой из этих дейтаграмм. Например, на получение эхо-ответов для трех первых эхо-запросов, отправленных маршрутизатору router.my.com, потребовалось 129, 126 и 130 мс. Трехкратное повторение эхо-запросов к маршрутизатору или хосту выполняется на случай возможной потери эхо-запросов. Затем эхо-запросы отправляются на хост target.my.com.

Отчет TCPdump о работе tracert

Ниже представлен отчет TCPdump о выполнении предыдущей команды tracert.

tracer.net > target.my.com: icmp: echo request [ttl 1] router.my.com > tracer.net: icmp: time exceeded in-transit tracer.net > target.my.com: icmp: echo request [ttl 1] router.my.com > tracer.net: icmp: time exceeded in-transit tracer.net > target.my.com: icmp: echo request [ttl 1] router.my.com > tracer.net: icmp: time exceeded in-transit

tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF) tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF) tracer.net > target.my.com: icmp: echo request target.my.com > tracer.net: icmp: echo reply (DF)

Первый отправленный с помощью tracert эхо-запрос передается в IP-дейтаграмме, значение поля TTL которой равняется 1. Значение поля TTL уменьшается на единицу при прохождении дейтаграммой каждого сетевого устройства, благодаря чему пакеты не могут вечно передаваться по Internet и будут отброшены, когда это значение Станет равным 0. Маршрутизатор, который отбрасывает пакет, уведомляет об этом отправителя с помощью сообщения “time exceeded in-transit”.

В нашем примере, получив дейтаграмму со значением поля TTL, равным 1, и уменьшив его до 0, маршрутизатор router. my. com уведомляет хост-отправитель об уничтожении пакета.

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

По умолчанию команда tracert отправляет по три эхо-запроса для каждого хоста на пути к получателю с целью повышения надежности при возможных потерях ICMP-сообщений. Посмотрим на отчет: хост tracer.net отправляет эхо-запрос хосту target.my.com. Мгновенно хост router .my. сот уведомляет об истечении времени жизни этого пакета. Это повторяется для всех трех первых эхо-запросов ICMP. Затем хост tracer. net увеличивает значение поля TTL до 2, что позволяет передать пакет адресату - target .my. com. По умолчанию в отчете TCPdump значение поля TTL выводится только в том случае, когда для передающегося пакета оно равно 1. Хост target .my.com на полученные эхо-запросы возвращает эхо-ответы. Для того чтобы в отчетах TCPdump всегда указывалось значение поля TTL, в командной строке запуска этой программы следует указать параметр - w.

Отклонения в работе протоколов

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

В частности, будут рассмотрены протокол FTP и программа Traceroute. Необычность работы FTP заключается в том, что этот протокол во время соединения использует один временный и один стандартный порт сервера. Программа Traceroute отличается объединением возможностей протоколов ICMP и UDP при выявлении IP-адресов промежуточных маршрутизаторов на пути доставки сообщения.

FTP

При использовании протокола TCP для установки соединения клиентом и сервером используются два порта. Клиент обычно использует временный порт, номер которого больше 1023, а сервер прослушивает стандартный привилегированный порт. Оставшееся время сеанса после установки TCP-соединения клиент и сервер взаимодействуют только через эти выбранные порты. Службы FTP отличаются от TCP-служб, так как при соединении используются два различных порта сервера. Первый из них - это порт 21, стандартный порт для канала команд FTP. Второй порт используется для передачи FTP-данных между клиентом и сервером. Номер этого порта зависит от того, какой режим (активный или пассивный) используется для канала данных FTP.

Активный режим канала данных FTP

При активном режиме канала данных порт для передачи данных открывает сам FTP-сервер (для передачи команд в любом случае используется порт 21, например для команд получения или сохранения файла). В активном режиме канала данных на сервере для обмена данными открывается порт 20. В качестве данных клиенту может передаваться файл или список файлов определенного каталога.

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

Установка FTP-сеанса:

ftp.client.com.35955 > ftp.server.com.21: S 1884312222:1884312222(0) ftp.server.com.21 > ftp.client.com.35955: S 3113925437:3113925437(0)

^ ack 1884312223

ftp.client.com.35955 > ftp.server.com.21: . ack 1

ftp.server.com.21 > ftp.client.com.35955: P 1:24(23) ack 1 ftp.client.com.3 5955 > ftp.server.com.21: . ack 24

Пользователь применяет команду dir:

ftp.server.com.2 0 > ftp.dient.com.35956: S 3558632705: 3 558632705(0) ftp.Client.com.3 5 956 > ftp.server.com.2 0: S 1901007864:1901007864(0)

'З* ack 3558632706

ftp.server.com.2 0 > ftp.dient.com.35956: . ack 1

В приведенном выше примере FTP-соединение устанавливается между хостом ftp.client.com (временный порт 35955) и сервером (порт 21). Проводится полная процедура установки соединения, а затем передаются определенные данные (как правило, приветственное сообщение). Это стандартный механизм работы ТСР-службы.

Затем пользователь вызывает FTP-команду dir, запрашивая с ее помощью список каталогов сервера. С порта 2 0 сервера устанавливается новое соединение к временному порту 35956 клиента. Хотя этого и не показано в отчете, но клиент с помощью команды port предварительно проинформировал сервер, что он будет ожидать получения запросов на временный порт 35956. После завершения этой новой процедуры установки соединения ftp.server.com может отправлять данные клиенту ftp.client.com. Следующие операции обмена данными потребуют установки новых соединений и привязки к новым временным портам. Этот режим называется актшным, так как передачу данных клиенту инициирует FTP-сервер. Несложно понять, что такой метод вызывает проблемы для устройств фильтрации пакетов, которые должны пропускать весь трафик, поступающий из порта отправителя 20. Пассивный режим канала данных позволяет избежать этих проблем за счет инициирования процесса передачи данных со стороны клиента.

Пассивный режим канала данных FTP

Пассивный и активный режимы канала данных FTP отличаются методом установки соединения для передачи данных. В пассивном режиме для канала команд устанавливается подключение к тому же 21 порту FTP-сервера. Но при активном режиме для возможности передачи данных устройство фильтрации пакетов должно пропускать внешние SYN-пакеты с указанным портом отправителя 20. Эти SYN-пакеты отправляются на временный порт системы (с номером выше 1023), которую защищает фильтр пакетов. Как закрыть этот канал доступа для хакера? В конце концов, фильтр пакетов не в состоянии исследовать содержимое каждого пакета, передаваемого по этому каналу, и невозможно гарантировать, что это действительно FTP-трафик.

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

ftp.client.com.44890 > ftp.server2.com.21: S 42 76284 026:42762 8402 6(0) win 8760 <mss 1380> (DF) ftp.server2.com.21 > ftp.client.com.44890: S 166 963 026 0:166963 0260(0)

’Ь ack 4276284027 win 8280 cmss 1460> (DF)

ftp.client.com.44 8 90 > ftp.server2.com.21: . ack 1 win 9660 (DF)

Пользователь выдает команду dir:

ftp.Client.com.44891 > ftp.server2.COm.3967: S 4282611109:4282611109(0) win 8760 cmss 1380> (DF) ftp.server2.com.3 967 > ftp.client.com.44891: S 16697688 08:1669768 808(0)

4> ack 4282611110 win 8280 cmss 1460> (DF)

ftp.client.com.44891 > ftp.server2.com.3 967: . ack 1 win 9660 (DF)

Когда на хосте ftp. client. com выполняется команда dir, должен быть установлен канал передачи данных. Хоть этого и не показано в отчете TCPdump, но сервер ftp.server2 .com с помощью команды port информирует клиента о том, что он ожидает запросов на порт 3 967. Клиент отправляет на этот порт SYN-пакет, а сервер отвечает пакетом с установленными флагами SYN и АСК. По этому каналу передается запрошенный список каталогов сервера. Так как клиент сам организовал исходящее соединение к серверу, то устройство фильтрации пакетов может разрешить прием ответной информации от сервера со сравнительно большой уверенностью в “безопасности” соединения. Такой метод менее рискован, чем разрешение поступления любых данных с порта получателя 20.

Traceroute

UNIX-программа Traceroute использует возможности протоколов UDP и ICMP для определения ІР-адресов хостов, которые участвуют в процессе передачи дейтаграммы заданному адресату. Промежуточные маршрутизаторы, как и в Tracert, выявляются с помощью отправки дейтаграмм с увеличивающимся на 1 значением поля TTL (когда TTL становится равным 0, они возвращают ICMP-сообщение “time-exceeded in transit”), пока не будет достигнут хост назначения. UDP-порт получателя обычно выбирается из диапазона 33000-33999 - один из тех портов, которые почти наверняка не используются никакими службами. Это делается с целью получения ICMP-сообщения о недостижимости порта, что служит для Traceroute сигналом о доставке пакета на хост-получатель. В Traceroute по умолчанию также отправляется по три пакета каждому промежуточному маршрутизатору и конечному хосту. В следующем примере для упрощения этот режим заменен отправкой только одного сообщения.

tracer.com.62615 > target.com.33456: udp 12 (DF) [ttll] router.com > tracer.com: icmp: time exceeded in-transit [tos OxcO]

tracer.com.62 615 > target.com.33457: udp 12 (DF)

target.com > tracer.com: icmp: target.com udp port 33457 unreachable (DF)

В приведенном выше отчете хост tracer . com отправляет UDP-пакет на порт 33456 хоста target. com. Значение поля TTL первой отправленной дейтаграммы равно 1, маршрутизатор router . com уменьшает его до 0 и возвращает отправителю сообщение time exceeded in-transit. Затем хост tracer.com отправляет следующую дейтаграмму, при этом порт получателя меняется на 3 3457, а значение поля TTL становится равным 2. Новая дейтаграмма проходит через первый маршрутизатор и достигает получателя target. com, который возвращает ICMP-сообщение о недостижимости своего порта 33457.

Следует заметить, что обе программы - и Traceroute, и Tracert - будут работать только при разрешении возвращения входящих ICMP-сообщений в сеть хоста-отправителя. Возникает вопрос: следует ли разрешать поступление в локальную сеть ICMP-сообщений, используемых при работе этих программ? Это зависит от принятой политики безопасности. На самых защищенных узлах, доступ к которым должен быть максимально ограничен, такое решение не приветствуется. Вероятная опасность превосходит возможные преимущества, так как ICMP-сообщения могут использоваться и хакерами для проведения атак (см. главу 4, “Протокол ICMP”, раздел “Программа Loki”).

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

Аномальные действия

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

Незаметное воздействие, отсутствие ответа

В следующем отчете TCPdump зарегистрирован процесс сканирования портов хоста victim.org, выполняемый с помощью пакетов с установленным флагом

FIN. Это скрытое сканирование, которое проводится с хоста stealthy, com, позволяет определить работающие службы удаленного хоста. Согласно RFC 793 при получении такого пакета открытый порт (на который ожидает запросов запущенная служба) отвечать не должен, а закрытый обязан вернуть пакет с установ ленными флагами RESET и АСК.

stealthy.com.50141 > victim.org.5: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.3: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.26: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.45: F 0:0(0) _win 4096 (DF)

stealthy.com.50141 > victim.org.17: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.7: F 0:0(0) win 4096 (DF) stealthy.com.50141 > victim.org.51: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.52: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.30: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.53: F 0:0(0) win 4096 (DF)

stealthy.com.50141 > victim.org.20: F 0:0(0) win 4096 (DF)

Некоторые системы обнаружения вторжений не реагируют на FIN-пакеты, поэтому данное сканирование можно назвать более замаскированным, чем сканирование с помощью SYN-пакетов для установки соединения. Раньше для выявления открытых портов использовались только SYN-па'кеты, и в разработанных в то время системах обнаружения вторжений контролируются именно такие попытки сканирования. Хакеры быстро поняли, как их обнаруживают, и придумали новый способ сканирования. Для выполнения этого скрытого сканирования с помощью FIN-пакетов была использована команда nmap -sF victim.org.

Вредоносное воздействие, фатальная реакция

Атаки отказа в обслуживании (DoS) приводят к чрезмерным тратам ресурсов атакованного компьютера, в результате чего он не в состоянии выполнять свои функции. Существует множество различных вариантов DoS-атак. Программа JoIt2 позволяет заблокировать работу удаленного компьютера за счет непроизводительного расходования ресурсов оперативной памяти. Рассмотрим отчет о проведении этой атаки.

10:48:56.848099 Verbo.com > win98.com: (frag 1109 :9@65520)

10:48:56.848099 Verbo.com > win98.com: (frag 1109:9®65520)

10:48:56.848295 verbo.com > win98.com: (frag 1109 :9@65520)

10:48:56.848295 verbo.com > win98.com: (frag 1109 :9@65520)

10:48:56.848351 verbo.com > win98.com: (frag 1109:9@65520)

10:48:56.848351 verbo.com > win98.com: (frag 1109 :9@65520)

10:48:56.848420 verbo.com > win98.com: (frag 1109 :9@65520)

10:48:56.848420 verbo. com > win98.COm-. (frag 1109:9065520)

10:48:56.848584 verbo.com > win98.com: (frag 1109 :9@65520)

Программа Jolt2 отправляет бесконечный поток эхо-запросов ICMP (ICMP используется по умолчанию, могут применяться пакеты других протоколов) на атакуемый хост под управлением Windows. Эти запросы отправляются как фрагменты с одинаковым идентификатором фрагмента с повторяющимся ненулевым смещением фрагмента.

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

Windows NT и Windows 2000 при попытке обработать последовательность фрагментов возникает проблема при отсутствии первого фрагмента со смещением 0. Атакованный хост не в состоянии выполнить сборку пакета, растет потребление оперативной памяти, что приводит к отказу в обслуживании.

Из отчета TCPdump можно узнать, что хост verbo. com отправляет какие-то пакеты хосту win98 . com. При этом идентификатор фрагментов остается постоянным, их длина составляет 9 байт, а смещение равно 65520. Последнее значение установлено в исходном коде программы JoIt2. Это значение очень близко к предельному значению 65535 байт, поэтому вначале думали, что именно оно позволяет провести успешную атаку. Однако после уменьшения этого значения в исходном коде программы Jolt2 и ее перекомпиляции отказ в обслуживании все равно наблюдался.

Чтобы проверять возможность ответов хоста win98 . com до и во время атаки Jolt2, с хоста хакера verbo. com время от времени отправляются ping-запросы. В нашем случае после запуска Jolt2 отказ в обслуживании произошел практически мгновенно. Хост win98 .com не отвечал ни на внешние запросы, ни на команды с клавиатуры. После прекращения атаки он возобновил свою работу без перезагрузки.

Причины сканирования

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

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

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

Воздействие отсутствует, реагируют все

В центре внимания этого раздела находится подмена IP-адресов (более подробная информация содержится в приложении А, “Программы атаки и методы сканирования”). В следующем отчете TCPdump хосты сети 1.2 получают ICMP-сообщения “time exceeded in-transit”, т.е. уведомления об истечении срока жизни отправленных этими хостами дейтаграмм. Таким образом, хосты сети 1.2 должны были отправить какой-то тарфик, который вызвал ответную реакцию. Но это не так. Никакого исходящего трафика не зафиксировано.

router.com > 1.2.10.72: icmp: time exceeded in-transit

router.com > 1.2.18.13: icmp: time exceeded in-transit

router.com > 1.2.11.67: icmp: time exceeded in-transit

router.com > 1.2.16.13: icmp: time exceeded in-transit router.com > 1.2.19.1: icmp: time exceeded in-transit router.com > 1.2.1.252: icmp: time exceeded in-transit

router.com > 1.2.13.56: icmp: time exceeded in-transit

router.com > 1.2.143.6: icmp: time exceeded in-transit

router.com > 1.2.13.15: icmp: time exceeded in-transit

Как можно объяснить появление этого трафика? Все очень просто: кто-то подменил IP-адрес хостов своей сети на IP-адреса хостов сети 1.2.0 мотиве создания оригинальных запросов можно только догадываться, но, скорее всего, осуществляется наводнение пакетами или проводится разведка чужой сети.

А не выполняет ли сам хост router. com разведывательных действий по отношению к хостам сети 1.2? Может ли полученный трафик вызывать какие-либо ответы если не локальных хостов, то хотя бы маршрутизатора? Дело в том, что в данном случае передаются ICMP-сообщения об ошибке, а согласно RFC 1122 ICMP-сообщение об ошибке не может послужить причиной отправки другого ICMP-сообщения, так как это может привести к созданию замкнутого цикла обмена сообщениями об ошибке. Поскольку ни один другой протокол не ответит на ICMP-трафик, то предположение о подмене IP-адреса кажется наиболее логичным.

I Обратное рассеяние атак

О случаях, подобных приведенному в этом разделе, было сделано очень интересное исследование. Авторы назвали подобные случаи примерами обратного рассеяния атак (backscatter). На протяжении длительного периода времени исследовалась работа в Internet сети класса А. Атаки обратного рассеяния определялись по получению незапрошенных ответных пакетов различных протоколов. При этом считалось, что данная ситуация возникла в результате подмены IP-адресов хостов контролируемой сети. На основе собранных данных были определены количество и типы атак, проведенных в Internet за ограниченный период времени. Высокая частота и разнообразие этих атак оказались весьма впечатляющими. Статью “Inferring Internet Denial-of-Service Activity” (“Исследование о проводимых в Internet атаках отказа в обслуживании”) можно прочесть по адресу www.cs.ucsd.edu/-savage/papers/UsenixSec01.pdf.

Нестандартное воздействие, идентифицирующий ответ

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

Знание операционной системы удаленного хоста позволяет хакерам подобрать соответствующие программы атаки, поэтому раскрытие этой информации несет потенциальную угрозу. Некоторые узлы настолько открыты, что о типе и версии используемой на них операционной системы можно узнать по идентификационным маркерам (banner) службы telnet или FTP. Конечно, эта информация предоставляется не всегда, а иногда она не соответствует действительности. В каждой операционной системе реализация стека протоколов TCP/IP имеет некоторые отличия. Если хакер отправляет специально подготовленные пакеты и знает, какие характерные признаки следует искать в полученных ответах, то он сможет, например, отличить Linux от Solaris, иногда даже без какой-либо дополнительной разведки.

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

■ Отправка FIN-пакета на открытый порт. Согласно стандарту RFC 793 для всех открытых портов ответ должен отсутствовать, но некоторые хосты отправляют пакет с установленным флагом RESET. Этот метод также позволяет провести скрытое сканирование портов.

■ Фальсификация значений “зарезервированных” TCP-флагов. Программа nmap проверяет, сбросит ли (установит равными 0) операционная система удаленного хоста значения битов несуществующих флагов.

■ Некорректные комбинации TCP-флагов. Большинство хостов не отвечают при получении пакетов с нестандартной комбинацией TCP-флагов, но по ответам немногих отвечающих хостов можно точно определить операционную систему.

■ Отправка NULL-пакета (без установленных флагов).

Фиктивные ТСР-флаги

Одним из способов получения данных для идентификации операционной системы является отправка пакета с фиктивными значениями TCP-флагов. Байт ТСР-флагов содержит информацию обо всех установленных в пакете ТСР-флагах (рис. 5.1). По этим флагам определяется назначение конкретного ТСР-сегмента. Так как TCP-флагов существует всего шесть, то в байте TCP-флагов остается 2 свободных бита. До изобретения явного уведомления о перегрузке (Explicit Congestion Notification - ECN) значение этих старших битов предполагалось равным 0.

Рис. 5.1. Вайт ТСР<ряагов

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

Байт состоит из двух шестнадцатеричных символов, или полубайтов (nibbles). Младший полубайт содержит биты, определяющие установку флагов PUSH, RESET, SYN и FIN. Теперь рассмотрим значения зарезервированных битов старшего полубайта. С помощью присвоения значений этим битам несуществующих флагов программа nmap осуществляет тестирование удаленных хостов. Если значение старшего полубайта превышает 3, значит, значение присвоено одному или обоим зарезервированным битам. Значение 3 получается следующим образом: установка флага АСК дает значение 2°=1, а флага URG - значение 2'=2. Сумма этих значений равняется 3. Поэтому любое значение старшего полубайта байта ТСР-флагов свидетельствует о нестандартной ситуации.

В приведенном ниже отчете TCPdump представлена попытка узнать с помощью nmap характерные особенности стека TCP/IP на удаленном хосте target.com и таким образом определить его операционную систему. При попытке организовать рассматриваемое соединение установлен один из несуществующих ТСР-флагов (конкретно тот, что на схеме слева от бита URG). Вначале показана строка стандартного отчета TCPdump, из которой нельзя ничего узнать об установке несуществующих флагов. Следующий отчет в шестнадцатеричном формате позволяет получить значения всех полей, включая и значение поля байта ТСР-флагов.

scanner.com.44388 > target.com.domain: S 403915838:403915838(0) -win 4096 'bcwscale 10,nop,mss 265, timestamp 1061109567 0, eol> (DF)

[4500 003c 7542 4000 3b06 15bd 0102 0304 0102 0305] ad64 0035 1813 443e 0000 0000 a042 1000 fa4c 0000 0303 OaOl 0204 0109

080a 3f3f 3f3f 0000 0000 0000

В последнем отчете первые 20 байт заголовка IP-дейтаграммы заключены в квадратные скобки. Затем следует TCP-заголовок и любые данные. Байт ТСР-

флагов - это 13-й байт в TCP-заголовке. В шестнадцатеричном формате его значение составляет 42, при этом значение полубайта высшего порядка больше 3 (равно 4), что означает установку значения для зарезервированного бита. Нарушитель надеется, что ответ на такой пакет с фиктивным TCP-флагом позволит идентифицировать операционную систему удаленного хоста.

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

target.com.domain > scanner.com.443 88: S 4154976859:4154976859(0)

ack 403915839 win 8855 < nop, nop,timestamp 16912287 1061109567,nop,wscale 0, tmss 265> (DF)

[4500 003c e04e 4000 ff06 e6af 83da d684 83da d683] 0035 ad64 f7a7 ea5b 1813 443f a012 2297 fd3f 0000 0101 080a 0102 0f9f

3f3f 3f3f 0103 0300 0204 0109

Таким образом, хост target. com отвечает на полученный пакет с фиктивным TCP-флагом пакетом с установленными флагами SYN/ACK. Это нормально, и кажется, что исследуемый хост никак не прореагировал на присутствие фиктивного флага. Как это проверить? Отчет о проведенной транзакции в шестнадцатеричном формате показывает, что в байте ТСР-флагов установлены флаги SYN и АСК

(выделенное жирным шрифтом шестнадцатеричное значение 12). Бит АСК- это младший бит старшего полубайта, поэтому его значение равно 1. Значение 2 младшего полубайта указывает на присвоение значения второму справа биту (флаг SYN). Следовательно, в ответе фиктивный флаг сброшен. Другая операционная система может оставить без изменений значение бита фиктивного флага.

Некорректные комбинации ТСР-флагов

В стандарте RFC 793 установка и возможные комбинации ТСР-флагов определены довольно жестко. Стеки протоколов TCP/IP большинства операционных систем выполняют требования этой спецификации. Но существует и несколько исключений из правила, благодаря чему можно выявить такие операционные системы. Рассмотрим следующий отчет TCPdump о работе программы nmap в режиме определения операционной системы удаленного хоста (запускается с помощью параметра командной строки -О).

Nmap -о win 98

20:33:16.409759 verbo.47322 > Win98.netbios-ssn: SFP 861966446:861966446(0)

'bwin 3072 urg 0 <wscale 10,nop,mss 265, timestamp 1061109567[tcp] 20:33:16.410387 Win98.netbios-ssn > verbo.47322: S 49904150: 49904150(0) ^ack 861966447 win 8215 <mss 1460> (DF)

Сканирующий хост отправляет пакет с установленным набором флагов SYN, FIN и PUSH. Очевидно, что такой набор флагов является некорректным, так как флаг SYN служит для установки соединения, флаг FIN - для его разрыва, а флаг PUSH - для отправки данных при установленном соединении. Естественным ответом на получение подобного бессмысленного пакета кажется его игнорирование или возврат пакета с флагом RESET. Однако в данном случае хост win98 под управлением операционной системы Windows 98 интерпретирует полученный пакет как запрос на соединение и возвращает пакет с установленными флагами SYN и АСК. Этот уникальный ответ позволяет точно определить тип операционной системы хоста win98.

TCP-сегмент без установленных флагов

В следующем отчете TCPdump представлен еще один пример определения операционной системы удаленного хоста. В данном случае используется ТСР-сегмент без установленных флагов (так называемый NULL-пакет).

scanner.com.44389 > target.com.domain: . win 4096 <wscale 10,nop,mss 265, b timestamp 1061109567 0, eol> (DF)

[4500 003c 7543 4000 3b06 15bc 0102 0304 0102 0305] ad65 0035 1813 443e 0000 0000 aOOO 1000 fa8d 0000 0303 OaOl 0204 0109 080a 3f3f 3f3f 0000 0000 0000

Рассмотрим отчет в шестнадцатеричном формате. Значение поля байта ТСР-флагов выделено жирным шрифтом (00). Следовательно, не установлено ни одного флага. Большинство хостов не отвечают на NULL-пакет, но находятся отдельные экземпляры, для выявления которых и проводится сканирование данного типа.

В нормальном TCP-пакете установлен по крайней мере один флаг. Хост не отвечает на переданный ему NULL-пакет. И даже отсутствие ответа дает подсказку о типе операционной системы этого хоста, потому что хосты под управлением других операционных систем могут реагировать иначе, например возвратом пакета с установленным флагом RESET.

Использование параметров TCP

При анализе приведенного ниже отчета TCPdump о сканировании с помощью программы nmap сконцентрируем внимание на выделенных жирным шрифтом параметрах TCP. scanner.com.44388 > target.com.domain: S 403915838:403915838(0) win 4096 ewscale 10,nop,mss 265,timestamp 1061109567 0, eol> (DF)

target.com.domain > scanner.com.44388: S 4154976859:4154976859(0)

'Ь ack 403915839 win 8855 < nop, nop,timestamp 16912287 1061109567,nop,wscale 0,

4>mss 265> (DF)

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

К тому же различные операционные системы устанавливают эти параметры в заголовке ТСР-сегмента в различном порядке. Вся эта информация может быть использована для определения операционных систем удаленных хостов. Как видно из предыдущего примера, в ответе изменились порядок и значения некоторых параметров (например, значение wscale изменилось с 10 на 0). Обратите внимание на то, что параметры пор и eol поменялись местами или вообще пропали. Эти поля используются для дополнения размера TCP-параметров до 4-.байтового значения и в ответе могут не потребоваться.

Более подробно значение TCP-параметров описано в RFC 1323. Здесь рассмотрены только некоторые из них.

■ -wscale. Позволяет увеличить размер окна до значения выше 65535 байт. Как правило, этот параметр применяется для увеличения производительности работы протокола TCP в сетях с высокой пропускной способностью и большими задержками.

■ -timestamp. Этот параметр позволяет сохранить время кругового обращения пакетов, что зачастую необходимо для оптимизации производительности при изменениях в сети.

■ -пор. Используется для добавления 1 байт к TCP-параметрам, размер которых должен составлять не менее 4 байт.

■ -eol. Параметр конца списка (end-of-list) применяется для дополнения последнего байта до минимального размера в 4 байт.

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

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

Резюме

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

В теории “воздействие-реакция” есть один очень важный момент. При появлении любого подозрительного трафика делается вывод об атаке со стороны компьютера-отправителя. Я рекомендую немного подумать перед автоматическим принятием этого решения. Нет сомнений, очень часто такое предположение будет правильным. Но не исключено, что этот трафик является следствием другого постороннего воздействия, и его появление связано, например, с подменой хакером вашего 1Р-адреса.

И, наоборот, при получении каких-либо ответов, например незатребованных эхо-ответов ICMP, весьма вероятно, что хост-отправитель этого трафика выполняет атакующие действия. Как изложено в главе 4, “Протокол ICMP”, при атаке TFN эхо-ответы ICMP используются в качестве средства связи между хозяином и демоном для запуска или управления распределенной атакой отказа в обслуживании. Если возникают какие-то сомнения о предназначении получаемого трафика, то лучше всего тщательно исследовать всю сохраненную дейтаграмму и проанализировать содержимое отдельных полей заголовка и данные. При анализе сетевого трафика никогда не стоит действовать на основе одних только предположений.

Протокол icmp | Обнаружение нарушений безопасности в сетях | Dns


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июнь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс