Объединение журнала событий и мониторинга

Published on Январь 30, 2009 by   ·   Комментариев нет

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

Средства, которые предлагаются на сегодняшний день администраторам по сетевой безопасности, не только варьируются приложениями, но и также в их возможности предоставить вам ключевой элемент для вашей повседневной битвы с хакерами. Это возможность – выдавать на выходе понятную информацию (meaningful output). Что может быть хорошего в брандмауэре (firewall), IDS, IPS или в чем-нибудь еще, если на выходе он выдает не только зашифрованную, но и непонятную информацию? Я сталкивался с большим количеством решений и не нашел действительно простого способа для того, чтобы связать их вместе. Вы будете удивлены количеством регистрационной информации, которая заносится на сегодняшний день в вашей организации, если в действительности задумаетесь над этим.

Хакеры и следы их деятельности

Для того чтобы представить вам обоснования для объединения журнала событий и мониторинга, давайте посмотрим, как хакер может скомпрометировать вашу сеть, и будет ли после их действий какой-нибудь остаток. Под остатком я понимаю следы, которые они оставят, если попытаются взломать вашу сеть. Запишется ли что-нибудь в журнал одного из маршрутизаторов ACL (access control list), после того, как они минуют ваш пограничный маршрутизатор (edge router)? Останется ли что-нибудь интересное об атакующем в журнале брандмауэра, который располагается за маршрутизатором? Что может сказать IDS, который подключен к порту span port вашего основного свитча (main switch)? Список будет продолжаться в зависимости от схемы вашей сети и применяемых вами средств безопасности.

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

TCP Port 21 FTP
TCP Port 22 SSH
TCP Port 25 SMTP
TCP/UDP Port 53 DNS
TCP Port 80
UDP Port 161
TCP Port 443 SSL

Посмотрим на это с точки зрения хакера.

Инструмент для объединения журналов событий

Рисунок 1

С таким списком служб, отмеченным в их любимом сканере портов, например nmap, хакер начинает исследовать вашу сеть. В зависимости от настроек защиты вашей сети это сканирование, запущенное хакером, может попасть в журнал. А что если хакер решить сделать то, что называется низким и медленным сканированием? А что это такое, вы спросите? Низкое и медленное сканирование – это когда хакер исследует вашу сеть, посылая всего лишь пару пакетов в день, на протяжении недели или недель. Преимущество такого сканирование заключается в том, что в этом случае вероятность того, что хакер попадет в ваши журналы, гораздо меньше. Но это лишь до тех пор, пока вы не выполнили объединение журнал событий и мониторинг. Но об этом немного позже.

Как насчет других устройств?

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

Далее следуют утилиты, дающие возможность заносить в журнал сетевые событий, связанных с применением контрольных устройств администратора, таких как PDC, BDC или контролер Active Directory. Эти системы заносят в журнал большое количество интересных данных. Это факт, который может подтвердить практически каждый администратор. Эти данные из Редактора событий (Event Viewer), предоставляемые в распоряжение системного администратора, являются очень важными для контроля безопасности.

Инструмент для объединения журналов событий

Рисунок 2

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

Объединение

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

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

Резюме

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

Источник www.windowsecurity.com








Смотрите также:

Tags: , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]