WARP la VPN di Cloudflare per il Mobile

Warp la VPN Mobile di Cloudflare

 

Cloudflare e’ ormai un’azienda affermata, tanto quanto Akamai o Amazon…..; in pratica CloudFlare è un sistema di reverse proxy con funzioni di CDN (Content Delivery Network), è dunque un servizio che si interpone tra il server dove viene ospitato il tuo sito ed i tuoi visitatori, svolgendo anche funzioni di caching, velocizzando cosi ulteriormente le performance del tuo sito.
Ma non si limita alla distribuzione dei contenuti statici (come potrebbe fare una normale CDN), infatti offre numerose funzionalità per aumentare la sicurezza, ottimizzare i siti, velocizzare le risoluzioni dei DNS e proteggerti dagli attacchi DDOS.

Ad oggi, con oltre il 39% dei domini DNS gestiti, Cloudflare gestisce una delle più grandi e autorevoli reti DNS al mondo, non a caso Cloudflare ha sviluppato un servizio di risoluzione “DNS Resolver” ad hoc (il famoso IP 1.1.1.1) che nulla ha da invidiare a quello di Google o di OpenDNS.

Non pago, Cloudflare, dopo aver lanciato il suo DNS Resolver 1.1.1.1, si è focalizzata nello sviluppo di soluzioni consumer per migliorare la privacy e la sicurezza per la navigazione sul web, infatti e’ notizia recente che 1.1.1.1 DNS è solo un tassello di una strategia ben più vasta di Cloudflare, e proprio in questi giorni infatti l’azienda ha lanciato il suo nuovo servizio VPN, chiamato WARP, pensato appositamente per gli utenti mobile.

Possiamo affermare in tutta tranquillita’ che oggi, gran parte degli utenti di Internet utilizza uno smartphone per interfacciarsi con la Rete. Tuttavia i protocolli Internet, come ad esempio il TCP, sono stati progettati in modo specifico per delle reti wired (rete standard cablata LAN) quindi non riescono ad offrire le medesime performance con le grandi reti wireless.

E’ per questo motivo che il team di Cloudflare ha sviluppato un servizio VPN ottimizzato per i dispositivi che sfruttano unicamente le reti wireless, come appunto gli smartphone. Warp è stato creato basandosi sul protocollo UDP (User Datagram Protocol) e su WireGuard, che e’ il successore di OpenVPN (ne parleremo nel prossimo articolo).

Le caratteristiche del protocollo UDP sono le seguenti:

  • E’ un protocollo non orientato alla connessione, utilizzato quando l’affidabilità, il cui controllo viene richiesto ai protocolli applicativi che ne fanno uso, non è il target primario.

Ma se per il protocollo UDP l’affidabilita’ non e’ il target primario, perche’ e’ stato scelto proprio questo protocollo, rispetto al TCP ??

Perché UDP

Come appena spiegato, a differenza del TCP, UDP ha la caratteristica di essere ” connection less “, inoltre non si occupa di gestire il riordinamento dei pacchetti né la ritrasmissione di quelli persi.

Per tali motivi solitamente è considerato meno affidabile di TCP, tuttavia UDP è molto rapido nelle sue operazioni, visto che non presenta latenza per il riordino e la ritrasmissione. Quindi risulta essere molto efficiente quando implementato, ad esempio, nei sistemi VOIP.

Perché WireGuard

WireGuard e un protocollo che implementa una virtual private network per creare connessioni sicure Point-to-Point in configurazione routed o bridged. Inoltre viene eseguito come modulo nel kernel Linux ed in certi contesti permette di avere prestazioni migliori rispetto ad altri protocolli simili come i ben piu’ conosciuti IPsec o OpenVPN.

WireGuard utilizza alcune specifiche tecnologie per la gestione della criptografia come, Curve25519 per lo scambio chiavi, ChaCha20 e Poly1305 per l’autenticazione e BLAKE2s per l’hashing. Queste permettono a WireGuard di impattare in modo molto contenuto sui consumi energetici e di rete dei dispositivi mobile.

Perche’ WARP

Perche’ Warp, non solo permette di ottenere buone performance con gli smartphone, ma offre anche tutte le features di privacy e sicurezza disponibili con il servizio DNS Resolver 1.1.1.1.

Dopo i tanti scandali sulla privacy, possiamo aggiungere con un certo piacere che, tra le caratteristiche di Warp c’e’ quella di non salvare i log di navigazione degli utenti, poiche’ il suo modello di business non è incentrato sulla vendita di dati a società terze, prova ne e’ che non è nemmeno necessario inserire i propri dati personali per utilizzare l’applicazione associata.

Attualmente Warp è gratuito anche se il team di Cloudflare è al lavoro per realizzare anche un servizio premium chiamato Warp+, basato sul virtual private backbone dell’azienda californiana e sulla tecnologia Argo.

Semplificate i vostri Firewall

Ipset facilita il Firewall

Ipset facilita il Firewall

Facilitare la gestione del Firewall usando IPSET

Premessa
iptables, che fa parte del più ampio framework netfilter, è notoriamente il tool in user-space destinato alla definizione delle regole di firewall del kernel Linux.

Ipset è una estensione per iptables che permette la creazione di regole firewall applicabili contemporaneamente ad interi insiemi di indirizzi. A differenza di quanto avviene nelle normali catene iptables, che sono memorizzate e traversate linearmente, i sets sono memorizzati in strutture dati indicizzate, caratteristica che ne rende la consultazione molto efficiente, anche in presenza di sets voluminosi, oltre che in situazioni dove è facile immaginarne l’utilità, come il blocco di lunghe liste di “bad” hosts senza doversi preoccupare dell’eccessivo impiego di risorse di sistema o della congestione di quelle di rete, ipset offre anche un nuovo approccio a determinati aspetti inerenti la progettazione di un firewall, semplificandone la configurazione.

Ipset e’ composto da due parti, un modulo kernel e, uno strumento di amministrazione, alcune distribuzioni includono anche dei wrapper di servizio per caricare configurazioni ipset al boot, come l’ipset-service di Fedora.

Prima di proseguire è doveroso spendere un po’ di tempo a rinfrescare alcuni concetti fondamentali di iptables.

In sintesi, la configuratione di un firewall iptables consiste di un set di “chains” built-in (raggruppate in quattro “tables”) che contengono ciascuna una lista di regole o “rules”.

Per ciascun pacchetto, in ciascuna fase del suo trattamento, il kernel consulta la chain appropriata per determinarne il destino.
Le chains vengono consultate in rigoroso ordine, basato sulla direzione del pacchetto (remoto->locale, remoto->remoto oppure locale->remoto) e la sua fase corrente di trattamento o processing (prima o dopo il “routing”).

Il pacchetto viene confrontato con ciascuna delle regole della chain, nell’ ordine, fino a che non viene trovata una corrispondenza. Una volta che ciò avviene, viene intrapresa la azione specificata nel target della regola.
Se viene invece raggiunta la fine della chain senza trovare una corrispondenza, viene intrapresa la azione target di default per la catena, o policy.

Una chain non è altro che una lista ordinata di regole, ed una regola non è altro che una combinazione corrispondenza/target.
Un semplice esempio di corrispondenza è “TCP destination port 25″.
Un semplice esempio di target può essere “scarta il pacchetto” (DROP).
I targets possono anche redirigere ad altre chains definite dall’utente, cosa che fornisce un meccanismo per raggruppare e suddividere le regole seguendo una logica.
Ciascun comando iptables destinato a definire una regola, corto o lungo che sia, è composto di tre parti fondamentali che specificano la table/chain, la corrispondenza (match) ed il target

Per creare una completa configurazione firewall, occorre di fatto mandare in esecuzione una serie di comandi iptables, in uno specifico ordine.

ipset
ipset è una “match extension”, cioè una estensione basata sulla definizione di corrispondenze, per iptables.
Per poterla usare è prima necessario creare e popolare dei “sets” univocamente chiamati utilizzando il tool a linea di comando ipset, e successivamente fare riferimento a tali sets in una o più regole iptables.

Un set può essere semplicemente una lista di indirizzi archiviata per un efficiente ritrovamento.
Prendiamo come riferimento i seguenti normali comandi iptables destinati a bloccare il traffico in ingresso proveniente da 201.121.12.1 e 202.121.12.2:

# iptables -A INPUT -s 201.121.12.1 -j DROP
# iptables -A INPUT -s 202.121.12.2 -j DROP

La sintassi che specifica la corrispondenza (-s 201.121.12.1) significa “i pacchetti il cui indirizzo di origine è 201.121.12.1″. Per bloccare sia 201.121.12.1 che 202.121.12.2, devono venire definite due distinte regole iptables con due distinte specificazioni di corrispondenza (una per 201.121.12.1 ed una per 202.121.12.2).

In alternativa, i seguenti comandi ipset/iptables servono ad ottenere lo stesso risultato:

# ipset -N myset iphash
# ipset -A myset 201.121.12.1
# ipset -A myset 202.121.12.2
# iptables -A INPUT -m set --set myset src -j DROP

I comandi ipset appena visti creano un nuovo set (myset, del tipo iphash) con due indirizzi (201.121.12.1 e 202.121.12.2).
Il successivo comando iptables fa quindi riferimento al set specificando la corrispondenza con -m set –set myset src, che significa “i pacchetti il cui source header è compreso nel set di nome myset”.
Il flag src significa che la corrispondenza deve avvenire su “source”. Analogamente il flag dst avrebbe spostato la corrispondenza su “destination”, mentre il flag src,dst avrebbe riguardato sia source che destination.

Nella seconda versione è richiesto un solo comando iptables, indipententemente da quanti indirizzi IP siano presenti nel set.
Anche se fossero migliaia, sarebbe necessaria sempre una singola regola iptables, mentre l’approccio tradizionale, senza il vantaggio offerto da ipset, richiederebbe migliaia di regole.

Tipi di set
Ciascun set è di uno specifico tipo, che definisce che genere di valore possa esservi memorizzato (indirizzi IP, networks, porte ecc.) così come debba essere ricercata la corrispondenza (ovvero, quale parte del pacchetto debba essere controllata e come debba essere confrontata coi valori presenti nel set).
Oltre ai tipi più comuni, che controllano gli indirizzi IP, ne sono disponibili addizionali che si riferiscono alla porta, sia all’indirizzo IP che alla porta contemporaneamente, oppure contemporaneamente al MAC address e all’indirizzo IP, ecc.

Ciascun tipo di set ha le proprie regole per tipo, range e distribuzione dei valori che può contenere.
Differenti tipi di set usano anche differenti tipi di indici e risultano ottimizzati per differenti scenari. La scelta del migliore o più efficiente tipo di set dipende quindi dalla situazione.

I tipi più flessibili di set sono iphash, che archivia liste di indirizzi IP arbitrari, e nethash, che archivia liste di networks eterogenee (IP/mask) di varie dimensioni. Si faccia comunque riferimento all man page di ipset per un elenco completo ed una descrizione di tutti i tipi di set.

È anche disponibile il tipo speciale setlist, che consente di raggruppare insieme differenti sets in un set unico.
È vantaggioso se si desidera, ad esempio,avere un singolo set che contenga sia singoli indirizzi IP che networks.

Faccio ora un esempio per capire meglio la potenza di ipset:

Limitare l’accesso restringendolo solo a certi hosts pubblici da parte di certi PC della rete locale
Supponiamo che nell’ufficio di cui gestite la rete passino spesso stagisti e che il megadirettore sia molto infastidito dall’idea che questi impiegati, Pippo, Pluto e Paperino possano passare il tempo a trastullarsi con Internet invece di lavorare e vi chieda di limitare l’accesso da parte dei loro PCs a uno specifico set di siti cui è necessario collegarsi solo per lavoro.
Per limitare i tre PC (192.168.0.5 è quello di Pippo, 192.168.0.6 quello di Pluto e 192.168.0.7 quello di Paperino) ad accedere solamente a corriere.it, repubblica.it e inps.it, si possono utilizzare i seguenti comandi:

# ipset -N limited_hosts iphash
# ipset -A limited_hosts 192.168.0.5
# ipset -A limited_hosts 192.168.0.6
# ipset -A limited_hosts 192.168.0.7
# ipset -N allowed_sites iphash
# ipset -A allowed_sites corriere.it
# ipset -A allowed_sites repubblica.it
# ipset -A allowed_sites inps.it
# iptables -I FORWARD \
-m set --set limited_hosts src \
-m set ! --set allowed_sites dst \
-j DROP

Questo esempio effettua un confronto con due sets in una singola regola. Se il l’indirizzo sorgente è compreso in limited_hosts e la destinazione non è compresa in allowed_sites, il pacchetto viene semplicemente scartato (a limited_hosts è permesso comunicare solamente con allowed_sites).

Si noti che dato che questa regola si trova nella chain FORWARD, non riguarda le comunicazioni da e verso il firewall stesso nè il traffico interno.

Cosi’ come per iptables, ipset vi permette di caricare le regole da un file ed effettuare l’output in un formato adatto al caricamento, nel seguente modo :

# ipset save > /path/to/ipset.save
# ipset restore < /path/to/ipset.save

Ipset vi permettera’ di mantenere la configurazione del vostro firewall piu’ corta, leggibile e molto piu’ facile da mantenere. Se vi servono ulteriori informazioni potete visitare il sito del progetto http://ipset.netfilter.org

 

#IpsetfacilitailvostroFirewall

HAPROXY – ed il bilanciamento di carico e’ servito

HAProxy Load Balancing

HAProxy Load Balancing

Bilanciamento, chi è costui?
Quando pensiamo a come implementare un servizio web, solitamente lo immaginiamo erogato da potenti server che, all’occorenza, sono in grado di scalare in automatico in modo da garantirne la continuità.
Ma con i nuovi servizi cloud ad alta frequentazione, la mole di accessi che deve essere trattata sara’ talmente elevata da mettere in crisi qualunque configurazione.

Come evitare una situazione del genere? Utilizzare ulteriore hardware, più potente, potrebbe non essere sufficiente, inoltre gestire una configurazione composta da sempre più server richiede l’introduzione di un “oggetto” capace di distribuire le connessioni su tutte le macchine installate.

L’oggetto a cui facciamo riferimento è un Load Balancer (bilanciatore di carico), capace di distribuire tutte le connessioni entranti tra i vari server assegnati alla funzionalita’ del nostro servizio.
Così facendo sara’ possibile:

  • migliorare l’alta affidabilità del servizio, perchè le richieste verranno sempre e solo, indirizzate ai server “attivi”;
  • migliorare la disponibilità del servizio, perchè le richieste verranno inviate ai server meno “carichi” in quel momento.

La soluzione: HAPROXY
Esistono molte soluzioni commerciali in tema di Load Balancing, ma può essere più interessante, sfruttabile, performante e conveniente, ricorrere a prodotti Open Source e, tra questi, c’è HAPROXY.
HAPROXY (http://www.haproxy.org/) è un bilanciatore in grado di gestire sia connessioni HTTP/HTTPS che connessioni di tipo TCP.

Utilizzo
Per prendere coscienza di quali siano le potenzialità di HAPROXY, proviamo a fare due esempi d’impiego delle funzionalità di bilanciamento, una dedicata ad un servizio di puro HTTP, e l’altra dedicata a bilanciare un servizio esclusivamente TCP.
Per provare le funzionalità di HAPROXY ho realizzato un ambiente virtuale con vagrant costituito da tre macchine virtuali:

  • 1 macchina Gentoo (molto leggera e performante) utilizzata come bilanciatore (loadbalancer)
  • 2 macchine Ubuntu utilizzate come server da bilanciare (web1 e web2)

Installiamo HAPROXY  sulla macchina Gentoo, attraverso il comando:

emerge haproxy

Mentre sulle macchine Ubuntu procediamo con l’installazione di Apache utilizzando il comando:

apt-get install apache2

Tutte le macchine sono state collegate alla stessa rete: 192.168.0.0/24:

  • loadbalancer: configurato con l’indirizzo fisico 192.168.0.254, e con due alias, per i servizi bilanciati, 192.168.0.253 e 192.168.0.252.
  • web1: indirizzo 192.168.0.31.
  • web2: indirizzo 192.168.0.32.

Si ricorre all’uso degli alias di rete per poter pubblicare i due servizi di bilanciamento su indirizzi distinti; in alternativa sarebbe stato possibile pubblicare tutti i servizi di bilanciamento sullo stesso indirizzo fisico del server loadbalancer, perché, nel nostro caso, le porte di ascolto dei due servizi sono comunque differenti; ovviamente, se si vogliono bilanciare più servizi che ascoltano sulla stessa porta l’impiego degli alias è inevitabile.

La configurazione di un servizio di bilanciamento in HAPROXY, può essere realizzata definendo una sezione di “frontend” ed una di “backend”; la prima serve per definire il punto di accesso dei client (internet), mentre la seconda viene utilizzata per definire l’insieme dei server a cui inviare le connessioni da bilanciare.
In alternativa, è possibile configurare un’unica sezione, “listen”, in cui vengono racchiuse sia le direttive che verrebbero utilizzate per configurare le sezioni di “frontend” e di “backend”.

Esempi di impiego di HAPROXY
Il file di configurazione del servizio si trova in /etc/haproxy/haproxy.cfg.

La configurazione di Haproxy è stata impostata per includere una sezione in cui inserire i parametri che agiscono a livello globale (“global”), nel nostro caso viene configurato il log degli eventi.
Viene poi configurata una sezione in cui riportare tutte quelle impostazioni che costituiranno la base di ciascun servizio bilanciato (sezione “defaults”).

global
log /dev/log local0
log /dev/log local1 notice

defaults
timeout client 5000
timeout connect 5000
timeout server 5000

Nella sezione “defaults” sono quindi impostati i valori dei timeout:

  • i timeout di inattività lato client mentre si attende una risposta dal server (timeout client);
  • i timeout di attesa di attivazione di una connessione al server (timeout connect);
  • il timeout di inattività lato server (timeout server).

Tutti i valori di timeout sono stati impostati a 5000 millisecondi (5 secondi); ma possono essere adeguati in base alle proprie necessità.

Esempio 1: bilanciare il web
In questo primo esempio, HAPROXY viene utilizzato per bilanciare le richieste indirizzate a due server web, configurati per pubblicare una semplice pagina HTML (index2.html) che visualizza una serie di immagini (differenti tra i due server web, così da rendere evidente all’utente su quale server si è stati bilanciati).

frontend webfront
bind 192.168.0.253:80
default_backend webback
backend webback
balance roundrobin
server web1 192.168.0.31:80 check inter 5000 rise 2 fall 3 weight 10
server web2 192.168.0.32:80 check inter 5000 rise 2 fall 3 weight 10
mode http
log global
option httplog
option httpchk GET /index.html

All’interno della sezione “frontend” viene specificato l’indirizzo su cui si pone in ascolto il bilanciatore per il servizio specifico, e viene poi incluso il riferimento alla configurazione di “backend”, contenente informazioni sui server da bilanciare.

Nella parte “backend”, si può specificare quale metodologia di bilanciamento da utilizzare, quindi con quale criterio distribuire le richieste dei client, in questo caso il bilanciamento è di tipo “round robin”, cioè le richieste vengono inviate alternativamente ai due server bilanciati 50 & 50 % .
Con la direttiva “server” vengono specificati tutti i server che si vogliono bilanciare, identificando ciascuno con un nome (non necessariamente corrispondente all’hostname del server), l’indirizzo IP e la porta su cui ascolta il servizio (in questo esempio, la porta TCP/80 per il web server).
Per ogni server, vengono poi specificati i criteri da seguire per controllare se questo è attivo (a livello di servizio web) o meno, in modo da poterlo escludere a fronte di un problema.
Con l’opzione “check” viene specificata la frequenza con cui controllare il server (“inter”, impostata a 5000 millisecondi), dopo quanti check falliti il server deve essere escluso dal bilanciamento (“fall”), oppure dopo quanti check andati a buon fine (“rise”), invece, deve essere reinserito nel bilanciamento, ed il peso (“weight”) di ciascun server, in modo da poter distribuire il carico in maniera proporzionale tra le varie macchine, cosi da poter meglio bilanciare lo sforzo dei server nel caso che questi avessero hadrware con prestazioni differenti, infatti impostando un server con un peso maggiore rispetto alle altre macchine, questo riceverà un numero di richieste maggiore.

Se non si specificheranno particolari direttive, Haproxy verificera’ solo la disponibilità del servizio su ciascun server, controllando se la porta TCP specificata è in ascolto o meno.
Nel caso di web server bilanciati, è possibile definire dei controlli specifici sul protocollo HTTP interrogando direttamente la parte web, cosi che, a fronte di una risposta HTTP diversa dal codice 200 (OK) , il server verra’ escluso (“option httpchk”).

Con l’opzione httplog si attiva anche un livello di log per tutte le richieste HTTP che arrivano al bilanciatore per quel determinato servizio.
Particolare attenzione va riservata alle impostazioni di “rise” e “fall”, per cercare il giusto equilibrio che consenta di evitare che un server venga escluso, o reinserito troppo velocemente dal bilanciamento.

Esempio 2: bilanciare un servizio TCP
Oltre a bilanciare servizi HTTP, Haproxy può bilanciare praticamente qualsiasi tipo di connessione TCP; nel nostro test, sui due server attivati e’ stato configurato in ascolto, un servizio sulla porta TCP/2222.
In queso caso, HAPROXY è configurato per restare in ascolto su un indirizzo IP diverso da quello del servizio web dell’esempio precedente, e diverso dall’indirizzo fisico del bilanciatore.

frontend sshfront
bind 192.168.0.252:2222
default_backend sshbe
backend sshback
balance roundrobin
server ssh1 192.168.0.31:2222 check inter 5000 rise 2 fall 3 weight 10
server ssh2 192.168.0.32:2222 check inter 5000 rise 2 fall 3 weight 10

Troubleshooting
All’interno dei log generati da haproxy è possibile rilevare gli eventi in cui un server viene escluso, oppure incluso, nel bilanciamento.
Nel caso in cui il server (o il servizio) bilanciato non sia disponibile verrà registrato il seguente evento:

Feb 22 10:30:50 localhost haproxy[23679]: Server webbe/web2 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

Nel momento in cui il server/servizio torna disponibile nei log di Haproxy si troverà, invece, questo evento:

Feb 22 10:32:10 localhost haproxy[23679]: Server webbe/web2 is UP, reason: Layer7 check passed, code: 200, info: "OK", check duration: 0ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

Conclusioni
Haproxy offre la possibilità di risolvere problemi di eccessivo carico, ma anche di realizzare un meccanismo di alta affidabilità per diverse architetture di server, con questo approccio si semplifichera’ quindi la gestione dei sistemi e dei servizi.
Le funzionalità di Haproxy non si fermano solo agli esempi trattati precedentemente, ma permettono di creare servizi di bilanciamento capaci di lavorare dal livello 3 al livello 7 della pila ISO/OSI.
Vedremo in un secondo tempo di approfondire le varie funzionalità avanzate che Haproxy mette a disposizione.

 

#Haproxy#Bilanciatoredicarico