A/I :: il remailer

Il remailer mixmaster: Il remailer mixmaster Next Previous Contents

2. Il remailer mixmaster

Installazione e configurazione di un remailer mixmaster

2.1 Preparazione all'installazione da sorgenti (versione 2.9.0)

Creare un nuovo utente e chiamatelo ad es. anon

# adduser anon

Verificare di avere installati sul proprio sistema sia GPG che PGP 2.6.3i per gestirsi chiavi DH e RSA.

Se utilizzate debian volendo esiste il pacchetto gia' compilato

Se invece volete compilarvelo come utente anon scaricare il file mixmaster-2.9.0.tar.gz dal sito http://www.sourceforge.net/projects/mixmaster nella home directory dell'utente anon (e scaricare anche la signature per verificare l'autenticita' del file) e decomprimere il pacchetto:

# tar xzvf mixmaster-2.9.0.tar.gz

# cd mixmaster-2.9.0

Eseguire il comando ./Install e rispondere alle domande con le scelte che trovate nel log di installazione che segue.
Tra parentesi tonda trovate dei commenti.

2.2 L'installazione vera e propria

Attenzione: molte distribuzioni linux hanno una versione di openssl senza il supporto per l'algoritmo idea. Questo impedisce al remailer di generare una chiave RSA.
In questo caso potete scaricare il file openssl-0.9.7.tar.gz dal sito http://www.openssl.org e copiare la directory openssl-0.9.7 contenuta nel pacchetto nella directory Src/ che e' una sottodirectory di mixmaster-2.9.0
In questo modo il supporto idea sara' inserito nel client del mixmaster anche se il vostro sistema non ha il supporto per idea.

# ./Install
  
 Mixmaster directory? [/home/anon/Mix]
 Do you want to set up a remailer? [y]
 Do you want to compile the passphrase into the binary? [n]
 Use the source if the pre-installed library causes compilation problems.
 Use source? [n]

 (Le domande che seguono sono parametri che andranno nel file mix.cfg 
 che potra' comunque essere modificato in seguito)

 Install as middleman? [n]
 (i remailer middleman accettano e inviano posta solo ad altri remailer;
 questa modalita' puo' essere utile ad es. nel caso in cui il remailer sia
 usato da qualcuno per fare spamming e l'operatore subisca pressioni per
 chiuderlo.)

 The e-mail address of your remailer:
 (inserite l'indirizzo del vostro remailer)

 Do you want Mixmaster to send auto-replies to messages it does not
 understand (If the address <anon@esempio.it> is also used
 for mail to be read by a human, type `n')? [y] 
 (se si attiva questa opzione il mixmaster rispondera' con un messaggio
 di spiegazioni alle e-mail che non interpreta come messaggi correttamente
 inviatigli nel formato mixmaster (altre spiegazioni piu' sotto)).

 An address to appear in the `From:' line of anonymous messages:
 (inserite l'indirizzo che deve comparire come mittente
 dei messaggi che transitano dal vostro remailer; di solito si usa nobody)

 Address for complaints to be sent to:
 (e' buona definire un indirizzo come abuse che sara' l'indirizzo usato per 
 inviare lamentele all'operatore).

 Choose a name for your remailer.  It will appear in remailer status messages.
 Long name: [Anonymous Remailer]
 
 Choose a name to be used in the `From:' line of remailed messages.
 Anon long name: [Anonymous]

 A short name to appear in lists:
 (questo sara' il "nome" del remailer con il quale sara'  definito nelle liste
 pubbliche dei remailer attivi; e' importante che non sia piu' lungo di
 8 caratteri e che non contenga lettere maiuscole).

 Accept Mixmaster (Type II) messages? [y]
 (per accettare messaggi nel formato mixmaster (type II) )

 Accept PGP (Type I) remailer messages? [y]
 (per accettare messaggi nel formato cypherpunk (type I) )

 Mixmaster will log error messages and warnings. Do you want to log
 informational messages about normal operation as well? [y]
 (il remailer non logga gli IP, pero' puo'  generare dei log
 riguardo la sua attivita', problemi, errori e operazioni compiute,
 utile soprattutto nella fase iniziale di debug)

 Filter binary attachments? [y]

 Allow users to add themselves to the list of blocked addresses? [y]
 (il remailer controlla se l'indirizzo di destinazione di un messaggio
 e' presente in un file di testo, e in caso affermativo non lo spedisce;
 se un utente riceve spamming dal remailer puo' chiedere che l'operatore
 lo inserisca nella block list, oppure puo' farlo da solo se questa
 opzione e' attivata).

 Do you want to allow posting? Newsgroups can be restricted in dest.blk.
 y)es, post locally; use m)ail-to-news gateway; n)o.
 Allow posting to Usenet? [m]

 Mail-to-news gateway: [mail2news_nospam@nym.alias.net]

 Pool size: [20]
 (se arriva un messaggio finisce nel pool e ne esce dopo tot tempo, tanto
 maggiore quanto piu' e' grande il pool dei messaggi, se pero' e'  troppo
 grande possono esserci problemi di latenza perche' i messaggi restano
 troppo nel pool prima di uscire; un valore basso e' utili per le prove).
 
 Mailbox for non-remailer messages: [/home/anon/Mix/mbox]
 (mailbox per i messaggi che il remailer non riconosce perche' non
 contengono istruzioni di remailing)

 Set .forward to the following line:
 "|/home/anon/Mix/mix -RM"
 Do that now? [n]
 (potete scegliere se usare questo formato oppure dire no e usare procmail
 che e' piu' versatile, spiegato piu' avvanti)
 
 Risposte automatiche impostate:
 Mail to <anon@esempio.it> with Subject: remailer-help => help.txt
 Mail to <anon@esempio.it> with Subject: remailer-adminkey => adminkey.txt
 Remember to add your Remailer Admin public PGP key to the adminkey.txt file.
 Mail to <anon@esempio.it> with line DESTINATION-BLOCK => blocked.txt
 Other mail to <anon@esempio.it> => usage.txt

 If you arrange for mail to <abuse@esempio.it> and <nobody@esempio.it>
 to be forwarded to <anon@esempio.it>:
 Mail to <abuse@esempio.it> => abuse.txt
 Mail to <nobody@esempio.it> => reply.txt

 Mixmaster installation complete.

2.3 Installazione del pacchetto debian precompilato

Se volete evitare la compilazione esiste per debian il pacchetto mixmaster

Una volta installato con "apt-get install mixmaster" verra' creato l'utente mixmaster.

Ora modificate il file di configurazione /var/lib/mixmaster/Mix/mix.cfg (che e' un symlink che punta a /etc/mixmaster/remailer.conf).

per la spiegazione delle varie voci vedete il capitolo precedente e la man page di mixmaster, la cosa piu' importante e' che definiate la PASSPHRASE, altrimenti le chiavi non saranno generate.

dopo averlo modificato create i msg usati dal remailer per rispondere in automatico ad alcune richieste:

# /usr/lib/mixmaster/mixmaster-rebuild

e generate le chiavi:

# mixmaster -G

questo dovrebbe creare sia la chiave mixmaster che la chiave gpg

In /etc/mixmaster sono contenuti alcuni file di configurazione:

allpingers.txt - lista dei pinger che raccolgono le statistiche dei remailer

client.conf - configurazione del client del remailer

filter.conf - qui si definisce quali header il remailer deve filtrare/accettare

network.conf - il contenuto della variabile network definita in questo file determina quando vengono aggiornate le statistiche e le chiavi dei remailer (tramite l'esecuzione di mixmaster-update, uno script eseguito giornalmente con cron). se la variabile NETWORK e' impostata a "PPP" questo avviene ogni volta che si entra in rete (utenti con modem classico) se si imposta come "permanent" questo avviene giornalmente (utenti con connessione fissa) se non si imposta non viene mai fatto l'aggiornamento in automatico

update.conf - qui' si definisce il pinger da cui prelevare le statistiche

sistemate i permessi dando un

# chown -R mixmaster.mixmaster /var/lib/mixmaster

2.4 Post-installazione

A questo punto come root dobbiamo impostare in /etc/postfix/aliases (questo dipende dal vostro MTA) due alias di posta per far arrivare all'utente anon i messaggi destinati ad abuse e nobody, e anche quelli per il remailer-admin.

abuse: mixmaster
nobody: mixmaster
remailer-admin: mixmaster

e lanciare il comando postalias /etc/postfix/aliases per aggiornare il database degli alias

Ora il remailer dovrebbe funzionare, ma bisogna fare ancora qualcosa prima di renderlo pubblico in modo che sia utilizzabile in catena:

Nel file mix.cfg sono anche definite le mailbox dove vengono salvati i msg errati (ad es. non crittati con la chiave del remailer), messaggi che vanno in bounce, richieste per l'utente abuse, errori vari e richieste di blocco delle persone che non vogliono che il remailer gli mandi i messaggi.

Per avere le mailbox facilmente accessibili con mutt bisogna impostare nel file .muttrc dell'utente anon:
set folder=~/Mix
Le mailbox saranno poi accessibili con mutt inserendo nel file .muttrc una riga come questa :
mailboxes +mbox.mix +mbox.abuse +mbox.block etc. etc.

Il remailer va annunciato alla lista dei remailer operators remops@remailer.org.uk remailer-operators@anon.lcs.mit.edu e al newsgroup alt.privacy.anon-server

Se si sceglie di gestire con procmail i msg in ingresso si devono mettere queste istruzioni nel .procmailrc dell'utente mixmaster:

:0
*
"|/usr/bin/mixmaster -RM"

Se usate il pacchetto debian ricordatevi di riavviare il servizio mixmaster ogni volta che modificate il file mix.cfg e anche di eseguire mixmaster-rebuild, di modo che le risposte automatiche siano ricostruite.

2.5 Tenere il remailer dentro un file system crittato

Un remailer dovrebbe sempre essere ben protetto, quantomeno le chiavi. E' possibile crittare tutto il disco, oppure scegliere di crittare solo alcune parti del remailer in modo da avere un piccolo file container crittato che contenga i dati piu' sensibili. Se scegliete questa seconda opzione qui' di seguito trovate una breve spiegazione di come fare:

Innanzitutto, studiatevi come si crea un container crittato con dmcrypt (potete trovare una piccola guida in questo stesso sito).

La dimensione del container dipende da cosa volete tenerci, il remailer inizialmente non occupa molto spazio, pochi Mb. Sono due le cose che possono occupare molto spazio: innanzitutto il pool dei messaggi, e secondariamente le mailbox dei messaggi di errore (soprattutto se non vengono controllate giornalmente).

Supponiamo di voler mettere nel container quello che sta dentro /var/lib/mixmaster:

Copiate il contenuto di /var/lib/mixmaster in una directory temporanea, a questo punto create un container crittato e montatelo in /var/lib/mixmaster.

Copiateci i file originariamente presenti in /var/lib/mixmaster

Il file /var/lib/mixmaster/Mix/mix.cfg e' un symlink che punta a /etc/mixmaster/remailer.conf

Visto che in questo file e' contenuta la passphrase della chiave del remailer e' meglio eliminare il symlink e spostare questo file nel container crittato:

# cd /var/lib/mixmaster/Mix
# rm mix.cfg
# mv /etc/mixmaster/remailer.conf ./mix.cfg
# ln -s /var/lib/mixmaster/Mix/mix.cf /etc/mixmaster/remailer.conf

ora, in questo modo il pool del remailer e' anch'esso contenuto nel container crittato, questo puo' causare problemi di carico e di spazio, volendo si puo' spostare il pool in /var/spool/mixmaster ad esempio e fare un symlink a questa directory.

Create uno script per montare il container all'avvio, che faccia partire anche postfix (e disabilitate l'avvio automatico di postfix che non deve partire finche' il container non e' montato).

E' possibile sfruttare il container per tenerci anche la chiave TLS di postfix e se sulla stessa macchina girano altri servizi anche le chiavi di questi ultimi.

Questo e' un esempio dello script per debian, da mettere in /etc/init.d :


#!/bin/sh
#
# monta la partizione crittata e avvia i servizi che ne abbisognano.
#


# immagine da montare
image_file=/root/mixmaster_container.img

# posti dove montarla
targets="/var/lib/mixmaster"

# servizi che dipendono dal container crittato
aux_svc="postfix mixmaster mixminion"

# nome del device mapper
devicem="secret"

# file di stato (memorizza quale fosse il loop device)
LOOPDEVFILE=/var/run/certs.loopdev


test -e $image_file || exit 1
test -x /sbin/cryptsetup || { echo "Install the 'cryptsetup' package." ; exit 1 ; }
test -e /proc/crypto || { echo "Install crypto support in the kernel." ; exit 1 ; }


case "$1" in

start)

        loop_device=`losetup -f`
        test -e $loop_device || exit 1

        echo $loop_device > $LOOPDEVFILE

        losetup $loop_device $image_file || exit 1
        
        # dmcrypt
        echo "Starting encryption..."
        /sbin/cryptsetup -c aes -s 256 -h ripemd160 create $devicem $loop_device 
        if [ $? -gt 0 ]; then
          echo
          echo "ERRORE - cryptsetup fallito."
          exit 127
        fi

        # mount partition
        echo -n "Mounting decrypted partition..."
        for mp in $targets
        do
          echo -n " $mp"
          mount -o rw,exec /dev/mapper/$devicem $mp
        done
        echo "."

        # controllino, evitiamo casini coi servizi che partono a muzzo
        if ! test -e /var/lib/mixmaster/Mix/secring.mix ; then
          echo "ERROR - something went wrong"
          exit 1
        fi

        # start more services
        echo "Starting more services..."
        for s in $aux_svc
        do
          invoke-rc.d $s start
        done

        ;;


stop)

        if [ ! -e $LOOPDEVFILE ]; then
          echo "No crypto partition state file found... Unmount by hand."
          exit 3
        fi
        loop_device=`cat $LOOPDEVFILE`
        if [ "x$loop_device" = "x" ]; then
          echo "Crypto partition state file is corrupted."
          exit 4
        fi

        echo "Stopping services depending on encrypted container"
        for s in $aux_svc
        do
          invoke-rc.d $s stop
        done

        echo -n "Unmounting partitions... "
        for mp in $targets
        do
          echo "$mp "
          umount -f $mp 2>/dev/null
        done
        echo "."

        echo -n "Stopping encryption..."
        /sbin/cryptsetup remove $devicem
        echo "done."

        losetup -d $loop_device

        ;;


reload)

        # fast restart, non scomoda i servizi
        echo -n "Re-mounting partitions..." 
        for mp in $targets
        do
          echo -n " $mp"
          umount -f $mp 2>/dev/null
          mount -o rw,exec /dev/mapper/$devicem $mp

        losetup -d $loop_device

        ;;


reload)

        # fast restart, non scomoda i servizi
        echo -n "Re-mounting partitions..." 
        for mp in $targets
        do
          echo -n " $mp"
          umount -f $mp 2>/dev/null
          mount -o rw,exec /dev/mapper/$devicem $mp
        done
        echo "."

        ;;


*)
        echo "$0 {start|stop|reload}"

esac


exit 0

2.6 Il remailer operator (remop)

Bisogna creare una chiave PGP/GPG che avra' uno user-ID remailer-admin@esempio.it, con questa chiave si firmeranno tutti i messaggi postati nella mailing list dei remailer-operators.

Bisogna creare l'utente remailer-admin@esempio.it in /etc/aliases che verra' indirizzato all'utente mixmaster

Per firmare tutti i msg in uscita dalla mailbox, usando mutt come client di posta di puo' impostare il .muttrc in questo modo:


my_hdr From: remailer-admin@esempio.it
set pgp_autosign
set pgp_sign_as="remailer-admin@esempio.it"
my_hdr X-PGP-Key-fingerprint: A9 32 4A CB 3C 4B 5D DA  AB 34 BC A6 4D C8 44 5C
set realname="remailerX Admin"

la chiave del remop va esportata nel file /Mix/adminkey.txt (se usate il pacchetto debian va messa in /etc/mixmaster/remailer/adminkey.txt), in modo che venga inviata a chi ne fa richiesta con un messaggio all'indirizzo del remailer con il subject "remailer-adminkey"

Inoltre e' buona norma firmare con la chiave del remop la chiave gpg del remailer.

Potete importare la chiave del remailer nel pubring dell'utente mixmaster, firmarla ed esportarla:

# gpg --import /var/lib/mixmaster/Mix/pgpkey.txt

# gpg -u remailer-admin@esempio.it --sign-key mixmaster@esempio.it

# gpg -a --export mixmaster@esempio.it > /var/lib/mixmaster/Mix/pgpkey.txt

2.7 Tips and tricks

Bounces

Puo' capitare che un remailer abbia dei problemi e quindi i messaggi destinati a lui vadano in bounce per qualche giorno. Quando il remailer torna online dobbiamo rimandargli tutti i messaggi, e per facilitare questa operazione potete usare questo script:

Resend

Dopo aver salvato in un file in formato mailbox tutti i messaggi, lanciando lo script con questa sintassi:

# ./resend file_mailbox indirizzo_del_remailer

i messaggi saranno rispediti.

Bloccare lo spam

Oltre ai soliti filtri a livello dell'MTA esistono diversi script per cercare di limitare lo spam. Uno dei piu' interessanti e sicuramente il Nilsimsa, che potete trovare a questo indirizzo:

http://ixazon.dynip.com/~cmeclax/nilsimsa.html

In pratica controlla che nel pool del mixmaster non ci siano dei messaggi che si "somigliano" oltre una certa soglia, e nel caso li mette in quarantena in attesa di essere esaminati.

E' un tool molto utile, anche se appesantisce un po' il lavoro di remailer administrator perche' poi i messaggi in quarantena vanno esaminati.

Fondamentalmente nilsimsa controlla se i messaggi che arrivano al remailer sono molto simili tra di loro, e se lo sono li cataloga come flood e li mette in quarantena, in attesa di essere esaminati e approvati/respinti.

scompattate il file nilsimsa-0.2.4.tar.gz nella home dell'utente che controlla il remailer, ad esempio /home/anon

# tar zxvf nilsimsa-0.2.4.tar.gz

che creera' la directory nilsimsa-0.2.4; entratevi e date i comandi

# ./configure && make

Potrebbe verificarsi un errore per la mancanza di termio.h, in questo caso dovete installare la libreria ncurses-dev.

Potete non effettuare il make install, previsto dalle istruzioni di installazione, per evitare la necessita' di avere le permission di root e mantenere tutti i file del remailer nella directory /home/anon

rinominate la directory

mv nilsimsa-0.2.4 nilsimsa

entrate nella directory nilsimsa/scripts ed editate i 3 script che vi si trovano, dando la path assoluta; in pratica, in tutte le righe che iniziano con

nilsimnsa .....

inserite la path all'inizio

/home/mix/nilsimsa/scripts/nilsimsa ......

Create la directory festi in /home/anon/Mix

cd /home/anon/Mix mkdir festi

facendo attenzione che abbia gli stessi permessi della directory pool

Con nilsimsa viene distribuito uno script (finddups) che va eseguito spesso, nel nostro caso noi lo facciamo girare ogni 2 minuti sul pool dei messaggi.

*/2 * * * * /Mix/nilsimsa/scripts/finddups

Se avete un POOL troppo piccolo o se avete impostato un SENDPOOLTIME troppo basso o un RATE troppo alto nel mix.cfg potreste avere problemi, nel senso che i messaggi potrebbero entrare ed uscire dal pool prima che nilsimsa li possa controllare.

Questo job lancia lo script finddups, che scandisce i file della directory pool (i messaggi del remailer) e sposta nella directory festi gli eventuali gruppi di messaggi molto simili. Inserisce poi nel file /home/mix/Mix/rules una riga che contiene l'impronta del gruppo di file spostati e la lettera "D". Questa riga provochera' lo spostamento di eventuali altri file simili che giungessero successivamente, anche se arrivassero uno per volta.

La directory festi tendera' quindi a riempirsi; usando a mano lo script catsimsa, a cui dovete fornire come argomento una intera liea del file rules, potete visualizzare i file relativi, per decidere se sono da gettare (spam, flood ..) oppure se sono legittimi (ad es. i ping dei pinger echolot)

Nei primi tempi dovrete provare ogni nuova riga di rules, per vedere se i messaggi sono dei ping; quando ne trovate uno, modificate la riga relativa sostituendo "D" con "A".

Potete anche aggiungere un commento aggiungendo un cancelletto a fine riga, e proseguendo con il commento vero e proprio. Attenzione a conservare lo spazio bianco che c'e' a fine riga; il cancelletto inseritelo dopo.

Rimettete poi i messaggi legittimi in pool con lo script mvsimsa, a cui come al solito va fornita la relativa riga di rules come argomento.

Ripetete l'operazione per tutte le nuove righe di rules (vi conviene inserire un commento per distinguere quelle che avete testato dalle altre che verranno aggiunte in futuro)

A questo punto cancellate tutti i file rimasti nella directory festi.

Durante un flood, su un remailer pienamente operativo possono essere generati anche 100Mb di file al giorno, sia nella directory festi, che nella mailbox dell'utente mix che nei file /home/anon/Mix/mbox.xxxx.

Oltre ai due scripts catsimsa e mvsimsa che aiutano nell'utilizzo di nilsimsa, io uso anche questi due:

delsimsa, per eliminare una serie di messaggi con lo stesso "nilsimsa code", o come in questo caso per parcheggiarli in una directory apposita.


 #!/bin/sh
 # delsimsa <nilsimsa code> <threshold>
 cd ~/Mix/festi
 ~/Mix/nilsimsa -c $1 -t $2 ~/Mix/festi/m* | grep ^1 | cut -c 3- | xargs -i mv {} ~/Mix/festi/deleted/

checksimsa, per avere una lista di tutti i file ordinati secondo il loro "nilsimsa cose", in questo modo e' piu' semplice individuare i gruppi di file identici.


 #!/bin/sh
 cd ~/Mix/festi
 ~/Mix/nilsimsa -v -H ~/Mix/rules ~/Mix/festi/m* | sort -k 3

Se un remailer cambia IP ma il DNS non si aggiorna

Quando un remailer cambia IP ma il DNS non si aggiorna i messaggi per quel remailer vanno in bounce.

Si puo' pero' forzare l'MTA a spedire i messaggi destinati ad un certo indirizzo non all'MX per quel dominio ma direttamente ad un indirizzo IP, senza passare dal DNS.

Se utilizzate postfix la procedura e' questa:


file /etc/postfix/transport:

| cypherpunks.to                smtp:[213.130.163.34]

In questo caso le mail per il dominio cypherpunks.to vengono spedite direttamente alla porta 25 dell'IP 213.130.163.34

Poi nel file /etc/postfix/main.cf definite la transport map:

transport_maps = hash:/etc/postfix/transport

e poi come root ricostruite la transport map

# postmap /etc/postfix/transport

Fare un upgrade delle chiavi del remailer

Ogni tanto le chiavi del remailer andrebbero sostituite con chiavi nuove.Per iniziare fatevi una copia dei vari keyring

Generate una nuova coppia di chiavi con

$ mix -G

Questo generera' nuove chiavi mixmaster, RSA e DH. Controllate di avere due chiavi nel file secring.mix, e spostate la chiave nuova in cima al file, spostando la vecchia sotto.

Eliminate il file key.txt e richiedete la chiave al remailer, lui rigenerera' il file con la nuova chiave pubblica ricostruendola dalla chiave privata.

Passiamo ora alle chiavi PGP/GPG:

Quando e' stata (o sono state, se avete anche la chiave RSA) prodotta la chiave, il file pgpkey.txt si dovrebbe essere aggiornato con le nuove chiavi.

Con questo comando:

$ gpg --no-default-keyring --secret-keyring ./secring.pgp --list-secret-keys

dovreste vedere sia le vecchie che le nuove chiavi con un output simile a questo:


./secring.pgp
-------------
sec  1024D/07BF4D7E 2002-09-29 Anonymous Remailer <anon@esempio.it>
ssb  1024g/B0C9007C 2002-09-29

sec  1024R/485671B1 2003-03-18 Anonymous Remailer <anon@esempio.it>

sec  1024R/495574F5 2003-03-18 Anonymous Remailer <anon@esempio.it>

sec  1024D/FBEED8AF 2003-03-18 Anonymous Remailer <anon@esempio.it>
ssb  1024g/D539A465 2003-03-18

l'ordine e' cronologico, in cima la chiave piu' vecchia, in fondo l'ultima generata.

Stessa cosa per il file pgpkey.txt

Ricordate che se cancellate il file pgpkey.txt, richiedendo la chiave al remailer con un messaggio dal subject "remailer-keys" il file sara' ricreato partendo dalle chiavi private presenti nel file secring.pgp

Annunciate il cambio di chiavi e postate le nuove chiavi sulla lista dei remailer operators e nel newsgroup alt.privacy.anon-server

Quindi eliminate dal file pgpkey.txt le vecchie chiavi, in modo che chi richieda le chiavi al remailer ottenga solo le chiavi nuove.

Dopo un paio di settimane eliminate le vecchie chiavi dai keyrings, in genere la cosa migliore e' fare un:

$ gpg --no-default-keyring --secret-keyring ./secring.pgp --delete-secret-keys keyID

dove KeyID e' il keyID della chiave che volete eliminare.

Firmare le nuove chiavi con le vecchie chiavi

Quando si generano nuove chiavi e' buona norma firmarle con la chiave del remailer administrator e con le vecchie chiavi. Supponendo che la chiave del remailer operator sia nel keyring dell'utente anon, importate le nuove chiavi pubbliche del remailer:

$ gpg --import pgpkey.txt

$ gpg --secret-keyring ./secring.pgp -u remailer_admin_keyID --sign-key new_remailer_keyID

$ gpg --secret-keyring ./secring.pgp -u old_remailer_keyID --sign-key new_remailer_keyID

In questo modo abbiamo importato le nuove chiavi, e le abbiamo firmate con la chiave del remailer admin e con le vecchie chiavi del remailer.

(la password delle vecchie (e nuove) chiavi e' scritta nel file mix.cfg)

Adesso esportiamo le chiavi firmate

$ gpg --export -a new_remailer_keyID > pgpkey.txt

Statistiche del remailer

Potete tener d'occhio come funziona il vostro remailer visitando queste pagine:

http:/www.noreply.org/

oppure createvi un vostro pinger installando il programma echolot.

2.8 Creare una pagina di statistiche del remailer

Per costruire una pagina che riassuma un po' di statistiche del remailer mi sono appoggiato a diversi script, molti dei quali scritti dall'admin del remailer arancio che ora e' chiuso e quindi gli script non sono piu' disponibili dal suo sito, quindi li riporto qui', modificati quel tanto che basta per adattarli al remailer paranoia.

Questo e' il crontab dell'utente anon:


# preleva le statistiche dei remailer ogni 6 ore.
0 */6 * * *     anon    /home/users/anon/scripts/getmix2.sh 2>/dev/null

# ogni ora richiede le statistiche al remailer 
1 * * * *       anon    echo "ping" | /usr/bin/mail -s "remailer-stats" \
   anon@paranoici.org > /dev/null 2>&1   

# generazione statistiche remailer
21 * * * *     anon     /home/users/anon/scripts/parse-stats.sh
25 */4 * * *   anon     /home/users/anon/scripts/stat2html.sh
10 0 * * *     anon     /home/users/anon/scripts/message-counter.sh

getmix2.sh viene lanciato ogni 6 ore e scarica chiavi e statistiche dei remailer da un sito (a scelta), potete anche indicarne uno non presente nel file, una lista dei pinger funzionanti si trova qui':

http://www.noreply.org/allpingers/

Ogni primo minuto di ogni ora viene mandata una mail al remailer richiedendo le sue statistiche, nel .procmail dell'utente anon c'e' poi questo:


:0 :
* ^From: Paranoia Remailer <anon@paranoici.org>
* ^Subject: Statistics for the paranoia remailer
/home/users/anon/tmp/stats-tmp

quindi le statistiche vengono salvate in /home/users/anon/tmp/stats-tmp

parse-stats.sh alle 3 di notte genera dal file stats-tmp due file, uno e' /home/users/anon/stats/remailer-stats.txt, che verra' usato da message-counter.sh, l'altro e' /home/users/anon/tmp/remailer-stats.txt da cui saranno prelevati i dati per i grafici di mrtg

message-counter.sh questo script lanciato ogni giorno alle 00:10 legge i dati delle statistiche e crea una tabella html (/home/users/anon/stats/messages.html) con il numero di messaggi processati dal remailer, divisi in cpunk, mix e totali.

stat2html.sh questo script viene lanciato ogni 4 ore, preleva le statistiche del nostro remailer da 5 diversi pinger (l'affidabilita' espressa in % e la latenza), mostra i dati giornalieri in una tabella html per i singoli pinger e calcola la media. Crea anche i file di testo che saranno poi utilizzati da MRTG per creare i grafici di questi dati, in modo che siano disponili su base giornaliera, settimanale, mensile e annuale. Puo' creare anche una tabella che evidenzia lo stato di salute generale della rete dei remailer.

questi sono i settaggi di mrtg.cfg per creare i grafici:

Scripts:

Next Previous Contents