Share di rete irraggiungibile via DNS: usare l’indirizzo IP degrada la sicurezza
Perché una scorciatoia di troubleshooting può trasformarsi in una regressione di sicurezza.
Oggi scriviamo un articolo che forse non serve.
Ma se anche una sola persona troverà qui un’informazione utile, allora si sarà già garantito una propria necessità.
Un utente segnala di non riuscire ad accedere a una share:
\\fileserver.ad.example.com\shareIl tecnico sospetta un problema DNS e fa una prova apparentemente logica:
\\10.10.20.30\shareSe tramite IP funziona, pensa, abbiamo tolto il DNS dall’equazione e ristretto il problema.
Sembra un test preciso, quasi elegante.
Tra poco vedremo che è molto meno corretto di quanto sembri.
Supponiamo che la share si apra.
A quel punto la tentazione è forte: il problema è il DNS, quindi cambiamo il collegamento dell’utente e usiamo direttamente l’IP.
Da:
\\fileserver.ad.example.com\sharea:
\\10.10.20.30\shareL’utente torna a lavorare.
Problema risolto?
No.
Il DNS è ancora guasto e, nel tentativo di aggirarlo, abbiamo cambiato qualcosa di molto più importante del percorso di rete: il modo in cui l’utente si autentica.
Il nome non serve solo a trovare il server
In Active Directory, il nome di un server non è semplicemente un’etichetta che il DNS traduce in un indirizzo IP.
Partecipa anche all’autenticazione Kerberos.
Quando il client accede a:
\\fileserver.ad.example.com\sharepuò richiedere al KDC un ticket Kerberos per uno specifico servizio, identificato da uno SPN come:
cifs/fileserver.ad.example.com
Qui “ticket” non significa richiesta di assistenza.
In Kerberos è una credenziale temporanea digitale emessa dal dominio.
Quando l’utente accede alla propria sessione, il client dimostra al KDC di conoscere il proprio segreto e riceve un primo ticket. Da quel momento può usare quel ticket per chiederne altri destinati ai servizi che deve raggiungere.
In forma molto semplificata:
utente/client → KDC → ticket per il serviziopoi:client → file server → ticket Kerberosil file server non riceve la password dell’utente e non riceve nemmeno il suo NT hash.
Sa chi è l’utente perché si fida della prova emessa dal dominio.
Quando invece sostituiamo il nome con:
\\10.10.20.30\sharenella configurazione Windows standard perdiamo il normale percorso Kerberos basato sul nome e sul relativo SPN. Se NTLM è disponibile, il client può ricadere su NTLM.
Esistono configurazioni specifiche per usare Kerberos anche verso un indirizzo IP, ma sono configurazioni esplicite. Non sono ciò che accade quando qualcuno sostituisce al volo un hostname con un IP durante un troubleshooting.
Quello che sembrava:
“tolgo il DNS dall’equazione”
può quindi diventare:
nome → Kerberoscontro:IP → NTLMEd ecco perché il test iniziale non era affatto neutro.
Se il test funziona
Torniamo a:
\\10.10.20.30\shareLa share si apre.
Abbiamo scoperto che quella risorsa è raggiungibile attraverso quell’indirizzo.
Ma per scoprirlo abbiamo già provocato un’autenticazione NTLMv2.
NTLMv2 usa uno scambio challenge-response. Il relativo materiale NetNTLMv2 può essere acquisito, nelle condizioni appropriate, e utilizzato per tentativi di cracking offline o per attacchi di relay.
Quindi la conseguenza di sicurezza esiste già durante il test.
Prima ancora di decidere se lasciare l’IP nel collegamento dell’utente.
E c’è un dettaglio tutt’altro che secondario: chi sta facendo la prova?
Spesso il tecnico.
E il tecnico può usare un account molto più privilegiato di quello dell’utente che ha aperto il ticket.
Siamo partiti da:
“la share non si risolve correttamente.”
Per verificarlo abbiamo potenzialmente generato materiale autenticativo relativo a un account amministrativo.
Se poi trasformiamo l’IP nella configurazione permanente, il problema cambia ancora scala.
La disclosure occasionale prodotta dal test diventa continuativa e ripetuta.
Ogni nuovo accesso alla share continuerà a dipendere da quel percorso di autenticazione.
Nel frattempo abbiamo anche creato una dipendenza dall’indirizzo IP, aggiunto debito tecnico e reso quella configurazione incompatibile con una futura eliminazione di NTLM.
Tutto questo lasciando intatto il problema DNS originale.
Se il test non funziona
Adesso immaginiamo lo scenario opposto.
\\10.10.20.30\sharenon si apre.
Che cosa abbiamo realmente scoperto?
Soltanto che l’accesso tramite IP è fallito.
Non sappiamo ancora perché.
Può essere un problema di rete, della porta 445, del servizio SMB, della share, delle autorizzazioni oppure dell’autenticazione.
E può semplicemente essere che NTLM sia disabilitato.
Qui il test può diventare ancora più pericoloso, perché rischia di cambiare la domanda.
All’inizio stavamo cercando di capire:
“Perché la share non funziona tramite nome?”
Adesso rischiamo di chiederci:
“Perché non funziona neanche tramite IP?”
Il tecnico approfondisce, trova una policy che blocca NTLM e conclude che quella policy impedisce il funzionamento.
A quel punto può nascere la tentazione di riabilitarlo.
riaprire a livello sistemico una superficie d’attacco già rimossa per rendere possibile un workaround locale a una share che continua ad avere un problema DNS.
La policy non era la causa del guasto.
Stava semplicemente impedendo che il workaround funzionasse degradando l’autenticazione.
Un caso apparentemente innocuo: le multifunzione
Le stampanti multifunzione rendono bene l’idea.
Quando un PC stampa direttamente verso una stampante usando una Standard TCP/IP Port, magari su RAW/9100, il percorso può essere:
PC → 10.10.30.50:9100 → stampanteQui usare l’IP può essere perfettamente normale: non stiamo accedendo a una share SMB e spesso non esiste alcuna autenticazione Windows verso il dispositivo.
Poi però usiamo la stessa macchina come scanner.
Lo scan-to-folder punta a:
\\fileserver.ad.example.com\scansioniQui la multifunzione deve autenticarsi verso una share SMB.
Se qualcuno configura invece:
\\10.10.20.30\scansionisiamo tornati esattamente nel caso precedente.
La falsa analogia è facile:
“Per stampare uso l’IP, quindi posso usarlo anche per lo scanner.”
Ma i due flussi non hanno nulla a che vedere tra loro dal punto di vista dell’autenticazione.
E infatti può succedere che, disabilitando NTLM, la stampa continui tranquillamente a funzionare mentre lo scan-to-folder configurato tramite IP smetta di funzionare.
Riabilitare NTLM per “sistemare lo scanner” sarebbe ancora una volta risolvere il problema sbagliato.
Il troubleshooting corretto parte più in basso
A questo punto la domanda torna a essere quella iniziale:
perché \\fileserver.ad.example.com\share non funziona?
E il primo controllo arriva ancora prima della query DNS.
Punto 0: quale DNS sta usando il client?
Get-DnsClientServerAddressoppure:
ipconfig /allPotremmo scoprire che il client usa 8.8.8.8.
Magari qualcuno lo aveva impostato manualmente durante un’attività temporanea e la configurazione è rimasta lì.
In quel caso la share è soltanto il primo sintomo visibile di un problema molto più ampio: quel client non sta usando il DNS interno previsto dall’ambiente.
Se la configurazione aziendale prevede DNS distribuiti via DHCP, può bastare riportare l’interfaccia alla configurazione corretta.
Fine.
Il problema “della share” era in realtà un DNS locale configurato male.
Poi verifichiamo la risoluzione
Resolve-DnsName fileserver.ad.example.comSe serve, interroghiamo direttamente uno specifico resolver:
Resolve-DnsName fileserver.ad.example.com -Server 10.10.10.10Ora sappiamo chi risponde e quale indirizzo restituisce.
Poi la rete e il servizio
Possiamo verificare l’IP:
ping 10.10.20.30tenendo presente che ICMP può essere filtrato.
Per SMB è molto più utile:
Test-NetConnection 10.10.20.30 -Port 445e confrontarlo con:
Test-NetConnection fileserver.ad.example.com -Port 445Così separiamo DNS, connettività e servizio senza autenticare nessuno alla share tramite IP.
Poi la share e i permessi
Sul file server possiamo controllare:
Get-SmbSharee:
Get-SmbShareAccess -Name NomeShareinsieme alle ACL NTFS e alle membership dell’utente.
La sequenza è semplice:
DNS del client → risoluzione → rete → TCP/445 → SMB → share → autorizzazioniCi muoviamo dal basso verso l’alto.
Ogni test risponde a una domanda.
Junior, senior e test con trade-off
Per un tecnico junior questa sequenza va seguita.
Magari alla quinta volta sembrerà noiosa, ma proprio la ripetizione costruisce un metodo di troubleshooting che vale molto oltre il caso SMB.
Un tecnico senior può avere un’intuizione.
Può pensare subito che il problema sia il DNS configurato sul client oppure un firewall e andare direttamente a verificarlo.
Ha senso.
Ma l’intuizione non giustifica un test con un trade-off di sicurezza quando esiste un test più pulito.
Resolve-DnsNameosserva la risoluzione.
Test-NetConnectionosserva la raggiungibilità della porta.
Get-SmbShareAccessosserva le permission.
Provare \\IP\share, assegnare temporaneamente Everyone: Full Control o aggiungere un SPN basato sull’IP fanno qualcosa di diverso: producono informazioni modificando contemporaneamente le condizioni del sistema.
Sono test con un costo.
Se l’intuizione del senior è corretta, benissimo: avrà risparmiato qualche passaggio.
Se non lo è, si torna in basso e si ricostruisce il percorso.
Per un junior la sequenza costruisce il metodo.
Per un senior il metodo permette di sapere dove accelerare.
In entrambi i casi, il criterio resta lo stesso:
un buon test deve produrre informazioni senza degradare la sicurezza del sistema che stiamo cercando di riparare.
