Oggi ci occupiamo della installazione del mio piccolo appliance WSA a casa. Seguiremo passo per passo il wizard e ne approfitteremo per fare alcune considerazioni inerenti la piattaforma in uso.
Queste configurazioni risultano utilizzabili, con semplici modifiche, in un qualsiasi ambiente di trial ed anche per una gran parte degli ambienti di produzione.
Innanzi tutto come installerò il mio apparato:
Data la relativa semplicità del mio network attuale utilizzerò una configurazione a singola interfaccia. Utilizzerò la stessa interfaccia sia per il management che per il traffico proxy.
Userò poi alcuni apparati che raggiungeranno il proxy in modalità esplicita diretta, alcuni via PAC file ed infine non disdegno la possibilità del transparent proxy e quindi mi terrò aperta questa porta.
La prima parte della attività è dedicata al lavoro pesante: sballare e cablare il bambino.
Il WSA – S160 dispone di diverse interfacce di rete, 6 per la precisione, e quindi occorre fare attenzione a come si cabla il tutto.
fondamentalmente dobbiamo ricordarci che la porta configurata di default è la M1 con i seguenti parametri:
IP:192.168.42.42
MASK: 255.255.255.0
la connessione può essere fatta semplicemente via HTTP al seguente indirizzo:
sono supportati tutti i maggiori browser attuali, io ho provato con successo IE8, Firefox3.5, Opera10, Safari4, Google Chrome
la prima operazione richiede la autenticazione al sito:
Fate attenzione al fatto che la connessione viene girata da HTTP ad HTTPS. la connessione viene gestita con un certificato non trusted e quindi sui browser attuali otterrete un messaggio di errore.
accettate la connessione e proseguite. vi ritroverete su di una interfaccia come quella della immagine a sinistra.
La operazione da fare è, semplicemente, immettere le credenziali di default e premere login.
La Username è
admin,
la Password:
ironport
a seguito del login appare il wizard di configurazione, la cui prima schermata è il classico documento di agreement con le condizioni di uso. Non mi soffermo sul testo perché ovviamente non lo legge mai nessuno 🙂 ma occorre ricordarsi di cliccare sul quadratino di accettazione prima di poter proseguire.
Il passo successivo richiede di scegliere la modalità di deployment. In questo caso la immagine mostra che viene richiesta la applicazione di una di 3 possibili configurazioni: Secure Web Proxy & L4TM, L4TM, Web Proxy
Attenzione che queste scelte sono irreversibili e quindi se cambiate idea dovete resetare l’apparato e rifare la installazione. Ci vengono incontro però un paio di caratteristiche simpatiche di WSA:
il fatto di poter gestire contemporaneamente le varie funzioni
Il fatto di non consumare risorse se la funzione viene abilitata ma non usata.
Il risultato di ciò è che la scelta più comoda, in questo caso, è di abilitare entrambe le funzioni, sia il servizio di proxy che il Monitoring del traffico a Layer4 (L4TM). Del resto questa è la configurazione di Default 🙂
Alla domanda se vi sono casi in cui diventa opportuno restringere le operazioni di WSA a uno solo dei due servizi la mia risposta è: oggi come oggi non vedo ragioni per escludere L4TM od il servizio di Web Proxy.
Una volta presa la decisione si può proseguire con la configurazione dell’apparato premendo NEXT.
La prossima schermata è dedicata al tipo di deployment che vogliamo fare in ambito proxy. fondamentalmente ci si chiede se esiste un ulteriore proxy cui puntare e in che modalità questo funzioni.
In presenza di ulteriori proxy si tende a porre WSA in cima alla catena, più vicino agli utenti.
La principale motivazione di ciò è che WSA offre una serie di servizi (Antivirus, antimalware, URL filtering, DLP…) che possono essere configurati agevolmente usando con Microsoft Active Directory il protocollo NTLMSSP, in maniera da usare una autenticazione assolutamente trasparente. Per altro WSA è capace di trasferire le informazioni di autenticazione al proxy successivo, lasciando inalterata la catena di autenticazione precedente.
Nel caso WSA non sia il primo proxy raggiunto dagli utenti ci si troverebbe nella condizione di dover richiedere al proxy di passare le credenziali (nel caso di NTLMSSP il token). Purtroppo non molti proxy consentono questa operazione in maniera semplice.
Vi sono alcune altre opzioni che devono essere valutate nel caso di deploy in proxy chain, spoofing e cache innanzi tutto. Torneremo su questi argomenti in seguito.
Nel nostro caso questo è l’unico proxy presente in rete e quindi ancora una volta il default è la scelta opportuna.
Il passo successivo richiede quali siano le modalità di funzionamento del servizio di Proxy.
Anche questa scelta, come quella analizzata in precedenza sul funzionamento dei servizi di WSA, è irreversibile. Come nel caso precedente, però, ancora una volta il default ci risulta utile, in quanto in modalità TRANSPARENT il proxy accetta anche chiamate esplicite. Non è vero il contrario.
Nel nostro caso la scelta riulta quindi obbligata, volendo lasciare la porta aperta alla transparent redirection.
Le motivazioni per cui vale la pena lasciare la configurazione come Forward Mode sono legate a considerazioni di carattere architetturale. Obbligare tutti gli utenti al forward esplicito può assumere un senso in alcune configurazioni, lasciare in questi casi il transparent aperto potrebbe causare delle incongruenze in termini di funzionamento dei client. Alcuni infatti “potrebbero” funzionare nonostante non gli si sia messo il proxy, e questo potrebbe essere un effetto sgradito.
Al di fuori di questa rara eventualità (che presuppone uno scarso controllo della rete) la scelta più comoda rimane il default.
Facendo click su next andiamo a vedere un riassunto della configurazione che stiamo immettendo e se va bene possiamo proseguire per configurare la rete.
la prima scelta che ci viene proposta è il nome dell’apparato, quindi il DNS ed infine il time-server.
Il nome dell’apparato non è quello delle sue interfacce, ricordiamoci che questa è una macchina multihomed che casualmente, in questa configurazione, usa una sola interfaccia di rete con un indirizzo TCP-IP. avremo quindi la necessità di definire, in seguito, un nome per le singole interfacce che vogliamo utilizzare.
Il secondo punto è il DNS. Sul DNS occorre fare chiarezza, ho già espresso in altri articoli la mia perplessità sull’uso dei DNS di alcuni service provider, anche di livello nazionale, per le scarse performance offerte. Il DNS come servizio è vitale per la navigazione in termini di efficienza e di velocità, dobbiamo inoltre considerare se il DNS cui puntiamo è sufficientemente protetto da attacchi quali il DNS poisoning o un attacco DDoS.
Tendenzialmente consiglio l’uso di un DNS interno, magari non lo stesso su cui gira AD e che non gestisca zone, e che serva solo come resolver. Questa eventualità, purtroppo, è spesso disattesa e quindi la scelta può ricadere sui DNSroot di default oppure su di un DNS service provider.
Fate riferimento ai miei articoli su questo blog per avere indicazioni in merito.
Troviamo ora la richiesta per il Time server. Anche in questo caso utilizzo i default, ma semplicemente perché non prevedo di utilizzare al momento, la sincronia con AD.
Nel csaso si voglia usare Active Directory con la autenticazione NTLMSSP occorre utilizzare come time server la stessa sorgente che sincronizza AD. in altre parole occorr epuntare ad un domain controller che offra la sincronia NTP. Di default questo lavoro se lo accolla il global catalogue ma può essere distribuito altrove.
è fondamentale sincronizzare WSA con l’ora di AD altrimenti si rischia di corrompere il database di autenticazione se le differenze di orario superano una certa quantità. in questo caso si rischia di dover riconfigurare WSA con AD.
è buona norma generale, comunque, in una rete sincronizzare i time server su di una fonte (o serie di fonti) affidabili che mantengano gli scarti inferiori al secondo.
Una altra ragione per cui la sincronia temporale è utile ed indicata, è per gestire la coerenza dei log nel caso si usino log provenienti da apparati e sorgenti diverse (magari non solo WSA).
Ed eccoci finalmente alla configurazione dei parametri di rete dell’apparato.
nel mio caso utilizzo solo M1 e quindi lo configuro direttamente. Nel caso si voglia usare più di una interfaccia occorre procedere alle varie configurazioni ricordando alcune semplici regole:
Due interfacce fisiche diverse devono stare su network logici (domini IP) diversi.
Esiste una sola default route, le altre route sono statiche
Se si vuole utilizzare anche P2 occorre configurarla in un secondo tempo.
Se NON si vuole usare M1 per fare da interfaccia di proxy occorre indicare che M1 fa da Management Only.
Occorre quindi configurare la parte di routing (nel mio caso basta porre il default gateway usando una rete piatta).
Nel caso vengano poste in essere più interfacce occorre provvedere alla definizione delle opportune route statiche. tendenzialmente consiglio di tenere la configurazione fatta via Wizard il piu semplice possibile e demandare la definizione degli altri parametri a wizard ultimato. Per essere del tutto chiari suggerisco sempre di effettuare le seguenti operazioni:
1) installazione via wizard più semplice possibile
2) configurazione eventuali parametri necessari
3) upgrade sistema operativo alla ultima release
4) configurazione completa e definitiva della macchina
la scelta della sequenza dipende, fondamentalmente, dal fatto che il wizard è uno strumento semplificato e che può capitare che un upgrade di OS cambi la struttura di alcuni parametri di configurazione o ne aggiunga alcuni.
gli ultimi passi riguardano la modalità di transparent routing che andiamo ad implementare. in questo caso eventuali specifiche di configurazione ulteriori (come nel caso del wccp) vanno inserite in un secondo tempo a wizard ultimato.
troviamo quindi i servizi di security che andiamo ad implementare.
i punti salienti sono se vogliamo o meno implementare l’IP spoofing, e quali servizi vogliamo utilizzare tra URL filtering, Web Reputation, WebRoot e Mac Afee.
Dobbiamo ricordarci che in fase di trial ironport fornisce il set completo di chiavi, e quindi tutti i servizi sono attivabili e testabili, in produzione invece funzioneranno solo i servizi che sono stati acquistati. La generazione di una licenza non abilita automaticamente un determinato servizio, se aggiungete quindi servizi in un secondo tempo occorre ricordarsi di abilitarli dalla opportuna interfaccia del prodotto.
Alla fine delle ostre fatiche troviamo finalmente il riassunto della configurazione che stiamo immettendo. se i parametri immessi ci soddisfano possiamo premere “install the configuration” altrimenti possiamo tronare indietro e modificare gli elementi che non ci soddisfano.
Va ricordato che nel momento in cui accettiamo la configurazione questa viene attivata e quindi, se siamo su di un network non coompatibile con la nuova configurazione IP, perderemmo l’accesso alla interfaccia di management.
Riconfiguriamo se occorre l’IP del nostro portatile e riconnettiamoci al nuovo indirizzo, sempre alla porta 8080.
A questo punto occorre fare alcuni passi ulteriori.
Innanzi tutto dobbiamo lanciare l’upgrade del sistema operativo:
basta andare in system administration –> system upgrade –> avaible upgrades e scegliere il più alto disponibile.
dopo di che suggerisco di effettuare anche questa altra operazione per rendere piu aggressivo il motore di cacheing:
aprite putty per andare in command line
inserite le credenziali:
lanciate il comando advancedproxyconfig e andate a modificare il parametro cache in aggressive mode
infine premete invio sino ad uscire dal comando e aggiornate la configurazione con un bel commit coomentato.
il mio WSA cosi è pronto per funzionare.
Adesso occorre definire policy ed altre configurazioni, ma questo in un prossimo articolo
sayonara
Antonio
Share this:
Related Posts via Taxonomies
To the official site of Related Posts via Taxonomies.
Discover more from The Puchi Herald Magazine
Subscribe to get the latest posts sent to your email.
Cisco-Ironport Web Security Appliance: WSA installazione by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
