Мы используем в общей сложности 7 выпусков Windows Server (2008/2012) R2 Standard Edition для сред разработки и производства. В прошлом месяце наши серверы были скомпрометированы, и мы обнаружили много журналов неудачных попыток в средстве просмотра событий Windows. Мы пробовали киберармы IDDS, но раньше это не помогло.
Теперь мы повторно создали образы всех наших серверов и переименовали учетные записи администратора / гостя. И после повторной настройки серверов мы используем это idds для обнаружения и блокировки нежелательных IP-адресов.
IDDS работает хорошо, но все же мы получаем 4625 событий в средстве просмотра событий без какого-либо исходного IP-адреса. Как я могу заблокировать эти запросы с анонимных IP-адресов?
<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-A5BA-3E3B0328C30D}'/>
<EventID>4625</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>12544</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime='2015-04-18T15:18:10.818780700Z'/>
<EventRecordID>187035</EventRecordID>
<Correlation/>
<Execution ProcessID='24876' ThreadID='133888'/>
<Channel>Security</Channel>
<Computer>s17751123</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'>aaron</Data>
<Data Name='TargetDomainName'>\aaron</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'>SSAWSTS01</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>
ОБНОВИТЬ : После проверки журналов брандмауэра я думаю, что эти события 4625 никоим образом не связаны с Rdp, но могут быть SSH или любыми другими попытками, с которыми я не знаком.
IP-адрес для неудачных попыток RDP регистрируется здесь даже при включенном NLA (никаких настроек не требуется) (протестировано на Server 2012 R2, не уверен в других версиях)
Журналы приложений и служб> Microsoft-Windows-RemoteDesktopServices-RdpCoreTS / Operational (идентификатор события 140)
Пример записанного текста:
Соединение с клиентским компьютером с IP-адресом 108.166.xxx.xxx не удалось из-за неправильного имени пользователя или пароля.
XML:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" Guid="{1139C61B-B549-4251-8ED3-27250A1EDEC8}" />
<EventID>140</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>4</Task>
<Opcode>14</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2016-11-13T11:52:25.314996400Z" />
<EventRecordID>1683867</EventRecordID>
<Correlation ActivityID="{F4204608-FB58-4924-A3D9-B8A1B0870000}" />
<Execution ProcessID="2920" ThreadID="4104" />
<Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
<Computer>SERVER</Computer>
<Security UserID="S-1-5-20" />
</System>
- <EventData>
<Data Name="IPString">108.166.xxx.xxx</Data>
</EventData>
</Event>
Это известное ограничение для события 4625 и подключений RDP с использованием TLS / SSL. Вам нужно будет использовать шифрование RDP для настроек сервера удаленного рабочего стола или получить лучший продукт IDS.
Вам следует использовать встроенный брандмауэр Windows и его настройки ведения журнала. Журналы сообщат вам IP-адреса всех попыток входящих подключений. Поскольку вы упомянули, что все ваши серверы выходят в Интернет, действительно существует нет извините за то, что вы не используете брандмауэр Windows как часть вашей стратегии глубокой защиты. Я бы особо рекомендовал не отключение NLA (аутентификация на сетевом уровне), поскольку многие из атак на RDP в прошлом исторически смягчались с помощью NLA и затрагивали только узлы сеанса RDP, использующие только классическое шифрование RDP.
Это событие обычно вызывается устаревшими скрытыми учетными данными. Попробуйте это из системы, выдающей ошибку:
Из командной строки запустите: psexec -i -s -d cmd.exe
В новом окне cmd запустите: rundll32 keymgr.dll,KRShowKeyMgr
Удалите все элементы, которые отображаются в списке сохраненных имен пользователей и паролей. Перезагрузите компьютер.