Da quando ho installato Snow Leopard da capo (la prima esperienza era un banale aggiornamento) ho riscontrato un sacco di problemi inerenti ai client VPN. Il mio lavoro mi porta ad avere una cozzaglia di client: cisco, sonicwall, watchguard.

Come far funzionare la maggior parte di loro è più tosto semplice, due minuti su google risolvono la maggior parte dei problemi. Se poi si tratta di Cisco, allora il supporto vpn è già integrato nel sistema operativo. Io rimango fedele al software Cisco, anche perche mi serve come traccia per un eventuale assistenza telefonica, ecc...

Quindi Cisco funziona, SonicWall pure, addirittura quella cagata di Check Point, bene.... Ma Watchguard SSL ? Ecco, bravo. Non c'è modo di farlo andare... E' fosse solo un problema del client, ma andiamo in ordine.

Esperienza windows: in base al firmware installato sul firewall, e io ho testato solo la 10.x e la 11.x, occorre avere il relativo client. Peccato che se ne possono installare uno per volta. Tanto di capello ai sviluppatori Wachguard, magari non hanno pensato che un povero cristiano potrebbe collegarsi sia a un 10.x che a un 11.x ...

Esperienza mac: se si parte dalla con Leopard (10.5 quindi) il client funziona, sia in versione 10.x che 11.x; aggiornando a Snow Leopard lo stesso. Ma con un Snow installato pulito no ! La 10.x crasha in maniera silenziosa:

25/01/10 09.40.48 SubmitDiagInfo[1777] Submitted crash report: /Users/rafal/Library/Logs/DiagnosticReports/WatchGuard Mobile VPN with SSL_2010-01-22-192117_homemacbook.crash

con la 11.x invece non riesce a scaricare qualcosa perche CURL ha la sintassi diversa, mi manca il log ma l'errore riguardava curl, credo...

Visto che non si può dare la colpa alla (poca) fantasia dei programmatori, e che sicuramente non ho visto la famosa opzione scritta alla pagina 46 del manuale (che non ho letto) che risolveva il tutto, tocca correre ai ripari.

Il cilent SSL VPN di Watchguard è un porting personalizzato di OpenVPN. Già in passato avevo risolto la questione di questo genere di accesso da parte di utenti linux (non esiste un client ufficiale watchgurd) con successo; osx non ne sarà immune.

Quindi come prima cosa bisogna munirsi di un ... windows... Anche se sono in attesa di una spiegazione da parte di Watchguard, non ho trovato altro modo per recuperare i certificati per la creazione della vpn. Infatti il client per windows salva tutto l'occorrente nella cartella :

C:\Documents and Settings\[ utente ]\Dati applicazioni\WatchGuard\Mobile VPN

I file sono:

• ca.crt
• client.crt
• client.pem
• client.ovpn

Il primo è il certificato della CA, altro certificato (2) e la relativa chiave (3) sono del utente, mentre il file ovpn è il file di configurazione del client openvpn. Per maggiori dettagli http://www.openvpn.net/

Qui il gioco si fa semplice, è sufficiente avere openvpn o un software simile. Io ho trovato un software semplice e abbastanza completo: Viscosity (http://www.viscosityvpn.com/), lo consiglio anche se è a pagamento (costa appena 9USD). Una volta installato basta copiare la cartella contenente i file recuperati da qualche parte, magari in ~/.openvpn/ e fare doppio click sul file di configurazione client.ovpn. Il profilo viene importato è sarà già perfettamente funzionante. Opzionalmente sarebbe da aggiungere le opzioni che aggiunge lo script che esegue Watchguard:

verb 3
management 127.0.0.1 1337
service wgsslvpnc_ExitEvent
management-query-passwords
management-hold

Anche se, dopo aver letto il manuale di OpenVpn, tali opzioni non sono necessarie.

Ovviamente è solo un esempio. Viscosity è molto carino e parecchio OSX like, esistono però delle alternative open source e non.

In definitiva in poco tempo ho risolto diversi aspetti: il primo è la funzionalità, purtroppo con queste vpn gestisco remotamente un diverse reti, il secondo la possibilità di profilare gli accessi. Infatti il client Watchgurd non ha una simile funzionalità. Inoltre, altro plus di Viscosity, posso salvare le credenziali nel Keychain, comodo.

Lo scotto è recuperare i file, occorre infatti stabilire una connessione funzionante con il peer per poterli recuperare. Ho aperto un post sul forum Watchgurd per sapere se è possibile recuperare queste informazioni in un'altro modo.

Prima di chiudere due parole su windows. Vale lo stesso discorso a patto che il client OpenVpn è 2.1 o superiore. Addirittura se si installa il client sopra l'installazione Watchguad, il profilo viene importato automaticamente. Peccato che la distribuzione base ha si la GUI ma senza la possibilità di gestire i profili. Ho visto comunque che esiste un porting per windows capace di farlo (a google arduo compito di ricerca).

Durante le ultime due settimane mi sono "divertito" a mettere in piedi un infrastruttura su vmware per un portale di un nostro cliente. Questo portale, oltre ad un back-end, eroga dei webservices e si basa su SQL 2005 come fonte dati. Il progetto di fatto funzionava già su una piattaforma fisica e io dovevo solo, almeno inizialmente, dare una valutazione della fattibilità della realizzazione e di produrre un progetto di massima con tempi e stima di prezzi.

Ecco cosa mi è stato dato come base di partenza:

La cosa non sembrava difficile. Un sistema multi-tier con un cluster MsSQL 2005 nel back-end, un network load balancer (NLB) Microsoft per IIS nel front-end. Il tutto gestito da due firewall in HA.

Come capita sempre, purtroppo, non ho avuto un gran che su cui lavorare, ma in fondo dovevo solo "stimare" e fare un "progetto di massima". Il tutto in un paio di giorni. Ero uscito fresco dalla certificazione VCP e dopo diverse esperienza (tra cui un sistema Exchange 2007 che usiamo come piattaforma di posta principale) e avevo ancora le idee un po' confuse. In ogni modo conoscevo i dati principali quali carichi, richieste di occupazione delle risorse, ecc...

Comunque la cosa mi sembrava, come sempre, stimolante per cui progettai una cosa simile alla presente:

Si tratta di due server fisci, ESX, che eseguono le macchine virtuali. I membri del cluster sono distribuiti tra entrambi i server fisici, quindi quello che VMWare chiama cluster-out-of-box, come anche i nodi NLB e i firewall, che diventano virtuali. Entrambi ESX sono configurati in HA in modo da ridondare i server NLB e i firewall tra i server fisci. Ovviamente da questo escludo i membri del cluster, anche tecnicamente non possono essere in HA. In questo modo ho la completa ridondanza hardware e software, fisica e virtuale. Insomma sulla carta sembra essere una cosa fattibile e sicura.

Come di solito accade in questi casi, il progetto di massima è diventato misteriosamente un preventivo che poi si è trasformato in un offerta e in un non meglio precisato progetto dettagliato (argh...). Il tutto gestito dal lato commerciale. Ma perche la prossima volta non mi chiedono semplicemente "si può fare ?" e "quanto ci costa?" quindi "quanto tempo ci metti?" ? Hmm... ripensandoci e cosi che vanno le cose normalmente, mah!

In ogni modo il cliente ci ha voluto conoscere di persona, abbiamo ragionato sui dettagli quali "figata, avete un db da 4GB" oppure su "azzo, ma come fate la replica dei file tra i nodi NLB". Insomma una intervista rapida ma esauriente.

La stima iniziale era di 4 settimane di lavoro. Questo perché non avevo neanche il hardware pronto. In ogni caso avevo pensato a 2 settimane di installazione e patching (ecc...), 1 settimana di testing e 1 settimana per hardering, vulnerability assessment e preparazione delle procedure di migrazione.

Prima ancora di procedere con l'accesso ai sistemi esistenti mi sono occupato del hardware.

Per il progetto sono state destinate due lame di un sistema blade HP. In particolare classe C, dei DL460C. Ogni lama è stata equipaggiata con una mezzanine FC QLogic e una mezzanine Gbic. In totale ho sul enclosure 4 porte LAN e due porte FC per ogni lama. Vito che le due lame andranno ad aggiungersi ad un infrastruttura esistente dovevo solo installare ESX sui nodi fisici, e configurare il comparto storage e lan.

Installazione di base non comporta nessun problema. Come dice un mio cliente: "... e che ci vuole, avanti, avanti, fine...". Lo storage è già configurato in multipath e ho lo spazio necessario.

Ho creato una LUN per vmstore per ospitare i dischi delle macchine virtuali e altre due per il cluster. Una volta configurato il mapping sui controller l'operazione era fatta.

La rete è stata un po' più complicata. Avevo a disposizione 4 interfacce. La suddivisione l'ho fatta cosi:

• prima interfaccia è dedicata alla Service Console e NFS (dove ho le ISO dei SO e altro software che mi serve)
• seconda interfaccia è dedicata alla rete pubblica, o vlan non filtrata se vogliamo
• terza interfaccia è dedicata alle LAN, DMZ, HB cluster e HB firewall
• quarta interfaccia è dedicata al VMKernel e alla Service Console di backup

Visto che su una interfaccia ho tutto il traffico LAN ho lavorato con le VLAN. Ecco il risultato:

Nell'immagine ci sono già le macchine virtuali collegate perché l'ho presa dall'ambiente in produzione.

Grazie a Dio i nostri switch sono dei HP Procurve, per cui abbiamo:

802.1Q VLAN ID Name Status Voice Jumbo
-------------- ------------ ------------ ----- -----   
180 lan-itc Port-based No No
181 dmz-itc Port-based No No
182 hb_fw-itc Port-based No No
183 hb_dmz-itc Port-based No No

Creata l'infrastruttura ho cominciato con i firewall.

Continua nella parte II.

Ad un nostro cliente è saltato il vecchio firewall. Si trattava di un Watchguard FBXIII 500. Una roba di 10 anni fa. Ha sempre funzionato bene ma si vede che è arrivata la sua ora. Una volta il cliente aveva una bella rete. Vpn tra Milano, Roma e pure China, diversi server e diversi accessi. Ora invece, complice la crisi, ha giusto l'exchange in casa e qualche accesso SSL. Di conseguenza la configurazione, una volta più tosto complessa, ora è abbastanza "standard".

Dalla nostra gli sono stati proposti alcuni apparati sostitutivi. In particolare tre: un Watchguard, uno Zywall e un Asa. Sarà il mercato, ma è andato finire che l'asa se l'ha comprato da solo e a noi ci ha chiesto solo la configurazione.

A me va bene. Purtroppo non ho il piacere di avere molto materiale Cisco sotto le mani, e la cosa mi dispiace un sacco. Ma visto che "...è un azienda in decadenza..." (ndr è una delle battute più idiote e allo stesso tempo memorabili del mio capo) .... Ahhhhh.

Prendo l'appuntamento con il cliente il venerdi scorso. Sballiamo la cosa e cominciamo a creare la configurazione. Io sono assolutamente negato con ASDM. Anche Firewall Builder mi sta particolarmente sulle palle. Di conseguenza normalmente le configurazioni le faccio dalla CLI.

La cosa più figa che configuro le prime cose e provo se vanno senza successo. Con senno di poi avevo sbagliato tutta la parte del nat, ma li in casa del cliente il cervello mi è andato in tilt. Alla fine mi sono portato via il "coso" e me lo sono configurato line-by-line, scrivendo tanto di commenti. Serve a me e serve ai miei colleghi.

Ecco cose ne è venuto fuori, con la dovuta precisazione che NON è la configurazione finale e che le classi e gli indirizzi ip sono quelli del laboratorio.

Lo schema della rete è banale. Tre interfacce:

• WAN : 192.168.1.36/24
• LAN : 172.16.9.100/24
• DMZ : 172.16.10.1/24

Gateway sulla WAN: 192.168.1.254. Sulla DMZ ho un server Exchange, mentre sulla lan il server di dominio. Sono stato molto pigro e non ho mai fatto la modifica del RPC. Di conseguenza il traffico tra la lan e dmz è permesso any-any. Visto che stiamo mettendo le mani nella rete e c'è un po' di spazio per poterlo fare sarà la prossima cosa che verrà fatta.

Ecco la mia esperienza da laboratorio:

Si parte con un bel erase della configurazione. Quindi:

write erase

reboot con reload e siamo pronti a cominciare.

Verifico le versioni del asa e del asdm (?!?). Come già scritto io non lo so proprio usare, anzi. Per questa esperienza me lo sono tenuto aperto e facevo di volta in volta "refresh" per capire proprio come si usa. Decisamente non male ma continuo a preferire la CLI. Asdm lo lascio cosi do al cliente un sistema di monitoraggio in real-time. Comunque:

dir disk:0/

un bel sh ver infine fa sempre bene...

Fatto l'aggiornamento via tftp:

copy tftp: disk0:

Poi setto le immagini di boot per quella per asdm:

boot system disk0:/asa804-k8.bin
asdm image disk0:/asdm-602.bin

Nel momento in cui scrivo mi sto scaricando dal Cisco CCO le nuove versioni. Tempo di leggere le release notes e faccio aggiornamento di nuovo. Comunque andando avanti configuro alcuni parametri di base e dei utenti:

hostname fwLaborTty
domain-name lttsite.local
username service password xxxxxxxxxx priv 2
username rafal password xxxxxxxxxx priv 15
enable password xxxxxxxxxx
logging consol error
logging enable

quindi passo alla configurazione delle interfaccie

interface Ethernet0/0
nameif outside
security-level 0
ip address 192.168.1.36 255.255.255.0

interface Ethernet0/1
nameif inside
security-level 100
ip address 172.16.9.100 255.255.255.0

interface Ethernet0/2
nameif dmz
security-level 100
ip address 172.16.10.1 255.255.255.0

Ora tocca al asdm:

http server enable
http 172.16.9.194 255.255.255.255 inside

Funziona anche da Safari, meno male. Avvio asdm per monitorare le modifiche fatte. Procedo quindi con SSH.

crypto key generate RSA

ssh 172.16.9.194 255.255.255.255 inside
ssh XX.XX.XX.XX 255.255.255.248 outside
ssh XX.XX.XX.XX  255.255.255.248 outside
ssh XX.XX.XX.XX  255.255.255.248 outside
ssh timeout 10
ssh version 2

Mi sembra ovvio che il mio mac sta sulla inside ed ha ip 172.16.9.194. Solo perche voglio fare dei test modifico il comportamento del icmp:

icmp unreachable rate-limit 1 burst-size 1
icmp permit any inside
icmp permit any dmz

Adesso tocca al NAT. Il mio scopo è quello di riprodurre il maniera fedele la configurazione precedente. Faccio quindi un nat dinamico sulla interfaccia outside per uscire sia per la LAN che per la DMZ. Occorre in anzi tutto un global per outside:

global (outside) 1 interface

quindi le acl per la configurazione del nat:

access-list outgoing_nat_lan extended permit ip 172.16.9.0 255.255.255.0 any
access-list outgoing_nat_dmz extended permit ip 172.16.10.0 255.255.255.0 any

Mi assicuro che nat-control è abilitato quindi creo le due regole:

nat (inside) 1 access-list outgoing_nat_lan
nat (dmz) 1 access-list outgoing_nat_dmz

Visto che, almeno in questo caso e per ora, voglio permettere tutto il traffico tra la LAN e DMZ, e le stesse interfacce sono nello stesso security-level aggiungo:

same-security-traffic permit inter-interface

Mi serve quindi la regola di esclusione del nat tra queste due reti:

access-list no_nat_lan_dmz extended permit ip 172.16.9.0 255.255.255.0 172.16.10.0 255.255.255.0
access-list no_nat_dmz_lan extended permit ip 172.16.10.0 255.255.255.0 172.16.9.0 255.255.255.0
nat (inside) 0 access-list no_nat_lan_dmz
nat (dmz) 0 access-list no_nat_dmz_lan

Faccio le dovute prove e funziona tutto. Bene. Ora so perche dal cliente non ha funzionato (ma 0 nat non me lo ricordo proprio mai!!!). E' ora di filtrare il traffico. Le access rules rispecchiano in toto la configurazione che il cliente aveva prima, nella configurazione finale ho sistemato meglio le inspection e fatto qualche variazione di qua e la. Prima di creare le regole creo un po' di oggetti che mi serviranno per comporle:

object-group protocol tcp-udp
protocol-object udp
protocol-object tcp

che non manca mai....

object-group network fastmediaNET
network-object XX.XX.XX.XX 255.255.255.248
network-object XX.XX.XX.XX  255.255.255.248
network-object 8XX.XX.XX.XX  255.255.255.248

object-group network genesys
network-object host XX.XX.XX.XX
network-object host XX.XX.XX.XX

object-group network LanNetwork
network-object 172.16.9.0 255.255.255.0

object-group network DmzNetwork
network-object 172.16.10.0 255.255.255.0

object-group service RDP tcp
port-object eq 3389

object-group network perTCPUDP7000
network-object host XX.XX.XX.XX

Quindi creo prima le acl per la dmz:

access-list dmz_access_in extended permit object-group tcp-udp object-group DmzNetwork any eq domain
access-list dmz_access_in extended permit tcp object-group DmzNetwork any eq www
access-list dmz_access_in extended permit tcp object-group DmzNetwork any eq https
access-list dmz_access_in extended permit tcp object-group DmzNetwork any eq ftp
access-list dmz_access_in extended permit tcp object-group DmzNetwork any eq smtp
access-list dmz_access_in extended permit ip object-group DmzNetwork object-group LanNetwork

quindi le applico alla interfaccia:

access-group dmz_access_in in interface dmz

Faccio lo stesso con la lan:

access-list lan_access_in extended permit object-group tcp-udp object-group LanNetwork any eq domain
access-list lan_access_in extended permit tcp object-group LanNetwork any eq www
access-list lan_access_in extended permit tcp object-group LanNetwork any eq https
access-list lan_access_in extended permit tcp object-group LanNetwork any eq ftp
access-list lan_access_in extended permit tcp object-group LanNetwork any eq smtp
access-list lan_access_in extended permit tcp object-group LanNetwork any eq 32300
access-list lan_access_in extended permit object-group tcp-udp object-group LanNetwork object-group perTCPUDP7000 eq 7000
access-list lan_access_in extended permit tcp object-group LanNetwork any eq pop3
access-list lan_access_in extended permit tcp object-group LanNetwork any eq imap4
access-list lan_access_in extended permit ip object-group LanNetwork object-group DmzNetwork

access-group lan_access_in in interface inside

Creo i nat in ingresso, che poi in realtà sono dei port forward. Il vecchio firewall gestisce infatti il nat direttamente sulla policy e anche se ho 10 ip pubblici da utilizzare non posso modificare ne ip con cui "esce" il cliente ne ip per servizi che sono legati al DNS:

static (dmz,outside) tcp interface smtp mail-srv smtp netmask 255.255.255.255
static (dmz,outside) tcp interface ftp mail-srv ftp netmask 255.255.255.255
static (dmz,outside) tcp interface www mail-srv www netmask 255.255.255.255
static (dmz,outside) tcp interface https mail-srv https netmask 255.255.255.255
static (dmz,outside) tcp interface 3389 mail-srv 3389 netmask 255.255.255.255
static (inside,outside) tcp interface ldap dom-srv ldap netmask 255.255.255.255

A questo punto mi faccio la configurazione delle ACL per l'accesso sulla outside:

access-list wan_access_in extended permit tcp any interface outside eq smtp
access-list wan_access_in extended permit tcp any interface outside eq www
access-list wan_access_in extended permit tcp any interface outside eq https
access-list wan_access_in extended permit tcp any interface outside eq ftp
access-list wan_access_in extended permit tcp object-group fastmediaNET interface outside object-group RDP
access-list wan_access_in extended permit tcp object-group genesys interface outside object-group RDP
access-list wan_access_in extended permit tcp object-group FastmediaAntispam interface outside eq ldap

infine

access-group wan_access_in in interface outside

Poi c'è da fare qualche limatura (log, mettere in sicurezza l'accesso sull'apparato, ecc) , ma in linea di massima funziona tutto. Come già scritto in precedenza ho applicato delle class map anti IM e P2P. Ho limato ulteriormente la configurazione e messo meglio in sicurezza il tutto con AAA.

Ho perso un pomeriggio dietro ad una "cazzata". Abituato poi ai Watchguard non solo non mi ricordo i comandi ma inizialmente mi è sfuggita completamente di mente anche la logica con la quale si programmano gli ASA. Questo post mi deve servire come promemoria e un po' come monito...

Venerdi mattina sono stato da un cliente per la configurazione di un firewall/proxy. Era ora! Il lavoro nei ultimi mesi era completamente fermo stavo rischiando di andare fuori di testa rimanendo in ufficio. Installo il server, lo configuro e lo provo. Il tutto con calma e assoluto relax. Funziona, bene, mi metto a fare altre attività. Collego il mio computer alla vlan del cliente e comincio a lavorare sul loro exchange.
A distanza di qualche minuto però cominciano ad arrivare telefonate delle persone che "si scollegavano dalla rete". Eh ? Finche non sono stato coinvolto direttamente ho continuato con le mie attività. Solo che la cosa stava diventando preoccupante. C'era un bel via vai delle persone che "non lavoravano in rete"... La rete è in produzione e manda avanti un attività ... ehm ... produttiva (solo per non svelare la natura del cliente per motivi di privacy).
Insieme al responsabile facciamo i soliti controlli: rete, ok; connettività, ok... Non è che sarà il mio pc. Cazzo, se gli ho bloccato la rete sono cavoli amari.
Ad un certo momento però, il responsabile si accorge che il problema è circoscritto ad un solo server. Un loro gestionale. Ehmm... Vediamo un po' la console. Ah, però ! Sta cercando di fare boot da rete! Figata, un problema sui dischi.
Applichiamo la prima legge dell'informatica, facciamo un bel reboot. Azz. Il controller RAID sembra (altro che sembra !!!) non vedere i dischi. Meglio, il messaggio di errore è al quanto drammatico: "missconfigured"...
Stacchiamo il server e vediamo un po' che c'è dentro. Trattasi di un IBM 346 con controller raid ServeRaid 7-k. Quest'ultima scheda, sita sotto il PCI raiser si presentva cosi (cliccare per alta risoluzione):



  La batteria tampone si è gonfiata ad un livello tale che per poco non ha rotto il PCB !!! Impressionante! E' la prima volta che vedo una cosa simile... Spero che l'immagine renda e appena posso pubblico l'intero book.  Per fortuna ho fatto risalire il server con il controller senza la batteria... Per fortuna.......

Qualche tempo fa mi hanno chiesto una particolare configurazione di un router. Al di fuori della configurazione, che non presenta nessuna particolarità, l'apparato in questione è un Digicom Michelangelo UMTS. Sto coso è veramente carino, almeno per l'opzione di backup su UMTS che si risolve in maniera molto economica visto che ha uno slot per PCMCIA. Va detto che supporto delle schede è veramente scarso, ma una soluzione simile, almeno per quanto ne so io, diventerebbe un po' più costosa volendola realizzare con altri apparati.

Va detto anche che non ho visto il giocattolo della Vodafone, ma qui siamo in un ambiente totalmente vendor dipendente...

Il router di per se è un gran brutto pezzo di plastica. Se devo essere onesto sono meglio alcuni apparati rimarcati e fatti in China. Oltre alla estetica anche il software è penoso. E' molto semplice, e a tratti povero di funzionalità, ma efficace e per nulla complicato.

Insomma mi metto sto coso sulla scrivania, ci caccio dentro la mia schedina, una schifo di TIM aziendale da 64k, e configuro l'accesso UTMS. In ufficio il segnale non è male, ma potrebbe essere meglio. Comunque copertura 3G c'è, la connessione viene stabilita al volo, mi faccio un paio di sessioni su qualche sito. Faunzina e vola!!! Vola letteralmente, sembra più veloce della nostra (ehm... nostre 3) adsl!

Faccio una prova, che può anche non significare molto:

Ehhhhhhhh ?!?!?!? Dapprima non ci credo, ma visto che il traffico UMTS non lo pago io:  
Non è la mia prima esperienza con UMTS, anzi, normalmente mi collego con il cellulare-a-mo-di-modem (full hsdpa) ma non sono mai andato un gran che. Prova allora un linksys che abbiamo qui ma non c'è paragone. Sarà per la pcmcia o per il hardware del router, teoricamente 100% italiano, ma sono rimasto senza parole. Complimenti. Non ho potuto provare ADSL, che dice essere 2+, ne WiFi integrato ma l'impressione per ora è molto (molto !) positiva.

La prima volta sono stato allo Smau più di dieci anni fa. Quella volta non era diventata ancora una fiera massmediatica anche se l'afflusso di noi (allora) ragazzini era evidente. Si andava in fiera sia per vedere le figate che vi venivano presentate che per innumerevoli gadgets che chiunque ti regalava. Di solito, almeno le prime volte, si tornava con una valigia piena zeppa di borse, buste, mouspad, e innumerevoli depliants che facevano sempre la stessa fine: cestino. In ogni modo era il paese dei balocchi e un must per gli appassionati. A distanza di qualche anno però il mio interesse era scemato, la fiera è diventata un tempio dei ragazzini e di eventi più o meno scarni dal punto di vista dell'informatica professionale. Non che all'epoca fossi chi sa quanto maturo o grande, semplicemente ero entrato nel modo dell'informatica professionale e i miei interessi andavano in una direzione decisamente più specifica. Allora infatti ero diventato più interessato alla novità dal punto di vista tecnico, se poi era anche accompagnata da un confronto con qualcuno di specializzato... Non mi andava di "pogare" in mezzo ai ragazzini che rincorrevano i premi e cazzatine. Addirittura il gioco non valeva più il viaggio fino a Milano.Poi qualcosa è cambiato e la fiera ha assunto un aspetto completamente diverso. Mi ricordo che ci sono andato il primo anno della rivoluzione. Che pena. E' quella doveva essere la fiera dell'innovazione? Un misero padiglione con qualche grande vendor e poca innovazione.Sarà che ormai le informazioni le abbiamo in tempo reale. Basta che chiunque pensi solo ad un prodotto "innovativo", che due minuti dopo te lo ritrovi nei siti, e-mail o feed rss... Ma forse non è solo quello. L'idea che mi ero fatto e che gli organizzatori volevano assolutamente tornare sul professionale e "forse", secondo me, hanno un po' esagerato.Alla fine mi ero promesso di non tornare più allo Smau, anzi, ho cominciato ad orientarmi a delle fiere ed eventi più specialistici. Quest'anno però ci sono tornato. Questa volta come espositore. Non che ne avevo una grande voglia ma la mia azienda è stata ospite nello stand Telecom. Ci sono stato un giorno solo ma è bastato per capire che anche quella giornata non serviva a nulla e che la mia opinione sullo Smau sarebbe rimasta sempre la stessa. Pensavo di essere gasato all'idea di entrare con il passi di espositore ma così non è stato. La giornata è stata noiosa e per nulla produttiva. Io mio capo è dell'opinione contraria, lui si è fatto tutti quattro giorni, ovviamente lui la vede dal punto di vista commerciale.Lo stand Telecom piccolo ed era diviso in diverse sezioni una delle quali era destinata ai partner. C'è nerano diversi. Alcuni li conoscevo, come Loquendo dove ho fatto il corso o Solo In Rete (mi sa sempre a un corso), altri meno, comunque tutti hanno portato dei prodotti propri o soluzioni fatte in casa. Credo che noi eravamo l'unico partner ad aver portato solo servizi e alcuni prodotti. Per tutta la mattinata sono rimasto allo stand e per fortuna che avevo la possibilità di parlare con qualcuno, l'unico aspetto positivo della cosa. Con noi, infatti, c'era la Laser Informati, un azienda con la quale collaboriamo e la Hal Informatica, l'azienda dove prendiamo i bilanciatori. Si è parlato del più e meno e si è condiviso qualche esperienza. La mattinata è passata velocemente e senza che me ne accorgessi. Il pomeriggio però sono rimasto da solo e, sempre nel pomeriggio, ho potuto farmi un giro per la fiera. Come pensavo la fiera era veramente scarna. Addirittura è stata snobbata da diversi vendor. Credo che i megagalattici stand della Microsoft c'è li scordiamo per sempre. Due padiglioni in tutto con poco o niente. Nel primo la facevano da padrone i sistemi POS, bilance e registratori di cassa più o meno futuristici. C'erano poi alcuni stand di distributori "vendo un po' di tutto". Ho provato a fermarmi alla Endian, ma le facce annoiate dei presenti mi ha fatto cambiare subito l'idea. Annoiate forse perche era tardi, ho fatto il mio giro verso le 16, ma non solo. Uscendo a fumare una sigaretta di fuori i commenti che si sentivano erano più o meno gli stessi: "non c'è gente", "non c'è nulla" e cosi via. L'altro padiglione, caratterizzato dai stand di Ibm, BlackBerry e Telecom Italia non era da meno. Il mio interesse era rivolto a GateProtect ma più di un depliant e qualche spiegazione imparata da un powerpoint non sono riuscito ad avere.La giornata per (s)fortuna si è messa al meglio con un problema al data center. Mi sono tenuto occupato per un oretta per spostare dei servizi di un server su un altro. La cosa positiva è che la Telecom ci passava una connessione da paura. Mi facevo delle medie in download di 800k... Sarà l'aria di Milano, ma da noi ad Ancona non ci si arriva neanche morti. In conclusione non è stata una grande esperienza. Non ha rispettato le aspettative, ma forse quest'ultime erano eccessivamente grandi. Mentre me ne stavo in fila sulla tangenziale e rimuginavo sulla giornata mi era venuto in mente allora un pensiero: "l'innovazione... dov'era?"

Anche per una cosa così banale esiste un RFC ! Si tratta di un documento pubblicato nel agosto del 1990, numero 1178. Va detto che il documento non è uno standard ma soltanto una memo, come tra l'altro viene subito specificato:

This FYI RFC is a republication of a Communications of the ACM
article on guidelines on what to do and what not to do when naming
your computer [1]. This memo provides information for the Internet
community. It does not specify any standard.

Alcuni paragrafi sono ovvi altri più o meno interessanti. Per alcune reti che ho visto sta cosa andrebbe stampata a caldo sulla pelle dei relativi responsabili (o utenti).

Documento originale dal quale prende il spunto questo RFC:

Choosing a Name for your Computer

Citazione presa da: http://roseweb.de/caro/pages/security/v-one/cut-orig.htm

Direi che rende benissimo l'idea!!!

The ULTIMATELY Secure Firewall

(Adaptive Packet Destructive Filter)

Installation Instructions

• For best effect install the firewall between the CPU unit and the wall outlet. Place the jaws of the firewall across the power cord, and bear down firmly. Be sure to wear rubber gloves while installing the firewall or assign the task to a junior system manager. If the firewall is installed properly, all the lights on the CPU will turn dark and the fans will grow quiet. This indicates that the system has entered a secure state.
• For Internet use install the firewall between the demarc of the T1 to the Internet. Place the jaws of the firewall across the T1 line lead, and bear down firmly. When your Internet service provider's network operations center calls to inform you that they have lost connectivity to your site, the firewall is correctly installed.

If I had a dollar....

If I had a dollar for every time I've seen someone post "I need a 100% secure firewall, that lets me do everything" I'd be retired by now.

The fact is, that if you're connecting your network to anything else, you're running a risk. Period. Usually, that risk can be reduced, often dramatically, by employing basic security precautions such as firewalls. But a firewall is a risk reduction system, it is not a risk mitigation system -- there is, always, some danger that something can go fatally wrong with anything built by humans.

The firewall above is the only 100% guaranteed secure solution.

Ogni giorno se ne scoprono delle belle nuove... Ecco cosa dice un stupendo manuale su Exchange 2007:

Before we go any further, we'd like to introduce you to - or reacquaint you with - the single most important acronym you will ever encounter in the alphabet soup that IT professionals eat on a daily basis: RTFM, or Read The Fine Manual.

Come non dargli torto !!!