Что такое аудит успеха Windows

Обновлено: 21.11.2024

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

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

Что, почему и как использовать журналы событий

Журналы событий – это локальные файлы, в которых записываются все «происшествия» в системе, в том числе доступ, удаление, добавление файла или приложения, изменение системной даты, выключение системы, изменение конфигурации системы и т. д. подразделяются на категории «Система», «Безопасность», «Приложение», «Служба каталогов», «DNS-сервер» и «Репликация DFS». Журналы службы каталогов, DNS-сервера и репликации DFS применимы только для Active Directory. События, связанные с безопасностью системы или данных, называются событиями безопасности, а их файл журнала называется журналом безопасности.

В следующих разделах содержится более подробная информация о журналах событий Windows и о том, что требует их мониторинга:

Категории журнала событий

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

Типы журналов событий

Каждая запись о событии классифицируется по типу, чтобы определить серьезность события. Это информация, предупреждение, ошибка, аудит успехов (журнал безопасности) и аудит отказов (журнал безопасности).

Тип журнала событий Описание
Журнал приложений Любой событие, зарегистрированное приложением. Они определяются разработчиками при разработке приложения. Например: ошибка при запуске приложения записывается в журнал приложений.
Системный журнал Любое событие, регистрируемое операционной системой. Например: сбой запуска диска во время запуска регистрируется в системных журналах
Журнал безопасности Любое событие, имеющее значение для безопасности системы. Например: действительные и недействительные входы и выходы из системы, любое удаление файлов и т. д. регистрируются в этой категории.
Журнал службы каталогов записывает события AD. Этот журнал доступен только на контроллерах домена.
Журнал DNS-сервера записывает события для DNS-серверов и разрешения имен. Этот журнал доступен только для DNS-серверов
Журнал службы репликации файлов записывает события репликации контроллера домена. Этот журнал доступен только на контроллерах домена.
Тип события Описание
Информация Событие, которое описывает успешную работу задачи, например приложения, драйвера или службы. Например, информационное событие регистрируется при успешной загрузке сетевого драйвера.
Предупреждение Однако событие, которое не обязательно является значительным, может указывать на возможное возникновение проблемы в будущем. Например, предупреждающее сообщение регистрируется, когда на диске начинает заканчиваться место.
Ошибка Событие, указывающее на серьезную проблему, такую ​​как потеря данных. или потеря функциональности. Например, если служба не загружается во время запуска, регистрируется событие Ошибка.
Аудит успеха (журнал безопасности) Событие, описывающее успешное завершение проверенного события безопасности. Например, событие аудита успеха регистрируется, когда пользователь входит в систему на компьютере.
Аудит отказов (журнал безопасности) Событие, описывающее проверенное событие безопасности, которое не завершилось успешно. Например, аудит отказов может быть зарегистрирован, когда пользователь не может получить доступ к сетевому диску.

В средстве просмотра событий список журналов событий выглядит следующим образом:

Понимание события

События перечислены с информацией в заголовке и описанием в средстве просмотра событий.

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

Дважды щелкните событие, чтобы просмотреть подробности:

Как журналы безопасности могут предотвратить взлом и кражу данных?

Безопасность — это самая большая проблема, с которой сегодня сталкивается любой бизнес. Такие инциденты, как взломы и кражи данных, постоянно растут, подвергая риску все сегменты бизнеса и оставляя администраторов с красными глазами. Различные промышленные исследования показывают, что большинство взломов и краж происходят из-за незаконных попыток аутентификации. Аудит незаконных или неудачных попыток входа в систему может предотвратить (или уменьшить) кражу данных. Тем не менее, важно, чтобы мы знали, что операционная система может обеспечить с точки зрения безопасности, и что мы должны сделать, чтобы внедрить операционные системы с требуемой безопасностью.

События, требующие аудита и плана аудита

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

  • Вход/выход пользователя
  • вход/выход/перезагрузка компьютера
  • Доступ к объектам, файлам и папкам
  • Системное время изменено
  • Журналы аудита очищены

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

  • События входа в аккаунт
  • Управление аккаунтом
  • Доступ к службе каталогов
  • События входа
  • Доступ к объектам
  • Изменение политики
  • Привилегированное использование
  • Отслеживание процесса
  • Системные события

Необходимость мониторинга журналов событий

Необходимость соблюдения требований безопасности, таких как SOX, HIPAA и т. д., для публичных компаний, отрасли здравоохранения и т. д. требует внедрения процесса управления безопасностью для защиты от попыток или успешного несанкционированного доступа. Защита информации в вашей сети имеет решающее значение для вашего бизнеса, независимо от того, соответствует ли она некоторым стандартам. Журналы событий Windows — это один из источников, с помощью которого можно отслеживать и регистрировать попытки входа в систему. Ручная проверка на каждом устройстве Windows утомительна и невозможна, поэтому требуется автоматический аудит и мониторинг журналов событий на регулярной основе.

В моем средстве просмотра событий на вкладке "Безопасность" почти ежечасно происходит большое количество событий входа в систему/выхода из системы/специального входа в систему. Между ними множество событий «Управление учетными записями пользователей». Это нормально? Рискну предположить, что это что-то вроде Onedrive, но я не уверен.

Дополнительная информация: на сегодняшний день большинство событий 4642 относятся к типу 5, хотя время от времени появляются некоторые события типа 4. Есть также несколько 4648, но они менее распространены. У меня есть Norton 360, и раньше я сканировал с помощью Malwarebytes, но ничего существенного не нашел.

Отредактировано SprungTheTrap, 8 января 2021 г., 01:08.

BC AdBot (войдите для удаления)

У вас есть некоторый контроль в Norton 360 для программных веб-соединений: используйте старый интерфейс (как я) и в правом верхнем углу Настройки --> Брандмауэр --> Управление программами и то, что вы не хотите разрешать. out, выключите его там или откройте программу и скажите ей, чтобы она перестала выходить/обновляться. Хотя лучше отключить в брандмауэре, если вы вручную обновляете его с копией поверх.

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

Хотя сомневаюсь, что у многих с программами. Вы можете получить программу под названием O&O ShutUp10, чтобы уменьшить телеметрию MS, что, возможно, очень много, особенно если вы не прошли через Win10 и отключили все, что вы не используете или не хотите, или удалили, что может быть (обратите внимание, что все может быть переустановлено программой )

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

Использование O&O ShutUp10 может отключить многие вещи, которые вы можете использовать. (Здесь я работаю как Win7, без BS---), поэтому создайте папку, поместите ее в нее, это сделает 1 файл .ini таким хорошим, чтобы создать папку, после больших обновлений Win10 проверьте сайт на наличие новой версии и скопируйте сверху и запустить снова.

Давно усвоил, что не стоит возиться с аудитом безопасности.

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

Отредактировано Pkshadow, 8 января 2021 г., 02:22.

Я не боюсь фотографии, пока ее нельзя использовать ни в раю, ни в аду. -- приписывается - Эдвард Мунк

I-7 ASUS Rampage Extreme II / ASUS TUF Gaming F17 / I-7 4770K ASUS Maximus VII Hero / I-7 4790K ASUS Maximus VI Extreme

Спасибо за быстрый ответ, Пк! Какое облегчение. Так что это не было проблемой. Я уже настроил брандмауэр Norton и прочесал его вручную, и я не возражаю против дополнительной телеметрии, поскольку она не сильно влияет на производительность моего компьютера.

У меня такая же проблема. Когда они происходят, мой компьютер зависает на несколько секунд. В последние дни стало хуже. У меня 16 657 событий безопасности за последние 24 часа. Что я могу сделать, чтобы остановить это?
Имя устройства *******
Процессор Intel® Core™ i7-4600U CPU @ 2,10 ГГц 2,70 ГГц
Установленное ОЗУ 12,0 ГБ
Идентификатор устройства 78BD**** 2-8389-48B1-ABC0-B22889B773A2
Идентификатор продукта 00330-50000-00000-A***M
Тип системы 64-разрядная операционная система, 64-разрядный процессор

Выпуск Windows 10 Pro
Версия 20H2
Установлена ​​‎2021-‎04-‎28
Сборка ОС 19042.928
Опробуйте Windows Feature Experience Pack 120.2212.551.0

Или еще лучше, удалите Norton 360, так как это ужасное программное обеспечение.

Большой, раздутый и использует много циклов процессора. Много ошибок.

Что плохого в том, чтобы просто использовать Защитник?

Я не уверен, что согласен в этом с PKShadow. Через 35 лет использования/исправления

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

за столь короткое время. Я не говорю, что это серьезно, но я никогда раньше этого не видел.

Можете ли вы экспортировать системный журнал и прикрепить его сюда? Это позволит нам

посмотреть. Возможно, стоит также прикрепить журнал приложений.

Отредактировано Shplad, 1 мая 2021 г., 11:16.

– Используйте это для сбора и публикации информации об оборудовании, программном обеспечении и конфигурации вашего ПК (независимо от того, у вас произошел сбой).

Инструкции по размещению сообщений о синем экране смерти (BSOD) — Windows 10, 8.1, 8, 7 и Vista

Событие с идентификатором 4624 (просматриваемое в средстве просмотра событий Windows) документирует каждую успешную попытку входа на локальный компьютер. Это событие генерируется на компьютере, к которому осуществлялся доступ, другими словами, на котором был создан сеанс входа в систему. Связанное событие, идентификатор события 4625, документирует неудачные попытки входа в систему.

Событие 4624 относится к следующим операционным системам: Windows Server 2008 R2 и Windows 7, Windows Server 2012 R2 и Windows 8.1, а также Windows Server 2016 и Windows 10. Соответствующие события в Windows Server 2003 и более ранних версиях включали как 528, так и 540 для успешный вход в систему.

Идентификатор события 4624 выглядит немного по-разному в Windows Server 2008, 2012 и 2016. На снимках экрана ниже выделены важные поля в каждой из этих версий.

Событие 4624 (Windows 2008)

Событие 4624 (Windows 2012)

Событие 4624 (Windows 2016)

Описание полей событий

Важная информация, которую можно получить из события 4624, включает:

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

Происходит, когда пользователь получает доступ к удаленным общим папкам или принтерам. Кроме того, большинство входов в Internet Information Services (IIS) классифицируются как входы в сеть (за исключением входов в IIS, которые регистрируются как тип входа 8).

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

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

Происходит, когда пользователь разблокирует свой компьютер с Windows.

Происходит, когда пользователь входит в систему по сети и пароль отправляется в виде открытого текста. Чаще всего указывает на вход в IIS с использованием «базовой аутентификации».

Происходит, когда пользователь запускает приложение с помощью команды RunAs и указывает переключатель /netonly.

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

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

Другая информация, которую можно получить из события 4624:

  • • В разделе "Тема" указана учетная запись в локальной системе (не пользователь), которая запросила вход.
  • • Раздел «Уровень олицетворения» показывает, в какой степени процесс в сеансе входа может олицетворять клиента.Уровни олицетворения определяют операции, которые сервер может выполнять в контексте клиента.
  • • В разделе "Информация о процессе" содержится подробная информация о процессе, предпринявшем попытку входа в систему.
  • • В разделе «Информация о сети» показано, где находился пользователь, когда он вошел в систему. Если вход был инициирован с того же компьютера, эта информация будет либо пустой, либо будет отражать имя рабочей станции локального компьютера и исходный сетевой адрес.
  • • Информация об аутентификации показывает информацию о пакете аутентификации, используемом для входа в систему.

Причины отслеживания успешных входов в систему

Безопасность

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

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

Работает

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

Соответствие

Для соблюдения нормативных требований необходима точная информация об успешных входах в систему.

Необходимость стороннего инструмента

В типичной ИТ-среде количество событий с идентификатором 4624 (успешных входов в систему) может исчисляться тысячами в день. Однако все эти успешные входы в систему не важны; даже важные события бесполезны сами по себе, без какой-либо связи с другими событиями.

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

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

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

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

Если вы хотите самостоятельно изучить продукт, загрузите бесплатную полнофункциональную 30-дневную пробную версию.

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

Журналы событий находятся в каталоге 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 предоставляет значительный контроль арендаторам или пользователям. Таким образом, события безопасности должны быть признаны имеющими разную степень целостности. Ниже приведены основные требования к созданию событий аудита и управлению ими:

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

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

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

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

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

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

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

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