Vai al contenuto

La funzione di tethering è utile per condividere la connessione internet dello smartphone con altri dispositivi che non ne hanno una: tipicamente mentre siamo in giro in luoghi dove non abbiamo un wifi a disposizione e vogliamo usare, ad esempio, il pc portatile con una connessione internet.

Con uno smartphone Android ho sempre usato questa funzione trovandomi bene e per anni ho avuto un vecchio smartphone con Android 7. La procedura era semplice: attivi l'hotspot wifi del cellulare e ti ci colleghi dal pc portatile.

Non so da quale versione Android in avanti ma sicuramente dalla 13 ho notato un comportamento strano. Attivando l'hotspot wifi non viene automaticamente spenta connessione wifi ma rimane accesa. In questo modo l'hotspot condivide la connessione wifi del cellulare tramite wifi invece che condividere la connessione dati del cellulare (per capirci 3G/4G/5G). Si tratta di un caso particolare in quanto, tipicamente, quando accendi l'hotspot è perché non hai a disposizione un wfi ma con Android 7 automaticamente si spegneva il wifi del cellulare e quindi non poteva succedere. Il motivo potrebbe anche essere perché l'hardware wifi del cellulare (vecchio, visto che usa un Android 7) non supporta un uso contemporaneo (wifi per collegarsi ad una rete wifi e wifi per esporre un hotspot wifi) e quindi spegne il wifi e non per una scelta del sistema operativo di spegnerlo ma per un obbligo fisico.

Segnala Bruce Schneier che negli usa, i mandati di geolocalizzazione di massa di un area geografica, sono stati dichiarati incostituzionali da una corte federale.

Questa tecnica investigativa è una richiesta a chi detiene i dati (gestori di reti cellulari, Google e altri) di fornire l'identificazione di tutte le persone presenti in una area geografica delimitata in un dato momento. Concordo con Bruce Schneier che dice che a lui pare ovvio ma che non si può dare nulla per scontato.

Da alcuni giorni sto utilizzando Simplenote: un programma che, come si intuisce dal nome, gestisce in maniera semplice le note. C'è un app per Android e per altre piattaforme e c'è pure la versione per Linux.

Io uso Ubuntu e ho trovato un problema intermittente che gli impedisce di partire. Se lo lanciate da riga di comando spesso vi restituisce questo errore prima di andare in crash

FATAL:gpu_data_manager_impl_private.cc(415)] GPU process isn't usable. Goodbye.

Ho trovato che questo bug è tipico di altri programmi che usano Electron e il workaround per evitare che vada in crash è di farlo partire con un --no-sandbox

Se lo lanciate da interfaccia grafica dovete editare come root il file /usr/share/applications/simplenote.desktop cambiando la riga di Exec da

Exec=/opt/Simplenote/simplenote %U

a

Exec=/opt/Simplenote/simplenote --no-sandbox %U

In questo modo partirà sempre senza andare in crash.

Leggendo un post di Stefano Quintarelli ho scoperto questo interessante browser: LibreWolf.

Si tratta di un browser basato su firefox e focalizzato sulla privacy, sulla sicurezza e sulla libertà.

Si può installare su svariate piattaforme e sicuramente lo proverò.

L'interoperabilità dei sistemi di messaggistica è un ottimo obbiettivo perché impedisce che un utente sia bloccato da un software di messaggistica e, di conseguenza, favorisce sia la libertà che la concorrenza. Anche Bruce Schneier afferma che in teoria è un bene.

Dei ricercatori hanno valutato che l'interoperabilità porta ad una superficie di attacco maggiore su parecchi aspetti. In pratica succede che la sicurezza complessiva diventa pari a quella della piattaforma peggiore: un brutto livellamento verso il basso diventa il risultato dell'applicazione di un principio che dovrebbe essere buono.

L'algoritmo a chiave pubblica CRYSTALS-Kyber è raccomandato dal NIST nel processo di selezione della crittografia post-quantica.

Dei ricercatoti hanno pubblicato un attacco Side-Channel basato sul consumo di corrente e si supponeva che questo algoritmo fosse resistente a questo tipo di attacco.

La parte interessante, fa notare Bruce Schneier, non è tanto l'attacco in se ma che abbiano usato una tecnica di machine learning per istruire il sistema su come portarlo a termine: effettivamente è importante notare che una tecnica relativamente nuova come quella del machine learning possa essere usata per trovare vulnerabilità e, ovviamente di contro, anche per forzare un sistema.

Capita di dover aprire un tunnel socks5 ma se poi questo tunnel deve restare aperto per ore e magari resistere a vari eventi avversi non basta il semplice comando ssh

ssh -ND 8080 root@192.168.1.1

perché se il server destinazione (il 192.168.1.1) ad esempio viene riavviato il tunnel cade. Per ovviare a questo ed altri inconvenienti basta un breve script che si occupa di verificare che il tunnel sia aperto e, in caso contrario, che lo apra e che faccia tutto questo all'infinito. Quantomeno fino a quando non lo blocchiamo a mano noi.

Questo è lo script bash

#!/bin/bash
# Script che apre e tiene aperto un tunnel socks5
# porta utente e ip o dns sono hardcoded ma volendo potrebbero essere messi come parametri

# Ciclo while infinito
while true
do
# Il comando if verifica l exit code del comando che sta cercando qualcosa in LISTEN sulla porta 8080 che è il mio tunnel 
  if netstat -an | grep 8080 | grep -q LISTEN 
  then
# Se lo ha trovato allora entra qui e attende 1 secodo poi salta il ramo else e ricomincia il coclo infinito
    sleep 1
  else
# Se non lo trova allora entra qui e il comando sotto crea in background il tunnel e poi aspetta 2 secondi poi continua il ciclo infinito
    nohup ssh -ND 8080 root@192.168.1.1 > /dev/null 2>&1 &
    sleep 2
  fi
done

Nagios

Era da più di due anni che non uscivano aggiornamenti per Nagios Core. Nel 2022 ne sono già usciti 3, l'ultimo dei quali pochi giorni fa.

Visto il lungo periodo di assenza potreste aver dimenticato di aggiornare oppure, visto che la versione 4.4.7 ha un bug che porta a dover disabilitare il check della release, potreste essere giustificati quindi ho pensato di avvisare che ora l'ultima release è la 4.4.9 quindi correte ad aggiornare.

Tesla Model 3 (auto elettrica su wikipedia)

Si sente alle volte dire che le auto elettriche richiederanno troppa elettricità al sistema mettendolo in crisi: non è vero perché la quantità di elettricità aggiuntiva richiesta è modesta, è in crescita graduale (le auto elettriche sono in crescita graduale) e potranno addirittura essere la soluzione ad un problema che invece è reale. Quello della stabilizzazione dei carichi di rete.

Tutto passa da volontà politiche, modifiche alle normative e incentivi. Per diverse ragioni è utile puntare sulla produzione di elettricità da fotovoltaico (è più economico, ci rende indipendenti dall'estero, abbiamo tanto sole) e questo richiede che vengano sbloccati progetti già pronti a partire riducendo la burocrazia normativa. Una volta che il fotovoltaico sarà libero di cresce avremo abbondante energia elettrica ma, per sua natura, intermittente (legata alle condizioni meteorologiche). È qui che nuovamente entra in gioco la normativa: un auto elettrica predisposta a VTG (Veicle To Grid: dall'auto alla rete elettrica) che venisse lasciata connessa alla rete potrebbe fornire energia alla rete nei momenti di scarsità (con vantaggi economici per il proprietario dell'auto) stabilizzando la produzione elettrica.

Quindi l'unico vero problema futuro reale, l'intermittenza della produzione elettrica fotovoltaica, potrebbe essere risolto dalle tante e capaci batterie delle auto elettriche connesse alla rete con tecnologia VTG. Basterebbe solo adeguare la normativa per consentirlo.

All'interno di un attacco informatico condotto dalla corea del nord contro ricercatori di sicurezza informatica dell'ovest l'hacker indipendente P4x è stato colpito direttamente e non l'ha presa molto bene.

Visto che, dopo un anno, nessuno ha preso provvedimenti ha pensato di darsi da fare lui per portare avanti il principio che "Se non vedono che abbiamo i denti, semplicemente continueranno a tornare" e gli è riuscito piuttosto bene visto che ha tirato giù tutti i router chiave del paese causando il blocco totale di internet.

Quindi occhio a far arrabbiare un hacker 😉

Via Quintarelli e Wired

Sono ormai alcune settimane che ho iniziato ad usare Syncthing (Open Source) per tenere sincronizzati file e cartelle tra i miei vari computer, server e smartphone e devo dire che come alternativa a Dropbox è veramente interessante.

Il compito che svolge è simile da Dropbox ma ci sono alcune differenze.

Syncthing non ha un server proprio dove custodisce una copia online dei dati come fa Dropbox quindi niente interfaccia web per la gestione dei propri file ma anche niente limiti di spazio. Si può tenere in sincronia tutti i file che si vuole e il limite è dato solo dallo spazio disco dei vostri dispositivi.

La gestione del versioning dei file è decisamente più articolata e flessibile ma come contro, ovviamente, utilizza il vostro spazio disco. Basta avere l'accortezza di attivare un versioning molto esteso solo su un computer con molto spazio storage per aggirare il problema: per esempio su uno smartphone solitamente non è il caso di sprecare spazio.

Il client Android ha il vantaggio di salvare una copia locale così da avere i dati disponibili anche offline ma, di contro, non è possibile selezionare una scheda sd come destinazione

Ci sarebbero svariate altre caratteristiche e informazioni interessanti ma mi sono limitato a citare i principali pro e contro di Syncthing rispetto a Dropbox.

sync image by Chris Veight

Un applicazione per smartphone intelligente ha dei dati salvati in modo da poterli usare anche da altri dispositivi: l'esempio più facile è un blocco note che viene usato dall'app sul telefono ma anche da computer e da tablet.

L'approccio più tipico e facile è di avere un server centrale di proprietà di chi sviluppa e rende disponibile l'applicazione al quale si collegano tutti i dispositivi in modo da tenere aggiornati i dati. Si tratta della soluzione più facile per l'utente che deve solamente avere un account che poi imposta sui vari dispositivi per trovare tutti i suoi dati su tutti i dispositivi.

Una seconda possibilità è di poter impostare l'utilizzo di un proprio server per sincronizzare i dati. Questa opzione richiede competenze e risorse dell'utilizzatore che non sono più da utente e richiede anche che il software per implementare il server sia disponibile. Di contro ci sono notevoli vantaggi dal punto di vista della sicurezza (i miei dati sono solo su miei dispositivi/server) e della continuità del servizio (se chiudono il server centrale io continuo ad avere il tutto funzionante perché uso un mio server)

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

Voi sareste pronti ad abbandonare Google come ha fatto il Quinta?

Io, francamente, non ancora anche se è da tempo che ci sto pensando.

Probabilmente potrei iniziare a sostituire qualcuno dei servizi che uso con delle alternative che Stefano Quintarelli segnala. Magari partendo da allwaysync.

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 anche voi usate da sempre FoxyProxy per gestire i proxy di Firefox vi sarete accorti che per un po' di tempo non era stato aggiornato per essere compatibile con la nuova tipologia di plugin di Firefox. Nel frattempo mi sono arrangiato a mano e poi ho dimenticato di controllare.

Ora mi sono accorto che è stato aggiornato (in realtà totalmente riscritto) e quindi possiamo tornare ad usarlo.

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.