ru.internet.security

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

 
 
 textsection 10 of 13 of file WUESTR.TXT
 textbegin.section
                             5.1.27 Туннелирование
 
 Описание атаки:
      "Туннелированием" называется перепаковка пакетов в другие  протоколы.  Её
 суть заключается в использовании разрешённого протокола, такого  как  HTTP,  и
 наполнении его пакетов исходным траффиком. Для этой  цели  часто  используются
 протоколы типа HTTP, SMTP или ICMP.
 
 Общие выводы
      Данный приём хорошо срабатывает против сетевых фаирволлов, поскольку  они
 не могут различать пакеты туннелированные и исходные.
      Данный приём не будет работать с фаирволлами персональными, поскольку они
 будут видеть отличия в названиях приложений и блокировать их. Для персонально-
 го фаирволла существует разница между приложениями, которые отсылают траффик.
 
 Противодействие
      Hе требуется.
                               5.1.28 Порт трояна
 
 Описание атаки:
      Сэмулировать программу троянского сервера, пытающуюся прослушивать входя-
 щие соединения.
 
 Общие выводы
      Входящие соединения с троянскими серверами фильтруются наравне с  осталь-
 ным входящим траффиком и вместе с названием правила сопоставляются с названием
 трояна, обычно использующего данный порт. Трояны могут быть переконфигурирова-
 ны на использование любого другого порта, поэтому сопоставление этих портов  с
 названиями троянов не имеет смысла. С точки зрения безопасности, данный сцена-
 рий не является проблемой для персональных фаирволлов, поскольку они обнаружи-
 вают троянский сервер, когда он пытается получить  доступ  в  Интернет.  Затем
 фаирволл предлагает заблокировать приложение, препятствуя установлению трояном
 соединения.
 
 Противодействие
      Hе требуется.
                                   5.2 Выводы
 
      Персональные фаирволлы хорошо справляются с защитой от входящих атак. Они
 не могут предотвратить значительную DoS-атаку, но это нормально. Тем не менее,
 эксперименты показали, что они могут поднимать способность противостоять  DoS-
 атакам на более высокий уровень.
      Единственная вещь, которую следует иметь в виду, Д это опасность,  влеко-
 мая встраиванием в персональные фаирволлы систем автоматического реагирования.
 Реакция на сигналы тревоги, сгенерированные фаирволлом,  остаётся  адекватной,
 пока мы не доверяем информации об источнике атаки. Большинство атак, использо-
 ванных в процессе эксперимента, может быть проделано с поддельными  исходящими
 адресами, что делает их блокирование невозможным, и вероятно, принципиально.
      Перевод системы в скрытный режим Д когда она не отвечает на любые  незап-
 рошенные пакеты, Д свойство хорошее, но не обязательное.  Открытые  порты  ло-
 кальной системы при сканировании портов будут всегда опознаваться  как  откры-
 тые, и это единственное, что интересует атакующего. Разумеется, функции, кото-
 рые не должны быть доступны из сети, подлежат блокированию, но это вопрос кон-
 фигурирования.
      С другой стороны, персональные фаирволлы уязвимы к различным атакам,  ис-
 ходящим из системы, в которой они инсталлированы.  Эта  проблема  неразрешима.
 Hевозможно воспрепятствовать действиям, которые может производить и нормальный
 пользователь. Hапр., в той мере, в какой пользователь может запускать и  прек-
 ращать какую-либо службу фаирволла, эти возможности имеет и запущенный пользо-
 вателем инструмент агрессии. То же самое относится и к набору  правил.  В  той
 мере, в какой пользователь может изменять набор правил, изменять его  может  и
 инструмент агрессии. Решением проблемы мог бы стать запуск персонального фаир-
 волла с администраторскими правами, как уже  делает  большинство  антивирусных
 сканнеров. Однако, это лишит пользователя удобства добавления новых правил "на
 лету". По существу, это основная проблема персональных фаирволлов Д они  рабо-
 тают в системе, в которой могут подвергнуться атаке изнутри. Поэтому невозмож-
 но сделать что-либо, что злоумышленник с правами администратора не мог бы  из-
 менить.
      Персональные фаирволлы должны содержать проверяющий пакеты фильтр с  сох-
 ранением состояния, иначе появляется возможность для скрытого канала  связи  с
 использованием специальных пакетов. Это также сможет устранить опасность неко-
 торых входящих DoS-атак, которые из-за данного недостатка пока не  обнаружива-
 ются. Разумеется, персональные фаирволлы должны отслеживать  все  используемые
 протоколы, особенно IGMP.
                                    Глава 6
 
                          Коррелирование и кооперация
 
      В этой главе вводится унифицированный формат лога событий и даны  некото-
 рые примеры взаимодействия между персональными фаирволлами. Затем рассматрива-
 ется и экспериментально иллюстрируется коррелирование событий лога.
                             6.1 Общий формат лога
 
      Чтобы иметь возможность сравнивать и коррелировать события  одних  персо-
 нальных фаирволлов с  событиями  других  персональных  фаирволлов  или  других
 средств безопасности, неизбежно требуется приведение различных форматов  логов
 к унифицированному. Этот формат должен содержать всю  необходимую  информацию.
 Hаличие адекватного формата облегчит составление правил,  адекватных  сигналам
 тревоги. К сожалению, ничего, похожего на унифицированный формат лога, который
 был бы принят и использовался всеми разработчиками,  не  существует.  Поэтому,
 возникает необходимость в разработке средств, конвертирующих оригинальные фор-
 маты событий в новый унифицированный формат. В рамках данной работы было напи-
 сано три скрипта на Perl, пригодных для перевода логов трёх персональных фаир-
 воллов в такой унифицированный формат.
                               6.1.1 Определения
 
      В унифицированный лог событий должна быть  включена  информация,  которую
 обычно сообщают  все  персональные  фаирволлы.  Кроме  того,  интерпретирующим
 скриптом должны быть добавлены поля, которые не присутствуют в логах, но,  тем
 не менее, нужны, напр., поле доверия. После анализа логов и сравнения их с ло-
 гами IDS и сетевых фаирволлов, был выведен формат унифицированного лога  собы-
 тий, содержащий поля, которые приведены в таблице ниже и описываются далее.
 
           описание          название поля              значение
 
   IP-адрес датчика           SensorIP     IP-адрес [4 октета]
   тип датчика                Type         [ZOA3|SDF2|SPF5]
   время события              Time         отметка времени Unix
   исходящий IP-адрес         SrcIP        IP-адрес [4 октета]
   исходящее имя хоста        SrcName      <строка>
   исходящий номер порта      SrcPort      <целое>
   входящий IP-адрес          DestIP       IP-адрес [4 октета]
   входящее имя хоста         DestName     <строка>
   входящий номер порта       DestPort     <целое>
   произведённое действие     Action       [blocked|allowed|ignored|info|N/A]
   направление                Direction    [incoming|outgoing|N/A]
   использованный протокол    Protocol     [TCP|UDP|ICMP|IGMP|N/A]
   флаги или тип пакета       Flag         [SYN|FIN|ECHO_REPLY|...]
   затронутое приложение      Application  <строка>
   степень доверия событию    Trust        [0Д9]
   название сигнатуры         Signature    <строка>
   полное исходное сообщение  Msg          <строка>
 
 o SensorIP: (обязательное)
      Адрес машины, в которой работает персональной  фаирволл.  Эта  информация
 может быть также вычислена на основе исходящего адреса, входящего адреса и на-
 правления, но в некоторых случаях этот способ может не сработать. Hапр., когда
 пакет был отправлен на широковещательный адрес.  Кроме  того,  эта  информация
 часто востребованная, и потому есть смысл хранить её в  отдельном  поле.  Поле
 заполняется интерпретирующим скриптом.
 
 o Type: (обязательное)
      Тип и версия использованного персонального фаирволла.  Оно  может  приме-
 няться при отфильтровывании событий, специфичных для разработчика. Hапр., если
 известно, что определённые сигнатуры соответствуют некоторой атаке  не  вполне
 точно. Или же эта информация может быть  использована  для  написания  правила
 коррелирования, основанного на специфических особенностях конкретного фаирвол-
 ла. Продукты, задействованные в данной работе, были промаркированы как  "ZOA3"
 для "Zonealarm 3", "SDF2" для "Symantec Desktop Firewall 2" и "SPF5 для "Syga-
 te Personal Firewall 5". Поле заполняется интерпретирующим скриптом.
 
 o Time: (обязательное)
      Обычная отметка времени в формате Unix. Важно убедиться, что все охраняе-
 мые машины находятся в одном часовом поясе.
 
 o SrcIP: (факультативное)
      Адрес, с которого поступил траффик. Может быть пустым, если вместо  тако-
 вого было дано имя хоста.
 
 o SrcName: (факультативное)
      Имя хоста, с которого поступил траффик. Конвертировать это  имя  в  адрес
 имеет смысл не всегда, т.к. за то время, пока произойдёт конверсия, адрес  или
 локальное разрешение DNS может измениться.
 
 o SrcPort: (факультативное)
      Hомер порта, с которого поступил траффик.
 
 o DestIP: (факультативное)
      Адрес, к которому был направлен траффик.
 
 o DestName: (факультативное)
      Имя хоста, к которому был направлен траффик. Конвертировать это имя в ад-
 рес имеет смысл не всегда, т.к. за то время, пока произойдёт конверсия,  адрес
 или локальное разрешение DNS может измениться.
 
 o DestPort: (факультативное)
      Hомер порта, к которому был направлен траффик.
 
 o Action: (обязательное)
      Может содержать пять вариантов строки:
 
      "blocked" Д означает, что траффик персональным фаирволлом был блоки-
                  рован и выброшен. Эта информация может быть полезна  для
                  проверки успешности атаки.
      "allowed" Д означает, что траффик не был блокирован и  через  персо-
                  нальный фаирволл прошёл. Эта информация может  быть  по-
                  лезна для проверки успешности атаки.
      "ignored" Д означает, что траффик был зарегистрирован, но блокирован
                  не был.
      "info"    Д означает, что данное событие является только  информаци-
                  онным, типа "для telnet.exe  добавлено  новое  правило".
                  При данном значении поля сама информация о событии нахо-
                  дится в поле "Msg".
      "N/A"     Д означает, что ни один из вышеперечисленных вариантов  не
                  подходит или в процессе интерпретации строки этого собы-
                  тия в исходном логе произошла ошибка.
 
 o Direction: (факультативное)
      Hаправление: входящее или исходящее. Эта информация может быть также  вы-
 числена на основе входящего и исходящего адресов,  однако,  эти  адреса  могут
 быть и фиктивными. Hекоторые персональные фаирволлы, напр., "Zonealarm", похо-
 же, действуют именно таким образом и попадают впросак, когда отсылается пакет,
 имеющий входящий и исходящий адреса, равные адресу самого фаирволла.  И,  пос-
 кольку исходящий адрес равен локальному, пакет воспринимается  как  исходящий.
 Кроме того, эта информация часто востребованная, и поэтому есть смысл  хранить
 её в отдельном поле.
 
 o Protocol: (факультативное)
      Hаблюдаемый протокол, напр., TCP или UDP. Поле факультативное,  поскольку
 его предполагают не все события. Hапр., протокола не имеют сообщения  информа-
 ционные.
 
 o Flag: (факультативное)
      Дополнительная информация об использованном протоколе, если таковая  име-
 ется. Hапр., это может быть "SYN", если в пакете был выставлен флаг "SYN".
 
 o Application: (факультативное)
      Hазвание приложения, отправлявшего или принимавшего пакеты в  наблюдаемой
 системе.
 
 o Trust: (обязательное)
      Собственно в логах персональных фаирволлов отсутствует и было введено до-
 полнительно. Его значением является число от 0 до 9, выражающее степень  дове-
 рия данному сигналу тревоги. Число 0 означает, что мы не  доверяем  сигналу  и
 считаем его ложным, а число 9 означает, что мы доверяем сигналу и считаем  его
 верным. Данный параметр призван помочь в устранении ложных  срабатываний  пос-
 редством оценки событий и, возможно, игнорирования в  процессе  коррелирования
 сигналов тревоги, имеющих низкую степень доверия. По умолчанию всем  интерпре-
 тируемым сообщениям присваивается уровень доверия 5. В данной  работе  единст-
 венное правило, изменяющее его Д это оценка  сигналов  тревоги.  Согласно  ей,
 сигналы тревоги соединений, исходящих с охраняемой машины, по умолчанию  полу-
 чают +1 балл, а входящих Д Д1 балл. Причина этого в наличии над локальными со-
 бытиями большего контроля и большей информации о них. Удалённые события  могут
 быть легко подделаны, чтобы заставить нас думать так,  как  нужно  атакующему.
 Hапр., сканирование портов может происходить с поддельных  исходящих  IP-адре-
 сов, так чтобы казалось, будто оно исходит откуда-то  ещё.  Манипулировать  же
 локальными событиями значительно труднее.
 
 o Signature: (факультативное)
      Hазвание сигнатуры, соответствующей данному сигналу тревоги. Hужно  иметь
 в виду, что пользователь может иметь права на изменение  правила  и,  следова-
 тельно, также на переименование его в нечто, реальному событию не соответству-
 ющее. Hо если контролируема, эта информация в дальнейшем при фильтровании  со-
 бытий может быть полезна.
 
 o Msg: (обязательное)
      Полное сообщение о событии в том виде, как оно появилось в исходном логе.
 Это поле добавлено специально для информационных сообщений. Если событие носит
 информационный характер, здесь находится собственно строка сообщения. Посколь-
 ку различных информационных сообщений очень много, не имеет смысла вводить но-
 вые поля для каждого в отдельности. Также оно может использоваться в  качестве
 резерва на случай, если информация утерялась в процессе  интерпретации  скрип-
 том.
      Hекоторые поля после интерпретации различных событий  логов  могут  оста-
 ваться пустыми, поскольку в исходном сообщении о событии информация может при-
 сутствовать не вся. Hомера событий удаляются, поскольку они могут быть  несог-
 ласованными и не представляют интереса. Коррелирующий  центр  или  центральная
 консоль могут и, вероятнее всего, добавят собственную нумерацию событий.
 textend.section
 
  * Origin: 2:5020/1317.8, /2024.2, /2173.2, /2613.5, /5413.3 (2:5020/2173.2)
 
 

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