24.4 C
Firenze
domenica, Agosto 17, 2025
Home Blog Page 3442

Quale ANTIVIRUS installare su un Server?

Andrea C.
-
0

In questo articolo voglio “sintetizzare” alcuni punti chiave della protezione Antivirus su SERVER Windows 2003 o Windows 2008. Per quanto possa sembrare “esosa” in termini di risorse (elaborazione, ram, ecc.) la protezione Antivirus è molto importante, specialmente su server WEB che sono sottoposti (spesso) a attacchi con script ASP o PHP.
Solitamente la scelta della protezione antivirus è un parametro che si tende a tralasciare, concentrandosi su altre soluzioni (es. urlscan, packet Inspection Firewall, ecc.)

Per quanto sia possibile installare molti antivirus “Home Edition” su un Server (es. Clamwin o addirittura Microsoft Security Essential) questi prodotti sono vivamente sconsigliati e pressochè inutili. E’ vero che queste protezioni analizzano anche script e li rimuovono, ma questo avviene solo quando viene INVOCATA manualmente ( o programmata) una scansione; quando l’antivirus “passa” sopra al file, lo riconosce e lo quarantena….ma finchè questo non avviene il file è libero di agire indisturbato.

Molti worm script ASP o PHP sono caricati attraverso FTP con password semplici o addirittura attraverso moduli di UPLOAD caricati nel sito web stesso.
In questi casi gli Antivirus che abbiamo definito “Home Edition” non sono in grado di intercettare il problema.

E’ da preferirsi invece una SUITE che integra anche un controllo del Traffico di Rete.
Non voglio “pubblicizzare” prodotti….ma Symantec Endpoint potrebbe essere un buon candidato, in quanto con la sua protezione a livello di RETE riesce a intercettare eventuali malware prima del loro ingresso.

Quale Antivirus per Server

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

Andrea C.
-
0

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”%>
…….

Bloccare Tutti gli IP di uno specifico paese su IIS 6.0

Andrea C.
-
0

Su IIS 6.0 è possibile bloccare determinati indirizzi IP (singoli o gruppi) con un semplice intervento nella sezione directory Security

IIS Directory Security

Ma come fare se è necessario bloccare un intero paese o centinaia di “gruppi di Ip” perchè siamo sotto una situazione di attacco?
Con IIS già “avviato” e quindi con siti web già in produzione sarà necessario utilizzare uno SCRIPT vbs perchè la restrizione dovrà essere fatta per ogni singolo sito web.
Questo potrebbe avere anche un suo lato “utile” in quanto se un cliente avesse un sito web da “mostrare” a quel paese sarà possibile “aprire” il blocco solo per lui.

Innanzi tutto è necessario reperire tutte le classi IP da bloccare.
Dobbiamo creare un file che per comodità chiameremo “iisrestriction.txt”
Dentro a questo file, gli indirizzi saranno dichiarati in questo modo:
(gli indirizzi utilizzati per l’esempio sono puramente casuali)

1.0.1.0, 255.255.255.0
1.0.2.0, 255.255.254.0
1.0.8.0, 255.255.248.0
1.0.32.0, 255.255.224.0
1.1.0.0, 255.255.255.0
..ecc.

Una volta salvato il file possiamo utilizzare lo SCRIPT allegato a questa pagina (proveniente da IISFAQ.com)
SetIPRestrictionsFromFile

Questo script dovrà essere eseguito con  una sintassi del tipo:

cscript SetIPRestrictionsFromFile.vbs -n 1 -f “C:Lockiisrestrictions.txt

dove -n 1 indica l’ID del sito web su cui andremo ad intervenire.
E’ ovvio che per bloccare molti siti web avremo bisogno di un .BAT fatto in questo modo (esempio):

cscript SetIPRestrictionsFromFile.vbs -n 1798 -f “C:Lockiisrestrictions.txt”
cscript SetIPRestrictionsFromFile.vbs -n 1799 -f “C:Lockiisrestrictions.txt”
cscript SetIPRestrictionsFromFile.vbs -n 18 -f “C:Lockiisrestrictions.txt”
cscript SetIPRestrictionsFromFile.vbs -n 18041 -f “C:Lockiisrestrictions.txt”

quindi dobbiamo prima ESTRARRE TUTTI GLI ID di tutti i siti web.
Per fare questo si può MODIFICARE questo script che ALLEGO. (mostra-ROOT)
Se eseguito senza alcuna MODIFICA creerà un file c:xportdb.txt con NOME – ID – CARTELLA

 

 

 

Guida alle Impostazioni di URLSCAN

Andrea C.
-
0

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

Andrea C.
-
0

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

Andrea C.
-
0

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

Rendere Sicuro un Server Web Windows

Andrea C.
-
0

WebServer Sicuro da hackerSe questo articolo fosse “PERFETTO” … la vita per hacker & malintenzionati sarebbe durissima.
Purtroppo queste persone (o sistemi) sono in continua evoluzione e in continuo apprendimento. E’ difficile “difendersi” da ultimi BUG o Vulnerabilità, ma molti “attacchi” arrivano con sistemi “conosciuti” o da principianti che spesso sfruttano sempre le stesse vulnerabilità (od i soliti componenti del sistema attaccati da worm e script kiddie)
La guida riportata di seguito è una BLINDATURA veramente “DURA” per un WebServer. Con questa “blindatura” alcuni componenti utilizzati dai clienti (es. php su Windows come CGI, ecc.) potrebbero non funzionare correttamente quindi vi invito a SCEGLIERE eventuali PUNTI da mettere in sicurezza….in base al servizio erogato.

1.) Verificare che gli Aggiornamenti automatici sono impostati per installarsi automaticamente . Questa utility è incorporato in Windows e tiene informati degli aggiornamenti critici e service pack. La maggior parte degli attacchi hacker mira le macchine che non hanno gli ultimi Service Pack e aggiornamenti installati su di esse.

2) Correggere i PERMESSI a soli SYSTEM e ADMINISTRATOR dei seguenti file: ftp.exe , tftp.exe , command.com , cmd.exe , Telnet.exe , wscript.exe e cscript.exe . Indipendentemente dal meccanismo che un hacker utilizza per entrare nel vostro server, l’obiettivo è lo stesso: eseguire il codice sulla vostra macchina. I programmi di cui sopra possono essere utilizzati dagli hacker per installare il software e anche eseguire codice.  Non è consigliabile eliminare o rinominare uno di questi file. Windows include una funzionalità denominata “Windows File Protection”, che sostituirà automaticamente alcuni di questi file (ad esempio cmd.exe) se vengono eliminati o rinominati. Se è necessario accedere a uno di questi programmi, si consiglia di effettuare una copia di del programma con un nome diverso (ad esempio “cmdsafe.exe” o “ftp99.exe”) – non dimenticare di aggiornare tutti i collegamenti a questi file. In questo modo, l’hacker non sarà probabilmente in grado di trovarlo.

3.) Rinominare l’account Administrator e disabilitare l’account Guest.
Per impostazione predefinita, Windows crea due account che molti hacker cercano sul vostro server, “Guest” e “Administrator”. Se la vostra macchina è un membro di un dominio, sarà necessario farlo due volte: una volta sul vostro computer, e una volta in Active Directory.

4) Utilizzare 1 account = 1 Cartella : Sarà necessario Impostare 1 Account (locale o Active Directory) per ogni SITO WEB che andremo a creare. Vedremo in un altro articolo come fare. Ricordate che l’utente deve essere creato nel sistema, assegnato alla cartella e Assegnato a IIS

5) Controllo dei file di LOG di IIS . E’ consigliabile abilitare la registrazione di IIS su tutti i siti. Si dovrebbe controllare periodicamente questi file di registro per verificare i tentativi degli hacker. In particolare, la ricerca di questi file per le pagine fallite (ad esempio 404) richieste, e anche per le seguenti parole: echo, copy, rename, dir, del, cmd.exe, command.com, tftp.exe, ftp.exe, e in generale, qualsiasi. exe,. com,. bat o altra estensione di file che gli utenti Web non dovrebbero usare. I file di log di IIS includeranno anche l’indirizzo IP dell’attaccante.

6)Visualizzatore eventi – Sicurezza Log ( disponibile nel menu Programmi, Strumenti di amministrazione) viene fornito con uno strumento chiamato Event Viewer. Questo strumento registra Applicazione, Sistema e Sicurezza Eventi.  E’ molto importante rivedere periodicamente il registro di protezione. Si consiglia vivamente che il backup di tutti i file di log e di impostare registri eventi per “Non sovrascrivere eventi (pulizia manuale del registro)”.

7) Configurazione del server IIS
a.) Togliere estensioni di FrontPage. Ci sono una serie di exploit contro FrontPage. Si raccomanda vivamente di rimuovere questo componente
b.) Rimuovere Connessione Web desktop remoto (tsweb). Per impostazione predefinita, alcune versioni di di IIS includono un sito web che permette di amministrare il computer che ospita IIS.
c.) Togliere Mapping applicazioni inutilizzate dal Web Server. IIS include una serie di “mapping di applicazioni”, che invocano vari programmi quando una pagina web con una determinata estensione di file (ad es. asp o. pl) viene richiamata. Anche se non si dispone di un file (nel vostro sito web) con una di queste estensioni, il server potrebbe essere ancora vulnerabile ad un exploit contro uno di questi tipi di file. Ci sono molti exploit contro varie Mapping applicazioni. Si raccomanda vivamente di rimuovere tutti i mapping delle applicazioni non utilizzate.

8) Configurazione Sito
a.) Disattivare il “Sito Web predefinito” e cancellare tutti i file. Gli hacker cercano questa configurazione. Crea il tuo sito web, e non metterlo in c: inetpub wwwroot.
b.) Disattivare “Indicizza questa risorsa” a tutti i siti web. Se si desidera creare un “Cerca nel sito” per il vostro sito web, utilizzare uno strumento 3rd party che non indicizza il codice sorgente del tuo script lato server.
c.) Disattivare “browsing Directory” su tutti i siti e directory virtuali. Non permettere agli hacker di “navigare” tra i file.
d.) Eliminare i “AdminScripts”, “IISSamples” e “Script” directory. Gli hacker sanno di queste directory di default, e so di molti exploit contro i file che vengono installati in queste directory in un’installazione predefinita di IIS. Sbarazzarsi di queste directory, e mai nominare le directory con questi nomi.
e.) Rimuovere qualsiasi directory di FrontPage residui. Frontpage installa una serie di directory che iniziano con il carattere “_” (es._vti_cnf). Eliminare tutti questi file e directory, e di sbarazzarsi di qualsiasi file o directory che il vostro sito non utilizza.
f.) Assicurarsi che nessuno dei vostri siti web hanno l’autorizzazione “Write” acceso.

9) Controllare tutte le porte TCP / IP aperte. In primo luogo, verificare quali porte la macchina deve utilizzare, e capire quali servizi le porte mappano. Per i primi, è possibile utilizzare “netstat-an” da un prompt di DOS. Installare ed eseguire InternetPeriscope sul vostro server per questo primo test. Successivamente, eseguire una scansione delle porte sul server da un computer che si trova all’esterno del firewall. Ancora una volta, InternetPeriscope può aiutare in questo. Questo vi darà un’idea di ciò che porti vedere il dell’hacker quando la scansione del sistema. Se vedete i servizi sulla vostra macchina che non ti servono, si dovrebbero rimuovere per “indurire” la sicurezza del server.

 

Could not use global.asa file already in use

Andrea C.
-
0

ASP Global AsaE’ possibile che si possa ricevere un errore di questo tipo sul file global.asa

Microsoft JET Database Engine error ‘80004005’
Could not use ”; file already in use.
/LM/w3svc/18099/Root/global.asa, line 7

prima di analizzare il codice alla linea indicata dall’errore, vi consiglio di controllare i permessi NTFS sulla cartella del sito web.
Solitamente questo errore è un problema di permessi

Operation not Allowed AspSmartUPLOAD ‘ASP 0104 : 80004005’

Andrea C.
-
0

Su Windows 2003 la Asp Smart UPLOAD DLL subisce una limitazione di IIS che è impostato a 200k.
Per aumentare il limite bisogna agire sul file metabase.xml
Per farlo, bisogna fermare IIS (net stop w3svc)
Andare a trovare il file in :
c:WindowsSystem32Inetsrvmetabase.xml

AspSmartUploadLa riga da cercare e ritoccare è : AspMaxRequestEntityAllowed
bisogna cambiarla in 1073741824 che è almeno 1 Giga.

Per ri-salvare vi potrebbe servire UNLOCKER anche se IIS è fermo perchè il file rimane appeso.

Riavviare IIS.
Se proprio non potete stoppare IIS (per ragioni vostre) fate così : tasto opposto sul nodo centrale di IIS (local computer) e andate su proprietà.
Attivare “Enable DIrect metabase EDIT”

per i “magnacci” della riga di comando si può fare anche così :

iisreset /stop
cd c:
cd c:inetpubAdminScripts
cscript adsutil.vbs set /w3svc/AspMaxRequestEntityAllowed 104857600
iisreset /start

AspMaxRequestEntityAllowed IIS 7, Limite massimo Corpo Entità Richieste, Limite Upload Iis 7.0, Limite Upload File IIS Windows 2008, IIS modificare limite Upload, iis upload, upload iis, max upload, max upload iis

1...3.4413.4423.443...3.460Page 3.442 of 3.460

Ultime dal Nostro BLog

Il presente sito non è collegato in alcun modo, direttamente o indirettamente, alle Fonti delle notizie segnalate né può essere ritenuto responsabile ad alcun titolo dei loro contenuti. Si precisa altresì che le notizie segnalate dall’aggregatore NON sono da intendersi in alcun modo di proprietà del sito GenSys.it, ad eccezione degli articoli e dei documenti pubblicati nel blog.

Contact us: info@gensys.it

© Copyright 2022 - Serverbay.it - Eteon.it