Рекомендации по применению средств просмотра потоков данных следующие [18]:

Средство просмотра можно установить как на специально выделенную рабочую станцию, так и на совмещающую несколько функций в сети, но при этом выбранная рабочая станция должна удовлетворять следующим требованиям:

- сетевой адаптер должен работать в "прозрачном" режиме,

- рабочая станция должна быть достаточно производительна (необходимая производительность определяется средствами ОС путем выявления загруженности системы во время работы средств инспекции);

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

2.2.1 Размещение сенсоров

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

Обычно сетевые сенсоры системы обнаружения атак устанавливаются на следующих участках сети:

- между маршрутизатором и межсетевым экраном;

- в «демилитаризованной зоне» (DMZ);

- за межсетевым экраном;

- у сервера удаленного доступа или у модемной стойки;

- на сетевой магистрали;

- в ключевых сегментах внутренней сети.

Между маршрутизатором и межсетевым экраном.

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



Рисунок 2.4 - Размещение сетевого сенсора между маршрутизатором и межсетевым экраном

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

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

В демилитаризованной зоне.

Следующая задача, возлагаемая на сетевые сенсоры, - защита устройств, находящихся в демилитаризованной зоне, реализация показана на рисунке 2.5. К таким устройствам можно отнести Web, FTP- и SMTP-серверы, внешний DNS-сервер, а также другие узлы, которые должны быть доступны внешним пользователям. При этом трафик, не проходящий через контролируемую зону, не анализируется сетевым сенсором системы обнаружения атак. Размещение сенсора в демилитаризованной зоне обычно практикуется компаниями, активно использующими внешне доступные ресурсы (электронные магазины, internet-порталы и т. п.)

За межсетевым экраном

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



Рисунок 2.5 - Размещение сетевого сенсора в демилитаризованной зоне

В ключевых сегментах внутренней сети

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

У сервера удаленного доступа

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



Рисунок 2.6 Размещение сетевого сенсора у сервера удалённого доступа

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

- это средство, как правило, нельзя обнаружить с других рабочих станций;

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

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

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

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

- регистрация событий, происходящих в сети;

- фиксирование всех физических устройств, подключенных к сети;

- захват запросов на установление и разрыв соединения, перехват всей информации, передаваемой во время определенного сеанса связи;

- количественные характеристики системы (число обнаруживаемых нарушений, частота обновления базы сигнатур, число контролируемых сенсоров системы обнаружения атак и т.д.);

- наличие механизма описания собственных сигнатур;

- наличие централизованного управления всеми сенсорами, установленными в разных местах корпоративной сети;

- сигнализация при регистрации отслеживаемого события; архивирование регистрируемой информации;

- просмотр и анализ информации из архива;

- собственная защита.

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

2.2.2 Основные проблемы существующих технологий обнаружения атак

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

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

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

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

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

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

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

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

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

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

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

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

Возможные решения этой проблемы - применение разветвителей (tap), концентраторов и span-портов [19].

Span-порт конфигурирует коммутатор таким образом, чтобы последний вел себя подобно концентратору для выделенных портов. На некоторых современных коммутаторах нельзя со 100% уверенностью гарантировать, что span-порт позволит обнаружить все атаки. Желательно, чтобы в один момент рабочий времени span-порт отслеживал только один порт, т.к. одновременный контроль нескольких машин может быть очень труден или невозможен.

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

Разветвитель - однонаправленное устройства и перенаправляет к IDS только трафик между коммутатором и машиной с ресурсом. Это предотвращает прохождение трафика с IDS на коммутатор или машину с ресурсом, а также трафик не может быть направлен к IDS. Т.к. разветвитель однонаправлен, то можно направлять трафик из отдельных разветвителей на концентратор, который контролируется IDS без возможных негативных последствий.

И еще одна проблема, связанная с коммутаторами.

Коммутаторы обладают большей пропускной способностью в сравнении с хабами и защищают от использования программ sniffer, но создают проблемы с использованием NIDS. Конечно, существуют коммутаторы с зеркалированием портов (SPAN-порты), которые копируют данные, проходящие через коммутатор на выделенный порт. Теоретически использование данных портов позволяет проверять весь поток данных, однако тут возникает проблема скорости передачи информации. Если зеркалируемый трафик превышает объем разрешенного к прохождению через выделенный порт, вполне вероятна потеря некоторых пакетов.

И еще одна проблема - применение средств шифрования. Сейчас уже ни один уважающий себя администратор не работает удаленно со своими системами без SSH или SSL, где передача данных осуществляется в шифрованном виде, а значит, проблема использования NIDS остается.

2.3 Выводы

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

ГЛАВА III. АРХИТЕКТУРА СИСТЕМЫ ОБНАРУЖЕНИЯ АТАК

3.1 Клиент - серверная технология

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

Разработанная подсистема обнаружения атак имеет архитектуру «клиент-сервер». В ней выделяется два основных модуля:

- устройство управления и отображения информации (консоль);

- устройство перехвата сетевого трафика (сенсор);

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

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

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

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

сенсор консоль

Рисунок 3.1 - Архитектура системы обнаружения атак

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

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

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

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

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

Далее опишу, как проходит процесс соединения клиента с сервером и последующие идентификация и аутентификация, передача файлов, проверка целостности и достоверности передаваемой информации.

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

Действия, которые производится при инициализации соединения между клиентом и сервером:

- Сервер, по алгоритму RSA генерирует пару ключей (открытый и закрытый) и передает клиенту открытый ключ.

- Клиент, получив открытый ключ, генерирует сеансовый ключ, шифрует его на полученном открытом ключе и передает эту информацию серверу.

- Сервер принимает зашифрованный блок и расшифровывает его своим закрытым ключом.

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

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

3.2 Модуль шифрования

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

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

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

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

После процедур идентификации и аутентификации клиент получает право на приём-передачу информации.

Передача данных от сервера клиенту и в обратном направлении осуществляется посредством синхронной передачи специально сформированных пакетов защищённой передачи. Структура такого пакета представлена на рисунке 3.2

Рисунок 3.2 - Структура пакета защищённой передачи данных

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

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

3.3 Модуль накопления и хранения предупреждений

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

Реализована данная функция следующим образом:

- информация об обнаруженной атаке записывается в модуль хранения и накопления предупреждений;

- клиент посылает запрос на установление связи с сервером;

- в случае установления соединения информация из модуля хранения и накопления предупреждений передается серверу, после подтверждения успешной передачи, проверки целостности и достоверности переданной информации содержимое модуля удаляется;

- если связь не установлена информация хранится в данном модуле до установления связи с сервером и все новые сообщения серверу записываются в базу данных модуля;

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

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

3.4 Алгоритм работы подсистемы

Подсистема в целом работает следующим образом:

- клиент посылает запрос на установление соединения с сервером;

- сервер, получив запрос, устанавливает соединение;

- происходит идентификация и аутентификация;

- затем происходит генерация и обмен ключами;

- файл, который необходимо послать серверу записывается в модуль накопления и хранения предупреждений;

- файл разбивается на блоки, шифруется и передается по блокам серверу в шифрованном виде;

- сервер, получив блоки, расшифровывает их и собирает обратно в единый файл, проверяя его на целостность и искаженность данных;

- если файл принят корректно, то сервер посылает подтверждение приема файла, в противном случае файл передается заново;

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

Описанный алгоритм показывает работу всей подсистемы. На рисунке 3.3 реализована структурная схема работы подсистемы для более наглядного представления о ее работе.

Рисунок 3.3 - Структурная схема подсистемы.

3.5 Выводы

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

ГЛАВА IV. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

4.1 Общая блок-схема подсистемы

Данная подсистема реализована на языке программирования Borland C++ Builder 6.0 по описанному выше алгоритму.

После того, как клиенты (клиент) подключились к серверу, происходит их идентификация по IP-адресам. Если процедура идентификации прошла успешно, то следующим этапом будет аутентификация клиентов по паролю. Если клиент был аутентифицирован, то он продолжает работу, а если нет, то он будет отключён. Далее следует основной цикл работы - это передача данных в направлениях: «сервер-клиент», «клиент-сервер». Защищённая передача данных происходит с использованием двух алгоритмов шифрования - асимметричного (RSA) и симметричного (RC4), контроль целостности данных осуществляется с помощью алгоритма хеширования ГОСТ Р 34.11-94. Сами данные вместе с подписью, полученной из хеша шифрованием по алгоритму RSA на закрытом ключе сервера, шифруются по симметричному алгоритму. Данные передаются вместе с сеансовым ключом, зашифрованном на открытом ключе получателя. Так же во время работы могут передаваться вновь сгенерированные асимметричные ключи. После окончания основного цикла работы клиент отсоединяется от сервера и завершает свою работу. После окончания основного цикла работы сервер также завершает свою работу, до следующего сеанса связи.

Блок-схема работы подсистемы представлена на рисунке 4.1:



Рисунок 4.1 - Общая блок - схема транспортной подсистемы обнаружения атак с распределенной архитектурой принятия решений.

4.2 Реализация клиент-серверной технологии

Для создания сетевого приложения удобно было использовать готовые решения для программистов, такие как сокеты Borland (в системах Delphi и C++ Builder). Итак, работа по созданию клиент-серверного приложения была проведена с помощью стандартных компонент сокетов(таблицы 4.1, 4.2).

Таблица 4.1 - Компонент TClientSocket

Свойства	Методы	События
Active - показывает, открыт сокет или нет. Тип: Boolean. Соответственно, True - открыт, а False - закрыт. Это свойство доступно для записи; Host - строка (Тип: string), указывающая на хост-имя компьютера, к которому следует подключиться; Address - строка (Тип: string), указывающая на IP-адрес компьютера, к которому следует подключиться. В отличие от Host, здесь может содержаться лишь IP. Отличие в том, что если Вы укажете в Host символьное имя компьютера, то IP адрес, соответствующий этому имени будет запрошен у DNS; Port - номер порта (Тип: Integer (Word)), к которому следует подключиться. Допустимые значения - от 1 до 65535; Service - строка (Тип: string), определяющая службу (ftp, http, pop, и т.д.), к порту которой произойдет подключение. Это своеобразный справочник соответствия номеров портов различным стандартным протоколам;	Open - открытие сокета (аналогично присвоению значения True свойству Active); Close - закрытие сокета (аналогично присвоению значения False свойству Active);	OnConnect - как следует из названия, это событие возникает при установлении соединения. Т.е. в обработчике этого события уже можно начинать авторизацию или прием/передачу данных; OnConnecting - возникает при установлении соединения. Отличие от OnConnect в том, что соединение еще не установлено. Обычно такие промежуточные события используются для обновления статуса; OnDisconnect - возникает при закрытии сокета. Причем, закрытия как из текущей программы, так и со строноны удаленного компьютера (либо из-за сбоя); OnError - Возникает при ошибке в работе сокета. Следует отметить, что это событие не поможет отловить ошибку в момент открытия сокета (Open). Для того, чтобы избежать выдачи сообщения об ошибке, надо заключить операторы открытия сокета в блок try..except (обработка исключительных ситуаций);
ClientType - тип соединения. ctNonBlocking - асинхронная передача данных, т.е. посылать и принимать данные по сокету можно с помощью OnRead и OnWrite. ctBlocking - синхронная (одновременная) передача данных. События OnRead и OnWrite не работают. Этот тип соединения полезен для организации обмена данными с помощью потоков (т.е. работа с сокетом как с файлом);		OnLookup - возникает при попытке получения от DNS IP-адреса указанного хоста; OnRead - возникает, когда удаленный компьютер послал текущей программе какие-либо данные. При возникновении этого события возможна обработка данных; OnWrite - возникает, когда разрешена запись данных в сокет.

Таблица 4.2 - Компонент TServerSocket

Свойства	Методы	События
Socket - класс TServerWinSocket, через который мы имеем доступ к открытым сокетным каналам. Тип: TServerWinSocket; ServerType - тип сервера. Может принимать одно из двух значений: stNonBlocking - синхронная работа с клиентскими сокетами. При таком типе сервера Вы можете работать с клиентами через события OnClientRead и OnClientWrite. stThreadBlocking - асинхронный тип. Для каждого клиентского сокетного канала создается отдельный процесс (Thread). Тип: TServerType; ThreadCacheSize - количество клиентских процессов (Thread), которые будут кэшироваться сервером. Здесь необходимо подбирать среднее значение в зависимости от	Open - Запускает сервер. По сути, эта команда идентична присвоению значения True свойству Active; Close - Останавливает сервер. По сути, эта команда идентична присвоению значения False свойству Active.	OnClientConnect - возникает, когда клиент установил сокетное соединение и ждет ответа сервера (OnAccept); OnClientDisconnect - возникает, когда клиент отсоединился от сокетного канала; OnClientError - возникает, когда текущая операция завершилась неудачно, т.е. произошла ошибка; OnClientRead - возникает, когда клиент передал серверу какие-либо данные. Доступ к этим данным можно получить через передаваемый параметр Socket: TCustomWinSocket; OnClientWrite - возникает, когда сервер может отправлять данные клиенту по сокету;
загруженности Вашего сервера. Кэширование происходит для того, чтобы не создавать каждый раз отдельный процесс и не убивать закрытый сокет, а оставить их для дальнейшего использования. Тип: Integer; Active - показатель того, активен в данных момент сервер, или нет. Т.е., фактически, значение True указывает на то, что сервер работает и готов к приему клиентов, а False - сервер выключен. Чтобы запустить сервер, нужно просто присвоить этому свойству значение True. Тип: Boolean; Port - номер порта для установления соединений с клиентами. Порт у сервера и у клиентов должны быть одинаковыми. Рекомендуются значения от 1025 до 65535, т.к. от 1 до 1024 - могут быть заняты системой. Тип: Integer; Service - строка, определяющая службу (ftp, http, pop, и т.д.), порт которой будет использован. Это своеобразный справочник соответствия номеров портов различным стандартным протоколам. Тип: string;		OnGetSocket - в обработчике этого события мы можем отредактировать параметр ClientSocket; OnGetThread - в обработчике этого события мы можем определить уникальный процесс (Thread) для каждого отдельного клиентского канала, присвоив параметру SocketThread нужную подзадачу TServerClientThread; OnThreadStart, OnThreadEnd - возникает, когда подзадача (процесс, Thread) запускается или останавливается, соответственно; OnAccept - возникает, когда сервер принимает клиента или отказывает ему в соединении; OnListen - возникает, когда сервер переходит в режим ожидания подсоединения клиентов.

Итак, пользуясь методами и свойствами стандартных компонент среды разработки Borland C++Builder 6.0 было разработано клиент-серверное приложение.

4.2.1 Серверная часть программы

Прежде всего, стоит сказать о тех файлах, которые использует сама программа:

- файл 1.lst - список идентификаторов, паролей, имён операторов и названий ключевых связок, городов, где находятся филиалы;

- файл events.txt - по умолчанию журнал событий происходящих на серверной части программы;

- файлы с расширением *.tmp - файлы для работы со считываемыми данными и промежуточной обработки информации;

- файл server.keys - файл, содержащий до 10 ключевых связок сервера: имена ключевых связок, открытые ключи, модули ключей, секретные ключи;

- файл client.keys - файл, содержащий по 3 ключевых связки клиента: ip-адреса клиентов, имена ключевых связок, открытые ключи и модули ключей;

- файл client.id - файл, содержащий регистрационные номера аппаратных идентификаторов клиентов: ip-адреса клиентов и сами регистрационные номера.

Глобальные переменные, используемые в программе:

int c,j

Переменная с - число активных соединений.

Переменная j- количество строк в таблице зарегистрированных ползователей.

int TN - номер идентифицированного клиента в таблице все пользователей.

int numsk - число ключей сервера.

int numck - число ключей клиента.

int numcli - число клиентов.

AnsiString s1 - В переменную s1 записывается имя передаваемого по сети файла.

String FileN, GetIP

FileN - переменная, в которую помещается имя файла выделенное из строки с указанием пути.

GetIP - переменная, в которую сохраняется IP-адрес клиента, подлежащего аутентификации.

char *curdir - записывается путь к текущей директории.

struct srv{

String ip; //ip-адрес клиента

String nick; //имя клиента

int snd; //число отправленных файлов

int recieve; //число полученных файлов

} - Структура специально для ведения статистики передачи и приёма файлов.

struct sndrecieve{//структура для ведения статистики приёма и передачи

srv sendrec[30]; //массив ведения статистики для каждого клиента

int allsnd; // всего отправленных файлов

int allrec; //всего полученных файлов

}globalsend - переменная для ведения статистики приёма и передачи файлов.

struct pswd{ //структура для хранения паролей

String ip; //ip-адрес клиента

String Pass; //пароль

byte random[16]; //случайная последовательность

}Pass[30] - массив для хранения паролей и случайных последовательностей клиентов.

String nickserv - переменная для хранения имени администратора сервера.

struct lister{ //структура для записи листингов каталогов

String ip;

String nick;

String filelist[200]; //массив для хранения листинга

int files;// число файлов в папке

int looks;// число просмотров папки

String time;//время последнего просмотра каталога

String rfile;//запрашиваемый файл

}list_list[30] - массив для записи листингов каталогов клиентов.

struct mess{ //структура для записи сообщений

String ip;

String nick;

AnsiString data[50000];//в этот массив сохраняются сообщения

int mesnum;//число сообщений

}mes[30] - массив для хранения сообщений от клиентов.

struct idn{ //структура для хранения регистрационных номеров

String ip;

String id;

}id[30] - массив для хранения регистрационных номеров аппаратных идентификаторов пользователей.

struct clientk{ //структура для хранения ключей клиентов

String ip;

String name;

TMemoryStream *ok; //поток с открытым ключом

TMemoryStream *mod;//поток с модулем ключа

}ckey[90] - массив для хранения ключей клиентов.

struct serverk{ //структура для хранения ключей сервера

String ip;

String name;

TMemoryStream *ok;

TMemoryStream *mod;

TMemoryStream *pk; //поток с секретным ключом

}skey[10] - структура для хранения ключей сервера.

String ipadr[29] - массив активных IP-адресов.

String old_ipadr[29] - массив IP-адресов для проверки на отсоединение.

byte *tmp2,*tmps - буферы для передачи данных из файла в сеть.

TFileStream *fs - файловый поток для записи зашифрованных, расшифрованных файлов.

struct send{

String ip; //ip-адрес клиента

TMemoryStream *data; //данные для клиента

char index; //индекс пакета

}xsend - переменная для передачи информации клиенту.

struct rf{ //структура для приёма файлов от клиентов

String ip;

TMemoryStream *mem;

}rfil[30] //массив для приёма файлов от клиентов.

Функции и процедуры серверной части программы:

void LoadInfo();

String NameOfFile(AnsiString FileName);

void ActivatedUsers();

void thread();

void thread2();

void Processing(TMemoryStream *m);

void Obrabotka(String ip,char index, TMemoryStream* tmp);

void Sending(String ipadres,TMemoryStream* datas, char indexs);

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

Функция NameOfFile(AnsiString FileName) выделяет из строки пути название файла. Функции передаётся переменная типа String с содержащейся в ней путём к файлу. Возвращает функция строку с названием файла.

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

Процедура thread() вызывается для сохранения списка зарегистрированных пользователей после его ввода в таблицу. Также отдельно вызываются диалоговые окна для ввода паролей клиентов. Список зарегистрированных пользователей сохраняется в файле 1.lst.

Процедура thread2() предназначена для отправки случайной последовательности клиенту для аутентификации на сервере. Сначала эта случайная последовательность генерируется, а затем формируется пакет для её передачи клиенту (последовательность подписывается, шифруется), и эта же процедура передаёт сформированный пакет.

Процедура Processing(TMemoryStream *m) извлекает полезный груз из пакета и однозначно идентифицирует вид пакета: сообщение, файл, запрос на передачу каталога и т. д. Эта процедура расшифровывает полученные данные и далее передаёт полезный груз для дальнейшей обработке. Переменная m - содержит полученный от клиента пакет.

Процедура Obrabotka(String ip,char index, TMemoryStream* tmp) предназначена для обработки полученного полезного груза и получения нужного результата: извлечения файла, вывод сообщения на экран, вывод листинга каталога, аутентификация пользователя. Переменная ip - ip-адрес клиента, переменная index - индекс пакета, переменная tmp - полезный груз.

Процедура Sending(String ipadres,TMemoryStream* datas, char indexs) отправляет пакет клиенту. Сначала она формирует пакет для передачи из полезного груза, а затем отправляет сформированный пакет клиенту. Переменная ipadres - ip-адрес получателя, переменная datas - полезный груз, переменная indexs - индекс пакета передачи (приложение А).

Остальные процедуры являются работой с графическим интерфейсом программы и обработкой стандартных событий (в том числе событий сокетов), помогающие вызывать вышеуказанные процедуры, и представляющие собой процедуры обработки введённой информации и вызова стандартных методов среды Borland C++Builder 6.0, не представляющих интереса с точки зрения разработки [20].

4.2.2 Клиентская часть программы

Стоит сказать о тех файлах, которые использует сама программа:

- файл events.txt - по умолчанию журнал событий происходящих на серверной части программы;

- файлы с расширением *.tmp - файлы для работы со считываемыми данными и промежуточной обработки информации;

- файл server.keys - файл, содержащий до 10 ключевых связок сервера: имена ключевых связок, открытые ключи и модули ключей;

- файл client.keys - зашифрованный файл, содержащий до 3 ключевых связок клиента: имена ключевых связок, открытые ключи, модули ключей, секретные ключи.

Глобальные переменные, используемые в программе:

long TimerHandle - хендл работы с аппаратным идентификатором iButton.

char *curdir - записывается путь к текущей директории.

int siz - переменная для записи размера буфера принимаемых от сервера данных.

String keyfile - строка для записи расшифрованного файла с ключами клиента.

byte *sr - указатель на переменную для записи случайной последовательности полученной от сервера.

int numsk - число ключей сервера.

int numck - число ключей клиента.

AnsiString s1, FileN

В переменную s1 записывается имя передаваемого по сети файла.

FileN - переменная, в которую помещается имя файла выделенное из строки с указанием пути.

struct pas{ //структура для хранения пароля

char password[16]; //пароль

int size; //рамер пароля

}pas1 - переменная для хранения пароля клиента.

struct snd{ //структура для ведения статистики приёма и передачи файлов

int allsnd; //всего отправлено файлов

int allrec; //всего принято файлов

}globalsend - переменная для ведения статистики для приёма и передачи файлов.

struct mess{ //структура для записи сообщений

String nick;

AnsiString data[50000];//в этот массив сохраняются сообщения

int mesnum;//число сообщений

}mes - массив для хранения сообщений от сервера.

struct clientk{ //структура для хранения ключей клиентов

String ip;

String name;

TMemoryStream *ok; //поток с открытым ключом

TMemoryStream *mod;//поток с модулем ключа

TMemoryStream *pk; //поток с секретным ключом

}ckey[3] - массив для хранения ключей клиентов.

struct serverk{ //структура для хранения ключей сервера

String ip;

String name;

TMemoryStream *ok;

TMemoryStream *mod;

}skey[10] - структура для хранения ключей сервера.

struct send{

String ip; //ip-адрес клиента

TMemoryStream *data; //данные для клиента

char index; //индекс пакета

}xsend - переменная для передачи информации клиенту.

Функции и процедуры серверной части программы:

void Obrabotka(String ip, char index,TMemoryStream *tmp);

void Sending(String ipadres,TMemoryStream* datas, char indexs);

void Processing(TMemoryStream *m);

String NameOfFile(AnsiString FileName);

Эти функции и процедуры идентичны рассмотренным выше (приложение Б).

Остальные процедуры являются работой с графическим интерфейсом программы и обработкой стандартных событий (в том числе событий сокетов), помогающие вызывать вышеуказанные процедуры, и представляющие собой процедуры обработки введённой информации и вызова стандартных методов среды Borland C++Builder 6.0, не представляющих интереса с точки зрения разработки [20].

Далее на рисунках 4.2 и 4.3 представлены блок - схемы по которым была реализована серверная и клиентская часть подсистемы.



Рисунок 4.2 - блок - схема серверной части подсистемы



Рисунок 4.3 - блок - схема клиентской части подсистемы

4.3 Реализация модуля шифрования

Существенное повышение производительности микропроцессоров в 1980-е годы вызвало в криптографии усиление интереса к программным методам реализации шифро-алгоритмов как возможной альтернативе аппаратным схемам на регистрах сдвига.

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

Алгоритм RC4 - это поточный шифр с переменной длиной ключа, разработанный в 1987 году Рональдом Райвистом для компании RSA Data Security. Как и его компаньон блочный шифр RC2, RC4 - шифр с переменной длиной ключа, пригодный для быстрого магистрального шифрования. Он очень компактен в терминах размера кода, и особо удобен для процессоров с побайтно-ориентированной обработкой. RC4 может шифровать со скоростью около 1 Мбайт/сек на 33 Мгц машине. Также схема безболезненно позволяет редуцировать длину ключа.

В настоящее время алгоритм RC4 реализован в десятках коммерческих криптопродуктов, включая Lotus Notes, Apple Computer's AOCE, Oracle Secure SQL, а также является частью спецификации стандарта сотовой связи CDPD.

Далее приведу алгоритм работы данного криптоалгоритма.

Криптогенератор функционирует независимо от открытого текста. Генератор имеет подстановочную таблицу (S-бокс 8 х 8): S0, S1, . . ., S255. Входами генератора являются замененные по подстановке числа от 0 до 255, и эта подстановка является функцией от ключа изменяемой длины. Генератор имеет два счетчика i и j, инициализируемых нулевым значением.

Для генерации случайного байта гаммы выполняются следующие операции:

i = (i+1) mod 256

j = (j+Si) mod 256

swap Si and Sj

t = (Si+Sj) mod 256

K = St

Байт K складывается операцией XOR с открытым текстом для выработки шифртекста. Шифрование происходит весьма быстро - примерно в 10 раз быстрее DES-алгоритма.

Инициализация S-бокса столь же проста. На первом шаге он заполняется линейно:

S0 = 0, S1 = 1, . . ., S255 = 255. Затем еще один 256-байтный массив полностью заполняется ключом, для чего ключ повторяется соответствующее число раз в зависимости от длины:

K0, K1, . . ., K255. Индекс j выставляется в нуль. Затем:

for i=0 to 255

j = (j+Si+Ki) mod 256

swap Si and Sj

Схема показывает, что RC4 может принимать примерно 21700 (256! x 2562) возможных состояний. S-бокс медленно изменяется в процессе работы: параметр i обеспечивает изменение каждого элемента, а j отвечает за то, чтобы эти элементы изменялись случайным образом.

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

Цитата из заключения закрытой работы криптографа RSA Labs Мэтта Робшоу : «Не имеется известных слабых ключей и, хотя нет доказательства для нижней границы периодов последовательностей RC4, проведенный теоретический анализ показывает, что период в подавляющем большинстве случаев превышает 10100. Тщательный и всеобъемлющий анализ стойкости RC4 не выявил никаких оснований подвергать сомнению стойкость, обеспечиваемую генератором RC4».

Функции модуля шифрования подсистемы:

Void TEventa::Base_step - реализация базового шага криптопреобразования (сложение содержимого бокса и ключа)

void TEventa::Crypt(unsigned long int *N) - процесс шифрования всего сообщения при помощи Base_step

void TEventa::Decrypt - процесс дешифрования сообщения по сокетам и обьединения в единый файл

4.4 Реализация модуля накопления и хранения предупреждений

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

Процедуры и функции, реализующие этот модуль:

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

SavingFile - данная функция записывает файл к себе в базу.

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

ГЛАВА V. РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ

Данная подсистема была протестирована на скорость передачи файлов по каналам связи. Передавался файл размером 5 Мбайт заполненный символами “а”. Файл передавался сначала в открытом виде, а затем в шифрованном. Тестирование проводилось на 3 различных компьютерах подключенных в ЛВС с максимальной скоростью передачи данных в канале связи 100 Мбит/c, с разной конфигурацией оборудования, работающих под управлением операционной системы WindowsXP. Результаты тестирования приведены в таблице 5.1

Таблица 5.1 - Результаты тестрования подсистемы

Конфигурация оборудования	Тип файла	Время передачи
Intel Pentium G630 2.70GHz / DDR3 4096 Mb Intel Celeron 2.4 GHz / DDR2 2048 Mb AMD Athlon II X2 260 3.2 GHz / DDR2 2048 Mb	Нешифрованный Шифрованный Нешифрованный Шифрованный Нешифрованный Шифрованный	1,18 секунды 1,38 секунды 1,84 секунды 2,18 секунды 1,54 секунды 1,85 секунды

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

ЗАКЛЮЧЕНИЕ

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

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