Perché dovresti disabilitare l'accesso alla rete per gli account locali?


8

Questa domanda è in riferimento al thread Twitter di @ SwiftOnSecurity: https://twitter.com/SwiftOnSecurity/status/655208224572882944

Dopo aver letto il thread, non riesco ancora a capire perché dovresti disabilitare l'accesso alla rete per gli account locali.

Quindi ecco cosa sto pensando, per favore correggimi dove sbaglio:

Supponiamo che abbia un annuncio configurato con un controller di dominio e più client. Uno dei clienti è John. Quindi al mattino John si mette al lavoro e accede al suo PC desktop con le credenziali di Active Directory. A mezzogiorno, John parte per una riunione e "blocca" il suo computer (windows + L). Ha quindi bisogno di riconnettersi al suo PC in ufficio usando il suo laptop personale da remoto (tramite RDP o qualcosa del genere). Tuttavia, usando questa nuova politica, non sarà in grado di farlo.

La spiegazione fornita da Securitay è che le password non sono salate. Tuttavia, come potrebbe ottenere un utente malintenzionato in questo caso? A che fine non viene salata la password? O la situazione che ho nella mia mente è completamente estranea a ciò che sta cercando di dire? In questo caso, cosa sta davvero cercando di dire?


Non sono sicuro di quale sia il problema descritto, ma nel tuo scenario nessuno degli account utilizzati sono account locali. Giusto?
Martijn Heemels,

4
Non per niente e senza offesa, ma perché non chiedi all'autore del post? "Someone on the internet said something. Let me ask someone else on the internet what the first person meant."
joeqwerty,

4
@joeqwerty l'autore è impegnato a esibirsi e non risponde spesso.
tedder42,

1
@joeqwerty È in tournée nel 1989, quindi è piuttosto impegnata ...
L'uomo

È davvero necessario disabilitare l'accesso alla rete per gli account locali? Non è disabilitato dall'UAC remoto per impostazione predefinita?
chris,

Risposte:


10

Consentire l'accesso alla rete per gli account locali è pericoloso e una pratica di sicurezza scadente. Per i membri del gruppo amministratori, lo caratterizzerei davvero come negligenza. Consente lo spostamento laterale ed è difficile da rilevare e controllare a causa degli accessi all'account non registrati centralmente (sui controller di dominio).

Per mitigare questa minaccia, Microsoft ha effettivamente creato due nuovi identificatori di sicurezza integrati da aggiungere al diritto utente "Nega l'accesso a questo computer dalla rete":

S-1-5-113: NT AUTHORITY\Local account  
S-1-5-114: NT AUTHORITY\Local account and member of Administrators group  

http://blogs.technet.com/b/secguide/archive/2014/09/02/blocking-remote-use-of-local-accounts.aspx

http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx


Grazie per avermi risposto. Fammi capire bene:
L'uomo

Diciamo che ho un DC (SERVER1) con RDP abilitato. Sul mio laptop personale (non connesso al dominio AD), ho lo stesso nome utente e password amministratore. Quindi, quando voglio gestire SERVER1, mi collego ad esso tramite RDP dal mio laptop personale. Tuttavia, un giorno, il mio laptop personale è stato rubato e il ladro è stato in grado di accedere al mio laptop con le autorizzazioni di amministratore. Da lì, può quindi vedere l'hash della password dell'utente locale e utilizzare lo stesso hash per connettersi al server. Questo scenario sarebbe corretto allora?
The Man

Tuttavia (se questo scenario è corretto), ciò ha sollevato più domande. Non ci sarebbe alcun rischio se avessi semplicemente usato password diverse per utenti diversi? Inoltre, come sarà abilitato l'accesso alla rete in questo caso? È solo perché l'attaccante può ottenere l'accesso e configurarlo senza avere accesso fisico?
L'uomo

2
Sì ad entrambi, ma dubito che un revisore accetterebbe di avere password diverse come controllo compensativo sufficiente per questo rischio. Avere gli account amministratore locale abilitati per l'accesso alla rete è il tipo di movimento laterale che affonda la tua corazzata quando vieni attaccato. Gli account dell'amministratore locale dovrebbero essere solo per l'accesso locale e mai sulla rete.
Greg Askew,

Giusto per chiarire alcune cose. Con entrambi, intendi che lo scenario più recente che ho suggerito è corretto, giusto? Inoltre, quanto sarebbe grave se le connessioni di rete fossero abilitate? Lo chiedo perché non riesco ancora a vedere come l'abilitazione dell'accesso alla rete consentirebbe l'accesso agli aggressori. Inoltre, se disabilito l'accesso alla rete, l'accesso fisico è l'unico modo per interfacciare / configurare il server?
The Man

3

No, lo scenario di esempio non è corretto. Se sta usando le credenziali AD per accedere, va tutto bene. Il problema riguarda gli account locali, ovvero quelli creati su, ed esistenti solo su singoli computer. Ad esempio. \ Administrator, ma questo vale per qualsiasi account nel dominio del computer (COMPUTERNAME \ USERNAME). Il rischio per la sicurezza ", AIUI, è che se gli account locali (ad esempio l'amministratore locale) condividono la stessa password su più macchine, è possibile estrarre gli hash delle password dal computer e riutilizzarli in alcuni casi (come infestazione da malware o altro utente malintenzionato) spostarsi lateralmente tra i computer.


Grazie per aver risposto. Tuttavia, puoi fare uno scenario di esempio su come la sicurezza può essere compromessa?
L'uomo

Contoso utilizza una password di amministratore locale fissa. Contoso non impedisce l'accesso alla rete per gli account locali. L'utente riceve una sorta di malware, che arriva al punto in cui viene eseguito con i diritti di amministratore. Estrae gli hash delle password. Se non sbaglio, ci sono modi per utilizzare un hash per l'autenticazione in alcune circostanze. O forse l'hash è facile da decifrare, o su un tavolo arcobaleno, o qualcosa del genere. Il malware si connette quindi a tutte le macchine e si diffonde a esse. Non solo, ma è difficile scoprire cosa sta succedendo, perché questo non viene registrato nel controller di dominio o in qualsiasi parte centrale, solo sui singoli PC.
Micha,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.