Archivi tag: ip camera

WI-FI IP camera (made in China): mettere al sicuro l’accesso da remoto

Problema

Negli ultimi anni si è assistito ad un vero e proprio boom riguardante l’acquisto di dispositivi di videosorveglianza basati sul protocollo IP,  ergo facilmente integrabili con le piccole reti domestiche preesistenti. Fin qui nulla di male, se non fosse che, spesso e volentieri, tali “aggeggi” montino dei firmware poco affidabili dal punto di vista della cybersecurity. Mi spiego meglio: cosa accadrebbe se consentissi l’accesso da remoto alla pagina Web di amministrazione della mia telecamera IP? Chi mi garantisce che:

1) Il codice server-side della suddetta pagina non sia vulnerabile;

2) Che non siano presenti una o più backdoor all’interno del codice sorgente del firmware.

dbpowerSoluzione

Se disponete di un server Linux a risparmio energetico (come nel mio caso) è possibile mettere al sicuro l’accesso da remoto alla nostra telecamera IP mediante l’uso di un reverse proxy. In particolare, la configurazione che sto per illustrarvi riguarda uno dei server Web più utilizzati in ambito open source, ovvero Apache.

Supponendo che la mia telecamera IP sia in ascolto sulla porta TCP 81 (HTTP-Alt) e che risponda all’indirizzo 192.168.1.5 , ecco la configurazione da me adoperata:

<VirtualHost *:81>
    ProxyPass / http://192.168.1.5:81/
    ProxyPassReverse / http://192.168.1.5:81/

    <Proxy *>
        Order deny,allow
        Allow from all
        AuthName "IPCamera Access"
        AuthType Basic
        AuthUserFile /etc/ipcam/passwd
        Require valid-user
    </Proxy>

</VirtualHost>

Nella fattispecie, oltre a loggare tutte le richieste di accesso provenienti dall’esterno (in modo da tenerne traccia), ho aggiunto un ulteriore meccanismo di autentica a quello già previsto dalla pagina Web di gestione. In questo modo sono riuscito a garantirmi 2 risultati:

1) Protezione contro attacchi di tipo Web-based;

2) Protezione contro eventuali backdoor presenti nel firmware.

Inoltre, dopo aver definito il suddetto VirtualHost, è stato necessario abilitare il modulo che fa funzionare Apache come reverse proxy, ovvero mod_proxy, decommentando o inserendo la seguente direttiva:

LoadModule proxy_module modules/mod_proxy.so

Per ciò che concerne le credenziali di accesso, invece, è stato possibile definirle utilizzando il comando htpasswd nel seguente formato:

[root@linuxbox ~]# htpasswd -c /etc/ipcam/passwd nomeutente

Infine ho ricaricato la configurazione di Apache per rendere effettive le suddette modifiche:

[root@linuxbox ~]# service httpd reload

Ora la vostra telecamera IP può essere considerata “relativamente” al sicuro.

Alla prossima.

Sistema di videosorveglianza fatto in casa

Ok, vi ho già parlato di questa IP camera in due recenti post. Dopo aver risolto tutte le grane che la configurazione di questo aggeggio ha comportato, ho deciso di allestire un sistema di videosorveglianza home made, in modo da registrare tutto ciò che la telecamera riprende durante certe fasce orarie.

Premesso che il firmware della telecamera in questione consente già di effettuare delle registrazioni video in tempo reale, ho deciso di utilizzare un sistema alternativo per due motivi:

1) la registrazione può avvenire solo ed esclusivamente sul PC locale, ovvero quello su cui viene visualizzata l’interfaccia Web della cam;

2) la registrazione può essere inizializzata solo ed esclusivamente se si utilizza Internet Explorer. Con tutti gli altri browser tale opzione non è nemmeno visualizzabile.

Ingredienti

Bene, come avrete certamente intuito l’IP camera che monta il firmware MyGion è uno degli ingredienti fondamentali. Gli altri ingredienti sono:

1) server a risparmio energetico con doppio HD, uno per il sistema operativo ed uno dedicato al salvataggio delle registrazioni. Per quest’ultimo è consigliata una dimensione pari o superiore a 500GB;

2) AP che supporti la modalità di cifratura WPA/WPA2;

3) Sistema operativo GNU/Linux. Nella fattispecie ho utilizzato Debian come distrubizione.

4) Software per la gestione dello streaming, ovvero VideoLAN (aka VLC).

Vi risparmio tutta la procedura di formattazione dei dischi, installazione e configurazione del SO, anche perchè su Internet ci stanno tonnellate di roba a riguardo. Dunque vado dritto al punto.

Configurazioni

Per prima cosa occorre configurare VLC in modo da gestire correttamente il traffico RTSP generato dall’IP camera. In particolare, è necessario procedere come segue:

1) Cliccare su Strumenti -> Preferenze -> Ingresso e codificatori (come riportato nel seguente screenshot):

vlc1.png

2) Alla voce Trasporto flussi Live555 selezionare RTP su RTSP (TCP).

A questo punto VideoLAN sarà in grado di ricevere lo streaming proveniente dalla nostra IP camera.

Esecuzione da terminale

L’esecuzione di VLC può avvenire anche mediante CLI e tale soluzione è molto utile nel caso in cui si voglia gestire il sistema di videosorveglianza da remoto. Nello specifico, il comando che ho utilizzato è il seguente:

vlc --x11-display :0.0 rtsp://username:password@ip:porta/display
 --sout '#duplicate{dst=display,dst="transcode{vcodec=mp2v,acodec=mpga,vb=800,ab=64,deinterlace}
 :std{access=file,mux=ts,dst='/media/data/recording/output.mpg'}"}'

Si, lo so, la suddetta chain, a primo acchito, può risultare incompresibile, quindi ho deciso di applicare la famosa tecnica divide et impera per illustrarvene il significato nel dettaglio.

A parte il comando vlc che serve a lanciare l’applicativo in questione, ho utilizzato le seguenti opzioni:

1) –x11-display, che consete di specificare il display su cui inviare lo streaming della telecamera. Per identificare il display utilizzato dal vostro Desktop Enviroment (ad esempio KDE) è sufficiente lanciare il comando:

nightfly@nightbox:~$ echo $DISPLAY

2) rtsp://username:password@ip:porta/display rappresenta semplicemente la URL RTSP associata alla nostra IP camera. Ad esempio, potrebbe assumere la forma:

rtsp://foo:Secret33@192.168.12.44:80/0

3) –sout, la quale permette di manipolare l’output in diversi modi. In particolare, ho deciso di salvare le registrazioni su file, ecco come:

3.1) mediante la direttiva #duplicate ho “clonato” l’output a video;

3.2) con la direttiva transcode sono riuscito a comprimere al volo l’audio/video, poichè, per default, VLC genera file di grandi dimensioni. A tal proposito, con vcodec ho specificato il tipo di codec video da utilizzare (mp2v, secondo me il giusto compromesso tra qualità e spazio su disco richiesto); con acodec ho definito il tipo di codec audio (mpga, per questioni di portabilità); con vb ed ab ho settato, rispettivamente, il bitrate video e quello audio;

3.3) mediante i due punti (:) ho fatto in modo che il risultato del transcoding venisse rediretto sullo standard output (standard alias std), in particolare su un file (access=file), mescolando audio e video tramite la multiplazione ts (mux=ts) e specificando il filename di destinazione (dst=’/media/data/recording/output.mpg’);

Ora, affinchè il suddetto comando possa essere lanciato da terminale (o da emulatore) e rimanga in eseguzione anche dopo la chiusura di quest’ultimo è sufficiente anteporgli il comando nohup:

nightfly@nightbox:~$ nohup vlc --x11-display :0.0 rtsp://username:password@ip:porta/display --sout '#duplicate{dst=display,dst="transcode{vcodec=mp2v,acodec=mpga,vb=800,ab=64,deinterlace}
 :std{access=file,mux=ts,dst='/media/data/recording/output.mpg'}"}'

Esistono altri apllicativi in grado di svolgere la medesima funzione di nohup (ad esempio screen), ma ho preferito utilizzare il suddetto comando per questioni di portabilità e perchè, in genere, è consigliabile installare su un sistema meno roba possibile (less is more).

Ovviamente, se volete che il vostro sistema registri lo streaming dell’IP camera solo in determinate fasce orarie, potete semplicemente schedulare l’esecuzione di VLC tramite cron.

E’ tutto. Alla prossima.