Come diventare raggiungibili da internet su rete fastweb con il protocollo IPv6

Molti di quelli che si connettono su rete Fastweb lo fanno ancora attraverso un Natting di rete; l’indirizzo IP con cui ci si presenta su internet è quindi condiviso con molti altri utenti.

Questo tipo di configurazione è perfettamente funzionale ad una normale navigazione su internet e in una certa misura migliora la sicurezza del nostro pc perché non ci espone direttamente dall’esterno.

Come contropartita però è un problema da aggirare se si vogliono implementare dei servizi di tipo server (un server web ad esempio) o per l’utilizzo di alcuni programmi (in genere giochi, sistemi peer-to-peer o altro) che, assegnando un ruolo paritario alle macchine coinvolte e richiedono ad ognuna alternativamente di assumere sia il ruolo del server sia quello del client.

Cercando su google idee su come gestire questo problema su una connessione fastweb ho trovato riferimenti sostanzialmente a tre tipi di indicazioni:

  • si ha già un IP dedicato ma bisogna configurare il portforwarding sul proprio router
  • molti dicono (ma io non ho provato e quindi mi limito a riportare quanto letto altrove) che in genere, insistendo con il supporto, si riesce a farsi assegnare un IP, non mi è chiaro se gratuitamente o meno.
  • se si è su rete nattata non c’è modo di aggirare il problema.

In realtà è comunque possibile sfruttare il protocollo IPv6 per gestire questo problema. Data la natura di questo protocollo infatti ogni IPv6 è un identificatore univoco di un apparato dulla rete.

Lo si può abilitare ad esempio come ho descritto in “primi passi in IPv6.

CORS on Amazon S3 and CloudFront

To enable the CORS (Cross-Origin Resource Sharing) on a tipical Amazon infrastructure it is necessary to configure both S3 and CloudFront. The behaviour of the various browser is not the same but on chrome the Header Access-Control-Allow-Origin is expected in the answer.

On S3 you have to add CORS properties in the properties tab. You will insert something like;

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Athorization</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

On CloudFront you have to change the behaviour of the origin to enable the forward of the request header. It is suggested to chose the whitelist mode and select the Origin header to have a better caching. This step is required to let the Origin header reach S3: without it S3 replies ignoring the CORS headers.

To test the result a curl can be used but the Origin header has to be inserted in the request using an existing (authorized) domain.

curl -H "Origin: http://www.example.com"  --verbose  http://***/fonts/arial.ttf

command line perl e analisi dei log

Tempo fa abbiamo visto come utilizzare il perl come tool di linea di comando. Vediamo oggi come utilizzarlo in un caso un poco più complesso: per contare le occorrenze di un dato vhost in un access.log di apache e magari al tempo stesso avere le statistiche di quante volte apache da una risposta corretta (return code 200) o qualche altro errore.

Osserviamo per prima cosa una riga di log del nostro sito preferito

xx.xx.xx.xx linuxandcompany.it - [06/Apr/2014:23:54:13 +0200] "GET /2014/01/squid-come-reverse-proxy/ HTTP/1.1" 200 10177 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"

Questo tipo di analisi si riesce a fare direttamente in linea con il perl. Iniziamo prima da una cosa cosa semplice: contiamo il numero di occorrenze dei vari return code per un dato sito:

cat linuxandcompany.it-08-04-2014.log|grep "linuxandcompany.it" |perl -ne '{@fields = split(/ /); $stat{$fields[8]}++;}END{while( ($key1, $value1) = each(%stat) ){print $key1. "\t" .$value1. "\n"}}'

che darà un risultato della forma:

304	16
200	397
302	4
301	2
404	2

Il comando inizia con un cat che passa ogni riga del file di log in stdout. Lo stdout viene intercettato da un grep che seleziona le righe del mio sito.
Le righe selezionate vengono poi passate al comando per che, come visto, con le opzioni ne applica il comando che segue ad ogni riga.
Il comando per è costituito da due blocchi: quello ordinario nella prima coppia di parentesi graffe e un secondo blocco identificato da END{…} che viene eseguito solo a conclusione del ciclo.

Il primo blocco inizia con uno split che separa la stringa in stdin in un array con le varie parole per elementi

@fields = split(/ /);

Tra gli slash è riportato il carattere scelto per spezzare la stringa.
Lo split avrebbe potuto anche essere scritto come

@fields = split(/ /, $_);

Utilizzo poi i campi per incrementare un hash di contatori che ha per chiavi i return code.

$stat{$fields[8]}++;

Il blocco finale si occuperà poi di visualizzare il risultato:

while( ($key1, $value1) = each(%stat) )
   {
   print $key1. "\t" .$value1. "\n"
   }

ed è costituito da un ciclo sulle coppie chiave, valore dell’hash.

In una situazione reale questo comando funziona però fino ad un certo punto perché le stringhe possono contenere spazi anche se non è frequentissimo. Un risultato molto migliore si ottiene combinando due split: un primo basato sulle virgolette, che racchiudono le stringe significative, ed un secondo basato sugli spazi da applicare alle sottostringhe:

cat linuxandcompany.it-08-04-2014.log|grep "linuxandcompany.it" |perl -ne '{@fields = split(/"/); @sub_fields = split(/ /, $fields[2]); $stat{$sub_fields[1]}++;}END{while( ($key1, $value1) = each(%stat) ){print $key1. "\t" .$value1. "\n"}}'

Si può poi complicare a piacere andando a fare la stessa statistica per ogni sito presente nel log. Sotto faccio un doppio report (per sito e complessivo).

cat linuxandcompany.it-08-04-2014.log |perl -ne '{@fields = split(/"/); @sub_fields1 = split(/ /, $fields[0]); @sub_fields2 = split(/ /, $fields[2]); $stat1{$sub_fields1[1]}{$sub_fields2[1]}++; $stat2{$sub_fields2[1]}++}END{while(($key1, $value1) = each(%stat1)){ while( ($key2,$value2) = each(%$value1) ){print $key1. "\t" . $key2."\t".$value2. "\n"}}; print "\n\n"; while( ($key1, $value1) = each(%stat2) ){print $key1. "\t" .$value1. "\n"}}'

Rimane evidente che questo è al limite di quello che ha senso fare con una linea di comando e non scrivendo un piccolo script.

Comandi analoghi si possono utilizzare ad esempio per contare le occorrenze delle pagine nel log.

Primi passi in IPv6

Questo articolo lo sto scrivendo connesso all’IP

2001:41d0:1:1b00:94:23.64:3

. Quello che si ottiene con un

dig -t AAAA linuxandcompany.it

Non è mica poco!

Alla fine cercando in rete ho trovato che da rete Fastweb è piuttosto semplice, anche se le informazioni è stato necessario metterle insieme da più fonti.

Prima di tutto l’IPv6 non è nativo ma la rete fastweb, come riportato qui, contiene il server

tsp.ipv6.fastweb.it

che permette di fare un tunnel verso la rete IPv6.

Per usare questo client si piò utilizzare il client gogoc sviluppato in gogo6. Da sito si scaricano solo i sorgenti e almeno sulla mia versione di ubuntu la compilazione non va a buon fine ma ho scoperto che il client è tra i pacchetti di ubunto e si chiama gogoc; basta quindi un

aptitude install gogoc

L’ultimo step è inserire qualche dato in

/etc/gogoc/gogoc.conf

ovvero

server=tsp.ipv6.fastweb.it
auth_method=anonymous

Dopo di che

/etc/init.d/gogoc start
/etc/init.d/gogoc status
ip add sh

saranno sufficienti per attivare il tunnel IPv6 e per verificarne lo stato.

Potremo poi verificare l’avvenuta attivazione dai siti

http://test.ipv6.fastweb.it/
http://www.ipv6.fastweb.it/

Se si ha poi un qualche tool che visualizza l’IP del sito che si sta visualizzando sul browser, e si naviga dopo averlo riavviato, si cominceranno a vedere molti accessi su questo protocollo di trasporto, che ha priorità più alta. Dovreste vederlo su linuxandcompany.it ma anche su qualche sito minore come www.google.com.

djbdns dns server: dnscache

Il mondo dei server DNS è sicuramente dominato da bind in ambito linux ma esistono altri prodotti interessanti soprattutto se la necessità non è quella di dare il servizio DNS su internet.

Trovo particolarmente interessante djbdns. Questo daemon è stato sviluppato da D.J. Bernstein, autore, tra l’altro, anche di qmail. La caratteristica più interessante di djbdns è quella di separare in tre daemon differenti tre funzionalità differenti generalmente unificate sotto un’unico daemon:

  • caching DNS: dnscache
  • authoriting delle zone: tinydns
  • trasferimento di zone: axfrdns and axfr-get

Di questi il più utile secondo me è dnscache che, essendo un sistema estremamente leggero è ideale per essere istallato e ridurre il carico di lavoro di tutti quei server che hanno la necessità di gestire un elevato numero di connessioni che giungono da svariati IP.

Djbdns richiede due software: daemontools e ucspi-tcp. Questi li istalliamo da pacchetto.

aptitude install daemontools
aptitude install ucspi-tcp

djbdns non è però presente sulla distribuzione debian. Scarichiamo quindi i sorgenti. La compilazione richiede i pacchetti make, gcc

 wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
tar -zxvf djbdns-1.05.tar.gz
cd djbdns-1.05
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make
make setup check

L’autore richiede poi di segnalare l’avvenuta istallazione con

( echo 'First M. Last'; cat `cat SYSDEPS` ) \
| mail djb-sysdeps@cr.yp.to

Passiamo ora alla configurazione del servizio. Come sempre non è il caos di di far girare dei daemon come root; aggiungiamo quindi due utenti al sistema inserendo nel file */etc/passwd*

dnscache:x:999:999::/dev/null:/usr/sbin/nologin
dnslog:x:998:999::/dev/null:/usr/sbin/nologin

e al file /etc/group

dnscache:x:999:

Prepariamo la configurazione di base

dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1

Con questo comando abbiamo generato la configurazione in /etc/dnscache specificando che l’utente che dovrà eseguire il daemon sarà dnscache, che i log saranno gestiti dall’utente dnslog e che il daemone sarà in ascolto sull’IP 127.0.0.1.

La directory creata conterrà 5 sottodirectory: env, log, root, run e seed. In particolare env e root contengono le configurazioni vere e proprie e log i log. Vedremo qualche dettaglio in seguito.

Occupiamoci ora dell’avvio del sistema. Vogliamo sfrutatre i daemontools e per farlo dovremo far si che svscanboot venga avviato all’avvio del sistema attraverso i meccanismi della distribuzione che stiamo utilizzando. Per le finalità di questo tutorial ci accontentiamo di lanciarlo a mano:

mkdir /etc/service/
cd /tmp/
nohup svcscanboot &

Il sistema dei daemontools si aspetta una directory in /etc/service per ogni servizio da gestire e monitorare. Aggiungiamo quindi la nostra cache dns

ln -s /etc/dnscache /etc/service/dnscache

Dopo qualche secondo il daemon sarà avviato

svstat /etc/service/dnscache/

ci restituirà il tempo di esecuzione e il PID del demone.

Interessanti un paio di *ps*

root@debian:/tmp# ps aux|grep sv
root      7605  0.0  0.0   4180   580 pts/0    S    22:24   0:00 /bin/sh /usr/bin/svscanboot
root      7607  0.0  0.0   4120   460 pts/0    S    22:24   0:00 svscan /etc/service
root@debian:/tmp# ps aux|grep dns
root      7609  0.0  0.0   3948   316 pts/0    S    22:24   0:00 supervise dnscache
dnslog    7611  0.0  0.0   4092   468 pts/0    S    22:24   0:00 multilog t ./main
dnscache  7612  0.0  0.1   5484  1492 pts/0    S    22:24   0:00 /usr/local/bin/dnscache

che mostrano tutti i processi coinvolti. Notare che la gestione dei log è fatta attraverso un daemon separato e infatti si troverà all’interno della directory log in /etc/dnscache una directory *service* esattamente come in */etc/dnscache*.

Per fermare e riavviare dnscahe si può ricorrere a

svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

o anche a un più brutale kill del daemon dnscache: ci penseranno i daemontools a riavviarlo.

Per meglio gestire le zone interne o se si vuole sfruttare qualche dns interno si consideri che in /etc/dnscache/root/servers si possono aggiungere file, denominati come un dominio e contenenti una lista di DNS interrogabili per quel dominio. Ad esempio con:

cd /etc/dnscache/root/servers
echo 213.251.188.150 > linuxandcompany.it
echo 213.251.128.150 > linuxandcompany.it
svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

posso dire alla cache dove di preferenza deve rivolgersi per le risoluzioni del dominio di questo sito.

Questa directory contiene di base un file denominato @ in cui è contenuta la lista dei root dns di internet.

Awstats e analisi dei log

Generalmente l’analisi del traffico sui siti web viene fatto strumenti sul genere di google analytics che si basano su chiamate dei client, generate da javascript, a siti di terze parti che si occupano della raccolta e della reportistica dei dati.

I server web generano però enormi quantità di log che contengono molti dettagli su tutte le attività del sito web. Nel caso di problemi specifici gli strumenti per analizzarli sono i vari tool della shell e il magari il perl ma se quello che si vuole è monitorare l’andamento del sito la cosa migliore è ricorrere a tool specifici. Uno dei tool storici per questa attività in ambiente LAMP è awstats.

Awstats è un insieme di scripts che si occupa di analizzare i log che gli vengono serviti e genera dei report fruibili poi attraverso un server web. Awstats è in grado di lavorare molti tipi di log che spaziano da quelli di svariati tipi di web server (come Apache o anche IIS) a quelli di ftp server o mail server.

Awstats non è il solo tool e loro stessi riportano una tabella di comparazione con altri prodotti analoghi.

Passiamo ora ad esaminare come configurare awstats. Come iare sempre non troverete qui una guida completa ma un punto di partenza per poter iniziare ad esplorare le potenzialità di questo prodotto.

La prima cosa è ovviamente istallarlo. Anche awstats è presente in gran parte delle distribuzioni. Su debian/ubuntu potrete quindi procedere con:

aptitude update
aptitude search awstats
aptitude install awstats apache2

Alternativamente dal sito di awstats è possibile effettuare il download dell’ultima versione stabile.

Se si procede da pacchetto si avranno a questo punto nella directory

/usr/share/doc/awstats/examples

molti file di esempio utili.

Iniziamo ora dalla configurazione di apache necessaria per la visulizzazione dei report: bisogna infatti istruire apache a mostrare i report aggiungendo ad un vhost le seguenti direttive:

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

Alias /awstatsclasses "/usr/share/awstats/lib/"
Alias /awstats-icon "/usr/share/awstats/icon/"
Alias /awstatscss "/usr/share/doc/awstats/examples/css"
ScriptAlias /awstats/ /usr/lib/cgi-bin/
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch

E’ necessario poi riavviare apache.

Passiamo ora all’anailsi dei file. Cominciamo facendo una copia del file /etc/awstats/awstats.conf rinominandolo in awstats.linuxandcompany.it.conf.
Le righe fondamentali da editare al suo interno sono

  • LogFile: che dovrà contenere il nome completo di path dei log da esaminare
  • SiteDomain: che conterrà il nome del dominio
  • HostAliases: per indicare, separati da spazi, eventuali nomi alternativi del dominio
  • LoadPlugin: vorremo probabilmente aggiungere almeno “ipv6”
  • LogFormat: permette di descrivere in dettaglio il formato dei log se non sio è utilizzato quello standard di apache o squid.

I parametri configurabili sono veramente molti e, se non la documentazione, il file merita almeno una scorsa per individuare elementi di interesse.

A questo punto non rimane che scaricare il file di log nella directory e far parsare il file ad awstats. Da sottolineare che i vari file di log devono essere processati nell’ordine in cui vengono generati e che il nome nella configurazione è univoco e bisognerà quindi o copiare giorno per giorno il file di log nella directory designata sovrascrivendo il precedente o sfruttare un link simbolico. Si tratta comunque di un’attività facilmente automatizzabile.

Procediamo quindi con il parse

/usr/lib/cgi-bin/awstats.pl -config=linuxandcompany.it -update

Se apache è stato configurato sulla propria macchina e se l’elaborazione è stata fatta localmente sarà possibile vedere il report sull’url

http://localhost/awstats/awstats.pl?output=main&config=linuxandcompany.it&framename=index

squid come reverse proxy

Squid è un prodotto eccellente per fare da web cache; sia che si voglia alleggerire il carico sulla connessione, sia che si voglia fare del filtraggio a livello applicativo sia che si abbia la necessità di fare del monitoraggio molto dettagliato dell’uso del web su di una rete, la flessibilità di questo applicativo permette di intervenire praticamente su ogni aspetto del protocollo http e non solo.

Segnalo fin da subito che squid, come tutti i prodotti di web cache, richiede un’ attenzione particolare alla configurazione, in particolare per l’aspetto dei permessi; si corre il rischio, infatti, di mettere su internet un server proxy che può essere usato da terzi per mascherare le proprie attività.

Oggi voglio mostrare come configurare squid per usarlo come reverse-proxy. Si parla di proxy quando la cache viene messa davanti ai client e risolve al posto di questi le chiamate su internet. Si parla di reverse-proxy quando il server viene posto davanti ai web server e raccoglie al posto dei server web le chiamate dei client.

La ragione base per cui si fa questo è migliorare le prestazioni incidendo il meno possibile sui costi. I server cache infatti mantengono in memoria e/o su disco le risposte alle richieste più frequenti dei client e rispondono direttamente senza convolgere i server web; infatti  sono in genere in grado si rispondere ad un numero di richieste molto più alto di un server web che sempre più spesso deve essere configurato per gestire elaborazioni pesanti.

Squid è un prodotto molto consolidato ed è presente oramai sui tutte le distribuzioni linux. Per istallarlo quindi in genere la cosa più semplice è ricorrere ai tool della propria distribuzione. Su Debian/Ubuntu:

sudo aptitude update
sudo aptitude search squid
sudo aptitude install squid

La configurazione di default di squid è molto ben fatta e contiene così tanti commenti da essere quasi completamente autoesplicativa; merita un’esame se si vuole utilizzare questo prodotto. Nel nostro caso però la costruiremo da zero. Come risulta dalla documentazione ufficiale ci sono più possibilità per la configurazione in modalità Reverse Proxy; ne analizzeremo una di uso ragionevolmente generale.

http_port 80 accel defaultsite=[server name] vhost

cache_peer [IP sorgente 1] parent 80 0 no-query originserver name=RevPro1
acl web1 dstdomain [accelerated domains list 1]

cache_peer [IP sorgente 2] parent 80 0 no-query originserver name=RevPro2
acl web2 dstdomain [accelerated domains list 2]

http_access allow web1
http_access allow web2
cache_peer_access RevPro1 allow web1
cache_peer_access RevPro2 allow web2

cache_dir diskd /var/cache/squid3 1000 32 32 Q1=64 Q2=72
cache_mem 1024 MB

cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
cache_swap_low  90
cache_swap_high 95

Vediamo ora questa configurazione in maggiore dettaglio:

http_port 80 accel defaultsite=[server name] vhost

In questo modo si dice a squid che lavorerà in modalità reverse-proxy e con che tipo di configurazione. Defaultsite conviene valorizarlo con il nome del server web, quali sono i siti di cui si fa reverse proxy viene specificato più avanti. Vhost specifica che la discriminante per la scelta del server di origine sarà il dominio.

cache_peer [IP sorgente 1] parent 80 0 no-query originserver name=RevPro1

Definiamo qui un server web di cui fare reverse proxy e assegniamo un nome a questa definizione (RevPro1).

acl web1 dstdomain [accelerated domains list 1]

Definiamo una lista di siti web (separati da spazi) di cui si vuole fare reverse proxy e le assegnamo un nome (web1).

cache_peer [IP sorgente 2] parent 80 0 no-query originserver name=RevPro2
acl web2 dstdomain [accelerated domains list 2]

Ripeto per un secondo server origin e una seconda lista di siti.

http_access allow web1
http_access allow web2

dico a squid che deve rispondere alle richieste (dei client) relative alle due liste di siti web1 e web2.

cache_peer_access RevPro1 allow web1
cache_peer_access RevPro2 allow web2

Associo le origin alle liste dei siti supponendo che un dato server web di origine serve alcuni dei siti mentre l’altro serve gli altri.

cache_dir diskd /var/cache/squid3 1000 32 32 Q1=64 Q2=72
cache_mem 1024 MB

cache_replacement_policy heap LFUDA
memory_replacement_policy heap GDSF
cache_swap_low  90
cache_swap_high 95

Infine queste righe configurano la cache.

Come quasi sempre su squid si definiscono degli oggetti per definire attività da permettere o vietare; si definiscono delle acl per definire il “chi” ed infine si associano questi due tipi di informazione in righe dove si definisce chi può fare cosa.

Come sempre prima di mettere in produzione un server con squid è bene leggerne la documentazione ufficiale.

gmail – cambiare il sender

La posta di gmail offre uno strumento poco noto ma molto utile. E’ possibile inviare posta con un sender differente dall’account con cui si è fatto login.

Questa feature di gmail può tornare utile in almeno due casi:

  1. se si hanno diverse caselle di posta sfruttando il cambio di sender e la possibilià di scaricare posta da altre caselle, per concentrare la gestione della propria posta in un unico punto.
  2. se si gestisce un dominio con centinaia di caselle su cui con ogni probabilità verranno richieste caselle non personali di cui è fin troppo facile perdere traccia, da la possibilità di limitare gli utenti alle caselle personali e usare i gruppi per tutte le caselle funzionali come le varie webmaster, postmaster etc.. Il vantaggio è doppio: igruppi non si pagano e  l’amministratore può ricostruire facilmente da chi vengono letti.

Per sfruttare questa feature bisogna:

  1. Fare login sulla webmail
  2. entrare nei settings del proprio account
  3. Selezionare il tab Accounts
  4. selezionare “Add another address you own”
  5. Sulla finestra di pop-up inserire il nome che si vuole mostrare accanto all’indirizzo nell’header From:”
  6. Sulla finestra di pop-up inserire l’email che si vuole nel campo From
  7. Sulla finestra di pop-up togliere il check “Treat as an alias box”
  8. Selezionare Next Step
  9. Si riceverà sull’altro account (o gruppo) un’email con un link di autorizzazione
  10. Confermare selezionando il link nell’email
  11. Tornare alla finestra di pop-up e concludere la procedura.

Da questo momento è possibile mandare la posta con unb altro Sender.