19.8 C
Firenze
sabato, Aprile 26, 2025
Home Blog Page 3038

VbScript – Attivare un Avviso sul cambio di Data di Modifica di un File

Il seguente “spezzone” di codice in linguaggio in VbScript ( Windows Script Host ) si utilizza per il monitoraggio della data di modifica di un file.
E’ estremamente semplice ed invia una e-mail al cambiamento della data di modifica (forzata nel codice)

[php]</pre>
strFile = "C:Rootwww.***.itindex.html"

SET objFSO = CREATEOBJECT("Scripting.FileSystemObject")
SET objFile = objFSO.GetFile(strFile)
‘wscript.echo "File Modified: " & CDATE( objFile.DateLastModified)
modifica = CDATE( objFile.DateLastModified)

If modifica <> "24/11/2014 16.13.06" then
Const MAIL_MODE = 2
Const MAIL_SERV = "mail.****"
Const MAIL_PORT = 25

Set objEmail = CreateObject("CDO.Message")
With objEmail
.From = "****"
.To = "****"
.Subject = "[FILE MODIFICATO]"
.Textbody = "TESTO"
.Configuration.Fields.Item("https://schemas.microsoft.com/c­do/configuration/sendusing") = MAIL_MODE
.Configuration.Fields.Item("https://schemas.microsoft.com/c­do/configuration/smtpserver") = MAIL_SERV
.Configuration.Fields.Item("https://schemas.microsoft.com/c­do/configuration/smtpserverport") = MAIL_PORT
.Configuration.Fields.Update
.Send
End With
End If
<pre>
[/php]

Altri script in VbScript che potrebbero interessarti :

[catlist id=218 numberposts=40]

Fonti : Data di Modifica di un File, Vbscript Data di Modifica di un File, Leggere Data di Modifica di un File, Alert su Data di Modifica di un File, Avviso Data di Modifica di un File, Avviso via e-mail cambiamento Data di Modifica di un File, Data di Modifica di un File

Monitoraggio ISAPI su IIS in caso di Server Compromesso (hacked)

0

current isapi extension requestsI valori di ISAPI, nel webServer sono in continuo “movimento” e sarebbe consigliabile effettuare un controllo “periodico”, specialmente se il server web fosse stato “mira” di hacker e/o in caso di applicazioni con connessioni “pesanti” a database o in utilizzo di XML parsing.

Per avere informazioni “maggiori” su ISAPI, vi rimando a questo articolo.

Se il server WEB Iis fosse stato “mira” di “hacker” è possibile che siano generate delle pagine script per catturare contenuti da fonti esterne e/o riscrivere “al volo” pagine htm/html sul server (woolrich, ecc.). Queste pagine, successivamente, saranno richiamate in modo continuo e potrebbero generare un impennata continua di ISAPI nel webserver.

Per effettuare un monitoraggio delle ISAPI a cadenze di tempo prestabilite (Operazioni Pianificate) si può utilizzare il seguente script in VBS : Controllo-Riavvio-suISAPI

Lo script è stato “creato” sulla base di questo articolo e provvederà ad inviare un messaggio e-mail quando il valore ISAPI sarà superiore a una certa soglia per un tot di secondi.
A questo punto si potrà intervenire con IISTRACER

IIS Server Compromesso, Monitoraggio Isapi, Alert isapi, Isapi hacked Server, Monitoraggio server Web Compromesso, Controllo server Web Compromesso, Monitoraggio server iis Compromesso

IIS – Come comportarsi con le estensioni Scriptmap non in utilizzo?

Uno dei più grandi “errori” dei sistemisti per WebServer Windows su IIS è sempre stato quello di “consentire” Application Extension che il “cliente” non utilizza ma che sono una vera “manna” per hacker & co. Se i vostri clienti non utilizzano Php, Asp.Net, ecc… è consigliabile rimuovere queste funzionalità dai propri Host e non “lasciarle li” a disposizione, casomai il cliente un giorno “decidesse” di utilizzarle.

Se il cliente deciderà di utilizzare nuovi linguaggi, richiederà l’ABILITAZIONE dello scriptmap solo per il proprio Host, ma fare ciò è ben diverso dal fornire una funzionalità già pre-confezionata a tutti gli utenti del server. Se un altro sito web “subisse” un accesso via FTP, il “malintenzionato” potrebbe caricare un file PHP per fare eventuali danni. Ovviamente la sicurezza sarebbe “garantita” dai corretti permessi NTFS tra le varie cartelle del disco ma ho scoperto che alcuni file in .Aspx utilizzano altri “utenti” che hanno accesso a varie cartelle di sistema.

Pertanto è consiglibile RIMUOVERE eventuali estensioni non utilizzate.

Estensioni ScriptMap Server

per maggiori informazioni potete consultare questo articolo : http://www.serverbay.it/?p=2443

Il tools SCARICABILE da qui : Remove_Scriptmap
ha bisogno del VBS “scriptmap.vbs” per funzionare, incluso (di solito) in c:inetpubAdminiscripts
Remove ScriptMap creerà un file .BAT di questo tipo :

Cscript scriptmap.vbs -n 10117 -d .aspx
REM www.youcloud.it

la riga in REM serve solo per vedere quale sito web è “legato” all’ID riportato nella riga subito superiore.
Nell’esempio proposto, scriptmap rimuove lo script mapping .aspx

Sicurezza Web Server, Sicurezza IIS Web Server, script mapping IIS, rimuovere asp.net IIS, imuovere estensione asp.net IIS, imuovere estensione script IIS, rimuovere scriptmap iis, rimuovere script tutti siti web IIS, iis rimuovere scriptmap, aspx disattivare IIS

Web Application Security – DotDefender

Web Application Firewall Un Software da “valutare” a livello di WebServer è sicuramente Web Application Security dotDefender della Applicure. Con questo Web Application Firewall ho risolto il 90% dei problemi di Hacking e Defacement  su Server Windows 2008 e 2003. Personalmente lo reputo “l’unico” componente in grado di bloccare AspXspy in quanto la soluzione proposta nell’utilizzo di UrlScan non è sempre sicura e anche l’Antivirus non riesce sempre a prevenire i problemi.

Questo Web Application Firewall si installa come ISAPI di IIS e ne monitorizza il traffico, sia entrante sia uscente.
E’ corredato di centinaia di regole per il blocco di script, Malware, ecc. ed è in perenne aggiornamento con Applicure.
Purtroppo la demo di funzionamento prevista sul sito web del produttore consente di effettuare solo un azione di “monitoraggio” e non di blocco.

Tuttavia è possibile richiedere a Applicure una licenza DEMO di 30 giorni per verificare l’effettivo funzionamento.

[catlist id=147]

IISTRACER – Attenzione alle dimensioni del file di LOG

E’ possibile che, qualche volta, si possa notare un eccessiva lentezza del server o un “accumulo” di ISAPI (Performance Monitor) veramente elevato.
Questa situazione potrebbe dipendere da un sito web che ha pubblicato qualcosa di “molto richiesto” oppure da un attacco che ha generato pagine che vengono “richiamate” continuamente (es PHP mailer, ecc.).

E’ buona regola tenere sotto “controllo” il file di LOG generato da IISTRACER.
Una dimensione eccessiva indica che il server richiede un controllo, in quanto potrebbe verificarsi una delle situazioni descritte sopra

Image2

 

Dimensione_LOG_IIStracer

ASPXspy.aspx – Lcx.Exe – Controllo Remoto del Vostro Server

In questo articolo vi racconterò l’esperienza “subita” da un nuovo Trojan per attaccare i WebServer : ASPXspy.aspx
E’ una semplice pagina ASPX e quindi eseguita da Net.Framework. E’ a suo agio con Net.Framework 4.0 e anche con alcune versioni precedenti.
Prima di capire che il problema (del nostro server) derivava da ASPXspy abbiamo impiegato un pò di tempo.
Il primo problema rilevato è stata la presenza di un altro componente LCX.EXE. Questo componente associato a ASPXspy permetteva all’utente di prendere in controllo il server con Desktop Remoto. Anche se il server era protetto da Firewall Locale e da Firewall hardware, LCX e ASPXspy “mappano” una porta locale su un sistema remoto.
Un pò come trasmettere all’esterno la porta 3389 del server. Il Malintenzionato “mappava” la porta su un’altra del proprio server (es. la 56) e poteva connettersi in quanto la “sessione” di desktop remoto era iniziata dal server (di destinazione).
Abbiamo impiegato un pò di tempo a cercare di capire e bloccare Lcx.Exe.
Il malintenzionato “portava” con se anche CMD.EXE in quanto ASPXspy consente di lanciare eseguibili (con privilegi Framework) anche in percorsi diversi.
Successivamente abbiamo rilevato files e cartelle cancellati e anche “utenti” Administrator che erano “creati” nel sistema (GetPass_cmd.exe)
Scansioni con ClamWin o Microsoft Security Essential riuscivano a identificare lo script e a rimuoverlo ma non a “prevenire” il suo inserimento in quanto sono Antivirus che non analizzano il traffico di rete. L’unico Antivirus che riesce a bloccare lo script è Symantec Endpoint in quanto dispone di un modulo per l’analisi del traffico di rete.

Alcuni SCREENSHOT di quello che può fare ASPXspy.

ASPXspy2.aspx    ASPXspy2.aspx    ASPXspy2.aspx

 

Per Bloccare questo componente la soluzione migliore è utilizzare un buon Antivirus che consenta la scansione del traffico di rete in accoppiata con URLSCAN 3.1
Il file di configurazione di Urlscan deve però essere modificato per creare una REGOLA per il blocco del componente.
E’ possibile creare una regola con questa configurazione :

RuleList=ASPXSpy

[ASPXSpy]
AppliesTo=.aspx,.asp,.php,.pl,.cgi,.py,.htm,.html,.css
DenyDataSection=ASPXSpyUrls
ScanAllRaw=0
ScanUrl=1
ScanHeaders=Cookie

[ASPXSpyUrls]
ASPXSpy=

In ALLEGATO un esempio di UrlScan.INI
UrlScan ASPXspy

Lo script è composto di righe di codice come queste :

<%@ Page Language=”C#” Debug=”true” trace=”false” validateRequest=”false” EnableViewStateMac=”false” EnableViewState=”true”%>
<%@ import Namespace=”System.IO”%>
<%@ import Namespace=”System.Diagnostics”%>
<%@ import Namespace=”System.Data”%>
<%@ import Namespace=”System.Management”%>
<%@ import Namespace=”System.Data.OleDb”%>
<%@ import Namespace=”Microsoft.Win32″%>
<%@ import Namespace=”System.Net.Sockets” %>
<%@ import Namespace=”System.Net” %>
<%@ import Namespace=”System.Runtime.InteropServices”%>
<%@ import Namespace=”System.DirectoryServices”%>
<%@ import Namespace=”System.ServiceProcess”%>
<%@ import Namespace=”System.Text.RegularExpressions”%>
<%@ Import Namespace=”System.Threading”%>
<%@ Import Namespace=”System.Data.SqlClient”%>
<%@ import Namespace=”Microsoft.VisualBasic”%>
<%@ Assembly Name=”System.DirectoryServices,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>
<%@ Assembly Name=”System.Management,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>
<%@ Assembly Name=”System.ServiceProcess,Version=2.0.0.0,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>
<%@ Assembly Name=”Microsoft.VisualBasic,Version=7.0.3300.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a”%>
…….

Guida alle Impostazioni di URLSCAN

IIS ServerLa presente guida è tratta da : https://support.microsoft.com/kb/326444/it
Fate riferimento a questa pagina per maggiori informazioni

Modificare il file URLScan. ini

La configurazione di URLScan viene eseguita tramite il file URLScan. ini, che si trova nella cartella %WINDIR%System32InetsrvURLscan. 

Nota Riavviare Internet Information Services (IIS) per le modifiche abbiano effetto. È possibile eseguire questa operazione rapidamente in un modo consiste nell’eseguire il comando IISRESET dal prompt dei comandi di. 

Il file URLScan. ini contiene le seguenti sezioni:

  • [Opzioni]: in questa sezione vengono descritte le opzioni generali URLScan.
  • [AllowVerbs] e [DenyVerbs]: in questa sezione definisce i verbi (noto anche come metodi HTTP) da URLScan.
  • [DenyHeaders]: in questa sezione sono elencate le intestazioni HTTP che non sono consentite in una richiesta HTTP.
  • [AllowExtensions] e [DenyExtensions]: in questa sezione definisce le estensioni dei nomi da URLScan.
  • [DenyURLSequences]: in questa sezione sono elencate le stringhe che non sono consentite in una richiesta HTTP.

Ogni sezione verrà descritta più dettagliatamente in questo documento.

La sezione [Options]

Nella sezione [Options] , è possibile configurare diverse opzioni di URLScan.

OptionName=OptionValue

Le opzioni disponibili e i valori predefiniti sono i seguenti:

  • UseAllowVerbs = 1
    Per impostazione predefinita, questa opzione è impostata su 1. Se questa opzione è impostata su 1, URLScan consente solo le richieste HTTP che utilizzano i verbi sono elencati nella sezione [AllowVerbs] . URLScan blocca tutte le richieste che non utilizzano tali verbi. Se questa opzione è impostata su 0, URLScan Ignora la sezione [AllowVerbs] e invece blocca solo le richieste che utilizzare i comandi elencati nella sezione [DenyVerbs] .
  • UseAllowExtensions = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 0, URLScan blocca le richieste di estensioni di file che sono elencate nella sezione [DenyExtensions] , ma consente le richieste di tutte le altre estensioni di file. Se questa opzione è impostata su 1, URLScan consente solo le richieste di file con estensioni elencate nella sezione [AllowExtensions] e blocca le richieste di tutti gli altri file.
  • NormalizeUrlBeforeScan = 1
    IIS riceve le richieste di URL codificati. Ciò significa che alcuni caratteri potrebbero essere sostituiti con un segno di percentuale (%) seguito da un numero particolare. Ad esempio, % 20 corrisponde a uno spazio, in modo che una richiesta di https://myserver/My%20Dir/My%20File.htm è lo stesso una richiesta di https://myserver/My htm esegue Dir/My. La normalizzazione è il processo di decodifica delle richieste con codifica URL. Per impostazione predefinita, questa opzione è impostata su 1. Se l’opzione NormalizeUrlBeforeScan è impostata su 1, URLScan analizza la richiesta decodificata. Se è impostata su 0, URLScan analizza invece la richiesta non decodificata. L’impostazione di questa opzione su 0 ostacola la possibilità di URLScan per bloccare determinati tipi di attacchi.
  • VerifyNormalization = 1
    Poiché il segno di percentuale (%) stesso può essere codificato in URL, un utente malintenzionato può inviare una richiesta appositamente a un server che è fondamentalmente doppia codifica. In questo caso, IIS può accettare una richiesta in caso contrario rifiuterebbe come non valido. Per impostazione predefinita, questa opzione è impostata su 1.Se l’opzione VerifyNormalization è impostata su 1, URLScan Normalizza l’URL due volte. Se l’URL dopo la normalizzazione prima è diverso dall’URL dopo la normalizzazione seconda, URLScan rifiuta la richiesta. Ciò impedisce gli attacchi che si basano sulle richieste di doppia codifica.
  • AllowHighBitCharacters = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 0, URLScan rifiuta le richieste che contengono caratteri non ASCII. Può impedire determinati tipi di attacchi, ma è inoltre possibile bloccare le richieste di determinati file legittimi, ad esempio file con nomi non in lingua inglese.
  • AllowDotInPath = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 0, URLScan rifiuta le richieste che contiene più punti (.). Impedire che i tentativi di nascondere le richieste di estensioni di file pericolosi inserendo un’estensione del nome file sicuro nella parte della stringa query o informazioni di percorso dell’URL. Ad esempio, se questa opzione è impostata su 1, URLScan potrebbe consentire una richiesta di https://servername/BadFile.exe/SafeFile.htm perché è ritenuto che una richiesta di una pagina HTML, quando è effettivamente una richiesta di un file eseguibile (.exe) con il nome di una pagina HTML nell’area di PATH_INFO. Quando questa opzione è impostata a 0, URLScan potrebbero rifiutare le richieste per le directory che contengono punti.
  • RemoveServerHeader = 0
    Per impostazione predefinita, un server Web restituisce un’intestazione che identifica il software del server Web è in esecuzione in tutte le risposte. Questa procedura può aumentare la vulnerabilità del server perché un utente malintenzionato è in grado di determinare che un server sia in esecuzione IIS e quindi attacchi noti problemi IIS, anziché tentare di attaccare un server IIS utilizzando gli attacchi da cui sono stati progettati per altri server Web. Per impostazione predefinita, questa opzione è impostata su 0. Se si imposta l’opzione RemoveServerHeader su 1, è possibile impedire il server di inviare l’intestazione che lo identifica come un server IIS. Se RemoveServerHeader è stato impostato su 0, viene comunque inviata questa intestazione.
  • AlternateServerName = (non specificato per impostazione predefinita)
    Se RemoveServerHeader è impostato su 0, è possibile specificare una stringa nell’opzione AlternateServerName per specificare ciò che verrà passato nuovamente nell’intestazione del Server. Se RemoveServerHeader è impostato su 1, questa opzione viene ignorata.
  • EnableLogging = 1
    Per impostazione predefinita, URLScan tiene un registro completo di tutte le richieste bloccate in % WINDIR%System32InetsrvURLScan. Se non si desidera mantenere questo registro, è possibile impostareEnableLogging su 0.
  • PerProcessLogging = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 1, URLScan crea un registro separato per ogni processo che ospita URLScan. Se è impostata su 0, tutti i processi di accedere allo stesso file.
  • PerDayLogging = 1
    Per impostazione predefinita, questa opzione è impostata su 1. Se questo valore è impostato su 1, URLScan crea un nuovo file registro ogni giorno. Ogni file di registro è denominato Urlscan.MMDDYY. log, dove MMDDYY rappresenta la data del file di registro. Se questo valore è impostato su 0, tutte le registrazione viene salvato nello stesso file, indipendentemente dalla data.
  • AllowLateScanning = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 0, URLScan viene eseguito come un filtro ad alta priorità, il che significa che viene eseguita prima di qualsiasi altro filtro Internet Server applicazione Programming Interface (ISAPI) installato sul server. Se questa opzione è impostata su 1, URLScan viene eseguito come un filtro a bassa priorità, in modo che altri filtri possono modificare l’URL prima che URLScan esegua le analisi. Estensioni del Server di FrontPage (FPSE) richiede questa opzione viene impostata su 1.
  • RejectResponseUrl = (non specificato per impostazione predefinita)
    Questa opzione specifica il percorso virtuale in un file che viene eseguito quando URLScan blocca una richiesta.Consente di personalizzare la risposta inviata al client per le richieste bloccate. È necessario specificareRejectResponseUrl come un percorso virtuale per il file appropriato, ad esempio /Path/To/RejectResponseHandler.asp.È possibile specificare un file URLScan blocca in genere, ad esempio una pagina di pagine ASP (ASP). È inoltre possibile utilizzare le seguenti variabili server dalla pagina:

    • HTTP_URLSCAN_STATUS_HEADER: Specifica il motivo per cui la richiesta è stata bloccata.
    • HTTP_URLSCAN_ORIGINAL_VERB: Specifica il verbo originale dalla richiesta bloccato (ad esempio, GET, POST, HEAD o DEBUG).
    • HTTP_URLSCAN_ORIGINAL_URL: consente di specificare l’URL originale della richiesta di blocco.

    Se si imposta RejectResponseUrl sul valore speciale di / ~ *, URLScan viene utilizzata la modalità di registrazione. Ciò consente a IIS di fornire tutte le richieste, ma aggiunge una voce nel Registro di URLScan per tutte le richieste che sono in genere bloccate. Ciò risulta utile se si desidera testare il file URLScan. ini.

    Se non si specifica un valore per RejectResponseUrl, URLScan viene utilizzato il valore predefinito di < respinti da UrlScan > /.

  • UseFastPathReject = 0
    Per impostazione predefinita, questa opzione è impostata su 0. Se questa opzione è impostata su 1, URLScan ignora l’impostazione RejectResponseUrl e restituisce immediatamente un messaggio di 404 errore al browser. Questo è più veloce rispetto all’elaborazione RejectResponseUrl, ma non consente tante opzioni di registrazione. Se questa opzione è impostata su 0, URLScan utilizza l’impostazione di RejectResponseUrl per elaborare la richiesta.

[AllowVerbs] e [DenyVerbs] sezioni

Le sezioni [AllowVerbs] e [DenyVerbs] definiscono i verbi HTTP (noto anche come metodi) da URLScan. I verbi HTTP comuni sono GET, POST, HEAD e PUT. Altre applicazioni, ad esempio di FPSE e Web Distributed Authoring and Versioning (WebDAV), utilizzano altri verbi.

Il [AllowVerbs] e le sezioni [DenyVerbs] hanno la stessa sintassi. Essi sono costituiti da un elenco di verbi HTTP e ogni verbo viene visualizzato sulla propria riga.

URLScan decide quale sezione da utilizzare in base al valore dell’opzione UseAllowVerbs nella sezione [Options] . Per impostazione predefinita, questa opzione è impostata su 1. Se UseAllowVerbs è impostato su 1, URLScan consente solo le richieste che utilizzano i comandi elencati nella sezione [AllowVerbs] . Una richiesta che non utilizza uno di questi verbi viene rifiutata. In questo caso, la sezione [DenyVerbs] viene ignorata.

Se UseAllowVerbs è impostato su 0, URLScan rifiuta le richieste che utilizzano i comandi elencati in modo esplicito nella sezione [DenyVerbs] . Sono consentite tutte le richieste che utilizzano i comandi che non vengono visualizzati in questa sezione. In questo caso, URLScan ignora la sezione [AllowVerbs] .

La sezione [DenyHeaders]

Quando un client richiede una pagina da un server Web, invia in genere su alcune intestazioni HTTP che contengono informazioni aggiuntive sulla richiesta. Intestazioni HTTP più comuni comprendono:

  • Host:Questa intestazione contiene il nome del server Web.
  • Accettare:Questa intestazione definisce i tipi di file che il client è in grado di gestire.
  • Agente utente:Questa intestazione contiene il nome del browser che richiede la pagina.
  • Autorizzazione:Questa intestazione definisce i metodi di autenticazione supportati dal client.

I client possono inviare altre intestazioni al server per specificare informazioni aggiuntive.

Nella sezione [DenyHeaders] , è possibile definire intestazioni HTTP URLScan respingerà. Se URLScan riceve una richiesta contenente un’intestazione che è elencata in questa sezione, respinge la richiesta. In questa sezione è costituita da un elenco di intestazioni HTTP, con le intestazioni che figurano sulla propria riga. I nomi di intestazione devono essere seguiti da due punti (:) (ad esempio, -nome dell’intestazione:).

[AllowExtensions] e [DenyExtensions] sezioni

La maggior parte dei file hanno estensione che identifica il tipo di file sono. Ad esempio, i nomi di file per Word documenti terminano in. doc, nomi di file HTML in genere terminano in htm o HTML e i nomi di file di testo normale terminano in. txt. Le sezioni [AllowExtensions] e [DenyExtensions] consentono di definire le estensioni URLScan bloccherà. Ad esempio, è possibile configurare URLScan per rifiutare le richieste per impedire agli utenti del Web di esecuzione delle applicazioni nel sistema i file .exe.

Il [AllowExtensions] e [DenyExtensions] sezioni hanno la stessa sintassi. Essi sono costituiti da un elenco di estensioni di file e ogni estensione viene visualizzato sulla propria riga. L’estensione inizia con un punto (.) (ad esempio. ext).

URLScan decide quale sezione da utilizzare in base al valore di UseAllowExtensions nella sezione [Options] . Per impostazione predefinita, questa opzione è impostata su 0. Se UseAllowExtensions è impostato su 0, URLScan Rifiuta solo le richieste per file di estensioni dei nomi elencati nella sezione [DenyExtensions] . Sono consentite tutte le estensioni di file che non sono elencate in questa sezione. La sezione [AllowExtensions] viene ignorata.

Se UseAllowExtensions è impostato su 1, URLScan rifiuta le richieste per qualsiasi file di estensioni non esplicitamente elencati nella sezione [AllowExtensions] . Sono consentite solo le richieste per un’estensione di file elencati in tale sezione. La sezione[DenyExtensions] viene ignorata.

Per ulteriori informazioni su come configurare URLScan per consentire le richieste di file che non hanno un’estensione, fare clic sul seguente numero di articolo per visualizzare l’articolo della Microsoft Knowledge Base:

312376 Come configurare URLScan per consentire richieste con estensione null in IIS

La sezione [DenyUrlSequences]

È possibile configurare URLScan per bloccare le richieste che contengono determinate sequenze di caratteri nell’URL. Ad esempio, è possibile bloccare le richieste che contengono due punti consecutivi (.), che vengono spesso utilizzati con gli attacchi che sfruttano le vulnerabilità di attraversamento di directory. Per specificare una sequenza di caratteri per bloccare, inserire la sequenza in una riga a sé stante nella sezione [DenyUrlSequences] .

Si noti che l’aggiunta di sequenze di caratteri può influire negativamente sulle Outlook Web Access (OWA) per Microsoft Exchange. Quando si apre un messaggio da OWA, la riga dell’oggetto del messaggio è contenuta nell’URL richiesto dal server.Poiché il file URLScan. ini consente di bloccare tutte le richieste che contengono il simbolo di percentuale (%) e il segno di e commerciale (&), gli utenti ricevono un messaggio di 404 errore quando si tenta di aprire un messaggio con un oggetto, ad esempio “Il fatturato aumenta del 100%” o “Bob & Luisa venute a città”. Per risolvere il problema, è possibile rimuovere queste sequenze dalla sezione [DenyUrlSequences] . Si noti che questo riduce la protezione perché consente potenzialmente dannose richieste per raggiungere il server. 

Per ulteriori informazioni, fare clic sul seguente numero di articolo per visualizzare l’articolo della Microsoft Knowledge Base:

325965 Lo strumento URLScan può causare problemi in Outlook Web Access

Esportare la Configurazione di IIS da un Server a un Altro

IIS ServerPer esportare la configurazione di IIS6 da un Server a un Server Nuovo non è possibile copiare “manualmente” i file XML contenuti in :
WINDOWSsystem32inetsrv
è necessario effettuare un EXPORT (e quindi anche un IMPORT) con uno script VBS specifico : IIsCnfg2.vbs
Potete scaricare il VBS qui (oppure in giro per la rete).

La sintassi di utilizzo è la seguente:

Lanciare il seguente comando sul server da cui si vuole ESPORTARE la configurazione.
Ovviamente, nomefile.xml, è il file in cui si andrà a effettuare il Backup.
(NOTA : il file IIsCnfg2.vbs andrà posizionato in WINDOWSsystem32inetsrv)
cscript iiscnfg.vbs /export /f nomefile.xml /d test /inherited /children /sp /LM/W3SVC

A questo punto bisogna trasportare nomefile.xml sul server di DESTINAZIONE e caricarlo con il comando.
cscript iiscnfg.vbs /import /f nomefile.xml /dp LM/W3SVC /children /inherited /merge /d test /sp /LM/W3SVC

Se ottenete l’errore “invalid signature” vuol dire che il file è corrotto, non è stato esportato correttamente o state cercando di importare il file : MetaBase.xml

Download : MIGRARE IIS altro server (UTILITY)

Esportare una Lista di Tutti gli Utenti di Windows

IIS ServerPotrebbe essere utile, in caso di ricostruzione di un server, il dover esportare una LISTA di tutti gli utenti creati (localmente) nel sistema, ovviamente senza la password.
Questo script VBS può venire in aiuto:

Set objNetwork = CreateObject(“Wscript.Network”)
strComputer = objNetwork.ComputerName
Set colAccounts = GetObject(“WinNT://” & strComputer & “”)
colAccounts.Filter = Array(“user”)
For Each objUser In colAccounts
Wscript.Echo objUser.Name
Next

Ultime dal Nostro BLog