Насколько прост наш первый пример реального трафика, настолько же и серьезна представленная ситуация. Когда-то я возглавлял группу по обнаружению взломов (CERT) в одном из департаментов Министерства обороны США. Моя смена начиналась очень рано, около 5.30 утра. Это было связано с предотвращением негативного воздействия мощного потока трафика, поступающего с предместий Вашингтона - одного из крупнейших коммуникационных узлов США. Однажды утром, когда я пришел в офис, там уже звонил телефон. Вряд ли кто-то собирался поздравить меня с выигрышем в лотерею. И в самом деле звонок был от одной из вышестоящих организаций. Мне сообщили, что ночью наша система была взломана.

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

Хотя, судя по графикам на рис. 11.4 и 11.5, это неочевидно, но полученные пакеты можно было четко разделить по группам, соответствующим стандартным начальным значениям поля ТТЬ. Например, при первом сканировании в полученных пакетах отсутствовали значения поля ТТЬ в промежутках между 22 и 42, а также между 56 и 103. Подобное явление наблюдалось и при повторном сканировании.

Размер окна

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

В большинстве полученных пакетов размер окна был 8192 (рис. 11.6). Согласно табл. 11.1 это указывает на операционную систему \Утс1ош$9х/МТ. Еще одно исследование позволило определить соответствие между стандартным размером окна 16384 и операционной системой \Утс1ош8 2000. Значение равмера окна 65535 соответствует хостам Овсо (см. табл. 11.1). Однако слишком большой процент пакетов с этим значением говорит о том, что это значение используется еще какими-то операционными системами.

Рис. 11.6. Использованные при сканировании значения размера окна

Поисковые машины не смогли помочь в определении операционных систем, размер окна которых по умолчанию был бы равен 65535. Тогда мы решили проверить все отчеты TCPdump за неделю, чтобы найти пакеты с таким размером окна. Из 5500 хостов, пакеты от которых были зарегистрированы за неделю, было только около десятка, использовавших это значение. Их сканирование с помощью программы пшар не позволило определить операционную систему. На некоторых из'этих хостов оказались открытыми порты 135 и 139, что указывает на операционную систему Windows до версии Windows 2000. На других хостах этой группы был открыт порт 445, который в Windows 2000 закреплен за протоколом SMB (Server Message Block - блок сообщений сервера), позволяющим двум ком пьютерам обмениваться данными поверх TCP/IP без необходимости применения промежуточного уровня NetBIOS over TCP/IP (NBT). Кроме того, остальные хосты, в пакетах которых был указан размер окна 65535, ожидали запросов на порты 111 (portmapper), 515 (служба lpd- демон построчной печати) и 6000 (служба XII), что указывает на UNIX-хосты. Таким образом, не удалось сделать никаких определенных выводов об операционных системах, использующих по умолчанию значение размера окна 65535.

Еще одним интересным значением размера окна было 32120, указывающее на хост под управлением Linux, которое было зарегистрировано только при первом сканировании и составило 0,19% от общего числа сканирующих хостов. Размер окна 8760, соответствующий хостам Solaris, был выявлен в обоих случаях сканирования (5,21% в первом сканировании и 6,6% - во втором).

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

Параметры TCP

Еще одним важным значением является значение поля MSS (Maximum Segment Size - максимальный размер TCP-сегмента), которое входит в набор параметров TCP. Это значение указывает максимальный размер полезных данных TCP-сегмента. При этом не учитываются размеры IP- и TCP-заголовков. Вообще, можно сказать, что значение MSS на 40 байт меньше значения MTU (Maximum Transmission Unit - максимальная единица передачи данных в сети) при условии отсутствия параметров IP и параметров TCP. Значение MTU может использоваться для определения типа сети, в которой установлен хост-отправитель.

В некоторых случаях, хотя и не в данном примере, значение MTU, а значит, и MSS может указывать максимальный размер передаваемого пакета на пути к получателю. С помощью пакета с установленным флагом DF отправитель может послать “тестовый” пакет для определения минимального значения MTU на пути доставки пакета. Если никаких ICMP-сообщений об ошибках не будет получено, то считается, что размер MTU для локальной сети подойдет и для передачи по Internet без фрагментации. Если же возвращается ICMP-сообщение “unreachable - need to frag (mtu ###) ”, то указанный размер MTU (###) определяет минимальное значение размера пакета для участка сети на маршруте передачи пакета. Отправитель может уменьшить размер пакетов, чтобы избежать фрагментации. Обратите внимание на то, что в этом случае размер MSS не может быть использован для определения MTU сети отправителя. Однако, поскольку не было никаких признаков предварительной отправки “пробных” пакетов, мы предположили, что MSS полученных пакетов позволяют узнать MTU сетей, в которых работают хосты-отправители.

В результате анализа мы узнали, что большинство сканирующих хостов установлены в сетях со значением MTU, равным 1500 байт, что указывает на локальные сети Ethernet или DSL-сети (рис. 11.7). Значение MTU 576 связывают с протоколом РРР или ISDN-сетями. И, наконец, значение MTU 1454 указывает на использование РРР в сетях Ethernet или на DSL-соединения.

Рис. 11.7. Значения MSS

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

Рассмотрим предположение об использовании для сканирования хостов, подключающихся к Internet по коммутируемым линиям. Во-первых, если для подключения к Internet зомби-хоста используется коммутируемая линия связи, то в момент атаки соединение может просто отсутствовать (если нет выделенного канала). Кроме того, для многих коммутируемых соединений выполняется распределение временных ІР-адресов с помощью протокола DHCP. Как “командир” передаст сигнал о начале атаки, не зная IP-адреса зомби-хоста? Единственным вариантом является периодическое уведомление зомби-хостов организатора атаки о своих новых IP-адресах. Поэтому участие в атаке смогут принять только активные хосты, подключенные к сети в момент атаки.

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

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

Повторные запросы

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

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

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

Альтернативный механизм называется сокетом для доступа к протоколам нижнего уровня (raw socket), при котором для создания пакетов не используется стек TCP/IP. Для создания заголовков и их полей применятся специальная программа. Сформированный пакет передается непосредственно сетевому адаптеру. Многие программы сканирования, например nmap и hping2, используют сокеты доступа к протоколам нижнего уровня.

При этом сканировании отправляются многочисленные повторные запросы на установку соединения, несмотря на отсутствие какого-либо ответа от хоста-получателя. Что это значит? Были использованы обычные сокеты? Во-первых, сканирующий хост хочет максимально увеличить шанс получения ответа - явный признак сканирования, а не отправки потока данных. При отправке потока данных пакеты чаще посылаются с помощью сокетов доступа к протоколам нижнего уровня с целью ускорить передачу. Во-вторых, использование сокетов доступа к протоколам нижнего уровня усложняет проведение атаки, так как требуется установить интерфейс прикладного программирования, предназначенный для захвата пакетов на уровне пользователя на сканирующем хосте. Для этой цели используются интерфейсы winpcap (для Windows) или lipcap (для UNIX). Использование стандартных сокетов упрощает установку программного обеспечения, необходимого для сканирования.

Резюме

Основной вывод, сделанный по результатам нашего исследования, таков. Было проведено очень эффективное сканирование с целью выявления хостов, которые ожидают запросов на ТСР-порт 27374. Сканирование осуществлялось зомби-хостами, большинство из которых работало под управлением Windows. Хосты, на которых были установлены другие операционные системы, тоже участвовали в сканировании, но играли второстепенную роль. Важно то, что “зараженными” оказались не только Windows-хосты. Неизвестно, насколько количество хостов под управлением Windows превышает число хостов под управлением других операционных систем, и не является ли процентное соотношение сканирующих хостов простым отображением популярности различных операционных систем. Преимущественное использование в качестве зомби-хостов хостов под управлением конкретной операционной системы говорит о простоте ее компрометации.

Является ли единственной целью этого сканирования найти хосты с открытым портом 27374? Мы предположили, что не все хосты были заражены с помо щью программы атаки SubSeven. Эта программа ориентирована на только на Windows-хосты. Возможно, здесь применялась улучшенная версия SubSeven, позволяющая также атаковать хосты под управлением других операционных систем. Какая бы программа атаки не управляла работой зомби-хостов, “командир” знает о существовании подчиненных хостов и не нуждается в их поиске с помощью сканирования. Является ли целью данного сканирования поиск других кандидатов в зомби-хосты, управлять которыми будет другой “командир”? В данном случае эти зомби-хосты будут хостами Windows, так как только они могут ожидать запросов на порт SubSeven. Новые зомби-хосты могут использоваться для любых целей, не только для сканирования.

Какой бы ни была цель сканирования, способ его выполнения очень эффективен. За несколько минут было просканировано более 30000 хостов. Это еще раз продемонстрировало увеличивающуюся сложность проводимых сканирований и программ атаки, примерами чему может послужить появление червей Code Red и nimda. Кроме того, очевиден рост количества используемых хостов, которые могут выполнять задания злоумышленников из-за невнимательности или беспечности домашних пользователей, компьютеры которых постоянно подключены к Internet, а также из-за появления операционных систем и прикладных программ с многочисленными уязвимыми местами.

Практический анализ | Обнаружение нарушений безопасности в сетях | Создание фильтров tcpdump


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



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

  • Октябрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс