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 tutti 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.

Ricetta quick’n dirty per creare una VPN tra un client remoto ed un server, entrambi con sistema operativo Windows. Destinata a cuochi mediamente abili. Versione routed(*).

Ingredienti:

• Un host che faccia da server, con IP privato statico (es: 192.168.1.2/24), collegato ad internet, acceso 24/7 e a cui il router inoltri almeno una porta TCP(**) (Es: TCP/11900). Windows 2000 o successivi, non necessariamente Server.
• Un client con connessione ad internet con IP privato di classe diversa dal server (es: 192.168.254.0/24).
• OpenVPN.

Esecuzione:

• Generare una chiave simmetrica key.txt tramite l’apposita utility e copiarla nelle cartelle “config” di OpenVPN di entrambi gli host.
• Scegliere una terza subnet diversa da entrambe le subnet degli host coinvolti. Es: 172.30.0.0/16.
• Aggiungere sul default gateway (tipicamente il router) della rete del server una rotta statica che inoltri tutto il traffico destinato alla rete 172.30.0.0/16 verso l’IP privato del server (192.168.1.2).
• Registrarsi su DynDNS e creare un hostname per il server (es: mioserver.dnsalias.net).
• Installare sul server il client DynDNS (versione per 200x Server in fondo alla pagina) e configurarlo per usare l’hostname appena creato. Accertarsi che il relativo servizio parta automaticamente.
• Installare OpenVPN su entrambi gli host, e inserire nelle cartelle “config” di OpenVPN i ripettivi file di configurazione, con estensione .ovpn.

File: client.ovpn
remote mioserver.dnsalias.net
dev tap
proto tcp-client
rport 11900
ifconfig 172.30.1.2 255.255.0.0
route 192.168.2.0 255.255.255.0 172.30.1.1
secret key.txt
verb 3

File: server.ovpn
dev tap
proto tcp-server
lport 11900
ifconfig 172.30.1.1 255.255.0.0
secret key.txt
verb 3

• Sul server avviare il servizio “OpenVPN Server” e impostarne l’avvio automatico.
• Sul client, collegato ad internet con una connessione internet diversa dal server,  eseguire “OpenVPN GUI” in modalità amministratore, cliccare col tasto destro sull’icona nella systray e scegliere “connect”.
• Effettuare dei test di connettività. In caso di problemi, i log di OpenVPN sono molto esplicativi già a verb 3.

Guarnire con quanta più banda possibile e servire con due righe di istruzioni per l’utente.

(*)Le due reti non sono in bridging, configurazione comunque possibile ma leggermente più complicata.

(**)Si può usare anche UPD, che sarebbe il default di OpenVPN, ma su alcuni router SOHO non si possono inoltrare le relative porte.

Universal Plug and Play, secondo Wikipedia, è un insieme di protocolli di rete che permette ai dispositivi che lo implementano di semplificare drasticamente la loro integrazione all’interno di una rete. Il nome è mutuato da Plug-and-play, una tecnologia che permette di collegare un dispositivo ad un computer e averlo immediatamente pronto all’uso. La similitudine si riferisce alla possibilità di alcuni dispositivi di collegarsi, autoconfigurarsi e annunciare i propri servizi alla rete senza necessità di configurazione preventiva. Per tutti i particolari più tecnici, vi rimando alla voce di Wikipedia che ho linkato qui sopra.

Una delle categorie di oggetti che supportano UPnP sono i router per uso casalingo o per piccoli uffici (SOHO), che tramite un’estensione del protocollo, detta Internet Gateway Device Protocol, permettono ai client in grado di sfruttare la tecnologia di compiere una serie di azioni; le più comuni sono il reperimento dell’indirizzo pubblico della connessione, la lista della tabella di inoltro delle porte TCP e UDP e la relativa modifica.

Proprio questo ultimo aspetto contribuisce a semplificare parecchio la vita degli utenti: per pubblicare un servizio o abilitare il traffico in ingresso verso un client è necessario configurare il NATP sul router, il che richiede conoscenze tecniche non banali. Se il software che stiamo utilizzando ed il router supportano UPnP è sufficiente assicurarsi che le rispettive voci siano abilitate e non ci sarà bisogno di fare nessuna configurazione.  L’esempio più comune sono i software P2P: per massimizzare la velocità di trasferimento è necessario che il traffico in ingresso su una o più porte TCP sia inoltrato verso il client su cui sta girando il software; programmi come µTorrent o Transmission sono in grado di configurare autonomamente il router in modo da ricevere il traffico entrante, rendendo il trasferimento molto più veloce.

Sfortunatamente, in tutto questo c’è un problema: UPnP non supporta l’autenticazione e presume che tutti gli host della rete siano sicuri e a tutti garantisce i privilegi sufficienti per effettuare modifiche alla configurazione, il che potrebbe rappresentare un buco nella sicurezza; è stato ipotizzato che un programma Flash opportunamente scritto potrebbe aprire alcune porte nel router all’insaputa dell’utente, esponendo quindi il client all’attacco dall’esterno con una semplice visita ad un sito contenente codice malevolo, anche se a memoria non ricordo di aver mai sentito parlare di qualcosa del genere. Per questo motivo, e per il fatto che si tratta comunque di un protocollo di cui l’utente è meglio sia al corrente, su parecchi dispositivi è disabilitato per default e va abilitato esplicitamente: controllate sul vostro router.

Scenario: un firewall con due interfacce WAN collegate a due router ADSL e configurate in failover. Cade la linea principale e la rete perde connettività: cosa è successo?

Ad una prima indagine mi accorgo che tutti gli host accedono regolarmente ad internet via linea di backup ma non funziona la risoluzione dei nomi, quindi è praticamente tutto fermo. La rete è servita da un Windows 2003 server che, tra gli altri, ha i ruoli di DNS server, mail server e webmail server.

La causa della risoluzione  non funzionante è il server che, scopro, non ha connessione ad internet. Come è possibile che tutta la rete acceda ad internet tranne il server? Verificato che il firewall non abbia policy restrittive e spulciati i log relativi, mi concentro sulla sua tabella di NAT.

Dato che il server è pubblicato per i servizi SMPT e HTTP, esiste una regola esplicita che natta l’IP privato sull’IP pubblico della WAN primaria, e fin qui tutto bene. Dopo una telefonata chiarificatrice con un collega, mi rendo conto che manca completamente la regola che NATti il server anche sull IP pubblico della linea di backup. Modifico la regola principale esplicitando l’interfaccia di outbound, che prima era ANY, e creo un’altra regola per il NAT sull’IP di backup, sulla relativa interfaccia. Come per magilla, la connettività riappare e il server DNS ricomincia a fare il suo mestiere.

Le VPN verso le sedi remote vengono riattivate facendo modificare alle filiali l’IP del peer da cui la connessione viene accettata, e specificando nel “local ID peer” l’IP pubblico della connessione di backup perché il router relativo, in comodato d’uso, fa a sua volta un NAT. Al momento del ripristino della linea principale, si effettuerà un rollback delle modifiche.

Per scongiurare problemi in futuro, rimangono da fare i seguenti passi:

• configurare un record backup MX nel DNS del dominio di posta, in modo che i messaggi possano essere anche ricevuti, oltre che inviati, quando è attivo il failover;
• aggiungere una regola di NAT sulle interfacce opportune per pubblicare l’IP privato del server anche sull’indirizzo pubblico della linea di backup.

Perché tutto ciò non è stato testato prima della messa in produzione? Per i soliti motivi: uno dei due provider tardava a fornire la connettività di backup e l’altro ha sbagliato il contratto modificando in corso d’opera la classe degli IP pubblici assegnati; Il cliente aveva bisogno di lavorare da subito e non c’è mai stato modo di fare un collaudo vero e proprio.

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.

Quasi ogni volta che mi imbatto in un IBM AS/400 ho sempre lo stesso problema: il server è irraggiungibile dall’esterno della sua subnet. Anche se firewall, router, NAT, frizzi lazzi e mazzi sono perfettamente configurati, non si riesce ad accedere dall’esterno, fosse anche la subnet a fianco, la WLAN o la DMZ.

Ormai vado a colpo sicuro e chiamo il sistemista AS: so già che manca il default gateway nella configurazione di rete dell’AS che, in queste condizioni, non è in grado di indirizzare i pacchetti dove potranno essere adeguatamente ruotati instradati.

Del perché mi imbatta spesso in questo problema, mi sono fatto un paio di convinzioni: intanto nella maggior parte dei casi questi baracconi son talmente vecchi che vanno ancora a legna, e all’epoca della loro installazione non si usava neppure il TCP/IP, preferendo lo SNA 5250; figuriamoci se c’era la necessità di uscire dalla subnet. Costretti dalla diffusione di Ethernet a scapito di Twinax a passare a TCP/IP, i sistemisti AS, un po’ pigri un po’ capre, hanno spesso omesso di configurare completamente i parametri di rete, limitandosi a compilare indirizzo IP e subnet mask.

Preferisco evitare di mettere le mani in quei cosi, meglio chiamare chi li conosce bene.

Lo studio medico di un amico ha una rete di computer non recentissimi, che utilizzano esclusivamente un applicativo client-server il cui motore gira su server Windows 2003. Niente Office, niente mail, niente altro.
La rete non aveva connessione ad internet, e grazie a questo tutto ha funzionato perfettamente fino ad ora: le macchine, benché vecchie, sono veloci, non hanno antivirus né spazzatura inutile installata; non sono mai intervenuto per alcun problema che non fosse la morte naturale di un PC, e il mio lavoro finora si era limitato all’installazione del server e di qualche stampante di rete.(*)

Si è presentata la necessità di collegare via internet lo studio con la ASL per la prenotazione online degli esami diagnostici, ed io ho cominciato a sudare freddo. Per fortuna Claudio è molto ragionevole ed ha capito subito le mie perplessità, abbiamo quindi convenuto che la cosa migliore da fare fosse filtrare l’accesso ad internet permettendo solo il traffico verso il sito dedicato, escludendo tutto il resto.

Trattandosi di una fase di test, per il momento ho preferito non far spendere allo studio qualche centinaio di euro per l’acquisto di un firewall; per diversi motivi l’istallazione di un vecchio PC che facesse da gateway non era praticabile/desiderata, quindi ho riflettuto su quale potesse essere la soluzione più semplice.

Scartata l’ipotesi di un proxy, ho deciso di installare DNS sul server, disabilitando le query ricorsive. Questa impostazione fa sì che la risoluzione dei nomi di domino venga fatta dal server esclusivamente con le sue risorse, senza inoltrare la richiesta ai suoi forwarders.

A questo punto, andando in gestione DNS, nelle “Zone di ricerca diretta” è sufficiente aggiungere una nuova zona per il dominio di secondo livello che si desidera risolvere, ed aggiungere al suo interno gli host A che ci servono, specificandone l’IP pubblico, risolto in precedenza tramite nslookup su un PC con un normale accesso ad internet. La procedura funziona anche con i domini di terzo e quarto livello.

Una volta installato il router, e configurato il servizio DHCP in modo che serva il corretto indirizzo del server DNS, il gioco è fatto: i client sono in grado di navigare solo sul sito la cui zona  stata configurata sul server, mentre il resto dei domini non vengono risolti poiché sono state disabilitate le query ricorsive.

E’ chiaro che si tratta di un metodo rudimentale, ma fa quello che deve fare senza troppe complicazioni.

Contro:

• Non è il massimo dell’eleganza.
• E’ facilmente aggirabile da un utente esperto.
• Va bene se la navigazione deve essere permessa solo verso pochi domini, dopodiché scala molto male.
• Se i domini da risolvere cambiano IP, la modifica non si propaga e ci costringe a modificare a mano gli indirizzi.
• Non blocca la navigazione tramite indirizzo IP.

Pro:

• E’ gratuito.
• Si configura in 10 minuti.
• Si basa su un servizio robusto (DNS di Microsoft lo è), e non richiede software di terze parti.
• E’ di semplice implementazione.
• Riduce il numero di asset da gestire.

(*) Questo dimostra quello che predico da sempre: PEBKAC.

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.

Nota veloce su Wireshark: per filtrare la visualizzazione dei pacchetti che contengono l’indirizzo IP 192.168.0.1 si usa l’espressione:

ip.addr==192.168.0.1

per filtrare i pacchetti che non lo contengono, saresti tentato di usare:

ip.addr!=192.168.0.1

che però non funziona: l’espressione sarà comunque vera per pacchetti dove la sorgente o la destinazione sono uguali a 192.168.0.1, perché sarà comunque diverso rispettivamente l’IP destinazione o sorgente. L’espressione viene letta come: “i pacchetti che contengono un campo ip.addr con un valore diverso da 192.168.0.1″; dato che i campi sono due, sorgente e destinazione, e almeno uno dei due è diverso da 192.168.0.1, il filtro non si comporta come penseresti.

Per escludere tutti i pacchetti da e per l’host 192.168.0.1 devi usare la seguente espressione:

!(ip.addr == 192.168.0.1)

che viene letta come “mostrami tutti i pacchetti per i quali è falso che almeno uno dei due campi indirizzo sia uguale a 192.168.0.1″

A volte leggere la guida in linea serve. Buone sniffate.

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”).