OpenVpn: installazione e configurazione in modalità bridge

Quest’articolo, per fruibilità, l’ho diviso nelle seguenti parti:

L’intera guida è orientata verso un S.O. Debian e Debian-like.
Ho impiegato tre giorni per scrivere questa guida, il motivo per cui l’ho scritta e che in internet si trovano tantissime guide sull’argomento, ma nessuna specifica che spiega per bene come integrare il servizio openvpn, configurato come bridge, con il demone dhcp.
Inoltre molte guide sono obsolete o con informazioni alle volte contraddittorie, per cui spero che possa essere utile a qualcuno. 🙂

Installiamo dei pacchetti necessari

sudo su
apt-get install openvpn bridge-utils

Creare i certificati usando il tool easy-rsa

Eseguite una copia dei file del tool easy-rsa:

mkdir /etc/openvpn/easy-rsa/
cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/

Settiamo il tool modificando il file vars:

nano /etc/openvpn/easy-rsa/vars

Modificare i campi:

export KEY_COUNTRY=""		# il vostro STATO
export KEY_PROVINCE=""		# la vostra PROVINCIA
export KEY_CITY=""		# la vostra città
export KEY_ORG=""		# la vostra organizzazione
export KEY_EMAIL=""		# il vostro indirizzo di posta elettronica
export KEY_SIZE=2048		# Diffie-Hellman
export KEY_NAME="server"        # X509 Subject Field

Certificati del Server

cd /etc/openvpn/easy-rsa/
source vars
./clean-all			# Cancella tutti i certificati e le chiavi presenti nella cartella /etc/openvpn/easy-rsa/keys
./build-ca			# Crea il certificato di ROOT della Certification Authority
./build-key-server server	# Crea il certificato e la chiave privata del server

Cambiate “server” con il nome che ritenete più opportuno.
All’esecuzione dell’ultimo comando vi verrà chiesto di inserire una password.
1. Inserite una password sicura e accertatevi di non perderla.
2. Alla richiesta di firmare il certificato rispondete di si.
3. Alla richiesta di eseguire il commit rispondete si.

Creiamo i parametri DIFFIE-HELLMAN necessari per il server per la connessione SSL/TSL

./build-dh

Tutti i certificati e le chiavi sono stati generati nella sottocartella “/etc/openvpn/vars/keys”
Se volete attivare il protocollo TSL dovete generare la key corrispondente:

openvpn --genkey --secret keys/ta.key

Wiki: http://it.wikipedia.org/wiki/Transport_Layer_Security

Mettiamo i file creati nella cartella del programma:

cp server.crt server.key ca.crt dh2048.pem ta.key /etc/openvpn/

Certificati del Client

sudo su
cd /etc/openvpn/vars
source vars
./build-key nome_del_pc_client

I certificati e le chiavi del client vengono sempre creati nella cartella “/etc/openvpn/easy-rsa/keys”

Il file che il client ha bisogno per effettuare la connessione con il server sono:

ca.crt				# Certificato di Root della CA
nome_del_pc_client.crt		# Certificato del client
nome_del_pc_client.key		# Chiave privata del client
ta.key				# TSL key

Copiate questi file all’interno della cartella /etc/openvpn/ del client.

Configurazione del server

tun (routing) o tap (bridging) ?

Il device TAP è una scheda di rete virtuale, mentre il dispositivo TUN è un collegamento IP virtuale da punto a punto (point-to-point).

Vantaggi e svantaggi: http://openvpn.net/index.php/open-source/faq/community-software-general/309-what-is-the-difference-between-bridging-and-routing.html

Se si utilizza bridging Ethernet (tap), è necessario utilizzare i parametri dev tap e server-bridge invece dei parametri dev tun e server.

Gli indirizzi utilizzati nella rete del server e nella rete locale del client non devono fare parte della stessa sottorete, altrimenti vi ritroverete con un loop nel routing dei pacchetti.

Es:

dev tap0
server-bridge

Altrimenti:

dev tun
server

L’istruzione server-bridge senza parametri, implica che il rilascio degli indirizzi ip per i client venga fornito dal demone dhcpd (isc-dhcp-server o dnsmasq) e non da openvpn.

Un motivo valido per cui si vuole usare dhcpd del proprio server piuttosto che openvpn e la possibilità che il proprio server abbia un dns (bind) installato e che il demone dhcp annunci i nuovi pc che si collegano alla rete al dns.

Questo aspetto è poco documentato e le informazioni al riguardo sono contraddittorie:

http://openvpn.net/index.php/open-source/faq/community-software-server/323-i-want-to-set-up-an-ethernet-bridge-on-the-1921681024-subnet-existing-dhcp.html

ATTENZIONE: La direttiva “server” con “dev tap” non deve essere usata come è suggerito dalla faq del sito openvpn, usate “server-bridge”:

  1. senza parametri se volete che sia il vostro server dhcp a rilasciare gli indirizzi
  2. con parametri opportunamente settati se volete che la gestione degli indirizzi ip sia lasciata al server openvpn.
    In questo caso c’è molta documentazione valida a riguardo.

Tuttavia è importante fare notare che il server dhcp non deve fornire ai client vpn il gateway di default della rete in cui è presente il server openvpn, pena la perdita di connessione da parte dei client remoti ad internet.

1. Creare un bridge su server

Configurazione di esempio della mia macchina (file: /etc/network/interfaces)

iface eth0 inet manual
iface eth1 inet manual
iface eth2 inet manual
iface eth3 inet manual
iface eth4 inet manual
iface wlan0 inet manual

auto br0
iface br0 inet static
	bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0
	address 172.16.0.10
	netmask 255.255.0.0
	network 172.16.0.0
	broadcast 172.16.255.255
	gateway 172.16.0.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 172.16.0.10 172.16.0.1 8.8.8.8
	dns-search example.org

Le istruzioni:

iface br0 inet static
	bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0

permettono la creazione di un bridge di rete di nome br0, con configurazione di rete statica, di cui fanno parte le periferiche fisiche:

eth0 eth1 eth2 eth3 eth4 wlan0

e la periferica virtuale

tap0

L’indirizzo di rete del bridge e le varie altre impostazioni vengono settate dalle istruzioni successive.

Una volta modificata la vostra configurazione di rete in relazione alle vostre esigenze potete riavviare il servizio di networking col comando:

sudo /etc/init.d/networking restart

2. Configurare il demone dhcpd, nel caso specifico “isc-dhcp-server”.

Questo è un cat parziale del mio file del mio file di configurazione /etc/dhcp/dhcpd.conf del mio server:

...

# Definizioni delle classi

class "local" {
	match pick-first-value (option dhcp-client-identifier, hardware);
}

class "ospiti" {
	match pick-first-value (option dhcp-client-identifier, hardware);
}

class "vpn" {	
	match if (substring(hardware, 1, 2) = 00:FF );
}

# MAC address delle macchine

subclass "ospiti" 1:00:01:AA:BB:CC:DD;
subclass "ospiti" 1:00:02:AA:BB:CC:DD;

subclass "local" 1:00:03:AA:BB:CC:DD;
subclass "local" 1:00:04:AA:BB:CC:DD;

# Definizione della subnet

subnet 172.16.0.0 netmask 255.255.0.0 {
    allow duplicates;
    default-lease-time 86400;
    max-lease-time 86400;				# 24h
    option domain-name "example.org";
    option subnet-mask 255.255.0.0;
    option broadcast-address 172.16.255.255;
    option domain-name-servers 172.16.0.10;
    option ntp-servers 172.16.0.10;

    # Local					172.16.0.50-89
    pool {
	allow members of "local";
	range 172.16.0.50 172.16.0.89;
	option routers 172.16.0.1;		# gateway della rete locale
	ddns-updates on;
    }

    # Ospiti					172.16.10.0/24
    pool {
        allow members of "ospiti";
       	range 172.16.10.1 172.16.10.254;
	default-lease-time 43200;
	max-lease-time 43200;			# 12h
	option routers 172.16.0.1;		# gateway della rete locale
	ddns-updates on;
    }

    # VPN					172.16.20.0/24
    pool {
	allow members of "vpn";
	range 172.16.20.1 172.16.20.254;
	ddns-updates on;
    }
}

Questa è la definizione del mio pool di indirizzi nel mio server.

Per la sottoclasse VPN l’opzione “option routers 172.16.0.10;” è mancante ne è presente nella definizione generale del range:

subnet 172.16.0.0 netmask 255.255.0.0 {
	...

Tanto basta per evitare che venga fornito ai client vpn un gateway che incasini l’instradamento di default dei client vpn verso internet.
Tuttavia è d’obbligo indicare l’opzione “option routers 172.16.0.10;” in tutti gli altri pool della subnet.

Per assicurarsi che tutti i client vpn finiscano nel pool corretto bisogna indicare come regola “allow members of “vpn”;” nel pool e creare una classe con questa regola qui:

class "vpn" {
        match if (substring(hardware, 1, 2) = 00:FF );
}

La regola funziona perché ogni client che si collega tramite openvpn avrà sempre come MAC address iniziale i valori: 00:FF
Tutti gli altri pool definiti nella subnet hanno regole differenti che non coincidono con la regola della classe vpn.

E’ importante accertarsi che nessuno dei client vpn possa finire in un pool di indirizzi in cui è definita la regola “option routers”, sopratutto se in quest’ultima regola è definito il gateway della rete del server vpn.

E’ possibile instradare tutto il traffico del client vpn verso la rete del server, ma in quel caso bisogna specificare come indirizzo ip quello del server vpn. Es:

option routers 172.16.0.10

Gli altri valori del MAC Address dei client vpn varieranno casualmente ad ogni connessione a meno che non si specificano esplicitamente tramite l’istruzione:

lladdr 00:ff:00:00:00:0d

per le macchine linux e nelle proprietà del device tap0 per le macchine windows.
Nelle macchine windows l’istruzione “lladdr 00:ff:00:00:00:0d” non è riconosciuta.

3. Configurazione del servizio OpenVpn

Nella cartella di configurazione del demone openvpn non sono presenti i file di configurazione per cui bisogna metterceli a mano:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gzip -d /etc/openvpn/server.conf.gz
rm /etc/openvpn/server.conf.gz

Una configurazione di esempio del file del server.conf è la seguente:

# Quale indirizzo ip dovrebbe rimanere in ascolto OpenVPN?
local 172.16.0.10		# Indirizzo ip del bridge br0

port 1194			# Porta
proto udp			# Protocollo

dev tap0
server-bridge

ca		ca.crt		# Certificato di Root della CA
cert		server.crt	# Certificato del Server
key		server.key	# Chiave privata del Server
dh		dh2048.pem	# Diffie Hellman parameters
tls-auth	ta.key 0	# This file is secret (0 = server)

comp-lzo			# algoritmo di compressione per la connessione
client-to-client
keepalive 10 120

user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log

daemon
verb 3
chroot jail

Anche qui ho omesso i commenti presenti nel file di configurazione di esempio.

Configurazione di un client

Il client ha anche lui bisogno del suo file di configurazione per cui, se non ne avete uno già pronto potete copiare quello di default:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/

Esempio di configurazione per un client linux.
E’ stata omessa la documentazione presente nel file di configurazione di esempio.

script-security 2

client
dev tap
proto tcp

remote vpn.example.org 1194	# Indirizzo del vostro server vpn

lladdr 00:ff:00:00:00:0d	# Indirizzo MAC del client

resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun

ca ca.crt			# Certificato radice della CA
cert client.crt			# certificato del client
key client.key			# chiave privata del client

ns-cert-type server

tls-auth ta.key 1		# File condiviso con il server (1 = client)
comp-lzo
verb 3

chroot

Per maggiorni informazioni in merito al chroot si può controllare questa pagina della wiki http://it.wikipedia.org/wiki/Chroot

mkdir /etc/openvpn/jail
nano /etc/openvpn/server.conf

Alla fine del file aggiungere l’istruzione:

chroot jail

e salvare.

chroot jail e syslog

Il problema è semplice, alla rotazione giornaliera dei log del sistema il servizio rsyslog viene riavviato dalla macchina facendo perdere la connessione alla socket “/dev/log” da parte del servizio openvpn.
Infatti la socket AF_UNIX “/dev/log” viene terminata e ricreata al riavvio del servizio rsyslog.
Il servizio openvnp, essendo bloccato dentro la cartella “/etc/openvpn/jail” non può più accedere alla socket del demone rsyslog che si torva fuori dalla cartella “jail” (ovvero “/dev/log”).

Per ovviare al problema bisogna creare la cartella dev dentro jail:

mkdir /etc/openvpn/jail/dev

e modificare la configurazione del demone rsyslog creando un nuovo file dentro la cartella “/etc/rsyslog.d” e aggiungere lì la configurazione del nuovo socket per il demone openvpn. Ovvero:

nano /etc/rsyslog.d/openvpn.conf

E aggiungere la seguente istruzione:

$AddUnixListenSocket /etc/openvpn/jail/dev/log

e salvare e riavviare il servizio.

service rsyslog restart

Streaming Evento Ferus Trapani (25-01-2013)

A 30 anni dall’assassinio del magistrato Giangiacomo Ciaccio Montalto, il 25 Gennaio 2013 alle ore 17:00 il Palazzo di Giustizia di Trapani apre le porte alla cittadinanza per affidare un messaggio di speranza alla voce ed al sentire della cultura, dell’arte e dell’impegno civile, nella convinzione che il bello, il giusto ed il buono della nostra terra sconfiggeranno la violenza, la sopraffazione e la devianza criminale che hanno insanguinato ed avvilito la Sicilia dei nostri anni. L’evento Ferus ha già riscosso una grande partecipazione popolare al Palazzo di Giustizia di Catania lo scorso 23 maggio, per il ventennale dalle stragi di Capaci e di Via D’Amelio, trasformando il tribunale in luogo ideale per l’espressione.

In collaborazione con:

Evento Ferus
Associazione Culturale 50mtAssociazione Nazionale Magistrati

Network Flow using Sankey Diagram

Qualche mese fa ho sviluppato un plugin, scritto in python, per la visualizzazione dei flussi di rete, per il programma nTop di Luca Deri. Il plugin è presente di default nella versione 5.0 di ntop.

Il diagramma “Sankey” è uno specifico diagramma di flusso, nel quale viene mostrata la larghezza delle frecce in proporzione alla quantità di flusso. Generalmente sono utilizzati per visualizzare le quantità di energia o materiali o costi tra i processi.
In questo programma, Network Flows, il diagramma di flusso Sankey viene utilizzato per mostrare le quantità di dati (flussi di rete), espressi in bytes, transitati tra uno o più host.

Network Flow using Sankey Diagram 1

Si può facilmente notare che in questo primo diagramma non si evidenziano le informazioni dei protocolli presenti nei flussi. Si è scelto di proposito di dare, in primo luogo, una visione d’insieme dei flussi maggiori della rete, lasciando, tuttavia, la possibilità di cliccare su un particolare flusso per aumentare il livello di dettaglio dei dati ed, eventualmente, di filtrarli selezionando solo i protocolli voluti.
In questo primo diagramma tutti i flussi di rete tra due host sono accorpati, le uniche informazioni mostrate sul flusso sono la sua direzione e dimensione.

Il programma Network Flows nella sua versione dimostrativa, liberamente scaricabile in licenza gpl, acquisisce le informazioni da visualizzare da un file, dove ogni riga è definita come:

host sorgente | host destinazione | bytes in | bytes out | proto layer 4| proto layer 7

Questo file viene elaborato dallo script python sankey.py che produrrà un output in formato json. I dati sono organizzati in:

  • una lista di nodi, dove ogni nodo è definito da un nome rappresentante l’indirizzo ip dell’host, altrimenti dal suo nome risolto, seguita da
  • una lista di archi, dove per ogni arco è definito il suo nodo di origine, il suo nodo di destinazione, il suo peso e la sua direzione;
  • meta informazioni, che definiscono:
    • il numero massimo di host che si è scelto di visualizzare nel diagramma;
    • l’ordine di misura del peso di un arco;
    • i protocolli layer 4 e layer 7 presenti nei flussi dati;
    • i sottoinsiemi dei predetti protocolli che si è scelto di visualizzare nel diagramma;
    • più alcune variabili di stato.

Lo script sankey.py computa i dati letti da file creando, per ogni nuova tupla di indirizzi degli host sorgente/destinazione, un nuovo elemento nell’hashmap archi, se la tupla è già presente i dati verranno sommati a quelli esistenti.

Per ogni chiave (sorgente/destinazione) vengono memorizzate più informazioni:

  • la somma dei byte in ingresso e in uscita; dato che poi verrà usato per rappresentare il peso di quell’arco, sia per ordinare i flussi in ordine decrescente;
  • i byte in ingresso;
  • i byte in uscita;
  • un hashmap rappresentante i protocolli layer 4, la cui chiave è il nome del protocollo del livello di trasporto, che, a sua volta, memorizzerà:
    • la somma dei byte in ingresso e uscita per quel protocollo;
    • un’ultima hashmap, rappresentante i protocolli layer 7, le cui chiavi sono in nomi dei protocolli del livello applicativo, che, a sua volta, memorizzerà:
      • la somma dei byte in ingresso e in uscita;
      • i byte in ingresso;
      • I byte in uscita per ogni protocollo layer 7.

La ragione di questo gioco di matriosche è di poter dare all’utente, una volta valutata la visione d’insieme dei flussi di rete, la possibilità di avere delle informazioni più dettagliate su un paticolare flusso, tra due specifici host, cliccandovi sopra.

Il diagramma di flusso sankey ha dunque due visualizzazioni.
La prima, nella quale ogni host è definito come un rettangolo a cui viene associato un nome e un colore che lo identificano. In questa visualizzazione ogni rettangolo avrà almeno due archi uno uscente e l’altro entrante (almeno di non trovarci nel caso limite di un flusso in un’unica direzione one-way flow), in cui l’arco dello stesso colore rappresenterà sempre i dati in uscita per quel nodo e l’arco di colore diverso rappresenterà il flusso di dati in ingresso avente come origine il suo host di destinazione.

Nella seconda modalità di visualizzazione si potranno vedere uno o più archi, dove ogni arco rappresenta il protocollo applicativo, mentre, il colore non identifica più la direzione del flusso bensì il protocollo layer 7. I rettangoli al centro del diagramma identificano, invece, i protocolli del livello di trasporto.

Network Flow using Sankey Diagram 2

È comunque sempre possibile selezionare un sottoinsieme di protocolli o definire un numero massimo di nodi da visualizzare al fine di raffinare la rappresentazione dei dati nel diagramma di flusso in base alle esigenze dell’utente.

Il compito di visualizzare i dati, una volta che lo script sankey.py ha finito di elaborarli, è lasciato alla libreria grafica d3.js, la quale produrrà un grafico in formato svg.

É opportuno far notare che il codice che disegna il grafo di flusso sankey, quando è stato scritto il programma Network Flow, non era presente nella libreria d3, poiché era ancora in fase di sviluppo. Lo sviluppatore della libreria, Mike Bostock, prevede in futuro un possibile miglioramento dell’algoritmo al fine di minimizzare la sovrapposizione dei collegamenti o per supportare grafi ciclici come i cicli al primo hop o connessioni di loopback.

In merito agli archi di ritorno, per ovviare al problema ho scelto di confrontare, come stringhe, per ogni arco la sua sorgente e la sua destinazione. Se la sorgente è maggiore della destinazione la computazione dei dati rimane invariata, altrimenti, viene eseguito il complementare dei dati, invertendo la tupla sorgente/destinazione e viene eseguita la somma dei dati in ingresso alla variabile che conta i dati in uscita e viceversa.

Per chi ha installato python 3 di default, è d’obbligo modificare la prima riga del file: sankey.py da

#!/usr/bin/env python

a

#!/usr/bin/env python2

Grazie nignux per la segnalazione :-).

Per avviare il programma bisogna dare il comando

python webserver.py

mentre per visualizzare il diagramma basta andare alla pagina

http://localhost:8090/

Codice sorgente in licenza gpl v3.

l’incaprettato

Il 23 maggio, a partire dalle 17:58 fino alle 24:00 andrà in streaming la performance “l’incaprettato” di Alessandro Librio, in occasione del ventesimo anniversario della morte di Giovanni Falcone.
Sarà presente all’interno del Palazzo di Giustizia di Catania, oltre alla performance “l’incaprettato”, l’installazione sonora “FINE”, realizzata dallo stesso artista, entrambe commissionate dall’Associazione Nazionale Magistrati.

TCP Socket (af_inet)(IPv4/IPv6)(with ssl) – c language

This program is an example of programming a TCP socket in C language, using the well-known client-server programming model.
The server side is multi-threaded, but the thread is optional since the developer/designer is still responsible for deciding if he/she needs it.

The library “commv6.c” develops all the functions to create, bind, listen, and remove a socket AF_INET, and the functions to send and receive messages (using the methods read and write). It supports: IPv4/IPv6 and SSL (see commSSL.c).
The structure of a message is defined in the file “msg.h”.

Code tested under debian-like and arch linux platform (thanks to nignux).


Questo programma è un esempio di programmazione di un socket TCP in linguaggio C, utilizzando il ben noto paradigma di programmazione client-server.
Il lato server è multi-threaded, ma è del tutto opzionale, e sarà responsabilità dello sviluppatore decidere se ne ha bisogno.

La libreria “commv6.c” sviluppa tutte le funzioni per creare, pubblicare, rimanere in ascolto e rimuovere una  socket af_inet, e le funzioni per inviare e ricevere messaggi (usando i metodi read e write). Il codice supporta socket ipv4/ipv6 e SSL (commSSL.c)
La struttura di un messaggio è definita nel file “msg.h”.

Codice testato sotto piattaforma debian-like e arch linux (ringraziamenti a nignux).


Be careful when you do a read(/write) on a socket: the machine at the other end of the socket is of your own platform (x86/x64)?
Fate attenzione quando fate una read(/write) su una socket: la macchina dall’altro capo della socket è della vostra stessa piattaforma (x86/x64)?
x86 x64
sizeof(char)  1  1
sizeof(short)  2  2
sizeof(float)  4  4
sizeof(int)  4  4
sizeof(unsigned int)  4  4
sizeof(long)  4  8
sizeof(double)  8  8
sizeof(long unsigned int)  4  8
sizeof(long double) 12 16
sizeof(long int)  4  8

x64

Linux 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

x32

Linux 2.6.18-6-k7 #1 SMP Thu Aug 20 22:36:26 UTC 2009 i686 GNU/Linux

Si consiglia di utilizzare:

sys/types.h

dove vengono dichiarati i tipi:

int8_t
u_int8_t
int16_t
u_int16_t
int32_t
u_int32_t
int64_t
u_int64_t

Tiscali Netbox G/N (Alcatel Thomson TG784)

If you are not paying for it, you’re not the customer; you’re the product being sold. —
Andrew Lewis MetaFilter, 26 Agosto 2010
Richard Stallman, hackmeeting Firenze, 26 Giugno 2011

Alcatel Thomson tg784g (Tiscali Netbox g)La politica di ogni provider adsl che si rispetti è di lasciare fuori i propri clienti dall’amministrazione del router. Va da se che questo modo di fare cozza, completamente, con i miei ideali. Ovvero, io ho acquistato il modem, dunque, penso di avere il diritto di gestirlo come amministratore.

Parliamo di cose serie, se siete tra i fortunati possessori del router Alcatel Thomson tg784g/n che viene dato (comodato d’uso o venduto) dalla Tiscali, per chi stipula un contratto voce, allora avete un serio problema di sicurezza sulla vostra rete locale.

Questi pazzi hanno lasciato l’accesso telnet attivo e aperto verso internet, inoltre, le credenziali di accesso come amministratore sono note. In termini pratici un lamer potrebbe entrare nel vostro router, copiarne la configurazione e/o modificarla a suo vantaggio. Ovvero, chiunque può amministrare il vostro router senza che voi ve ne accorgete, esponendo la vostra rete locale ad attacchi di tipo man in the middle o al furto delle vostre credenziali di accesso alla rete adsl e voip.

Bene, mettiamoci ai ripari. Il mio suggerimento è di creare un nuovo account sul router con i privilegi di amministratore e di rimuovere l’account di default.

Consiglio: prima di continuare accedete all’interfaccia amministrativa web del vostro router, con le credenziali di accesso di amministratore, e salvatene la configurazione (File: user.ini)

Cambiate l’indirizzo ip del vostro pc con 192.168.1.34 e collegatevi all’interfaccia telnet del vostro router:

telnet 192.168.1.254 8081

Attenzione, da rete locale il router risponderà all’interfaccia telnet solo se il pc che chiede l’accesso ha l’indirizzo 192.168.1.34. Il motivo è una regola impostata nel firewall del router (estratto da user.ini):

Thomson TG 784 H:

rule add chain=sink_system_service index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Thomson TG 784 N:

rule add chain=sink_fire index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Loggatevi con le credenziali di accesso di root e date i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user add name = <nome> password = <password> role = root
user list
saveall
exit

sostituite:

  • <nome> col nome del vostro nuovo utente amministratore (consiglio: evitate nomi come  admin, administrator, root e simili) e
  • <password> con la password da voi preferita (consiglio: metteteci una password forte).

Attenzione, alcune volte il router si pianta durante la procedura di saveall. Non allarmatevi se, per più di un minuto, la console telnet non risponde, riavviate il modem usando il pulsante di accensione. Generalmente il router riesce a salvare le impostazioni anche quando si pianta.
Loggatevi nuovamente con le credenziali del nuovo utente che avete creato ed eseguite i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user list
user delete name = <nome>

Sostituite <nome> con il nome dell’utente root standard del router.
Se cancellate anche l’utente della tiscali avrete eliminato la possibilità da parte dell’assistenza remota di entrare nel vostro router: a voi la scelta.

E, giacché ci siamo, abilitiamo il client ntp del router:

sntp add name=it.pool.ntp.org version=3
sntp config poll=60 pollpresync=5
sntp config state=enabled

inoltre, dato che la tiscali censura i dns, aggiungiamone due statici con priorità superiore a i dns della tiscali stessa:

dns server route add dns=208.67.222.222 metric=1 intf=Internet
dns server route add dns=208.67.220.220 metric=1 intf=Internet
dns server route list

I dns che vedete nell’esempio precedente sono di opendns, se non vi piacciono cambiateli con quelli che più preferite. Nel mio caso ho inserito come dns il server di casa mia considerato che ho bind 🙂
Ebbene si! In Italia esiste la censura… (lol) provate a collegarvi al sito www[dot]thepiratebay[dot]org oppure www[dot]btjunkie[dot]org, prima e dopo aver cambiato i dns.
T1scal1 censura, al momento, solo i dns, Alice e altri provider eseguono una censura a livello di pacchetto, quindi, anche cambiando i dns non vi collegherete, comunque, ai siti internet censurati. (ricordate tor è vostro amico)

Aggiornamento del 25/07. Sono spiacente di informare la censura di t1scal1 si è allineata agli altri provider adsl, censurando a livello di pacchetto e non più di solo dns…

Modifichiamo la regola del firewall per il servizio telnet del router, al fine di rendere accessibile telnet da qualsiasi pc della rete locale.
Creiamo una nuova espressione che identificherà il range degli indirizzi della nostra lan:

expr add name=personal type=ip addr=192.168.1.0/24 mask=0

Poi modifichiamo la regola (che vi avevo mostrato prima) per il telnet:

regola da usare per il modello Thomson TG 784 H:

firewall rule modify chain=sink_system_service index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

regola da usare per il modello Thomson TG 784 N:

firewall rule modify chain=sink_fire index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

Il comando “srcintf=lan” (letteralmente source interface expression) indica che la regola è valida solo per la rete locale lan. Se volete creare una regola per le connessioni internet dovete usare la parola “wan“.

Non dimenticatevi di salvare tutto prima di uscire:

saveall
exit

Per maggiori informazioni sulla command line interface di questo router eseguite la ricerca “thomson tg784 cli” su g00gle e scaricate il pdf.

Ad ogni modo, eseguendo la procedura di reset fisico del router, sarà possibile riportare il router alle impostazioni standard della adsl Tiscali.

Abilitazione accesso FTP e HTTP da remoto
(Aggiornamento del 10-10-2011)

Non ho mai usato l’ftp del router… tuttavia sembra che a qualcuno faccia comodo 🙂

service system ifadd name=FTP group=wan
saveall

Regola testata e NON funzionante o almeno sembra che non basti per fare funzionare l’ftp da remoto.

Analogamente per l’interfaccia web di amministrazione del modem..
(sconsiglio caldamente di abilitarla, ma a volte si sa può servire…)

service system ifadd name=HTTP group=wan
saveall

[Regola testata e funzionante]

Rimozione accesso Telnet da remoto (FTP e HTTP)

Una volta per tutte, togliamo questa falla alla sicurezza del router…
Attenzione, potrete sempre accedere al router tramite telnet dalla vostra rete locale di casa vostra, ma non più da internet.

service system ifdelete name=TELNET group=wan
saveall

Regola per rimuovere l’accesso FTP da remoto ..

service system ifdelete name=FTP group=wan
saveall

Regola per rimuovere l’accesso remoto all’interfaccia web di amministrazione del modem.. (l’accesso remoto non è attivo come impostazione di default del modem, almeno di vostre modifiche)

service system ifdelete name=HTTP group=wan
saveall

Insomma, avrete capito che service system ifadd aggiunge e service system ifdelete rimuove, mentre se volte avere una lista dei servizi del router…

service system list

Purtroppo,  quella lista non ci dice nulla su quale lato (internet o lan) del router sono attivi, bisogna andare a spulciarsi il file user.ini.

Aprire le porte sul router…

Aprire le porte su questo router non è esattamente immediato.
E’ facile notare che se si utilizza una regola per servizio già presente sul router la porta viene aperta correttamente.
Potete constatare voi stessi che se si assegna un ad un pc il servizio ssh o qualsiasi altro servizio preimpostato sul router la porta risulta essere effettivamente raggiungibile dall’esterno. Ben altra cosa accade con le regole definite manualmente dall’utente.

Ho visto che ci sono alcuni navigatori che suggeriscono di disabilitare l’intrusion detection. Non è il caso. Vi faccio una metafora: è come se il vostro elettricista di fiducia per fare passare il cavo dell’antenna dal muro anziché fare un buco col trapano, ve l’ho butta giù con il martello pneumatico. Beh sicuramente il filo ci passa, ma non era esattamente quello che volevamo no?

La soluzione esiste:

  • Fissate in modo statico gli indirizzi ip dei pc di casa vostra su cui volete assegnare dei servizi (Home > Home Network > Devices > …)
  • Create tutte le regole che vi servono (Home > Toolbox > Game & Application Sharing > New Game or Application).
  • Assegnate le regole alle vostre macchine
  • Salvate il vostro file user.ini (Home > Thomson Gateway > Configuration > Backup & Restore) sul desktop e apritelo con wordpad/gedit
  • Cercate la sezione “[ service.ini ]” Es:
[ service.ini ]
add name="AIM Talk" mode=client
...
add name=test
add name=VNC mode=server
add name="Xbox Live" mode=server
...
...

Per sinteticità ho tagliato le regole presenti nel router.
La regola che ho creato per queste esempio si chiama test. La regola in questione non ha il parametro mode, per il modem è equivalente a scrivere mode=client. Risultato porta chiusa dall’esterno. Aggiungete mode=server ad ogni vostra regola creata:

add name=test mode=server

Salvate il file, ridatelo in pasto al modem e avete finito. Solo un ultimo consiglio: NON usate la porta 8080 per le vostre regole, pena la perdita dell’accesso all’interfaccia web del router.
(anche se disabilitato, sulla 8080 del router è presente il servizio di parental control)
In generale se volete avere la lista di quali porte NON si devono usare sul router perché sono in uso dallo stesso modem. Dall’interfaccia telnet date:

service system list

Aprire le porte sul router tramite telnet

Un altro metodo, che vi evita di modificare a mano il file user.ini è il seguente:

Si crea un nuovo “nome di regola”. Es:

service host add name=my_torrent mode=server

Se per caso nel vostro nome di regola sono presenti degli spazi, allora:

service host add name="my torrent" mode=server

bisogna inserire i doppi apici.
Successivamente si devono creare le vere regole per questo nuovo “nome di regola”. Es:

per il solo protocollo TCP:

service host rule add name=my_torrent protocol=tcp portrange=9020-9020

per il solo protocollo UDP:

service host rule add name=my_torrent protocol=udp portrange=9020-9020

per entrambi i protocolli:

service host rule add name=my_torrent protocol=any portrange=9020-9020

Qui, abbiamo aperto la porta 9020 del router. Si possono aggiungere molte regole ad ogni nome di regola, anche per più porte e protocolli diversi, tuttavia ogni nome di regola può essere assegnato ad un solo pc alla volta. Ad ogni modo è da evitare categoricamente la creazione di nomi di regole che aprono le stesse porte con lo stesso protocollo.
(Qui serve solo del buon senso e un po di conoscenza del concetto di NAT)

Infine bisogna assegnare la regola al pc:

service host assign name=my_torrent host=192.168.1.69 log=disabled

Modificate l’indirizzo 192.168.1.69 con quello del vostro pc e ricordatevi di settare il suo indirizzo come statico nell’interfaccia del router. (Home > Home Network > Devices > …)

Per rimuovere l’assegnamento:

service host disable name=my_torrent

Altro esempio. Assegnamo l’SSH ad un pc di casa, (la regola è già esistente sul router):

service host assign name="Secure Shell Server (SSH)" host=192.168.1.66 log=enabled

Rimozione dell’assegnamento:

service host disable name="Secure Shell Server (SSH)"

E adesso, divertiamoci con un po’ di hacking…

Attenzione: Questa procedura è valida solo per il modello TG 784 H.
(Per chi non conosce le credenziali di accesso di default del router o, semplicemente, vuole sbirciare dentro il firmware di questo apparecchio.)
Prendetevi una penna usb, la più piccola che avete va bene. Se avete dei dati sul supporto usb che volete conservare salvateli perché con questa procedura la penna usb verrà formattata.

Procedura valida solo per il vecchio modello Thomson TG 784; il nuovo modello (TG784n) non riconosce il filesystem del pennino.

  • Scaricate il file: tg787-sysroot.sqsh.7z (filesystem che contiene un ln -s alla root)
  • Aprite una shell sotto linux (una distro live di ubuntu può fare al caso vostro se  non avete linux installato sul vostro pc)
  • se non l’avete già fatto, inserite la penna usb nel vostro pc ed eseguite il comando
  • $ mount, nella vostra shell e identificate qual’è il nome della vostra penna usb (nel mio caso /dev/sdb), ed eseguite il comando:
  • $ sudo dd if=/dev/zero of=/dev/sdb, che cancellerà ogni dato presente nella penna (più è grande il supporto più questa operazione sarà lunga),
  • andate nella path dove avete scaricato il file e una volta scompattato eseguite il comando:
  • $ sudo dd if=sysroot.sqsh of=/dev/sdb,
  • a operazione terminata staccate la penna usb e inseritela nella porta usb del router
  • Controllate, collegandovi all’interfaccia web del thomson, che in toolbox => content sharing sia attivo server enabled (upnp Av Media Server) (generalmente è già tutto attivato di default).
  • All’indirizzo \\192.168.1.253 o nelle condivisioni di rete (winzoz) troverete un pc chiamato thomson, al cui interno c’è condiviso il firmware del vostro router.
  • Aprite il file mlpuser.def che si trova in /sys/archive/xxxx/active/, per leggere le credenziali di default del vostro router.

thomson tg784g

Qualcuno ha detto TTL?

Thomson TG784g TTL JTAG

Sembra però che bisogna anche saldare due ponticelli dietro la board del modem per fare funzionare la ttl.
A questo link c’è spiegata la procedura per il modello tg782 (estremamente simile al tg784)
Appena ho un po di tempo farò alcune prove in merito.
Sarebbe molto carino riuscire a parlare direttamente con busybox piuttosto che con la command line interface (CLI) sviluppata da thomson.

Cambiare antenna

Procedura valida solo per il modello TG 784 H, sul quale NON è presente il wifi di tipo N.

Qui si può vedere il cavo “Mini PCI U.FL to RP-SMA Pigtail”

Link utili:

Installazione “Palermo a Venezia” di Alessandro Librio

Un giorno di traffico per Venezia.

Alessandro LibrioSegnalo l’evento speciale “Palermo a Venezia” dell’artista Alessandro Librio che avrà luogo il 4 Giugno, giornata di apertura della 54° edizione della Biennale di Venezia.

L’installazione si terrà al n. 63 di Piazza San Marco nel cortile del Palazzo Reale, sarà inoltre possibile seguire l’evento in diretta sul sito internet dello stesso artista: http://www.alessandrolibrio.com/node/173.

L’obbiettivo che l’installazione si propone è l’unione del paesaggio sonoro della città di Palermo con quello di Venezia, infatti per ventiquattro ore i suoni/rumori del traffico palermitano verranno acquisiti e riprodotti in tempo reale a Venezia.

Per informazioni più approfondite rimando all’intervista del sito SiciliaInformazioni:
http://www.siciliainformazioni.com/giornale/cultura/125290/suoni-palermo-invadono-venezia-linstallazione-librio-apre-biennale-darte.htm

Threads pool (posix) – c language (ver 2)

Example of generalized thread pool in C language with signal handling.

rev 2: Completely revised the code of the library.
Now there is a queue of jobs, a thread is awakened when a new job is available, following the classic mechanism of producer / consumer.

You can set: the thread pool size, its signal mask and the size of the job queue, calling the poolInit function that returns a new pool. If the signal mask is null then the signal mask shall be inherited from the creating thread.

The function poolDispatcher gets three arguments the pointer to the pool; a void pointer to function (start_routine), with a single argument void arg. (very similar to pthread_create). The poolDispather when executed creates a new job that is inserted into the queue of jobs.

If you send too many jobs to the pool and the queue fills up, the poolDispatcher reject the new job and returns the error code “-5” (to avoid DOS attacks).
The function poolDestroy, puts the pool in termination state, (the pool is no longer available to run new job), it waits for all active and pending jobs to finish; execute the join of the threads; free resources and exit.
doxygen docomuntation and source code (license GPLv2)

 

Esempio di pool di thread in linguaggio C generalizzato con gestione dei segnali.

E’ possibile passare a questa libreria un proprio puntatore a funzione.
La funzione verrà eseguita dal primo thread disponibile del pool di threads.

E’ facile notare come la funzione addjob esegue, nel caso in cui tutti i threads siano impegnati, attesa attiva.
La soluzione è presto detta, implementare una lista di jobs, oppure (per chi non ha voglia) aumentare opportunamente la dimensione del pool threads.

[update]
Rivisto completamente il codice della libreria.
Adesso esiste una lista di job; un thread del pool viene risvegliato quando un nuovo job è disponibile, seguendo il classico meccanismo di produttore/consumatore.

La dimensione massima della coda dei job è settabile in fase di creazione del pool.
Se si inviano troppi job al pool e la coda si riempie, la poolDispatcher rifiuterà il nuovo job ritornando il codice di errore “-5” (evitiamo attacchi di DOS).

La funzione poolDestroy, mette il pool in fase di terminazione, (ovvero il pool non è più disponibile ad eseguire nuovi job), aspetta che tutti i job attivi e pendenti terminino; esegue la join dei threads; libera le risorse ed esce.
[update-end]

Una volta terminato il job, il thread viene reso automaticamente disponibile per un nuovo job.
La dimensione del pool e la maschera dei segnali per i threads sono passate in fase di inizializzazione del pool stesso.

E’ possibile creare infiniti pool di threads, dato che ogni struttura dati viene creata dinamicamente in fase di inizializzazione del pool stesso. La maschera dei segnali è invece opzionale.

Per commenti e info più dettagliate sul codice: documentazione html (doxygen).

E per scaricare il codice sorgente: codice sorgente (in licenza gpl v2).

LaCie 2Big Network: supporto nfs

No, I will not fix your pc.
[Detto anonimo e largamente condiviso]

Aggiornamento / Update (05/02/2012):

Per il servizio nfsd in kernelspace, guardate i commenti di questo stesso articolo.
Suggerisco di usare il servizio nfsd in kernelspace, dato che supporta il lock dei file.

For nfsd kernel space, look at the comments of this article.
I recommend to use nfs kernel space since it supports file locking.

All thanks go to Bert.


Avevo tentato precedentemente di installare il supporto nfs sul mio vecchio (v1) nas 2Big Network della LaCie ma avevo desistito per la mancanza del modulo kernel nfsd, che permette di abilitare nfs server in kernelspace.

Di recente, dopo una richiesta di aiuto da parte di un navigatore, ho riaffrontato il problema trovando una soluzione: nsf in spazio utente. Ok storco il naso anche io per l’enormità di quello che ho appena detto..
Infatti ci sono grossi handicap per nfs userspace: lo sviluppo del codice è stato completamente abbandonato (l’ultima versione è la 0.9.22 e risale al 05/01/2009), ma il problema più grave che non vi è alcun supporto per il lock dei file.

Per installare il supporto per nfs v3 sul nas c’è bisogno dei demoni unfsd e portmap, il primo è nfs stesso il secondo è un servizio ONC RPC, in esecuzione su una macchina collegata in rete, che fornisce altri servizi ONC RPC (Remote Procedure Call). (Chi è abituato a programmare sa di che sto parlando)
Per farla breve il pacchetto unfs3 dipende dal pacchetto portmap. Ai fini pratici significa che è richiesto  l’installazione anche del servizio portmap per avere nfs funzionante.
Significa anche che ho dovuto scrivere due script per initng per avviare/arrestare correttamente i due demoni.

File portmap.i:

# NAME: portmap
# DESCRIPTION: DARPA port to RPC program number mapper
# WWW: 

# exec daemon = /sbin/portmap -d ${PORTMAP_OPTS};
daemon portmap {
	need = bootmisc virtual/net;
	provide = virtual/portmap;
	pid_file = /var/run/portmap.pid;
	forks;
	env PORTMAP_OPTS=;
	env_file = /etc/portmap.conf;
	exec daemon = /sbin/portmap;
}

File unfs3.i:

# NAME: unfs3
# DESCRIPTION: starts user-space NFSv3 server.
#	       UNFS3 is a user-space implementation of the NFSv3 server specification.
#	       It provides a daemon for the MOUNT and NFS protocols,
#	       which are used by NFS clients for accessing files on the server.
#	       Unlike nfs-user-server, unfs3 is capable of handling files larger than 2GB,
#              but there is currently no support for file locking.
# WWW:

daemon unfs3 {
	need = initial virtual/portmap virtual/net;
	env PID_FILE = /var/run/unfsd.pid;
	env_file = /etc/unfs3.conf;
	pid_file = ${PID_FILE};
	require_network;
	forks;
	exec daemon = /usr/sbin/unfsd -i ${PID_FILE} $DAEMON_OPTS;
	daemon_stops_badly;
}

Installazione di nfs3 server

Come premessa generale si presuppone che:

  • abbiate già effettuato l’hack del vostro nas (vedi articolo),
  • installato ssh e soprattutto con esso le librerie tcp-wrappers,
  • avete un account di root sul vostro nas (tutte operazioni documentate nell’articolo già citato)
  • e sopratutto, una buona padronanza della bash e dei sistemi linux.

Per installare nfs server dovete scaricare questi due archivi:

I pacchetti sono stati scaricati della distro debian lenny e sono compilati per armtel, da entrambi gli archivi ho eliminato i man page e i doc al fine di recuperare tutto lo spazio possibile.
Ho spostato il file di configurazione di portmap nella cartella /etc e l’ho rinominato in portmap.conf.
Il demone unfsd ha in file di configurazione proprio (da non confondere con il file /etc/exports) che ho rinominato in unfs3.conf e inserito anch’esso nella cartella /etc.
Queste modifiche erano dovute dato che l’architettura del nas differisce dall’architettura di un sistema operativo debian. Gli script per initng riflettono queste modifiche per cui se cambiate posto a quei file dovrete modificare di conseguenza gli script di avvio dei demoni.

Copiate l’archivio nella vostra cartella condivisa del nas.

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf portmap_6.0-9_armel.tar.gz -C /
# tar -xvzf unfs3_0.9.21_armel.tar.gz -C /
# rm portmap_6.0-9_armel.tar.gz
# rm unfs3_0.9.21_armel.tar.gz
# cd /etc/initng/runlevel/
# echo portmap >> default.runlevel
# echo unfs3 >> default.runlevel

Adesso dovete configurare il file exports che indica al demone nfs quali cartelle deve condividere nella vostra rete locale:

# vi /etc/exports

Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+“:wq” per salvare e uscire, “ESC”+“:q!” per forzare l’uscita dal file senza salvare le modifiche apportate.

La configurazione del file in questione la lascio alla vostra esperienza personale, se state installando nfs sul nas si presuppone che sappiate quello che state facendo. Vi informo tuttavia che questa versione di nfs (unfs3) non supporta nfs v4 ne nfs v2, inoltre non supporta nemmeno alcuni tag di configurazione come sync.

Non ho voluto implementare il supporto per nfs v2 perché assolutamente obsoleto, infatti un client nfs presuppone che, se non diversamente specificato, il protocollo, che deve usare per condividere in locale una cartella esportata da una macchina remota, sia nfs v3. Per finire nfs v2 non supporta file di dimensione superiore a i 2Gb.

Una volta configurato il file exports potete riavviare la macchina o se preferite avviare manualmente i demoni con i comandi:

# ngc -u portmap
# ngc -u unfs3

Per maggiori informazioni su ngc, digitate:

# ngc -h

E dire che questo nas non lo uso neanche più…

Aggiornamento.

Ho modificato nuovamente lo script unfs3.i inserendo la riga require_network a causa dell’avvio immediato del demone unfsd da parte di initng (prima ancora che l’interfaccia di rete lan fosse attiva). Il demone unfsd non pubblicava la socket sull’indirizzo di rete locale impedendo l’accesso da remoto.

La clausola require_network impone ad initng di attendere che l’interfaccia di rete della lan sia attiva prima di avviare il server unfsd: problema risolto.

Rsync

Script di avvio per rsync. (Il programma è già incluso nel nas)
File rsyncd.i:

#!/sbin/itype

# Short-Description: fast remote file copy program daemon
# Description: rsync is a program that allows files to be copied to and
# from remote machines in much the same way as rcp.
# This provides rsyncd daemon functionality.

daemon rsyncd {
       need = bootmisc virtual/net;
       require_network;
       env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
       env_file = ${RSYNC_CONFIG_FILE};
       exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
       daemon_stops_badly;
}

Per maggiori informazioni su rsync vedere nei commenti di questo stesso articolo.