Коллектив авторов - Защита от хакеров корпоративных сетей
Программа congestant является другим заслуживающим упоминания инструментальным средством, в котором реализовано ряд способов модификации пакетов, затрудняющих работу системы обнаружения вторжения. Ее автор называет себя «horizon». Впервые программа описана в его работе «Победа над сетевыми анализаторами сети и системами обнаружения вторжения» (Defeating Sniffers and Intrusion Detection Systems), которая была опубликована в декабре 1998 года (www.phrack.org/show.php?p=54&a=10). В отличие от предыдущей программы, программа congestant реализована в виде разделяемой библиотеки или патча к ядру операционной системы OpenBSD. Читатель может использовать программы fragrouter и congestant совместно, исследуя слабые стороны используемой им системы обнаружения вторжения.
Повышение сложности системы обнаружения вторжения, увеличение ее накладных расходов предоставляет дополнительные преимущества злоумышленнику. Эти системы становятся более подверженными к атакам типа отказ в обслуживании (DoS), поэтому маловероятно сохранение их работоспособности в критической ситуации. Вполне очевидно, что в системы обнаружения вторжения по мере их совершенствования всегда будут включать новые возможности и режимы работы, поскольку атакующий всегда будет выискивать в них узкие места (системы обнаружения вторжения могут использовать многие критические операции центрального процессора, требующие для своего выполнения значительных ресурсов).
Ниже представлены результаты работы программы fragrouter, запущенной командным процессором. Программа поддерживает стандарт plug-and-play. Читателю следует только убедиться, что его система машрутизирует трафик к адресату через хост с работающей программой fragrouter:
storm:~/dl/fragrouter-1.6# ./fragrouter -F5
fragrouter: frag-5: out of order 8-byte fragments, one duplicate
truncated-tcp 8 (frag 21150: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 21150: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 21150: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 21150: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 21150: [email protected])
truncated-tcp 8 (frag 57499: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57499: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57499: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57499: [email protected])
truncated-tcp 8 (frag 57500: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57500: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57500: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 57500: [email protected])
truncated-tcp 8 (frag 58289: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 58289: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 58289: [email protected]+)
10.10.42.9 > 10.10.42.3: (frag 58289: [email protected])Ниже приведен вывод утилиты tcpdump, иллюстрирующий разницу между обычным сетевым трафиком и трафиком в сети при запуске программы fragrouter в режиме F5 «fragrouter: frag-5: беспорядочные восьмибайтовые фрагменты c одним дубликатом («fragrouter: frag-5: out of order 8-byte fragments, one duplicate»)». Обратите внимание на флаги DF (Don't Fragment – не фрагментировать) каждого пакета обычного соединения и наличие в потоке программы fragrouter нескольких фрагментированных пакетов.
Before (no fragrouter):
19:36:52.469751 10.10.42.9.32920 > 10.10.42.3.7: S
1180574360: 1180574360(0) win 24820 <nop,nop,sackOK,mss
1460> (DF)
19:36:52.469815 10.10.42.9.32920 > 10.10.42.3.7: S
1180574360: 1180574360(0) win 24820 <nop,nop,sackOK,mss
1460> (DF)
19:36:52.470822 10.10.42.9.32920 > 10.10.42.3.7: . ack
4206722337 win 24820 (DF)
19:36:52.470841 10.10.42.9.32920 > 10.10.42.3.7: . ack 1 win
24820 (DF)
19:36:53.165813 10.10.42.9.32920 > 10.10.42.3.7: F 0:0(0)
ack 1 win 24820 (DF)
19:36:53.165884 10.10.42.9.32920 > 10.10.42.3.7: F 0:0(0)
ack 1 win 24820 (DF)
19:36:53.171968 10.10.42.9.32920 > 10.10.42.3.7: . ack 2 win
24820 (DF)
19:36:53.171984 10.10.42.9.32920 > 10.10.42.3.7: . ack 2 win
24820 (DF)After (with fragrouter):
19:37:29.528452 10.10.42.9.32921 > 10.10.42.3.7: S
1189855959: 1189855959(0) win 24820 <nop,nop,sackOK,mss
1460> (DF)
19:37:29.528527 10.10.42.9.32921 > 10.10.42.3.7: S
1189855959: 1189855959(0) win 24820 <nop,nop,sackOK,mss
1460> (DF)
19:37:29.529167 10.10.42.9.32921 > 10.10.42.3.7: [|tcp]
(frag 21150: [email protected]+)
19:37:29.529532 10.10.42.9.32921 > 10.10.42.3.7: . ack
4211652507 win 24820 (DF)
19:37:29.529564 10.10.42.9.32921 > 10.10.42.3.7: . ack 1 win
24820 (DF)
19:37:29.530293 10.10.42.9.32921 > 10.10.42.3.7: [|tcp]
(frag 57499: [email protected]+)
19:37:30.309450 10.10.42.9.32921 > 10.10.42.3.7: F 0:0(0)
ack 1 win 24820 (DF)
19:37:30.309530 10.10.42.9.32921 > 10.10.42.3.7: F 0:0(0)
ack 1 win 24820 (DF)
19:37:30.310082 10.10.42.9.32921 > 10.10.42.3.7: [|tcp]
(frag 57500: [email protected]+)
19:37:30.316337 10.10.42.9.32921 > 10.10.42.3.7: . ack 2 win
24820 (DF)
19:37:30.316357 10.10.42.9.32921 > 10.10.42.3.7: . ack 2 win
24820 (DF)
19:37:30.316695 10.10.42.9.32921 > 10.10.42.3.7: [|tcp]
(frag 58289: [email protected]+)
Контрмеры
К счастью, идя навстречу пожеланиям реализовать сетевые системы обнаружения вторжения повсюду в сетевой инфраструктуре, появились технологии, которые помогут исключить большое число уязвимостей протокола более низкого уровня. Нормализация протокола, обсужденная Марком Хандлейом (Mark Handley) и Верном Пакссоном (Vern Paxson) в мае 2001 года в работе «Обнаружение вторжения в сеть: уклонение, нормализация трафика и семантики сквозного протокола» (Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics), www.aciri.org/vern/papers/norm-usenix-sec-01-html/index.html, является попыткой вычистить или перезаписать сетевой трафик по мере его получения адресуемой сетью. Описанный в работе процесс чистки должен устранить большое число трудностей восстановления последовательного представления сетевого трафика. Если бы и система обнаружения вторжения, и хост-адресат находились бы за программой чистки протокола, то они оба получали бы идентичное представление сетевого трафика....Инструментарий и ловушки
Наживка на приманку
Недавно был отмечен рост числа использования программ-приманок ( honeynets) в интересах защиты сетей. Программа-приманка является программной системой, которая размещается для того, чтобы привлечь внимание злоумышленника, который попытался бы ее скомпрометировать. Это чрезвычайно защищенные инструментальные средства, которые могут быть размещены и приведены в действие в любом месте внутри сети. В настоящее время принято считать, что наилучшим вариантом использования программ-приманок является размещение в сети двух систем, одна из которых является приманкой, а другая предназначена для регистрации трафика.
Регистрирующий хост должен быть сконфигурирован как мост (невидимый для любого удаленного атакующего) с достаточным дисковым пространством для записи всего сетевого трафика, для того чтобы его впоследствии можно было проанализировать. Система, расположенная за регистрирующим хостом, может быть сконфигурирована любым способом. Большинство из них являются приманками. Это означает, что размещенные за регистрирующим хостом системы предназначены стать мишенью для атак злоумышленников. Расчет основан на том, что злоумышленники увидят хост-приманку и начнут его атаковать. Было отмечены причины конфигурирования систем-приманок аналогично другим работающим системам в атакуемой сети (будем надеяться, что они достаточно надежны). В результате если атака будет обнаружена программой-приманкой (а она такова, что никто не сможет передать ей никаких данных, оставаясь при этом необнаруженным), то обороняющийся может удостовериться в существовании уязвимостей в конфигурации работающих систем. Учитывая дополнительные преимущества детальной регистрации трафика, некоторые работающие на низком уровне «прокурорские» программы (forensics) выявляют информацию об уязвимости сети наряду с ее любыми потайными лазейками, с помощью которых злоумышленник может вломиться в сеть и натворить в ней дел.
Имейте в виду, нет систем с защитой «от дурака». У атакующих есть возможность понять, что они находятся позади моста. В этом им поможет отсутствие трафика на уровне канала передачи данных и несоответствия в адресах протокола управления доступом к передающей среде (подуровень канального уровня, задающий методы доступа к среде, формат кадров, способ адресации), записанных в ARP кэше системы приманки.
Для более подробного ознакомления с системами-приманками читателю рекомендуется обратиться по адресу http://project.honeynet.org.
Уклонение на уровне приложений
У датчиков системы обнаружения вторжения есть возможность исследовать внутреннее устройство протокола связи приложений в интересах обнаружения вторжения. Разработчики систем обнаружения вторжения используют два основных способа. Во-первых, декодирование протокола приложений, когда система обнаружения вторжения предпринимает попытки разобрать поступающую к ней сетевую информацию для определения законности запросов сервисов. Во-вторых, простое сравнение характерных признаков сетевой активности с сигнатурами (сопоставление сигнатур). Каждый их этих двух подходов обладает свойственными им собственными достоинствами и недостатками. Можно увидеть, что большинство систем обнаружения вторжения по существу являются гибридом этих решений. На каждом уровне стека протокола есть возможность избежать вторжения.
Защита вдогонку
Деятельность разработчиков приложений определяется открывающимися перед ними перспективами и возможностью заработать. Всем известно, что в итоге успех или неудачу программного обеспечения определяет конечный пользователь. Прилагая все усилия для обеспечения наиболее удобной работы пользователя, максимальной совместимости программы и исключения ошибочных ситуаций, разработчики жертвуют строгим соответствием спецификациям протокола, отдавая предпочтение вопросам исправления ошибок. Нечасто можно встретить приложение, которое немедленно бы завершало запрос при первых признаках отклонения от определенного протокола. Напротив, предпринимаются все возможные и невозможные усилия для восстановления любых ошибок в попытке обслужить любой запрос (и таким образом увеличивается совместимость приложения и, вероятно, способность к взаимодействию). Исследователь вопросов безопасности, известный под псевдонимом Форест Паппи (Forest Puppy), или, что используется гораздо чаще, RFP, на конференции CanSecWest Security 2001 года (CanSecWest Security Conference 2001) утверждал: «Можно только удивляться тому, что передается через законный трафик по протоколу HTTP…» Подобная практика ведет к снижению безопасности приложений, поскольку она помогает атакующему, расширяя его злоумышленные возможности.
