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

Фильтры для исследования ТСР-флагов

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

Рис. 12.5. Байт ТСР-флагов

Байт ТСР-флагов является 13-м байтом ТСР-заголовка. Для обнаружения конкретных флагов, установленных в этом байте, придется выполнить маскировки. Начнем с создания фильтра для обнаружения пакетов с единственным установленным флагом SYN. tcp[13] & Oxff = 2

Почему фильтр выглядит именно так? Очевидно, что маска состоит из одних единиц. А почему не применить маску, которая содержит нули во всех полях, кроме поля для флага SYN (tcp [13 ] & 0x02 = 2)? Если маскировать значение бита с помощью 0, то результатом всегда будет 0. Значением исходного бита может быть 1, и маска отбросит это значение. Поясним это на примере.

Предположим, нужно отобрать из общего трафика TCP-сегменты, в которых установлен только флаг SYN. Теперь представим, что в байте ТСР-флагов установлены флаги АСК и SYN. Двоичным значением такого байта будет 0001 0010. Если это значение маскировать с помощью маски 0000 0010, то конечным результатом будет 0000 0010 или 2. Таким образом, маскирование с помощью нулей всех полей байта ТСР-флагов, кроме поля флага SYN, приводит к выбору TCPdump “лишних” TCP-сегментов, а не только искомых пакетов с установленным флагом SYN. Поэтому и необходимо использовать приведенный выше фильтр и сохранять все исходные установленные флаги. Если полученный результат будет отличаться от 2, то это означает, что установлены дополнительные (кроме SYN) флаги. Например, если будет установлен бит АСК, то результатом маскирования будет значение 18.

Поскольку нам необходимо отобрать только те сегменты, в которых установлен один флаг SYN, то наиболее простым фильтром для этой цели может послужить следующий, tcp [13] =2

Этот фильтр позволяет гарантировать, что будут выбираться только ТСР-сегменты с установленным флагом SYN, потому что, если будет установлен любой другой флаг, то результат сложения всех битов байта ТСР-флагов будет отличаться от 2. Например, представим, что в байте ТСР-флагов установлен нестандартный набор флагов: SYN и URG. Если установлен флаг URG, то его позиция соответствует значению 32, флаг SYN дает значение 2. Таким образом, результатом сложения двух битов будет 34, что не соответствует фильтру.

Рассмотрим ряд других фильтров для других возможных комбинаций ТСР-флагов.

■ tcp [13] & Oxff = 0 или tcp [13] = 0. Позволяет выявить попытки сканирования с помощью null-пакетов (не установлено никаких флагов). Такие пакеты принимать не следует.

■ tcp [13] & Oxff = 3 или tcp [13] = 3. Позволяет выявить TCP-сегменты, в которых одновременно установлены флаги SYN и FIN (это явно нестандартная ситуация). Можно заменить указанный фильтр фильтром tcp [13] &

0x03 = 3, который позволит обнаружить любые пакеты с двумя установленными флагами SYN и FIN, в том числе совместно с другими флагами.

■ tcp[13] & Oxff = 0x10 and tcp[8:4] = 0. Позволяет выявить сег менты с установленным флагом АСК, и со значением номера подтверждения, равным 0. Это подозрительная ситуация, так как после проведения полной процедуры установки соединения номер подтверждения должен быть больше начального порядкового номера. Этот фильтр часто позволяет обнаружить попытки сканирования программы nmap для выявления операционных систем удаленных хостов. Программа nmap отправляет ТСР-сегменты на различные порты исследуемого хоста с одним установленным флагом АСК и значением 0 в поле номера подтверждения.

Очень редко значение 0 для номера подтверждения является нормальным. Это происходит, если отправитель передает пакет, в котором указан порядковый номер, состоящий из одних единиц (т.е. значение будет равно 2 " - 1). Тогда для следующего ожидаемого порядкового номера должно быть выполнено обнуление значения.

ш tcp [13] >= 64. Два старших бита байта ТСР-флагов считаются зарезер вированными (см. рис. 12.5). Значения этих двух битов должны равняться 0. Если это не так, то что-то неправильно. Первому биту соответствует значение 2Ь (64), а второму - 2' (128). Если один или оба бита установлены, то значение байта ТСР-флагов будет равняться или превышать 64. Наша старая знакомая, программа nmap, часто устанавливает бит в позиции значения 64 при сканировании операционных систем. Большинство хостов сбрасывают эти установленные значения в 0, но некоторые операционные системы оставляют этот бит без изменений.

Не так давно эти старшие биты байта ТСР-флагов стали использоваться для уведомления о перегрузке (ECN) с целью улучшить работу в сети. Как можно отличить нормальный трафик с ECN-битами от попыток сканирования nmap? При использовании в ТСР-сегменте ECN-битов для уведомления о перегрузке поле TOS (“Тип обслуживания”) должно хранить ненулевое значение, а программа nmap оставляет значение этого поля равным 0. Более подробную информацию о битах ECN можно получить в документе RFC 3168.

Мы рассмотрели только некоторые из возможных комбинаций ТСР-флагов, наличие которых можно проверять в ТСР-сегментах.

Выявление данных в SYN-пакетах

Перед тем как вы начнете самостоятельно создавать фильтры TCPdump, рассмотрим пример еще одного расширенного фильтра, использующего уже описанные в этой главе значения битов и полей, а также некоторые другие. В главе 2, “TCPdump и TCP”, мы рассказали о том, что данные не должны отправляться до завершения полной процедуры согласования параметров ТСР-соединения. Такие действия выполняет программа 3DNS, которая причиняет неудобства, но не является вредоносной. Кроме того, мы описали сканирование, которое выполнялось с помощью отправки данных в начальном SYN-пакете. Это может помешать системе обнаружить взлом, поскольку она начинает собирать поток данных только после завершения процедуры установки соединения.

Поэтому стоит создать фильтр TCPdump, который бы позволял обнаруживать передачу данных в SYN-пакете (конечно, при этом вероятны ложные тревоги, вызванные работой программы 3DNS). Проблема в том, что ни в одном поле ТСР-заголовка не хранится значение длины полезных данных ТСР-сегмента. Но есть много других полей, хранящих значения других длин. В частности, в IP-заголовке существуют поля длины всей IP-дейтаграммы и поле длины одного IP-заголовка. В ТСР-заголовке присутствует поле, в котором указана длина этого заголовка. Таким образом, если от длины всей IP-дейтагараммы отнять значения длин IP- и ТСР-заголовков, мы получим искомое значение полезных данных ТСР-сегмента (рис. 12.6).

Рис. 12.6. Вычисление длины полезной нагрузки ТСР-сегмента

Вы скажете “совсем просто”? Но следует принять во внимание ряд обстоятельств. Не забывайте, что значения разных полей указаны в различных единицах измерения: длина 1Р-дейтаграммы указана в байтах, а значения длин ІР-заголовка и ТСР-заголовка являются 32-битовыми словами. Для преобразования двух последних значений в байты их необходимо умножить на 4. Как видите, задача вполне решаемая.

Еще одной небольшой неприятностью является необходимость обращаться к значению поля длины ТСР-заголовка (рис. 12.7). Это поле занимает старший полубайт 12'ГО байта ТСР-заголовка. Для исследования значения только старшего полубайта младший полубайт придется маскировать нулями, но и это еще не все. Так как рассматривается старший полубайт, то его значение, умноженное на 16, должно быть нормализовано.

Предположим, что длина ТСР-заголовка составляет 24 байт, включая 20 байт самого заголовка и несколько ТСР-параметров. Не забывайте, что значение указано в виде 32-битовых слов, поэтому в поле длины ТСР-заголовка в этом случае будет содержаться значение 6 (нужно выполнить деление на 4). Предположим, младший полубайт уже замаскирован, и в результате шестнадцатеричное значе ние этого байта равно 60. В двоичной форме он будет выглядеть как 0110 0000. Единицы установлены в позициях 26 (64) и 2’ (32), т.е. десятичное значение составляет 96. Поскольку данное поле представляет собой старший полубайт, то его значение в 16 раз больше значения младшего полубайта, и его необходимо нормализовать, поделив на 16, а затем для получения значения в байтах умножить на 4. Только теперь можем создать наш фильтр.

Рис. 12.7. Заголовок ТСР-сегмента

Перед написанием самого фильтра давайте вспомним необходимые условия и нужную формулу.

Если установлен только один флаг SYN, вычтем из общей длины IP-дейтаграммы переведенную в байты длину IP-заголовка и нормализованную и переведенную в байты длину TCP-заголовка и убедимся, что полученное значение отличается от нуля.

Единственный установленный флаг SYN. tcp[13] & Oxff = 2 или tcp[13] = 2 Общая длина 1Р-дейтаграммы. ip [2 : 2]

Значение длины IP-заголовка, преобразованное в байты.

( ( ip [0] & 0x0f) *4 )

Нормализованное и переведенное в байты значение длины ТСР-заголовка:

((tcp[12] & OxfO)/16*4)

Это аналогично:

( (tcp [12] & OxfO) /4)

Теперь объединим все части в один фильтр.

tcp [13] & Oxff = 2 and

( 1р [2:2] -

((:1р[0] & 0x0f)*4) -

( (йср [12] & СМ0) /4)

) != 0

Этот фильтр позволяет выявить любые попытки передачи данных в 5У№ пакетах.

Резюме

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

В большинстве создаваемых фильтров ТСРс1итр используются макросы, и не требуется выполнять операцию побитового маскирования. Но, если нужно проверить отдельные биты байта, их значения нужно выделить с помощью масок. Мы также рассказали о еще одном важном моменте при создании фильтров: не забывайте переводить значения различных полей в одни единицы измерения, а точнее, в байты. Кроме того, важно учитывать положение битов в байте (для значений старшего полубайта, возможно, потребуется нормализация). Овладев техникой создания фильтров и получив возможность всесторонне исследовать поступающие пакеты, вы испытаете чувство глубокого удовлетворения.

Udp-фильтры программы tcpdump | Обнаружение нарушений безопасности в сетях | Система snort


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



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

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