На сегодняшний день базовым стандартом в теории обнаружения вторжений является набор правил Snort. Ранее использовались два основных набора правил, но некоторые проблемы с законом у Макса Вижина (Max Vision) привели к тому, что теперь его набор правил недоступен. Было очень интересно наблюдать совместный труд многих пользователей над созданием правил, уточнением списка контролируемых портов и объяснением уязвимых мест. Мне даже стыдно уделять так мало места описанию этого важного труда, но здесь нужно быть осторожными. Мы уже рассматривали проблему ложных тревог при обсуждении сигнатур и фильтров для выявления сигнатур. Теперь рассмотрим влияние принципа низко висящего плода на ложное отсутствие предупреждений. При чем здесь низко висящий плод?

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

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

Хотя ситуация, описанная в предыдущем абзаце, отчасти справедлива, но есть множество методов, чтобы избежать этой проблемы. Многие исследователи и поставщики систем обнаружения вторжений поддерживают связи с хакерами и имеют доступ к большему количеству атак, чем предоставляется на сайтах. Несколько исследователей стараются собрать все программы атаки с целью узнать все уязвимые места. К сожалению, они используют различные названия при описании одних и тех же атак. Организация Mitre (http://cve.mitre.org) руководит проектом под названием CVE (Computer Vulnerabilities and Exposures - уязвимые места и дефекты компьютерных программ), который получил широкую поддержку у производителей. Целью проекта является создание единой системы имен, которую можно было .бы использовать как словарь (или справочник) для описания уязвимых мест и создания систем обнаружения вторжений.

Кроме того, можно создать фильтр, позволяющий выявить целую группу программ атаки. Мы уже рассматривали один такой фильтр для выявления атак на Web-серверы. При его изучении мы рассказывали о большом количестве атак CGI-BIN на Web-серверы, в которых предпринималась попытка получить файл паролей для их последующего взлома. Самой известной является атака на сценарий PHF. Кроме того, существует еще около сотни подобных атак, включая атаки на РНР и aglimpse. В прошлом в пакете каждой из этих атак содержались строки cgi-bin и /etc/passwd, поэтому все подобные атаки можно было обнаружить с помощью одного общего фильтра. С появлением теневых файлов паролей количество атак с указанием файла /etc/passwd уменьшилось. Вместо этого в пакете обычно содержится следующая строка, id;uname -a; w

Команда id предоставляет действительный идентификатор пользователя, точка с запятой отделяет команды, команда uname -а выводит отчет об операционной системе (текущую версию, установленные заплаты), и, наконец, команда w предоставляет сведения обо всех зарегистрированных пользователях. Также можно (и крайне желательно) создать общие фильтры для выявления необычных событий (тех, что не должны происходить) и выдачи отчета об этих событиях. Примером такого события является получение пакетов со всеми установленными TCP-флагами, вообще без установленных флагов и пакетов неизвестных IP-протоколов. Существует много способов для усовершенствования средств обнаружения, однако следует задуматься: если система обнаружения взлома основана на сигнатурах и в ней не предусмотрен фильтр для выявления этой сигнатуры, как она сможет выявить атаку?

Человеческий фактор

На уровень обнаружения значимых событий и уведомления о них также влияет участие человека. В течение обычного рабочего дня оператор системы обнаружения вторжений регистрирует несколько происшествий и, возможно, сообщает о них. Если просмотреть годовой отчет о событиях на крупном узле, можно обнаружить отчеты о приблизительно 12 атаках на IMAP, 5 на portmap, 25 эхо-тестированиях по ICMP, 30 атаках Smurf, 8 сканированиях ms s с ап, 5 сканированиях портов, 5 попытках переноса зоны DNS, 4 атаках WinNukes и т.д. Если обратиться к группе CIRT крупной сети, то мы узнаем, что обо всех этих инцидентах сообщали только некоторые администраторы узлов этой сети. Почему так происходит? Не только потому, что система обнаружения вторжений не смогла отреагировать на атаку из-за отсутствия нужной сигнатуры. Зачастую аналитики сетевого трафика сами не сообщают о выявленных инцидентах.

Если потратить день или два на поиск в Internet, можно без труда собрать сотни различных программ атаки. Компиляция некоторых из них потребует определенных усилий, для других не предоставляется полной документации. Но факт остается фактом - можно легко найти большее число атак, чем было обнаружено и описано. А в чем же проблема? Частично это объясняется тем, что не так просто определить нужную сигнатуру. Если система работает на основе сигнатур, а фильтра не существует, выявить событие невозможно. Другие факторы, снижающие способности выявления значимых событий системами обнаружения вторжений, связаны с аналитиками сетевого трафика и группами CIRT (Computer Incident Response Team - группа реагирования на угрозы безопасности компьютеров).

Ограничения, связанные с аналитиками

Часть ответственности за необнаруженные атаки лежит на аналитиках сетевого трафика. Тому есть несколько причин. Иногда аналитики пренебрегают попытками взлома и считают их недостаточно серьезными для глубокого анализа. Я и сам так поступал много раз. Бот классический пример: вирус Code Red по-прежнему действует только потому, что некоторым людям не хватает соображения установить заплаты для своих IIS-серверов. Однажды на моем узле было зарегистрировано большое число попыток подключения к порту 80, но я не стал глубоко их анализировать, сообразив, что это действие Code Red. Однако в феврале 2002 года, когда появились сведения о выявлении уязвимого места в сценарии РНР сервера Apache, мне пришлось изменить свое отношение. В конце концов, ведь на моем хосте также запущен Apache.

Сообщают ли аналитики о тех атаках, которых они сами не поняли? Чтобы понять смысл неизвестных методов атаки, необходимо обладать глубокими знаниями о теории стека TCP/IP и процессах, происходящих в компьютерных системах. А что если аналитик не доверяет собственной системе обнаружения вторжений? Требуется немалая уверенность в своей системе, чтобы принимать решение только по информации предупреждения, выдаваемого на экран. И практически слепое доверие необходимо, когда система обнаружения вторжений сообщает о двух атаках Wiz в день (Wiz- это очень старая атака на электронную почту) и шести SYN-наводнениях в час (очевидно, что имеют место ложные тревоги). Таким образом, аналитики явно являются слабым звеном в системе обнаружения вторжений. Основные причины этого:

■ нежелание сообщать о событиях, выявленных системой обнаружения вторжений;

■ недостаток знаний, необходимых для выявления новых атак;

■ недостаточные знания о протоколах стека TCP/IP и сетевых службах;

■ недоверие к самой системе обнаружения вторжений.

Ограничения, связанные с группами CIRT

Могут ли группы CIRT не уведомлять о каких-то выявленных атаках? Если эта группа получит отчет об атаке на IMAP, portmap, сканировании ICMP, атаках Smurf, mscan, portscan, переносе зоны DNS или чем-либо подобном, то все будет нормально. Они внесут это сообщение в свою базу данных, доступную всем пользователям. Но что будет, если группа CIRT получит приблизительно такое уведомление “Неизвестный тип зондирования. Вот его трассировка. Эта атака привела к отказу моего компьютера”? Человек, который сообщил об атаке, вероятно, новичок. Кроме того, возникает проблема отсутствия нужного раздела в базе данных. Профессиональные аналитики обычно перегружены работой, и опытные сотрудники групп CIRT обычно выходят из себя при получении отчетов о (как часто оказывается впоследствии) ложных тревогах. Отношение будет другим только при получении второго подобного отчета из другого источника. Такая задержка может быть очень опасной при активном использовании новой атаки. С момента, когда я впервые узнал об уязвимом месте в klogin в мае 2000 года, прошло менее 8 часов до компрометации нашей первой системы.

Это серьезная проблема, потому что группы CIRT практически всегда недо-укомплектованы. Люди звонят по телефонам и просят о помощи, так как их компьютеры скомпрометированы, а в их организации никогда не относились серьезно к безопасности. Этим людям помощь необходима в первую очередь. В конце месяца или квартала CIRT издает свой отчет, в котором уведомляется об обнаружении такого-то количества попыток проведения каждой конкретной атаки. Неопытный аналитик сетевого трафика, сообщивший о неизвестном типе атаке, видит, что в отчете CIRT о его случае нет и слова, и решает больше никогда не сообщать о происшествиях. При этом он не знает, сочли сотрудники CIRT его уведомление ошибочным, или им просто все равно. Вот почему мы сделали сознательный выбор в пользу Incidents.org - добровольного объединения всех групп CIRT и организаций обеспечения безопасности в Internet. Именно этой организации мы прежде всего отправляем наши уведомления обо всех неизвестных шаблонах атаки и добавляем следующий комментарий: “Мы понятия не имеем, что это такое. Может ли нам кто-нибудь помочь?”. Не один раз полученный ответ меня смущал, так как я должен был узнать эту атаку. Со временем мы научились работать подобно CIRT и отправлять запросы только в случае крайней необходимости. Мы стали осторожнее в призывах о помощи, и это может привести к успеху атаки прежде, чем мы самостоятельно сможем ее выявить и заблокировать. Мы знаем, что не следует быть слишком замкнутыми, но так трудно бороться со своим характером.

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

Степень угрозы

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

Это происходит постоянно

Однажды группу обнаружения вторжений, в которой я работал на протяжении нескольких лет, пригласили провести день в обществе очень большой группы CIRT. В состав этой группы CIRT входил отдел аналитиков сетевого трафика, которые только что получили новые возможности обнаружения атак с помощью интерфейса, позволяющего контролировать большое количество датчиков. Нам всем показалось очень интересным понаблюдать за работой группы аналитиков, использующих систему Shadow, и оценить эффективность нового программного интерфейса. Через четыре минуты одна из аналитиков обнаружила сигнатуру, указывающую на взлом с правами суперпользователя на одном из близких нам узлов. Она хотела позвонить на узел и сообщить им об атаке, но сотрудники CIRT рассмеялись, сказав: “Это происходит постоянно”. Несомненно, с их точки зрения это было справедливо. За год они, вероятно, получают уведомления о таком числе взломов, с каким я не сталкивался за свою жизнь. Мне было не по себе, так как я знаю, сколько проблем и неприятностей несет взлом системы ее владельцам и тем, кто им помогает. Поэтому степень угрозы лучше всего оценивать владельцам взломанных систем.

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

Рис. 16.3. Степень угрозы

Действительно ли ненаправленные атаки на уязвимые места, которые отсутствуют на атакуемом компьютере, не представляют никакой опасности? С научной точки зрения одним из элементов уравнения для оценки риска считается уровень уверенности - насколько вы уверены, что в программном обеспечении ваших систем нет уязвимых мест. Я скорее консерватор. Поэтому считаю, что я ненаправленные, “безвредные” атаки не представляют опасности только тогда, когда они дополнительно блокируются брандмауэром или фильтрующим маршрутизатором. В этом случае можно говорить об отрицательном риске. Злоумышленник сам подвергается большей опасности, когда использует ненаправленную атаку против хорошо защищенного узла, чем этот узел, так как об атаке будет сообщено. Если он добьется успеха и причинит ущерб на других узлах, то, по крайней мере, повышается вероятность его обнаружить.

Как можно оценить степень угрозы? Какие основные факторы? Можно ли написать уравнение? Насколько высока вероятность того, что атака нанесет ущерб, и насколько серьезным он будет? Очевидно, все это должно быть учтено.

Важность цели

В теории оценки риска одним из важнейших факторов является важность атакуемой цели. Когда-то, выступая в Вашингтоне, я хотел привлечь внимание к антивирусам и брандмауэрам на персональных компьютерах. Я спросил у аудитории: “Сколько из вас путешествуют по несколько раз в год?”. Большинство слушателей подняли руки вверх, что вполне нормально для офицеров штаба. Тогда я спросил: “Сколько из вас берут с собой “Кипро?”. “Кипро” - это антибиотик против сибирской язвы. Поскольку до октября 2001 года никто не слышал о рассылке бактерий по почте, то об этом никто и не думал. Однако я только могу представить себе, что было бы, будь я в незнакомом городе, и вдруг у меня начались боли, сильнее которых не было в моей жизни. Как мне получить высококвалифицированную медицинскую помощь? Дома у меня есть личный врач, который меня знает, медицинская карточка и друзья-доктора. В Хьюстоне, Сиэтле или Нью-Йорке придется обращаться в отделение скорой помощи. Практически невозможно ждать 12 часов, чтобы тебя осмотрели в приемном отделении. Насколько это серьезно? Эта загадка может любого вывести из равновесия. Теперь, чтобы вы не думали, что я не встаю со своего кресла-качалки без “Кипро”, уточню, что тоже много путешествую и, хотя стараюсь не пить сырой воды и чищу фрукты, все равно лучше иметь средство наподобие “Кипро” на всякий случай. Какое это имеет отношение к антивирусам или персональным брандмауэрам? Если, не имея этих средств, вы будете “путешествовать” по Internet, то можете оказаться в сложной ситуации, сравнимой с заболеванием сибирской язвой и одновременным отсутствием “Кирпо”.

Будет не очень хорошо, если я заболею сибирской язвой, но еще хуже, если ею заболеет президент Соединенных Штатов. Основным критерием для оценки опасности является важность цели атаки. При взломе настольного компьютера могут быть потеряны время и результаты работы. Кроме того, эта система может использоваться как стартовая площадка для организации последующих атак. Однако при компрометации сервера DNS или сервера электронной почты возникающие проблемы гораздо серьезнее. Действительно, если взломщик сможет контролировать сервер DNS, то он сможет манипулировать доверительными отношениями и скомпрометировать большинство или все системы локальной сети. Для создания метрики требуется определить способ оценки важности цели. Для этого можно использовать простую пятибалльную шкалу.

5 баллов Брандмауэр, DNS-сервер, основной маршрутизатор 4 балла Сервер электронной почты 2 балла Настольная пользовательская UNIX-система 1 балл Система MS DOS 3.11

Уровень риска

Уровень риска атаки определяет то, какой ущерб она может причинить. Программы атаки обычно предназначены для использования уязвимых мест опреде ленных приложений или операционных систем. Компьютер под управлением Macintosh не уязвим для программы атаки на переполнение буфера на сервере объектной базы данных ToolTalk системы UNIX или атаки на службу rpc . statd. Если же эти атаки будут использованы против хоста Sun Microsystems, на котором запущена версия Solaris без установленных заплат, то атакованный хост может быстро перейти в “собственность” хакера. Как аналитик сетевого трафика, я всегда беспокоюсь, когда нарушитель атакует конкретную цель при помощи подходящей программы атаки. Это означает, что он уже провел предварительную разведку, и что нужно предпринимать дополнительные меры противодействия для защиты атакуемой цели. Для оценки степени риска снова воспользуемся пятибалльной системой.

5 баллов Злоумышленник получает права суперпользователя на всех хостах локальной сети 4 балла Полное блокирование с помощью атаки отказа в обслуживании 4 балла Доступ посредством учетной записи пользователя (например, с помощью взломанного пароля)

1 балл Малая вероятность успеха атаки (например, для атаки Wiz в 2002 году)

Последний пример в 1 балл для атаки Wiz позволяет продемонстрировать действительно важный момент при оценке степени риска атак - новизну атаки. Для описания этого аспекта используют кривую риска. У хакеров есть специальный термин точка отсчета (zero day), который относится к началу использования атаки, которая еще не известна общественности. Программа атаки работает хорошо, и ее держат в секрете несколько человек, применяющие ее для взлома систем. Это высшая точка кривой риска, но при этом число атак еще сравнительно мало. Со временем атака обнаруживается и описывается. Теперь о ней уже знает и сообщество пользователей, и другие злоумышленники. Возникает условие “гонки на выживание” - злоумышленники стремятся скорее использовать атаку и взломать чужие системы, а специалисты по безопасности стараются быстрее создать заплаты, загрузить новые сигнатуры для систем обнаружения взлома или предпринять другие меры защиты. На этом этапе атака еще очень опасна, но кривая риска начинает снижаться, в то время как количество случаев взлома возрастает. Наконец, мы достигаем гребня волны. Все больше системных администраторов устанавливают заплаты или используют другие контрмеры, и со временем атака становится все менее и менее опасной.

Меры противодействия

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

5 баллов Современная операционная система со всеми доступными запла тами, с установленными средствами обеспечения безопасности, такими как TCP Wrappers и служба SSH

3 балла Устаревшая операционная система, некоторые заплаты отсутствуют 1 балл Никаких средств защиты, разрешено использование постоянных незашифрованных паролей

Пятибалльная шкала для сетевых мер противодействия выглядит так.

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

Используется несколько внешних соединений (модемные, ISDN)

2 балла Брандмауэр, разрешающий прохождение большинства пакетов

(основной вопрос: “позволяет ли брандмауэр провести атаку?”)

Вычисление степени угрозы

Аналитики сетевого трафика, прошедшие курс обучения в GIAC, для вычисления степени угрозы атаки используют следующую формулу.

(Важность цели + Уровень риска) - (Системные + сетевые меры противодействия)

= Степень угрозы

Рассмотрим несколько примеров. Они взяты из практического курса получения сертификата сетевого аналитика в GIAC. Чтобы не вырывать эти примеры из контекста, опишем весь процесс анализа, сосредоточив основное внимание на степени угрозы.

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

Поиск троянских программ

Первый пример взят из трассировки, выбранной Дэвидом Липхартом (David Leaphart) для использования в своих практических занятиях. Для начала скажем, что запись первой строки свидетельствует о том, что 24 марта в 1:54 ночи хост-отправитель 24.3.57.38, использовав порт 11111, подключился к ТСР-порту получателя 12 34 5 хоста 24.3 .21.199.

Маг 24 01:54:58 сс1014244-а kernel: securityalert: tcp if=ef0 from 24.3.57.38:11111 to 24.3.21.199 on unserved port 12345 Mar 24 03:14:13 ccl014244-a kernel: securityalert: tcp if=ef0 from % 171.214.113.228:2766 to 24.3.21.199 on unserved port 1243 Mar 24 04:45:01 ccl014244-a kernel: securityalert: tcp if=ef0 from

208.61.109.243:3578 to 24.3.21.199 on unserved port 1243 Mar 24 04:45:06 ccl014244-a kernel: securityalert: tcp if=ef0 from Ъ 208.61.109.243:3832 to 24.3.21.199 on unserved port 27347 Mar 24 05:40:42 ccl014244-a kernel: securityalert: udp if=ef0 from 24.24.100.172:2147 to 24.3.21.199 on unserved port 137 Mar 24 14:56:08 ccl014244-a kernel: securityalert: udp if=ef0 from 63.17.79.40:4294 to 24.3.21.199 on unserved port 137 Mar 24 17:20:44 ccl014244-a kernel: securityalert: tcp if=ef0 from

62.6.100.45:1828 to 24.3.21.199 on unserved port 27374 Mar 24 20:50:47 ccl014244-a kernel: securityalert: tcp if=ef0 from 194.27.62.179:4857 to 24.3.21.199 on unserved port 27374

Анализ

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

■ Есть ли доказательства направленности атаки?

Да. Трафик от отправителя поступает на интерфейс конкретного хоста.

■ Есть ли записи в архиве?

Нет. Все переданные пакеты зафиксированы в отчете.

■ В чем заключается метод атаки?

TCP- и UDP-пакеты были направлены на конкретный хост. SYN-пакеты были направлены на ТСР-порты 12345, 1243, 27347 и 27374. UDP-пакеты предназначались UDP-порту 137. Отправитель надеется на получение в ответ SYN/АСК-пакета или отсутствие ответа на UDP-пакет. Сканирование портов осуществлялось с разных компьютеров в течение нескольких часов. Все IP-адреса отправителей принадлежат активным хостам, подключенным к Internet, и, по всей видимости, не подменялись.

■ Есть ли доказательства злого умысла хакера?

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

■ порт 12345 программы Netbus и TrendMicro;

■ порт 1243 троянские программы SubSeven и Backdoor-G;

■ порт 27374 программа SubSeven 2.0;

■ порт 27347 возможно, случайность, опечатка вместо 27374;

■ порт 137 NetBIOS.

Аналитик сетевого трафика должен сам проверить атакованный хост на наличие троянских программ и убедиться в нормальном функционировании NetBIOS.

■ Отдельный злоумышленник или группа?

Судя по информации службы whois, IP-адреса отправителей принадлежат хостам различных сетей. Они не связаны ни географически, ни хронологически. На последние адреса, однако, следует обратить особое внимание, так как они принадлежат хостам в Турции. Это вредоносное сканирование, но атакованный хост надежно блокирует атаку.

Степень опасности

Оценить степень опасности этой атаки можно следующим образом.

■ Важность цели - 2 балла при условии, что сервер не является критически важным.

■ Уровень риска - 4 балла, так как эти программы атаки способны причинить серьезный вред.

■ Меры противодействия - 5 баллов при условии, что для операционной системы установлены все программные заплаты.

■ Сетевые меры противодействия - 0 баллов, так как, по всей вероятности, брандмауэр отсутствует.

Сканирование хостов по FTP

Рассмотрим еще один пример (табл. 16.1), который предоставил нам Эрик Брок (Eric Brock). Для сбора этой информации он использовал брандмауэр Wire Wall-1.

Анализ

Перед тем как начать анализ атаки, хотим обратить внимание на тот факт, что пакеты поступили в нашу демилитаризованную зону. Очень важно найти записи в архиве. В следующем исследовании мы рассмотрим записи в архиве нашей демилитаризованной зоны. Однако с помощью программы dshield (http:/www.dshield.org/ipinfо-php) мы можем выполнить поиск по IP-адресам отправителей также и в архивах на других узлах сети. Мы опишем использованный метод сканирования и попытаемся наиболее точно определить предназначение полученных пакетов.

■ Исходные данные. К нам обращается кто-то, заявляющий, что его 1Р-адрес 195.243.30.140.

■ Архив. В архиве не содержится никаких записей о предыдущих соединениях с этим хостом.

■ Методы. Отправитель посылает по одному FTP-пакету на каждый хост нашей сети. Пакеты передаются очень быстро.

■ Намерения. Отправитель стремится найти в нашей сети хосты, которые отвечают на запрос к порту службы FTP.

■ Направление атаки. Целью сканирования является вся наша сеть без выделения конкретных серверов.

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

Степень опасности

При оценке степени опасности атаки используется ряд показателей.

■ Важность цели - 3 балла, так как не было направленного сканирования отдельных серверов.

■ Уровень риска - 4 балла, так как существует много уязвимых мест в программном обеспечении службы FTP.

Таблица 16.1. Сводные данные о сканировании хостов по ГТР

Идентификатор

Дата

Время

1Р-адрес отправителя

Порт отправителя

1Р-адрес получателя

Порт получателя

Протокол

Размер

661530

21РеЬ2000

9:09:24

195.243.30.140

4858

10.10.1.1

ГТР

ТСР

1сп 60

661531

21РеЬ2000

9:09:24

195.243.30.140

4857

10.10.1.0

РТР

ТСР

1еп 60

661532

211'еЬ2000

9:09:24

195.243.30.140

4860

10.10.1.0

РТР

ТСР

1еп 60

661533

21РеЬ2000

9:09:24

195.243.30.140

4859

10.10.1.0

РТР

ТСР

1еп 60

661632

21РеЬ2000

9:09:25

195.243.30.140

1144

10.10.1.252

РТР

ТСР

1еп 60

661633

21РеЬ2000

9:09:25

195.243.30.140

1145

10.10.1.253

РТР

ТСР

1еп 60

661634

21РеЬ2000

9:09:25

195.243.30.140

1146

10.10.1.254

РТР

ТСР

1еп 60

■ Системные меры противодействия - 2 балла, на всех операционных системах установлены последние заплаты, но на некоторых хостах открыты порты службы FTP.

■ Сетевые меры противодействия - 4 балла, так как брандмауэр блокирует все входящие FTP-пакеты.

■ Степень угрозы равна 1. Она определяется по формуле:

(Важность цели + Уровень риска) - (Системные + сетевые меры противодействия) = Степень угрозы

Размещение датчиков

Сетевая система обнаружения вторжения не будет работать без средств обнаружения (датчиков), а если датчики установлены неправильно, действует неэффективно. Датчики следует устанавливать рядом с брандмауэром.

Перед брандмауэром

Обычно датчики систем обнаружения взлома устанавливают перед брандмауэром в демилитаризованной зоне3 (рис. 16.4). Таким образом, датчик может регистрировать все атаки, поступающие из Ітегпеї. Однако если для проведения атаки используется протокол ТСР, и она блокируется брандмауэром или фильтрующим маршрутизатором, то система обнаружения вторжения может ее не выявить. Многие атаки обнаруживаются только при совпадении полученных данных с заданной строкой сигнатуры. Строка символов не отправляется до завершения полной процедуры установки ТСР-соединения.

Несмотря на то что некоторые атаки не будут выявлены при установке датчика перед брандмауэром, все равно это лучшее место для размещения датчика. Преимущество заключается в том, что аналитики сетевого трафика могут видеть все атаки, которым подвергается их узел и брандмауэр. Один из рецензентов книги сказал об этом так: “Перед брандмауэром мы выявляем атаку, а за брандмауэром - взлом”.

Рис. 16.4. Датчик (детектор событий) установлен в демилитаризованной зоне

В конце 1997 и начале 1998 годов на многих узлах были зарегистрированы попытки доступа к TCP/UDP-порту 111 (portmapper). На компьютерах с открытыми портами portmapper скорее всего был запущен демон rpc.statd. Я использовал программу сканирования уязвимых мест на двух узлах, чтобы оценить степень риска. Сканирование выявило более 50 систем, которые бы ответили на запрос rpcinfo -р (что означает наличие незащищенной службы portmapper). Дальнейшее исследование показало, что на этих хостах был запущен демон statd. Таким образом, хосты сетей, которые подвергались атакам, были уязвимы. Однако на обоих узлах брандмауэры блокировали атаки на службу и любые попытки непосредственного доступа к демону statd. Это лишний раз убедило меня в необходимости приложить все усилия, чтобы защитить службы преобразования портов и контролировать установку всех последних заплат для службы statd. Более подробную информацию по этой теме можно получить по адресу www.cert.org/advisories/CA-9 7.26.statd.html.

Датчики за брандмауэром

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

Абсолютно справедливо, что правильно настроенные брандмауэры блокируют большинство простых попыток проведения атак. И правда то, что слишком много внимания уделяется обнаружению и исследованию этих простых атак.

И перед, и за брандмауэром

Чем больше, тем лучше. Для меня это не просто поговорка. Я устанавливаю датчики с обеих сторон брандмауэра. Если ваша организация может себе позволить установить датчики и перед, и за брандмауэром, то это даст определенные преимущества, например:

• не нужно угадывать, пропустит ли брандмауэр атаку;

■ есть возможность выявлять атаки внутри локальной сети;

■ можно обнаружить неверную настройку некоторых систем, которая не позволяет их пакетам проходить через брандмауэр (и тем самым оказать помощь системному администратору).

Если в организации используется дорогостоящая система обнаружения вторжений, то, может, она того и не стоит. Лучше установить датчики перед и за брандмауэром, и внутренний датчик уведомит об опасности.

Неверно сконфигурированные системы

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

• Широковещательные рассылки localhost 127.0.0.1 или 127.0.0.2 во внутренней подсети.

• Неправильная конфигурация файлов DNS. Они читаются справа налево. Например, если адрес сети 172.20.0.0/24, и вы обнаружили хост (172.20.30.40), выполняющий широковещательную рассылку по адресу 255 . зо . 20 .172, то, скорее всего, кто-то не знает, что файлы конфигурации домена читаются справа налево.

• Некорректная маска подсети. Широковещательные рассылки отправляются по адресу 172.20.255.255 вместо 172.20.30.255.

• Потайные ходы. Когда регистрируется пакет, поступающий из Internet на адрес 172 .20.30.255 (используем адрес сети из предыдущего примера), то весьма вероятно, что хакером установлен потайной ход. Пакет, предназначенный для передачи в локальной сети, не должен существовать за пределами брандмауэра.

Другие места установки датчиков

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

■ сети партнеров, с которыми устанавливаются прямые соединения, заказчиков или поставщиков, нередко работающих на хостах вашей сети, защищенной брандмауэром;

■ особо важные места, например научные лаборатории или сети бухгалтерии;

■ сети с большим количеством временных пользователей;

■ подсети, которые могут стать мишенью для атак извне, или в которых выявлены признаки взлома или другие отклонения от нормальной работы.

Последний вопрос, связанный с размещением датчиков, - к чему их подключать. Современные сети практически полностью представляют собой коммутируемые сети VLAN (Virtual Local Area Network - виртуальная локальная вычислительная сеть). Датчики могут работать в таких средах. Однако, если связующие порты коммутатора сконфигурированы неверно, то обнаружение взлома будет невозможным. Не забывайте, что использование несколькими сетями VLAN общего связующего дерева (Spanning Tree) дает большую нагрузку на коммутатор. Если датчик должен работать в коммутируемой сети, то его обязательно нужно протестировать. Протокол TCP является дуплексным, и аналитик сетевого трафика должен убедиться, что датчик получает данные от каждой стороны соединения. Кроме того, датчик должен без ошибок передавать данные из коймути-руемой сети. Возможно, что для датчика потребуется установка двух сетевых адаптеров. Первый из них, присоединенный к связующему порту, позволяет контролировать трафик, передающийся в неразборчивом режиме (перехват всех пакетов, независимо от того, предназначались ли они датчику). Второй сетевой адаптер, который будет взаимодействовать с хостом аналитика, можно “разместить” в отдельной сети VLAN. Безусловно, трата денег на решение проблемы - один из лучших методов в технологии обнаружения вторжений. Для того чтобы устранить проблемы с конфигурацией или нагрузкой в сети, можно предпринять следующие действия.

■ Установить сетевые ответвители, которые подключаются непосредственно к среде передачи данных и позволяют датчику перехватывать все данные, проходящие через этот ответвитель.

■ Использовать коммутатор компании TopLayer (www.toplayer.com), позволяющий копировать передаваемые в сети данные в систему обнаружения вторжений.

■ Задействовать коммутаторы Cisco Catalyst 6000, поддерживающие дополнительную опцию Policy Feature Card, которая также позволяет управлять процессом копирования трафика в систему обнаружения вторжений.

Системы доставки и системы отправления сообщений

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

Предотвращение атаки митника | Обнаружение нарушений безопасности в сетях | Системы обнаружения вторжений на основе доставки сообщений


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



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

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