Ошибка отправки регистрационных сообщений в журнал событий error 50 windows

Обновлено: 21.11.2024

Самая распространенная причина, по которой люди просматривают журналы Windows, – это поиск и устранение неполадок в своих системах или приложениях.

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

События журнала безопасности

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

Следующие события имеют особое значение в журнале безопасности:

Вы успешно вошли в систему

Эти события включают все успешные попытки входа в систему. Каждое событие включает категории информации:

  • Подробности журнала: имя журнала, источник, серьезность, идентификатор события и другая информация журнала.
  • Тема – имя учетной записи, домен и информация о безопасности для входа в систему.
  • Информация для входа в систему — тип — это метод, используемый для входа в систему, например с помощью локальной или удаленной клавиатуры (по сети). Значение этого поля выражается целым числом, чаще всего это 2 (локальная клавиатура) и 3 (сетевая). Также доступны дополнительные сведения о входе в систему.
  • Уровень олицетворения — какие полномочия предоставляются серверу, когда он олицетворяет клиента.
  • Новый вход — имя, домен и другие данные для нового входа в систему для учетной записи, в которую выполнен вход.
  • Информация о процессе — имя и идентификатор исходного процесса.
  • Информация о сети — имя, IP-адрес и порт, на который поступил запрос на удаленный вход. возник. Эти значения остаются пустыми для локальных входов или если информация не может быть найдена.
  • Подробная информация об аутентификации — подробная информация об этом конкретном запросе на вход.

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

Не удалось войти в систему

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

  • Подробности журнала — имя, источник и другая информация журнала.
  • Тема – имя учетной записи, домен и информация о безопасности при входе в систему.
  • Тип входа — метод, используемый для входа, например, с помощью локальной или удаленной клавиатуры (по сети). Значение этого поля выражается целым числом, чаще всего это 2 (локальная клавиатура) и 3 (сетевая).
  • Учетная запись, для которой произошел сбой входа — имя, домен и другие сведения о неудачном входе.
  • Информация о сбое — причина сбоя и статус попытки.
  • Информация о процессе — имя и идентификатор исходного процесса.
  • Информация о сети — имя, IP-адрес и порт, откуда поступил запрос на удаленный вход. Эти значения остаются пустыми для локальных входов или если информация не может быть найдена.
  • Подробная информация об аутентификации — подробная информация об этом конкретном запросе на вход.

Чтобы узнать больше, вы можете прочитать описание всех полей этого события.

Вот пример неудачной попытки входа в систему, сгенерированной системой, к которой осуществляется доступ, когда попытка не удалась:

Приложению не удалось войти в систему

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

Назначение особых привилегий

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

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

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

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

Чтобы узнать больше, вы можете прочитать описание всех полей этого события журнала.

Вот еще один пример события с повышенными правами.

Почему произошел сбой моего сервера или приложения?

Если вы пытаетесь выяснить, почему произошел сбой вашего сервера или приложения, журнал событий – отличное место для начала поиска. Журналы приложений и системы могут сообщить вам, когда и почему произошел сбой. Например, это может дать вам подсказку, если это произошло из-за проблемы с системой или приложением.

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

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

  • Неожиданная перезагрузка
  • Приложение зависает
  • Ошибка приложения

Неожиданная перезагрузка

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

Вот выдержка из неожиданной перезагрузки:

Зависание приложения

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

В этом примере показано, как приложение перестало отвечать Windows, и Windows закрыла его.

Ошибка приложения

Ошибка сбоя приложения появляется в журнале событий, когда программа, работающая на вашем сервере, обнаруживает критическую ошибку. Эта ошибка обычно связана с ошибкой в ​​коде приложения или с нехваткой памяти. Вот пример неисправной DLL для svchost.exe.

Поиск основной причины отказа службы

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

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

  • Не удалось запустить службу
  • Время ожидания службы
  • Ошибка Центра обновления Windows
  • Запланированная задача отложена или не выполнена

Не удалось запустить службу

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

Тайм-аут службы

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

Сбой Центра обновления Windows

Одна из задач системного администратора — следить за тем, не получают ли компьютеры в сети обновления Windows.

Служба обновления Windows Server (WSUS) — это инструмент управления исправлениями, который автоматически загружает и применяет исправления и обновления безопасности для продуктов Microsoft с веб-сайта Microsoft. В большинстве производственных установок администраторы хотят иметь какой-то контроль над тем, какие исправления применяются и когда они применяются. Это сделано для того, чтобы избежать неожиданного поведения, такого как автоматическая перезагрузка или сбой приложений после цикла исправления. Во многих организациях для загрузки всех исправлений используется централизованный сервер WSUS, а затем администраторы планируют их распространение. Важно следить за статусом запуска Центра обновления Windows.

В этом примере обновление Microsoft не удалось установить, и был сгенерирован код ошибки (0x80240017). Мы можем найти дополнительную информацию.

Запланированная задача отложена или не выполнена

Еще одна служба, которую люди часто используют, — это Планировщик заданий Windows. Это похоже на демон cron в Linux. Вы можете регулярно планировать и запускать программы, сценарии или команды. Задачи можно планировать на определенное время или запускать в ответ на триггер. Например, задача может запускать сценарий резервного копирования PowerShell каждую ночь или копировать файлы на FTP-сервер раз в неделю.

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

С какими еще вариантами устранения неполадок вы сталкиваетесь? Добавьте свои комментарии и дайте нам знать!

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

Рабочие решения Пошаговое устранение неполадок< /th>
Исправить 1. Восстановить поврежденные сектора Выполнить команду chkdsk c: /r /f /v на вашем ПК > Восстановить читаемую информацию из поврежденного сектора. Полные шаги
Исправить 2. Снять защиту от записи Выполнить том списка > выбрать том X > атрибуты команды disk clear readonly для снятия защиты от записи. Полные шаги
Исправить 3. Проверьте диск в безопасном режиме Перезагрузите компьютер и введите Расширенный запуск> Войти в безопасный режим> Запустите команду CHKDSK для проверки диска. Полные шаги
Исправление 4. Отправить диск на ремонт Если предыдущие 3 исправления не помогли решить эту проблему, возможно, он физически поврежден. Отправьте в ремонт. Полные шаги
Исправить 5. Восстановить данные на диске После исправления этой ошибки запустите Мастер восстановления данных EaseUS > Сканировать диск и восстановить потерянные данные. Полные шаги

О сбое переноса зарегистрированных сообщений в журнал событий со статусом 50

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

Симптомы

При попытке запустить программу CHKDSK на компьютере может возникнуть распространенная ошибка «Не удалось передать зарегистрированные сообщения в журнал событий со статусом 50» в процессе восстановления жесткого диска. Это может произойти в Windows 10/8.1/8/7/2008/XP/Vista или других версиях.

Причины

Сообщение об ошибке «Не удалось передать зарегистрированные сообщения в журнал событий со статусом 50» обычно появляется по трем причинам:

  • В разделе Windows есть повреждения или поврежденные сектора (как логические, так и физические поврежденные сектора).
  • Диск или раздел доступны только для чтения
  • Ваш диск физически поврежден

Часть 1. Восстановление данных перед исправлением ошибки «Передача зарегистрированных сообщений, статус 50»

Если команда "chkdsk c: /r /f /v" не смогла устранить повреждение на жестком диске, но появилось предупреждающее сообщение с "передать зарегистрированные сообщения. Статус 50", вы не сможете получить доступ ни открыть устройство.

Чтобы избежать ненужной потери данных и защитить важные файлы, вам может потребоваться сначала найти решение для восстановления ваших файлов в случае непредвиденной потери данных. Здесь может помочь надежное программное обеспечение для восстановления данных на диске - EaseUS Data Recovery Wizard.

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

Шаг 1. Запустите мастер восстановления данных EaseUS на компьютере с Windows 11, Windows 10, Windows 8 или Windows 7. Выберите раздел диска или место хранения, где вы потеряли данные, и нажмите "Сканировать".

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

Шаг 3. Просмотрите и восстановите потерянные файлы Windows. Вы можете дважды щелкнуть, чтобы просмотреть отсканированные файлы.Затем выберите целевые данные и нажмите кнопку «Восстановить», чтобы сохранить их в другом безопасном месте на ПК или на внешнем запоминающем устройстве.

Имейте в виду, что если ваш внутренний жесткий диск сильно поврежден и не может загрузить Windows, загрузите EaseUS Data Recovery Wizard Pro с загрузочным носителем, чтобы восстановить данные.

Часть 2. Как исправить ошибку CHKDSK при передаче зарегистрированных сообщений со статусом 50

Исходя из перечисленных возможных причин, существуют соответствующие решения для решения проблемы «не удалось передать зарегистрированные сообщения в журнал событий со статусом 50» при выполнении команды CHKDSK.

Решение 1. Исправление поврежденных секторов

Поскольку сообщение об ошибке «Не удалось передать зарегистрированные сообщения в журнал событий со статусом 50» может появляться из-за повреждений или поврежденных секторов в разделе Windows, вы можете запустить команду «chkdsk c: /r /f /v» для восстановления. читаемая информация из поврежденных секторов и устранение ошибок файловой системы.

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

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

Решение 2. Снимите защиту от записи

Если ваш диск или раздел настроен только для чтения, система не сможет передавать зарегистрированные сообщения. Чтобы успешно запустить CHKDSK, вы можете убрать атрибут «только для чтения» на вашем диске. После этого вы больше не будете сталкиваться с ошибкой «не удалось передать зарегистрированные сообщения в журнал событий со статусом 50». Существует несколько способов снять защиту от записи, самый простой из них:

Шаг 1. Запустите «Командную строку» от имени администратора.

Шаг 2. Введите diskpart и нажмите "Да" в запросе уведомления.

Шаг 3. Введите следующую команду по порядку:

Если ваш диск защищен от записи, вы также можете столкнуться с ошибкой "Windows не может выполнить проверку диска на этом томе, поскольку он защищен от записи" при запуске CHKDSK.

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

EaseUS CleanGenius — это один из этих инструментов, который помогает устранять вышеупомянутые проблемы на ваших дисках, даже не зная ничего о командной строке.

Вот простое руководство по использованию этого инструмента для решения проблем:

Шаг 1: ЗАГРУЗИТЕ и установите EaseUS CleanGenius (бесплатно) на свой компьютер.

Шаг 2. Запустите EaseUS CleanGenius на своем ПК, выберите «Оптимизация» и выберите режим защиты от записи.

Шаг 3. Выберите устройство, защищенное от записи, и нажмите «Отключить», чтобы снять защиту.

Решение 3. Запустите CHKDSK после загрузки в безопасном режиме

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

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

Следующие шаги выполняются в Windows 10:

Шаг 1. Удалите все периферийные устройства с компьютера.

Шаг 2. Нажмите "Пуск" и выберите "Настройки" (значок шестеренки).

Шаг 3. Перейдите в раздел «Обновление и безопасность» > «Восстановление».

Шаг 4. В разделе "Расширенный запуск" нажмите "Перезагрузить сейчас".

Шаг 5. После этого ваш компьютер перезагрузится и откроется экран «Выберите вариант». Выберите «Устранение неполадок» > «Дополнительные параметры» > «Параметры запуска» > «Перезагрузить».

Шаг 6.Затем ваш компьютер запустится со списком опций для вас. Выберите «Включить безопасный режим», чтобы загрузить компьютер в безопасном режиме.

Шаг 7. Запустите команду CHKDSK в соответствии с вашими потребностями.

Решение 4. Отправить диск на ремонт

Если ваш жесткий диск поврежден, запуск CHKDSK, скорее всего, завершится ошибкой с сообщением об ошибке "не удалось передать зарегистрированные сообщения в журнал событий со статусом 50". Когда ваш жесткий диск физически поврежден, все, что вы можете сделать, это отправить его на ремонт, если вы хотите восстановить свои данные. Ручной ремонт или служба ручного восстановления данных могут помочь спасти ваш диск или данные на нем.

Итог

Во время работы CHKDSK вы можете получать другие сообщения об ошибках, такие как "не удается открыть том для прямого доступа", "chkdsk недоступен для дисков RAW" и т. д. «Не удалось перенести зарегистрированные сообщения в журнал событий со статусом 50» — только одна из них. Как правило, это вызвано ошибками вашего диска, будь то плохие сектора, повреждения или ошибки файловой системы. Выработайте привычку использовать диск, чтобы свести к минимуму его повреждение, и регулярно создавайте резервные копии файлов, чтобы избежать полной потери данных.

Проблема Windows: не удалось передать зарегистрированные сообщения со статусом 50

Об ошибке «Не удалось передать зарегистрированные сообщения со статусом 50»

Если вы получили это сообщение, значит, вы использовали утилиту chkdsk для проверки диска.

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

Причины проблемы

Итак, почему вы видите ошибку «не удалось перенести сообщения журнала в журнал событий»?

Лучше всего, если проблема в том, что диск находится в режиме чтения. В этом случае chkdsk не может проверить диск.

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

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

И что еще хуже, это означает механическое повреждение жесткого диска. Часто это происходит из-за неправильного обращения с компьютером.

Способ 1. Если жесткий диск имеет атрибуты только для чтения

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

Вам нужно указать всего несколько команд и защита будет снята, после чего вы сможете свободно пользоваться chkdsk. Итак, запустите diskpart и используйте следующие команды:

список томов — затем нажмите Enter.

выберите том Е (E — буква диска) — затем нажмите Enter.

указывает, что диск очищается только для чтения — затем нажмите Enter.

Очистить атрибуты только для чтения.

После этих трех команд перезагрузите компьютер и действуйте как раньше.

Метод 2. Используйте chkdsk для решения проблемы «не удалось передать зарегистрированные сообщения со статусом 50»

Chkdsk может повредить данные, которые можно восстановить (скорее всего, разрубив их на мелкие фрагменты - до 512Кб).

Поэтому перед запуском запустите DiskInternals Uneraser и восстановите данные.

Это золотой стандарт работы с утилитой chkdsk. DiskInternals Uneraser быстро сделает копию ваших данных во всех форматах. При этом программа не будет заморачиваться с лимитами восстановления; это очень полезно для восстановления жестких дисков. Сканирование качественное, поэтому глубокий поиск позволяет найти даже самые устаревшие файлы. Мастер восстановления даст вам возможность бесплатно просмотреть все найденные данные, и только после этого предложит их сохранить.

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

Что касается экспорта, то это уже платная услуга, но за небольшие деньги вы получите обратно весь свой жесткий диск; оно того стоит.

Способ 3. В крайнем случае

Если проблема «chkdsk status 50» по-прежнему беспокоит вас, вы можете переустановить Windows.

Вся информация с жесткого диска уже сохранена в другом месте с помощью DiskInternals Uneraser. Теперь осталось только запустить установочный диск и переустановить ОС.

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

Журналы событий находятся в каталоге Windows или WINNT в папке %WinDir%\system32\config.Эти файлы заканчиваются на .evt, но мы видели их с разными схемами капитализации (.evt, .EVT, .Evt).

Аудит событий входа в учетную запись

Аудит управления аккаунтом

Изменение политики аудита

Аудит использования привилегий

Рисунок 5.4. Запись о неудачном входе

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

Чтобы заключить сделку, атаки с подбором пароля происходят намного быстрее, чем любой человек может ввести. Так будет не каждый раз. Захваченные нами инструменты для подбора паролей могут снизить частоту атак (x атак в течение y часов), поэтому это может быть не так очевидно (см. рис. 5.5).< /p>

Рисунок 5.5. Атака с подбором пароля

И Phatbot, и Rbot предоставляют другие признаки того, что атака с подбором пароля реальна. Ранее в книге мы перечислили идентификаторы пользователей по умолчанию, которые они оба могут использовать. Вы можете не увидеть это в каждой атаке, но если бот еще не собрал какие-либо идентификаторы пользователей локально или если собранные идентификаторы пользователей не вошли, бот может попробовать идентификаторы пользователей из списка по умолчанию. Они почти всегда пытаются использовать Администратора, поэтому, если вы переименовали эту учетную запись, ее появление при неудачной попытке входа повышает вероятность того, что это атака. Если вы видите попытки использовать идентификаторы пользователей Administrador, а затем administrateur в качестве идентификатора входа, вы можете быть уверены, что это атака с подбором пароля и что бот (вероятно, Phatbot, Rbot или другое родственное семейство ботов) атакует компьютер жертвы. Если попытки происходят в то время, когда никто не должен работать в этом отделе, вы можете быть еще более уверены.

Итак, какой смысл анализировать эти данные? Вы исследуете этот компьютер, потому что кто-то уже сказал, что он заражен вирусом, или потому что один из ваших источников информации заметил, что он общается с известным C&C-сервером. Вот значение этого анализа: Все компьютеры, перечисленные в поле «рабочая станция» в записях о неудачном входе в систему 3-го типа, где поле «рабочая станция» отличается от имени компьютера жертвы, являются зараженными компьютерами. Используя эту технику на этапе анализа, мы обнаружили более 200 зараженных компьютеров, которые были частью одного ботнета. И это несмотря на то, что мы активно сканируем активность C&C ботов. Это глубокоэшелонированная защита во всей красе. Однако это происходит на этапе анализа, который мы рассмотрим позже в этой главе. На этом этапе мы пытаемся определить вектор атаки, время успешной попытки и идентификатор пользователя, успешно вошедшего в систему (который теперь следует считать скомпрометированным).

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

Рисунок 5.6. Успешный взлом

Мы создали пакетный файл, содержащий одну строку: C:\"Program Files\Log Parser 2.2\"LogParser.exe -o:CSV file:LogonFailuresDistinct2.sql?machine=*"

В этой строке говорится: «Запустите синтаксический анализатор журнала, прочитайте файл LogonFailures.sql, выполните найденные там команды SQL, сообщите о найденных результатах для всех компьютеров и поместите результаты в файл значений, разделенных запятыми».

Запрос SQL LogonFailures говорит:

ОТ .\logs2\*.evt, ГДЕ EventType = 16 И EventCategory = 2 И Attacking_Workstation <> ComputerName

Этот запрос заставит Log Parser:

Извлечь поле, сгенерированное временем

Извлеките имя пользователя и домен для входа и соедините их, чтобы сформировать поле с именем Пользователь

.

Переименуйте поле ComputerName в Targeted Computer

Найдите поле Рабочая станция

Log Parser должен сделать это из всех журналов событий в .\logs для всех событий входа в систему (категория событий 2), которые завершились неудачно (тип события 2) и где имя атакующей рабочей станции не соответствует ComputerName< /em> поле.

Таблица 5.1 показан пример вывода этого SQL-запроса. Вы можете видеть, что атаки исходили от двух компьютеров, ATTACKER1 и ATTACKER2. ATTACKER2 демонстрирует паттерн, соответствующий атаке с автоматическим подбором пароля, с попытками, совершаемыми по одной в секунду в течение часа. Также является подсказкой, что за этот час было совершено 2200 попыток. Вы также можете видеть, что злоумышленник в нашем значительно измененном примере использовал словарь, содержащий пять паролей, чтобы попробовать для каждого идентификатора пользователя. Когда вы объединяете все подобные журналы для анализа, вы можете увидеть шаблон атаки. Найдите злоумышленника, а затем найдите его в столбце «Жертва». Вы можете отметить, какой компьютер заразил этот компьютер, и проследить его в обратном направлении в столбце «Жертва», таким образом реконструируя временную шкалу распространения ботнета. Это часто показывает шаблон, называемый «разветвлением», когда ботнет заражает один компьютер в новой подсети, а затем этот компьютер разветвляется, чтобы заразить другие в той же подсети. Используя эту технику, мы можем превратить вектор атаки бот-клиента в источник информации.

Таблица 5.1. Пример вывода SQL-запроса синтаксического анализатора журнала

< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< td >ЖЕРТВА< тд > VI CTIM
TimeGeneratedПользовательTargeted_ComputerAttacking_Workstation
03.08.2006 8:40:24ATTACKER1\jdoeНАПАДАТЕЛЬ1
8/3/2006 8:44:02НАПАДАТЕЛЬ1\jdoeНАПАДАТЕЛЬ1
8/3/2006 8:46:51НАПАДАТЕЛЬ1\jdoeНАПАДАТЕЛЬ1
8/3/2006 8:50:37НАПАДАТЕЛЬ1\jdoeНАПАДАТЕЛЬ1
8/3/2006 8:53:33НАПАДАТЕЛЬ1\jdoeНАПАДАТЕЛЬ1
8/3/2006 8:57:17НАПАДАТЕЛЬ1\jdoeАТАКУЮЩИЙ1
14.08.2006 10:25:00АТАКУЮЩИЙ1\jdoeАТАКУЮЩИЙ1
14.08.2006 10:29:09АТАКУЮЩИЙ1\jdoeАТАКУЮЩИЙ1
14.08.2006 10:31:46АТАКУЮЩИЙ1\jdoeATTACKER1
14.08.2006 10:35:23ATTACKER1\jdoe ЖЕРТВААтакующий1
16.08.2006 8:21:06Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:07Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:08Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:09Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:11Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:13Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:14Атакующий2\Администратор ЖЕРТВААтакующий2
16.08.2006 8:21:15Атакующий2\ Администратор ЖЕРТВАНАПАДАТЕЛЬ2
16.08.2006 8:21:16ATTACKER2\AdministradorVICTIMATTACKER2
16.08.2006 8:21:17ATTACKER2\AdministradorVICTIMATTACKER2
16.08.2006 8:21:18Атакующий2\АдминистраторЖЕРТВААтакующий2
16.08.2006 8:21:20Атакующий2\АдминистраторЖЕРТВААтакующий2
16.08.2006 8:21:21Атакующий2\АдминистраторЖЕРТВААтакующий2
16.08.2006 8:21:23Атакующий2\АдминистраторЖЕРТВААтакующий2
16.08.2006 8:21:27Атакующий2\АдминистраторЖЕРТВААтакующий2

Вы можете найти основные пояснения в сопроводительном файле справки или выполнить поиск по запросу Logparser на сайте Microsoft. Существует также гораздо более подробное описание использования Log Parser в книге Syngress, < em>Набор инструментов Microsoft Log Parser Toolkit, написанный Габриэле Джузеппини и Марком Бернеттом. Гуизеппини — один из разработчиков инструмента Microsoft.

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

Имя компьютера и источник

IP-адрес и источник

MAC-адрес и источник

Что наблюдалось (например, атака с подбором пароля против Victim1)

Дата/время последней попытки

Здание, комната и номер гнезда

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

Отсутствуют несколько важных компонентов нашей инфраструктуры. Система управления активами отсутствует, поэтому база данных активов не связана с системой справочной службы. База данных, которая связывает информацию о помещении здания и разъеме данных с портом коммутатора, не обновлялась. Сопоставление зданий с комнатами и разъемами данных не обновлялось, поэтому мы продолжаем посылать техников в комнаты, которых больше не существует. Не существует простого способа соотнести имя NetBios компьютера с его IP-адресом и MAC-адресом. Хотя для компьютеров существует стандартное соглашение об именах, другие отделы слабо соблюдают его. Почти невозможно найти компьютер с именем LAPTOP среди 27 000 пользователей. В XP запись журнала событий безопасности содержит только NetBIOS-имя компьютера, а не IP-адрес; из-за того, как настроен наш DNS, некоторые из этих имен NetBIOS можно найти с помощью nslookup.

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

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

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

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

Защита облака: архитектура

Вик (Дж. Р.) Винклер в книге «Безопасность облака», 2011 г.

Аудит системы и сети

Журналы событий системной и сетевой безопасности – это краеугольный камень для управления постоянной безопасностью любой системы. В облаке события аудита будут генерироваться в принципиально разных зонах доверия; они варьируются от высокозащищенной сети и компонентов безопасности до систем, в которых CSP предоставляет значительный контроль арендаторам или пользователям. Таким образом, события безопасности должны быть признаны имеющими разную степень целостности. Ниже приведены основные требования к созданию событий аудита и управлению ими:

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

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

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

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

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

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

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

Читайте также: