Ідентифікатор події 4625 без джерела IP

Ми використовуємо 7 стандартних версій Windows Server (2008/2012) R2 для середовищ розробки та виробництва. Минулого місяця наші сервери були порушені, і ми знайшли багато невдалих журналів спроб у вікні перегляду подій Windows. Ми спробували Cyberarms 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 (ID події 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

Видаліть усі елементи, що відображаються у списку збережених імен користувачів та паролів. Перезавантажте комп'ютер.