Limitare le capacita’ d’ascolto di IIS

IIS, sia nella obsoleta versione 6 che nella 7, ha un brutto vizio, quello di mettersi in ascolto su tutti gli indirizzi IP della macchina sulla quale Ŕ installato. Non ha importanza se il server abbia pi¨ schede di rete oppure diversi indirizzi IP su una sola, all'avvio del server, IIS da solo farÓ un binding su questi indirizzi per intercettare eventuali chiamate sulla porta 80, 21 o tutte quelle che avrete configurato.

Questo comportamento non Ŕ il massimo delle performance, specie se la macchina non deve offrire solo servizi web. Fortunatamente questo aspetto Ŕ configurabile tramite dei comandi impartiti da un prompt con permessi amministrativi.

Per IIS 6:

  1. net stop http /y, cosý che fermiamo tutti i servizi web senza richiesta di conferma
  2. httpcfg delete iplisten -i 0.0.0.0, cosý che cancelliamo questo binding universale
  3. httpcfg set iplisten –i , per limitare le capacitÓ di ascolto
  4. httpcfg query iplisten, per una rapida verifica
  5. net start http e iisreset, per ripristinare il normale ordine delle cose. Se la cosa non funziona, bisogna riavviare il server.

Per IIS 7 Ŕ pi¨ o meno la stessa cosa, solo che le funzionalitÓ di httpcfg.exe sono state spostate all’interno del comando netsh,

  1. netsh http add iplisten
  2. netsh http show iplisten
  3. iisreset
Technorati tags: , ,

IIS7 – Abilitare i Custom Error

Dal titolo del post dovreste aver gi├á capito tutto, ma facciamo luce per chi non ├Ę pratico di IIS. Fino ad IIS6 per abilitare i custom error era sufficiente modificare il file web.config, aggiungendo la sezione customError opportunamente modificata e il gioco era praticamente fatto.

Oggi, con IIS7 le cose sono cambiate leggermente. Dato che non tutti abilitavano i cosiddetti CustomError, spesso e volentieri ci si ritrovava con schermate d’errore prive di significato per la maggior parte degli utenti, che raramente erano volont├á implicita del developer, piuttosto una dimenticanza.

Le maschere di errore, si s├á, sono molto utili per il debug, a volte anche troppo, perch├Ę spesso contengono delle informazioni che si vorrebbero nascondere agli occhi di tutti. Ecco il motivo con il quale durante lo sviluppo di IIS7 ├Ę stata rilasciata quelli che vanno sotto il nome di IIS7 detailed errors, ovvero una nuova funzione aggiuntiva di IIS7 che permettono di mandare al browser una maschera di errore generica o una dettagliata.

Di default viene mandata quella generica, che racchiude in una forma elegante l’errore, senza per├▓ rivelare troppo, lasciando quindi che il vero errore – quello dettagliato compaia solo sul server almeno fintanto che non si vanno a modificare le impostazioni.

Infatti vi sarete accorti che, seppur avete la vostra sezione nel web.config correttamente impostata, migrando il vostro sito sotto IIS7, questa ha smetto misteriosamente di funzionare. In realt├á nulla di misterioso; ├Ę solo opera di questa nuova impostazione presente nel nuovo server web Microsoft.

Come modificare l’IIS7 detailed error per mostrare i Custom Errors.iis7-errorpages-actions.jpg

Questa caratteristica di cui ho accennato ├Ę una caratteristica modificabile per ogni singolo sito presente nel vostro IIS7. Una volta entrati nello snap-in amministrativo, cliccate su Error Pages.

iis7-errorpages-featuresettings.jpgVi verr├á mostrata la lista degli errori gestiti da IIS, tra cui il pi├╣ comune 404, gestiti con una semplice pagina statica presente di default nel vostro server. Se ponete l’attenzione sulla parte destra dello schermo (nelle Actions), troverete ad un certo punto un Edit Feature Settings.

Cliccando su questo tasto, si presenter├á questo ulteriore pannello di configurazione, riportato nell’immagine qua accanto.

Non dovete far altro che spostare il pallino dalla terza opzione – default – su Custom Error pages, ripristinando il funzionamento delle Custom Error pages cos├Č come indicato nel file web.config.

Ricordatevi che, in ogni caso, i Custom Error nel web.config, funzionano solo ed esclusivamente per le pagine con estenzione .aspx o cmq quelle gestite dal framework.
Per tutte le altre pagine, la gestione degli errori passa dentro una pipe diversa gestita direttamente da IIS e non dal framework, quindi se vi state avvicinando per la prima volta al framework e ad IIS7, non iniziate a parlare subito male di Microsoft dicendo che rilascia prodotti che non funzionano.

IIS6 ├Ę stato il server web pi├╣ sicuro di tutto il 2006-7 se non erro, e il nuovo IIS7 ├Ę il suo degno successore.

Recuperare alcune proprieta’ dal metabase di IIS

Stavo lavorando su di un sito web in Asp.net e ho avuto la necessitÓ di recuperare alcune informazioni dal metabase di IIS. Ora, mentre sul nuovo IIS7 esistono delle classi native realizzare per interrogare il file applicationHost.config, nel vecchio IIS6, questa cosa Ŕ possibile solamente utilizzando Active Directory e il protocollo IIS.

Con poche righe di codice si pu˛ interrogare il metabase di IIS6 (ma anche del 5 che spero bene sia morto e sepolto). Il sistema Ŕ ovviamente valido anche per IIS7, ma buona pratica vorrebbe che si utilizzassero le nuove classi, sicuramente pi¨ scalabili e thread safe.

Ovviamente il codice non Ŕ per nulla ottimizzato e non ci stanno controlli di errore; a me serviva qualcosa al volo per leggere e poi riutilizzare le chiamate giuste in una classe decisamente pi¨ corposa di questa.

1: using System.DirectoryServices;
2: 
3: namespace ConsoleApplication1
4: {
5:     class Program
6:     {
7:       static void Main(string[] args)
8:       {
9:          DirectoryEntry entry = new
                  DirectoryEntry("IIS://localhost/W3SVC");
10: 
11:          foreach (DirectoryEntry site in entry.Children)
12:          {
13:              Console.WriteLine(site.Name + "   " + site.Path);
14: 
15:              foreach (DirectoryEntry x in site.Children)
16:              {
17:                  Console.WriteLine("> " + x.Name + "");
18:                  Console.WriteLine("> " + x.Path + "");
19:                  Console.WriteLine("> " + x.Parent + "");
20: 
21:                  Console.WriteLine("");
22:                  Console.WriteLine("");
23:                  Console.WriteLine(" Properties list ");
24:                  Console.WriteLine("");
25:                  foreach (PropertyValueCollection v in x.Properties)
26:                  {
27:                      Console.WriteLine(" --> " + v.PropertyName + " = " + v.Value);
28:                  }
29: 
30:                  Console.WriteLine("");
31:              }
32: 
33:              Console.WriteLine(" ");
34:              Console.WriteLine(" <--------------------> ");
35:              Console.WriteLine(" ");
36:              Console.WriteLine(" ");
37:          }
38:      }
39:     }
40: }

Maggiori informazioni su come utlizzare le nuovi classi native per IIS7, le trovate qui.

Technorati tags: , ,

Debug di connessione remota ad un MS FTP Server da Mac OSX

Un paio di sabati fa ho avuto la necessitÓ di cambiare l’indirizzo IP del mio housed server verso una classe di indirizzi completamente differente. L’operazione che di per se – a parte le operazioni di cambio DNS richieste per il caso specifico – non dovrebbe comportare alcunchÚ, mi ha fatto arrovellare il cervello per una buona ora cercando di fare del debug e capire perchŔ – improvvisamente – dopo questo cambio non avevo pi¨ la possibilitÓ di scrivere file sul server remoto, ma solo di leggerli.

La cosa buffa, infatti, era proprio questa, che nonostante riuscissi a collegarmi al server FTP, nonostante il mio nome utente e password fossero corretti, nonostante mi venisse restituita la lista dei file presenti sul server, non c’era verso di scrivere niente. Ricevevo sempre un messaggio di errore di transfer incomplete senza per˛ saperne la causa.

La necessitÓ di riavere indietro un servizio funzionante non ve la sto neanche a raccontare, quindi mi sono armato di santa pazienza ed ho iniziato ad investigare.

La prima cosa a cui ho pensato Ŕ stata quella di verificare il servizio del firewall del mio Windows Server 2003. In un primo momento non gli era nemmeno piaciuto il cambio di indirizzo fatto, perchÚ addirittura abilitando o disabilitando il servizio, avevo comunque la possibilitÓ di ricevere una risposta dal server, cosa questa assolutamente anormale. Primo step, quindi, riavviare il servizio Windows Firewall (ICS). Subito dopo, le cose sono tornate apposto, quanto meno per l’aspetto servizio disabilitato – accesso negato. Per˛ continuavo a non poter scrivere file.

A questo punto ho cercato tra le righe del log files; nulla, semplicemente tante righe che mostravano il processo di autenticazione, ma nulla in merito alla scrittura. La cosa era al quanto strana. Come Ŕ possibile che non vi sia nemmeno una riga che dica accesso negato, permessi non validi e roba simile?

Prova successiva, disabilitare – temporaneamente il firewall – e vedere se tutto funziona. AhimŔ si, senza firewall ero in grado di scrivere senza problemi. Almeno avevo compreso su cosa dovevo concentrarmi.

Ripasso al setaccio tutte le impostazioni e non c’Ŕ nulla di anomalo. A questo punto tento per la strada della replicabilitÓ, ovvero, riesco a connettermi tramite un altro windows? La risposta Ŕ si, quindi c’Ŕ qualcosa che non va nella sessione che si stabilisce tra il mio client FTP per Mac – CyberDuck – e il server FTP Microsoft remoto. Ma cosa? Cyberduck nella sua session log non mostra errori. Provo allora ad utilizzare il Terminal per vedere se ottengo delle informazioni in pi¨, ed effettivamente ottengo questo:

ftp> put bookmarks.html
local: bookmarks.html remote: bookmarks.html
500 'EPSV': command not understood
421 Service not available, remote server has closed connection.

Problema trovato: non riesco pi¨ a collegarmi in modalitÓ passiva, infatti tentando di nuovo una connessione passiva con un client windows (che di default, invece, si imposta su attiva) ottenevo il medesimo problema.

Il codice di errore evidenziato – 500 e EPSV – sono per il relativo comando che viene utilizzato dal client per modificare il tipo di connessione da Attiva – default – a passiva (Quando in sostanza vedete scritto tipo di connessione automatica, sappiate che questo Ŕ quello che succede).

ModalitÓ quest’ultima implementata per una risoluzione di molte problematiche celate dietro l’uso congiunto del servizio firewall assieme a quello FTP. Per chiarimenti sulla connessione attiva e passiva, consiglio questo documento in inglese.

Infatti, modificando le impostazioni del client, forzandolo quindi ad una connessione attiva, ed effettivamente tutto funziona.

A questo punto configurare nuovamente il server FTP di Microsoft per la modalitÓ passiva e tutto torna a funzionare. Come? Si pu˛ seguire questa KB della Microsoft per impostare il range di porte che si vogliono far utilizzare al servizio FTP, ma ovviamente il tutto NON BASTA, perchŔ sul documento non si fa minimo accenno al fatto che bisogna forzare la mano al firewall indicandogli che non deve pi¨ accettare connessioni sulla porta 21 come di default.

Come fare? Passo passo:

Si deve aprire la finestra di configurazione del Firewall, quindi andare sulle proprietÓ avanzate, selezionare le proprietÓ dell’adattatore di rete locale, entrare nelle proprietÓ e disabilitare il servizio di FTP Server. Sembra un controsenso lo s˛, ma fidatevi!

A questo punto andate nella schermata delle eccezioni, scegliete aggiungi servizio, fate sfoglia e puntate il percorso su C:\Windows\system32\intesrv e selezionate il file InetInfo.exe che altro non Ŕ che l’IIS Admin Service.

Fatto questo riavviate la macchina e vedrete che sarete in grado di connettervi in modalitÓ passiva al vostro server FTP Microsoft.

Alle volte sono cose che capitano, ma se non altro, tra le varie analisi, purtroppo ho trovato nei log alcuni tentativi di accesso non desiderato. Qualcuno che ha tentato di farmi del (in)sano home-defacing?

Technorati tags: , ,