Pare che la moda del momento sia chiedere che i propri dipendenti non usino Facebook e non chattino su MSN. Pur non essendo d’accordo, credo si tratti di una richiesta lecita se fatta da chi paga sia le persone che la banda(*).

I sistemi di content filtering possono essere costosi e/o impegnativi nella manutenzione per aziende di piccole dimensioni che magari dispongono a malapena un firewall. Ci sono un paio di tecniche che permettono di filtrare abbastanza agevolmente senza dover fare alcun investimento. Il principio è controllare le query DNS, intercettando i domini da bloccare e/o utilizzando l’apposito servizio gratuito fornito da OpenDNS. Della situazione speculare, il blocco totale con pochi domini in whitelist avevo già parlato qui.

Come spesso accade, in azienda c’è un piccolo server Windows 200x o Small Business Server che adempie alle solite funzioni (AD controller, file e print server, DNS, DHCP ecc ecc.); concentriamoci sul DNS. In questo esempio mi interessa bloccare il traffico verso Facebook, quindi ne carico una pagina e do una scorsa al sorgente HTML, dal quale mi accorgo che gli unici domini interessati sono Facebook.com e fbcdn.net. Provvedo quindi a creare due nuove zone di ricerca diretta primarie, integrate in AD e replicate su tutti i server DNS proprio per quei due domini (facebook.com e fbcdn.net).

Il risultato di questa operazione sarà che il mio server sarà convinto di essere autoritativo per i domini in questione e non si preoccuperà di recuperare dai suoi forwarder, o dai root server, l’indirizzo IP degli host di quei domini(**). Non avendo alcun record di tipo A definito, restituirà al client un messaggio di host sconosciuto (“www.facebook.com non esiste“); otteniamo così il risultato di rendere Facebook non raggiungibile. (Naturalmente devo attendere che la cache DNS sui client sia scaduta o forzarne il refresh con ipconfig /flushdns)

Per evitare che un utente più smaliziato usi un server DNS pubblico, bisogna bloccare sul firewall tutto il traffico in uscita sulla porta 53 sia TCP che UDP, tranne quello proveniente dai server DNS interni.

Per bloccare Messenger e per un controllo su altre categorie di siti, si può usare il servizio gratuito offerto da OpenDNS, dove basta registrarsi, configurare il proprio server DNS con gli appositi forwarder, registrare e confermare il proprio network seguendo le semplici indicazioni (c’è anche un client per chi non ha un IP pubblico statico) e attivare il content filtering. Questo è un esempio di configurazione che blocca Messenger ed altre categorie di siti.

Queste impostazioni che vedete sono disponibili anche nella versione gratuita, che assolve egregiamente ai suoi scopi. Si possono anche specificare singoli domini da blacklistare. Il servizio offre anche un po’ di statistiche. Le pagine bloccate vengono catturate e viene restituita una pagina con messaggi personalizzabili e logo dell’azienda.

E’ evidente che questi metodi non resistono ad un utente con competenze evolute (non riuscirete a bloccare il traffico a un ufficio di sistemisti), ma per la maggior parte dell’utenza è uno scoglio insormontabile.

Pregi:

• Sono gratuiti.
• Sono molto semplici da implementare.
• Sono facili da spiegare ai clienti.
• Richiedono pochissima manutenzione.
• Sono adatti a aziende piccole o medio-piccole.
• Sono facilmente reversibili alla configurazione “tutto aperto”.

Difetti:

• Pasticciare con le query DNS non è affatto elegante.
• Ci si affida a un servizio esterno con tutto ciò che ne consegue in termini di sicurezza, privacy e continuità del servizio.
• Utilizzare un servizio come OpenDNS che raccoglie un database di query e lucra sul traffico rediretto è comunque un compromesso.
• Non scalano bene nel caso le esigenze di controllo diventino più granulari.
• Non sono adatti ad aziende più grandi con infrastrutture più complesse.

(*)Ulteriori considerazioni sul filtrare i contenuti internet sono al di fuori dello scopo di questo post.

(**)Semplificazione. Per una spiegazione più approfondita, leggimi qui.

Tapullo: “Non esiste parola che si possa paragonare a Tapullo. Trattasi di riparazione di fortuna che spesso dura nel tempo e aggiunge nuove funzionalità (…). I Genovesi, da sempre parsimoniosi, sono abili nei Tapulli. I Tapulli vengono mostrati con fierezza agli amici, alcuni diventano perfino leggendari e spesso i grandi marchi vi si ispirano per migliorare i propri prodotti. A volte viene usato il termine per denigrare una riparazione di fortuna (raro), o per indicare una soluzione temporanea (più comune).” Fonte.

Iperf è uno strumento per misurare l’ampiezza di banda di cui avevo già accennato qui. Il sito originale nel frattempo è sparito ma si trovano parecchi tutorial, dei quali vi segnalo questo. Per fortuna il progetto non è stato del tutto abbandonato e sebbene il codice originale sia sempre lo stesso, Google Code ospita JPerf.

Si tratta di un frontend grafico pensato per semplificare l’utilizzo di Iperf e aggiungere dei grafici abbastanza gradevoli. Permette di salvare risultati e configurazione mentre per i grafici ci si deve arrangiare con uno screenshot, almeno al momento. Si basa su Java ed è quindi multipiattaforma.

Molto utile per la redazione delle relazioni tecniche, croce e deliza dei sistemisti; ha il vantagio di produrre risultati abbastanza comprensibili anche per i non addetti ai lavori, perlomeno con le impostazioni predefinite.

Ritorno sulle impostazioni e parametri delle connessioni ADSL Telecom di tipo business per puntualizzare alcune cose.

I parametri della linea sono: VPI e VCI rispettivamente 8 e 35, encapsulation LLC, QoS UBR, protocollo RFC1483 routed. Per questo tipo di linea vengono forniti in genere almeno quattro IP fissi, ed il foglio che lascia l’omino Telecom contiene due classi di indirizzi chiamati IP LAN e IP punto-punto (o IP WAN).

Se avete un router di proprietà, ecco come impostarlo.

Intanto fatevi un’idea di come sono fatte le classi di indirizzi; nessuno fa i conti a mano, utilizzate l’ottimo Online IP calculator.

Facciamo un esempio pratico(*): sul foglio, spesso scritto a mano con pessima calligrafia e fotocopiato da una Xerox degli anni ’50, ci sono:

IP LAN: 78.62.124.200 / 255.255.255.248. Il tool ci dice che abbiamo a disposizione una classe da 8 indirizzi (78.62.124.200 – 78.62.124.207), di cui possiamo utilizzarne 6, poiché il primo (.200) identifica la rete e l’ultimo (.207) il broadcast.

Punto-punto: 84.81.188.200 / 255.255.255.252    Stessa cosa: ma solo 4 indirizzi (84.81.188.200 – 84.81.188.203 ) con 2 utilizzabili.

A questo punto impostiamo IPoA (IP over ATM) e mettiamo nell’indirizzo IP della connessione (lato WAN) 84.81.188.202, subnet 255.255.255.252 e gateway 84.81.188.201. Questo perché il gateway di Telecom è sempre il primo indirizzo disponibile.

Nell’indirizzo LAN del router va inserito uno degli IP pubblici forniti. Scegliamo il primo, 78.62.124.201 con subnet 255.255.255.248. Questa configurazione è routing “puro”, e il NAT andrà disabilitato poiché nei modelli più semplici di router non è possibile assegnare due IP all’interfaccia LAN, oltretutto NATtandone uno solo; per questo siete praticamente obbligati ad installare un firewall con WAN 78.62.124.202, subnet 255.255.255.248 e gateway 78.62.124.201 (l’interfaccia LAN del router). IP LAN e NAT andranno configurati in conseguenza della classe di indirizzi privati che utilizzate nella vostra rete locale.

Naturalmente nessuno di Telecom vi dirà nulla di tutto questo, lo dovrete scoprire da soli.

(*) gli indirizzi sono assolutamente inventati.

Iperf è uno strumento per misurare l’ampiezza di banda su TCP, abbastanza flessibile, open source e disponibile per diversi sistemi operativi.

Ecco le caratteristiche:

• TCP
  • Measure bandwidth
  • Report MSS/MTU size and observed read sizes.
  • Support for TCP window size via socket buffers.
  • Multi-threaded if pthreads or Win32 threads are available. Client and server can have multiple simultaneous connections.
• UDP
  • Client can create UDP streams of specified bandwidth.
  • Measure packet loss
  • Measure delay jitter
  • Multicast capable
  • Multi-threaded if pthreads are available. Client and server can have multiple simultaneous connections. (This doesn’t work in Windows.)
• Where appropriate, options can be specified with K (kilo-) and M (mega-) suffices. So 128K instead of 131072 bytes.
• Can run for specified time, rather than a set amount of data to transfer.
• Picks the best units for the size of data being reported.
• Server handles multiple connections, rather than quitting after a single test.
• Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.
• Run the server as a daemon.
• Run the server as a Windows NT Service
• Use representative streams to test out how link layer compression affects your achievable bandwidth.
• A library of useful functions and C++ classes.

Permette di controllare l’effetto della variazione di diversi parametri tipo la TCP windows size o l’MTU, supporta IPV6 e ha diverse opzioni per girare come demone o servizio.

Senza scendere in usi troppo esoterici è utile per controllare la banda a disposizione tra due siti connessi via WAN e/o VPN. L’uso più semplice è lanciare

iperf -s

sull’host “server” e

iperf -c IP_HOST_SERVER

sul client, e dopo qualche secondo apparirà il responso. La porta di default su cui deve poter essere raggiunto il server è la 5001/TCP. Ripetere in senso inverso per valutare le performance nei due sensi della connessione. (Vi ricordo che la “A” di ADSL sta per “Asymmetric”).