E’ necessario da prima installare i seguenti pacchetti:

• bluez

Necessario per instaurare la connessione bluetooth seriale con il cellulare.

• wvdial

Per effettuare la connessione vera e propria

Per prima cosa bisogna effettuare il pairing tra i due dispositivi, la procedura da seguire la potrete trovare sul link [2] in fondo alla pagina.

Configurazione

Ora configuriamo la connessione seriale, con il comando hcitool scan cerchiamo il MAC del nostro cellulare e segniamocelo:

Scanning ...
        00:01:02:03:04:05       Nss

Ora cerchiamo il canale su cui è in ascolto il servizio di Dialup con il comando:

sdptool browse 00:01:02:03:04:05

E nell’output cerchiamo la seguente porzione e segniamoci il valore del parametro “Channel”, nel mio caso 3.

...
Service Name: Dialup Networking
Service RecHandle: 0x10002
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
...

Editiamo il file /etc/bluetooth/rfcomm.conf e inseriamoci, sostituendo i parametri visti in precedenza, le seguenti righe:

rfcomm0 {
        bind yes;
        device 00:01:02:03:04:05;
        channel 3;
}

Nel file /etc/wvdial.conf creiamo invece la seguente sezione:

[Dialer tre]
Modem = /dev/rfcomm0
Baud = 115200
Init1 = ATH
Init2 = ATE1
Init3 = AT+CGDCONT=1,"IP","tre.it","",0,0
Dial Command = ATDT
Phone = *99#
Username = tre
Password = tre
Ask Password = 0
Stupid Mode = 1
Idle Seconds = 0
Auto DNS = 1
Check Def Route = 1

Connessione

Per effettuare il collegamento seriale lanciamo da shell il comando che creerà il device /dev/rfcomm0:

rfcomm bind 0

La connessione invece andrà effettuata invece con il comando:

wvdial tre

[1] http://archlinux.it
[2] https://wiki.archlinux.org/index.php/Bluetooth#Pairing

• Automatic full mesh routing

Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.

• Easily expand your VPN

When you want to add nodes to your VPN, all you have to do is add an extra configuration file, there is no need to start new daemons or create and configure new devices or network interfaces.

• Ability to bridge ethernet segments

You can link multiple ethernet segments together to work like a single segment, allowing you to run applications and games that normally only work on a LAN over the Internet.

Verranno mostrati i passi essenziali da seguire…

• Abbiamo 2 computer PCA e PCB
1. PCA con direttamente raggiungibile e con ip pubblico x.y.z.t
2. PCB dietro nat quindi non direttamente raggiungibile

entrambi i pc hanno installata la distribuzione ArchLinux.

• Su entrambi i PC:
1. Installiamo i pacchetti necessari

pacman -S openssh zlib lzo
yaourt -S tinc

2. Definiamo la variabile $VPNNAME assegnandole il nome che vogliamo dare alla vostra VPN

VPNNAME=mia_vpn

3. Creiamo i file e le directory necessarie

mkdir -p /etc/tinc/$VPNNAME/hosts
mkdir -p /usr/var/run/
touch /etc/tinc/$VPNNAME/tinc.conf
touch /etc/tinc/$VPNNAME/tinc-down
touch /etc/tinc/$VPNNAME/tinc-up
chmod +x /etc/tinc/$VPNNAME/tinc-up
chmod +x /etc/tinc/$VPNNAME/tinc-down

• Ora spostiamoci su PCA (quello con ip pubblico x.y.z.t)

ATTENZIONE: sostituire a $PCxHOSTNAME l’hostname della macchina, a $INTERNETIF l’interfaccia con la quale la macchina esce su internet e a $VPNNAME il nome della vpn usato precedentemente (VPNNAME=mia_vpn)

1. Inseriamo le seguenti righe nel file /etc/tinc/$VPNNAME/tinc.conf

Name = $PCAHOSTNAME
AddressFamily = ipv4
BindToInterface = $INTERNETIF
Device = /dev/net/tun
PrivateKeyFile=/etc/tinc/$VPNNAME/rsa_key.priv

2. Creiamo il file /etc/tinc/$VPNNAME/hosts/$PCAHOSTNAME e all’interno mettiamo:
   l’ip 10.0.10.1 è stato preso a caso dalla classe 10.x.x.x, potrete cambiarlo a vostro piacimento

Address = x.y.z.t
Subnet = 10.0.10.1/32

3. Aggiungiamo al file /etc/tinc/$VPNNAME/tinc-up

#!/bin/bash
ifconfig $VPNNAME 10.0.10.1 netmask 255.255.0.0 up

4. Mentre nel file /etc/tinc/$VPNNAME/tinc-down mettiamo

#!/bin/bash
ifconfig $VPNNAME down

5. Lanciamo il comando per generare la chiave per criptare la comunicazione e diamo invio alle successive richieste

tincd -K -n $VPNNAME

• Possiamo finalmente passare a PCB, i passi saranno uguali se non per alcuni dettagli
1. Configuriamo il portforwarding del router in modo da mandare tutte le richieste delle porte 655 TCP/UDP su PCB
2. Inseriamo le seguenti righe nel file /etc/tinc/$VPNNAME/tinc.conf

Rispetto alla configurazione di PCA abbiamo aggiunto le righe 5 e 6.

1 2 3 4 5 6 7

Name = $PCBHOSTNAME AddressFamily = ipv4 BindToInterface = $INTERNETIF Device = /dev/net/tun ConnectTo = $PCAHOSTNAME TCPOnly = yes PrivateKeyFile=/etc/tinc/$VPNNAME/rsa_key.priv

3. Creiamo il file /etc/tinc/$VPNNAME/hosts/$PCBHOSTNAME e inseriamoci:

l’ip 10.0.10.2 è stato preso a caso dalla classe 10.x.x.x, potrete cambiarlo a vostro piacimento

Subnet = 10.0.10.2/32

4. Aggiungiamo al file /etc/tinc/$VPNNAME/tinc-up

#!/bin/bash
ifconfig $VPNNAME 10.0.10.2 netmask 255.255.0.0 up

5. Mentre nel file /etc/tinc/$VPNNAME/tinc-down mettiamo

#!/bin/bash
ifconfig $VPNNAME down

6. Lanciamo il comando per generare la chiave per criptare la comunicazione e diamo invio alle successive richieste

tincd -K -n $VPNNAME

La procedura è quasi terminata, dovremmo solo copiare i file

• /etc/tinc/$VPNNAME/hosts/$PCAHOSTNAME sulla stessa directory in PCB
• /etc/tinc/$VPNNAME/hosts/$PCBHOSTNAME sulla stessa directory in PCA

In questo momento dovremmo avere nella directory etc/tinc/$VPNNAME/ di entrambe le macchine i seguenti file

./tinc.conf
./tinc-up
./rsa_key.priv
./tinc-down
./hosts
./hosts/$PCAHOSTNAME
./hosts/$PCBHOSTNAME

Se tutto è stato configurato in maniera corretta, basterà dare il seguente comando su entrambi i pc

tincd -n $VPNNAME

e per verificare l’effettivo funzionamento

• Da PCA proviamo:

ping 10.0.10.2

• Da PCB proviamo:

ping 10.0.10.1

In caso di problemi è possibile lanciare tinc in modalità debug per analizzare al meglio eventuali errori

tincd -D -d5 -n $VPNNAME

[1] http://it.wikipedia.org/wiki/Virtual_Private_Network
[2] http://www.tinc-vpn.org/

Per navigare attualmente con un indirizzo IPv6 (alcuni siti/servizi sono già disponibili con questo protocollo) vi è la necessità che qualcuno ce ne fornisca uno.

Perché crearsi un tunnel IPv6?
La mia è stata semplice curiosità…

Per creare il tunnel abbiamo bisogno di un Tunnel broker [2], personalmente ho usato HURRICANE ELECTRIC [3] e di seguito vi illustrerò la serie di passi necessari per crearsi un proprio tunnel IPv6.

Iniziamo la procedura…

Per usufruire del servizio è necessario registrarsi alla pagina http://tunnelbroker.net/register.php.
Una volta effettuato il login alla pagina, sulla destra si avrà a disposizione un pannello con le funzioni utente da cui andrà selezionata la voce Create Regular Tunnel.

Verrà chiesto, a questo punto, di inserire un “IPv4 endpoint”, l’indirizzo IPv4 della vostra parte del tunnel…

• Se avete un indirizzo IPv4 fisso potete inserirlo tranquillamente nella casella
• Se invece il vostro indirizzo non è fisso ma varia di volta in volta dovrete usare uno script per aggiornare l’indirizzo di volta in volta come indicato qui [4](nel prossimo post mostrerò lo script)

Se la macchina da collegare via IPv6 è quella su cui stiamo lavorando, basterà inserire come “IPv4 endpoint” il valore che si trova in “You are viewing from IP” e premendo il tasto Submit verremo rimandati alla pagina con i dettagli del tunnel appena creato…

Qui, in fondo alla pagina sarà presente un menù con la scritta Example IPv6 Tunnel Configurations by OS (Windows, Linux, etc.), dal quale è possibile ricavare i comandi per una corretta configurazione del tunnel.

Config Examples

Nel caso di linux ci verranno mostrate le righe da copiare e incollare nella nostra shell per abilitare il tunnel…
Fatto questo basterà verificarne il funzionamento attraverso il comando

ping6 ipv6.google.com

[1] http://it.wikipedia.org/wiki/IPv6
[2] http://en.wikipedia.org/wiki/Tunnel_broker
[3] http://he.net/
[4] https://tunnelbroker.net/ipv4_end.php

L’evento si svolgerà il 18 settembre a Perugia, avremmo a disposizione una scuola (da condividere naturalmente) con tanto di sala conferenze, sarebbe una buona occasione per incontrarci e magari organizzare un workshop in quella giornata.

Vi comunico la cosa perché non sarei comunque in grado di organizzare da solo e quindi mi farebbe comodo l’aiuto di qualcuno.
Senza contare che sarebbe bello se qualcuno preparasse qualche talk o se venissero proposti nuovi progetti per migliorare la nostra già ottima distribuzione…

Insomma rimango in attesa di vostre proposte e spero che questa opportunità per incontrarci venga colta da molti.

Saluti, Luca

cgit is an attempt to create a fast web interface for the git scm, using a builtin cache to decrease server io-pressure.

Questa interfaccia è basata su: un “semplice” script cgi scritto in c, un file di configurazione /etc/cgitrc, un foglio di stile css e un logo.

Per installare cgit su Archlinux basterà il comando:

yaourt -S cgit

che oltre a installare il man e a creare alcune cartelle utili, fornirà i seguenti file

/etc/cgitrc
/srv/http/cgit/cgit.cgi
/srv/http/cgit/cgit.css
/srv/http/cgit/cgit.png

Nella configurazione di Apache di Archlinux, esiste un alias che specifica che all’url /cgi-bin/ corrisponde il percorso fisico /srv/http/cgi-bin dobbiamo quindi creare la directory in questione e copiarci all’interno il file cgit.cgi:

mkdir /srv/http/cgi-bin
cp /srv/http/cgit/cgit.cgi /srv/http/cgi-bin/

diciamo quindi al software dove trovare il logo e il foglio di stile modificando nel file di configurazione “/etc/cgitrc“ le variabili css e logo come segue:

css=/cgit/cgit.css
logo=/cgit/cgit.png

in fondo allo stesso file trovate le righe di esempio per configurare i repository da monitorare,

repo.url=saetta
repo.path=/tmp/saetta.git
repo.desc=the master foo repository
repo.owner=fooman@foobar.com
repo.readme=info/web/about.html

Inseriamo quindi un alias nel file /etc/httpd/conf/httpd.conf che richiami lo script cgit.cgi quando visitiamo l’indirizzo “http://dominio-git/git“:

ScriptAlias /git "/srv/http/cgi-bin/cgit.cgi"

e riavviamo il server apache.

Per vedere il risultato visitate http://vostrodominio/git e dovreste trovarvi un’interfaccia simile a quella del progetto stesso [1] :D

[1] http://hjemli.net/git/cgit/tree/README

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Spesso per fare ciò mi affido a qualche servizio esterno ma avendo a disposizione un server personale mi sono chiesto perché non sfruttarlo anche a questo scopo.

Cercando ho trovato gittosis [2],

gitosis aims to make hosting git repos easier and safer. It manages multiple repositories under one user account, using SSH keys to identify users. End users do not need shell accounts on the server, they will talk to one shared account that will not let them run arbitrary commands.

Ho distillato qui i passi per la configurazione prendendo spunto da questa guida [3].

Per chi ha (IMO) la fortuna di usare Archlinux, per installare il software basterà lanciare sul server il semplice comando:

yaourt -S gitosis-git gitosis-scripts

In questo modo verranno installati il software con alcuni script aggiuntivi e inoltre verrà creato un utente “git” ed un gruppo omonimo.
Per le altre distribuzioni sarà necessario installare il software e creare utente e gruppo a mano (l’utente deve avere una shell e una home ma non una password).

A questo punto una volta installato il software passiamo alla configurazione; sul vostro Client (il computer da cui sviluppate) create le chiavi ssh per il vostro utente con il comando:

ssh-keygen -t rsa

e copiate il file ~/.ssh/id_rsa.pub, creato da quel comando, sul server.

Dal server tramite l’utente “git” (basterà diventare root e usare il comando su git, oppure usare sudo) lanceremo il comando:

gitosis-init < /tmp/id_rsa.pub

Questo comando creerà le directory “gitosis” e “repositories” nella home dell’utente “git” e aggiungerà la chiave pubblica del client tra quelle autorizzate.

Per una maggiore sicurezza è anche consigliato settare i permessi di esecuzione al file “post-update” con il comando:

chmod 755 /srv/gitosis/repositories/gitosis-admin.git/hooks/post-update

basterà ora lanciare sul client il comando:

git clone git@YOUR_SERVER_HOSTNAME:gitosis-admin.git

e dovreste trovarvi la directory "gitosis-admin" sincronizzata in locale.

Probabilmente "tradurrò" anche il resto della guida appena ho tempo, per ora mi fermo qui.

Saluti, Nss

[1] http://git-scm.com/
[2] http://www.ohloh.net/p/gitosis
[3] http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Assumiamo qui che tutti i file all’interno della home appartengano all’utente proprietario della home e che sui due sistemi esistano gli stessi gruppi.

Chiameremo PC_A il pc da sostituire e PC_B il nuovo sistema, inoltre abbiamo utente che rappresenta appunto l’utente da migrare e IP_A e IP_B gli ip dei due sistemi.
Naturalmente supponiamo che i due pc siano sulla stessa rete.

Creiamo ora su PC_B l’utente che vogliamo esportare:

adduser utente

ed avviamo il servizio sshd sul PC_B:

/etc/rc.d/sshd start

Siamo ora pronti per esportare l’utente da PC_A a PC_B.
Per questo scopo ho usato rsync [1] per la sua capacità di minimizzare il trasferimento di dati trasferendo solo i cambiamenti (se non dovessi riuscire a copiare tutto in una volta).
Il comando da me usato è il seguente:

rsync -vrogpa --progress -e ssh --delete /home/utente/ utente@IP_B:

Questo copia tutti i file presenti nella dir /home/utente/ attraverso ssh sul PC_B preservando proprietario gruppo e permessi e fornendoci i dati sul trasferimento.

Attenzione:l’opzione --delete elimina dalla destinazione i dati che non sono presenti nella sorgente.

Fatto…
[1] http://it.wikipedia.org/wiki/Rsync

http://tinyurl.com/yg5r82z
consigliato firefox per aprire questo link in quanto “migliore” nel gestire i file svg

Non vuole essere un lavoro professionale ma solo un semplice schema per dare l’idea dei dati che andrò ad inserire nel database e il tipo di relazioni tra essi.
Tutto ciò con la prospettiva di creare un “motore di ricerca” on line con cui effettuare ricerche sulle informazioni dei pacchetti…

Se qualcuno ha idee su come migliorare tale schema può lasciare un commento di seguito e ne parliamo… potremmo anche creare una sezione apposita nel forum.

I sorgenti in formato .dia sono qui [1]

Grazie a tutti.

[1] http://tinyurl.com/yhvcrqr

E’ proprio arrivato il momento di mettere in guardia le persone… se fino a “ieri” era semplice penetrare una rete wireless protetta da una chiave WEP o da una WPA, oggi se vedete una nonnina al volante sotto casa vostra con un notebook appoggiato sul sedile accanto PREOCCUPATEVI…

Almeno questo è quanto sostengono i creatori di questo software [1], che hanno tra l’altro documentato l’attacco portato dalla nonna, con delle simpatiche foto della signora prima e dopo l’attacco…

Io personalmente non l’ho provato… ma se qualcuno avesse Tempo/Voglia di testarlo mi farebbe piacere se poi mi dicesse come funziona effettivamente.

PS: qualcuno ha già provveduto a pacchettizzarlo per Archlinux [2]…

[1] http://www.backtrack.it/~emgent/hackstuff/old_gerix_wifi_cracker_ng/index.html
[2] http://aur.archlinux.org/packages.php?ID=28769

Auditing

Facendo il pendolare mi capita spesso di comprare riviste da leggere durante il viaggio in treno, proprio oggi ne ho comprata una, che non compro frequentemente, e ho trovato un “interessante articolo” sul software Lynis [1].

Questo software permette di fare un analisi automatica sulla sicurezza del sistema.

Le distro supportate sono:
Arch Linux, CentOS, Debian, Fedora Core 4 (and higher), FreeBSD, Gentoo, Knoppix, Mac OS X, Mandriva 2007, OpenBSD 4.x, OpenSolaris, OpenSuSE, PcBSD, PCLinuxOS, Red Hat, RHEL 5.x, Slackware 12.1, Solaris 10, Ubuntu

Possiamo trovare il software per Archlinux su AUR (anche se al momento in cui scrivo il PKGBUILD fa riferimento ad una versione non troppo aggiornata) e dopo averli installato, possiamo lanciare il test con un semplice:

lynis -c

Ci verrà fornita la possibilità di effettuare un insieme di test divisi per categoria e alla fine verrà ricapitolato il risultato dell’analisi e verranno mostrati eventuali suggerimenti su migliorare la sicurezza del sistema.

[1] http://www.rootkit.nl/projects/lynis.html