Оповещение об уведомлении

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

Отказ от обновления

Очень редко в процессе оценки системы обнаружения атак пользователи обращают внимание на возможность отказа от обновления. И хотя на первый взгляд этот механизм не кажется важным, на самом деле это не так. Приведу пример из смежной области. До недавнего времени пользовался российской антивирусной системой AVP, которая устраивала меня по всем параметрам. Однако, начиная с какого-то момента, база cигнатур вирусов этой системы пополнилась такими программами, как Remove Administrator, Back Orifice, NetBus и т. д. После этого моя жизнь превратилась в кошмар. Антивирусный монитор (AVP Monitor) стал с завидной регулярностью предупреждать меня о наличии этих программ на моем жестком диске. Мало того, он назойливо не давал их запускать, несмотря на то, что все эти вредоносные программы использовались мной в процессе преподвания. Когда я попытался отключить обнаружение данных "объектов преследования", то не смог обнаружить соответствующей кнопки (грубо говоря). Возможность отката назад, к моменту пополнения базы данных сигнатурами этих программ также отсутствовала. После этого я прекратил пользоваться системой АУР несмотря на все ее положительные стороны. Именно поэтому я призываю учитывать наличие отказа от обновления в оцениваемой системе обнаружения атак.

Варианты реагирования

Мало выявить и идентифицировать атаку - необходимо на нее соответст­вующим образом отреагировать. Именно варианты реагирования во многом определяют эффективность системы обнаружения атак.

Уведомление

Самый первый вариант реагирования, который был реализован в системах обнаружения атак – это уведомление администратора безопасности или оператора системы обнаружения атак. В современных средствах предусмот­рен полный спектр различных вариантов реагирования, начиная от посылки сообщений на консоль системы обнаружения атак и заканчивая отправкой звукового оповещения на телефон (рис. 8.15).

Обычно в системе обнаружения атак предусмотрено 2-3 варианта реагирования – посылка уведомления на консоль системы обнаружения атак, генерация сообщения электронной почты (по протоколу SMTP) и сообщения для системы сетевого управления (по протоколу SNMP). В некоторых разработ­ках существуют и другие варианты уведомления. Например, в системах NetProwler и eTrust IDS реализован сигнальный механизм для пейджера ад­министратора безопасности, в программе eTrust IDS каждое обнаруживаемое событие может быть обозначено звуковым сигналом или информация о нем может быть послана по факсу. В системе RealSecure возможностей посылки факсимильных уведомлений или на пейджер нет, однако RealSecure может быть интегрирована с системой AlannPoint компании Singlepoint System (http://www.singlepointsys.com).Данная система предназначена для реализации различных сценариев оповещения при помощи разнообразных средств: факса, телефона, пейджера, мобильного телефона, электронной и голосовой почты и т. д.

Очень интересная, хотя и редко применяемая, возможность имеется в системах RealSecure OS Sensor и RealSecure Server Sensor. С ее помощью оповещение об обнаружении несанкционированной деятельности посылается не администратору, а злоумышленнику. По мнению разработчиков системы RealSecure, это дает понять нарушителю, что его обнаружили, и вынуждает его прекратить свои действия. И еще один вариант уведомления, который также реализован в системе RealSecure, когда информация об атаке посылается на консоль межсетевого экрана. Если речь идет о системе обнаружения атак RealSecure Network Sensor, разработанной компанией ISS, то в качестве межсетевого экрана выступает Lucent Managed Firewall компании Lucent. Для системы RealSecure, выпускаемой компанией Check Point в соответствии с соглашением с компанией Internet Security Systems, таким межсетевым экраном является Firewall-1.

Регистрация событий

О регистрации обнаруживаемых событий много писать нет необходимости т.к. это обязательное условие для любой системы обнаружения атак. Пожалуй, можно только отметить два аспекта — куда и в каком объеме записываются события. В качестве журнала регистрации может выступать текстовый файл, системный журнал (например, в системе Cisco Secure Integrated Software), текстовый файл специального формата (например, в системе Snort), локальная база данных MS Access (как в системе Internet Scanner), SQL-база данных (в системе Spitfire или RealSecure).

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

Второй тип подразумевает также фиксацию содержания всех передаваемых в рамках события данных. Например, сетевые системы обнаружения атак за­писывают все сетевые пакеты. Расширенный формат регистрации поддер­живается такими системами обнаружения атак, как Snort (листинг 8.20), Cisco Secure IDS, RealSecure и т. д.

Трассировка событий

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

Завершение соединения

Завершение соединения используется для прерывания действий атакующего. Этот механизм может быть реализован двояко. В системе обнаружения атак, функционирующей на уровне сети, механизм разрыва соединения заключается в его перехвате (session hijacking) и посылке пакета с установленным флагом RST атакуемому и злоумышленнику от имени каждого из участников (рис. 8.16).

У данного варианта реагирования, который реализован в системах RealSecure Network Sensor и Cisco Secure IDS, есть два ограничения. Он доступен только для событий, состоящих из нескольких пакетов и только для полностью установленных TCP-соединений. Например, для атаки WinNuke этот вариант не применим, т. к. она реализуется при помощи всего одного пакета. Также этот способ реагирования не подходит для атаки SYN Flood, поскольку полноценного TCP-соединения в процессе ее реализации не устанавливается.

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