учебники, программирование, основы, введение в,

 

Системы обнаружения вторжений

В предыдущей лекции мы ознакомились с сетевыми анализаторами и многими полезными вещами, которые можно делать с их помощью. Анализаторы можно использовать даже для выявления подозрительной активности в сети. Еще один шаг в этом направлении можно сделать, используя программное обеспечение, называемое системами обнаружения вторжений. По сути эти программы представляют собой модифицированные анализаторы, которые видят все потоки данных в сети, пытаются выявить потенциально вредный сетевой трафик и предупредить вас, когда таковой появляется. Основной метод их действия заключается в исследовании проходящего трафика и сравнении его с базой данных известных шаблонов вредоносной активности, называемых сигнатурами. Использование сигнатур очень похоже на работу антивирусных программ. Большинство видов атак на уровне TCP/IP имеют характерные особенности. Система обнаружения вторжений может выявлять атаки на основе IP-адресов, номеров портов, информационного наполнения и произвольного числа критериев. Существует другой способ обнаружения вторжений на системном уровне, состоящий в контроле целостности ключевых файлов. Кроме того, развиваются новые методы, сочетающие концепции обнаружения вторжений и межсетевого экранирования или предпринимающие дополнительные действия помимо простого обнаружения (см. врезку "Новое поколение систем обнаружения вторжений"). Однако в этой лекции основное внимание уделено двум наиболее популярным способам обнаружения вторжений в сети и системах: сетевое обнаружение вторжений и контроль целостности файлов.

Сетевая система обнаружения вторжений может защитить от атак, которые проходят через межсетевой экран во внутреннюю ЛВС. Межсетевые экраны могут быть неправильно сконфигурированы, пропуская в сеть нежелательный трафик. Даже при правильной работе межсетевые экраны обычно пропускают внутрь трафик некоторых приложений, который может быть опасным. Порты часто переправляются с межсетевого экрана внутренним серверам с трафиком, предназначенным для почтового или другого общедоступного сервера. Сетевая система обнаружения вторжений может отслеживать этот трафик и сигнализировать о потенциально опасных пакетах. Правильно сконфигурированная сетевая система обнаружения вторжений может перепроверять правила межсетевого экрана и предоставлять дополнительную защиту для серверов приложений.
Сетевые системы обнаружения вторжений полезны при защите от внешних атак, однако одним из их главных достоинств является способность выявлять внутренние атаки и подозрительную активность пользователей. Межсетевой экран защитит от многих внешних атак, но, когда атакующий находится в локальной сети, межсетевой экран вряд ли сможет помочь. Он видит только тот трафик, что проходит через него, и обычно слеп по отношению к активности в локальной сети. Считайте сетевую систему обнаружения вторжений и межсетевой экран взаимодополняющими устройствами безопасности - вроде надежного дверного замка и системы сигнализации сетевой безопасности. Одно из них защищает вашу внешнюю границу, другое -внутреннюю часть.
Имеется веская причина, чтобы внимательно следить за трафиком внутренней сети. Как показывает статистика ФБР, более 70 процентов компьютерных преступлений исходят из внутреннего источника. Хотя мы склонны считать, что наши коллеги не сделают ничего, чтобы нам навредить, но иногда это бывает не так. Внутренние злоумышленники - не всегда ночные хакеры. Это могут быть и обиженные системные администраторы, и неосторожные служащие. Простое действие по загрузке файла или по открытию файла, присоединенного к электронному сообщению, может внедрить в вашу систему "троянскую" программу, которая создаст дыру в межсетевом экране для всевозможных бед. С помощью сетевой системы обнаружения вторжений вы сможете пресечь подобную активность, а также другие возможные компьютерные интриги. Хорошо настроенная сетевая система обнаружения вторжений может играть роль электронной "системы сигнализации" для вашей сети.


Новое поколение систем обнаружения вторжений
Системы обнаружения вторжений на основе выявления аномальной активности
Вместо применения статических сигнатур, с помощью которых можно выявлять только явно вредоносную деятельность, системы нового поколения отслеживают нормальные уровни для различных видов активности в сети. Если наблюдается внезапный всплеск трафика FTP, то система предупредит об этом. Проблема с системами такого рода состоит в том, что они весьма склонны к ложным срабатываниям - то есть выдаче сигналов тревоги, когда в сети имеет место нормальная, допустимая деятельность. Так, в примере с FTP-трафиком загрузка особенно большого файла будет возбуждать сигнал тревоги.
Следует учитывать также, что системе обнаружения вторжений на основе выявления аномальной активности требуется время, чтобы построить точную модель сети. Вначале система генерирует так много тревожных сигналов, что пользы от нее почти никакой. Кроме того, подобные системы обнаружения вторжений можно обмануть, хорошо зная сеть. Если хакеры достаточно незаметны и используют протоколы, которые активно применяются в сети, они не привлекут внимания систем такого рода. С другой стороны, важное преимущество подобных систем - отсутствие необходимости постоянно обновлять набор сигнатур. Когда эта технология достигнет зрелости и достаточной интеллектуальности, она, вероятно, станет употребительным методом обнаружения вторжений.
Системы предотвращения вторжений
Новый тип сетевых систем обнаружения вторжений, называемый системами предотвращения вторжений, декларирован как решение всех проблем корпоративной безопасности. Основная идея состоит в том, чтобы при генерации тревожных сигналов предпринимать ответные действия, такие как написание на лету индивидуальных правил для межсетевых экранов и маршрутизаторов, блокирующих активность подозрительных IP-адресов, запрос или даже контратака систем-нарушителей.
Хотя эта новая технология постоянно развивается и совершенствуется, ей еще слишком далеко до проведения анализа и принятия решений на уровне человека. Факт остается фактом - любая система, которая на 100% зависит от машины и программного обеспечения, всегда может быть обманута посвятившим себя этому человеком (хотя некоторые проигравшие шахматные гроссмейстеры могут с этим не согласиться). Примером системы предотвращения вторжений с открытыми исходными текстами служит Inline Snort Джеда Хейла - свободный модуль для сетевой системы обнаружения вторжений Snort, обсуждаемой в данной лекции.

 

Примеры сигнатур сетевых систем обнаружения вторжений
Сетевые системы обнаружения вторжений действуют, проверяя пакеты и сравнивая их с известными сигнатурами. Хорошим примером распространенной атаки, которую можно четко идентифицировать по ее сигнатуре, является атака cmd.exe, направленная против Информационного Сервера Интернет (IIS) - web-сервера корпорации Microsoft. Эта атака применяется Интернет-"червями" и вирусами, такими как Nimda и Code Red. Атакующий "червь" или человек пытается выполнить в каталоге с правом на запись копию программы cmd.exe - командного интерпретатора Windows, используя переполнение буфера в модуле IIS, называемом Internet Server API (ISAPI). В случае успеха хакер или червь получает доступ к командной строке на этой машине и может произвести значительные разрушения. Однако команда для копирования этого файла является очевидной и нет причины для ее легального выполнения пользователями через сеть с помощью IIS. Поэтому, если вы видите подобную активность, то весьма вероятно, что это попытка вторжения. Проверяя полезную нагрузку пакета и разыскивая слова cmd.exe, сетевая система обнаружения вторжений может идентифицировать данную атаку. Показан один из таких пакетов. Шестнадцатеричное представление содержимого находится слева, а перевод в текст - справа.
length = 55
000 : 47 45 54 20 2F 73 63 72 69 70 74 73 2F 2E 2E 25 GET / scripts/..%
010 : 35 63 25 35 63 2E 2E 2F 77 69 6E 6E 74 2F 73 79 5c%5c../winnt/sy
020 : 73 74 65 6D 33 32 2F 63 6D 64 2E 65 78 65 3F 2F stem32/cmd.exe?/
030 : 63 2B 64 69 72 0D 0A c+dir..
Другой атакой, которую легко идентифицировать по ее сигнатуре, является переполнение буфера .ida. "Червь" Code Red распространялся с помощью этого метода. Эксплуатируется переполнение буфера в расширении .ida для web-сервера Microsoft IIS. Это расширение установлено по умолчанию, но часто не требуется. Если вы не наложили заплату на это место, оно может предоставить прямой доступ к вашей машине. По счастью, сетевая система обнаружения вторжений способна быстро идентифицировать эти пакеты, находя содержащийся в них оператор GET /default.ida. Частичный листинг атаки .ida показан на листинге 7.2. В этом конкретном примере присутствуют также слова Code Red II, свидетельствующие о том, что он был создан "червем" Code Red, пытавшимся инфицировать данную машину. Даже если ваша машина полностью защищена от подобных атак, не мешает выяснить, откуда они приходят и с какой частотой.
length= 1414
000 : 47 45 54 20 2F 64 65 66 61 75 6C 74 2E 69 64 61 GET /default.ida
010 : 3F 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
020 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
030 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
040 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
050 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
060 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
070 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
080 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
090 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0a0 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0b0 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0c0 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0d0 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0e0 : 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 ?XXXXXXXXXXXXXXX
0f0 : 58 25 75 39 30 39 30 25 75 36 38 35 38 25 75 63 X%u9090%u6858%uc
100 : 62 64 33 25 75 37 38 30 31 25 75 75 39 30 39 25 bd3%u7801%u9090%
110 : 75 36 38 35 38 25 75 63 62 64 33 25 75 37 38 30 u6858%ucbd3%u780
120 : 31 25 75 39 30 39 30 25 75 36 38 35 38 25 75 63 1%u9090%u6858%uc
130 : 62 64 33 25 75 37 38 30 31 25 75 39 30 39 30 25 bd3%u7801%u9090%
140 : 75 39 30 39 30 25 75 38 31 39 30 25 75 30 30 63 u9090%u8190%u00c
150 : 33 25 75 30 30 30 33 25 75 38 62 30 30 25 75 35 3%u0003%u8b00%u5
160 : 33 31 62 25 75 35 33 66 66 25 75 30 30 37 38 25 31b%u53ff%u0078%
170 : 75 30 30 30 30 25 75 30 30 3D 61 20 20 48 54 54 u0000%u00=a HTT
180 : 50 2F 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 74 P/1.0..Content-t
190 : 79 70 65 3A 20 74 65 78 74 2F 78 6D 6C 0A 43 6F ype: text/xml.Co
1a0 : 6E 74 65 6E 74 2D 6C 65 6E 67 74 68 3A 20 33 33 ntent-length: 33
1b0 : 37 39 20 0D 0A 0D 0A C8 C8 01 00 60 E8 03 00 00 79 ........'....
1c0 : 00 CC EB FE 64 67 FF 36 00 00 64 67 89 26 00 00 ....dg.6..dg.&..
1d0 : E8 DF 02 00 00 68 04 01 00 00 8D 85 5C FE FF FF .....h......\...
1e0 : 50 FF 55 9C 8D 85 5C FE FF FF 50 FF 55 98 8B 40 P.U...\...P.U..@
1f0 : 10 8B 08 89 8D 58 FE FF FF FF 55 E4 3D 04 04 00 .....X....U.=...
200 : 00 0F 94 C1 3D 04 08 00 00 0F 94 C5 0A CD 0F B6 ....=...........
210 : C9 89 8D 54 FE FF FF 8B 75 08 81 7E 30 9A 02 00 ...T....u..-0...
220 : 00 0F 84 C4 00 00 00 C7 46 30 9A 02 00 00 E8 0A ........F0......
230 : 00 00 00 43 6F 64 65 52 65 64 49 49 00 8B 1C 24 ...CodeRedII...$

Проблема ложных срабатываний сетевых систем обнаружения вторжений
Одной из главных проблем систем обнаружения вторжений является их склонность к большому числу ложных срабатываний. Ложное срабатывание имеет место, когда система генерирует сигнал тревоги на основе того, что она считает вредоносной или подозрительной активностью, но что в действительности оказывается нормальным трафиком для данной сети. Обычно в подразумеваемой конфигурации сетевая система обнаружения вторжений будет реагировать на все хоть чуть-чуть необычное. У большинства подобных систем имеются обширные используемые по умолчанию базы данных из тысяч сигнатур возможной подозрительной активности. Производители сетевых систем обнаружения вторжений не могут знать характер вашего сетевого трафика, поэтому для перестраховки они предусматривают срабатывание по каждому поводу.
Типичные причины ложных срабатываний
Работа системы мониторинга сети
Многие организации используют системы мониторинга сети, такие как HP OpenView или WhatsUp Gold, чтобы следить за системами в своей сети. Они характеризуются высокой сетевой активностью опроса и обнаружения. Для опроса состояния эти системы обычно применяют SNMP или аналогичный протокол, но они могут также использовать эхо-тестирование и другие, более назойливые проверки. По умолчанию большинство систем обнаружения вторжений рассматривают эту активность как вредоносную или, по крайней мере, подозрительную. В большой сети мониторинг может порождать тысячи сигналов тревоги в час, если система обнаружения вторжений настроена для отслеживания такой деятельности. Этого можно избежать, игнорируя активность с участием IP-адреса системы мониторинга. Можно также исключить из базы данных соответствующие сигналы тревоги, если их отслеживание не представляет для вас особой важности.
Сетевое сканирование уязвимостей/сканеры портов
Всякий раз, когда вы запускаете сетевое тестирование уязвимостей или сканирование портов с помощью таких программ, как Nessus и Nmap, ваша сетевая система обнаружения вторжений будет сходить с ума. Эти программы созданы для выполнения именно того, что делают хакеры. На самом деле, вероятно, сигналы тревоги заданы для большинства встраиваемых модулей Nessus. И здесь также можно отключить сообщения с участием IP-адреса сервера Nessus или Nmap, но лучше всего вообще выключать систему обнаружения вторжений на время планового сканирования. В этом случае сканирующая машина будет по-прежнему защищена от атак, когда не выполняется сканирование, а база данных сигналов тревоги не будет искажена множеством данных от вашей собственной активности по сканированию.
Пользовательская активность
Большинство сетевых систем обнаружения вторжений настроены для сигнализации об опасной активности пользователей, такой как одноранговое разделение файлов, мгновенный обмен сообщениями и т.д. Однако, если подобная активность допускается либо формальной политикой, либо просто несоблюдением существующих политик, то она будет фиксироваться в журналах в виде сигналов. Это может стать основанием для проведения в жизнь или создания политик против таких видов деятельности, так как можно показать, какую часть полосы пропускания и сколько времени они занимают, не говоря уже о последствиях для безопасности. Однако, если вы намерены и далее разрешать такую активность, то необходимо закомментировать эти правила, чтобы не заполнять журналы сигналами ложных срабатываний.
Поведение, напоминающее "троянскую" программу или "червя"
Современные вирусы и вирусоподобное программное обеспечение ("черви" и "троянские" программы) нередко используют сетевые средства, пытаясь выполнять такие действия, как инфицирование других машин или массовая рассылка электронных сообщений. Подобную активность можно выявить с помощью сетевых систем обнаружения вторжений. Однако эти сигнатуры могут порождать сигналы тревоги и при нормальной деятельности. Примером служит червь Nimda, который пытается копировать на различные системы файлы с определенными расширениями, такими как .eml. К сожалению, программа Microsoft Exchange ведет себя аналогично при использовании ее web-интерфейса. Поэтому, хотя знать о подобной "троянской" активности в сети было бы полезно, можно при желании отключить сигналы, порождаемые известной нормальной деятельностью, даже когда имеется потенциальная опасность, что трафик все-таки окажется вредоносным. Это поможет избежать чрезмерного количества ложных срабатываний.
Длинные базовые цепочки аутентификации
Сигнал такого типа ориентирован на чрезмерно длинные входные строки Web, поскольку некоторые программы использования уязвимостей применяют подобный метод для переполнения буфера и несанкционированного получения доступа. Однако в последнее время многие Web-сайты набивают в это поле много информации и могут ненароком сбить с толку сетевую систему обнаружения вторжений.
Аутентификационная активность базы данных
Некоторые сетевые системы обнаружения вторжений следят за деятельностью по администрированию баз данных. Теоретически в производственных базах данных не должно наблюдаться высокой административной активности, а ее наличие может служить признаком того, что кто-то пытается что-то сделать с базой. Однако во многих базах данных использование идет параллельно с разработкой, отсюда и большой объем администрирования. Эта деятельность, хотя и вполне законная, будет порождать множество сигналов тревоги. Если ваша база данных находится в состоянии непрерывного развития, то вам, вероятно, следует отключить эти сигналы, по крайней мере пока база не стабилизируется и не перейдет в режим производственной эксплуатации.
Существует много других причин ложных срабатываний, зависящих от конфигурации сети и уровня активности. В подразумеваемой конфигурации сетевая система обнаружения вторжений может порождать сотни ложных срабатываний в день, что способно привести системного администратора в отчаяние. В результате сигналы тревоги этих систем вскоре начинают игнорироваться, как некий посторонний шум. Однако при небольших усилиях и с помощью методов, описанных в этой лекции, сетевая система обнаружения вторжений может быстро стать полезным средством, а не электронной версией мальчика, который то и дело кричал "Волк!".

Как получить максимум пользы от системы обнаружения вторжений

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

Правильное конфигурирование системы

Если вы только что установили систему обнаружения вторжений и запустили ее в подразумеваемой конфигурации, то тысячи ложных срабатываний скоро переполнят чашу вашего терпения. Хотя вы сможете перенастроить систему постфактум, лучше поберечь силы и нервы, уделив некоторое время упреждающему конфигурированию. Не принимайте подразумеваемые настройки, индивидуализируйте их для своей ЛВС.
Большинство систем обнаружения вторжений группирует сигналы тревоги по категориям. Просмотрите каждую группу, чтобы решить, насколько она подходит для вашей сети. Если имеется группа сигнатур для UNIX-платформ, но у вас в сети нет UNIX-систем, то, вероятно, можно безопасно отключить весь этот пакет сигналов. В некоторых системах предусмотрены сигналы тревоги, зависящие от политики и отвечающие за такие вещи, как использование мгновенного обмена сообщениями или программного обеспечения одноранговых сетей. Если у вас уже есть системы, фильтрующие подобные виды активности, или вы их разрешаете, то эти сигналы можно отключить. Необходимо тщательно проанализировать группы сигналов. Хотя вам может пригодиться большинство сигналов для Windows-платформ, некоторые из них, возможно, не имеют отношения к вашей сети или будут вызывать ложные срабатывания.
Можно также освободить некоторые хосты от контроля. Если ваша персональная машина постоянно посылает в сеть SNMP-запросы, или вы постоянно входите как администратор, то это может порождать много бесполезных сигналов тревоги. Хотя освобождение от контроля снижает уровень безопасности и может оставить критически важные машины без защиты, оно способно сделать систему обнаружения вторжений более эффективной. Уделив несколько часов тщательному конфигурированию системы до ее активации, можно сберечь много времени и сил в будущем.

Настройка системы обнаружения вторжений

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

Средства анализа для систем обнаружения вторжений

Системы обнаружения вторжений обычно предлагают администраторам несколько различных способов получения уведомлений о срабатывании сигналов тревоги. В простейшем случае сигналы могут просто протоколироваться для последующего просмотра. На самом деле это не рекомендуется, так как заставляет администратора неусыпно следить за регистрационными журналами. Если не делать этого ежедневно, то могут пройти дни или недели, прежде чем попытки вторжения будут обнаружены. Другой возможностью извещения соответствующего должностного лица о возникновении сигнала тревоги является отправка сообщения по электронной почте или на пейджер. Однако даже с хорошо настроенной системой получение на пейджер по несколько сообщений в день может доставлять слишком много хлопот. Кроме того, электронные сообщения будут иметь формат, в котором их сложно сравнивать с прошлыми сигналами тревоги или анализировать каким-то иным образом. Лучшим способом обработки сигналов тревоги является их немедленное занесение в базу данных, чтобы можно было выполнить углубленный анализ. Существует средство с открытыми исходными текстами для систем обнаружения вторжений, называемое ACID (Analysis Console for Intrusion Detection - консоль анализа для обнаружения вторжений). Оно подробно рассматривается.
Теперь, ознакомившись с тем, как работают системы обнаружения вторжений, давайте построим такую систему и запустим ее в работу.


Snort: система обнаружения вторжений для UNIX с открытыми исходными текстами

Snort
Автор/основной контакт: Martin Roesch
Web-сайт: http://www.snort.org
Платформы: FreeBSD, Linux, Windows и некоторые UNIX
Лицензия: GPL
Рассмотренная версия: 2.1.1
Списки почтовой рассылки:
Snort-announcements
Общие объявления о версиях и коррекциях. Не для обсуждения. Подписка по адресу lists.sourceforge.net/lists/listinfo/snort-announce.
Snort-users
Общая дискуссия о Snort. Новички приветствуются. Подписка по адресу lists.sourceforge.net/lists/listinfo/snort-users.
Snort-developers
Для разработчиков или желающих разрабатывать код ядра snort. Подписка по адресу lists.sourceforge.net/lists/listinfo/snort-developers.
Snort-sigs
Для разработчиков или желающих разрабатывать правила snort. Подписка по адресу lists.sourceforge.net/lists/listinfo/snort-sigs.
Snort-cvsinfo
Только для активных разработчиков, желающих получать уведомления при обновлении дерева CVS. Дискуссии не допускаются. Подписка по адресу lists.sourceforge.net/lists/listinfo/snort-cvsinfo.
На сайте Snort доступен архив прошлых сообщений. При возникновении вопроса целесообразно сначала поискать ответ в архиве. Вполне возможно, что кто-то встречался с вашей проблемой раньше. Посетите http://www.snort.org/lists.html
Существуют локальные группы пользователей, которые время от времени собираются для обсуждения различных вопросов, связанных со Snort. Список этих групп представлен на http://www.snort.org/user-groups.html.
Примерно в полудюжине крупных городов имеются активные группы пользователей, и еще в дюжине подобные группы находятся в стадии становления. Форма на упомянутой выше web-странице позволяет выразить заинтересованность в создании такой группы, если в ваших краях ее еще нет.

Snort - творение Мартина Реша, вышедшее, однако, далеко за пределы его авторства. В настоящее время ядро группы разработчиков насчитывает более 30 человек, не считая тех, кто пишет правила и другие части программного обеспечения. Как можно видеть из приведенных выше списков рассылки, существует много доступных источников информации о Snort. И это только бесплатные сетевые ресурсы. Имеется также несколько полноформатных книг на эту тему. Данный раздел, хотя и не является истиной в последней инстанции, дает достаточно сведений об основах, позволяет освоить Snort и работать с ним.
Snort можно отнести к системам обнаружения вторжений на основе сигнатур, хотя с добавлением модуля Spade он приобрел способность выявлять аномальную активность. Имеются также дополнительные модули, такие как Inline Snort, которые позволяют автоматически реагировать на любые сигналы тревоги.

Уникальные особенности Snort

  • Открытые исходные тексты. Исходные тексты Snort открыты, он переносим практически на любую разновидность операционной системы UNIX. Доступны также версии для Windows и других операционных систем.
  • Легковесность. В силу эффективной реализации Snort не требует мощного оборудования (см. врезку "Оборудование"). Это позволяет анализировать трафик в сети 100 Мбит/с практически в реальном масштабе времени, что кажется невероятным, если представить, что делается с каждым пакетом.
  • Индивидуальные правила Snort. Snort предлагает простой способ расширения и индивидуализации программы путем написания собственных правил или сигнатур. Обширная документация помогает научиться этому, не говоря уже о сетевых форумах и справочных списках.

Установка Snort

Snort устанавливается довольно просто.

  1. В качестве предварительного условия требуется установить пакет libpcap. Если вы загрузили любой из пакетов из лекций с 4 по 6, то libpcap уже установлен. В противном случае его можно загрузить с http://www.tcpdump.org.
  2. После загрузки этих библиотек просто возьмите файл с компакт-диска, прилагаемого к книге, или загрузите самую свежую версию с web-сайта.
  3. Когда файл окажется в вашей машине, распакуйте его и выполните команды компиляции:
./configure
make
make install

Запуск Snort

Snort запускается из командной строки. Его можно выполнять в трех различных режимах: анализа, протоколирования и обнаружения вторжений. Последний режим является наиболее употребительным, но имеются применения и для первых двух.
Режим анализа пакетов
В этом режиме Snort действует просто как анализатор, показывая нефильтрованное содержимое среды передачи. Конечно, если вам требуется только анализатор, можно применить Tcpdump или Ethereal, однако данный режим позволяет убедиться, что все работает правильно и Snort видит пакеты. В табл. 7.1 перечислены ключи, которые можно использовать при выполнении Snort в режиме анализа. Необходимо включить как минимум команду -v, поскольку иначе Snort по умолчанию будет выполняться в одном из двух других режимов (протоколирования или обнаружения вторжений), ожидая других опций.
Испробовать этот режим можно, просто набрав в командной строке

snort -v

или

snort -vde

Выдача будет практически такой же, как от анализаторов, описанных в предыдущей лекции. Для выхода нажмите Ctrl+C, и вы увидите сводные данные сеанса анализа пакетов.


Таблица 7.1. Опции режима анализа пакетов

Опция

Описание

-v

Выдает на экран заголовки пакетов TCP/IP в сети Ethernet

-d

Аналогично предыдущей опции, но отображаются также данные прикладного уровня

-e

Аналогично предыдущей опции, но выдаются также заголовки канального уровня

Требования к оборудованию для сетевых систем обнаружения вторжений
Есть ряд моментов, которые нужно учитывать при выборе оборудования для работы сетевых систем обнаружения вторжений. Поскольку системы обнаружения, как правило, активно используют процессор и дисковое пространство, настоятельно рекомендуется, чтобы сетевая система обнаружения вторжений выполнялась на специально выделенном компьютере. Однако, поскольку система функционирует на платформе Linux, она все равно потребует меньше оборудования, чем эквивалентная машина Windows. При этом предполагается, что не используется графическая среда X-Window, которая для Snort не нужна, но существенно увеличивает нагрузку на процессор.
Для работы Snort желательно иметь процессор Intel 500 МГц, хотя можно обойтись и ПК с 266 МГц. Если вы храните файлы журналов локально, вам потребуется также по крайней мере несколько гигабайт доступного дискового пространства. Должна применяться сетевая плата 100 Мбит/с, чтобы исключить возможность заторов, если вы будете анализировать сеть 100 Мбит/с. Авторы Snort утверждают, что программа будет работать в активно используемом сегменте сети 100 Мбит/с без потери пакетов. Однако, если ваша сеть перегружена, то, возможно, придется несколько повысить требования к оборудованию - до процессора 1 ГГц. Так или иначе, необходимым требованиям легко удовлетворит любая машина, кроме разве что самых старых.

Режим протоколирования пакетов
Этот режим аналогичен предыдущему, но позволяет записывать пакеты на диск для последующего анализа, аналогично функциям протоколирования в описанных выше анализаторах. Чтобы запустить Snort в режиме протоколирования, воспользуйтесь той же командой, что и для режима анализа (-v, -d и/или -e), но с добавлением ключа -l каталог_журналов, задающего маршрутное имя каталога журналов, в которые Snort будет записывать пакеты. Пример:

snort -vde -l /var/log/snort

Эта команда создаст файлы журналов в каталоге /var/log/snort. Убедитесь, что указанный каталог существует, иначе программа не будет загружаться правильно. Snort протоколирует пакеты по IP-адресам, создавая отдельный каталог для каждого из них. Если вы протоколируете трафик в большой локальной сети с множеством адресов, ситуация может быстро выйти из-под контроля. Поэтому можно применить другую настройку, чтобы Snort протоколировал пакеты относительно вашей домашней сети, в которой вы находитесь. Это делается с помощью команды -h домашняя_сеть, где домашняя_сеть - диапазон IP-адресов локальной сети в нотации с косой чертой. В этом случае Snort будет помещать пакеты в каталоги на основе нелокального IP-адреса в пакете, что позволяет легко распознавать "неместный" трафик. Если оба хоста, целевой и исходный, являются локальными, Snort помещает пакет в каталог, соответствующий стороне с большим номером порта, как бы отдавая предпочтение подключающемуся хосту перед серверным. В случае равенства номеров портов Snort по умолчанию использует исходный адрес в качестве каталога для размещения данных пакета. Сейчас это может показаться несущественным, но если вы протоколируете сигналы о вторжении, важно быстро определить, откуда исходит подозрительный трафик.
Учитывая приведенные соображения, командной строке для режима протоколирования пакетов целесообразно придать следующий вид:

snort -vde -l /var/log/snort -h 192.168.1.0/24

Тем самым внутренняя сеть задается диапазоном 192.168.1.1-254.
Можно также применить опцию -b для протоколирования всех данных в одном бинарном файле, пригодном для последующего чтения с помощью анализатора пакетов, такого как Ethereal или Tcpdump. При протоколировании с опцией -b нет необходимости определять домашнюю сеть, так как данные будут записываться последовательно в один большой файл. Этот метод намного быстрее для протоколирования работы активно используемых сетей или на медленных машинах. Он также облегчает анализ с помощью более развитых средств, которые приходится применять при просмотре больших объемов перехваченных сетевых данных.
Режим обнаружения вторжений
В этом режиме Snort протоколирует подозрительные или требующие дополнительного внимания пакеты. Для перевода Snort в режим обнаружения вторжений достаточно добавить к приведенной выше инструкции ключ -c конфигурационный_файл, предписывающий использовать указанный конфигурационный файл для управления протоколированием пакетов. Конфигурационный файл определяет все настройки Snort, он очень важен. Snort поставляется с подразумеваемым конфигурационным файлом, но перед запуском в него целесообразно внести некоторые изменения, отражающие специфику вашей среды. Поэтому, набрав в командной строке

snort -de -l /var/log/snort -h 192.168.1.0/24 -c /etc/snort/snort.conf

вы запустите Snort в режиме обнаружения вторжений с использованием подразумеваемого конфигурационного файла snort.conf. Убедитесь, что указанный конфигурационный файл существует, или задайте маршрутное имя, соответствующее его расположению в вашей системе.
Обратите внимание, что я не использовал ключ -v для запуска Snort в режиме обнаружения вторжений. Если, помимо сопоставления всех пакетов с сигнатурами, заставлять Snort еще и выдавать на экран сигналы тревоги, это может привести к потере пакетов, особенно в загруженных сетях. Можно также не задавать ключ -e, чтобы повысить производительность, если не требуется протоколировать работу канального уровня. Если убрать ключ -l, то Snort будет использовать подразумеваемый каталог протоколов /var/log/snort. Опять-таки убедитесь, что этот каталог существует, иначе Snort не запустится. Можно также задать ключ -b, если вы хотите направить протокол в бинарный файл для последующего анализа отдельной программой. Команда для запуска Snort в режиме обнаружения вторжений в результате будет выглядеть следующим образом:

snort -h 192.168.1.0/24 -c /etc/snort/snort.conf

Режимы сигнализации Snort
При протоколировании пакетов, вызывающих сигналы тревоги, необходимо выбрать подходящий уровень детализации и формат "тревожных" данных. В табл. 7.2 перечислены опции, которые можно задавать в командной строке после ключа -A.


Таблица 7.2. Опции режима сигнализации Snort

Опция

Описание

-A full

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

-A fast

Быстрый режим. Протоколируются только заголовки пакетов и тип сигналов. Это полезно в очень быстрых сетях, но если требуется дополнительная судебная информация, необходимо использовать опцию full

-A unsock

Посылает сигнал в UNIX-сокет с указанным номером, на котором может слушать другая программа

-A none

Отключает сигналы тревоги

Имеются также опции вывода syslog, smb и database, но они используют не ключ -A, а отдельные модули вывода и предлагают более широкое разнообразие выходных форматов. Эти опции следует конфигурировать во время компиляции при помощи ключей инструкции configure.

  • SMB посылает сигналы тревоги службе всплывающих окон Windows, поэтому вы увидите сигналы всплывающими на вашем экране или экране машины, осуществляющей мониторинг. Однако, прежде чем использовать эту опцию, желательно тщательно настроить систему обнаружения вторжений, иначе вы не сможете ничего делать, кроме как наблюдать всплывающие то и дело окна! Для того чтобы включить этот метод сигнализации, при установке Snort задайте в инструкции configure опцию enable-smbalerts. Затем нужно запустить snort со следующими аргументами
snort -c /etc/snort.conf -M рабочие_станции

задав после -M имена хостов Windows, на которые отправляются сигналы.

  • Syslog посылает сигналы тревоги Syslog-серверу UNIX. Syslog - это служба, выполняющаяся на машине (обычно UNIX), которая может подхватывать и сохранять различные файлы журналов. Это помогает консолидировать журналы вашей сети в одном месте, а также затрудняет хакеру удаление протоколов вторжений. В данной книге не рассматриваются особенности настройки сервера Syslog, но если он у вас есть, то при наличии в командной строке ключа -s Snort будет посылать сигналы туда. Можно также определить в конфигурационном файле различные форматы Syslog, которые рассматриваются в следующем разделе.
  • Snort напрямую поддерживает четыре вида вывода в базу данных посредством своих модулей вывода. К числу поддерживаемых форматов принадлежат MySQL, PostgreSQL, Oracle и unixODBC. Это должно удовлетворить потребности большинства пользователей баз данных. И, естественно, если ваша база данных не поддерживается, можно взяться за проект по написанию нужного модуля расширения. Модуль вывода в базу данных требует как параметров времени компиляции, так и настроек в конфигурационном файле. Более подробные сведения - в следующем разделе.

 

Конфигурирование Snort для достижения максимальной производительности
Теперь, когда система Snort установлена, а вы ознакомились с основными командами, следует отредактировать конфигурационный файл, чтобы сделать ее надежной системой обнаружения вторжений и получать требуемые результаты. Подразумеваемым конфигурационным файлом служит snort.conf, который по умолчанию помещается в /etc/snort.conf. В этом файле задаются все настройки Snort. Имя этого файла можно изменить, если при запуске Snort после ключа -c указать новое маршрутное имя. Данный файл можно редактировать с помощью vi, EMACS или другого текстового редактора. Многие строки в этом файле начинаются со знака #, за которым следуют различные комментарии. Знак # служит стандартным началом строк комментариев, которые многие интерпретаторы, командные или такие как Perl, игнорируют. Строки комментариев применяются для документирования программ или для отключения старого кода. Вы будете использовать их позже при тонкой настройке набора правил. Но пока единственными строками, реально воздействующими на конфигурацию, являются строки без знака # в начале. Остальные присутствуют только для информационных целей. Конфигурационный файл настраивается в несколько шагов.

  1. Задание домашней сети.

Необходимо сообщить Snort адреса, которые представляют домашнюю сеть, чтобы он мог правильно интерпретировать внешние атаки. Это делается с помощью инструкции
var HOME_NET адреса
где адреса следует заменить на адресное пространство вашей локальной сети. Если имеется несколько сетей, то можно ввести их все, разделяя запятыми. Можно также ввести имя интерфейса, чтобы IP-адрес и маска сети, присвоенные этому интерфейсу, использовались как HOME_NET. Для этого служит следующий формат:
var HOME_NET $ имя_интерфейса
где имя_интерфейса заменяется интерфейсом, на котором слушает Snort (например, eth0 или eth1).
С помощью аналогичной инструкции можно определить внешние сети, заменяя HOME_NET на EXTERNAL_NET. Подразумеваемым значением обеих переменных служит any. Можно оставить их в таком виде или определить одну или обе. Я рекомендую определить внутреннюю сеть, но оставить внешние сети заданными как any.

  1. Задание внутренних серверов.

В конфигурационном файле можно определить ряд серверов, включая Web, mail, DNS, SQL и Telnet. Это уменьшит число ложных срабатываний для этих сервисов на этих машинах.
Можно также задать номера портов для этих сервисов, чтобы регистрировались только атаки на указанные порты. Все эти опции конфигурации позволяют сократить число ложных срабатываний, чтобы до вас доводилась только информация, обладающая реальной ценностью. Имеется также раздел для добавления серверов AIM, чтобы отслеживать применение AOL Instant Messenger. Это имеет смысл только в том случае, если включен класс правил Chat.

  1. Конфигурирование декодировщиков и препроцессоров Snort.

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

  1. Конфигурирование модулей вывода.

Это важный шаг, если вы хотите использовать базу данных при обработке вывода Snort. Здесь вы указываете программе, как обрабатывать данные сигналов тревоги. Имеется несколько модулей вывода, которые можно применять в зависимости от требуемого формата данных: Syslog, Database и новый модуль Unified, который поддерживает универсальный бинарный формат, полезный для импорта данных другими программами. Общий формат для конфигурирования модулей вывода таков:
output имя_модуля: конфигурация опции
где имя_модуля следует заменить на alert_syslog, database или alert_unified в зависимости от используемого модуля.
Опциями конфигурации для различных модулей вывода служат:

    • Syslog

Для систем UNIX/Linux нужно использовать следующую директиву:
output alert_syslog: LOG_AUTH LOG_ALERT
Для Windows-систем можно использовать любой из следующих форматов:
output alert_syslog: LOG_AUTH LOG_ALERT
output alert_syslog: host=имя_хоста, LOG_AUTH LOG_ALERT
output alert_syslog: host=имя_хоста:порт, LOG_AUTH LOG_ALERT
где имя_хоста и порт нужно заменить, соответственно, на IP-адрес и порт сервера Syslog.

    • Database

Общий формат для настройки вывода в базу данных таков:
output database: log, тип_базы_данных, user=имя_пользователя
password=пароль dbname=имя_базы_данных host=адрес_базы_данных
где тип_базы_данных заменяется одной из допустимых для Snort разновидностей баз данных (MySQL, postgresql, unixodbc или mssql), имя_пользователя - допустимым именем пользователя машины базы данных, а пароль - его паролем. Переменная dbname задает имя базы данных для протоколирования. Наконец, адрес_базы_данных является IP-адресом сервера базы данных. Не рекомендуется устанавливать Snort и базу данных на один сервер. Помимо того, что безопаснее держать данные сигналов тревоги на другом компьютере, работа Snort и базы данных на одной машине будет существенно снижать производительность. Хотя настройка баз данных не является темой книги, базовая конфигурация базы данных MySQL для Snort и других программ обсуждается.

    • Unified

Это основной бинарный формат быстрого протоколирования и сохранения для будущего использования. Поддерживаются два аргумента - filename и limit, а вся директива может выглядеть примерно так:
output alert_unified: filename snort.alert, limit 128

  1. Индивидуализация наборов правил.

Можно выполнить тонкую настройку Snort, добавляя или удаляя наборы правил. Файл snort.conf позволяет добавлять или удалять целые классы правил. В конце файла перечислены все наборы правил генерации сигналов тревоги. Можно отключить целые категории правил, закомментировав строки с помощью знака # в начале. Например, можно отключить все правила icmp-info для снижения числа ложных срабатываний на трафике ping или все правила NetBIOS, если в сети нет машин Windows. Имеются также общедоступные наборы правил, уже настроенные для определенных сред.
Закончив внесение изменений в конфигурационный файл, сохраните его, и тогда все будет готово для запуска Snort.


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

Однако при подобном размещении будет генерироваться много сигналов тревоги на основе потоков данных Windows, так что будьте готовы проделать большой объем работы по настройке в этой области. Далее, если у вас коммутируемая ЛВС, то понадобится возможность отражения всех портов в порт монитора, чтобы система обнаружения вторжений могла прослушивать весь трафик ЛВС.

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

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

  • Между вашим поставщиком Интернет-услуг и межсетевым экраном. В этом случае будет фильтроваться весь входящий и исходящий трафик вашей ЛВС и демилитаризованной зоны. Положительная сторона этого подхода состоит в том, что вы будете перехватывать все, что направлено против ваших общедоступных серверов и внутренней ЛВС, отрицательная - в том, что вы не увидите внутренний трафик, а общий объем сигналов может быть весьма большим из-за высокого уровня фонового атакующего трафика.

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

Отключение правил в Snort

Простейшим способом ограничения потока сигналов является отключение правил, неприменимых к вашей системе. Для этого нужно войти в компьютер, на котором выполняется Snort, и найти каталог rules (обычно в каталоге, в котором установлен Snort). В этом каталоге имеется много файлов с расширением .rules. Каждый из них содержит множество правил, сгруппированных по категориям. Можно отключить целый класс правил, закомментировав его в конфигурационном файле, или же отключать отдельные правила, если вы хотите сохранить защиту других правил этого класса. Чтобы закомментировать правило, нужно найти его в соответствующих файлах .rules и поместить символ # перед строкой этого правила. Отметим, что обычно лучше отключать отдельные правила, а не классы, за исключением случаев, когда какой-то класс целиком неприменим для вас. В табл. 7.3 перечислены все имена файлов для классов правил Snort и приведено их краткое описание.


Таблица 7.3. Имена файлов классов правил Snort

Класс правил

Описание

attack-responses.rules

Это сигналы для пакетов обычных ответов после успешных атак. Они редко оказываются ложными. В большинстве случаев их следует оставить включенными.

backdoor.rules

Это обычные признаки использования потайных входов или "троянских" программ. Они редко бывают ложными

bad-traffic.rules

Эти правила представляют нестандартный сетевой трафик, который обычно не должен присутствовать в большинстве сетей

chat.rules

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

ddos.rules

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

dns.rules

Ищет некоторые стандартные атаки против серверов DNS. Если у вас нет собственного сервера DNS, эти правила можно отключить

dos.rules

Аналогично вышеупомянутому набору правил ddos.rules.

experimental.rules

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

exploit.rules

Предназначены для стандартного трафика использования уязвимостей и всегда должны быть включены

finger.rules

Эти правила сигнализируют о трафике, связанном с серверами finger. Если вы не используете finger, то можно, наверное, их отключить. Однако серверы finger часто выполняются скрытно от системного администратора, поэтому можно оставить их включенными, так как они не будут вызывать ложных срабатываний, если у вас нет серверов finger

ftp.rules

Аналогично finger.rules, но ищет признаки использования уязвимостей FTP. Эти правила также вполне можно оставить включенными, даже если у вас нет серверов FTP, так как они будут сигнализировать обо всех нелегальных серверах FTP

icmp-info.rules

Эти правила отслеживают сообщения ICMP в вашей сети, порожденные, например, утилитой ping. Они часто являются причиной ложных срабатываний, и можно, наверное, отключить весь набор, если только вы не хотите строго контролировать трафик ICMP в своей сети. Другой класс известного незаконного трафика ICMP icmp.rules перехватывает сканирование портов и сходную активность

icmp.rules

Охватывает незаконный или подозрительный трафик ICMP, такой как сканирование портов, и не столь часто, как icmp-info.rules, порождает ложные срабатывания. Однако, возможно, что они будут часто возникать в загруженной сети с множеством работающих диагностических сервисов

imap.rules

Правила, относящиеся к использованию в вашей сети протокола IMAP (Internet Message Access Protocol)

info.rules

Перехватывает различные сообщения об ошибках от Web, FTP и других серверов

local.rules

В этот файл вы добавляете индивидуальные сигнатуры для сети. По умолчанию файл пуст. В конце этой лекции имеется раздел о том, как писать индивидуальные правила Snort

misc.rules

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

multimedia.rules

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

mysql.rules

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

Netbios.rules

Этот класс правил сообщает о различных видах активности NetBIOS в вашей ЛВС. Часть из них соответствует очевидным атакам. Однако, другая часть, например, сигналы о сеансах NULL, может иметь место в нормальных условиях в ЛВС Windows. Необходимо поэкспериментировать с этим разделом, чтобы выявить правила, подходящие для вашей ЛВС

nntp.rules

Правила, имеющие отношение к серверу телеконференций. Если вы их не используете, то эти правила, наверное, можно отключить

oracle.rules

Правила для сервера баз данных Oracle. Если вы его не используете, можно отключить эти правила

other-ids.rules

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

p2p.rules

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

policy.rules

Этот файл содержит различные сигналы, связанные с разрешенной активностью в ЛВС, такой как Go-to-my-pc и другими программами. Необходимо просмотреть эти правила и включить только те, которые соответствуют внутренним политикам

pop2.rules pop3.rules

Оба файла относятся к почтовым серверам. Большинство организаций при использовании POP будут применять сервер POP3. Если у вас есть какой-либо из этих двух типов серверов, оставьте эти правила включенными, если нет - отключите

porn.rules

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

rpc.rules

Этот класс обрабатывает сигналы тревоги, вызванные применением удаленного вызова процедур. Даже если вы считаете, что не используете подобные сервисы, следует учитывать, что они часто выполняются как часть других программ, поэтому важно знать, когда это происходит в вашей ЛВС. Удаленный вызов процедур может допускать удаленное выполнение кода, что часто используется троянскими программами и программами эксплуатации уязвимостей

rservices.rules

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

scan.rules

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

shellcode.rules

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

smtp.rules

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

sql.rules

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

telnet.rules

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

tftp.rules

TFTP (trivial FTP) является альтернативным сервером FTP, часто выполняемым на маршрутизаторах. Он может применяться для загрузки новых конфигураций, поэтому стоит за ним следить

virus.rules

Содержит сигнатуры некоторых распространенных червей и вирусов. Этот список не является полным, поддерживается нерегулярно и не может служить заменой антивирусного программного обеспечения, но способен перехватывать некоторых сетевых "червей"

web-attacks.rules web-cgi.rules web-client.rules web-coldfusion.rules web-frontpage.rules web-iis.rules web-php.rules

Все эти классы относятся к различным видам подозрительной web-активности. Некоторые из них универсальны, например, класс web-attacks. Другие, такие как web-iis и web-frontpage, специфичны для определенных серверных платформ web. Даже если вы полагаете, что у вас в сети нет web-серверов Microsoft и PHP не используется, стоит оставить все правила включенными, чтобы обнаруживать в ЛВС любую активность такого рода, о которой вы можете и не знать. Необходимо тщательно настроить эти правила, особенно если ваши web-серверы активно развиваются.

X11.rules

Отслеживает применение графической среды X11 в вашей сети.

 

Запуск Snort в качестве службы

Если вы собираетесь выполнять Snort на сервере, предназначенном для круглосуточной работы, то желательно запускать Snort при загрузке операционной системы, чтобы после временного выключения машины она перезагружала Snort, и система обнаружения вторжений продолжала защищать ваши ЛВС. Один из способов сделать это - включить в число стартовых процедур небольшой командный файл, запускающий Snort с параметрами командной строки. В Linux можно поместить строку для запуска Snort в файл rc.local в каталоге /etc/rc.d. Пример:

snort -h 192.168.1.0/24 -c /etc/snort/snort.conf &

Знак & (амперсанд) в конце означает запуск Snort в фоновом режиме. Можно также запускать Snort как службу, воспользовавшись командой service snort start.


Snort Webmin Interface: Графический интерфейс для Snort

Snort Webmin Interface
Автор/основной контакт: Mike Baptiste/MSB Networks
Web-сайт: msnnetworks.net/snort/
Платформы: Большинство Linux
Лицензия: GPL
Рассмотренная версия: 1.1

Настраивать Snort из командной строки - скучновато. Хотя Snort не имеет пока собственного графического интерфейса, существует модуль для популярного средства управления Webmin на базе Web. Он позволяет произвести всю настройку и конфигурирование из любого web-навигатора. Свойствами этой системы являются:

  • Доступ к конфигурационным файлам Snort на основе форм.
  • Различные уровни доступа пользователей, что позволяет задать различные права доступа для различных пользователей.
  • Возможность включать и выключать наборы правил щелчком мыши.
  • Индикатор статуса для всех правил и наборов правил.
  • Встроенные ссылки к внешней базе данных, такой как archNIDS, CVE и Bugtraq.
  • Запись изменений в журналах.
  • Средства поддержки различных языков.
  • Поддержка запуска Snort в качестве службы с помощью файлов rc.d.
  • Защищенное удаленное администрирование через SSL (если включено).

В  рассмотрена загрузка Webmin для администрирования межсетевого экрана. Этот же дополнительный модуль можно применять и для конфигурирования Snort. Обратитесь, если вы еще не загрузили Webmin.
Для Snort требуется версия Webmin 0.87 или выше. Можно использовать файл Snort Webmin с компакт-диска, загрузить модуль Snort с помощью интерфейса Webmin или сначала загрузить файл, а потом установить его локально, взяв его по адресу: http://www.msbnetworks.com/snort/download/snort-1.1.wbm
Чтобы загрузить модуль Snort через интерфейс Webmin, выполните следующие действия.

  1. Перейдите на основную страницу Webmin. Войдите с помощью имени и пароля, заданных во время установки Webmin.
  2. Щелкните мышью на вкладке конфигурирования Webmin. Щелкните на Modules и выберите либо Local file, либо FTP Url, в зависимости от того, загрузили вы его уже на свою машину или хотите, чтобы Webmin взял его с web-сайта.
  3. Щелкните мышью на Install module, в результате будет установлен файл модуля Snort. Модуль Snort появится как иконка на основной странице Webmin. Щелкните мышью на этой иконке, чтобы отобразить интерфейс Webmin Snort.

Открыв страницу Snort, вверху экрана вы увидите все основные разделы конфигурационного файла, такие как настройки сети, параметры препроцессора и опции входа. Щелкнув мышью на любом из параметров конфигурации, можно заполнить форму своей информацией, и Webmin произведет изменения в соответствующих конфигурационных файлах Snort.
Все наборы правил перечислены ниже, и можно видеть, какие из них включены или выключены. Галочка указывает, что набор правил включен, а значком Х отмечены выключенные наборы. Для того чтобы отключить целый набор правил, достаточно сделать двойной щелчок мышью в поле Action. Если вы хотите просмотреть набор правил и модифицировать отдельное правило, щелкните мышью на голубом подчеркнутом тексте, и вы попадете на страницу Edit Ruleset (Редактирование набора правил). На ней можно видеть все активные правила набора. С правилами можно выполнять действия - выключение, включение или удаление из набора правил. Если в описании сигнала тревоги имеются ссылки на внешние базы данных, такие как номера в словаре уязвимостей CVE (Common Vulnerability or Exploit), то можно получить дополнительную информацию о действии сигнала, щелкнув мышью на гиперссылке. Использование подобного интерфейса может существенно облегчить настройку правил. Webmin Snort
Модуль Webmin Snort позволяет также управлять доступом пользователей к настройкам. На странице пользователей Webmin можно задать ряд параметров для каждого пользователя (при условии, что вы являетесь администратором Webmin). Можно предоставить определенным пользователям доступ для редактирования правил, но не для редактирования конфигурационных файлов. Можно управлять тем, к каким конфигурационным файлам они будут иметь доступ - или позволить им только просматривать файлы без редактирования или отключения. Таким образом, модуль Webmin Snort предоставляет весьма детальное управление доступом, что позволяет вам делегировать ежедневные обязанности по настройке менее квалифицированному техническому специалисту, оставляя за собой управление конфигурацией и изменениями.

К счастью для тех, кто не может или не хочет устанавливать версию Snort для UNIX, имеется полностью поддерживаемая версия для платформы Windows. Хотя отдача от каждого вложенного в аппаратуру доллара для UNIX-версии будет выше, Windows-версия не является просто побочным проектом - фактически, она разработана основной группой Snort и в достаточной степени синхронизирована с UNIX-версией. Она позволяет воспользоваться преимуществами простоты установки, а также другими достоинствами Windows 2000 и XP, такими как встроенная поддержка IPSec. Приятно видеть проект с открытыми исходными текстами, участники которого понимают, что имеется много компаний, использующих только Windows, которые с удовольствием применят возможности этой отличной системы обнаружения вторжений с открытыми исходными текстами.

Требования для использования Snort в Windows

Snort для Windows требует Windows 2000 или XP; на NT, 98 или 95 выполнение невозможно. Необходимы также установленные библиотеки WinPcap. Если они были установлены для программ, описанных ранее в этой книге, таких как Ethereal или WinDump, тогда все готово. В противном случае можно взять их по адресу
netgroup-serv.polito.it/winpcap
Вам может также потребоваться база данных MySQL, если вы планируете импортировать результаты в базу данных. Конкретная конфигурация MySQL для этой цели описана.
Для того чтобы Snort для Windows демонстрировал ту же производительность, что и UNIX-версия, понадобится более мощная аппаратура,. Машина с процессором 700 МГц - это минимум, но лучше использовать процессор с частотой 1 ГГц и выше. Необходимо также убедиться, что сервер Windows хорошо защищен, на нем выполняется минимум сервисов и удалены программы, активно использующие процессор, такие как IIS. Воспользуйтесь окном Services из Administrative tools Панели управления, чтобы проверить, не запускается ли что-нибудь лишнее.

Установка Snort для Windows

Чтобы установить Snort для Windows, возьмите бинарный файл с прилагаемого к книге компакт-диска или с сайта http://www.snort.org. Сделайте на нем двойной щелчок мышью, и он автоматически установится. Вас спросят, нужна ли вам определенная база данных или дополнительные модули, такие как модуль гибкого реагирования.

Настройка Snort для Windows

Процесс настройки версии Snort для Windows весьма схож с настройкой для UNIX. Все файлы конфигурации и правил находятся в тех же относительных подкаталогах. Войдите в файл snort.conf в подкаталоге etc установки Snort. Измените и отредактируйте его, как предложено в разделе о UNIX-версии. Затем перейдите в файлы правил и произведите изменения там. После этого все будет готово к запуску Snort. Обратитесь к разделу "Запуск Snort" для UNIX, чтобы получить дополнительную информацию о применении Snort для Windows, так как все команды такие же. Дополнительные настройки и рекомендации по размещению - те же, что и для исходной UNIX-версии.


Уголок кодировщиков Флэми Теха
Написание индивидуальных правил Snort
Хотя стандартные наборы правил, с которыми поставляется Snort, обеспечивают достаточную защиту от атак с известными сигнатурами, можно создавать некоторые индивидуальные правила, специфичные для вашей сети, чтобы получить от системы обнаружения вторжений максимальную отдачу. Вы можете написать правила для:
  • отслеживания входящего и исходящего доступа для определенных серверов;
  • поиска определенных типов или имен файлов, специфичных для вашей организации;
  • наблюдения за определенными типами трафика, чужеродными для вашей сети;

Научиться писать правила для Snort несложно; это позволит быстро наращивать функциональность программы даже при отсутствии обширных программистских знаний. Как вы видели, все правила Snort являются просто текстовыми инструкциями в одном из файлов правил.
Если нужно, чтобы Snort обнаруживал некое особое поведение, которое в вашей сети будет считаться подозрительным, можно быстро закодировать правило и тут же протестировать это поведение. Правила Snort по сути представляют собой одиночные текстовые строки, начинающиеся с действия (как правило, alert), за которым следует несколько аргументов. В новейшей версии (2.0 и выше) можно добавить несколько строк, просто помещая \ (обратную косую черту) в конце каждой строки, кроме последней. В более сложных случаях можно также вызывать другие программы, используя инструкцию включения. Но в своей базовой форме правило Snort имеет две части: заголовок и параметры. Ниже представлен пример правила.

alert tcp any any 192.168.0.0/24 \ (content:"|00 05 A4 6F 2E|";msg: "Test Alert")

Заголовок является частью перед первой скобкой. Данная инструкция содержит действие (в нашем случае - alert), протокол, а также адреса и порты отправителя и получателя. Действие будет выполняться, если заданное правилом условие истинно. В данном случае будет порождаться сигнал тревоги (alert). Другими вариантами действий служат Log, Pass, Activate и Dynamic.


Log

Просто протоколирует пакеты

Pass

Игнорирует пакет. Это подразумеваемое действие для пакетов, не соответствующих правилу.

Activate

Сигнал тревоги, затем активация динамического правила.

Dynamic

Остается пассивным, пока не активируется динамическим правилом, затем действует как log.

Протоколами могут быть tcp, udp, icmp или ip, что означает любой IP-протокол. (В будущем могут поддерживаться протоколы не на основе IP, такие как IPX). Исходный и целевой порты самоочевидны. Исходный адрес идет первым и задается в стандартной нотации с косой чертой для IP-диапазона. Можно также перечислить несколько индивидуальных адресов и сетей, разделяя их запятой без пробелов и заключая в квадратные скобки, например: alert tcp any < [192.168.1.1,192.168.1.5,192.168.1.10] 80 \ (content: "|00 05 A4 6F 2E|";msg: "Test Alert";)
Эта инструкция ориентирована на трафик, приходящий из любых адресов, направляющийся на машины с адресами 192.168.1.1, 192.168.1.5 и 192.168.1.10 в порт 80. При условии, что это ваши web-серверы, приведенное правило будет искать идущий туда трафик, который содержит указанные шестнадцатеричные данные в разделе содержимого.
Второй частью правила Snort служат опции, задающие дополнительные детали выявляемого трафика. Можно искать по набору полей в заголовке TCP/IP (см. описания или по полезной нагрузке пакета. За каждой опцией должны следовать кавычки и разыскиваемое значение. Можно добавить несколько опций, разделяя их с помощью точки с запятой. Ниже приведены допустимые опции.


msg

Предоставляет текстовое описание сигнала тревоги

logto

Записывает пакет в заданный пользователем файл вместо стандартного выходного файла

ttl

Проверяет значение поля TTL в заголовке IP

tos

Проверяет значение поля TOS в заголовке IP

id

Сравнивает значение поля идентификатора фрагмента в заголовке IP с указанной величиной

ipoption

Ищет поля опций IP с определенными кодами

fragbits

Проверяет биты фрагментации в заголовке IP

dsize

Сравнивает размер полезной нагрузки пакета с указанным значением

flags

Проверяет флаги TCP на соответствие определенным значениям

seq

Сравнивает поле порядкового номера TCP с определенным значением

ack

Проверяет поле подтверждения TCP на соответствие определенному значению

itype

Проверяет поле типа ICMP на соответствие определенному значению

icode

Проверяет поле кода ICMP на соответствие определенному значению

icmp_id

Проверяет поле ECHO ID ICMP на соответствие определенному значению.

icmp_seq

Проверяет порядковый номер ECHO ICMP на соответствие определенному значению

content

Ищет определенный шаблон в полезной нагрузке пакета

content-list

Ищет определенный набор шаблонов в полезной нагрузке пакета

offset

Модификатор для опции содержимого. Задает смещение для начала сопоставления с образцом

depth

Модификатор для опции содержимого. Устанавливает максимальную глубину поиска при сопоставлении с образцом

nocase

Сравнивает предыдущую цепочку содержимого без учета регистра символов

session

Вывод информации прикладного уровня для данного сеанса

rpc

Следит за сервисами RPC для выявления определенных вызовов приложений/процедур

resp

Активный ответ. Закрывает соединение (например, разрывая его)

react

Активный ответ. Отвечает запрограммированным поведением (например, блокированием определенных Web-сайтов)

reference

Идентификаторы ссылок на внешние атаки

sid

Идентификатор правила Snort

rev

Номер версии правила

classtype

Классификационный идентификатор правила

priority

Идентификатор уровня серьезности правила

uricontent

Сопоставление с образцом в части URI пакета

tag

Дополнительные действия по протоколированию для правил

ip_proto

Значение протокола в заголовке IP

sameip

Определяет, не равны ли исходный и целевой IP-адреса

stateless

Применимо независимо от состояния потока

regex

Сопоставление с образцом с применением метасимволов

byte_test

Числовое сравнение

distance

Заставляет при относительном сопоставлении с образцом пропустить в пакете определенное число байт

byte_test

Числовое сопоставление с образцом

byte_jump

Числовое сопоставление с образцом и корректировка смещения

Более подробную информацию о каждой из опций правил можно получить в оперативной справке. Ниже представлены несколько примеров применения этих опций для создания индивидуальных правил Snort
Пример 1 индивидуального правила
Предположим, имеется набор бухгалтерских серверов, доступ к которым может осуществляться только из внутренней сети. Можно написать правило Snort, реагирующее на трафик, идущий с любого не принадлежащего вашей сети IP-адреса и направленный на эти серверы. Пусть бухгалтерские серверы имеют IP-адреса 192.168.1.10, 192.168.1.11 и 192.168.1.12, а ваша внутренняя сеть - адреса 192.168.2.0/24. Тогда правило будет выглядеть примерно так:

alert tcp !192.168.1.0/24 any \
< [192.168.1.10,192.168.1.11,192.168.1.12] any \ 
(msg: "Попытка внешнего доступа к бухгалтерскому серверу";)

Знак операции ! (восклицательный знак) обозначает логическое отрицание. Смысл правила в том, чтобы выдать сигнал тревоги при обнаружении TCP-трафика, идущего не из сети 192.168.1.0/24 и направленного на указанные серверы. Не задается никаких опций, кроме msg - метки, появляющейся в журналах сигналов. Дело в том, что нас интересует любой трафик на любой порт. Будет отмечено любое обращение к бухгалтерским серверам, исходящее из внешнего мира, так как предполагается, что любой внешний трафик к этим серверам должен считаться вредоносным.
Пример 2 индивидуального правила
Опираясь на сценарий из примера 1, предположим, что следует разрешить некоторый внешний доступ к бухгалтерским серверам, но, тем не менее, гарантировать, что никто не скопирует определенные файлы. Предположим, что имеется файл с именем payroll.xls, который содержит все данные о зарплате (совершенно секретный файл, как внутри, так и вне организации). Можно написать правило, которое проследит за любым трафиком, внутренним или внешним, направленным на эти серверы и содержащим имя секретного файла. Это можно сделать с помощью опции content, осуществляющей поиск в реальном содержимом пакетов. Правило будет выглядеть примерно так:

alert tcp ![192.168.1.10,192.168.1.11,192.168.1.12] any < 
 [192.168.1.10,192.168.1.11,192.168.1.12] any 
 (content: "payroll.xls";msg: "Попытка доступа к файлу зарплат")

Отметим, что знак операции ! снова означает, что нас интересует трафик, направленный на бухгалтерские серверы из любого места, кроме этих серверов. Тем самым устраняется сигнализация о межсерверном трафике. Отметим также, что символ \ позволяет писать многострочные правила, а опция content - осуществлять поиск текста payroll.xls в пакетах. В результате серверные машины могут иметь доступ в Интернет, но если этот конкретный файл будет когда-либо выгружаться с них, вы будете об этом оповещены.
С помощью других опций можно писать правила для выявления трафика практически любого вида. Если ваши правила могут представлять интерес для других организаций, стоит послать их разработчикам Snort для вставки в официальный набор распространяемых правил. Если вы решите это сделать, постарайтесь использовать все средства документирования, такие как msg, sid, rev, classtype и priority. Также тщательно протестируйте свои правила, чтобы гарантировать, что они действительно охватывают все виды активности, которую вы пытаетесь поймать, и не дают ложных срабатываний.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика