Software utili su Ubuntu

26 04 2009

Quando installo una nuova macchina con Ubuntu (ma si può applicare anche ad altre distribuzioni), installo sempre questi software:

  • ssh (il server)
  • ubuntu-restricted-extras (ne avevo parlato un po’ di post fa, contiene JRE, Adobe Flash Player, Fonts vari, ecc…)
  • emacs22-nox (la versione con la GUI la trovo troppo pesante)
  • wine (per emulare molti dei programmi win32)
  • nmap (insostituibile scanner di rete)
  • filezilla (client FTP)
  • xchat (chat IRC)
  • emesene (client MSN Messenger)
  • gparted (editor di partizioni stile PartitionMagic, consigliato se non fosse già incluso nella vostra distribuzione)
  • gnome-do (lanciatore con moltissime funzioni e plugin non solo per gnome…)
  • thunderbird (non capisco perchè non sia già incluso in Ubuntu di default)
  • virtualbox-ose (versione open source del noto software di virtualizzazione, mancano un po’ di cose presenti invece nella versione PUEL)
  • network-manager-openvpn (per connettersi a vpn basate su OpenVPN tramite il network manager di Ubuntu)
  • soundconverter (converte file audio da e in vari formati)
  • xnest (fornisce le funzionalità per le connessioni remote tramite protocollo XDMCP)
  • serpentine (crea CD audio da mp3, ogg, ecc…)
  • kino (semplici montaggi video)
  • cheese (gestione della webcam e buffi effetti)

Questi software elencati sono disponibili nei repository APT di Ubuntu (dalla 8.04 in poi) così come sono scritti. Per installarli basta quinid lanciare un semplice

sudo apt-get install nomepacchetto

Altri software che uso frequentemente ma non sono disponibili nei repository ufficiali (nonostante siano quasi sempre reperibili sotto forma di pacchetti deb) sono:

Per installarli cliccate sui link e scaricate il pacchetto che più vi aggrada dal sito ufficiale.





Creazione di un media center casalingo

25 03 2009

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…





Un Ubuntu davvero portatile – seconda parte

19 03 2009

Man mano che faccio dei miglioramenti alla mia piccola macchina virtuale portatile, li scrivo qui in modo che altri possano beneficiarne.

Per prima cosa mi sono deciso ad installare X, e non volendo windows manager troppo pesanti, la scelta è caduta su FluxBox:

sudo apt-get install xorg fluxbox xdm

Dopo ciò mi sono veramente stancato dei miseri 128Mb di memoria che qemu di default assegna alle macchine virtuali, ed ho modificato gli script di avvio per far si che la ram virtuale assegnata alla macchina sia almeno di 512Mb (potete aumentarla o diminuirla a vostro piacere). Per quanto riguarda gli script per linux ecco la versione attuale:

#!/bin/sh
./bin/qemu -hda ./bin/ubuntu.img -L ./bin -m 256 -boot c

Mentre questa è la versione modificata del file .bat per Windows:

@ECHO OFF

SET SDL_VIDEODRIVER=windib
SET SDL_AUDIODRIVER=dsound
SET QEMU_AUDIO_DRV=dsound
.\bin\qemu.exe -hda .\bin\ubuntu.img -L .\bin -m 256 -boot c

A questo punto si può usare un po’ più agevolmente la nostra macchina virtuale…





Un Ubuntu davvero portatile

18 03 2009

C’è una grandissima comodità nel portarsi dietro una macchina virtuale: si ha il proprio sistema operativo preferito sempre a disposizione, ci si possono mettere i propri dati (non tutte le discografie, ovviamente) , non si lasciano tracce ad esempio, sul computer durante la navigazione, ecc…

Le soluzioni sono molteplici: si può ad esempio preparare una pennetta USB avviabile con su una DSL o una Ubuntu, (non si tratta di virtualizzazione ovviamente) ma occorre penare un po’ per rendere la partizione avviabile, formattarla e poi è difficile usarla per altri scopi o fare in modo che le modifiche siano persistenti, e non ultimo problema, ogni volta che si vuole utilizzare la macchina virtuale occorre riavviare il PC.

Un’altra soluzione può essere quella di usare software come Virtualbox, VMWare o altro, ma anche qui si pone un problema: cosa fare se sul sistema host (ovvero quello fisico) non c’è installato il relativo software di emulazione? Rischieremmo di portarci dietro un file di svariate centinaia di Mb senza poterlo utilizzare…

La soluzione è Qemu, reso “portatile” e una bella Ubuntu minimale. L’idea mi è venuta vedendo questo, e ovviamente alcuni dei files sono copiati da quella macchina virtuale.

Andiamo per steps:

  1. Installare qemu sulla propria macchina (una volta terminato il processo si può disinstallare senza problemi)
  2. Da terminale:
    • Creare una cartella sul proprio PC, entrare nella cartella appena creata e lanciare il seguente comando:
      qemu-img create ubuntu.img 1200M

      (ovviamente la dimensione fissa di 1.2 Gb è modificabile a piacere)

  3. Scaricare da questa pagina la versione di ubuntu che più ci aggrada. Io ad esempio ho scaricato la 8.10. Il download è di soli 9 Mb perchè non ci sono praticamente pacchetti: tutti i software infatti verranno installati scaricandoli da internet, il che vuol dire una granularità ed un aggiornamento dei pacchetti senza precedenti.
  4. Una volta scaricata l’immagine all’interno della cartella lanciamo questo comando da terminale:
    qemu -cdrom mini.iso -hda ubuntu.img -boot d
  5. Verrà quindi lanciata la macchina virtuale dall’immagine ISO scaricata che potremo installare sul nostro bell’HD virtuale secondo tutte le opzioni che preferiamo. L’importante è avviare l’installazione testuale scrivendo al prompt cli.
    Nel mio caso oltre alla lingua inglese e alla tastiera italiana, ho scelto i repository italiani per l’installazione dei pacchetti e ho completato l’installazione. Se si volesse uscire dalla macchina virtuale per tornare al sistema operativo host basta premere Ctrl+Alt, mentre per usare la modalità a tutto schermo premere Ctrl+Alt+F.
  6. Mentre si scaricano e installano i pacchetti scaricate questo eseguibile e scompattatelo in una sottocartella chiamata bin/
  7. In questa cartella /bin/) eseguite:
    cp /usr/bin/qemu .
  8. Una volta fatti tutti  gli aggiornamenti del caso, la vostra macchina nuova nuova con Ubuntu vorrà riavviarsi, ma riavviandosi ripartirà con il cdrom, che non è proprio quello che vogliamo…per farla partire come vogliamo quindi, la cosa migliore sarà fermare qemu (CTRL+C) e lanciare di nuovo al macchina da terminale con questo comando:
    qemu -hda ubuntu.img
  9. Completiamo la procedura di installazione facendo login sulla macchina e installando tutti i software che vogliamo.
  10. A questo punto dobbiamo creare gli script di avvio da Windows e Linux. Nella nostra cartella (non bin/, la superiore) creiamo un file ubuntu.sh con questo contenuto:

    #!/bin/sh
    ./bin/qemu -hda ./bin/ubuntu.img -L ./bin -boot c
  11. Diamo i permessi di esecuzione al file
    chmod a+x ubuntu.sh
  12. Creiamo anche un file ubuntu.bat con il seguente contenuto:
    @ECHO OFF
    
    SET SDL_VIDEODRIVER=windib
    SET SDL_AUDIODRIVER=dsound
    SET QEMU_AUDIO_DRV=dsound
    .binqemu.exe -hda .binubuntu.img -L .bin -boot c
  13. I più attenti avranno notato che i due file sono delle semplici copie con piccolissime modifiche di quelli trovati all’interno della macchina virtuale scaricata prima. Se siete così attenti potete anche andare avanti senza il mio aiuto…
  14. Spostiamo il file ubuntu.img all’interno della cartella bin/ e cancelliamo la iso mini.iso
  15. Vediamo un secondo quindi la struttura della nostra cartella…
    • ubuntu.sh
    • ubuntu.bat
    • bin/
    • bin/SDL.dll
    • bin/bios.bin
    • bin/casper.img
    • bin/fmod.dll
    • bin/ubuntu.img
    • bin/qemu
    • bin/qemu.exe
    • bin/pxe-ne2k_pci.bin
    • bin/pxe-pcnet.bin
    • bin/pxe-rtl8139.bin
    • bin/kqemu.exe
    • bin/qemu-img.exe
    • bin/libusb0.dll
    • bin/vgabios.bin
    • bin/vgabios-cirrus.bin
    • bin/keymap/…
  16. Possiamo copiare la cartella e il suo contenuto su una pennetta usb e avviare l’eseguibile corretto a seconda di essere su una macchina Windows o Linux, ed avere quindi al nostra bella macchina virtuale Ubuntu sempre a portata di mano…

Buon divertimento (e buona navigazione senza tracce) con la vostra nuova macchina virtuale!

Vi posto per completezza un paio di link utili e idee interessanti…fate voi…

http://www.nubuntu.org/

http://wiki.colar.net/creating_a_qemu_image_and_installing_debian_in_it

http://www.torproject.org/

https://www.torproject.org/torbutton/

http://www.metropipe.net/pvpm.php





Problemi con driver ATI e il nuovo X.org

11 01 2009

A quanto pare, l’aggiornamento di questi giorni di X per Intrepid Ibex è stato più travagliato del solito. Non funzionano bene ne i driver restricted per NVidia ne per ATI. Avendo una NVidia, sono passato comunque alla scheda video di AMD per aver sentito dire da alcuni che i driver disponibili per questi chipset erano open source.
Stronzate.
Comunque devo dire che la situazione è leggermente migliorata. Mentre con la NVidia GeForce 5200 la risoluzione massima dello schermo era 640×400 e i driver ufficiali facevano morire il tutto tra atroci spasimi, con il nuovo computer (eh si, ne ho approfittato per cambiare mobo, processore, e case) i driver ATI proprietari funzionano molto bene.
Unica pecca: non si può fare un login decente. A quanto pare da letture su vari forum e newsletter, i driver ATI hanno effetto su X ma GDM che dovrebbe andarsi a leggere la configurazione non lo fa, o meglio se la inventa, dandomi quindi una risoluzione altissima per il mio schermo, che ovviamente lo faceva andare in out of range e che mi costringeva quindi a fare il login “alla cieca”.
Dopo varie disinstallazione e reinstallazioni (sempre benedetta sia la partizione /home) ho deciso di disabilitare i driver proprietari, aspettare l’aggiornamento che corregga i bug di X.org e di modificare a mano il file /etc/X11/xorg.conf che incollo a perenne memoria:

Section "Device"
Identifier "Configured Video Device"
Option "UseFBDev" "true"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
SubSection "Display"
Depth 16
Modes "1280x1024" "1024x768"
EndSubSection
SubSection "Display"
Depth 24
Modes "1280x1024" "1024x768"
EndSubSection
EndSection





Port Knocking, OpenVPN e IPTables

7 09 2008

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.








Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.