Ведение журнала событий IP-адрес не всегда разрешается

Question

Я перехватываю журнал событий безопасности с классом System.Diagnostics.Eventing.Reader.EventLogWatcher и наблюдаю за событием с кодом 4625 на сервере 2008 года для входящих неудачных входов (особенно RDP).

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

Я запустил windump, наблюдая за сервером, пробуя мои обычные RDP-входы с разных серверов и версий ОС, и единственный вывод, к которому я могу прийти, это проблема различия версий, а не плохое кодирование. Хотя я могу ошибаться, LOL.

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

Приводит ли какой-либо более новый вариант mstsc к удаленному журналу событий НЕ запись IP-адреса источника? Похоже, что это верно для любого другого сервера 2008 года, который я запускаю на этом подключенном сервере. Любая машина 2003 или XP, которую я до сих пор пробовал, регистрируется правильно.

Если вам нужна дополнительная информация, дайте мне знать. Спасибо ТАК!

EDIT

Нужно ли делать что-то сумасшедшее - например, использовать sharpPcap и соотносить IP-адреса с журналами событий? знак равно Можно ли запросить lsass (разве это не единственное, что обычно записывает в журнал безопасности)?

Answer 1

Я, наконец, получил это работает. Это происходило потому, что для соединений RDP использовались два метода аутентификации: NTLM и User32. Я изменил настройки GPO, чтобы уничтожить внешние NTLM-соединения.

Это настройки GPO, которые я установил, которые сделали волшебство. Обратите внимание, что это коробка Server 2008 R2.

Обязательно
Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Параметры безопасности

Сетевая безопасность: уровень аутентификации LAN Manager - отправлять только NTLMv2-ответ. Отказаться от LM & NTLM
Сетевая безопасность: ограничение NTLM: аудит входящего трафика NTLM - включение аудита для всех учетных записей
Сетевая безопасность: ограничение NTLM: входящий трафик NTLM - запрет всех учетных записей

Рекомендуется
Не разрешать сохранение паролей - Включено
Запрашивать учетные данные на клиентском компьютере - Включено

Я также изменил некоторые другие ключи, связанные с безопасностью, но они должны быть основными. Принудительное отклонение входящего сетевого трафика от использования NTLM позволяет каждому событию 4625 содержать IP-адрес неисправного компьютера, поскольку они вынуждены использовать вход в систему User32.

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

Answer 2

Ответ Астероида работает, но вы ДОЛЖНЫ включить «Разрешить подключения с компьютеров, на которых установлена ​​любая версия Удаленного рабочего стола (менее безопасных)» вместо «Разрешить подключения только с компьютеров, на которых работает Удаленный рабочий стол с аутентификацией на сетевом уровне (более безопасной)». *

NLA не использует User32, но использует NtLmSsp, который опирается на ответы LM. Если он заблокирован (как это будет сделано в приведенных выше инструкциях), вы получите сообщение «С местным органом безопасности нельзя связаться».