Uno script di autoconfigurazione con estensione *.pac, chiamato per comodità proxy.pac contiene genericamente una funzione JavaScript chiamata “FindProxyForURL(url, host)” che restituisce uno o più risultati, basandosi su condizioni definite dal gestore del sistema di proxy, che un moderno browser è in grado di interpretare.
Viene solitamente utilizzato quando è necessario discriminare la modalità di navigazione al fine di indirizzare l’utente, in modo trasparente, a rivolgere la sua richiesta attraverso il proxy oppure in modalità “diretta”.
Eccone un esempio:

function FindProxyForURL(url, host)
{
       if (isPlainHostName(host))
       {
       return "DIRECT";
       }
// NAME HOSTS --> DIRECT

        if ((host=="domainname.it")||
            (host=="domainname.com"))
        {
        return "DIRECT";
        }

// NAME HOSTS --> PROXY

        if ((host=="abcd.domainname.it")||
            (host=="efgh.subdomain.domainname.it"))
        {
        return ProxyServer(url);
        }

// IP HOSTS --> DIRECT

        if ((host=="10.60.50.141") ||      // Servizio XYZ;
            (host=="10.32.1.103"))          // Servizio ZXY;
        {
        return "DIRECT";
        }

// IP HOSTS --> PROXY A

        if ((host=="10.128.64.50")   ||    // Servizio A
            (host=="10.51.8.50")     ||     // Servizio B
            (host=="10.51.76.202"))        // Servizio C
        {
        return ProxyServer(url);
        }

// IP HOSTS --> PROXY B;

        if ((host=="XXX.201.99.120") ||
            (host=="YYY.223.212.242") ||
            (host=="ZZZ.221.99.154"))
        {
        return "PROXY aa.bbb.ccc.d:8080; DIRECT";
        }

 //LOCAL DOMAIN NAME --> DIRECT

        if (dnsDomainIs(host, "subdomain.mydomain.it") ||
            dnsDomainIs(host, "subdomain.mydomain.com") ||
            dnsDomainIs(host, "internaldomain.loc") ||
            dnsDomainIs(host, "otherdomain.it"))
        {
        return "DIRECT";
        }

//PRIVATE NETWORK --> DIRECT

        if (isInNet(host, "10.0.0.0", "255.0.0.0") ||
            isInNet(host, "127.0.0.0", "255.0.0.0")  ||
            isInNet(host, "172.16.0.0", "255.240.0.0")  ||
            isInNet(host, "192.168.0.0", "255.255.0.0"))
        {
        return "DIRECT";
        }

        // otherwise use Proxy Server

        else

        function ProxyServer(url);

function ProxyServer(url) {
   return "PROXY cache.internaldomain.it:3128; DIRECT";
}

Il proxy.pac per essere utilizzato deve essere messo in linea su un web server opportunamente configurato, argomento che tratteremo in un prossimo articolo.

Per ulteriori informazioni sull’uso degli script di autoconfigurazione consultate Wikipedia
Per verificare la sintassi e/o i risultati del vostro proxy.pac potete utilizzare pactester.

Qualsiasi amministratore si augura di non dover mai utilizzare questa password, ma proprio perchè il suo utilizzo non è così frequente, molti non la ricordano, oppure essendo subentrati nella gestione dei sistemi a qualcun altro, non la conoscono.
Accorgersi di non conoscerla in un momento critico, può essere davvero moltro frustrante, quindi se vi sta sorgendo il dubbio, reimpostatela.

In Windows 2000, a partire dal Service Pack 2, è possibile utilizzare il comando setpwd digitando,

• Aprite una console (cmd.exe) e digitate setpwd /s:nomeserver(dove nomeserver è il nome del Domain Controller sul quale si intendende impostare la nuova password).

In Windows 2003, questa funzionalità è stata inserita nell’utilità di sistema Ntdsutil, ecco i passaggi da seguire:

• Aprite una console (cmd.exe) e digitate Ntdsutil + Invio.
• set dsrm password.
• digitare uno dei seguenti comandi:
  • reset password on server null (per impostare la password sul server su cui si sta operando)
  • reset password on server nomeserver (dove nomeserver è il nome del Domain Controller sul quale si intendende impostare la nuova password)
• Al termine premete q + Invio per tornare al menu precedente
• Premete ancora q + Invio per uscire da Ntdsutil.

Nella parte precedente dell’articolo abbiamo visto come creare un virtual host Apache utilizzando il moduli mod_proxy, mod_rewrite e mod_ssl per creare un reverse-proxy https riscrivendo l’URL OWA di Exchange 2007. Se lasciassimo la configurazione cosi’, gli utenti, per raggiungere l’applicazione attraverso il reverse-proxy, dovrebbero digitare https://webmail.dominio.it, ma saranno pero’ condizionati alla scrittura del prefisso https://.
Con un po’ di pazienza e qualche altra riga di codice, potremmo semplificare ulteriormente.
Ecco come fare:

Questo virtual host si limita soltanto a redirigere permanentemente cio’ che arriva sulla porta 80 del reverse-proxy (http://webmail.dominio.it) sulla porta 443 (https://webmail.dominio.it) senza apportare nessuna modifica. Non e’ sicuramente fondamentale ai fini del risultato ricercato, ma si tratta di una piccola “finezza” che permettera’ agli utenti di raggiungere l’applicazione OWA semplicemente digitando webmail.dominio.it.

In questo articolo, vedremo come esporre su internet OWA (Outlook Web Access) in modo sicuro traslando l’URL http con indirizzo privato in un URL https con indirizzo pubblico utilizzando alcune funzionalita’ messe a disposizione da Apache tramite i moduli mod_proxy mod_rewrite e mod_ssl.

Il modulo mod_proxy permette di effettuare relay e caching di richieste provenienti da vari host verso altri host mantenendo questi logicamente separati.
E’ praticamente uno step intermedio fra i client e il server remoto, in modo da non consentire il passaggio diretto delle informazioni, ma sia il proxy a gestire la comunicazione fra le parti.
Puo’ essere utilizzato in modalita’ FORWARD e REVERSE, proprio come se fosse un imbuto.
Nel primo caso il proxy raccoglie le richieste dei client da tutta una LAN e le redirige verso internet (forward), il secondo caso e’ esattamente opposto, il proxy raccoglie le richieste da internet e le redirige su un server della LAN (reverse).

Il modulo mod_rewrite permette di riscrivere un URL in un altro senza che l’utente ne sia a conoscenza. L’associazione avviene al “volo” tramite regole definite nel file di configurazione e/o virtualhosts oppure nel file .htaccess. Questo tipo di riscrittura apre a numerose possibilita’ per “ripulire” un URL e renderlo quindi piu’ semplice per l’utente.
Molti avranno sperimentato che, in particolar modo, con l’uso di CMS (Content Management System) il server produce URL simili a:

sicuramente non semplice da digitare, ma utilizzando la riscrittura la si puo’ rendere:

decisamente meglio, vero?

Il modulo mod_ssl è il modulo per la gestione del protocollo HTTPS in Apache, basato su OpenSSL capace di supportare i protocolli Secure Sockets Layer (SSL v2/v3) e Transport Layer Security (TLS v1), un tempo sviluppato come “patch” del codice sorgente, oggi modulo cardine della sicurezza.

Non resta che unire queste funzionalita’ in due virtualhost di Apache per ottentere il risultato desiderato.
Dato per assunto che abbiate installato Apache con i moduli richiesti su un server Linux questa e’ la configurazione da fare:

Nella configurazione appena vista deve essere inserito l’indirizzo IP privato del vostro server reverse proxy (nell’esempio 172.18.27.7) su cui sara’ effettuato il NAT (se utilizzate questa tecnica), altrimenti se utilizzate una rete disaccoppiata (server con un indirizzo privato ed un indirizzo pubblico) sara’ necessario creare due virtual host (identici) con gli indirizzi IP (Publico e Privato) del vostro server reverse proxy, “aa.bb.cc.dd” deve essere sostituito con quello del vostro server Exchange e il certificato di crittografia deve essere esportato dal server Exchange 2007 e convertito in formato Apache (per informazioni Esportare un certificato SSL da IIS per utilizzarlo in Apache).

Nella prossima parte dell’articolo ci occuperemo di creare il virtual host http che sara’ rediretto sul virtual host https appena visto.

In alcuni casi, puo’ essere necessario utilizzare lo stesso certificato SSL su un server Microsoft IIS e su un server Apache.
E’ possibile esportare un certificato SSL da IIS per utilizzarlo in ambiente Apache.
Ecco come fare:

1. Sul server Windows con IIS aprire una Microsoft Management Console (mmc.exe), aggiungere lo snap-in Certificates e selezionare Account Computer e Local Computer.

2. Cercare il certificato che si intende esportare e selezionando All Tasks > Export, avendo cura di esportare anche la chiave privata, inserendo una password alla richiesta.

3. Prendere il file formato pfx appena generato e spostarlo su una macchina Unix/Linux in cui e’ installato OpenSSL e digitare:

4. Il file formato PKCS12 non e’ altro che la concatenazione del certificato e della chiave privata che dovrete separare in due file con estensione .crt (certificato) e .key (chiave privata).

5. Per eliminare la password inserita durante l’esportazione (utile in ambienti di produzione in cui Apache deve avviarsi in modalita’ non assistita) digitare:

I file cosi’ ottenuti sono perfettamente compatibili in ambiente Apache.

Cosa ne fate dei vecchi computers? Li vendete o li donate a qualche ente?
La risposta in sè non ha molta importanza, la domanda che dovreste porvi in realtà è un’altra.
Uno o più hard disk di questi computer conteneva dati confidenziali?
Se la risposta a questa domanda è SI, esiste la possibilità che, seppur avendo riformattato gli hard disk dei vostri computers prima della cessione (al broker piuttosto che alla scuola superiore) qualcuno possa recuperare (senza neanche molta fatica) i vostri dati utilizzando uno qualsiasi dei programmi, largamente diffusi, per il recupero dei dati cancellati.
Quindi prima di apprestarvi a cedere (anche qualora optaste per l’alienazione) dei vostri computers obsoleti, dovrete assicurarvi che i vostri dati non finiscano nelle mani sbagliate.
Cipher offre un metodo per cancellare un hard disk in modo che anche il più abile degli hacker trovi notevole difficolta nel cercare di recuperare i vostri dati.
La soluzione consiste nel sovrascrivere ogni settore dell’hard disk con dati random ed è composta di due fasi.

• Dopo aver montato l’hard disk in questione in un enclosure USB, collegatelo ad un PC con sistema operativo Windows XP e formattatelo.
• Dalla console lanciate il comando “cipher.exe /w:driveUSB:” (dove “driveUSB” rappresenta la lettera dell’hard disk che avete collegato alla porta USB)

Perchè l’operazione (Decommission) abbia successo e si dimostri sicura, dovreste ripetere il secondo punto per almeno tre volte.
Probabilmente l’NSA oppure la CIA saranno ancora in grado di recuperare i vostri dati, ma che per la maggior parte degli occhi indiscreti risulteranno completamente illegibili.

N.B.
Il punto uno (la formattazione) è fondamentale altrimenti Cipher sovrascriverà soltanto i dati degli spazi “vuoti” dei vostri hard disk lasciando inalterati i dati esistenti.

Microsoft Security Response Center (MSRC) fornisce supporto “day by day” a tutte le problematiche di protezione legate al software Microsoft.

Ore 0:53, sono appena arrivato a casa dopo una serata passata nel datacenter del mio cliente invece di essere a cena con Greta.
Tutto e’ iniziato alle 20:15 con l’arrivo di una chiamata di un collega (Pj), che mi chiedeva se questa sera dopo le 21:00 avessi potuto lavorare con lui, all’analisi di un problema verificatosi in giornata su un’applicazione per video chiamata basata su protocollo SIP.
Ovviamente non potevo “esimermi” da tale impegno, dato che il tono di Pj lasciava trasparire che il problema “esigeva” una soluzione nel breve termine e che molto probabilmente anche questa volta il commerciale si era “prostituito” col cliente finale promettendo una soluzione in tempi rapidi…ssimi.
In breve:
il client dell’applicazione (installata presso il call center) deve collegarsi ad un server (in IDC) utilizzando il protocollo SIP con porta sorgente 5060 e porta di destinazione 5060, ma dai logs del firewall emerge che “qualcosa” modifica la porta sorgente del client, infatti tutti i frames vengono allegramente droppati dal firewall perche sorgenti da porte random (???????). Ovviamente tutti i vari carrier che forniscono servizi di rete nel “mezzo” (tra il call center e l’IDC) giurano di non apportare nessun tipo di modifica, quindi tocca a noi fare l’analisi.
Del resto questa è la professione che ho scelto, per cui parto alla volta dell’ IDC Settimo Milanese, faccio tappa in autogrill per pieno di gasolio (quando si ha fretta, il serbatoio e’ sempre vuoto) e sacchetto con panino e bibita, conscio del fatto che quella sarebbe stata la mia cena.
Arrivo all’IDC alle ore 21:15, preparo il portatile, ripassando mentalmente la topologia della rete realizzata piu di una anno fa e che nel frattempo ha subito notevoli modifiche (gli switch sono piu del doppio, rispetto a quelli installati in origine), apro un terminale sullo switch sul quale e’ attestata la rete MPLS che collega il call center all’IDC per configurare l’interfaccia in mirror e verificare se il traffico in ingresso è effettivamente quello che ci apettiamo di ottenere, verificando che nessuna delle parti coinvolte abbia commesso spergiuro.
Chiamo Pj e lo informo, intanto collego il pc, avvio lo sniffer per raccogliere il traffico di un paio di minuti, ed effettivamente le richieste dirette al server sono “pulite” (source 5060, destination 5060), nessuno ha commesso spergiuro, il problema è altrove.
Sempre al telefono col “serafico” Pj, apro un terminale sul nodo attivo del firewall (cluster Checkpoint), avvio tcpdump sull’interfaccia in ingresso del firewall, ma anche qui il traffico in ingresso è pulito, avvio tcpdump sull’interfaccia in uscita e BANG…trovato!!!!
Dal firewall le richieste entrano corrette, ma escono modificate, la porta sorgente non e’ piu’ 5060 ma e’ 14322 (?????), vuol dire che il software di firewalling apporta alcune modifiche, Pj si abbandona ad un sarcastico “ottimo”.
Apro la rule based, verifico la regola, ma è corretta (source x.x.x.x, destination y.y.y.y, service “sip”), domani dovremo contattare l’assistenza e aspettare che rispondano in “tempi biblici”, Pj non e’ felice di doverlo dire al cliente.
Nel frattempo che Pj informa il tecnico che si occupa dell’applicazione in questione, apro le proprieta’ dell’oggetto “sip” di checkpoint e noto che è attivo il “packet inspection”, in pratica checkpoint non si limita a controllare IP e porta, ma verifica se il protocollo in transito sia effettivamente SIP.
Vado su google, cerco un possibile caso analogo, e trovo il post di uno sventurato che si e’ scontrato con un problema analogo utilizzando ASTERISK, il quale suggerisce, per risolvere il problema, di impostare il packet inspection a “none”.
Lo faccio, chiedo a Pj di ripetere la prova, acconsente….FUNZIONA!!!!!!!!!.
Ci siamo salutati contenti di aver trovato la soluzione, seppur un po’ amareggiati per aver capito che checkpoint ne era la causa.

Se usate VMWare ESX (vale anche per la versione GSX e Professional) a volte può rendersi necessario clonare una macchina virtuale.
Se la macchina virtuale ha un sistema operativo Windows ed è parte di un dominio, dopo aver svolto tutte le operazioni necessarie alla clonazione, è necessario eseguire, sulla macchina virtuale clonata, NewSid prima di effettuare nuovamente il join a dominio.
Questo perchè ciascun “account di protezione” (utenti, gruppi e computer) possiede un SID (Security IDentifier)che lo identifica “univocamente” all’interno del dominio.
Un SID duplicato all’interno del dominio, potrebbe causare problemi di sicurezza in relazione a risorse quali file, directory, stampanti, cassette postali di Microsoft Exchange, database di Microsoft SQL Server, oggetti memorizzati in Active Directory o qualsiasi altro tipo di dato protetto dal modello di protezione di Windows.

Questo ovviamente vale anche per cloni ottenuti da duplicazione di HDD (es. ricostruzione da RAID 1) oppure ottenuti da tools per duplicazione (tipo Symantec’s Ghost, PowerQuest’s Image Drive, and Altiris’ RapiDeploy)

La Sicurezza informatica è il settore dell’informatica atto alla salvaguardia dei sistemi informativi dal rischio di violazione dei dati o del sistema stesso.
Si fonda su alcuni aspetti principali per la protezione dei dati, confidenzialità , integrità e disponibilità .

La “Sicurezza Informatica” si ottiene agendo su più livelli:
1) Livello fisico: Ponendo i server in luoghi il sicuri, con controllo accessi e dotati di sorveglianza;
2) Livello Logico: Prevedendo controlli quali autenticazione e autorizzazione dell’utente nel sistema. Le operazioni effettuate dall’utente successivamente al processo di autenticazione, devono essere tracciate in file di log (processo di accounting).