La disabilitazione dell'accesso anonimo in IIS crea un rischio per la sicurezza?

Question

Se I deseleziona la casella di controllo "Abilita accesso anonimo" in IIS, in modo da proteggere con password un sito, ad esempio limitando l'accesso in lettura agli account Windows designati, esegue il dialogo con password risultante che viene quindi presentato a tutte le richieste HTTP anonime, rappresentano un rischio per la sicurezza in quanto (apparentemente) offre tutti quanti un numero illimitato di tentativi di indovinare con qualsiasi password dell'account Windows?

MODIFICA: OK, non c'è molta gioia con questo finora, quindi mi sto allegando una taglia. Solo 50 punti, mi dispiace, sono un uomo dai mezzi modesti. Per chiarire che cosa sto cercando: la disabilitazione dell'accesso anonimo in IIS offre un'opportunità di indovinare la password al pubblico che non esisteva in precedenza, o è il caso in cui il dialogo delle credenziali dell'utente del browser può essere simulato includendo un nome utente e una password in un richiesta http direttamente, e che la risposta indicherebbe se la combinazione fosse corretta anche se la pagina era aperta agli utenti anonimi in ogni caso? Inoltre, i tentativi di password errati inviati tramite http soggetti allo stesso criterio di blocco vengono applicati per gli accessi interni e, in caso affermativo, rappresentano un'opportunità molto semplice per bloccare deliberatamente i nomi utente conosciuti o, in alternativa, se c'è qualcosa che può essere fatto per mitigare questa possibilità illimitata di indovinare la password?

Answer 1

Quando si sceglie un'autenticazione diversa da Anonimo, è possibile essere soggetti a violazione della password. Tuttavia, l'account utilizzato è soggetto alle politiche di blocco degli account standard impostate in Criteri di sicurezza locali e nella politica di sicurezza del dominio.

Ad esempio, se si dispone di un account locale "FRED" e il criterio di blocco dell'account è impostato su 5 tentativi non validi entro 30 minuti, ciò impedisce efficacemente l'individuazione della password dell'account, a rischio di un attacco denial of service. Tuttavia, l'impostazione della finestra di ripristino su un valore (15 minuti?) Limita effettivamente il DOS.

• L'autenticazione di base non è consigliata per una connessione non SSL poiché la password verrà eseguita in testo normale.

• Digest Autenticazione richiede che le password vengano memorizzate sul server utilizzando una crittografia reversibile, quindi, mentre meglio di Basic, Digest ha i suoi difetti.

• L'autenticazione integrata di Windows include NTLM e Kerberos.

  • il server IIS deve essere configurato tramite Criteri di gruppo o le impostazioni di protezione locale per disabilitare l'autenticazione LM (Protezione di rete: livello di autenticazione LAN Manager impostato su "Invia solo risposta NTLMv2" o superiore, preferita è "Invia solo risposta NTLMv2 \ rifiutare LM & NTLM ") per impedire il banale cracking di LM di hash e per prevenire l'attacco di NTLM man nel proxy centrale.

  • Kerberos può essere utilizzato, tuttavia funziona solo se entrambe le macchine sono membri dello stesso dominio e le DC possono essere raggiunte. Poiché questo non si verifica in genere su Internet, è possibile ignorare Kerberos.

Così il risultato finale è, sì, disabilitando anonimo fa si aprirà per la password di cracking tentativi e gli attacchi DOS, ma questi possono essere prevenuti e mitigati.

Answer 2

È necessario leggere i meccanismi di autenticazione differnet disponibili: Base, Digest, NTLM, Certificati, ecc. IETF compiled a document che suddivide i pro e i contro di alcuni di questi (NTLM è un protocollo MS propiziatorio).

La linea di fondo è: non hai finito con la disattivazione di accesso anonimo. Devi assolutamente considerare attentamente quali sono gli scenari di attacco, quale potrebbe essere il potenziale danno, quale utente può essere disposto ad accettare e così via.

Se si introduce l'autorizzazione, è necessario affrontare il rischio di compromissione delle credenziali. Dovresti anche pensare se ciò che vuoi effettivamente ottenere è il trasporto confidenziale del contenuto: in questo caso dovrai istruire la sicurezza del livello di trasporto come SSL.

Answer 3

La risposta breve alla tua domanda è sì. Ogni volta che si fornisce accesso remoto a qualsiasi risorsa sulla rete presenta un rischio per la sicurezza. La soluzione migliore è seguire lo IIS best practices e prendere quindi alcune precauzioni. Rename your built in administrator account. Applicare criteri di password forte. Change the server header. La rimozione dell'accesso anonimo, mentre il rischio di indovinare la password, è molto gestibile se utilizzata con il modello di sicurezza a livelli appropriato.

Answer 4

I am by know significa un guru di hosting e immagino ci siano modi e mezzi per farlo, ma la mia opinione personale è che ciò che si sta parlando di fare è provocatoriamente un rischio di sicurezza non necessario. Se questo sito deve essere disponibile su Internet e avrà accesso pubblico, probabilmente non si desidera disabilitare l'accesso anonimo in IIS.

Si ricorda che l'idea di poter configurare l'accesso anonimo per un sito in IIS è in modo tale che sia possibile creare un utente che abbia un'autorizzazione specifica per leggere i file rilevanti per un determinato sito. Quello di cui stiamo parlando qui è l'accesso ai file su un disco fisico. Per prima cosa un server web pubblico dovrebbe essere in una DMZ e non far parte del dominio della tua azienda, quindi gli utenti non dovrebbero essere in grado di accedere con le loro credenziali di dominio.

L'unico motivo per cui posso immaginare di voler disattivare l'accesso anonimo e costringere gli utenti a immettere le proprie credenziali di Windows è per un sito che verrà utilizzato solo internamente e anche in questo caso probabilmente non sceglierei di limitare l'accesso in in questo modo

Se si desidera limitare l'accesso ai contenuti di un sito Web pubblico, è preferibile scrivere qualcosa che gestisca l'autenticazione come parte del sito stesso o un servizio che il sito può utilizzare. Quindi se qualcuno dovesse ottenere le credenziali dell'utente, almeno tutto ciò che sarà in grado di fare è ottenere l'accesso al sito e non vi è alcun potenziale per una violazione della rete interna con qualsiasi mezzo.

C'è un motivo per cui gli sviluppatori dedicano molto tempo a scrivere soluzioni di gestione degli utenti. Troverai molti consigli su come scrivere qualcosa come questo e molte librerie che faranno la maggior parte del lavoro per te.