FreeNAS Nextcloud plugin – nginx e HTTPS

Come descritto nell’articolo sulla mia configurazione cloud, il webserver della mia istanza Nextcloud non esce fuori dalla rete locale se non attraverso una VPN con OpenVPN.

Idealmente dunque, utilizzare HTTP invece di HTTPS potrebbe sembrare una scelta ragionevole: handshake iniziale più rapido, numero minore di componenti da configurare e intuitivamente performance migliori.

In realtà, HTTPS con HTTP2 (tecnologia costruita su SPDY) garantisce performance migliori in quanto aggiunge la compressione degli header, la parallelizzazione delle richieste e un eventuale push proattivo da parte del webserver che può decidere che certe risorse saranno necessarie al client ancora prima che questi ne faccia richiesta. Non mi credete? Provate voi stessi.

A tutta questa (bella) roba si aggiunge uno strato di sicurezza in più: anche all’interno della mia rete locale le richieste (e le autenticazioni) verso nextcloud saranno cifrate e illeggibili da un aggressore.

Tutto molto bello insomma, non potevo lasciarmelo scappare. Non c’è ragione di usare HTTP invece di HTTPS in tutti i tuoi progetti web.

Il plugin di NextCloud per FreeNAS si basa su nginx, un webserver più moderno e performante del robustissimo Apache.

Configurare nginx per usare SSL e HTTP2 è semplicissimo. Entriamo via SSH nella Jail dedicata a nextcloud con jexec.

1. Verifichiamo se OpenSSL è installato (eventualmente installiamolo usando pkg).

root@nextcloud:/ # openssl version
OpenSSL 1.0.2o-freebsd 27 Mar 2018

2. Verifichiamo se i moduli nginx relativi a SSL (--with-http_ssl_module) e HTTP2 (--with-http_v2_module) sono installati.

root@nextcloud:/ # nginx -V
nginx version: nginx/1.16.0
built with OpenSSL 1.0.2o-freebsd  27 Mar 2018
TLS SNI support enabled
configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf
--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio
--http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log
--with-http_v2_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-pcre --with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --with-mail_ssl_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-mail=dynamic --with-stream=dynamic
root@nextcloud:/ #

3. Generiamo i certificati necessari (Certificate Authority, chiave privata e così via…).
Il CA sarà di tipo self-authority (non legato ad un ente certificatore esterno come potrebbe essere Let’s Encrypt [1]). Nessun problema, semplicemente il browser ci darà un warning (ma noi sappiamo di aver emesso noi quel certificato: possiamo fidarci).

Personalmente ho creato una directory openssl dentro /usr/local/etc/ssl/ nella quale ho salvato i file del mio certificato.

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1095
cat key.pem>>cert.pem
openssl dhparam 2048 -out dhparam.pem

Durante la generazione dei vari certificati vi verranno chieste un paio di password e qualche informazione per descrivere il certificato. Conservate le password con cura.

Occhio che il parametro -days indica i giorni di validità del certificato: 1095 sono 3 anni.

A questo punto sarete già al 50% del lavoro.

4. Raggiungete la cartella di configurazione della vostra istanza web nextcloud.
Di default si trova in /usr/local/etc/nginx/conf.d/

Per non far danni fate una copia di nextcloud.conf e successivamente modificate la configurazione in questo modo:

server {
  listen 443 ssl http2;
  server_name nextcloud.local;
  ssl_certificate /usr/local/etc/ssl/openssl/cert.pem;
  ssl_certificate_key /usr/local/etc/ssl/openssl/key.pem;
  ssl_prefer_server_ciphers on;
  ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DHE+AES128:!ADH:!AECDH:!MD5;
  ssl_dhparam /usr/local/etc/ssl/openssl/dhparam.pem;
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
...

Tutto il resto del file di configurazione potete lasciarlo immutato.

5. Riavviamo la lettura dei file di configurazione da parte di nginx:

root@nextcloud:/usr/local/etc/nginx/conf.d # service nginx reload
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
root@nextcloud:/usr/local/etc/nginx/conf.d #

Modifica completata! Se non avete fatto errori potrete loggarvi su https://<nextcloud-ip-address>:443/ 🎉

[1] Non ho potuto usare Let’s Encrypt perché come dicevo il mio webserver è isolato e non possiede un dominio. Se non siete nelle mie condizioni potrete usare CertBot e gestire l’intera catena di certificazione configurando il porting di Certbot per FreeBSD e nginx.

Il mio cloud? E’ a casa mia.

Credo poco nelle qualità irrinunciabili del cloud e da alcuni mesi ne ho abbandonato quasi del tutto l’utilizzo. Il cloud, d’altronde, è il computer di qualcun altro.

Il mio non è un tentativo di fuga dalla tecnologia quanto un uso più intelligente ed educato della stessa. Come dico da tempo, non voglio vivere più come un prodotto.

Il 90% del furto dei dati nel mondo del lavoro è legato al cloud secondo un report di Kaspersky.
Credete ancora che il cloud sia la soluzione a tutto?

Il mondo è cambiato da quando avevamo connessioni a 56kbps. Il digital divide in Italia esiste ancora, ma se siete tra quelli che hanno una linea dati sufficientemente capace (io ho una 30/3Mbps, nulla di fantascientifico) allora potreste considerare la mia soluzione.

Negli ultimi 5-6 anni siamo stati bombardati e incentivati all’uso del cloud con una narrativa abbastanza standard «E’ fondamentale per la resilienza dei dati, velocizza il lavoro, conserva i dati al sicuro» e così via.

I vantaggi del cloud.

Per eliminare il cloud bisogna dunque chiedersi quali siano i reali vantaggi al netto del marketing. Solitamente le funzioni apprezzate sono due:

  1. disponibilità dei file indipendente dalla propria posizione
  2. garanzia che i dati non vadano persi

Se osservate attentamente però entrambe le qualità hanno degli aspetti critici.

Esternalizzare l’hosting dei dati, ha un serio impatto sulla sicurezza e la riservatezza. Inoltre i dati possono potenzialmente venire dispersi: hacking a sistemi “cloud”, social engineering verso l’utente o semplice data-mining da parte del provider [1] sono alcuni dei limiti del fantasmagorico “cloud”.

A questo ovviamente va aggiunto il fatto che il cloud non è gratis. Per un uso intensivo infatti i classici piani gratuiti diventano molto rapidamente stretti e scomodi.

Con cosa ho sostituito il cloud?

La soluzione messa in piedi non è alla portata di tutti, ma copre le peculiarità del cloud senza grosse limitazioni. Non ho intenzione di fare una noiosissima guida alla sua configurazione (sono disponibile a dare una mano nei commenti) ma la soluzione che segue può essere implementata solo se non storcerete il naso leggendo certe parole.

Per tutti gli altri, il mio consiglio è quello di tenere d’occhio Cubbit, un progetto semi-italiano di tutto rispetto.

Il cuore del mio “cloud” è l’HP MicroServer comprato mesi fa sul quale ho installato FreeNAS.

E l’accessibilità dall’esterno?

So che aprendo qualche porta sul router potevo rendere la soluzione ancora più user-friendly ma preferisco mantenere tutti i servizi interni alla mia rete protetti da uno scudo ben robusto. Pertanto ho configurato una VPN (OpenVPN + DuckDNS) sul mio EdgeRouter. In questo modo la rete di casa mia è accessibile in maniera comoda e sicura dall’esterno e tutti i servizi con cui voglio dialogare “non escono da casa”.

Si ma… l’esperienza d’uso?

Il cloud cui siamo abituati, è costituito da un’interfaccia web con un file manager (Dropbox, Google Drive, One Drive e così via sono tutti simili a meno di personalizzazioni estetiche).

Io ho risolto installando sul NAS Nextcloud + Elasticsearch (per avere l’indicizzazione dei contenuti dei file). Nextcloud è una piattaforma di file-hosting opensourceDropbox style“. Per intenderci, avrete un client da installare sul desktop, una app per i vostri dispositivi mobili e così via.

Ok, e il disaster-recovery? La disponibilità dei dati?

La cartella nextcloud del mio MacBook viene tenuta in sync con il mio NAS. Se l’hard disk del MacBook dovesse morire, avrei i dati sul NAS. Se dovesse morire il NAS, avrei i dati sul MacBook.

La ridondanza dei dischi e l’uso di ZFS come file system sul NAS però non coprivano tutti gli scenari di disaster-recovery. Un furto in casa o un incendio tecnicamente potrebbero far svanire rapidamente i miei archivi (come direbbe Elon Musk, “rapid unplanned disassembly“) così con un amico ho messo in piedi una VPN site-to-site (sempre sul mio EdgeRouter che in questo caso mostra la flessibilità del device rispetto ad un classico router consumer) ed ho configurato sul NAS un backup giornaliero cifrato dei dati del mio NAS (cron + duplicity).

Duplicity prima di inviare i dati, fa una cifratura on-the-fly degli stessi usando GPG. In pratica, sebbene abbia fiducia nell’amico, preferivo non perdere la riservatezza dei miei dati. [2]

In math we trust.

Anonymous cyptographer

Per ulteriore ridondanza ho impostato un ulteriore backup cifrato via rsync su Dropbox. In questo modo Dropbox non potrà collezionare né dati d’uso (non ho le app di Dropbox, né effettuo login in mobilità), né informazioni sui miei file (tutto ciò che vede sono dei file di cui anche il nome è composto da una stringa randomica illegibile).

Perché Dropbox? Semplice pigrizia. 🙂 L’idea è quella di farne a meno tra un po’ ma in fase di avviamento volevo esser certo di avere “una copia cifrata in più“.

E le performance?

Le performance sono limitate dalla capacità della vostra linea. Con una linea FTTC o FTTH raggiungerete certamente prestazioni migliori ma posso assicurarvi che 3Mbit sono sufficienti a fare video streaming tranquillamente.

Un film in streaming attraverso Plex (installato sul NAS) mentre ero fuori casa

L’uso tipico che faccio del “cloud” prevede upload o download di documenti di pochi Mb che richiedono pochi istanti per esser trasferiti.

Potrei raccontarvi di tutte le feature aggiuntive di nextcloud, ma quello magari lo riserviamo ad un prossimo capitolo.

Riprendiamoci i nostri dati.

Emanuele

[1] Google ad esempio, riguardo al suo Google Drive, scrive che scansiona tutto quello che caricate al fine di «fornirti funzionalità del prodotto personalizzate, come risultati di ricerca personalizzati, pubblicità su misura, rilevamento spam e malware».

[2] Nota per i nerd: il backup iniziale (circa 350GB) ha impiegato poco meno di 20 giorni. Per testare la robustezza della soluzione abbiamo riavviato più volte router, NAS, VPN… Duplicity ha sempre ripreso le sue attività senza batter ciglio. I backup incrementali successivi dipendono esclusivamente dalle modifiche che faccio sul mio (next)cloud ma si limitano tipicamente a pochi MB al giorno così i backup (schedulati in notturna) sono sempre rapidi e invisibili.

La privacy è un concetto semplice.

Siamo tutti apaticamente in attesa che il rispetto della nostra privacy arrivi dall’alto. In realtà siamo anche noi, con le nostre scelte a determinare quanti e quali dati disperdere.

Privacy significa avere la possibilità di scegliere ciò che vogliamo condividere, quando e con chi farlo.

Se il mercato è libero di comportarsi in maniera deplorevole, scegliere saggiamente è completamente nelle nostre mani. Sempre e comunque.

Emanuele

FTPD su FreeNAS step by step

  • Crea una nuova Jail in modo da non sporcare il sistema di base (puoi farlo via SSH usando iocage create o via GUI)
  • Via SSH, dopo essere entrato (con jexec <id> tcsh) nella jail appena creata crea l’utente utilizzando adduser e aggiungilo al gruppo ftp
root@FTPServer:/ # adduser
Username: testUser
Full name: Utente di prova
Uid (Leave empty for default):
Login group [testUser]:
Login group is testUser. Invite testUser into other groups? []: ftp
Login class [default]:
Shell (sh csh tcsh nologin) [sh]: sh
Home directory [/home/testUser]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]:
Use an empty password? (yes/no) [no]:
Use a random password? (yes/no) [no]: yes
Lock out the account after creation? [no]:
Username   : testUser
Password   : <random>
Full Name  : Utente di prova
Uid        : 1002
Class      :
Groups     : testUser ftp
Home       : /home/testUser
Home Mode  :
Shell      : /bin/sh
Locked     : no
OK? (yes/no): yes
  • Per evitare che l’utente creato possa navigare oltre la sua home, crea /etc/ftpchroot e inserisci il nome dell’utente appena creato
root@FTPServer:/ # cd etc
root@FTPServer:/etc # touch ftpchroot
root@FTPServer:/etc # vi ftpchroot
  • Ripeti le operazioni 2 e 3 per ogni utente che vuoi creare
  • Inserisci in /etc/rc.conf l’impostazione ftpd_enable=”YES”
  • Dai service ftpd start via SSH
root@FTPServer:/etc # service ftpd start
Starting ftpd.

Ovviamente dovrai assegnare un mountpoint esistente sul tuo pool di FreeNAS e collegarlo ad /home/testUser interno alla jail.

Emanuele

«Privacy? Io non ho nulla da nascondere».

Durante gli ultimi 16 mesi, discutendo questo argomento in giro per il mondo, ogni volta che qualcuno mi ha detto «Io non mi preoccupo dell’invasione della privacy perché non ho nulla da nascondere», ogni singola volta in cui è accaduto ho sempre risposto allo stesso modo. Ho preso una penna, ho scritto il mio indirizzo email e ho detto «Eccoti il mio indirizzo email. Quel che ti chiedo quando tornerai a casa è di inviarmi via mail le password di tutti i tuoi account email, non solo quella dell’indirizzo “educato e pacato” del lavoro, ma anche tutte le altre perché io voglio essere in grado di curiosare sulla tua vita online, leggere quel che mi gira e pubblicare quel che trovo interessante. Dopotutto, se non sei una cattiva persona, se non stai facendo nulla di male, non dovresti avere nulla da nascondere». Neanche una persona fin ora ha mai accettato la mia offerta.

Glenn Greenwald in Why privacy matters – TED Talk

Del perché anche la nostra posta sia importante ho parlato qualche tempo fa. In ogni caso direi che affermare di non avere nulla da nascondere sia una risposta che letteralmente non ha senso.

Tutti, in realtà, desideriamo avere della privacy.

Emanuele

Continua con… la tua password.

Se hai seguito i miei ultimi post, capire il perché di questo avvertimento ti verrà facile.

Google, Facebook e molti altri social da anni propongono un servizio molto carino: il login centralizzato. Comodo, non c’è che dire. Permette di farsi riconoscere su tanti siti senza dover ricordare l’ennesima password.

Google, Facebook, Twitter o chi per essi però sfruttano anche questo meccanismo per conoscere il web che visitiamo. Noi, con le nostre informazioni siamo il prodotto da vendere agli inserzionisti.

Ingenuamente, in cambio di una password in meno raccontiamo a che ora, da che device, quante volte siamo soliti visitare quel sito. Considerate infine che qualora il vostro account dovesse venire sospeso, bloccato o rubato, perdereste la possibilità di accesso anche verso tutti quei siti web.

Se insomma avete problemi a memorizzare le password (anch’io fatico!), organizzatevi con un semplicissimo password manager.

Piccole attenzioni. Riprendiamoci i nostri dati.

Emanuele

DMARC, SPF e DKIM per proteggere la tua identità

Se hai un dominio, poco importa se sei un’azienda o sei un privato, devi leggere questo post: ti spiegherò perché ti interessa.

Uno dei difetti storici del sistema di posta su internet è la scarsa capacità di autenticazione del mittente di una email. Lo spam, da decenni, gioca su questa incapacità per tentare di raggiungere la vittima/destinatario.

Quante volte avete visto nella cartella dello spam delle email apparentemente inviate da persone a voi note o addirittura da voi stessi?

Il campo FROM di una mail, infatti, non è strettamente legato alla casella di posta del mittente, ma il protocollo SMTP ne permette lo spoofing, la falsificazione. Per farla breve, tecnicamente io potrei tentare di inviare una email apparentemente inviata tramite il vostro indirizzo email.

I sistemi di posta si sono evoluti nel tempo ed hanno cercato di trovare soluzioni a questa vulnerabilità. SPF, DKIM e ultimamente DMARC sono sistemi nati per cercare di riconoscere e limitare i tentativi di spoofing dell’indirizzo email. Non eliminano lo spam, ma aiutano i filtri antispam a lavorare meglio.

Perché è importante farne uso?

  • Se sei un’azienda una mail a tuo nome potrebbe essere considerata vera da un cliente e in base al contenuto potresti perderlo.
  • Se sei un privato le tue mail recapitate ad un familiare o ad un amico potrebbero rappresentare la chiave d’accesso ai loro sistemi. Quante fiducia in più abbiamo nel cliccare un link proveniente da una mail familiare?

La loro sicurezza passa anche dalla vostra capacità di proteggere l’uso indiscriminato dei vostri indirizzi di posta o del vostro dominio.

Come funzionano?

Non entrerò molto nel tecnico perché sarebbe utile un post per ognuna di queste tecnologie ma quel che vi importa sapere è il seguente:

  • SPF specifica quali server di posta autorizzate ad inviare per conto vostro. Solitamente qui vanno indicati gli indirizzi IP del vostro provider di posta.
  • DKIM specifica la chiave pubblica che verrà confrontata con la chiave inviata dal vostro provider per firmare la vostra email. Se la crittografia che sta alla base di questo concetto (chiave pubblica-chiave privata) è verificata, allora DKIM è valido.
  • DMARC è l’ultimo tassello, ratificato nel 2015, che aiuta il provider di posta del destinatario. Attraverso di esso infatti potrete consigliare al ricevente come trattare le mail in caso di fallimento di SPF o DKIM (“non fare nulla“, “invia nello spam“, “rifiuta totalmente la mail“).

Tool utili per il setup:

  • Per iniziare il processo potete utilizzare questo strumento della GlobalCyberAlliance. Cliccando su ognuna delle 3 tecnologie avvierete una procedura guidata utile alla configurazione dei vostri parametri.
  • Per verificare che le vostre mail partano con i corretti header DMARC mail-tester.com vi tornerà utile.
  • Infine, per un monitoring nel tempo dell’andamento delle vostre impostazioni potrete fare uso di DMARCian.
DMARCian - DreamsWorld

Qui sopra, ad esempio, le statistiche del mio account, con evidenti (in rosso) usi fraudolenti del mio nome e l’azione di reject segnalata ai provider dei riceventi.

Tutti i principali provider di posta odierni supportano DMARC. Utilizzarlo protegge i destinatari, protegge il vostro brand, fa risparmiare risorse spazio e banda ai sistemi di posta.

Domande? Scrivetemi nei commenti.

Emanuele

Privacy e blog

Riprendere possesso dei propri dati, passa anche dai propri siti web.

Hai un blog? Ti sei mai domandato quanti servizi esterni hai integrato sul tuo sito per il bene di chissà cosa?

I bottoni di like, fav, ❤ dei vari social, oltre ad essere degli strumenti di voto, sono delle cimici utilizzate dai vari provider per monitorare le attività sul web “esterno” (il web interno, la “gabbia dorata” di ogni social, è monitorata in maniera molto più agevole e intensa. Ad esempio, Facebook registra anche i vostri movimenti del mouse sulla pagina).

Questo blog è Facebook Free da sempre e Google Free da circa una settimana.

La stesura di questa rubrica mi è servita da sprone per eliminare due strumenti di Google: Google Analytics e Google AdSense. Del secondo, dati gli introiti ormai relativamente bassi (il traffico sui blog si è decimato rispetto a 6-7 anni fa) non sentirò la mancanza. Di Analytics, il tool di monitoring degli accessi, non volevo fare del tutto a meno.

La domanda che mi sono posto durante la sua rimozione è stata: a me serve precisamente Google Analytics o un tool moderno di analisi degli accessi?

La risposta era scontata.

Ho colto così l’occasione per installare Matomo, una piattaforma di web analytics rispettosa della privacy e compliant con il GDPR e col Do Not Track. In pratica se impostate il vostro browser con il DNT attivo, la vostra visita qui non viene registrata e io vi vorrò bene ugualmente. 🙂

Matomo è divenuto velocemente il più grosso progetto OpenSource di web analytics al mondo ed è utilizzato anche nei siti della Commissione Europea che ne parla così:

“Europa Analytics is based on Matomo which is the leading open-source analytics platform that provides relevant and reliable insights into user behaviour. The data and information collected by Matomo is 100% owned and controlled by the European Commission. This guarantees compliance with strict privacy regulations and laws. Matomo is used by more than 1,000,000 websites worldwide, including large corporations, SMEs, governments & non-profit organisations.”​

Se avete un hosting che supporta Softaculous, l’installazione si effettua con pochi click e senza troppe difficoltà. Se amate consultare le vostre statistiche in mobilità, è disponibile anche l’app di Matomo.

Un altro aspetto spesso sottovalutato dai webmaster, è quello relativo ai contenuti multimediali dei blog (font, immagini, video). Personalmente ho sempre preferito evitare i Google Fonts e le CDN. Se da un lato possono velocizzare il caricamento dei contenuti (per il visitatore che capita qui la prima volta, per gli altri in realtà la cache del browser fa già un buon lavoro!), dall’altro (anch’essi, sigh!) sono metodi per monitorare la navigazione sul web.

Il web, vi sarà evidente, è diventato un ambiente di tracking incredibile. Strumenti apparentemente innocui (font, pulsanti di like) sono stati trasformati in strumenti di marketing. Perché regalare a questi giganti del web tali informazioni? Per cosa poi? Per guadagnare un numero incrementale chiamato “like” e gioire come bambini?

Io dei “like” me ne sono sempre bellamente fregato e da oggi se utilizzate un buon browser, potete star tranquilli che né Google né Facebook sapranno mai che siete capitati da queste parti.

Riprendiamoci i nostri dati.

Emanuele