Инструменты безопасности с открытым исходным кодом

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

Разбить на страницы
Показывать лекцию целиком

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

Обзор лекции

Изучаемые концепции:

  • Типы систем обнаружения вторжений
  • Сигнатуры для систем обнаружения вторжений
  • Ложные срабатывания в сетевых системах обнаружения вторжений
  • Правильное размещение систем обнаружения вторжений
  • Настройка систем обнаружения вторжений
  • Контроль целостности файлов
  • Используемые инструменты:

    Snort, модуль Snort Webmin, Snort for Windows, Tripwire

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

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

    (рис 7.1) Защита с помощью сетевой системы обнаружения вторжений и межсетевого экрана

    Имеется веская причина, чтобы внимательно следить за трафиком внутренней сети. Как показывает статистика ФБР, более 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, сетевая система обнаружения вторжений может идентифицировать данную атаку. На листинге 7.1 показан один из таких пакетов. Шестнадцатеричное представление содержимого находится слева, а перевод в текст - справа.

    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 - консоль анализа для обнаружения вторжений). Оно подробно рассматривается в лекции 8.

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

    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 устанавливается довольно просто.

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

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

    Режим анализа пакетов

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

    Испробовать этот режим можно, просто набрав в командной строке

    snort -v

    или

    snort -vde

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

    Опции режима анализа пакетов
    Опция Описание
    -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.

    Опции режима сигнализации 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, игнорируют. Строки комментариев применяются для документирования программ или для отключения старого кода. Вы будете использовать их позже при тонкой настройке набора правил. Но пока единственными строками, реально воздействующими на конфигурацию, являются строки без знака # в начале. Остальные присутствуют только для информационных целей. Конфигурационный файл настраивается в несколько шагов.

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

    Необходимо сообщить Snort адреса, которые представляют домашнюю сеть, чтобы он мог правильно интерпретировать внешние атаки. Это делается с помощью инструкции

    var HOME_NET адреса

    где адреса следует заменить на адресное пространство вашей локальной сети. Если имеется несколько сетей, то можно ввести их все, разделяя запятыми. Можно также ввести имя интерфейса, чтобы IP-адрес и маска сети, присвоенные этому интерфейсу, использовались как HOME_NET. Для этого служит следующий формат:

    var HOME_NET $ имя_интерфейса

    где имя_интерфейса заменяется интерфейсом, на котором слушает Snort (например, eth0 или eth1).

    С помощью аналогичной инструкции можно определить внешние сети, заменяя HOME_NET на EXTERNAL_NET. Подразумеваемым значением обеих переменных служит any. Можно оставить их в таком виде или определить одну или обе. Я рекомендую определить внутреннюю сеть, но оставить внешние сети заданными как any.

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

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

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

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

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

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

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

    Это важный шаг, если вы хотите использовать базу данных при обработке вывода 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 и других программ обсуждается в лекции 8.

  • Unified

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

    output alert_unified: filename snort.alert, limit 128
  • Индивидуализация наборов правил.

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

  • Закончив внесение изменений в конфигурационный файл, сохраните его, и тогда все будет готово для запуска Snort.

    Правильное размещение сетевой системы обнаружения вторжений

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

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

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

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

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

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

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

  • Мы перечислили все разумные варианты размещения системы обнаружения вторжений. Разумеется, ничто не мешает использовать их все, если у вас достаточно оборудования и времени для управления.

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

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

    Имена файлов классов правил 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 (если включено).
  • В лекции 3 рассмотрена загрузка Webmin для администрирования межсетевого экрана. Этот же дополнительный модуль можно применять и для конфигурирования Snort. Обратитесь к лекции 3, если вы еще не загрузили Webmin.

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

    Чтобы загрузить модуль Snort через интерфейс Webmin, выполните следующие действия.

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

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

    (рис 7.3) Страница редактирования наборов правил Webmin Snort

    Модуль Webmin Snort позволяет также управлять доступом пользователей к настройкам (рис. 7.4). На странице пользователей Webmin можно задать ряд параметров для каждого пользователя (при условии, что вы являетесь администратором Webmin). Можно предоставить определенным пользователям доступ для редактирования правил, но не для редактирования конфигурационных файлов. Можно управлять тем, к каким конфигурационным файлам они будут иметь доступ - или позволить им только просматривать файлы без редактирования или отключения. Таким образом, модуль Webmin Snort предоставляет весьма детальное управление доступом, что позволяет вам делегировать ежедневные обязанности по настройке менее квалифицированному техническому специалисту, оставляя за собой управление конфигурацией и изменениями.

    (рис 7.4) Управление доступом для модуля Webmin Snort
    Snort for Windows: система обнаружения вторжений для Windows с открытыми исходными текстами

    Snort for Windows

    Автор/основной контакт: Martin Roesch

    Перенос в Windows: Michael Davis, Chris Reid

    Web-сайт: http://www.snort.org

    Платформы: Windows 2000, XP

    Лицензия: GPL

    Рассмотренная версия: 2.0.0

    Другие ресурсы: См. список в разделе "Snort: система обнаружения вторжений для UNIX с открытыми исходными текстами" выше в этой лекции.

    К счастью для тех, кто не может или не хочет устанавливать версию 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 для этой цели описана в лекции 8.

    Для того чтобы 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 (см. описания в лекции 6) или по полезной нагрузке пакета. За каждой опцией должны следовать кавычки и разыскиваемое значение. Можно добавить несколько опций, разделяя их с помощью точки с запятой. Ниже приведены допустимые опции.

    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. Также тщательно протестируйте свои правила, чтобы гарантировать, что они действительно охватывают все виды активности, которую вы пытаетесь поймать, и не дают ложных срабатываний.

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

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

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

    Преимущества хостовых методов обнаружения вторжений

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

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

    Tripwire

    Автор/основной контакт: Dr. Eugene Spafford и Gene Kim

    Web-сайт: http://www.tripwire.org

    Платформы: Большинство UNIX

    Лицензия: GPL

    Рассматриваемая версия: V 2.3.47

    Tripwire может служить еще одним прекрасным примером программного обеспечения с открытыми исходными текстами, совершившего переход на коммерческую платформу. Первоначально Tripwire была в чистом виде программой с открытыми исходными текстами. Со временем основатели организовали компанию для продажи и поддержки Tripwire на коммерческой основе, однако исходный базовый код они выпустили под лицензией GPL, чтобы разработка могла продолжаться в сообществе открытого ПО. Текущая открытая версия 2.3 была получена путем обновления версии 2.2.1, выпущенной в октябре 2000 года.

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

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

    Установка Tripwire

  • Чтобы установить Tripwire, возьмите файлы с компакт-диска или загрузите RPM или tar с web-сайта Tripwire для компиляции исходных текстов.

    Для некоторых дистрибутивов существуют также доступные RPM (RPM для Mandrake и RedHat помещены на компакт-диск). Просто щелкните мышью на файле RPM, чтобы установить программу. Если у вас нет RPM для вашей операционной системы, то можно загрузить файл .tar с исходными текстами (или "tarball", как его часто называют) для последующей компиляции. Распакуйте tar-файл и перейдите в каталог src.

  • В каталоге src наберите
    make all

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

  • Откройте файл install.cfg и проверьте, что все подразумеваемые значения подходят для вашей системы. Этот файл управляет местом установки файлов программы и другими переменными системного уровня. Большинство подразумеваемых значений годятся для большинства систем. Проверьте, что ваш почтовый клиент задан правильно.
  • После установки переменных окружения перейдите в каталог /etc/tripwire и наберите twinnstall.sh.

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

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

  • На этом процесс установки Tripwire завершается.

    Конфигурирование Tripwire

    Заключительным шагом, предшествующим запуску Tripwire, служит задание вашей политики. Файл политики очень важен для работы Tripwire: в нем специфицируются отслеживаемые файлы и уровень детализации. Основной файл политики, twpol.txt, находится в главном каталоге Tripwire. Строго говоря, это не сам файл политики, а копия зашифрованной версии, которую в действительности использует программа. Для большей безопасности необходимо сделать копию и удалить незашифрованную версию twpol.txt, после того как вы определите и протестируете свою политику.

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

    Маски свойств Tripwire
    Буква кода Отслеживаемый атрибут
    a Время последнего доступа
    b Отведенные блоки
    с Время создания/изменения
    d Идентификатор устройства, на котором располагается описатель файла
    g Идентификатор владеющей группы файла
    i Номер описателя файла
    l Разрешен ли рост файла
    m Метка времени изменения
    n Значение счетчика ссылок в описателе файла
    p Режим доступа к файлу
    s Размер файла
    t Тип файла
    u Идентификатор пользователя владельца файла
    C Хэш-код CRC32
    H Хэш-код Haval
    M Хэш-код MD5
    S Хэш-код SHA/SHS

    Политики Tripwire действуют по принципу флагов игнорирования. Можно сконфигурировать Tripwire для отслеживания или игнорирования различных свойств файлов. Знак + (плюс) используется для отслеживания свойств, а знак - (минус) - для их игнорирования. Формат инструкций в файле политики таков:

    имя_файла/каталога -> маска_свойств;

    Например, следующая строка в файле политики

    /etc/secretfile.txt -> +amcpstu;

    предписывает Tripwire извещать вас всякий раз, когда у файла secretfile.txt в каталоге /etc изменяются время последнего доступа, время создания или модификации, режим доступа, владелец, размер или тип файла.

    Существует также несколько предопределенных масок свойств. В табл. 7.5 перечислены эти стандартные маски и их действие.

    Стандартные маски свойств
    Маска свойств Действие
    $Readonly +pinugtsdbmCM-rlaSH
    $Dynamic +pinugtd-srlbamcCMSH
    $Growing +pinugtdl-srbamcCMSH
    $Device +pugsdr-intlbamcCMSH
    $IgnoreAll -pinugtsdrlbamcCMSH
    $IgnoreNone +pinugtsdrrlbamcCMSH

    Предопределенные переменные соответствуют поведению различных наборов файлов. Например, можно использовать $Readonly для ключевых конфигурационных файлов, так как время доступа будет изменяться, когда программы их используют, но вы не желаете, чтобы изменялись размер или содержимое. Можно использовать $Growing для файлов журналов, так как они будут (во всяком случае, должны) постоянно увеличиваться в размере.

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

    SEC_CRIT = $(IgnoreNone)-SHa ; # Критичные файлы, которые 
                                   # не могут изменяться
    SEC_SUID = $(IgnoreNone)-SHa ; # Бинарные файлы с установленными
                                   # флагами SUID или SGID
    SEC_BIN = $(ReadOnly) ;        # Бинарные файлы, которые не 
                                   # должны изменяться
    SEC_CONFIG = $(Dynamic) ;      # Конфигурационные файлы, 
                                   # которые редко изменяются, 
                                   # но часто используются
    SEC_LOG = $(Growing) ;         # Файлы, которые увеличиваются,
                                   # но никогда не должны менять
                                   # владельца
    SEC_INVARIANT = +tpug ;        # Каталоги, у которых никогда 
                                   # не должны изменяться режим
                                   # доступа или владелец
    SIG_LOW = 33 ;                 # Некритичные файлы, которые
                                   # имеют минимальное влияние 
                                   # на безопасность
    SIG_MED = 66 ;                 # Некритичные файлы, которые
                                   # имеют значительное влияние
                                   # на безопасность
    SIG_HI = 100 ;                 # Критичные файлы, которые
                                   # являются существенными точками уязвимости

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

    Инициализация эталонной базы данных

    Первым шагом при выполнении Tripwire является формирование эталонной базы данных. Создается начальный список сигнатур, согласно которым будут применяться политики. Помните, что выполнение этого шага после того, как в системе появились подозрительные файлы, ни к чему хорошему не приведет; необходимо создать эталонную базу данных до того, как появятся какие-либо проблемы с безопасностью, лучше всего сразу после установки и конфигурирования системы. Чтобы создать начальный файл базы данных, используйте команду

    tripwire -m i -v

    Ключ -m определяет режим выполнения, в данном случае i означает инициализацию. Ключ -v задает расширенный вывод, чтобы можно было посмотреть, что происходит. Tripwire определяет все файлы, заданные в файле политики, создает базу данных в каталоге ./database и шифрует ее с помощью пароля сайта.

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

    Проверка целостности файлов

    Это основной режим выполнения программы Tripwire после ввода в эксплуатацию. В этом режиме текущие атрибуты определенных файлов сравниваются с атрибутами в базе данных Tripwire. Формат запуска в этом режиме таков:

    tripwire -m c маршрутное_имя

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

    Обновление базы данных

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

    tripwire -m u -r маршрутное_имя_отчета

    Здесь маршрутное_имя_отчета соответствует самому свежему файлу отчета. Выполнение этой команды покажет все произошедшие изменения, а также правила, их обнаружившие. Рядом с файлами, в которых обнаружились изменения, будет присутствовать знак x в квадратных скобках. Если оставить x на месте, то Tripwire обновит сигнатуру для этого файла, когда вы закончите работу с отчетом. Если удалить x, то Tripwire будет предполагать, что исходная сигнатура правильна, и не будет ее обновлять. При выходе Tripwire внесет изменения. Можно задать ключ -c в командной строке, чтобы пропустить предварительный просмотр отчета. В этом случае Tripwire просто учтет обнаруженные изменения.

    Обновление файла политики

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

    tripwire -m p текстовый_файл_политики

    указав новый файл политики. Прежде чем обновить политику, Tripwire запросит у вас пароли для сайта и локального входа. Когда политики Tripwire будут настроены в достаточной степени, можно будет создать задание cron и выполнять его ежедневно (или так часто, как захотите), чтобы проверять файловые системы в поисках следов взлома.

    Страницы:

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

    Обзор лекции

    Изучаемые концепции:

  • Типы систем обнаружения вторжений
  • Сигнатуры для систем обнаружения вторжений
  • Ложные срабатывания в сетевых системах обнаружения вторжений
  • Правильное размещение систем обнаружения вторжений
  • Настройка систем обнаружения вторжений
  • Контроль целостности файлов
  • Используемые инструменты:

    Snort, модуль Snort Webmin, Snort for Windows, Tripwire

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

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

    (рис 7.1) Защита с помощью сетевой системы обнаружения вторжений и межсетевого экрана

    Имеется веская причина, чтобы внимательно следить за трафиком внутренней сети. Как показывает статистика ФБР, более 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, сетевая система обнаружения вторжений может идентифицировать данную атаку. На листинге 7.1 показан один из таких пакетов. Шестнадцатеричное представление содержимого находится слева, а перевод в текст - справа.

    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 - консоль анализа для обнаружения вторжений). Оно подробно рассматривается в лекции 8.

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

    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 устанавливается довольно просто.

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

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

    Режим анализа пакетов

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

    Испробовать этот режим можно, просто набрав в командной строке

    snort -v

    или

    snort -vde

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

    Опции режима анализа пакетов
    Опция Описание
    -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.

    Опции режима сигнализации 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, игнорируют. Строки комментариев применяются для документирования программ или для отключения старого кода. Вы будете использовать их позже при тонкой настройке набора правил. Но пока единственными строками, реально воздействующими на конфигурацию, являются строки без знака # в начале. Остальные присутствуют только для информационных целей. Конфигурационный файл настраивается в несколько шагов.

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

    Необходимо сообщить Snort адреса, которые представляют домашнюю сеть, чтобы он мог правильно интерпретировать внешние атаки. Это делается с помощью инструкции

    var HOME_NET адреса

    где адреса следует заменить на адресное пространство вашей локальной сети. Если имеется несколько сетей, то можно ввести их все, разделяя запятыми. Можно также ввести имя интерфейса, чтобы IP-адрес и маска сети, присвоенные этому интерфейсу, использовались как HOME_NET. Для этого служит следующий формат:

    var HOME_NET $ имя_интерфейса

    где имя_интерфейса заменяется интерфейсом, на котором слушает Snort (например, eth0 или eth1).

    С помощью аналогичной инструкции можно определить внешние сети, заменяя HOME_NET на EXTERNAL_NET. Подразумеваемым значением обеих переменных служит any. Можно оставить их в таком виде или определить одну или обе. Я рекомендую определить внутреннюю сеть, но оставить внешние сети заданными как any.

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

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

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

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

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

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

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

    Это важный шаг, если вы хотите использовать базу данных при обработке вывода 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 и других программ обсуждается в лекции 8.

  • Unified

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

    output alert_unified: filename snort.alert, limit 128
  • Индивидуализация наборов правил.

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

  • Закончив внесение изменений в конфигурационный файл, сохраните его, и тогда все будет готово для запуска Snort.

    Правильное размещение сетевой системы обнаружения вторжений

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

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

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

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

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

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

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

  • Мы перечислили все разумные варианты размещения системы обнаружения вторжений. Разумеется, ничто не мешает использовать их все, если у вас достаточно оборудования и времени для управления.

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

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

    Имена файлов классов правил 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 (если включено).
  • В лекции 3 рассмотрена загрузка Webmin для администрирования межсетевого экрана. Этот же дополнительный модуль можно применять и для конфигурирования Snort. Обратитесь к лекции 3, если вы еще не загрузили Webmin.

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

    Чтобы загрузить модуль Snort через интерфейс Webmin, выполните следующие действия.

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

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

    (рис 7.3) Страница редактирования наборов правил Webmin Snort

    Модуль Webmin Snort позволяет также управлять доступом пользователей к настройкам (рис. 7.4). На странице пользователей Webmin можно задать ряд параметров для каждого пользователя (при условии, что вы являетесь администратором Webmin). Можно предоставить определенным пользователям доступ для редактирования правил, но не для редактирования конфигурационных файлов. Можно управлять тем, к каким конфигурационным файлам они будут иметь доступ - или позволить им только просматривать файлы без редактирования или отключения. Таким образом, модуль Webmin Snort предоставляет весьма детальное управление доступом, что позволяет вам делегировать ежедневные обязанности по настройке менее квалифицированному техническому специалисту, оставляя за собой управление конфигурацией и изменениями.

    (рис 7.4) Управление доступом для модуля Webmin Snort
    Snort for Windows: система обнаружения вторжений для Windows с открытыми исходными текстами

    Snort for Windows

    Автор/основной контакт: Martin Roesch

    Перенос в Windows: Michael Davis, Chris Reid

    Web-сайт: http://www.snort.org

    Платформы: Windows 2000, XP

    Лицензия: GPL

    Рассмотренная версия: 2.0.0

    Другие ресурсы: См. список в разделе "Snort: система обнаружения вторжений для UNIX с открытыми исходными текстами" выше в этой лекции.

    К счастью для тех, кто не может или не хочет устанавливать версию 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 для этой цели описана в лекции 8.

    Для того чтобы 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 (см. описания в лекции 6) или по полезной нагрузке пакета. За каждой опцией должны следовать кавычки и разыскиваемое значение. Можно добавить несколько опций, разделяя их с помощью точки с запятой. Ниже приведены допустимые опции.

    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. Также тщательно протестируйте свои правила, чтобы гарантировать, что они действительно охватывают все виды активности, которую вы пытаетесь поймать, и не дают ложных срабатываний.

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

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

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

    Преимущества хостовых методов обнаружения вторжений

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

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

    Tripwire

    Автор/основной контакт: Dr. Eugene Spafford и Gene Kim

    Web-сайт: http://www.tripwire.org

    Платформы: Большинство UNIX

    Лицензия: GPL

    Рассматриваемая версия: V 2.3.47

    Tripwire может служить еще одним прекрасным примером программного обеспечения с открытыми исходными текстами, совершившего переход на коммерческую платформу. Первоначально Tripwire была в чистом виде программой с открытыми исходными текстами. Со временем основатели организовали компанию для продажи и поддержки Tripwire на коммерческой основе, однако исходный базовый код они выпустили под лицензией GPL, чтобы разработка могла продолжаться в сообществе открытого ПО. Текущая открытая версия 2.3 была получена путем обновления версии 2.2.1, выпущенной в октябре 2000 года.

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

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

    Установка Tripwire

  • Чтобы установить Tripwire, возьмите файлы с компакт-диска или загрузите RPM или tar с web-сайта Tripwire для компиляции исходных текстов.

    Для некоторых дистрибутивов существуют также доступные RPM (RPM для Mandrake и RedHat помещены на компакт-диск). Просто щелкните мышью на файле RPM, чтобы установить программу. Если у вас нет RPM для вашей операционной системы, то можно загрузить файл .tar с исходными текстами (или "tarball", как его часто называют) для последующей компиляции. Распакуйте tar-файл и перейдите в каталог src.

  • В каталоге src наберите
    make all

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

  • Откройте файл install.cfg и проверьте, что все подразумеваемые значения подходят для вашей системы. Этот файл управляет местом установки файлов программы и другими переменными системного уровня. Большинство подразумеваемых значений годятся для большинства систем. Проверьте, что ваш почтовый клиент задан правильно.
  • После установки переменных окружения перейдите в каталог /etc/tripwire и наберите twinnstall.sh.

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

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

  • На этом процесс установки Tripwire завершается.

    Конфигурирование Tripwire

    Заключительным шагом, предшествующим запуску Tripwire, служит задание вашей политики. Файл политики очень важен для работы Tripwire: в нем специфицируются отслеживаемые файлы и уровень детализации. Основной файл политики, twpol.txt, находится в главном каталоге Tripwire. Строго говоря, это не сам файл политики, а копия зашифрованной версии, которую в действительности использует программа. Для большей безопасности необходимо сделать копию и удалить незашифрованную версию twpol.txt, после того как вы определите и протестируете свою политику.

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

    Маски свойств Tripwire
    Буква кода Отслеживаемый атрибут
    a Время последнего доступа
    b Отведенные блоки
    с Время создания/изменения
    d Идентификатор устройства, на котором располагается описатель файла
    g Идентификатор владеющей группы файла
    i Номер описателя файла
    l Разрешен ли рост файла
    m Метка времени изменения
    n Значение счетчика ссылок в описателе файла
    p Режим доступа к файлу
    s Размер файла
    t Тип файла
    u Идентификатор пользователя владельца файла
    C Хэш-код CRC32
    H Хэш-код Haval
    M Хэш-код MD5
    S Хэш-код SHA/SHS

    Политики Tripwire действуют по принципу флагов игнорирования. Можно сконфигурировать Tripwire для отслеживания или игнорирования различных свойств файлов. Знак + (плюс) используется для отслеживания свойств, а знак - (минус) - для их игнорирования. Формат инструкций в файле политики таков:

    имя_файла/каталога -> маска_свойств;

    Например, следующая строка в файле политики

    /etc/secretfile.txt -> +amcpstu;

    предписывает Tripwire извещать вас всякий раз, когда у файла secretfile.txt в каталоге /etc изменяются время последнего доступа, время создания или модификации, режим доступа, владелец, размер или тип файла.

    Существует также несколько предопределенных масок свойств. В табл. 7.5 перечислены эти стандартные маски и их действие.

    Стандартные маски свойств
    Маска свойств Действие
    $Readonly +pinugtsdbmCM-rlaSH
    $Dynamic +pinugtd-srlbamcCMSH
    $Growing +pinugtdl-srbamcCMSH
    $Device +pugsdr-intlbamcCMSH
    $IgnoreAll -pinugtsdrlbamcCMSH
    $IgnoreNone +pinugtsdrrlbamcCMSH

    Предопределенные переменные соответствуют поведению различных наборов файлов. Например, можно использовать $Readonly для ключевых конфигурационных файлов, так как время доступа будет изменяться, когда программы их используют, но вы не желаете, чтобы изменялись размер или содержимое. Можно использовать $Growing для файлов журналов, так как они будут (во всяком случае, должны) постоянно увеличиваться в размере.

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

    SEC_CRIT = $(IgnoreNone)-SHa ; # Критичные файлы, которые 
                                   # не могут изменяться
    SEC_SUID = $(IgnoreNone)-SHa ; # Бинарные файлы с установленными
                                   # флагами SUID или SGID
    SEC_BIN = $(ReadOnly) ;        # Бинарные файлы, которые не 
                                   # должны изменяться
    SEC_CONFIG = $(Dynamic) ;      # Конфигурационные файлы, 
                                   # которые редко изменяются, 
                                   # но часто используются
    SEC_LOG = $(Growing) ;         # Файлы, которые увеличиваются,
                                   # но никогда не должны менять
                                   # владельца
    SEC_INVARIANT = +tpug ;        # Каталоги, у которых никогда 
                                   # не должны изменяться режим
                                   # доступа или владелец
    SIG_LOW = 33 ;                 # Некритичные файлы, которые
                                   # имеют минимальное влияние 
                                   # на безопасность
    SIG_MED = 66 ;                 # Некритичные файлы, которые
                                   # имеют значительное влияние
                                   # на безопасность
    SIG_HI = 100 ;                 # Критичные файлы, которые
                                   # являются существенными точками уязвимости

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

    Инициализация эталонной базы данных

    Первым шагом при выполнении Tripwire является формирование эталонной базы данных. Создается начальный список сигнатур, согласно которым будут применяться политики. Помните, что выполнение этого шага после того, как в системе появились подозрительные файлы, ни к чему хорошему не приведет; необходимо создать эталонную базу данных до того, как появятся какие-либо проблемы с безопасностью, лучше всего сразу после установки и конфигурирования системы. Чтобы создать начальный файл базы данных, используйте команду

    tripwire -m i -v

    Ключ -m определяет режим выполнения, в данном случае i означает инициализацию. Ключ -v задает расширенный вывод, чтобы можно было посмотреть, что происходит. Tripwire определяет все файлы, заданные в файле политики, создает базу данных в каталоге ./database и шифрует ее с помощью пароля сайта.

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

    Проверка целостности файлов

    Это основной режим выполнения программы Tripwire после ввода в эксплуатацию. В этом режиме текущие атрибуты определенных файлов сравниваются с атрибутами в базе данных Tripwire. Формат запуска в этом режиме таков:

    tripwire -m c маршрутное_имя

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

    Обновление базы данных

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

    tripwire -m u -r маршрутное_имя_отчета

    Здесь маршрутное_имя_отчета соответствует самому свежему файлу отчета. Выполнение этой команды покажет все произошедшие изменения, а также правила, их обнаружившие. Рядом с файлами, в которых обнаружились изменения, будет присутствовать знак x в квадратных скобках. Если оставить x на месте, то Tripwire обновит сигнатуру для этого файла, когда вы закончите работу с отчетом. Если удалить x, то Tripwire будет предполагать, что исходная сигнатура правильна, и не будет ее обновлять. При выходе Tripwire внесет изменения. Можно задать ключ -c в командной строке, чтобы пропустить предварительный просмотр отчета. В этом случае Tripwire просто учтет обнаруженные изменения.

    Обновление файла политики

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

    tripwire -m p текстовый_файл_политики

    указав новый файл политики. Прежде чем обновить политику, Tripwire запросит у вас пароли для сайта и локального входа. Когда политики Tripwire будут настроены в достаточной степени, можно будет создать задание cron и выполнять его ежедневно (или так часто, как захотите), чтобы проверять файловые системы в поисках следов взлома.

    Вернуться к учебному плану