Я хотел бы написать службу, которая извлекает записи средства просмотра событий, в частности, из журнала безопасности. Особый интерес для меня представляют сообщения о событии с идентификатором 4625 (ошибка аудита). В идеале я хотел бы сохранить IP-адреса клиентов, которые вызывают сбой аудита больше, чем n раз в m секунд на некоторое время.
Звучит достаточно просто, поэтому я быстро создал для этого службу .NET. Однако, когда я извлекаю эти ошибки аудита, значение «Сетевого адреса источника» всегда равно «-». Я хотел бы знать, как Windows может пройти весь путь входа в систему, закончиться неудачей и не знать IP-адрес однорангового узла.
Также стоит отметить, что несколько раз, когда IP-адрес действительно регистрируется, запись в журнале действительно содержит много другой полезной информации (например, процесс, который его сгенерировал, причину сбоя, переданные услуги и т. Д.).
Может кто-нибудь сказать мне, почему журнал безопасности не знает IP-адреса людей, которые пытаются войти в систему и терпят неудачу?
Может кто-нибудь сказать мне, почему журнал безопасности не знает IP-адреса людей, которые пытаются войти в систему и терпят неудачу?
Вот причина чего-то вроде удаленного рабочего стола.
В Windows нет возможности включить или отключить регистрацию IP-адреса, по крайней мере, насколько мне известно.
Для удаленного рабочего стола я обнаружил, что вход в «Конфигурация узла сеанса удаленного рабочего стола» и изменение соединения RDP-TCP, чтобы иметь уровень безопасности «Уровень безопасности RDP» вместо «Согласование» или «SSL (TLS 1.0)» вернули IP адреса.
Действительно ли вы хотите сделать это - другой вопрос для вас: «Если вы выберете уровень безопасности RDP, вы не сможете использовать аутентификацию на уровне сети».
IP-адреса, отсутствующие в журналах Windows, не так уж редки, особенно если (например) сбои происходят из-за службы, такой как IIS, и у вас есть только «базовый» уровень ведения журнала для IIS ... или SMTP, и вы иметь ведение журнала "базового" уровня для SMTP и т. д.
Не так, как я бы установил свои параметры ведения журнала по умолчанию, если бы моей ОС была Windows, но Гейтс никогда не спрашивал меня. Я бы посоветовал отрегулировать уровни ведения журнала (и увеличить максимальные размеры файлов журнала) и посмотреть, не решит ли это проблему. Дело не в том, что Windows не знает IP-адрес источника, а в том, что уровень ведения журнала установлен так, что он не записывает эту информацию. (И, как бы то ни было, установка уровня ведения журнала на что-нибудь полезное - один из первых шагов, которые я предпринимаю при создании нового сервера или шаблона сервера Windows.)
Подобно тому, что сказал HopelessN00b, наиболее вероятная причина, по которой вы не видите эту информацию, заключается в том, что ошибка аудита генерируется службой от имени пользователя. Таким образом, пользователь аутентифицируется не напрямую (как, например, при входе в Windows), а через какую-то другую службу, такую как IIS, SQL и т. Д. Затем вам нужно будет проанализировать журналы этих служб, чтобы узнать IP. адрес.
Теперь, если аутентификация осуществляется напрямую через Windows, вы обычно должны видеть IP-адрес или 127.0.0.1, если он поступает с локального компьютера.
В Windows нет возможности включить или отключить регистрацию IP-адреса, по крайней мере, насколько мне известно. Итак, настоящего «уровня» журналирования нет. Вы либо включаете категорию ведения журнала, либо нет. Единственное, что вы можете настроить, - это регистрировать сбои аудита и / или события успеха аудита (возможно, см. Эту статью: http://blogs.technet.com/b/askds/archive/2007/10/19/introduction-auditing-changes-in-windows-2008.aspx).
Кстати, есть много бесплатных продуктов, которые отслеживают журналы событий (например, мы разрабатываем EventSentry), обычно намного проще просто использовать это, чем писать свою собственную (если, конечно, вы не делаете это в качестве упражнения :-)).
Надеюсь это поможет.
Скорее всего, источником входящего трафика NTLM. Мне не удалось найти способ зарегистрировать IP-адрес, но вы можете заблокировать его, здесь вы можете узнать, почему не регистрируется, и шаги на как отключить входящий NTLM-трафик https://serverfault.com/a/729662/200398
Вы можете войти через брандмауэр. Если это атака методом грубой силы с одного IP-адреса, это будет легко сопоставить. Брандмауэр может быть восходящим. Как затем автоматизировать обнаружение и блокировку соединения - решать вам. У них никогда не закончатся конечные точки.
Вы также можете рассмотреть сценарий, который пробивает дыру в вашем брандмауэре, это обычно делается в настоящее время в облаке с помощью манипуляций NSG (Network Security Group) в самых простых крайностях. Также популярны прыжки с трамплина через серверы прыжков или бастионов.