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

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

Пример отчёта по запускаемым программам

Итак приступим. Система состоит из трёх частей, а именно

• Сбор журналов
  • сбор с ПК
  • закачка на ФТП
  • скачка с ФТП, перепаковка
• Ежедневная обработка журналов, оповещения
  • Отчёт по запущенным процессам
  • По неверным входам
• Архивирование журнлов
  • Перепаковка и архивирование для сброса ни диск старых журналов (раз в год\раз в пл года)

1) Сбор системных журналов Windows

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

1.1.1 Сбор через DUMPEVT.exe (http://ptraffer.ru/downloads/events_upload_domain_manual.rar)

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

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

То, что процесс завершон вы сможете поняль по отсутствию процесса wscript.exe (или cscript.exe) - соответствено чтобы форсировать остановку убиваем вышеуказанный процесс.

В шедулер домен-контроллера раз в три часа, начиная с ноля, добавляем events_upload_domain.vbs

указав в строке

WshShell.Run "ncftpput\ncftpput -u ftp_user_name -p ftp_user_pass -m -DD -R ftp.mysite.ru / " & chr(34) & szPath & "\*.7z" & chr(34), 1, True

Необходимые параметры подключения к ФТП-серверу.

Всё, первый вариант готов к сбору - просто, не правда ли )

1.1.2 Сбор из базы ПК в AD + из сетевого окружения (http://ptraffer.ru/downloads/filials_event_zaliv_domain(anon share).rar)

Данный способ через WMI запускает DUMPEVT.EXE на ПК пользователя, это более гуманный способ т.к. можно регулировать приоритет процесса, а также его не видно через всякие NetWatcher-ы, минус состоит в том что необходима специальная шара, в которую сможет писать процесс запусщенный от SYSTEM-а на доменном ПК. Например это самбовская шара на какой-то никсовой система без авторизации, или же на недоменном ПК обычная.

Реализована защита от распространения вирусов, т.е.еслиодин из ПК в сети заражает исполняемые файлы (не Ваш, конечно), то другие не пострадают.

Отличительным свойстом данного метода также является одновременный асинхронный сбор журнаов сразу с нескольких ПК. Это означает что количество процессов на ПК может доходит до 200-300 в сети с 500 ПК. Это нормальное поведение т.к. такое количество последовательно опросить просто нереально по времени - проверено.

Другим свойством является водключение к ПК через пользователя, отличного от текущего. Данныепо этому пользователю и ФТП-аользователю указываются в скрипте - просмотрите его и вопросов возникнуть не должно.

2) Ежедневная обработка журналов, оповещения

Размышлений о опытов по технологии хранения журналов было довольно много - от базы данных, до специализированного дедуплицирующего хранилища вроде базы данных с кучей связанных таблиц. Скажу сразу что всё это работает, но есть некая очевидная зависимость между сложностью структуры (т.е. временем сохранения и чтения данных) и её объёмом. Например в SQL данные сохраняются довольно бодро, но т.к. они являются плайн-текстом объёмом от 2 ГБ в день(!), то хранение данных за 6 месяцев уже, мягко говоря, требует лишних ресурсов. Сложная таблица со связанными подзапросами для удаления дублирующихся слов и описаний событий этот вопрос в какой-то степени решает, но скорость добавления примерно 100 килобайт данных в секунду, в общем был выбран другой вариант - подобран архиватор для текстовых данных (7z с алгоритмом PPMD выдаёт просто астрономические результаты!).

2.1 Собственно сбор ()

...продолжение следует....