Registrazione eventi IP Address non sempre risolve

Question

Sto agganciando il registro eventi di sicurezza con la classe System.Diagnostics.Eventing.Reader.EventLogWatcher e sto guardando ID evento 4625 su una casella del server 2008, per accessi non riusciti in entrata (RDP, in particolare).

L'acquisizione del registro funziona correttamente e sto eseguendo il dumping dei risultati in una coda per l'elaborazione successiva e correlata. Tuttavia, a volte i registri catturati hanno il campo dati IPAddress pieno (risolto) e talvolta no.

Ho eseguito windump mentre guardavo il server, provando i miei soliti login RDP da server e sistemi operativi diversi, e l'unica conclusione a cui posso arrivare è un problema di differenza di versione e non una cattiva programmazione. Anche se potrei sbagliarmi, LOL.

Il problema è nei registri eventi stessi riguardo a queste connessioni. Tutti gli accessi RDP non riusciti vengono registrati e vengono elaborati correttamente, ma alcuni registri semplicemente non registrano l'indirizzo IP di origine della connessione non riuscita.

Qualche novità di mstsc causa in qualche modo un registro eventi remoto a NON registrare l'indirizzo IP di origine? Questo sembra essere vero per qualsiasi altro server 2008 che corro contro questo server agganciato. Qualsiasi macchina 2003 o XP che ho provato finora è registrata correttamente.

Se hai bisogno di ulteriori informazioni, fammi sapere. Grazie COSÌ!

EDIT

Ho bisogno di fare qualcosa di pazzo - come implementare SharpPcap e correlare gli IP a eventlogs in quel modo? = /. Può essere interrogato forse (non è l'unica cosa che in genere scrive nel registro di sicurezza)?

Answer 1

Finalmente ho funzionato. Questo stava accadendo perché c'erano due metodi di autenticazione usati per le connessioni RDP: NTLM e User32. Ho modificato le impostazioni GPO per eliminare le connessioni NTLM esterne.

Queste sono le impostazioni di GPO ho impostato che ha fatto la magia. Si noti che questa è una casella Server 2008 R2.

richiesti
Configurazione computer \ Impostazioni di Windows \ Impostazioni protezione \ Opzioni di protezione

Protezione di rete: livello di autenticazione LAN Manager - Invia solo risposta NTLMv2. Rifiutare di sicurezza LM & NTLM
rete: limita NTLM: Audit Incoming NTLM Traffic - Attivare il controllo per tutti gli account
sicurezza di rete: limita NTLM: traffico NTLM in arrivo - Nega tutti i conti

consigliato
Non consentire password per essere salvato - Abilitato
Richiesta di credenziali sul computer client - Abilitato

Ho modificato anche altre chiavi relative alla sicurezza, ma queste dovrebbero essere le principali. Forzare il traffico di rete in entrata dall'utilizzo di NTLM consente a ogni singolo evento 4625 di contenere l'indirizzo IP del computer in errore, poiché sono obbligati a utilizzare l'accesso User32.

Fammi sapere se questo sembra totalmente insicuro o potrebbe esserci un modo migliore per farlo, ma ciò consente il conteggio corretto e il registro dei tentativi falliti mantenendo un livello di crittografia per la connessione. risposta

Answer 2

dell'asteroide funziona, ma è necessario attivare "Consenti connessioni dai computer che eseguono qualsiasi versione di Desktop remoto (meno sicuro)" invece di "Consenti connessioni solo da computer che eseguono Desktop remoto con Autenticazione a livello di rete (più sicuro)".

NLA non utilizza User32, ma utilizza NtLmSsp che si basa sulle risposte LM. Se ciò è bloccato (come faranno le istruzioni precedenti), finirai con voi vecchi "L'autorità di sicurezza locale non può essere contattata."