Creazione di un media center casalingo

Ho deciso da un po’ di tempo di creare un media center casalingo basato su Linux (anche se esistono delle ottime alternative open source basate su Windows).

Questo post descriverà tutto quello che ho fatto, controllatelo spesso se vi interessa perchè lo aggiornerò abbastanza frequentemente, fino alla fine del porgetto (che è ancora in essere).

Il software scelto è MythTV su Ubuntu 8.10, che permette anche di creare configurazioni più elaborate (uno più backend per registrare e memorizzare i dati multimediali e uno o più frontendo per vederli).

Hardware

Cominciamo dall’hardware usato, e relativi prezzi:

• Computer Mini ATX, con 1Gb di RAM e processore Intel a 2,6 GHz
  Scheda video integrata, uscita VGA, DVI, S-Video + USB frontali, Ethernet 10/100, firewire.
  Masterizzatore DVD DL
  Alimentatore esterno.
  Potete usare qualsiasi computer come frontend, l’importante è che sia piccolo, economico (niente schede video meravigliose, basta che abbiano l’uscita S-Video), silenzioso.
  Per un totale di circa 200€
• Hard disk SATA 160Gb (Seagate).
  Non so il prezzo, ce l’avevo a casa, non più di 40€ probabilmente.
• Scheda acquisizione digitale terrestre HAUPPAUGE WinTV Nova T-Stick DVB-T USB, comprata online qui.
  Prezzo: 32,90€+6,58€ (spedizione) = 39,48€
• Telecomando economico con ricevitore USB.
  Si trova anche sulle bancarelle per strada, io l’ho preso qui.
  Prezzo: 5,99€+5,00€= 10,99€
• Lettore Schede Memoria Interno 3,5″ per PC Nero CF – MD – MS – SD – MMC – SM – XD – T-F – USB 2.0
  Anche questo comprato qui.
  Prezzo: 9,99€+4,50€=14,49€
• Dongle USB Wi-Fi.
  Anche questo ce l’avevo a casa, non pagatelo più di 20€
  
• Antenna UHF per ricezione digitale terrestre (la mia è arrivata e quella che danno con la Hauppauge è inutile).
  E’ ancora in fase di acquisto, comunque non vorrei spenderci più di 25/30€
• Sistema di videosorveglianza con telecamere a infrarossi.
  L’idea è di prendere questo che mi sembra conveniente ma vorrei trovare almeno due telecamere wireless.
  Spesa prevista: non più di 150€

In futuro probabilmente aggiungerò anche una webcam e un microfono. Per quanto riguarda il televisore, per ora mi accontento del mio buon vecchio CRT con due ingressi SCART e un S-Video.

Struttura del sistema

Nonostante MythTV possa essere usato in motli modi, preferisco una configurazione classica, con backend e frontend sulla stessa macchina, server MySQL senza password (e senza accesso da remoto).

L’idea è che i files multimediali vengano montati come risorse nfs da un server centralizzato (che ho già a casa) facilitando in questo modo il backup e l’aggiunta di nuovi media.

L’accesso alla televisione digitale terrestre avviene tramite la scheda TV Hauppauge, la registrazione dei canali viene però fatta in locale (non su nfs). Se ci fosse bisogno di salvare qualcosa, in quel caso si potrà esportare sul server nfs centrale.

Per quanto riguarda la videosorveglianza, ancora non so bene come configurare il tutto, probabilmente mi affiderò ad un ciclico per le telecamere e a ZoneMinder e Motion.

Appena ho tempo faccio un piccolo diagramma…

Installazione del telecomando

Questo telecomando da pochi soldi funziona semplicemente “out of the box” con Ubuntu, sia per quanto riguarda MythTV sia per quanto riguarda il normale desktop (XFCE o Gnome). Certo, non tutti i tasti funzionano e la disposizione non è delle più ergonomiche per un media center, ma il prezzo è ottimo.

Dato che il ricevitore sembra essere abbastanza semplice e versatile, si può sempre provare a usare un telecomando universale…

Come al solito, è una cosa che rimanderò a più tardi…

Installazione della rete (wifi)

La soluzione migliore sarebbe far arrivare direttamente un cavo di rete fino al pc ma la disposizione delle tracce della casa non lo permette. Per questa ragione utilizzo un router con antenna wifi e una pennetta D-Link System DWA-140.

L’installazione dei driver è stata piuttosto semplice: ho installato prima ndisgtk

sudo apt-get install ndisgtk

Quindi avviando l’interfaccia grafica di ndiswrapper ho selezionato il file .inf dal cdrom di installazione della pennetta e tutto ora funziona alla perfezione…

Installazione del sistema

Dopo aver assemblato tutte le parti hardware, installiamo sul Mythbuntu avendo cura di fare un partizionamento del genere:

• 30 Gb o più alla partizione /
• swap q.b (uguale alla ram o il doppio di essa, a seconda di come vi trovate meglio)
• tutto il resto a /var che viene usato da MythTV per salvare ed elaborare i media.
• ovviamente tutto in ext3…

Finita l’installazione del sistema è ora di schiaffarci dentro un paio di pacchetti prima di procedere all’installazione di MythTV:

sudo apt-get update
sudo apt-get install xubuntu-restricted-extras vlc

Prima configurazione di MythTV

Per prima cosa eseguiamo il frontend dal menu di gnome (MythTV Frontend) e controlliamo che tutto funzioni correttamente.
Ovviamente ne la televisione ne i vari tipi di media funzioneranno finchè non configureremo la scheda di acquisizione video o aggiungeremo qualche file multimediale.

Come prima cosa lanciamo il Mythbuntu Control Centre, e da li alla voce “Applications & Plugins” selezioniamo tutti i plugin.  Alla voce “System services” mettiamo su Enable tutti i servizi.
Alla sezione “Artwork and Login Behaviour” barriamo la checkbox per l’avvio automatico di MythTV e selezioniamo l’utente tv (se così si chiama l’utente che abbiamo creato) per il login automatico.

Infine nella sezione “Restricted Drivers” selezioniamo le voci non selezionate e infine clicchiamo su Apply. Attendiamo che il sistema scarichi ed installi tutto il necessario e poi, per sicurezza, riavviamo Ubuntu.

Come prima cosa testiamo le cose semplici, come la riproduzione di audio e video non provenienti dalla scheda di acquisizione tv. Copiamo quindi alcuni files codificati in DivX all’interno di /var/lib/mythtv/videos (cartella di cui creeremo un collegamento sul desktop, dato che presumibilmente utilizzeremo parecchio) e lanciamo dal frontend: Utilities/Setup e quindi Video Manager; qui vedremo tutti i nostri bei files che abbiamo messo nella cartella

CONTINUA…

Collaborare con Ubuntu (Bug testing)

Molte persone (o almeno io) si sono chieste come si può dare una mano ad Ubuntu. In effetti sul sito sono presenti indicazioni chiare, ma si rischia di perdersi nelle burocrazie interne della comunità.

Scrivo ciò che ho fatto e cosa bisognerebbe fare per cominciare a collaborare con questa distribuzione Linux sudafricana:

1. Come prima cosa bisogna avere una chiave OpenPGP con cui firmare patch, documenti ed altro. Generatela con il vostro programma preferito (il mio è GnuPG).
2. Iscrivetevi a Launchpad, la piattaforma collaborativa che Ubuntu utilizza per la gestione dei bug, delle traduzioni ecc…
   Curiosando su Launchpad potrete trovare anche altri progetti interessanti con cui collaborare, se ne avrete il tempo e la voglia.
3. Seguite le indicazioni dopo la registrazione per la convalida della vostra chiave pubblica OpenPGP. Vi verrà inviato un messaggio cifrato con la suddetta chiave contente un link che vi permetterà di associare al vostro nome (login) la vostra chiave.
4. Sempre tramite Launchpad iscrivetevi all’Ubuntu Bugsquad. La registrazione è libera e non moderata, e potrete trovare molte risorse sui bug, nonché cominciare a conoscere la struttura della comunità.
   Altre informazioni su BugSquad sono presenti su https://wiki.ubuntu.com/BugSquad
5. Iscrivetevi alle seguenti mailing list per essere sempre aggiornati (non scegliete una password importante perché vi verrà ricordata in chiaro di tanto in tanto):
   ubuntu-bugsquad@lists.ubuntu.com (iscrizione da https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad)
   ubuntu-news@lists.ubuntu.com (iscrizione da https://lists.ubuntu.com/mailman/listinfo/ubuntu-news)
   ubuntu-it@lists.ubuntu.com (iscrizione da https://lists.ubuntu.com/mailman/listinfo/ubuntu-it)
   Non hanno un gran traffico, ma se non vi piacciono molti messaggi nella casella di posta scegliete il digest giornaliero.
6. Scaricate un client IRC se non l’avete già (su Linux mi trovo bene con XChat), scegliete un nickname, andate su irc.freenode.net e se il vostro nick non è stato usato registratelo con:
   /msg nickserv register <your-password> <your-email>
   vi arriverà una email sulla casella di posta che avete fornito con un comando da lanciare in irc, fatelo, dopodiché lanciate anche
   /msg nickserv set hidemail on
   per evitare che gli altri possano vedere la vostra email.
   Per fare in modo che il vostro nick venga riconosciuto, quando vi connettete al server (molti client lo fanno in automatico) lanciate:
   /msg nickserv identify <your-password>
   A qusto punto mettete in autojoin i seguenti canali (se non sapete come si fa leggete la documentazione del vostro client):
   #ubuntu-bugs-announce (non si parla, vengono pubblicati in tempo reale i bug)
   #ubuntu-bugs
   #ubuntu
   #ubuntu-it
7. Andate sul vostro profilo su launchpad e cliccate in alto a sinistra sul link “Change details“, poi in basso sul link “Update IRC nicknames” quindi riempite il primo capo con il server (irc.freenode.net) e il secondo con il nick che avete registrato. Salvate e il vostro nick verrà associato all’account su freenode in modo che le persone possano contattarvi anche in chat.

Ora che avete compiuto tutti i passi fondamentali non vi resta che mettervi alla ricerca di bug non ancora presi in gestione e occuparvene, se siete in grado. Molte pagine sul wiki ufficiale descrivono le procedure per fare questo, io vi incollo un po’ di link da mettere nei preferiti per avere sempre a portata di mano gli strumenti:

https://bugs.launchpad.net/ubuntu
Questo è il pannello di controllo dei bug di Ubuntu; se impostate sul menu a tendina “newest first” vedrete quelli da processare, che poi sono gli stessi che si vedono in tempo reale sul chan #ubuntu-bugs-announce.
Altrimenti se conoscete bene un pacchetto potete cercarne qualcuno non ancora elaborato (cioè in stato “new” e importance “undecided“) inserendo il nome del programma nella textbox e cliccando sul bottone “Search”.

https://wiki.ubuntu.com/Bugs/HowToTriage
Questa è la pagina del wiki fondamentale per chi si avvicina per la prima volta al mondo del BugTrialing in Ubuntu. Vengono descritte le procedure da seguire, come cercare e gestire i bug duplicati e tutto quello che vi può servire. Va letta e riletta parecchie volte, e magari anche stampata e tenuta accanto alla tastiera.

https://wiki.ubuntu.com/Bugs/Responses
Dato che bisogna sempre usare cortesia con chi ci comunica un bug, è nata questa pagina con molte riposte standard da usare nelle varie situazioni.

https://wiki.ubuntu.com/BugSquad/KnowledgeBase
Tutto quello che vi può servire è qui.

Una volta che avrete acquistato dimestichezza con il sistema e che avrete contribuito per un tempo sufficientemente lungo ai progetti che la comunità Ubuntu porta avanti (non solo bug, ma anche traduzioni, ad esempio) potete pensare di proporre la vostra iscrizione come Members ufficiali di Ubuntu. La procedura è abbastanza lunga, quindi riporto il link che la descrive nel dettaglio:
https://wiki.ubuntu.com/Membership?action=show&redirect=NewMemberHowto
Ovviamente la cosa migliore è diventare membro prima del proprio gruppo locale, nel nostro caso di quello italiano, che è raggiungibile a questi indirizzi:
http://wiki.ubuntu-it.org/Comunita/Membership

https://launchpad.net/~ubuntu-it-members

Port Knocking, OpenVPN e IPTables

Nel precedente articolo ho spiegato come attivare un servizio OpenVPN sul proprio “server” casalingo e connettersi in questo modo alle proprie risorse in qualunque parte del mondo, lasciando aperta solo una porta.

Dato che la paranoia non è mai troppa, vediamo di complicare ancora di più le cose ad un eventuale attaccante che volesse tentare di sfruttare magari un bug ancora non corretto della nostra VPN. Il modo migliore di impedire ad una persona di connettersi ad un servizio è nasconderlo, ovviamente dopo l’uso di un meccanismo di autenticazione forte. Chiudendo la porta 1194 impediremo ad ogni utente che non conosca una particolare “combinazione” di rilevare qualsiasi cosa da un port-scanning. Ovviamente faremo in modo che la porta si apra solo per noi e per il tempo strettamente necessario alla nostra connessione.

La prima cosa da fare è installare tramite aptitude un demone per il port-knocking. Per Ubuntu c’è knockd che è molto leggero, affidabile e stabile. Installiamolo con:

sudo aptitude install knockd

A questo punto il servizio sarà avviato. Se siamo dietro ad un router consiglio di mettere l’ip interno del nostro server in DMZ, in modo tale da non rivelare nulla neanche attraverso il NAT del router ad un eventuale attaccante.

La prima cosa da fare con knockd è editare il file /etc/default/knockd per modificare la linea

START_KNOCKD=0

in

START_KNOCKD=1

In questo modo abbiamo abilitato a tutti gli effetti il demone knockd e siamo pronti a configurarlo per far si che apra le porte che vogliamo ad una specifica bussata. La configurazione è piuttosto semplice: se volessimo infatti far aprire la porta 1194, non dobbiamo far altro che decidere una sequenza di porte a cui “bussare” e specificarle nel file /etc/knockd.conf

Se ad esempio decidessimo che per aprire la nostra porta per l’OpenVPN la bussata debba essere 25, 2000, 4723, il file di configurazione assomiglierà a qualcosa del genere:

[options]
logfile = /var/log/knockd.log

[openOPENVPN]
sequence    = 25, 2000, 4723
seq_timeout = 5
command     = /sbin/iptables -A INPUT -s %IP% -p udp --dport 1194 -j ACCEPT
tcpflags    = syn

[closeOPENVPN]
sequence    = 4723,2000,25
seq_timeout = 5
command     = /sbin/iptables -D INPUT -s %IP% -p udp --dport 1194 -j ACCEPT
tcpflags    = syn

E’ abbastanza intuitivo: la prima sezione specifica il file di log che il demone utilizzerà (ricordatelo, perchè ci servirà quando proveremo la nostra bussata), la seconda sezione si pone in ascolto sulle porte 25,2000,4723 per attivare un comando se e solo se vengono mandati dei pacchetti syn nell’ordine che abbiamo specificato. Il comando è una semplice istruzione iptables che non fa altro che aprire la porta 1194 per l’IP che ha fatto al bussata (%IP% è una variabile propria di knockd).

A questo punto la porta è aperta e non verrà richiusa finchè non eseguiremo la bussata descritta nella sezione [closeOPENVPN]. In questo caso ho inserito come bussata le stesse porte dell’apertura ma in ordine inverso, ma si possono inserire anche altre porte o mettere altri ordini. E’ tutto delegato alla vostra fantasia e alla vostra memoria. Ovviamente viene eseguito il comando

command     = /sbin/iptables -D INPUT -s %IP% -p udp --dport 1194 -j ACCEPT

che non fa altro che eliminare la regola di iptables (-D) che avevamo descritto.

Ora che il file è stato configurato, manca solo una cosa: creare le regole base per iptables.
E’ assolutamente importante che i seguenti comandi siano dati in locale e non da una sessione SSH, ad esempio. Il motivo lo sa bene chi si è messo a giocherellare con iptables da remoto e si è trovato improvvisamente tagliato fuori. Se proprio non potete farlo, mettete tutti i comandi in uno script e lanciatelo.

Quello che ci interessa fare è impedire l’accesso a tutti i pacchetti in entrata e in forwarding, mentre lasceremo “senza regole” quelli in uscita. Ovviamente dovremo stare accorti che ogni servizio abbia comunque le sue porte aperte, quindi se avete aMule, server Web o altri tipi di server che richiedono una connessione indipendentemente dalla VPN, aggiungete le regole di conseguenza.

I comandi da lanciare (in locale) saranno allora:

sudo iptables -P INPUT DROP (fa "cadere" tutte le connessioni in entrata)
sudo iptables -P INPUT DROP (elimina tutti i forwarding (mica siamo un router...))
sudo iptables -A INPUT -i lo -j ACCEPT (accetta le connessioni dall'interfaccia di loopback)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT (fondamentale, accetta le connessioni già stabilite)
sudo iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT (accetta il ping)
sudo iptables -A INPUT -s 192.168.0.0/16 -j ACCEPT (ovviamente deve accettare connessioni dalla rete interna, a meno che non vogliate diversamente...)

Dato che tutte queste belle istruzioni andranno perse al prossimo riavvio, salviamo il tutto con un:

iptables-save > /etc/nostreregoleiptables

e modifichiamo il file /etc/network/interfaces aggiungendo subito prima della riga

auto eth0

questo comando:

pre-up iptables-restore < /etc/nostreregoleiptables

Ovviamente se la vostra interfaccia di rete è eth0, ma l’ho dato per scontato fin’ora. In realtà si potrebbe inserire lo stesso comando in /etc/rc.local, ma francamente lo trovo “più pulito” nel file di configurazione delle interfacce di rete.

A questo punto, se tutto è andato per il verso giusto, eseguiamo un port scanning sulla nostra macchina (se non sapete come si fa leggetetvi qualche manuale su nmap) e dovremmo avere tutte le porte chiuse (sempre che l’abbiate fatto sull’indirizzo esterno della macchina.

Facciamo partire il server knockd con il solito

sudo /etc/knockd/start

e rifacendo la scansione notermo che nulla è cambiato. Tuttavia se da un altro computer eseguiamo il comando (anche qui dobbiamo avere un client knock installato):

knock 'indirizzoesternodellamacchina' 25 2000 4723

e proviamo a connetterci con il nostro bravo client OpenVPN…magia! Ci connetteremo senza problemi!
La cosa non finisce qui: quando avremo finito con la nostra connessione potremo richiudere la porta dietro le nostre spalle dando la bussata 4723 2000 25, e nessun’altro si connetterà alla nostra amata porta 1194.
Questo però potrebbe anche essere uno svantaggio per noi: se ci scordiamo la porta aperta, virtualmente lasciamo una via d’entrata (anche se protetta da chiave) a chiunque. La soluzione, come al solito, è nella pagina di manuale di knockd: è possibile infatti impostare un’”apertura temporizzata”, che dopo x secondi si richiude ma ormai noi saremo dentro e la regola

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

farà si che la nostra connessione rimanga attiva. La sintassi del nuovo file /etc/knockd.conf sarà allora:

[options]
 logfile = /var/log/knockd.log
[opencloseOPENVPN]
 sequence      = 25 2000 4723
 seq_timeout   = 15
 tcpflags      = syn
 start_command = /sbin/iptables -A INPUT -s %IP% -p udp --dport 1194 -j ACCEPT
 cmd_timeout   = 10
 stop_command  = /sbin/iptables -D INPUT -s %IP% -p udp --dport 1194 -j ACCEPT

In questo modo dopo 10 secondi la porta si chiuderà da se senza lasciare traccia di ciò che è successo, e senza doverci seccare con una sequenza in più da ricordare.

Per verificare, apriamo una shell in locale sul nostro server e digitiamo

sudo tail -f /var/log/knockd.log

che durante una bussata “regolare” ci mostrerà un output di questo tipo:

[2008-09-06 18:09] starting up, listening on eth0
[2008-09-07 00:23] 87.20.xxx.xxx: opencloseOPENVPN: Stage 1
[2008-09-07 00:23] 87.20.xxx.xxx: opencloseOPENVPN: Stage 2
[2008-09-07 00:23] 87.20.xxx.xxx: opencloseOPENVPN: Stage 3
[2008-09-07 00:23] 87.20.xxx.xxx: opencloseOPENVPN: OPEN SESAME
[2008-09-07 00:23] opencloseOPENVPN: running command: /sbin/iptables -A INPUT -s 87.20.xxx.xxx -p udp --dport 1194 -j ACCEPT

Il che vuol dire che l’indirizzo 87.20.xxx.xxx ha eseguito una bussata corretta e attivato la porta 1194 come volevamo.

Consiglio di aggiungere un’altra sezione con un’altra sequenza che non faccia altro che aprire la porta 22, così in caso di emergenza disporrete di un accesso sicuro per compiere tutte le vostre operazioni.

Un’altra paranoia potrebbe essere quella di un attaccante che sniffi il traffico diretto alla vostra macchina e scopra le porte che usate per la bussata. Anche in questo caso ci viene in aiuto la pagina di manuale di knockd che indica come costruire un file di sequenze che solo voi conoscerete. Ad ogni bussata la sequenza relativa viene cancellata e non potrà essere più riusata per accedere; questo ovviamente comporta che abbiate sempre con voi una copia del suddetto file e che di tanto in tanto lo rinnoviate, oppure trovate un algoritmo per generare sequenze a partire da fenomeni conoscibili a priori, come ad esempio le estrazioni del lotto…:-)

Sono sicuro di aver commesso parecchi errori durante la stesura di questo post, quindi se qualcuno decidesse di povare a seguire queste indicazioni, è pregato di dirmi se qualcosa non funzionasse, e io provvederò ad aiutarlo e a correggere per i futuri lettori.

OpenVPN su Hardy Heron (Ubuntu 8.04)

Volendo creare una VPN che mi permettesse di connettermi dall’ufficio a casa, ho provato varie alternative, tutte egualmente utili per certi versi. PPTP ad esempio è buona per connettersi con client Windows, ma non garantisce praticamente nulla in sicurezza ed è molto scomoda da gestire via Linux (server o client). Dopo altre peregrinazioni sono giunto alla ben (almeno da me) conosciuta OpenVPN che qualche tempo fa non mi ispirò tanta fiducia a causa dell’assenza di un client già integrato in Windows.

Per farla breve, ho riscoperto questo meraviglioso server, ho trovato che alla fine l’installazione del client su Windows non è così complessa (l’unica cosa che mi secca sono i privilegi di amministratore che devi avere, ma a quanto pare si può porre rimedio anche a quelli). Ho così installato il server sulla mia Hardy Heron e vado a trascrivervi come al solito i passaggi salienti per la configurazione.

Prima di tutto si deve installare il pacchetto OpenVPN:

sudo aptitude install openvpn

Poi si creano manualmente due directory che serviranno più in la a contenere files importanti (sempre perchè sono preciso e ordinato):

sudo mkdir /etc/openvpn/configs && sudo mkdir /etc/openvpn/keys

A questo punto bisogna creare il file /etc/openvpn/server.conf che stabilisce i parametri più importanti che il server avrà. Ovviamente dovete modificare alcuni parametri: io ho cambiato la porta per ragioni personali, anche se in questo file lascio quella assegnata da IANA al protocollo, ovvero la 1194.  Modificate anche la riga server e le due seguenti perchè corrspondano alla vostra classe di IP della LAN privata e alla relativa maschera di sottorete (se non sapete di cosa parlo non vi dovrebbe neanche servire una VPN).

port 1194 
local 192.168.2.50 
proto udp 
dev tun0 
ca keys/ca.crt 
cert keys/server.crt 
key keys/server.key 
dh keys/dh1024.pem 
server 192.168.100.0 255.255.255.0 
push "route 192.168.0.0 255.255.0.0" 
push "redirect-gateway def1" 
push "dhcp-option DNS 192.168.100.1" 
client-to-client 
keepalive 10 600 
cipher AES-128-CBC 
comp-lzo 
user nobody 
group nogroup 
persist-key 
persist-tun 
status /var/log/openvpn-status.log 
log openvpn 
verb 3 
mute 20

La riga local deve corrispondere all’indirizzo IP interno del vostro server (nel mio caso 2.50), il server OpenVPN visto dai client avrà indirizzo 192.168.100.1 e il range di IP assegnabili sarà 192.168.100.0/24.

Ora bisogna editare con il vostro Emacs preferito il file /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars, andando a cambiare alla fine del file i valori e mettendone alcuni che corrispondano alla nostra localizzazione geografice, ecc…
Consiglio di lasciare gli altri valori così come sono se non volete ritrovarvi a passare la notte a fare troubleshooting.

A questo punto conviene diventare root e lanciare nella directory precedente (/usr/share/doc/openvpn/examples/easy-rsa/2.0/) i seguenti comandi:

source ./vars
./clean-all
./build-ca
./build-key-server server
./build-key --pass vostronick
./build-dh

E’ ovvio che dovrete sostituire a vostronick un nome che poi verrà usato per la connessione. L’ho anche messo in corsivo…
Consiglio anche qui di lasciare tutte le impostazioni di default eccetto che per il Common Name che va impostato come vostronick…
Spostiamoci nella cartella keys e lanciamo un bel

cp ca.key ca.crt dh1024.pem server.key server.crt /etc/openvpn/keys
cp vostronick.crt vostronick.key ca.crt /etc/openvpn/configs/

Tiriamo un sospiro e andiamo avanti (mi sto stancando molto a scrivere questa guida).
Ora bisogna creare il file di configurazione (/etc/openvpn/vostronick.conf)  che andrà utilizzato sul/sui client; come per il server le impostazioni sono molte e il contenuto può variare per voi. Vi incollo il mio leggermente modificato. Cambiate ciò che vi sembra opportuno:

client
 proto udp
 dev tun
 remote vostroindirizzoip 1194
 persist-key
 persist-tun
 ca ca.crt
 cert vostronick.crt
 key vostronick.key
 cipher AES-128-CBC
 comp-lzo
 verb 3
 mute 20

Per quanto riguarda l’indirizzo IP che dovrà essere ovviamente statico, consiglio servizi come No-IP e simili.

adesso diamo i permessi di lettura al file vostronick.key e copiamolo (via scp, USB o altri mezzi sicuri) sul client con il file .conf e il .crt, oltre al file ca.crt ovviamente.

Andiamo ancora in /etc/openvpn e lanciamo il comando:

openvpn --genkey --secret ta.key

che genererà la chiave del server.

Siamo quasi alla fine, ricordiamoci di aprire sul nostro router la porta 1194 UDP, di abilitare l’IP forwardingo con

echo 1 > /proc/sys/net/ipv4/ip_forward

e facciamo partire il servizio con un bel

sudo /etc/init.d/openvpn start

Ora se tutto va bene vi potrete connettere alla vostra VPN casalinga installando un appropriato client sul vostro PC (io uso kvpnc anche su Gnome e questo su Windows) importando certificato, chiave e file di configurazione (tutto nella stessa directory).

Come al solito se qualcosa non dovesse andare, commentate e vedrò di rispondervi. Se lo chiederete inoltre, potrò ampliare il post spiegando come associare il servizio di VPN ad un meccanismo di sicurezza di tipo port-knocking per far si che il vostro server sia completamente invisibile dall’esterno.

Installare VMWare Workstation 6.0.3 su Ubuntu Hardy Heron

Semplice semplice, se si installano tutti i pacchetti, e in particolare g++:

Scaricare dal sito ufficiale VMWare Workstation 6.0.3 per Linux, archivio .tar.gz, non rpm. Al momento è disponibile la build 80004

Scompattare l’archivio e entrare nella cartella, lanciare da root (o con sudo) vmware-install.pl

Finita l’installazione, se tutto è andato per il verso giusto, dovrebbe dare degli errori con vmmon, durante la configurazione. E’ normale. Scaricate da qui la patch (la famosa any-any-update).

Scompattate anche questa e eseguite lo script (da root) chiamato runme.pl. Dopo tutte le compilazioni (ignorate warning vari), tutto dovrebbe essere pronto.

Come visualizzare i log di Honeyd senza impazzire

Continuiamo la rassegna su Honeyd, al massimo rimarrà negli archivi…

Dato che sono alcuni giorni che Honeyd gira e “cattura” dati, ho cominciato a cercare uno strumento per visualizzare i log che produce senza dover imparare tutti i codici a memoria.

Gira che ti rigira, ho deciso di dare uno sguardo a honeydsum, un semplice script in perl che volendo genera dei log HTML decisamente passabili. Il problema è che ha bisogno di una bella quantità di moduli (lo so, il Perl è così…) e anche loro non scherzano con le pretese.

Ora, se ricostruisco un attimo la mia history vi dovrei dire cosa ho fatto.

Come prima cosa ovviamente scaricate e installate:

honeyd-common da aptitude,
libgd2-xpm-dev sempre da aptitude o con apt-get,
Honeydsum da qui.

I moduli Perl da scaricare e installare sono:

GD (2.39)
GD Graph (1.44)
GD TextUtil (0.86)
GD Graph3d (0.63)
Net Netmask (1.9015)

I nomi ovviamente non sono “corretti” e qualche purista del Perl potrà storcere il naso davanti alla mia pessima grafia, ma basta una Ricerca su CPAN con quello che ho scritto per trovarli. Vi ricordo che la procedura di installazione per un modulo Perl è la seguente:

1. Scompattare il .tar.gz che contiene i files
2. Entrare nella cartella appena creata e lanciare
   perl Makefile.PL
3. se non ci sono errori lanciare make && make test && make install

Se tutto è andato bene, potrete lanciare il nostro bel programmino per la visualizzazione dei log ad esempio con questa sintassi:

./honeydsum.pl -c honeydsum.conf -w /var/log/honeyd/honeylog.log

Che vuol dire: usa il file di configurazione honeydsum.conf -che si deve trovare nella stessa cartella-, genera una pagina in formato HTML (-w) del log che si trova in /var/log/honeyd/honeylog.log.
A questo punto aprite la cartella e magicamente troverete una selva di immagini e pagine web. Aprite index.hml fiduciosi con il vostro browser preferito e ammirate i vostri log.

Mo mi metto a studiare il file di configurazione perchè vorrei cambiare alcune cose…