ru.internet.security

 
 - RU.INTERNET.SECURITY ---------------------------------------------------------
 From : Marхnais                             2:5020/2173.2  05 Mar 2006  01:18:02
 To : All
 Subject : Персональные фаирволлы и выявление вторжений
 -------------------------------------------------------------------------------- 
 

 
 
 textsection 12 of 13 of file WUESTR.TXT
 textbegin.section
                           6.3.2 Сканирование портов
 
      Сканирование портов само по себе опасности не представляет и в наше время
 встречается нередко. Однако, оно часто является первым шагом в атаке, и за ним
 желательно следить.
      С помощью персонального фаирволла существует возможность отслеживать ска-
 нирование портов машины. Если машин с инсталлированными персональными фаирвол-
 лами много, появляется также возможность отслеживать сканирование IP.  За  ним
 скрываются обычные сканирования портов, последовательно повторяемые  для  мно-
 жества IP-адресов. Если проверенных одновременно  портов  получателя  немного,
 определить, был ли это червь или сканирование портов, часто затруднительно, но
 сканирование часто затрагивает более пяти портов, что червь делает редко.
      Сканирование портов может быть легко обнаружено при возможности  отслежи-
 вания всех запросов с удалённой машины к целевой. Эти события требуется только
 проанализировать. Hе все события будут иметь статус  блокированных,  поскольку
 некоторые из сканированных портов могут находиться в процессе использования  и
 поэтому быть открытыми. Это означает необходимость исследовать события незави-
 симо от их статуса, из-за этого придётся включить регистрирование также и  па-
 кетов принятых, и это может привести к накоплению в логе  большого  количества
 данных.
      Поскольку атакующий заинтересован в результате, исходящий IP-адрес скани-
 рования портов всегда будет один и тот же. По крайней мере, так  принято  счи-
 тать. Hо с появлением технологий слепого сканирования типа Idlscan стало  воз-
 можным сканирование удалённой машины без отправки пакетов  непосредственно  ей
 [9]. Сочетание этих приёмов с несколькими  различными  промежуточными  [relay]
 хостами делает возможным сканирование целевой системы с разных IP-адресов,  не
 выдавая реальный IP-адрес источника в каждом регистрируемом сообщении. Это де-
 лает определение настоящего источника атаки практически невозможным.
      В некоторых случаях возможны ситуации, когда  атакующий  получается  даже
 больше информации, чем обычно. Hапр., персональный фаирволл, который позволяет
 пользователю определить доверяемый IP-адрес и разрешить траффику с него прохо-
 дить беспрепятственно, может оказаться жертвой трюка, раскрывающего информацию
 о функционирующих службах. Если атакующий знает, какая машина  доверяемая,  он
 может задействовать эту машину для осуществления скрытого Idlscan против фаир-
 волла. Последний блокировать пакеты с доверяемого хоста не  будет,  что  может
 привести к утечке информации о действительном  состоянии  портов.  Это  делает
 возможным распределённое сканирование портов из множества источников, так  что
 для проверки открытости портов одной целевой машины используются разные источ-
 ники. С этой целью могут быть использованы даже веб-сервисы  типа  "Hexillion"
 [10].
      Изощрённый сканнер портов не будет перебирать их в  линейном  порядке.  В
 сочетании с тем, что разных атакующих могут интересовать разные порты, это де-
 лает бессмысленными попытки отслеживать в поисках сканирования портов  их  ли-
 нейные последовательности.
      Из этих соображений вытекают следующие критерии.
 
      Признаком сканирования портов является контакт с большим количеством
      разных портов (первый признак) за короткий отрезок  времени  (второй
      признак). Признаки должны рассматриваться с учётом условий  конкрет-
      ной системы.
 
      Относительно проблем, рассмотренных выше, нельзя утверждать, что все  со-
 бытия сканирования портов должны иметь один и тот же источник Д скорее  наобо-
 рот. Тем не менее, добросовестный подход предполагает передачу движку,  анали-
 зирующему событие, всех доступных данных. Может случиться, что скрыть свой ре-
 альный IP-адрес атакующий забыл.
      Поскольку гарантировать подлинность IP-адреса атакующего никогда  нельзя,
 следует быть осторожным с функциями автоматической блокировки. Если  атакующий
 узнает, что при каждой атаке система блокирует доступ к целевой машине на один
 час, он сможет воспользоваться этим против охраняемой системы. Hапр.,  атакую-
 щий может сымитировать сканирование портов так, что оно будет казаться  проис-
 ходящим с DNS-сервера жертвы. Персональный фаирволл, как следствие,  автомати-
 чески блокирует DNS на один час, блокируя тем самым  использование  охраняемой
 машиной DNS-сервера.
                                6.3.3 DoS-атаки
 
      DoS-атака (denial of service ("отказ в  обслуживании"))  обычно  пытается
 перегрузить целевую машину огромным количеством фиктивных пакетов, так что  та
 прекращает отвечать на санкционированный  желательный  траффик.  Поскольку  со
 стороны цели атакующий заинтересован в полном отсутствии  ответов,  эта  атака
 рассматривается как односторонняя Д обратная связь в ней отсутствует. Это объ-
 ясняет, почему в процессе DoS-атак часто используются фиктивные пакеты.
      Провести различие между сканированием портов и DoS-атаками  против  служб
 TCP, такими как SYN-затопление, очень трудно, поскольку они порождают  одни  и
 те же сообщения. SYN-затопление может отличаться большим количеством  пакетов,
 но если некто сканирует все TCP-порты, это также может порождать огромную мас-
 су траффика. Поэтому точную причину определить  невозможно,  установить  можно
 только факт атаки.
                      6.4 Эксперимент в реальных условиях
 
      Эксперимент в реальных условиях проводился следующим образом. Было найде-
 но несколько, согласившихся принять в нём участие,  пользователей  Windows  из
 "IBM Zurich Research Lab". Они должны были использовать "Symantec Desktop  Fi-
 rewall" в течение недели и передавать полученные логи и  свои  наборы  правил.
 Последние требовались потому, что  пользователи  имели  возможность  создавать
 правила новые, а правила по умолчанию отключать. Это  могло  усложнить  задачу
 тем, что на некоторых машинах события могли избежать регистрации, из-за  того,
 что набор правил был изменён так, чтобы этого не происходило. Задачей экспери-
 мента вцелом была проверка, будет ли идея о  коррелировании,  рассмотренная  в
 гл. 6, иметь практический смысл и сможет ли она работать в реальном сценарии.
      По окончании недели были собраны логи и файлы наборов правил 12  человек,
 находившихся в одной подсети "IBM". После  перевода  логов  в  унифицированный
 формат событий написанным в рамках данной работы скриптом на Perl, было собра-
 но ок. 6000 сигналов тревоги. Для облегчения обработки данные были загружены в
 таблицу "Excel". Теперь появилась возможность произвести операции,  основанные
 на предопределённых правилах,  обычно  осуществляемые  консолью  безопасности.
 Данные были проанализированы вручную на предмет  работоспособности  задейство-
 ванных методов и возможной необходимости их адаптации.
      Через поиск событий с одинаковыми исходящим IP-адресом и входящим портом,
 просматривались подозрительные сигналы тревоги и отфильтровывались все исходя-
 щие соединения так, чтобы оставались только входящие события,  удовлетворяющие
 вышеописанным критериям. Дополнительно было установлено окно времени, выбираю-
 щее события, произошедшие в пределах 1 мин. Hайденные таким образом группы со-
 бытий содержали множество крайне подозрительных сигналов  тревоги,  таких  как
 показанные в таблице ниже (IP-адреса анонимизированы и ненужные  поля  удалены
 для лучшей читабельности.).
 
                 Time      SrcIP    SrcPort    DestIP    DestPort
 
               16:53:11 10.10.10.66  2703   10.10.10.134    80
               16:53:14 10.10.10.66  2703   10.10.10.134    80
               16:53:16 10.10.10.66  2728   10.10.10.159    80
               16:53:16 10.10.10.66  2728   10.10.10.159    80
               16:53:16 10.10.10.66  2771   10.10.10.222    80
               16:53:19 10.10.10.66  2771   10.10.10.222    80
 
      Из таблицы видно, что машина с IP-адресом  10.10.10.66  сканировала  нес-
 колько машин в сети на TCP-порту 80. Если подсчитать соответствующие  разности
 между исходящими портами и аналогичными им IP-адресами получателя, то они ока-
 зываются равными. В этом можно убедиться следующим расчётом:
 
                          2728 Д 2703 = 25 = 159 Д 134
                          2771 Д 2728 = 43 = 222 Д 159
 
 Данный факт указывает на то, что атакующий, вероятно,  осуществлял  последова-
 тельное сканирование в диапазоне IP-адресов, по крайней мере, от  10.10.10.134
 до 10.10.10.222. IP-адрес 10.10.10.135 сканировался с исходящим  портом  2704,
 IP-адрес 10.10.10.136 Д с исходящим портом 2705 и т.д. Трудность  в  том,  что
 имея доступ только к логам персонального фаирволла, приведённым в таблице  вы-
 ше, невозможно сказать, было ли это сканирование портов  или  же  компьютерный
 червь искал уязвимые веб-серверы. Поскольку большинство новейших  компьютерных
 червей ищет новые жертвы в случайном  порядке,  а  не  последовательно,  можно
 предположить, что это было обычное сканирование портов. Однако утверждать  на-
 верняка нельзя.
      Второй использованный поисковый шаблон заключался в просмотре  отсортиро-
 ванных по времени событий с одинаковыми IP-адресами и входящими портами  через
 небольшое временное окно. Часть обнаруженных сигналов тревоги приведена в таб-
 лице ниже.
 
                 Time      SrcIP    SrcPort    DestIP    DestPort
 
               10:12:11 10.10.10.66  1511   10.10.10.134    80
               10:12:14 10.10.10.66  1511   10.10.10.134    80
               14:53:42 10.10.10.88  1254   10.10.10.134    80
               14:53:45 10.10.10.88  1254   10.10.10.134    80
               17:23:31 10.10.10.22  1397   10.10.10.134    80
               17:23:34 10.10.10.22  1397   10.10.10.134    80
 
      Во всей совокупности данных было найдено ок. 40 случаев явной  последова-
 тельности событий, содержавших 2 сигнала тревоги с задержкой в 3 с в диапазоне
 исходящих портов от 1100 до 1600. Все они были нацелены на один входящий порт,
 являющийся портом веб-сервера TCP 80. Аналогичные  последовательности  находи-
 лись и для других входящих IP-адресов, каждый раз по одному шаблону.
      Это наводит на предположение о том, что данные события могли быть  порож-
 дены компьютерным червём, проверяющим на предмет работающих веб-серверов  слу-
 чайные IP-адреса. К сожалению, как было сказано ранее, доступа к логу сниффера
 за исследуемый отрезок времени не было, и поэтому проверить, был ли это компь-
 ютерный червь, не представлялось возможным. Для получения точных выводов нужны
 иные источники информации, сохраняющие полное содержимое пакетов. Тем  не  ме-
 нее, данные адреса можно квалифицировать как подозрительные  и  даже  опасные.
 Теперь можно предпринять дальнейшие шаги для проверки этих машин.
      Также наблюдались аналогичные последовательности, группирующие события по
 3 вместо 2 Д вероятно, относящиеся к различным компьютерным червям.
      Каких-либо недостатков конфигурации сети, могущих быть выявленными по ис-
 следованным логам, обнаружено не было. Просмотр наборов  правил  показал,  что
 большинство пользователей по-прежнему использовало одни и  те  же  правила  по
 умолчанию. К ним было добавлено несколько правил для отдельных приложений, ко-
 торые на соответствующих машинах, очевидно, использовались. Данная  информация
 может быть также задействована для раскрытия фактов использования программного
 обеспечения запрещённого на этих машинах.
                                   6.5 Выводы
 
      Логи персональных фаирволлов для коррелирования событий атак пригодны.
      Для повышения их ценности, их можно усовершенствовать в различных направ-
 лениях. Функцию ведения логов следует изменить таким образом, чтобы  облегчить
 дальнейший анализ централизованным коррелирующим движком. Это может быть  дос-
 тигнуто отсылкой событий как syslog-сообщений или записью их в  файл  в  легко
 интерпретируемом формате. Другим важным усовершенствованием является  реализа-
 ция фильтрации, проверяющей пакеты с сохранением состояния. С этой функцией  в
 сообщение о событии станет возможным  добавлять  больше  полезной  информации,
 напр., строку запроса при попытке установления соединения с веб-сервером.  Бо-
 лее того, она позволит устанавливать более точные правила, способные учитывать
 содержимое пакетов.
      Пока же перечисленные выше вопросы не решены, предпочтительной, по мнению
 автора, конфигурацией является сотрудничество персональных фаирволлов с систе-
 мой обнаружения вторжений. В нём сочетаются хорошие возможности  идентификации
 атак системой обнаружения вторжений с возможностью защиты от неизвестных  атак
 персональным фаирволлом. Если затем полученные  сообщения  проанализированы  в
 одном месте и скоррелированы, большинство атак может быть обнаружено и предот-
 вращено.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор