Я использую для этих целей Diskeeper Undelete, поиск удаленного файла занимает около 10-15 секунд, так как программа записывает путь до директории откуда был удален файл, одной кнопкой файл можно вернуть на место, так же можно посмотреть какой юзер его удалил.
Возможно придется настроить размер журнала Security, если событий слишком много и старые события перезатираются.
Если событий реально много — тогда имеет смысл включить архивирование журналов (параметр Archive the log when full, do not overwrite events), уменьшить размер лога, скажем до 10 мегабайт. Потом модифицировать скрипт, чтобы он ходил по архивным логам, парсил их и удалял обработанные.
Слишком больше логи ооочень долго парсит. Лучше запускать скрипт с более-менее нормальным периодом, и смысла не будет хранить виндовые логи в архивах. Слишком уже они неудобные.
На боевых серверах парсить журнал PowerShell-ом — проще застрелиться.
У нас есть самодельный сервис, который подписывается на события eventlog-а и сливает события в MS SQL прямо как есть в xml-виде (кидает в SQLite, если MSSQL временно недоступен). Благо, MSSQL-сервер позволяет индексировать такие данные и делать хорошие выборки с использованием xpath-синтаксиса.
почему считаете что проще застрелится… вполне себе нормально отрабатывает. Все конечно зависит от объема, но в моем случае вполне даже себе справляется. Конечно проиндексированные данные из БД парсить куда удобнее. Поделитесь?)
Неудобства PS:
1. долго работает (конечно, если искать за нужный день. сливать за последние N минут не пробовал)
2. полные данные некоторых событий (например, редактирование объекта AD) нужно собирать по нескольким event-ам, связывая по Correlation GUID. join прямо таки просится
поделиться не могу — в рабочее время написано по тз.
заняло 2 дня: 1) копипаста с MSDN готовых кусков (скелет службы и разные варианты подписки на eventlog есть в законченных примерах), 2) отладка опечаток
Я у нас делал так: С помощью Snare конвертировал Eventlog в Syslog и отправлял его на соседний Linux — сервер, который скриптом на перле обрабатывал каждую строку и делал выводы по этим шаблонам:
Потом это все писалось в Mysql и отчеты делались уже по ней, не нагружая сервер с виндой.
Но, конечно, у вас проверки более детальные, у меня определял иногда действия ошибочно и генерировал очень много лишних логов. Надо переписать согласно вашей статье, спасибо!
У меня так же работает SYSlog сервер который собирает себе в MySQLную базу все логи с Windows-серверов. Заметил только, что неокторые логи приходят обрезаные:( Поле Message, если оно достаточно большое, обрезается, видимо. Проверил прямым запросом к базе, и там они так же обрезаны. Так же заметил, что некоторые логи вообще пустые в поле Message. Возможно проблема конечно с клиентом который кидает все это на сислог-сервер. У меня Evtsys используется.
Кстати вопрос как раз таки… кто нибудь вкурсе как кидать алерты с rsyslog-сервера в Jabber? :)
Я правильно понимаю, что
1. операция 4663 с DELETE-ом означает ЛИБО переименование, ЛИБО удаление?
2. если в течении нескольких секунд до или после такого 4663 с DELETE-ом мы видим 4660 и Handler-ы совпадают, то значит что операция была удаление
3. А как «связать» переименование? Я пропустил. Как понять, как новое имя файла?
После публикации данного поста, я немного изменил скрипты, добавил запись логов не в файл, а в SQL. И переписал все скрипты на .NET C# в виде Windows-службы, которая все время висит в фоне и парсит лог. Работает в разы быстрее — и ест всего 8МБ памяти (судя по диспетчеру задач).
1. все верно.
2. да
3. К сожалению новое имя файла не фиксируется в логах. Возможно стоит поиграться с политиками аудита, но объем логов может вырасти в десятки раз.
При переименовании файла фиксируется доступ к данному файлу и папке (4663), которая его содержит.
В дополнении хотелось бы еще указать на еще один евент под номером 4659.
Он так же фиксирует удаление файлов при определенных случаях. Сейчас уже не помню при каких конкретно, но он может появиться при удалении файла.
Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell