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

Флаг, который сигнализирует о переполнении счетчика последовательного номера.

Окно для подавления атак воспроизведения

Используется для определения повторной передачи пакетов. Если значение в поле Sequence Number не попадает в заданный диапазон, то пакет уничтожается.

Информация AH

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

Информация ESP

алгоритмы шифрования и аутентификации, необходимые ключи, параметры инициализации (например, IV), время жизни ключей и другие параметры

Режим работы IPsec

туннельный или транспортный

Время жизни SA

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

MTU

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

Каждый протокол (ESP/AH) должен иметь свой собственный SA для каждого направления, таким образом, связка AH+ESP требует для дуплексного канала наличия четырёх SA. Все эти данные располагаются в SAD.

В SAD содержатся:

· AH: алгоритм аутентификации.

· AH: секретный ключ для аутентификации

· ESP: алгоритм шифрования.

· ESP: секретный ключ шифрования.

· ESP: использование аутентификации (да/нет).

· Параметры для обмена ключами

· Ограничения маршрутизации

· Политика IP-фильтрации

Security Policy Database [править | править вики-текст]

Помимо базы данных SAD, реализации IPsec поддерживают базу данных SPD (Security Policy Database — база данных политики безопасности). SPD служит для соотнесения приходящих IP-пакетов с правилами обработки для них. Записи в SPD состоят из двух полей.^[8] В первом хранятся характерные признаки пакетов, по которым можно выделить тот или иной поток информации. Эти поля называются селекторами. Примеры селекторов, которые содержатся в SPD: ^[6]

· IP-адрес места назначения

· IP-адрес отправителя

· Имя пользователя в формате DNS или X.500

· Порты отправителя и получателя

Второе поле в SPD содержит политику защиты, соответствующую данному потоку пакетов. Селекторы используются для фильтрации исходящих пакетов с целью поставить каждый пакет в соответствие с определенным SA. Когда поступает пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся в SPD. При нахождении совпадения в поле политики защиты содержится информация о том, как поступать с данным пакетом: передать без изменений, отбросить или обработать. В случае обработки, в этом же поле содержится ссылка на соответствующую запись в SAD. Затем определяется SA для пакета и сопряжённый с ней индекс параметров безопасности (SPI), после чего выполняются операции IPsec (операции протокола AH или ESP). Если пакет входящий, то в нём сразу содержится SPI — проводится соответствующая обработка.

Authentication Header[править | править вики-текст]

Authentication Header format

Offsets

Octet16

Octet16

Bit10

Next Header

Payload Len

Reserved

Security Parameters Index (SPI)

Sequence Number

C

Integrity Check Value (ICV) …

…

…

Тип следующего заголовка (8 bits)

Тип заголовка протокола, идущего после заголовка AH. По этому полю приёмный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700.

Длина содержимого (8 bits)

Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.

Зарезервировано (16 bits)

Зарезервировано. Заполняется нулями.

Индекс параметров системы безопасности (32 bits)

Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован IANA.

Порядковый номер (32 bits)

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

Данные аутентификации

Цифровая подпись. Служит для аутентификации и проверки целостности пакета. Должна быть дополнена до размера, кратного 8-байтам для IPv6, и 4-байтам для IPv4.

Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче^[9].Обработка выходных IP-пакетов [править | править вики-текст]

Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает AH-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) он по-разному вставляет AH-заголовок в IP-пакет. В транспортном режиме AH-заголовок располагается после заголовка протокола IP и перед заголовками протоколов верхнего уровня (Обычно, TCP или UDP). В режиме туннелирования весь исходный IP-пакет обрамляется сначала заголовком AH, затем заголовком IP-протокола. Такой заголовок называется внешним, а заголовок исходного IP-пакета- внутренним. После этого передающий IPsec-модуль должен сгенерировать последовательный номер и записать его в поле Sequence Number. При установлении SA последовательный номер устанавливается в 0, и перед отправкой каждого IPsec-пакета увеличивается на единицу. Кроме того, происходит проверка- не зациклился ли счетчик. Если он достиг своего максимального значения, то он снова устанавливается в 0. Если используется услуга по предотвращению повторной передачи, то при достижении счетчика своего максимального значения, передающий IPsec-модуль переустанавливает SA. Таким образом обеспечивается защита от повторной посылки пакета- приёмный IPsec-модуль будет проверять поле Sequence Number, и игнорировать повторно приходящие пакеты. Дале происходит вычисление контрольной суммы ICV. Надо заметить,

что здесь контрольная сумма вычисляется с применением секретного ключа, без которого злоумышленник сможет заново вычислить хэш, но не зная ключа, не сможет сформировать правильную контрольную сумму. Конкретные алгоритмы, использующиеся для вычисления ICV, можно узнать из RFC 4305. В настоящее время могут применяться, например, алгоритмы HMAC-SHA1-96 или AES-XCBC-MAC-96. Протокол АН вычисляет контрольную сумму (ICV) по следующим полям IPsec-пакета: ^[10]поля IP-заголовка, которые не были подвержены изменениям в процессе транслирования, или определены как наиболее важныеАН-заголовок (Поля: «Next Header», "Payload Len, «Reserved», «SPI», «Sequence Number», «Integrity Check Value». Поле «Integrity Check Value» устанавливается в 0 при вычислении ICVданные протокола верхнего уровняЕсли поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приёме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402.

Обработка входных IP-пакетов [править | править вики-текст]

После получения пакета, содержащего сообщение АН-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) SAD (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. При этом используется метод скользящего окна для ограничения буферной памяти, требуемый для работы протоколу. Приёмный IPsec-модуль формирует окно с шириной W (обычно W выбирается равным 32 или 64 пакетам). Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то принятый пакет уничтожается.

Encapsulating Security Payload[править | править вики-текст]

Security Parameters Index (32 bits)

Индекс параметров безопасности (аналогичен соответствующему полю AH). Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (ESP-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован IANA для последующего использования.

Sequence Number (32 bits)

Последовательный номер (аналогичен соответствующему полю AH). Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в ESP-заголовке. Отправитель (передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке.

Payload data (variable)

Это поле содержит данные (в зависимости от выбора режима — туннельного или транспортного, здесь может находиться либо весь исходный инкапсулированный пакет, либо лишь его данные) в соответствии с полем «Next Header». Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации — «Initialization Vector»), то это поле может содержать эти данные в явном виде.

Padding (0-255 octets)

Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра.

Pad Length (8 bits)

Размер дополнения (в байтах).

Next Header (8 bits)

Это поле определяет тип данных, содержащихся в поле «Payload data».

Integrity Check Value

Контрольная сумма. Служит для аутентификации и проверки целостности пакета. Должна быть кратна 8-байтам для IPv6, и 4-байтам для IPv4.^[11]

Обработка выходных IPsec-пакетов [править | править вики-текст]

Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает ESP-обработку, то он начинает обработку. В зависимости от режима(транспортный или режим туннелирования) исходный IP-пакет обрабатывается по-разному. В транспортном режиме передающий IPsec-модуль осуществляет процедуру обрамления протокола верхнегоуровня (например, TCP или UDP), используя для этого ESP-заголовок (поля Security Parameters Index и Sequence Number заголовка) и ESP-концевик (остальные поля заголовка, следующие за полем данных — Payload data), не затрагивая при этом заголовок исходного IP-пакета. В режиме туннелирования IP-пакет обрамляется ESP-заголовком и ESP-концевиком (инкапсуляция), после чего обрамляется внешним IP-заголовком (который может не совпадать с исходным — например, если IPsec модуль установлен на шлюзе).^[8] Далее произвоится шифрование- в транспортном режиме шифруется только сообщение протокола выше лежащего уровня (то есть все, что находилось после IP-заголовка в исходном пакете), в режиме туннелирования- весь исходный IP-пакет. Передающий IPsec-модуль из записи о SA определяет алгоритм шифрования и секретный ключ. Стандарты IPsec разрешают использование алгоритмов шифрования Triple DES, AES и Blowfish, если их поддерживают обе стороны. Иначе используется DES, прописанный в RFC 2405. Так как размер открытого текста должен быть кратен определенному числу байт, например, размеру блока для блочных алгоритмов, перед шифрованием производится ещё и необходимое дополнение шифруемого сообщения. Зашифрованное сообщение помещается в поле Payload Data. В поле Pad Length помещается длина дополнения. Затем, как и в AH, вычисляется Sequence Number. После чего считается контрольная сумма (ICV). Контрольная сумма, в отличие от протокола AH, где при её вычислении учитываются также и некоторые поля IP-заголовка, в ESP вычисляется только по полям ESP-пакета за вычетом поля ICV. Перед вычислением контрольной суммы оно заполняется нулями. Алгоритм вычисления ICV, как и в протоколе AH, передающий IPsec-модуль узнает из записи об SA, с которым связан обрабатываемый пакет.

Обработка входных IPsec-пакетов [править | править вики-текст]

После получения пакета, содержащего сообщение ESP-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) в SAD, используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI. ^[8] Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приёмный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приёмный пакет уничтожается. Далее производится расшифрование пакета. Приёмный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования также должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа «отказ в обслуживании»(DOS-атаки). Далее расшифрованное сообщение в соответствии с полем Next Header передается для дальнейшей обработки.

IKE[править | править вики-текст]

Основная статья: IKE

IKE (произносится айк, аббр. от Internet Key Exchange) — протокол, связывающий все компоненты IPsec в работающее целое. В частности, IKE обеспечивает первоначальную аутентификацию сторон, а также их обмен общими секретными ключами.

Существует возможность вручную установить ключ для сессии (не путать с pre-shared key [PSK] для аутентификации). В этом случае IKE не используется. Однако этот вариант не рекомендуется и используется редко. Традиционно, IKE работает через порт 500 UDP.

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

Первая фаза [править | править вики-текст]

IKE создает безопасный канал между двумя узлами, называемый IKE security association (IKE SA). Также, в этой фазе два узла согласуют сессионный ключ по алгоритму Диффи-Хеллмана. Первая фаза IKE может проходить в одном из двух режимов:^[12]

· Основной режим

Состоит из трёх двусторонних обменов между отправителем и получателем:

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

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

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

· Агрессивный режим

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

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

Вторая фаза [править | править вики-текст]

В фазе два IKE существует только один, быстрый, режим. Быстрый режим выполняется только после создания безопасного канала в ходе первой фазы. Он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Использование последовательных номеров обеспечивает защиту от атак повторной передачи. Также быстрый режим используется для пересмотра текущей IPsec SA и выбора новой, когда время жизни SA истекает. Стандартно быстрый режим проводит обновление общих секретных ключей, используя алгоритм Диффи-Хеллмана из первой фазы.

Как работает IPsec[править | править вики-текст]

В работе протоколов IPsec можно выделить пять этапов:^[13]

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

2. Второй этап является по сути первой фазой IKE. Её цель — организовать безопасный канал между сторонами для второй фазы IKE. На втором этапе выполняются:

Аутентификация и защита идентификационной информации узлов

Проверка соответствий политик IKE SA узлов для безопасного обмена ключами

Обмен Диффи-Хеллмана, в результате которого у каждого узла будет общий секретный ключ

Создание безопасного канала для второй фазы IKE

Третий этап является второй фазой IKE. Его задачей является создание IPsec-туннеля. На третьем этапе выполняются следующие функции:Согласуются параметры IPsec SA по защищаемому IKE SA каналу, созданному в первой фазе IKE

Устанавливается IPsec SA

Периодически осуществляется пересмотр IPsec SA, чтобы убедиться в её безопасности

(Опционально) выполняется дополнительный обмен Диффи-Хеллмана

Рабочий этап. После создания IPsec SA начинается обмен информацией между узлами через IPsec-туннель, используются протоколы и параметры, установленные в SA.

Прекращают действовать текущие IPsec SA. Это происходит при их удалении или при истечении времени жизни (определенное в SA в байтах информации, передаваемой через канал, или в секундах), значение которого содержится в SAD на каждом узле. Если требуется продолжить передачу, запускается фаза два IKE (если требуется, то и первая фаза) и далее создаются новые IPsec SA. Процесс создания новых SA может происходить и до завершения действия текущих, если требуется непрерывная передача данных.

Использование[править | править вики-текст]

Протокол IPsec используется, в основном, для организации VPN-туннелей. В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания межсетевого экрана. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом.^[14]Например, он может отклонять определенные пакеты, тем самым прекращая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить веб-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов HTTP и HTTPS. IPsec можно применять и для защиты серверов — для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP, или через порт TCP 443 в случаях, когда применяется HTTPS. Пример^[15]:

IPsec_VPN

С помощью IPsec здесь обеспечивается безопасный доступ пользователей к серверу. При использовании протокола ESP, все обращения к серверу и его ответы шифруются. Однако за VPN шлюзом (в домене шифрования) передаются открытые сообщения. Другие примеры использования IPsec^[16]:

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

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

[править | править вики-текст]

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 19 февраля 2016; проверки требуют 5 правок.

Система обнаружения вторжений (СОВ) — программное или аппаратное средство, предназначенное для выявления фактов неавторизованного доступа в компьютерную систему или сеть либо несанкционированного управления ими в основном через Интернет. Соответствующий английский термин — Intrusion Detection System (IDS). Системы обнаружения вторжений обеспечивают дополнительный уровень защиты компьютерных систем.

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

Обычно архитектура СОВ включает:

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

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

· хранилище, обеспечивающее накопление первичных событий и результатов анализа

· консоль управления, позволяющая конфигурировать СОВ, наблюдать за состоянием защищаемой системы и СОВ, просматривать выявленные подсистемой анализа инциденты

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

Содержание

[скрыть]

· 1Виды систем обнаружения вторжений

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

· 3Сравнение СОВ и межсетевого экрана

· 4История разработок СОВ

· 5Свободно распространяемые СОВ

· 6Коммерческие СОВ

· 7См. также

· 8Примечания

· 9Ссылки

Виды систем обнаружения вторжений[править | править вики-текст]

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

· Сетевая СОВ (Network-based IDS, NIDS) отслеживает вторжения, проверяя сетевой трафик и ведет наблюдение за несколькими хостами. Сетевая система обнаружения вторжений получает доступ к сетевому трафику, подключаясь к хабу или свитчу, настроенному на зеркалирование портов, либо сетевое TAP устройство. Примером сетевой СОВ является Snort.

· Основанная на протоколе СОВ (Protocol-based IDS, PIDS) представляет собой систему (либо агента), которая отслеживает и анализирует коммуникационные протоколы со связанными системами или пользователями. Для веб-сервера подобная СОВ обычно ведет наблюдение за HTTP и HTTPS протоколами. При использовании HTTPS СОВ должна располагаться на таком интерфейсе, чтобы просматривать HTTPS пакеты ещё до их шифрования и отправки в сеть.

· Основанная на прикладных протоколах СОВ (Application Protocol-based IDS, APIDS) — это система (или агент), которая ведет наблюдение и анализ данных, передаваемых с использованием специфичных для определенных приложений протоколов. Например, на веб-сервере с SQL базой данных СОВ будет отслеживать содержимое SQL команд, передаваемых на сервер.

· Узловая СОВ (Host-based IDS, HIDS) — система (или агент), расположенная на хосте, отслеживающая вторжения, используя анализ системных вызовов, логов приложений, модификаций файлов (исполняемых, файлов паролей, системных баз данных), состояния хоста и прочих источников. Примером является OSSEC.

· Гибридная СОВ совмещает два и более подходов к разработке СОВ. Данные от агентов на хостах комбинируются с сетевой информацией для создания наиболее полного представления о безопасности сети. В качестве примера гибридной СОВ можно привести Prelude.

Пассивные и активные системы обнаружения вторжений[править | править вики-текст]

В пассивной СОВ при обнаружении нарушения безопасности информация о нарушении записывается в лог приложения, а также сигналы опасности отправляются на консоль и/или администратору системы по определенному каналу связи. В активной системе, также известной как Система Предотвращения Вторжений (IPS — Intrusion Prevention system (англ.)), СОВ ведет ответные действия на нарушение, сбрасывая соединение или перенастраивая межсетевой экран для блокирования трафика от злоумышленника. Ответные действия могут проводиться автоматически либо по команде оператора.

Сравнение СОВ и межсетевого экрана[править | править вики-текст]

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

История разработок СОВ[править | править вики-текст]

Первая концепция СОВ появилась благодаря Джеймсу Андерсону и статье ^[1]. В 1984 Фред Коэн (см. Обнаружение вторжений) сделал заявление о том, что каждое вторжение обнаружить невозможно и ресурсы, необходимые для обнаружения вторжений, будут расти вместе с степенью использования компьютерных технологий.

Дороти Деннинг, при содействии Питера Неймана, опубликовали модель СОВ в 1986, сформировавшую основу для большинства современных систем.^[2] Её модель использовала статистические методы для обнаружения вторжений и называлась IDES (Intrusion detection expert system — экспертная система обнаружения вторжений). Система работала на рабочих станциях Sun и проверяла как сетевой трафик, так и данные пользовательских приложений.^[3]

IDES использовала два подхода к обнаружению вторжений: в ней использовалась экспертная система для определения известных видов вторжений и компонент обнаружения, основанный на статистических методах и профилях пользователей и систем охраняемой сети. Тереза Лунт ^[4] предложила использовать искусственную нейронную сеть как третий компонент для повышения эффективности обнаружения. Вслед за IDES в 1993 вышла NIDES (Next-generation Intrusion Detection Expert System — экспертная система обнаружения вторжений нового поколения).

MIDAS (Multics intrusion detection and alerting system), экспертная система, использующая P-BEST и LISP, была разработана в 1988 году на основе работы Деннинга и Неймана.^[5] В этом же году была разработана система Haystack, основанная на статистических методах.^[6]

W&S (Wisdom & Sense — мудрость и чувство), основанный на статистических методах детектор аномалий, был разработан в 1989 году в Лос-Аламосской Национальной лаборатории.^[7] W&S создавал правила на основе статистического анализа и затем использовал эти правила для обнаружения аномалий.

В 1990, в TIM (Time-based inductive machine) было реализовано обнаружение аномалий с использованием индуктивного обучения на основе последовательных паттернов пользователя на языке Common LISP.^[8] Программа была разработана для VAX 3500. Примерно в то же время был разработан NSM (Network Security Monitor — монитор сетевой безопасности), сравнивающий матрицы доступа для обнаружения аномалий на рабочих станциях Sun-3/50.^[9] В том же 1990 году был разработан ISOA (Information Security Officer’s Assistant), содержащий в себе множество стратегий обнаружения, включая статистику, проверку профиля и экспертную систему.^[10] ComputerWatch, разработанный в AT&T Bell Labs, использовал статистические методы и правила для проверки данных и обнаружения вторжений.^[11]

Далее, в 1991, разработчики Университета Калифорнии разработали прототип распределенной системы DIDS (Distributed intrusion detection system), которая также являлась экспертной системой.^[12] Также в 1991 сотрудниками Национальной Лаборатории Встроенных Вычислительных Сетей (ICN) была разработана система NADIR (Network anomaly detection and intrusion reporter). На создание этой системы оказала большое влияние работа Деннинга и Люнт.^[13] NADIR использовала основанный на статистике детектор аномалий и экспертную систему.

В 1998 году Национальная лаборатория им. Лоуренса в Беркли представила Bro, использующий собственный язык правил для анализа данных libpcap.^[14] NFR (Network Flight Recorder), разработанный в 1999, также работал на основе libpcap.^[15] В ноябре 1998 был разработан APE, сниффер пакетов, тоже использующий libpcap. Спустя месяц APE был переименован в Snort.^[16]

В 2001 году была разработана система ADAM IDS (Audit data analysis and mining IDS). Система использовала данные tcpdump для создания правил.^[17]

 

⇐ Предыдущая123

Поделиться:

Воспользуйтесь поиском по сайту: