Prestazioni e sicurezza dell'app ASP.NET MVC - mapping e moduli del gestore

Question

Ho appena letto un articolo interessante. In sostanza si dice, si dovrebbe ottimizzare IIS impostazioni per ogni applicazione in 2 modi:

1. mapping di gestore - rimuovere tutto inutilizzato per applicazione
2. moduli - rimuovere tutto inutilizzato per applicazione

Beh, sviluppo ASP.NET da un po 'di tempo, anche sul posto di lavoro, e non l'abbiamo mai fatto in ambiente di produzione afaik. Comprendo i vantaggi teorici presentati, riducendo al minimo la "superficie" dell'applicazione (sicurezza) e migliorando le prestazioni. Ma sono davvero curioso, se lo fai nella vita reale (progetti reali per i tuoi clienti, non progetti di proof-of-concept). Quali sono i lati negativi di questo (forse manutenzione?). E la domanda più importante - ne vale la pena? Ad esempio, il guadagno in termini di prestazioni è ancora visibile?

Inoltre, se si considera questa una buona pratica, si prega di presentare un modo buono e coerente (o indicarmi un tutorial), come esattamente si esegue questo processo - come si decide cosa rimanere e cosa rimuovere.

Ad esempio, qual è il set minimo ma funzionante per l'applicazione ASP.NET MVC 3, che utilizza l'autenticazione personalizzata (basata sulla sessione, non basata su autenticazione Forms, autenticazione Windows ecc.), Nessun servizio web e funzionalità simili?

EDIT

Ho trovato questo articolo: http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx

In esso, Scott Guthrie dice:

In generale è possibile ottenere alcuni molto piccoli prestazioni vince con questo approccio - anche se io probabilmente raccomandare di non farlo. Il motivo è che alcune funzionalità di ASP.NET (moduli auth, ruoli, memorizzazione nella cache, ecc.) Smetteranno di funzionare una volta rimossi i moduli da cui dipendono. Cercare di capire perché questo è successo può spesso essere fonte di confusione.

ma ancora nessuna measurments, pratiche (non sono realmente convinto da "si può essere sorpresi dopo" argomento :)

Answer 1

per ciò che è la pena, Security Best Practices for IIS 8 ha questo:

• installare solo i moduli IIS necessari.

  IIS 8 è composto da più di 40 moduli, che consentono di aggiungere moduli necessari e rimuovere tutti i moduli non necessari. Se si installa solo i moduli necessari, si riduce la superficie esposta a potenziali attacchi.

• Rimuovere periodicamente moduli e gestori non utilizzati o indesiderati.

  Cerca moduli e gestori non più utilizzati e rimuovi dall'installazione di IIS. Impegnarsi a mantenere l'area della superficie IIS il più piccola possibile.

IIS Modules Overview ha anche moduli IIS di riferimento con una sezione chiamata 'potenziali problemi quando si rimuove il modulo' per ciascun modulo. Ad esempio, se viene rimosso il modulo DefaultAuthentication:

Alcune funzionalità ASP.NET potrebbero non funzionare per le richieste anonime se la modalità di autenticazione ASP.NET è Moduli. Inoltre, l'evento DefaultAuthentication.OnAuthenticate non verrà generato.

Answer 2

Questo non risponde direttamente alla tua domanda, ma nel rispondere another question on SO, ho appena scoperto circa l'impatto delle prestazioni su MVC di avere lo URL Rewrite module turned on.

Quando si esegue la generazione URL (ad esempio tramite un metodo come Html.ActionLink) in alcuni casi i controlli MVC per vedere se il momento URL richiesto è stato riscritto dal modulo URL Rewrite. Se questo è il caso il risultato viene elaborato in modo che corrisponda correttamente all'URL richiesto dal client. L'atto di verificare se un URL è stato riscritto ha un costo non banale (perché implica il controllo delle variabili del server ). ASP.NET MVC 3 verifica se URL Rewrite è disattivato e può memorizzare nella cache questo fatto evitando così la necessità di ispezionare le variabili del server per ogni richiesta. Se URL Rewrite è attivato, MVC avrà per controllare le variabili del server, anche se non si è verificata alcuna riscrittura per una particolare richiesta , pertanto se non si utilizza Riscritto URL è necessario disattivare .

Quindi, ecco un caso anche se non si sta utilizzando un modulo, può avere un impatto sull'applicazione.

Tuttavia, a meno che non si abbiano problemi di sicurezza con specifici moduli o gestori che dovrei essere d'accordo con Scott Gu, probabilmente non lo noterete (a meno che non si gestiscano circa 1 milione di richieste al giorno o qualcosa del genere) e sarebbe meglio passare questo tempo a sintonizzare i profili della cache (database e contenuto).

Oh, e quindi in qualche modo rispondo alla tua domanda, no non lo facciamo.

Answer 3

<modules runAllManagedModulesForAllRequests="false"> 
    <!-- disable authorization section --> 
    <remove name="UrlAuthorization" /> 
    <!-- disable unused authentication schemes --> 
    <remove name="WindowsAuthentication" /> 
    <remove name="PassportAuthentication" /> 
    <!-- disable ACL file and directory check --> 
    <!-- <remove name="FileAuthorization" /> --> 
    <!-- We don't use ASP.NET Profiles --> 
    <remove name="Profile" /> 
    <!-- We don't provide any WCF service --> 
    <remove name="ServiceModel" /> 
    <!-- Remove modules not used by ASP.NET MVC + jQuery --> 
    <remove name="ScriptModule-4.0" /> 
</modules> 

Answer 4

Da un punto di vista delle prestazioni, è un'ottima pratica ottimale. Spesso però ci sono altri fattori da considerare.

1. La maggior parte delle applicazioni viene ampliata nel tempo. Se non stai utilizzando una funzione ora, potresti farlo in futuro. Quando lo fai, posso immaginare che qualcuno si dimentichi di riconfigurare le impostazioni di IIS, causando un rallentamento del tuo ambiente di produzione.

2. Gli ambienti di produzione spesso non sono nelle mani degli sviluppatori.

   a. Le persone che sono, probabilmente hanno abbastanza idee da applicare a piccole modifiche alle prestazioni.

   b. Più breve è il manuale di rilascio, meglio è. L'aggiunta di passaggi non necessari (in questo caso, banali) per i ritocchi delle prestazioni può portare a passaggi da esaminare.

Ancora una volta, dal punto di vista delle prestazioni, è un'ottima pratica ottimale. Nella mia esperienza, la maggior parte delle applicazioni non richiede questo tipo di modifiche alle prestazioni. Pertanto, gli svantaggi superano i vantaggi. Ma, come ha detto Tommy, se la tua applicazione gestisce milioni di richieste al giorno, allora ogni cosa aiuta.

Answer 5

In primo luogo, sarò onesto qui, ed essere chiaro che non ho fatto questo, ma in una occasione (più su di sotto).

Si deve considerare che da un punto di vista della sicurezza è un gioco da ragazzi. Se sai che non stai utilizzando una serie di funzioni, perché continuare a esporle?

Ora torniamo indietro nel tempo fino a settembre 2010. C'era una grave vulnerabilità: l'asp.net padding oracle. Ho alcuni post sul blog, uno su asp.net padding oracle: impact on asp.net MVC and PHP

Nota come questo potrebbe influire sul PHP anche se asp.net non è stato utilizzato attivamente.

Quindi il problema riguardava i gestori che non sono in genere utilizzati in asp.net MVC. In effetti, su alcuni server/applicazioni client che stavo gestendo al momento, abbiamo disattivato i gestori di messaggi offensivi. Vulnerabilità chiusa, prima che MS scendesse la soluzione; le applicazioni non sono state influenzate dal momento che non stavamo usando nessuno dei gestori.

Il trade off, è che non tutti i gestori sono così semplici. Può essere davvero molto difficile sapere quali gestori sono in uso in alcune applicazioni. D'altra parte, è bello sapere cosa sta succedendo con i pezzi di asp.net che stai usando.