Номера портов отправителя и получателя хранятся в 16-битовых полях ТСР-заголовка в 0-м и 1-м байтах (порт отправителя) и во 2-м и 3-м байтах (порт получателя) ТСР-заголовка. Возможные значения находятся в диапазоне от 1 до 65535. Использование номера порта 0 не допускается и считается “сигнатурой” неверного значения поля.

Когда отправитель хочет установить соединение с удаленным хостом, то для этой цели, как правило, выбирается один из временных портов, номер которого больше 1023. Для каждого нового соединения (за исключением повторной отправки данных) должен быть выбран другой временный порт. Правила повторной отправки данных при TCP-соединениях будут рассмотрены в разделе “Повторная передача данных”. Зачастую при сканировании значение порта отправителя увеличивается на единицу для каждого нового соединения.

Одним из явных признаков проводящегося сканирования пшар с помощью SYN-пакетов является постоянный номер порта отправителя для большого количества новых ТСР-соединений.

Nmap -sS sparky

09:40:43.964215 verbo.47247 > sparky.1548: S 2401927088:2401927088(0) win 2048

09:40:43.964412 verbo.47247 > sparky.24: S 2401927088:2401927088(0) win 2048

09:40:43.964465 verbo.47247 > sparky.1547: S 2401927088:2401927088(0) win 2048

09:40:43.964553 verbo.47247 > sparky.2564: S 2401927088:2401927088(0) win 2048

09:40:43.964604 verbo.47247 > sparky.1484: S 2401927088:2401927088(0) win 2048

09:40:43.964695 verbo.47247 > sparky.628: S 2401927088:2401927088(0) win 2048 09:40:43.964748 verbo.47247 > sparky.1112: S 2401927088:2401927088(0) win 2048

Хотя, казалось бы, номер порта отправителя хоста verbo должен был бы изменяться для каждой новой попытки установить соединение с различными портами хоста sparky, он остается постоянным (4 724 7).

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

Hping2 -S spanky

09:44:13.882207 verbo.1788 > sparky.0: S 1553132317:1553132317(0) win 512

09:44:14.876837 verbo.1789 > sparky.0: S 1894028093:1894028093(0) win 512

09:44:15.876836 verbo.1790 > sparky.0: S 2032501562:2 032501562(0) win 512

09:44:16.876832 verbo.1791 > sparky.0: S 851202745:851202745(0) win 512

Контрольная сумма TCP-заголовка

Контрольные суммы, указанные в заголовках вложенных пакетов, позволяют гарантировать целостность вложенного заголовка и данных . TCP-, UDP- или ICMP-пакета. В отличие от контрольной суммы IP-заголовка контрольные суммы вложенных пакетов проверяются только на хосте-получателе. В UDP-заголовках проверка контрольной суммы не является обязательной, но настоятельно рекомендуется.

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

Рис. 9.1. Псевдозагловок для вычисления контрольной суммы ТСР

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

Давайте рассмотрим особый случай, когда псевдозаголовок позволяет предотвратить доставку пакета по ошибочному адресу (рис. 9.2). Предположим, что есть хост, который отправляет пакет по 1Р-адресу получателя 1.2.3 .4. Для создания вложенного пакета используется протокол ТСР, но в данном примере нет принципиальной разницы в использовании протокола ТСР или 1)БР, так как в обоих протоколах применяется псевдозаголовок. При вычислении контрольной суммы заголовка транспортного протокола используются значения полей псевдозаголовка. Поэтому для вычисления контрольной суммы ТСР-заголовка использовано значение 1Р-адреса получателя 1. 2 . 3 . 4.

На пути доставки пакета к получателю он проходит через маршрутизаторы, каждый из которых должен проверить контрольную сумму 1Р-заголовка. Предположим, что один из этих маршрутизаторов проверил контрольную сумму 1Р-заголовка, уменьшил на единицу значение поля ТТЬ и должен вычислить новую контрольную сумму. По какой-то неизвестной причине на 1Р-уровне маршрутизатора 1Р-адрес получателя был изменен на 1. 2 . 3 . 5, и новая контрольная сумма 1Р-заголовка вычисляется на основе именно этого искаженного значения, а пакет передается далее по неправильному адресу получателя.

Рис. 9.2. Использование псевдозаголовка

Предположим, что адрес 1. 2 . 3 . 5 принадлежит активному хосту. Искаженный пакет доставляется по неверному адресу. Проверка хостом-получателем контрольной суммы IP-заголовка дает положительный результат, так как при ее вычислении маршрутизатором уже было использовано неверное значение. Пакет передается на транспортный уровень, где для проверки контрольной суммы используются поля псевдозаголовка. Эта проверка позволит выявить искаженный пакет, так как при подсчете исходной контрольной суммы TCP-заголовка было использовано правильное значение адреса получателя 1. 2 . 3 . 4. Полученный пакет отбрасывается хостом 1. 2 . 3 . 5.

Призыв о помощи

Из различных источников информации у меня сложилось ясное представление, что предназначением псевдозаголовка является дополнительная проверка правильности доставки пакета указанного протокола на конкретный хост. Тем не менее я не знал, как именно это делается. Я спрашивал у нескольких коллег, но так не получил точного ответа, подкрепленного наглядным примером. Закончилось тем, что я написал разработчику и специалисту в области стека протоколов TCP/IP Дугу Камеру (Doug Camer), который и пояснил мне все это на примере искажения пакета на промежуточном маршрутизаторе. Выражаю ему свою искреннюю признательность.

Порядковые номера

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

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

ТСР-сегмента (ISN) указывается в SYN-пакетах (и отправителем, и получателем), отправляемых при установке ТСР-соединения.

В различных вариантах стека TCP/IP начальные порядковые номера выбираются по разным формулам. Программа nmap использует эту особенность для определения операционных систем удаленных хостов. Совместно с программой nmap поставляется файл с сигнатурами операционных систем, которые позволяют выявить тип и версию операционной системы удаленного хоста по ответам, приходящим от этого хоста. Для получения характерных ответов программой nmap используется набор специальных тестов, и первый тест из этого набора заключается в том, что nmap проверяет порядковые номера, установленные в ответном пакете после запроса на прослушиваемый порт. В некоторых устаревших версиях операционных систем для каждого нового соединения начальные порядковые номера ТСР-сегмента изменяются в определенной последовательности. Если хакер способен прослушивать передающийся трафик, он сможет спрогнозировать и перехватить соединение на основе этой информации, как это было сделано при известной атаке Мит-ника. В других операционных системах значения начальных порядковых номеров выбираются по формуле, зависящей от времени отправки пакета. Это, разумеется, тоже не очень безопасно. Самым надежным способом является выбор случайного значения ISN, которое невозможно спрогнозировать. Хуже всего, что начальный SYN-пакет ТСР-соединения используется для синхронизации значений порядковых номеров. В следующем примере представлен результат запуска программы nmap для определения операционной системы удаленного хоста (с помощью параметра командной строки -О), при этом указаны: обнаруженные открытые порты, сложность предсказания порядкового номера и предположительные тип и версия операционной системы.

Nmap -О sparky

(The 1495 ports scanned but not shown below are in state: closed)

Port State Service

23/tcp open telnet

2S/tcp open smtp

lll/tcp open sunrpc

513/tcp open login

32771/tcp open sometimes-rpc5

32772/tcp open sometimes-rpc7

TCP Sequence Prediction: Class=random positive increments

Diff iculty=46112 (Worthy challenge)

Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7

Данное сканирование хоста sparky обнаружило, что установка значений начальных порядковых номеров базируется на основе “случайных положительных приращений” (“random positive increments”). Также сообщается, что прогнозирование следующего порядкового номера будет “достаточно сложным” (“worthy challenge”). Хост sparky работает под управлением Solaris 2.7,

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

Номера подтверждения

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

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

Программа nmap позволяет определить активные хосты с помощью отправки TCP-сегмента с установленным флагом АСК. Этот метод значительно более эффективен, чем тестовая ping-проверка, так как на многих современных узлах блокируются входящие эхо-запросы ICMP. Тем не менее маршрутизатор, который не отслеживает содержимое пакетов, может позволить прохождение пакета “установленного” соединения, содержащего флаг АСК. Целью отправки незатребованного пакета с флагом АСК является получение в ответ от удаленного хоста пакета с флагом RESET, что явно свидетельствует об активности этого хоста. Но такое сканирование выявить довольно просто, так как в современных версиях nmap в отправляемом тестовом АСК-пакете значение номера подтверждения равно нулю, как показано в следующем примере.

verbo.52776 > win98.netbios-ssn: . ack 0 win 4096 <wscale 10,nop,mss 265,

'btimestamp 1061109567 [ tcp]>

ТСР-флаги

TCP-флаги указывают на предназначение конкретного пакета TCP-сеанса. SYN-флаг используется для организации сеанса, а флаг FIN - для его “нормального” завершения. Флаг RESET указывает на немедленный разрыв соединения, а флаг АСК обозначает подтверждение принятых данных. Флаг АСК устанавливается во всех пакетах после получения первого SYN-пакета сеанса. Флаг PUSH позволяет сообщить отправителю о необходимости немедленной отправки данных из буфера, а хосту-получателю - о передаче всех полученных данных на уровень протокола TCP. Сейчас возможна отправка данных из незаполненного до конца выходного буфера даже без получения пакета с установленным флагом PUSH. И, наконец, с помощью флага URGENT обозначается пакет с наивысшим приоритетом.

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

Искажение ТСР-пакетов

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

Рассмотрим следующий отчет о получении пакета. Это зарегистрированная NIDS попытка установить соединение со службой Napster еще в те времена, когда Napster была бесплатным и легальным средством для обмена файлами mp3, host.home.com.1310 > napster.com.66 99 : SRP [bad hdr length] (DF)

В этой записи бросаются в глаза две аномалии. Первая заключается в наличии установленных флагов SYN, RESET и PUSH (строка SRP). Второй признак искажений - это уведомление TCPdump “bad hdr length”.

Сообщение об ошибке “bad hdr length” выдается TCPdump, когда указанная длина TCP-заголовка больше действительной длины всего ТСР-сегмента (заголовка и данных). Поскольку в IP-дейтаграмме нет поля, в котором бы хранилось значение длины ТСР-сегмента, TCPdump вычисляет это значение на основании информации доступных полей. Для этого из общей длины 1Р-дейтаграммы вычитается значение длины IP-заголовка. В правильно сформированных пакетах в результате получается действительная длина ТСР-сегмента. Одна из проверок TCPdump полученного пакета заключается в том, чтобы выяснить, не превышает ли указанное в пакете в байтах значение длины TCP-заголовка вычисленного значения всего ТСР-сегмента. При наличии ошибки выдается уведомление.

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

[4500 0028 8974 4000 7406 а9с5 1804 ее22 80f4 4с7Ь] <05le 1а2Ь 0000 029d 9efe а721

а7ае 5010 2058 ас31 0047 0050>

Сосредоточим наше внимание на значениях полей для хранения длины. Прежде всего, рассмотрим длин)' всей IP-дейтаграммы, указанную во 2-м и 3-м байтах (выделены жирным шрифтом) IP-заголовка. Это значение равно 0x28, что соответствует длине IP-дейтаграммы в 40 байт. Длина IP-заголовка содержится в полубайте нулевого байта IP-заголовка. Как вы помните, значение 5 соответствует длине в 20 байт.

Жирным шрифтом также выделено значение 9-го байта, которое указывает на протокол, использованный при создании вложенного пакета. Значение 06 обозначает протокол TCP. Затем вычисляется длина вложенного ТСР-сегмента: 40 -20 = 20 байт. Этого вполне хватит для хранения TCP-заголовка без параметров и без данных в пакете, что нормально для SYN-пакета.

Тем не менее судя по выделенному жирным значению старшего полубайта 12-го байта TCP-заголовка (Оха) длина TCP-заголовка равна 40 байт (для этого нужно умножить на 4 десятичное значение 32-битового слова).

Теперь понятно, почему TCPdump генерирует сообщение об ошибке bad hdr length? Эта дейтаграмма имеет общую длину 40 байт, включая 20 байт IP-заголовка, и размер TCP-заголовка тоже 40 байт. Следовательно, или IP-дейтаграмма должна быть размером 60 байт или произошло искажение пакета.

Может так случиться, что пакет был искажен и контрольная сумма неверна? Ведь если происходит искажение TCP-заголовка или данных, то обнаружить это можно только на хосте-получателе. Система обнаружения вторжений обычно не проверяет контрольную сумму ТСР-сегмента.

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

Таким образом, мы не можем точно сказать, был пакет искажен случайно или специально и по какой причине. Единственным способом установить искажение пакета является подсчет вручную контрольной суммы его TCP-заголовка на маршрутизаторе локальной сети или изучение реакции хоста-получателя (napster.com). Проблема в том, что если контрольная сумма ТСР-заголовка окажется неправильной, никакой реакции от napster . com вообще не последует. И даже если контрольная сумма будет правильной, некорректная комбинация TCP-флагов может привести к отсутствию ответа. Если же мы действительно увидим неожиданный ответ от napster. com (наиболее вероятно возвращение ТСР-сегмента с установленным флагом RESET), то контрольная сумма была правильной, и пакет не был искажен на пути его доставки. Это значит, что пакет, скорее всего, был специально сформирован с неверными значениями полей на хосте-отправителе. Кроме того, всегда существует возможность, что 16-битовые поля пакета просто поменяются местами. Это исказит его информацию, но никак не отразится на контрольной сумме.

Верн Паксон (Vern Paxson), создатель системы обнаружения вторжений под названием Вго, в своей статье “Вго. Система обнаружения вторжений в реальном времени” использует специальный термин crud для обозначения трафика, содержащего “безвредные ошибки реализации”, который можно представить как шаблон вероятных отклонений, подобных настоящим атакам. Автор представил примеры отклонений в работе реальных стеков TCP/IP, регулярно устанавливающих флаг URG в SYN-пакетах, или флаг DF во фрагментах дейтаграмм. Хотя это и не касается искажения пакетов, но очень важно запомнить, что не всегда необычный трафик является вредоносным.

Биты флага ECN

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

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

В главе 8, “Исследование полей IP-заголовка”, мы рассказывали о новом предназначении двух младших битов ECN (Explicit Congestion Notification - явное уведомление о перегрузке) байта “Тип обслуживания”. С их помощью маршрутизатор может уведомлять отправителя о существовании перегрузки в сети и о необходимости снижения скорости передачи данных.

Как именно это происходит? В настоящее время, как указано в RFC 3168, единственным протоколом транспортного уровня, способным поддерживать уведомления о перегрузке, является ТСР.ЧВ этом RFC предлагается использовать два старших бита байта TCP-флагов в качестве полей для хранения битов ECN (рис. 9.3). Правый из этих битов называют эхо-битом ECN. Этот бит устанавливается, когда в принятом пакете установлен бит уведомления о перегрузке в байте “Тип обслуживания” IP-заголовка. Это означает, что обе стороны, взаимодействующие по протоколу TCP, поддерживают уведомления о перегрузке, что определяется в процедуре согласования параметров ТСР-соединения.

Рис. 9.3. Биты ECN байта ТСР-флагов

Эхо-бит ECN установленный в TCP-заголовке, уведомляет отправителя о необходимости снизить скорость передачи данных из-за перегрузки в сети между отправителем и получателем. После получения TCP-сегмента с установленным эхобитом ECN отправитель в два раза уменьшает окно перегрузки - размер буфера отправляемых данных. После этого он устанавливает бит CWR (Congestion Window Reduced - уменьшенное окно перегрузки) для уведомления второй стороны о предпринятых действиях для снижения перегрузки. Этот бит является старшим битом байта ТСР-флагов.

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

Определение операционной системы

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

nmap -О win98

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 4 9904150:4 9904150 (0) 'back 861966447 win 815 <mss 1460> (DF)

nmap -O sparky

20:37:00.738412 verbo.50107 > sparky.echo : SFP 232 6441544:232 6441544(0) 'bwin 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 [ tcp]>

nmap -O linux

20:44:50.370158 verbo.42318 > linux.ftp: SFP 1749165 064:1749165064(0)

*bwin 1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

При сканировании первого хоста win98 на порт 139 отправляется пакет с установленными флагами SYN, FIN, PUSH и URG. Это порт службы NetBIOS, на который ожидается поступление запросов. Все отлично - хост отвечает подтверждением. Это необычная ответная реакция на получение нестандартного пакета.

Во второй попытке сканирования пакет с тем же набором флагов отправляется на открытый порт (echo) хоста под управлением Solaris. Никакого ответа не выдается. В третьем примере сканирования все тот же пакет отправляется на порт службы FTP хоста под управлением Linux, и опять ответ не выдается. Это стандартная реакция на получение подобного пакета, описанная в спецификациях RFC. Таким образом, этот тест продемонстрировал, как можно отличить Win-dows-xocT от других хостов.

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

Повторная передача данных

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

Кроме того, существует вероятность, что хост-получатель ответил на отправленный запрос на соединение положительно (установлены флаги SYN и АСК) или отрицательно (установлены флаги RESET и АСК), но хост-отправитель по какой-то причине не получил этого ответа.

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

Как можно отличить повторные запросы от новых попыток установки ТСР-соединения? Для повторной передачи данных неизменными остаются номер порта отправителя и порядковые номера TCP-сегмента. Этот метод не является абсолютно надежным. Возможно, что отправитель специально сформировал пакеты с одинаковыми номерами порта отправителя и порядковыми номерами.

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

17:14:18.726864 1.1.1.1.62555 > 192.168.44.63.3128 : S 20583734:20583734 (0) 4>win 8192 <mss 1380> (DF) (ttl 17, id 15697)

17:14:21.781140 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) '«win 8192 <mss 1380> (DF) (ttl 17, id 33873)

17:14:27.776662 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) ^win 8192 <mss 1380> (DF) (ttl 17, id 46113)

17:14:39.775929 1.1.1.1.62555 > 192.168.44.63.3128: S 20583734:20583734(0) 'Win 8192 <mss 1380> (DF) (ttl 17, id 54353)

Рассмотрим временные метки отправленных пакетов. Между первой и второй попытками проходит около 3 с, между второй и третьей в два раза больше - б с, а между третьей и четвертой - 12 с. Это удвоение промежутка времени между повторными запросами наблюдается не всегда - в различных стеках TCP/IP применяются различные алгоритмы для определения времени ожидания для следующей попытки отправить запрос.

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

Использование повторных ответов против хоста нарушителя

Тома Листона (Tom Liston) можно назвать очень опытным специалистом по проблеме защиты от сканирований Web-серверов, выполняемых червем Code Red. Он написал программу, которая блокирует работу сканеров, выполняющих поиск свободных IP-адресов. Как правило, если регистрируются действия по поиску свободных IP-адресов, это означает, что кто-то сканирует хосты вашей сети. Том Линстон назвал свою программу LaBrea по имени знаменитого “кладбища” животных La Brea.

Программа LaBrea устанавливается на локальный хост и ожидает появления ARP-запросов для свободных IP-адресов. Обычно такой ARP-запрос генерирует маршрутизатор при поиске компьютера с неизвестным IP-адресом. Если в течение трех секунд ни от одного реального хоста не поступает ARP-ответа, то LaBrea подменяет этот ответ своим ARP-ответом.

Если затем со сканирующего хоста (в данном случае с хоста, зараженного Code Red) следует SYN-пакет по тому же адресу “найденного” хоста, то LaBrea генерирует подложный ответ с установленными флагами SYN и АСК (LaBrea не проверяет значение порта получателя, поэтому может использоваться против любого сканирования по протоколу TCP или попытки установить TCP-соединение по свободному IP-адресу). Сканирующий хост завершает процедуру установки соединения и пытается отправить какие-то данные. Программа LaBrea умышленно не выдает никаких ответов и не отправляет никаких подтверждений о получении данных. Таким образом, сканирующий хост попадается в ловушку отправки бесполезных повторных передач данных до тех пор, пока не истечет заданный лимит времени. Это требует расхода ресурсов сканирующего хоста и уменьшает его возможности сканирования, особенно, если он ожидает получения ответа перед тем, как продолжить процесс сканирования.

Давайте рассмотрим все происходящие действия шаг за шагом.

Поступает ARP-запрос для свободного 1Р-адреса 192.168.143.236

18:34:32.757821 arp who-has 192.168.143.236 tell 192.168.143.1 18:34:35.743528 arp who-has 192.168.143.236 tell 192.168.143.1 После 3 с без ARP-ответа хост, на котором установлена LaBrea,

отправляет подложный ответ 18:34:35.743591 arp reply 192.168.143.236 (0:0:f:ff:ff:ff) is-at ^0:0:f:ff:ff:ff

Вначале LaBrea ожидает появления ARP-запросов в локальной сети. Как правило, они поступают от маршрутизатора локальной сети. Если по истечению 3 с (это значение используется по умолчанию, но его можно изменить) никаких ARP-ответов не поступает, то LaBrea подменяет настоящий ARP-ответ. В этом случае мы видим ARP-запрос к хосту 192.168.143.236 (свободный IP-адрес) от локального маршрутизатора 192 .168 .143 .1. ARP-ответа нет, и через три секунды генерируется повторный ARP-запрос. Практически в тот же момент, через 3 с после первого запроса, программа LaBrea выдает подложный ARP-ответ, в котором указывает, что МАС-аресом хоста 192.168.143.236 является 0 : 0 : f : f f : f f : f f. Интересно, что ни IP-адрес 192 .168 .143 . 236, ни МАС-адрес 0 : 0 : f : f f : f f : f f в реальности не существуют. Теперь LaBrea будет просматривать проходящий трафик, предназначенный подложному МАС-адресу.

После получения подложного МАС-адреса сканирующий хост отправляет SYN-пакет запроса на соединение, на который LaBrea генерирует ответ, фальсифицирующий работу запущенной службы на активном хосте, как это показано ниже. Хост, зараженный червем Code Red, отправляет SYN-пакет 18:34:35.743817 codered.victim.com.1113 > 192.168.143.236.www: S ^30119-0748 : 301190748 (0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

Хост с программой LaBrea генерирует подложное подтверждение 18:34:35.743940 192.168.143.236.WWW > codered.victim.com.1113: S ^2516582400:2516582400(0) ack 301190749 win 10

Хост, зараженный червем Code Red, завершает процедуру установки соединения 18:34:35.744190 codered.victim.сот.1113 > 743940 192.168.143.236.www: . ack 1 win 8576 (DF)

Б приведенном выше отчете зарегистрирована попытка хоста codered.victim.com отправить SYN-пакет на порт 80 (www) свободного IP-адреса 192.168.143.236. Программа LaBrea в ответ генерирует SYN/ACK-пакет от имени несуществующего хоста 192.168.143.236. Как и ожидалось, сканирующий хост завершает процедуру установки соединения.

Затем хост codered.victim.com пытается отправить 10 байт данных по адресу несуществующего Web-сервера.

Хост, зараженный червем Code Red, отправляет 10 байт данных 18:34:35.745555 codered.victim.com.1113 > 192.168.143.236.www: . 1:11(10) 'back 1 win 8576 (DF)

Повторная передача через 6 с 18:34:41.746643 codered.victim.com.1113 > 192.168.143.236.WWW: . 1:11(10)

'back 1 win 8576 (DF)

Повторная передача через 12 с 18:34:53.743027 codered.victim.com.1113 > 192.168.143.236.www: . 1:11(10)

'back 1 win 8576 (DF)

Повторная передача через 24 с 18:35:17.735734 codered.victim.com.1113 > 192.168.143.236.WWW: . 1:11(10)

'back 1 win 8576 (DF)

Повторная передача через 48 с 18:36:05.741181 codered.victim.com.1113 > 192.168.143.236.WWW: . 1:11(10)

'back 1 win 8576 (DF)

Повторная передача через 96 с 18:37:41.911995 codered.victim.com.1113 > 192.168.143.236.www: . 1:11(10)

'back 1 win 8576 (DF)

Через 3 минуты 6 секунд попытки повторной передачи прекращаются

В отправляемых пакетах установлен только флаг АСК, подтверждающий получение подложного пакета с флагами SYN и АСК от несуществующего хоста 192.168.143.236.

Вот ловушка и сработала. Подтверждение получения данных, отправленных хостом codered.victim.com, не выдается. Поэтому данный хост вынужден проводить повторную передачу данных. При этом используется алгоритм удвоения времени задержки между повторными попытками. В различных случаях запуска программы LaBrea промежуток времени между начальным и первым повторным запросом сканирующего хоста находится в диапазоне от 3 до 12 с.

После отправки начального пакета данных проходит 3 мин и 6 с, за которые хост codered.victim.com осуществляет 5 попыток передачи данных, а затем прекращает эти попытки. Но за это время были потрачены ресурсы этого компьютера и был замедлен процесс сканирования (особенно, если сканирующий хост ожидает ответа от несуществующего хоста до продолжения сканирования). Еще больший эффект достигается, когда сканирующий хост снова и снова попадается в ловушку повторных запросов при сканировании всех свободных ІР-адресов локальной сети.

Использование программы LaBrea может показаться весьма удобным, однако стоит задуматься и о ее недостатках. Во-первых, в ловушку попадает любая попытка TCP-соединения по свободному IP-адресу локальной сети, независимо от указанного порта получателя. Если реальный хост локальной сети временно вышел из строя и не способен ответить на ARP-запрос, то по ошибке могут быть пойманы в ловушку легитимные соединения. Во-вторых, работа брандмауэров, поддерживающих таблицы состояний текущих соединений, может быть затруднена бесконечными повторными попытками. Программный код LaBrea можно получить по адресу www. hackbusters . net.

Дегтярная ловушка

Знаменитая ловушка для доисторических животных La Brea находится в парке Хенкок города Лос-Анджелес. В этом месте нефть выходила на поверхность и превращалась в деготь. Более 2,5 миллионов лет назад животные забредали в эту ловушку и погибали в ней.

Размер окна

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

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

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

Программа LaBrea, версия 2

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

Том Линстон, автор LaBrea, усовершенствовал свою программу, использовав другой метод, который назвал таймером удержанияТСР-соединения. Как было сказано, если входной буфер хоста-получателя будет заполнен, то отправитель будет уведомлен о необходимости приостановить передачу данных (в ответном пакете размер окна равен 0 байт). Обычно при освобождении части буфера отправителю немедленно посылается TCP-сегмент с указанием доступного размера окна. А что если это уведомление будет потеряно? И отправитель, и получатель будут заблокированы в ожидании ответа от второй стороны соединения.

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

Как вы увидите в следующем отчете TCPdump, новая версия программы LaBrea позволяет поймать в ловушку хост нарушителя на неопределенный промежуток времени. Как и в прошлой версии, сначала осуществляется полная процедура установки соединения, но в ответ на передачу данных LaBrea отправляет уведомление о получении с указанием размера окна, равного 0. Эта игра “вопрос-ответ” может продолжаться бесконечно. Таким образом обеспечивается длительное соединение атакующего хоста с хостом, на котором запущена программа LaBrea, без передачи каких-либо данных. Рассмотрим отчет.

19:28:07.577541 codered.victim.com.2045 > 10.10.10.155.www: S

^882335286:882335286(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

19:28:07.577618 10.10.10.155.WWW > codered.victim.com.2045: S

^998514038:998514038(0) ack 882335287 win 5

19:28:07.577879 codered.victim.com.2045 > 10.10.10.155.WWW: . ack 1 win 8576

^ (DF)

19:28:07.581366 codered.victim.com.2045 > 10.10.10.155.www: . 1:6(5) ack 1 Ъ win 8576 (DF)

19:28:07.581437 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0

19:28:09.820965 codered.victim.com.2045 > 10.10.10.155.WWW: . :6:7(1) ack 1

^ Win 8576 (DF)

19:28:09.821041 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 19:28:14.424567 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 b win 8576 (DF)

19:28:14.424646 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 19:28:23.621770 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1

% win 8576 (DF)

19:28:23.621845 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0 19:28:42.016162 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1 b win 8576 (DF)

19:28:42.016237 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0

19:29:18.804962 codered.victim.com.2045 > 10.10.10.155.www: . 6:7(1) ack 1

win 8576 (DF)

19:29:18.805038 10.10.10.155.www > codered.victim.com.2045: . ack 6 win 0

Мы начали просмотр отчета с момента после отправки подложного ARP-ответа хостом, на котором установлена программа LaBrea (от имени хоста с IP-адресом 10.10.10.155). Хост, инфицированный Code Red, здесь указан как codered.victim.com. Этот хост отправляет 5 байт данных (выделено жирным шрифтом), так как это позволяет указать размер окна несуществующего хоста 10.10.10.155. Хост с программой LaBrea отвечает уведомлением о получении данных, но указывает, что размер окна стал равен 0. Хост codered. victim, сот ожидает несколько секунд и, так как не получает никакого уведомления об увеличении размера окна, то отправляет пробный пакет, содержащий 1 байт данных. В ответ на это он получает “успокаивающий” пакет, которым LaBrea уведомляет, что интересующий нарушителя хост по-прежнему работает, но еще не готов к получению данных. Как вы видите, этот цикл запрос-ответ продолжается бесконечно, при этом промежуток времени между повторными запросами постоянно увеличивается.

Анализ заголовков вложенных пакетов | Обнаружение нарушений безопасности в сетях | Udp


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



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

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