Vai al contenuto

Videocamera di sorveglianza via Pixabay

Sono in atto norme drastiche sugli spostamenti delle persone, praticamente in tutto il mondo, per contenere il contagio da Coronavirus COVID-19. A supporto di queste norme, che condivido, cresce la richiesta di sorveglianza straordinaria per farle meglio rispettare.

Anche su questo sono d'accordo perché la situazione è seria e bisogna adoperarsi per evitare che peggiori ulteriormente: la privacy può essere ridimensionata.

Come però fa notare il buon Bruce bisogna assicurarsi che queste restrizioni alla privacy vengano cancellate riportando tutto alla normalità una volta che la pandemia sarà finita. L'obbiettivo è, non solo di cancellare le eccezioni alle norme sulla privacy, ma di eliminare anche i dati raccolti in modo che non vengano usati successivamente per altri scopi sia da enti governativi che privati: a pandemia finita tutto dovrà essere cancellato.

Bruce Schneier non ci crede, io neppure: voi?

Click sull'immagine per la gif animata

Segnala Bruce Schneier che c'è un kickstarting (crowdfunding) per una candela con fuoco vero controllabile via internet e, giustamente, si domanda: cosa potrebbe andare storto?

Alcuni lettori di Bruce hanno lasciato commenti particolarmente significativi:

  • Puoi verificare da remoto se casa tua ha una perdita di gas.
  • La si potrebbe chiamare candela di Darwin.
  • Prossimamente l'integrazione con svariati assistenti vocali per una migliore e più veloce esperienza di incendio.
  • Adesso avremo bisogno di una estintore IoT.
  • Tocca qui per bruciare tutti (cit. Click here to kill everybody).

Se già usate fail2ban per proteggere l'accesso ssh e avete anche un web server Apache installato è una buona idea aggiungere alcuni protezioni che fail2ban è in grado di offrire per apache.

Ci sono già diversi moduli pronti che possono essere attivati con poco sforzo. Basta aggiungere un file .conf in /etc/fail2ban/jail.d con la parte di configurazione che modifica quella standard. Per esempio per aggiungere la protezione all'autenticazione di Apache il codice è

[apache-auth]

enabled = true
port = http,https
logpath = /var/log/apache2/error.log
maxretry = 3
findtime = 600

Ci sono anche altri moduli interessanti: apache-overflows apache-badbots php-url-fopen: qui trovate qualche dettaglio in più oppure direttamente sul wiki di fail2ban.

Il procuratore generale William Barr ha tenuto un discorso sulla cifratura dove il punto più importante, secondo Bruce Schneier e anche secondo me, è che finalmente c'è l'ammissione che introdurre delle backdoor per garantire l'accesso alle forze dell'ordine diminuisce la sicurezza.

Barr rimane convinto che ne valga la pena ma non è questo il punto: fino ad ora era sempre stato detto che le backdoor di stato si sarebbero potute aggiungere senza diminuire la sicurezza.

Ora finalmente si può iniziare un dibattito politico serio. Aggiungere le backdoor permette alle forze dell'ordine di intercettare i cattivi ma, diminuendo il livello di sicurezza, permette anche ai cattivi di sorvegliare noi.

Quello che il procuratore Barr dice è che si tratta di "cybersecurity di consumo" e non "codici di lancio nucleari": è vero ma non dimentichiamo che le persone che usano questa famosa "cybersecurity di consumo" sono anche legislatori, amministratori delegati, le stesse forze dell'ordine per non parlare del personale addetto alle centrali nucleari o ai codici di lancio giusto per fare un esempio. Argomentare poi che queste persone posso essere dotate di strumenti di comunicazione sicuri (senza le backdoor) è un esercizio che si ritorce contro a chi lo propone visto che, a questo punto, anche i criminali possono usarle strumenti senza backdoor quindi torneremmo tutti al punto di partenza avendo solamente peggiorando la sicurezza generale.

C'è veramente da sperare che finalmente ora il dibattito possa spostarsi dal precedente "finta sicurezza" vs privacy al reale dibattito sicurezza vs sicurezza e, secondo Bruce Schneier la sicurezza complessiva è molto più importante dell'esigenza delle forze dell'ordine di intercettare e va difesa anche a costo di rinunciare all'accesso tramite backdoor delle forze dell'ordine. Questo, tra i vari motivi, perché tutti questi strumenti di comunicazione proteggono anche i codici di lancio delle armi nucleari citati dal procuratore Barr.

Image credit TorrentFreak

Un interessante articolo di Bruce Schneier sull'eterna battaglia tra esperti di sicurezza informatica e politici: entrambi sono conviti di essere nel giusto e quello che Bruce Schneier propone è una nuova figura che racchiuda sia le competenze tecniche di un esperto di cybersecurity che la cognizione di causa sugli interessi pubblici di un politico.

Una figura rara ma non inesistente.

Image credit TorrentFreak

I prezzi che il broker di exploit Zerodium paga per gli zero-day sono in aumento: questo indica che mediamente è più difficile trovare bug gravi perché i prodotti sono scritti meglio che in passato e anche che la domanda di zero-day è in aumento.

Altra informazione interessante è che molte aziende hanno un programma di ricompense per i bug ma quello che pagano è drasticamente meno di quanto pagano i broker che poi, presumibilmente, li rivendono a chi li usa per scopi non leciti.

Via Bruce Schneier, Image credit Blue Solution Blog

Grazie ad una nuova legge dello stato della California avremo maggior sicurezza sui dispositivi IoT.

Questa legge impone a tutti gli oggetti connessi di avere un ragionevole livello di sicurezza: dato che i produttori di dispositivi IoT devono aggiornare il loro software per poter vendere in California e che non ha senso mantenere un ramo "sicuro" per la California e uno "insicuro" per tutti gli altri, questo miglioramento sarà per tutti.

Via Bruce Schneier

Interessante articolo di Bruce Schneier sull'uso dei dati personali degli IoT (per esempio videocamere di sorveglianza ma anche aspirapolvere e altro). I produttori di questi oggetti non pubblicano nulla sulla trasparenza nell'uso dei nostri dati e non commentano al riguardo quando interpellati.
Siete sempre convinti che sia bello, comodo e fantastico avere il proprio sistema di allarme, con magari videocamere interne, connesso via internet al sito del produttore?
Segue una traduzione molto libera del breve articolo di Bruce.

I dispositivi IoT sono dispositivi di sorveglianza e i produttori generalmente li usano per raccogliere dati sui loro clienti. La sorveglianza è ancora il modello di business di Internet e questi dati sono usati contro l'interesse dei clienti: sia dai produttori che da qualche terza-parte al quale il produttore vende i dati. Ovviamente questi dati possono anche essere usati dalle forze dell'ordine; lo scopo dipende dalla nazione.

Niente di tutto questo è una novità e molto di questo è spiegato nel mio (ndt suo: di Bruce) libro Data and Goliath. Quello che è comune per le aziende di Internet è di pubblicare un "rapporto sulla trasparenza" che indica almeno le informazioni generali su come le forze dell'ordine usano questi dati. Le aziende IoT non pubblicano questi report.
TechCrunch ha chiesto informazioni ad alcune di queste aziende e, fondamentalmente, ha scoperto che nessuno parla.

Via BoingBoing

1

Un aspirapolvere potrebbe essere trasformato in una spia e questo può succedere perché, prima di tutto, c'è la mania di avere tutto quanto connesso ad internet ( IoT ) e poi perché qualcuno ha avuto la strana idea di dotarlo di un microfono.

A questo punto, dato che spesso la sicurezza informatica di questi oggetti è molto bassa, succede che vengano trovati sistemi per manometterli e trasformarli in dispositivi di sorveglianza. In questo caso bisogna poter mettere fisicamente le mani sull'aspirapolvere quindi il tipo di attacco è limitato: se hai un malintenzionato in casa il problema maggiore non è l'aspirapolvere.

Bruce Schneier si domanda perché un aspirapolvere debba essere dotato di microfono e pure io me lo chiedo. In più mi chiedo anche il perché di questa mania di avere tutto connesso: soprattutto visto che quasi nessuno si cura della sicurezza di questi oggetti.

Se avete l'esigenza di esporre un servizio web di casa vostra e volete farlo in maniera sicura gestendo voi direttamente il tutto per avere il massimo controllo una soluzione è il reverse proxy con autenticazione.

Per fare un esempio potreste voler pubblicare in internet una ip cam di sorveglianza che guarda l'esterno di casa. Il modo più facile è di impostare una regola sul vostro router per aprire la porta della videocamera ma questo presenta almeno un paio di problematiche che portano a sconsigliarlo. La più ovvia è che la videocamera potrebbe non avere l'impostazione per proteggerla con password e non è bello che chiunque possa guardare fuori da casa vostra. Una seconda considerazione è sul grado di sicurezza della vostra ip cam: potrebbe avere dei bug che permettono ad un malintenzionato di prenderne il controllo o, anche se non ne avesse, in futuro potrebbero saltarne fuori e il produttore quasi certamente non pubblicherà un aggiornamento per tappare la falla.

La soluzione reverse proxy con autenticazione è indubbiamente più complessa ma permette di avere il pieno controllo della parte che si pubblica in internet e di poter quindi tenere aggiornati tutti i componenti alle ultime versioni: un sistema correttamente configurato e mantenuto aggiornato è una buona garanzia di sicurezza.

Cosa serve per realizzarlo? Prima indico un breve elenco di oggetti che servono e poi qualche dettaglio sulle configurazioni.

Elenco:

  • Un ip pubblico (niente NAT/Carrier Grade NAT altrimenti non siete raggiungibili dall'esterno)
  • Un router che possa tenere aggiornato un dns dinamico con il vostro ip (o un ip pubblico statico)
  • Un server sempre acceso da adibire a reverse proxy

Per accedere in maniera sicura bisogna esporre il servizio in HTTPS quindi usiamo Let's Encrypt per avere un certificato gratuito per il dns che abbiamo impostato nel nostro router.

Se utilizzare una Debian con Apache come web server allora dovete abilitare i vari moduli proxy e un idea di settaggi del reverse proxy potrebbe essere:

<VirtualHost *:443>
          SSLEngine on
          SSLCertificateFile /etc/letsencrypt/live/tuo.dominio.it/fullchain.pem
          SSLCertificateKeyFile /etc/letsencrypt/live/tuo.dominio.it/privkey.pem
          ServerAdmin tuaemail@example.it
          ServerName tuo.dominio.it
          ProxyPass / http://192.168.1.100/
          ProxyPassReverse / http://192.168.1.100/
          <Proxy *>
                    AuthType Basic
                    AuthName "Restricted Access"
                    AuthUserFile "/cartella/dove/metti/il/file/passwordapache"
                    Require user nomeutente
          </Proxy>
          </VirtualHost>
<VirtualHost *:80>
          ServerName tuo.dominio.it
          Redirect permanent / https://tuo.dominio.it/
</VirtualHost>

Come vedete ho messo un rediret permenent per HTTP (porta 80) in modo che se anche cerchi di accedere senza l'HTTPS vieni rediretto sul sito sicuro. Nella sezione sopra, quella HTTPS (porta 443), ho indicato le posizioni dei certificati, l'ip interno del web server da esporre (da notare che può essere anche solo HTTP ma verso l'esterno viene fatto transitare HTTPS), come AuthName non mettete nulla di personale perché è visibile a chiunque prima dell'autenticazione e poi c'è il file dove salverete utente e password.

Fatto in questo modo potete accedere da internet al vostro servizio web semplicemente con https://tuo.dominio.it/ vi apparirà la richiesta di nome utente e password e tutto quanto transiterà in maniera cifrata.

Come avevo preannunciato in dicembre 2016 ho finalmente implementato l'https su questo blog.

A parte l'accesso amministrativo che richiede un autenticazione e quindi mandare le credenziali in chiaro (con http) non è sicuro, il resto non ha un motivo pratico per richiedere la cifratura delle comunicazioni.

Il motivo è un altro. A tendere tutti i siti web dovrebbero passare ad https e questo porterà all'abitudine di aspettarsi che un sito sia https. Questo aiuta ad essere sicuri che il sito che si sta visitando sia realmente quello che ci aspettiamo.

In realtà anche un malintenzionato può mettere in piedi un sito truffa in https ma almeno dovremo solo controllare il nome del sito a destra del lucchetto per essere sicuri che corrisponda a quello sul quale volevamo andare.

Anche google dice ormai che nei risultati delle ricerche verranno penalizzati i siti che non saranno in https quindi conviene non rimanere indietro.

Ora veniamo a qualche informazione tecnica che potrebbe esservi utile per la

MIGRAZIONE DA HTTP A HTTPS

Il passaggio, che è sempre un pre requisito ogni volta che si mette mano al proprio blog, è quello di fare un backup completo: sia del database che della /var/www del blog (o della cartella dove risiede)

Come segnalato all'inizio con il link al mio vecchio post il primo passaggio è quello di richiedere il certificato.

Se nei vostri vecchi post avevate delle immagini e i link erano con indicato http avrete un problema: i browser segnaleranno qualcosa che non va. Per sistemare ho usato un plugin wordpress che si chiama Search & Replace e ho sostituito src="http:// con src="// togliendo così il riferimento e lasciando il default del sito. Ovviamente nelle impostazioni generali dovrete cambiare l'indirizzo del blog mettendo https.

Anche da altre parti potrebbe essere rimasto qualche riferimento ad immagini http. Tipicamente nelle colonne laterali ma si tratterà di pochi link che dovrete controllare a mano e sistemare senza la necessita di tool automatizzati come per le immagini dei post che invece potrebbero essere tante.

Che dati bisogna backuppare?

La domanda sembra banale ma non lo è visto che nasconde delle insidie.

In un mondo perfetto tutti i dati dovrebbero essere salvati ma nella vita reale è importante scegliere perché, se si esagera, va poi a finire che c'è così tanta roba da salvare che passa la voglia oppure finisce lo spazio per i backup.

Come primo passaggio consiglio di suddividere i vostri dati in due grandi categorie: la prima comprende quelli che, se persi, non sareste più in grado di riavere (foto personali, documenti personali) e la seconda tutto il resto e quindi quei dati che potete scaricare o ricreare senza troppa fatica (app del telefono, programma del computer, foto pubbliche per esempio quelle che usate come sfondi ecc. ecc.)

La prima categoria dovete backupparla, la seconda no.

Ora che abbiamo il criterio su cosa va backuppato dobbiamo applicarlo a tutti i nostri supporti che contengono dati: attenzione a non dimenticarne. Ad esempio avremo sicuramente dei dati sul telefono e su tablet e computer ma ci sono anche dei dati sul cloud; ad esempio potreste avere Dropbox: non commettete l'errore di pensare che su un sistema remoto di archiviazione i dati siano al sicuro e non serva il backup.

Queste sono solo delle indicazioni di massima ma vi saranno utili per scoprire cosa backuppare.

Foto credit Evan Dennis

Ricordatevi di fare il backup dei vostri dati e di farlo regolarmente.

Come tutti sanno "i backup non servono a nulla" e difatti è così ma solo fino a quanto non ti accorgi che hai perso dei dati. In quel momento ti rendi conto che, se avessi fatto regolarmente il backup, ora potresti recuperali.

Detta così aiuta poco perché l'argomento è veramente ampio ma conto di sviscerarlo per bene trattando tutti gli aspetti. Tanto per capirci: quali dati backuppare, quando backupparli, con che strumento backupparli, dove conservare i backup, in quante copie conservare i backup, per quanto tempo conservare i backup e forse anche altro.

Per iniziare vale il suggerimento del titolo: quale che siano i vostri dati salvatene subito una copia, fatelo regolarmente e possibilmente su un supporto diverso da quello dove risiedono: i dati sono su un computer? Salvate una copia su una chiavetta usb o su un dvd.

Si tratta solo di una indicazione rapida e per nulla completa ma è meglio di nulla: per il resto seguiranno altre interessanti informazioni.