Grazie ad una wave con Ely ho scoperto Conky. Un monitor di sistema per linux il quale, configurato opportunamente, si sovrappone allo sfondo del desktop mostrando informazioni relative CPU, memoria, spazio disco, temperature, traffico di rete e molto altro.
Mi sono appassionato alla configurazione di questo tool e nelle varie peripezie affrontate sono riuscito a portare in conky gli eventi creati con Google Calendar in maniera efficiente. Riportero’ di seguito la procedura che ho effettuato ed uno script creato di getto.

Il primo passo è consistito nel trovare un modo per ottenere i dati di Google Calendar da linea di comando, per questo è stato d’aiuto il programma gcalcli che pur risentendo di qualche difetto si è comunque prestato all’impresa. L’ho quindi scaricato e copiato nel path di sistema:

wget http://gcalcli.googlecode.com/files/gcalcli-1.4.tgz
tar -xvf gcalcli-1.4.tgz
sudo mv gcalcli /bin

Conky può essere configurato per mostare l’output di alcuni comandi di sistema. Specificando i comandi direttamente nel file di configurazione si otterra che ogni volta che conky aggiorna il suo stato (lasso di tempo dell’ordine del secondo) tali programmi saranno riavviati. Interrogare la rete ogni secondo non era nelle mie intenzioni ho quindi creato uno script per lanciare conky costruendo il file di configurazione in modo dinamico:

#!/bin/bash
cd; # get home directory
today=`date +"%m/%d/%Y"` # current date
nextmonth=`date --date "now 30 days" +"%m/%d/%Y"` # current date + 30 days
# get the conky configuration code for the calendar
echo -e "\${font Purisa}\${color red}Google Calendar \${hr}\$color\$font \n\${font Purisa:size=10}`gcalcli --nc --user $1 --pw $2 agenda $today $nextmonth | sed '/^$/d'` \$font \n\${color red}\${hr}\$color" > caltemp
# build a conky configuration file
cp .conkyrc_base .conkyrc
cat caltemp >> .conkyrc
rm caltemp
# launch conky
sleep 10
conky &
exit

La variabile today conterrà la data corrente mentre nextmonth è la data corrente più trenta giorni, avremo quindi sul desktop gli eventi in agenta dal giorno in corso fino al mese successivo. In base ai valori di tali date viene lanciato gcalcli ed il risultato viene innestato in codice di configurazione conky per il quale si rimanda all’apposita documentazione. Il codice generato viene copiato in coda ad un file con la configurazione di base. Facendo partire conky con questo script Google Calendar sarà interrrogato una sola volta durante il suo ciclo di vita.

Per far partire conky all’avvio è necessario copiare il file con la configurazione di base, scaricabile da qui, nella propia home e posizionare lo script appena visto al path (di norma /bin). Poi bisogna aggiungere lo script alla lista dei programmi di avvio di gnome andando in System -> Preferences -> Startup Applications clickando su Add, compariranno le finestre mostrate in figura, e nel campo Command immettere conky_gcal , naturalmente le credenziali devono essere quelle dell’account Google dove si ha il calendario da monitorare.
Chi non volesse modificare il proprio file di configurazione conky può semplicemente usarlo come file di configurazione di base posizionandosi nella propria home e rinominandolo come segue:

mv .conkyrc .conkyrc_base

In questo modo gli eventi Google Calendar saranno mostrati sotti i dati solitamente monitorati.

Anche se ogni macchinadi internet ha uno o più indizizzi IP, questi non possono essere usati per inviare pacchetti perchè l’hardware che opera a livello datalink non è a conoscenza degli indirizzi IP.
Ogni scheda Ethernet ha associato un indirizzo a 48 bit chiamato MAC address. Le schede comunicano tra loro utilizzando tale indirizzo.
L’associazione tra IP e MAC Address avviene al momento della comunicazione tra glio host. Quando l’host A ha bisogno di inviare un pacchetto all’host B controlla se l’IP di B è nella sua stessa sottorete e se è cosi’ invia un messaggio in broadcast a tutta la sottorete per chiedere il MAC di B. A tale richiesta risponderà solo B. Il protocollo per effettuare tale comunicazioni è chiamato ARP.
Per utilizzare ARP in modo efficiente vengono attuate delle ottimizzazioni. Una volta ottenuto l’indirizzo di un host esso viene salvato in una cache, in questo modo non sarà effettuata nessuna richiesta ARP alla comunicazione con tale host.Ogni macchina invia in Broadcast la propria associazoine una volta collegata alla rete, in questo modo ogni host avrà in cache l’indirizzo della macchina appena collegata.
Purtroppo le associazioni non sono valide per sempre, ciò comporta che i valori nelle chache scadono e nuove domande ARP dovranno essere effettuate.

Il protocollo ARP non è progettato per ambienti ostili e manca di un meccaniscmo di autenticazione. Tale mancanza consente di effettare un’attacco chiamato ARP Poisoning, con il quale è possibile intercettare pacchetti destinati ad altri host.
Si immagini una reto con due host, uno in possesso dell’attaccante ed l’altro in possosesso della vittima, ed un nodo che funge da gateway. L’attaccante può inviare alla vittima una ARP reply fabbricata con l’associazione (IP.Gateway, Mac:Attaccante) ed un’altra al gateway con l’associazione (IP.Vittima, Mac:Attaccante). Dopo aver ricevuto tali pacchetti la vittima ed il gateway aggiorneranno le proprie cache con gli indirizzi forniti dall’attaccante che riceverà sia i pacchetti inviati che quelli ricevuti dalla vittima. Inoltre per non farsi scoprire potrà reinoltrare i pacchetti senza bloccare la comunicazzione.

Il tipo di attacco descritto è implementato nel software ettercap. Vediamo come intercettare il traffico tra l’host 192.168.1.10 e l’host 192.168.1.254 con questo programma:


# ettercap -T -M ARP /192.168.1.10/ /192.168.1.254/
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Listening on eth0... (Ethernet)
eth0 -> MALLORY:MAC:ADDR 192.168.1.100 255.255.255.0
...
Scanning for merged targets (2 hosts)...
* |==================================================>| 100.00 %
2 hosts added to the hosts list...
ARP poisoning victims:
GROUP 1 : 192.168.1.10 VICTIM:MAC:ADDR
GROUP 2 : 192.168.1.254 GATEWAY:MAC:ADDR
Starting Unified sniffing...


Con l’opzione -T si dice al programma di usare la console come interfaccia con l’utente e con -M si indica di reinoltrare i pacchetti intercettati.
Utilizzando Whireshark durante l’operazione di ARP poisoning possiamo osservare il seguente traffico ARP:


Source Destination Type Description
RealtekS Broadcast ARP Who has 192.168.1.10? Tell 192.168.1.100
RealtekS Broadcast ARP Who has 192.168.1.254? Tell 192.168.1.100
BillionE RealtekS ARP 192.168.1.254 is at GATEWAY:MAC:ADDR
Nokia_80 RealtekS ARP 192.168.1.10 is at VICTIM:MAC:ADDR
RealtekS Nokia_80 ARP 192.168.1.254 is at MALLORY:MAC:ADDR
RealtekS BillionE ARP 192.168.1.10 is at MALLORY:MAC:ADDR


Prolog è un linguaggio per il calcolo simbolico dove la necesita di eseguire calcoli aritmetici è esigua. In questa lezione vedremo come gestire le operazione aritmetiche.
I principali operatori aritmetici di Prolog sono:

• +, addizione
• -, sottrazione
• *, moltiplicazione
• /, divisione
• mod, resto della divisione

L’uso di tali operatori non è diretto. Infatti scrivendo

?- X = 1 + 2.

Prolog risponderà “X = 1 + 2″ e non “X = 3″ come qualcuno potrebe aspettarsi. Ciò avviene perchè la stringa “1 + 2″ in prolog coincide con un termine dove + è il funtore ed 1 e 2 i suoi argomenti. Per eseguire l’operazione aritmetica c’è bisogno di usare l’operatore speciale is come segue:
Read the rest of this entry »

Le liste sono strutture dati tanto semplici quanto usate. In questa lezione vedremo come usarle in Prolog. Una lista è una sequenza di elementi e, come visto anche nella lezione precedente, può essere scritta in Prolog utilizzando il funtore ‘.’ oppure usando la notazione con parentesi quadre. Quest’ultima è la notazione più comoda e sarà l’unica ad essere trattata in questa lezione. Una lista può essere scritta nel seguente modo:

[item1, item2, item3, item4]

Read the rest of this entry »