Когда я использую новый удаленный рабочий стол с ssl и пытаюсь войти в систему с неверными учетными данными, он регистрирует событие 4625, как и ожидалось. Проблема в том, что он не регистрирует IP-адрес, поэтому я не могу заблокировать вредоносный вход в наш брандмауэр. Событие выглядит так:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{00000000-0000-0000-0000-000000000000}" />
<EventID>4625</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2012-04-13T06:52:36.499113600Z" />
<EventRecordID>467553</EventRecordID>
<Correlation />
<Execution ProcessID="544" ThreadID="596" />
<Channel>Security</Channel>
<Computer>ontheinternet</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-0-0</Data>
<Data Name="SubjectUserName">-</Data>
<Data Name="SubjectDomainName">-</Data>
<Data Name="SubjectLogonId">0x0</Data>
<Data Name="TargetUserSid">S-1-0-0</Data>
<Data Name="TargetUserName">notauser</Data>
<Data Name="TargetDomainName">MYSERVER-PC</Data>
<Data Name="Status">0xc000006d</Data>
<Data Name="FailureReason">%%2313</Data>
<Data Name="SubStatus">0xc0000064</Data>
<Data Name="LogonType">3</Data>
<Data Name="LogonProcessName">NtLmSsp</Data>
<Data Name="AuthenticationPackageName">NTLM</Data>
<Data Name="WorkstationName">MYSERVER-PC</Data>
<Data Name="TransmittedServices">-</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x0</Data>
<Data Name="ProcessName">-</Data>
<Data Name="IpAddress">-</Data>
<Data Name="IpPort">-</Data>
</EventData>
</Event>
Похоже, что из-за того, что тип входа в систему равен 3, а не 10, как в старых сеансах rdp, IP-адрес и другая информация не сохраняется.
Машина, с которой я пытаюсь подключиться, находится в Интернете, а не в той же сети, что и сервер.
Кто-нибудь знает, где хранится эта информация (и какие еще события возникают при неудачном входе в систему)?
Любая помощь будет высоко ценится.
Используя TLS / SSL в качестве шифрования для протокола RDP, Windows не регистрирует IP-адрес пользователя, пытающегося войти в систему. Когда вы настраиваете сервер для шифрования протокола с (устаревшим) шифрованием RDP, он записывает IP-адрес в журнал событий безопасности.
Вам придется пойти на компромисс. Либо у вас будет менее безопасное шифрование протокола, либо вы никогда не узнаете источник потенциальной атаки. Имея правильную систему обнаружения вторжений (которую можно загрузить бесплатно), система автоматически заблокирует потенциального злоумышленника после определенного количества неверных входов в систему.
Узнайте больше о безопасности RDP, интеллектуальном обнаружении и защите от вторжений здесь: https://cyberarms.net/security-blog/posts/2012/june/remote-desktop-logging-of-ip-address-(security-event-log-4625).aspx
В secpol.msc открыто Local Policies | Security Options устанавливать Network security: Restrict NTLM: Incoming NTLM traffic к Deny all accounts. Это нельзя использовать с NLA, но работает с SSL (значок информации SSL на верхней панели mstsc.exe клиент подтверждает идентичность сервера) и успешно записывает исходный сетевой адрес в неудачное событие с идентификатором 4625 в журнал аудита.
Вот мой предыдущий журнал
Oct 17 13:59:22 TS04.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 13:59:22","Hostname":"TS04.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":1366552,"ProcessID":568,"ThreadID":35244,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-0-0","SubjectUserName":"-","SubjectDomainName":"-","SubjectLogonId":"0x0","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM","WorkstationName":"CVETKOV-C3414E6","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"-","IpAddress":"-","IpPort":"-","EventReceivedTime":"2015-10-17 13:59:24","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015
и после
Oct 17 14:00:36 TS02.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 14:00:36","Hostname":"TS02.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":2613410,"ProcessID":564,"ThreadID":17112,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-5-18","SubjectUserName":"TS02$","SubjectDomainName":"UCSSAAS","SubjectLogonId":"0x3e7","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate","WorkstationName":"TS02","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"C:\\Windows\\System32\\winlogon.exe","IpAddress":"109.199.229.32","IpPort":"0","EventReceivedTime":"2015-10-17 14:00:37","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015
В основном источник WorkstationName потеряно, и теперь вместо этого отображается имя сервера RDSH, но вы получаете IpAddress в обмен. Это показывает изменение, которое произошло под "LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM" изменен на "LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate"
Я использую этот параметр на нескольких узлах сеансов Win2012 R2 и провел тесты с несколькими успешными / неудачными сеансами входа в систему из mstsc.exe клиенты на машинах Win XP (последние mstsc.exe версия 6.1.7600 для XP).
(Журнал выше взят из rsyslog на балансировщике нагрузки haproxy, который собирает журналы аудита из ящиков RDSH, которые пересылаются службой nxlog в формате JSON. На haproxy есть тюрьма fail2ban, которая блокирует клиентов по IP после ряда неудачных попыток входа в систему попытки.)
Я нашел эту статью о файлах журнала для сеанса RDP. Надеюсь, это будет вам полезно.
http://forums.techarena.in/windows-security/838814.htm
Я тоже не вижу - в чем конкретно проблема?
Сделав предположение на основе темы, проверьте журнал программы просмотра событий безопасности Windows XP. Политику аудита можно настроить с помощью редактора групповой политики для отслеживания успешных и неудачных попыток входа в систему: С Пуск | Запустите командное окно типа gpedit.msc. Перейдите к политике локального компьютера | Конфигурация компьютера | Настройки Windows | Настройки безопасности | Местная политика | Политика аудита | Аудит событий входа в систему. Выделите, щелкните правой кнопкой мыши и выберите свойства. Настроить по желанию.
Обратите внимание, что вход в систему без пароля регистрируется как сбой. Это приводит к тому, что журнал безопасности заполняется очень быстро, если вы регистрируете сбои и у пользователя нет пароля. В результате вы не можете войти в систему в обычном режиме. Также обратите внимание, что отсутствие пароля является потенциальной и вероятной угрозой безопасности.
Журнал событий можно просмотреть, перейдя в Пуск | Панель управления | Производительность и обслуживание | Администрирование и нажмите «Просмотр событий».
Журнал событий (безопасность), регистрирующий успешный вход в систему и выход из системы удаленным пользователем. Пользователь может выделить запись в журнале и щелкнуть правой кнопкой мыши, чтобы просмотреть свойства события для получения подробной информации.
Найдите в журнале событий безопасности событие 528 входа / выхода и тип входа 10.
Бесплатная программа Microsoft Port Reporter обеспечивает дополнительное ведение журнала. Описание инструмента Port Reporter Parser (PR-Parser) http://support.microsoft.com/default...b;en-us;884289
Доступность и описание инструмента Port Reporter http://support.microsoft.com/kb/837243