«Пиковая» загрузка ЦП на контроллерах домена

TL; DR: файл журнала событий заполнен. Перезапись записей стоит дорого и / или не очень хорошо реализована в Windows Server 2008.

В @pk. и @joeqwerty посоветовавшись, я решил, что, скорее всего, забытая реализация мониторинга очищает журналы событий.

Я установил Сетевой монитор Microsoft на одном из контроллеров домена и начал фильтрацию MSRPC с помощью ProtocolName == MSRPC фильтр. Был большой трафик, но он все происходил между RODC нашего удаленного сайта и, к сожалению, не использовал тот же порт назначения, что и слушающий процесс EventLog. Штопать! Вот эта теория.

Чтобы упростить задачу и упростить запуск программного обеспечения для мониторинга, я решил развернуть службу EventLog из SVCHost. Следующая команда и перезагрузка контроллера домена выделяют один процесс SVCHost службе EventLog. Это немного упрощает расследование, поскольку к этому PID не подключено несколько сервисов.

SC config EventLog Type= own

Затем я прибег к ProcMon и настройте фильтр, чтобы исключить все, что не использовало этот PID. Я не видел тонны неудачных попыток EventLog открыть отсутствующие ключи реестра, как указано в качестве возможной причины. Вот (видимо дрянные приложения могут регистрироваться как Источники событий крайне плохим способом). Как и ожидалось, я видел много успешных записей ReadFile в журнале событий безопасности (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

Вот посмотрите на стек одного из этих событий:

Сначала вы заметите RPCBinding, а затем RPCBindingUnbind. Был много из этих. Тысячи в секунду. Либо журнал безопасности действительно занят, либо что-то не работает с Security.evtx журнал.

В EventViewer журнал безопасности регистрировал только 50–100 событий в минуту, что казалось подходящим для домена такого размера. Штопать! Есть теория номер два, что у нас было какое-то приложение с включенным очень подробным аудитом событий слева в забытом углу, которое все еще покорно пыхтит. Было зарегистрировано очень много (~ 250 000) событий, хотя скорость регистрации событий была низкой. Возможно, размер журнала?

Журналы безопасности - (Щелкните правой кнопкой мыши) - Свойства ... и максимальный размер журнала был установлен равным 131 072 КБ, а размер журнала в настоящее время составляет 131 072 КБ. Установлен переключатель "Перезаписывать события по мере необходимости". Я подумал, что постоянное удаление и запись в файл журнала, вероятно, было тяжелой работой, особенно когда он был настолько заполнен, поэтому я решил очистить журнал (я сохранил старый журнал на случай, если он нам понадобится для аудита позже) и позволил службе EventLog создать новый пустой файл. Результат: загрузка ЦП вернулась к нормальному уровню около 5%.

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

• Откройте системный монитор и создайте новую определяемую пользователем группу сборщиков данных.
• выберите Руководство (без шаблона) и выберите Данные трассировки событий только.
• Добавить Доменная служба Active Directory: Core данные и сохраните набор.
• Изменить Состояние остановки под Свойства до 1 минуты.
• Запускаем набор и ждем.
• По завершении конвертируйте сохраненные .etl файл в .csv с помощью tracerpt –l “file.etl” –of CSV
• Проанализировать summary.csv и dumpfile.csv данные в Excel. Вы можете скачать это Импорт-DC-Info.xlsm документ, чтобы помочь вам с анализом.

Если моя догадка верна, вы увидите, как некоторые устройства (IP: порт) забивают ваш DC.

Конечно, трудный. Помимо того, что вы просто оставите его в покое (1 ЦП / 50% нагрузки ... кого это волнует?), Вы можете попробовать настроить новый контроллер домена и посмотреть через несколько дней, дает ли он такое же поведение. Если это так, вы можете попробовать трассировку Wireshark (очевидно, что что-то из сети вызывает это)

Следующее, что приходит на ум, - это простой звонок в Microsoft.

Трэвис, "архив" тебе не помог. Фактически, даже очистка журнала событий, когда он вырос на 2/3, вам не помогла. Но «архив» действительно помог KraigM.

kce: очистил файл 131 МБ для перезаписи, и производительность упала с, скажем, 55% до 5%, но ВОПРОС: возможно, в конечном итоге вы снова увидите высокую загрузку, поскольку это может (а) срабатывать только при достижении условия перезаписи или (б) это может линейно ухудшаться по мере увеличения размера очищенного файла с 0 МБ до 131 МБ.

Некоторые видят это для security.evtx, а кто-то - для рабочего журнала планировщика заданий. Я предлагаю полностью удалить ваш AV (какой вы используете) и попробовать. Злоумышленникам необходимо скрыть свои следы, и их следы создаются в запланированных задачах, которые они устанавливают, или в логинах, которые они выполняют. Таким образом, они будут скрывать свои следы, ломая дескрипторы этих журналов событий и переписывая их, чтобы пропустить свои следы. Возможно, антивирусные программы обнаруживают это ошибочно, поскольку, если бы это была Microsoft, о таком высоком использовании сообщалось бы больше, но я вижу лишь скудные сообщения при поиске в Google. Я также вижу это на сервере 2008 R2 для журнала security.evtx. Нет подписчиков журнала событий, нет внешних мониторов. Я наблюдал за работой нескольких AV-сервисов (McAfee), и они имели очень низкую общую загрузку сервера в течение многих дней, поэтому я подозреваю, что он был удален, и только частично (вероятно, требуется специальный деинсталлятор McAfee), и мне интересно, есть ли в нем ловушки. остаток (или даже обычно установленный) службы McAfee или запущенные драйверы фильтров McAfee, которые каким-то образом выполняют обычную запись в журнал событий и решают в своей фильтрации, что им необходимо превратить это в полноценное чтение всего журнала событий. Поверьте мне, сторонние драйверы фильтров от некоторых AV-компаний содержат ошибки и, безусловно, в 10000 раз более ошибочны, чем реализация регистрации событий Microsoft, которая, скорее всего, идеальна. Таким образом, 100% удалите ВСЕ ВАШЕ AV И ПОСМОТРИТЕ, ЕСЛИ проблема решена. Если это так, поработайте со своей AV-компанией, чтобы исправить их AV. Не рекомендуется делать исключения для файлов .EVTX, поскольку вы можете проиграть это обнаружение вторжений, которое, поверьте мне, важно для плохих парней.

Кроме того, при использовании procmon обратите внимание на вызовы WriteFile, потому что Writefile - это то, что заставит диспетчер фильтров прочитать весь файл. В моем случае чтение было инициировано примерно через 30 секунд после завершения записи, что могло быть задумано. Но это было согласованно, и в моем случае файл был 4 ГБ, а чтение файла включало 64 КБ файлов чтения каждый по 64 КБ, и для этого использовалось 35% ЦП. Очень грустный.

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

Как я сказал коллеге из Azure ниже, у нас нет ответа на исходный плакат, если проблема снова возникнет после очистки журнала событий, потому что это распространенное и ошибочное решение, поскольку производительность со временем снова ухудшается. Это называется «продолжение», и я на собственном опыте вижу, что исходное решение плаката может обмануть тех, кто не следит за ним, полагая, что они решили проблему. Меня тоже чуть не обманули. Я очистил журнал событий, и производительность улучшилась, но я использовал procmon и увидел, что проблема будет расти и медленно расти со временем, пока не станет проблематичной. По какой-то причине этот парень из Azure резко критикует меня, когда исходный плакат не последовал (возможно, он умер, был уволен, уволился или был занят). Сотрудник из Azure, представленный ниже, думает, что если исходный постер не последовал, проблема должна быть решена. Это досадно и озадачивает, потому что я не могу вспомнить никого, кто так высоко ценится в техническом плане, кто занял бы эту позицию. Прошу прощения, если укололи нервы. Возможно, из-за моей активности в другом месте в Интернете, где я вызываю людей, я действовал ему на нервы - здесь (сбой сервера) я просто проявляю доброту и делюсь глубокими техническими знаниями, а результат мистера Азура запугивает, является ли мой технический вклад даже необходимо или для какого-то моего блога (у меня такого блога нет). Я пока не собираюсь отправлять эту ссылку примерно полдюжине ключевых друзей в Microsoft и спрашивать их, что, черт возьми, происходит с таким типом издевательств со стороны ключевого сотрудника MSFT, потому что я сосредоточен исключительно на том, чтобы Сообщество, о котором идет речь, и ответы г-на Лазур ниже, в двух словах, невероятны, язвительны, пугают и запугивают - что, я уверен, некоторым людям нравится поступать с другими. Сначала я был оскорблен, но я переборщил с этим и знаю, что пассивные или активные читатели оценят то, что я говорю, и оценят мои комментарии - я на 100% поддерживаю это, не обращая внимания на юридические причины, почему это здесь неуместно или нет. М. Лазур, пожалуйста, проявите доброту и воздержитесь от того, чтобы выставлять мои комментарии в плохом свете. Просто преодолейте это и проявите сдержанность и больше не комментируйте.

Гарри