Security

Windows Server 2003 ed errore durante l'avvio di eseguibili da Share di rete

Ermanno Goletto — Fri, 30 May 2008 17:44:27 GMT

Per impostazione predefinita in Windows Server 2003 è abilitata la Protezione avanzata di Internet Explorer ciò causa il seguente errore se provate ad avviare eseguibili, setup etc da una share di rete anche se sulla stessa avete tutti diritti necessari:
Impossibile accedere alla periferica, al percorso o al file specificato. E' probabile che non si disponga delle autorizzazioni necessarie.

Le possibili sluzioni sono:

Aggiungere il o i server su cui risiedono le share nell'eleco dei siti Intranet Locale.
Se l'utente appartiene ad un grupoo amministrativo disabilitare la Protezione avanzata di Internet Explorer per gruppi Amministrativi.
Disinstallare la Protezione avanzata di Internet Explorer

E' possibile disinstallare la Protezione avanzata di Internet Explorer o modificarle le impostazioni tramite:
Panello di controllo -> Installazioni applicazioni -> Installazioni componenti di Windows -> Protezione avanzata di Internet Explorer

Per ulteriori informazioni si veda Diversa esplorazione con il browser in seguito all'impostazione della protezione avanzata di Internet Explorer e in particolare:

"La protezione avanzata di Internet Explorer impone delle limitazioni anche all'accesso a script, file eseguibili e altri file potenzialmente non sicuri su un percorso UNC, a meno che tale percorso non sia stato aggiunto esplicitamente all'area Intranet locale. Ad esempio, se si desidera accedere a \\server\share\setup.exe, sarà necessario aggiungere \\server all'area Intranet locale. "

il certificato autofirmato di Exchange 2007

Ermanno Goletto — Wed, 05 Mar 2008 13:12:42 GMT

Durante l'installazione del ruole Client Acces di Exchange 2007 viene creato un certificato autofirmato che ha lo scopo di garatire un metodo temporaneo per criptare le comunicazioni client fino a che non viene installato un certificato alternativo. Il certificato autofirmato ha due Subject Alternative Name: uno per il nome NetBIOS e uno per il FQDN del server Client Access. Non è raccomandabile usare tale certificato con applicazioni client e dispositivi, ma è preferibile usare un certificato di terze parti o un certificato firmato da un CA interna Windows PKI.

Il certificato autofirmato ha le seguenti limitazioni:

Ha una durata di 12 mesi e alla scadenza va rinnovato tramite il cmdlet New-ExchangeCertificate.
Non può essere utilizzato con Outlook Anywhere.
Non può criptare le comunicazioni tra dispositivi Microsoft Exchange ActiveSync e Exchange server.
Gli utenti Microsoft Outlook Web Access riceveranno l'avviso che il certificato non è attendibile in quanto non è firmato da un'autorità riconosciuta dal client come attendibile. E' possibile ignorare l'avviso e utilizzare il certificato.
Il certificato predefinito ha la chiave privata contrassegnata come non esportabile quindi non è possibile utilizzarla per pubblicare Exchange 2007 tramite una Exchange Web Client Access Publishing Rule di ISA Server 2006. E' possibile clonare il certificato creandone un nuovo con la chiave privata esportabile.

Per clonare o rinnovare il certificato auto firmato è possibile utilizzare la seguente procedura

Ottenere il Thumbprint (xxx) del certificato tramite il seguente cmdlet:
CodeGet-ExchangeCertificate -DomainName ServerName.DomainName.Ext |fl
Clonare il certificato tramite il seguente cmdlet:
Get-ExchangeCertificate -thumbprint xxx | New-ExchangeCertificate
- Confermare con S la sovrascrittura del SMTP esistente.
- Viene visualizzato il Thumbprint (yyy) del nuovo certificato.
- Nel caso si intenda creare un certificato con chiave privata esportabile utilizzare il seguente cmdlet:
  Get-ExchangeCertificate -thumbprint xxx | New-ExchangeCertificate -PrivateKeyExportable $true
Visualizzare il nuovo certificato tramite il seguente cmdlet:
CodeGet-ExchangeCertificate -thumbprint yyy |fl
- Il nuovo certificato sarà abilitato solo per IMAP, POP, SMTP e non per IIS
Abilitare il nuovo certificato per IIS tramite il seguente cmdlet:
Enable-ExchangeCertificate -thumbprint yyy -services IIS
Verificare che il nuovo certificato sia abilitato anche per IIS tramite il seguente cmdlet:
CodeGet-ExchangeCertificate -thumbprint yyy |fl
Controllare la funzionalità dei servizi con il nuovo certificato.
Eliminare il vecchio certificato tramite il seguente cmdlet:
Remove-ExchangeCertificate -thumbprint xxx
- Confermare con S la rimozione del certificato.

Sebbene la clonazione permetta di continuare ad utilizzare il certificato autofirmato il consiglio è di usarlo solo temporaeamente o in ambienti di test tenendo conto che come detto prima vi sono funzionalità non possono funzionare utilizzando questo certificato.

Pubblicato articolo Configurazione VPN per accesso remoto con ISA2006

Ermanno Goletto — Wed, 23 Jan 2008 13:59:53 GMT

Oggi è stato publicato su Sysadmin.it il mio articolo Configurazione VPN per accesso remoto con ISA2006.

ISA Server 2006 e eMule

Ermanno Goletto — Fri, 28 Dec 2007 22:43:01 GMT

Immagino che a molti sarà capitato di installare un firewall dal cliente e dopo aver finito le configurazioni per mettere in massima sicureza il sistema sentirsi chiedere di avere la possibilità di usare eMule.

Ovviamente tutti gistamente cerchiamo di evitare questo tipo di configurazioni sia perchè c'è ben poco da scaricare che non violi il diritto d'autore sia perchè è innegabile che il P2P costituisca un varco nella sicurezza, secondo me, non giustificabile in una rete aziendale. Se però la richiesta arriva da un titolare che magari se non lo facciamo tanto chiama un amico smanettone che nel giro di pochi secondi invaliderà tutte le nostre configurazioni di sicurezza allora tanto vale dargli il contentino ovviamente dopo avergli snocciolato tutti i rischi legali e di sicurezza che sia chiaro dovrà accollarsi.

Se non altro se lo facciamo noi almeno possiamo almeno predisporre una macchina virtuale fuori dominio in cui far girare eMule e configurare ISA per consentire il traffico solo ad essa con il minimo di porte aperte per accedere alle reti ED2K e Kad.

Se portroppo vi trovate in questa spiacevole situazione qui trovate un'indicazione su come configurare ISA 2006 che comunque può pure essere utilizzata alla rovescia per bloccare il traffico se una regola troppo permissiva lo ha consentito:
http://xoomer.alice.it/ermannogoletto/Articles/IT/ISA2006-eMule/index.htm.

Impossibile accedere alle condivisioni di un computer con XP

Ermanno Goletto — Tue, 11 Dec 2007 12:43:22 GMT

Innanzitutto va detto che questa problematica può dipendere da molti fattori e di solito la causa è quasi sempre un codice malevolo che disabilitato servizi o modificato chiavi di registry.
Nel mio caso nonostante su un computer venissero create delle condivisioni con full control al gruppo Everyone gli altri computer all'atto dell'acesso al computer tramite \\nomepc ricevevano un errore che indicava l'impossibilta di accedere al PC.
Il motivo era l'errato configurazione di una policy locale. Per accedere alle policy locali autenticarsi al computer con un account che abbia i privilegi di amministratore locale ed eseguire gpedit.msc.

La policy incrimita è la seguente:
Criteri Computer locale\Configurazione computer\Impostazione di Windows\Impostazione protezione\Criteri locali\Assegnazione diritti utente\Accedi dalla rete al computer specificato.

Per default dovrebbero poter accedere i seguenti gruppi/utenti: Everyone, Administrators, Users, Power Users, Backup Operators. In particolare è importante per questo tipo di problema che siano presenti Everyone e Administrators.

Per ulteriori informazioni si vedano i seguenti:

Messaggio di errore: Impossibile accedere a: \\nomecomputer
http://support.microsoft.com/kb/555915/it
Descrizione della condivisione di file e delle autorizzazioni in Windows XP
http://support.microsoft.com/kb/304040/it

Matching delle Firewall Access Rule di ISA Server

Ermanno Goletto — Sat, 08 Dec 2007 01:11:27 GMT

Il matching delle Firewall Access Rule di ISA Server a volte non è proprio intuitivo come ci si aspetterebbe (o forse solo come mi aspetterei).
Innanzitutto va detto una Firewall Access Rule viene presa in considerazione se soddisfa i seguenti elementi nel segunete ordine:

Protocol
From (source)
Schedule
To (destination)
Users
Content groups

Vi sono però delle particolarità una in particolare riguarda l'elemento Users: se una rule che richiede autenticazione processa una richiesta anonima questa richiesta verrà negata anche se è una Allow rule.

Ciò significa che è importatre l'ordine delle rule si cosiderino per esempio queste rule:
#1 HTTP - Internal - Always - External - All Auth Users - All - Allow
#2 HTTP - Internal - Always - URLs - All Users - All - Allow

In questo caso la rule #1 blocca tutte le richeste anonime (client su cui ISA è definito come gateway) per HTTP. Per fare in modo che le richieste anonime siano accettate verso le URLs consentite occorre invertire le rule.

Per maggiori informazioni si veda l' articolo Understanding the ISA 2004 Access Rule Processing in cui è disponibile il seguente schema che mostra il flusso con cui viene gestito il Matching delle Firewall Access Rule.

Exchange e Realtime Blackhole Lists (RBL) Conservative

Ermanno Goletto — Fri, 30 Nov 2007 12:02:33 GMT

A partire da Exchange 2003 vi è il supporto alle RBL per verificare se le mail arrivano da una fonte nota di spam e ne caso rifiutarla. Ovvimente nasce il problema di quali utilizzare perchè l'obbiettivo è quello di ridurre lo soap, senza incappare il falsi positivi utilizzando quindi RBL di tipo consevartivo. Un altro punto da tenere presente è che l'uso delle RBL ovviamente genera un overhead di traffico e quindi occerre sceglierle con cura per evitare di usarne troppe e magari simili.

A futura memoria mi segno quelle conservative che al momento sembrano essere quelle che coprono il maggior numero di fonti di spam:

zen.spamhaus.org (http://www.spamhaus.org/zen/) è l'unione delle seguenti 3 RBL:
- SBL Spamhaus Block List Direct UBE sources, spam services and ROKSO spammers.
- XBL Exploits Block List Illegal 3rd party exploits, including proxies, worms and trojan exploits.
- PBL Policy Block List Non-MTA IP address ranges set by outbound mail policy.
list.dsbl.org (http://dsbl.org/howitworks):
all single hop relays that were tested by trusted testers get listed.
dul.dnsbl.sorbs.net (http://www.au.sorbs.net/using.shtml):
Dynamic IP Address ranges (NOT a Dial Up list!).
combined.njabl.org o dnsbl.njabl.org (http://www.njabl.org/use.html)
combination of the above 127.0.0.x types except for 127.0.0.6.

Per la configurazione delle RBL in Exchnage 2003 si veda il seguente:
Configurazione del filtro connessioni affinché utilizzi elenchi RBL (Realtime Block List) e del filtro destinatari in Exchange 2003

ISA Server Cache Directory Tool

Ermanno Goletto — Tue, 23 Oct 2007 10:51:21 GMT

Dopo aver configurato una rule per la cache (a tal proposito si veda ISA 2006 Web Caching) la prima cosa che viene in mente è quella di testarla provando a richiedere alcuni link tramite un browser su un client e andare poi su ISA Server a controllare il contenuto della cache tramite ISA Server Cache Directory Tool. Se l'esporazione tramite CACHEDIR non ci da alcun elemeto il motivo è che gli elementi ancora non sono stati scritti su disco, infatti per default il 10% della memoria viene utilizzata per la cache. E' possibile forzare la scrittura su disco degli elementi della cache in memoria tramite il riavvio del servizio del firewall.

Una curiosità durante la crezione della rule compare la richiesa della network entity a cui andrà applicata come mostra la seguente immagine della guida indicata predentemente:

Come si nota nell'intestazione compare la segente indicazione: "This rule will apply ti request send to the destinations specified on this page" che indica correttamente che la rule farà caching delle richeste fatte verso la/le network entity/entities specificati (quindi se ad esempio vogliamo fare il web caching occorrerà specificare External come mostrato).

Prima del listview contenente le network entities selezionate compare in vece la seguente indicazione: "This rule applies to content request from these network entities" che invece indica erroneamente che la rule viene aplicata alle richieste provenienti dalle network entities elencate (quindi nel caso del il web caching occorrerebbe specificare Internal).

Utilizzare una stampante condivisa su un computer non in dominio

Ermanno Goletto — Wed, 18 Apr 2007 16:09:00 GMT

In certi casi può essere necessario utilizzare una stampante che si trova su un computer che per ragioni di sicurezza è preferibilie non associare al dominio.

La procedura che riporto è stata testata su un computer con Windows 2000 Server SP4.

Un metodo potrebbe essere quello di abilitare sul computer che condivide la stampante l'account GUEST questa soluzione però non piace granchè anche se forse è più immediata (nel caso si intenda utilizzarla si veda questo articolo per eventuali problemi di autorizzazioni che si possono incontrare e relative soluzioni Permission Error Messages Occur When Printing with the Guest Account).

La soluzione che ho adottato io è stata quella di creare sul computer che condivide la stampante un account non appartenente ad alcun gruppo di protezione locale che utilizzo solo per l'autenticazione alla condivione IPC$ dal momento che per impostazione predefinita quando si crea una stampante al gruppo Everyone viene concesso l'autorizzazione a stampare (inoltre sarà possibile in questo modo definire sull'utente eventuali altre impostazioni di sicurezza).

Quindi sui computer Windows 2000, XP e 2003 Server è possibile aggiungere la credenziali per connettersi al computer che condivide la stampante. In alternativa è possibile aggiungere allo script di accesso il seguente comando:
net use \\PcPrinterServer password /user:PcPrinterServer\PrintUser /persistent:no
In questo modo viene creata una connessione alla share IPC$ ma la password risulterà in chiaro nello script, si tenga presente anche nei sistemi operativi di tipo workstation e sono consentite un massimo di 10 connessioni contemporanee (anche se le connessioni inattive da più di 15 minute vengono interrotte automaticamente), a riguardo si veda il seguente http://support.microsoft.com/kb/314882/it.
Ora sarà possibile installare la stampante senza che vengano richieste credenziali di acccesso (va comunque detto che durante l'installazione se non si è prebventivamente autenticati e possibile farlo e scegliere di memorizzare le credenziali)

Se è necessario usare la stampante condivisa da computer con Windows 98 (per esempio da macchine virtuali che eseguono software legacy) sarà necessario creare sul computer che condivide la stampante dgli ulteriori account sempre non appartenenti ad alcun gruppo di protezione locale con stesso username e password utilizzati dai computer con Windows 98 (per evitare problemi è consigliabile non utilizzare password blank) a riguardo si veda il seguente http://support.microsoft.com/kb/q258717 (ovviamente un'alternativa sarebbe abilitare l'utente GUEST).
Se si percorre l'approccio tramite script va detto che il comando net use sui computer con Windows 98 non è necessario e tra l'altro non può essere eseguito perchè questa versione di sistema operativo non accetterebbe questa sintassi. Quindi possono tornare utili questi comandi per evitare di dover creare script separati per evitare di eseguire il comando su computer con Windows 98:

VER |find /i "Windows 98" >NUL
IF ERRORLEVEL 1 net use \\PcPrinterServer password /user:PcPrinterServer\PrintUser /persistent:no

Per eliminare elimnare la connessione utilizzare il seguente comando:
net use \\PcPrinterServer /d

Utilizzare WPA2 su Windows XP

Ermanno Goletto — Wed, 15 Nov 2006 18:14:00 GMT

Per utilizzare lo standard IEEE 802.11i (conosciuto come WPA2) per una rete WiFi occorre oviamente utilizzare AccessPoint e Schede di rete che lo supportino, ma bisogna tenere presente anche Windows XP con SP2 ha il supporto solo per WEP e WPA.

Per far si che Windows XP suporti anche WPA2 occorre installare la KB893357 http://support.microsoft.com/kb/893357.

Se poi si desidera aggiungere il supporto delle opzioni WPA2 di Criteri di gruppo wireless è necessario installare la KB917021 http://support.microsoft.com/kb/917021.