BestKevin's Weblog

Hacking di un addon firefox

BestKevin — 2008-08-02T14:08:36+02:00

Dovrei scrivere il report dei due week end passati, ma troppo da scrivere e poco tempo...
Vabbe'...prendo l'occasione per esporre un sistema banale per risolvere il problema del plugin Snap links: "Snap Links allows users to easily open multiple links in new tabs by drawing a box around them. Links can also be opened in new windows, new tabs on a new window, copied to clipboard, bookmarked or downloaded."
E' un plugin molto carino ed interessante, immaginate una pagina con tutta una serie di link, ad esempio una ricerca su google, grazie a questo pezzo da aggiungere a firefox potete selezionare con il tasto destro tutti i link ed essi verranno aperti in nuove schede. Ma...c'e' un problema: questo plugin non e' compatibile con la versione 3.x di firefox, ed ecco come ovviare al problema:
scaricate il plugin da qui, e' un file .zip nonostante abbia l'estensione .xpi, per cui scompattatelo; dentro trovate il file install.rdf che dovete aprire con un editor di testo: modifica la riga contenente "maxVersion" mettendo al posto del valore (io avevo 3.0a8) con un valore maggiore, ad esempio 3.1. Salvate, comprimete con uno zip il contenuto rinomimandolo .xpi ed importatelo in firefox mediante il menu' file/apri.
Tutto qui. Una soluzione semplice, per un problema potenzialmente grande :)

Auguri SysAdmin

BestKevin — 2008-07-25T08:39:02+02:00

Un caloroso augurio a tutti gli amministratori di sistema in occasione del 9th Annual System Administrator Appreciation Day.
"It's you isn't it? THE BASTARD OPERATOR FROM HELL!" "In the flesh, on the phone and in your account..."
Simon Travaglia

One time pass su ssh

BestKevin — 2008-06-07T23:03:44+02:00

Lo avevo gia' fatto con sarge, ma da quando ho reinstallato con etch era una delle cose che avevo lasciato al futuro, ovvero ad adesso.
Sto parlando delle OPIE - One Time Password. Lo scopo di questo modulo e' generare una password da richiedere (nel mio caso in ssh) ma che una volta usata viene "bruciata", come avviene con alcuni sistemi usati dalle banche per autorizzare le transazioni. La comodita' e' quella di potersi collegare da macchine considerate non sicure, ad esempio il PC di un cliente o di un amico, che potrebbero avere uno sniffer a bordo, poiche' il sistema non chiedera' piu' quella password, quindi averla non servira' a nulla.
Si inizia ad installare i pacchetti richiesti:
apt-get install libpam-opie opie-server opie-client
L'utente (nell'esempio kevin) deve creare una password per OPIE che sara' usata per generare le pass seguenti, attraverso l'apposito comando (notare cheuso il parametro -f per forzare quello che sarebbe un comando da dare esclusivamente da console):

opiepasswd -f -c kevin

Se vi dimenticate la password inserita potete rimuovere la riga relativa in /etc/opiekeys
Si deve poi configurare pam modificando il file /etc/pam.d/ssh inserendo la riga (la prima e la terza ci sono gia', le ho messe per indicare dove metterla esattamente):

# Standard Un*x authentication.
auth sufficient pam_opie.so
@include common-auth

In questo modo prima di richiedere la password del passwd (comportamento standard), viene richiesta la OPIE.
E' necessario pero' modificare anche /etc/ssh/sshd_config nel valore di una variabile, ponendo:

ChallengeResponseAuthentication yes

Riavviamo poi sshd con

/etc/init.d/ssh restart

Se ora si prova a collegarsi in ssh, dopo il nome utente viene richiesta una pass mostrando due parametri: numero della chiave e seme. Il primo e' decrescente (la prima volta viene chiesto la chiave 499, poi la 498 etc...) mentre il secondo e' fisso ed e' generato e visualizzato quando si da il comando opiepasswd. Questi due valori, insieme alla password inserita sempre con opiepasswd, serve ad ottenere una serie di parole che rappresentano il valore della chiave OPIE da inserire. Come calcolarla ? Ci sono vari sistemi, io uso un programma (free) in java installato sul mio SonyEricsson T630 che si chiama VeJOTP: basta inserire il numero di chiave richiesta, il seme e la password per ottenere la frase segreta, il numero di chiave viene poi decrementato automaticamente per cui la volta successiva basta premere il pulsante per ottenere la frase segreta.

Aggiornamento statistiche spam

BestKevin — 2008-04-01T18:05:14+02:00

Dopo l'applicazione delle regole per bloccare le email dirette a indirizzi inesistenti (pubblicata QUI), ho voluto riprovare a vedere se i server remoti imparano un po', ed in effetti parrebbe di si', vediamo alcune statistiche:

Mail lecite:
grep "delivered" /var/log/syslog.0 | wc
2813 36578 410275
grep "Illegal user" /var/log/syslog.0 | wc
16877 354417 4662719

Beh, un buon risultato confrontandolo con quello precedente:

Mail lecite:
grep "delivered" /var/log/syslog.0 | wc
2531 32931 370647
grep "Illegal user" /var/log/syslog.0 | wc
48161 1011383 13132925

Circa un terzo delle email illecite ricevute (alle quali si chiude la porta in faccia), e cio' non e' dovuto ad un diminuito traffico in quanto le mail lecite sono invece aumentate. Molto bene.

Dimenticavo SPF :)

BestKevin — 2008-03-21T20:47:19+02:00

In questo articolo ho accennato ad un sistema per porre fine, o almeno limitare, lo spam che falsifica il mittente apparendo provenire dal mio dominio, ma ho scoperto di non averne in realta' accennato :)
Oltre a Domain Keys un altro sistema utilizzato da vari provider, tra cui Google, e' SPF - Sender Policy Framework.
Scopo di questo sistema e' quello di definire quali server sono autorizzati a inviare email per un certo dominio: io mando una mail da kevin @bestkevin.com dal server xxx.xxx.xxx.xxx, il server ricevente verifica se tale server e' autorizzato o meno a mandare email per il dominio bestkevin.com e si comporta secondo quello che viene definito. Ma come fare a dire quali IP sono autorizzati o meno ?
La cosa e' brillantemente semplice: come in Domain Keys anche qui ci si basa sul campo TXT nella zona definita nel DNS.
Prendiamo ad esempio proprio bestkevin.com:

kevin@jenny:~$ dig +short TXT bestkevin.com
"v=spf1 a mx -all"

ovvero, nella zona:
bestkevin.com. IN TXT "v=spf1 a mx -all"
Il significato e': accetta email per il dominio bestkevin.com solo da quei server che sono definiti come MX per il dominio stesso. L'elenco delle varie opzioni e possibilita' le trovate qui. Ovvio che ora posso mandare email @bestkevin.com solo dal mio server, ma e' quello che faccio sempre, quindi, per me, non e' una limitazione.

Ancora sulla lotta allo spam

BestKevin — 2008-03-17T23:22:24+02:00

Riprendendo il discorso gia' iniziato sullo spam che cerca di raggiungere utenti inesistenti, dopo l'uso di dkimproxy, ho pensato di fare un ulteriore passo in avanti (o indietro...domani vedremo).
Nella catena di ricezione delle email postfix:25(DNSBL) -> postgrey:60000 ... postfix:25 -> amavis:10024 -> postfix:10025, ho pensato che forse sprecare tutta questa CPU e memoria per gestire un 80% di email destinata a utenti inesistenti e' un grosso peccato, per cui, perche' non creare una lista di destinatari esistenti e relativi alias, direttamente al primo postfix ? Si risponderebbe (o anche no, vedete voi) che l'utente non esiste e fine, senza passare per tutti gli step.
Visto che gli utenti nel mio caso sono in un db MySQL, ho fatto quindi un paio di modifiche a postfix aggiungendo (anche se in realta' l'opzione era gia' presente ma lo dico per completezza) le seguenti impostazioni nel main.cf:

smtpd_recipient_restrictions =
...
check_recipient_access hash:/etc/postfix/recipient_access,
...

A questo punto, tramite un banale script, genero il file recipient_access:

#!/bin/sh
# Sostiture xxx con la password di accesso a mysql, se necessaria,

cat /dev/null > /etc/postfix/recipient_access
for user in `mysql -N -pxxx --batch -e "select username from mailbox order by domain" postfix`
do
echo $user" FILTER smtp-amavis:[localhost]:10024" >> /etc/postfix/recipient_access
done

for user in `mysql -N -pxxx --batch -e "select address from alias where address <> goto order by domain" postfix`
do
echo $user" FILTER smtp-amavis:[localhost]:10024" >> /etc/postfix/recipient_access
done

for domain in `mysql -N -pxxx --batch -e "select domain from domain order by domain" postfix`
do
echo $domain" 550 Illegal user." >> /etc/postfix/recipient_access
done

cd /etc/postfix
postmap recipient_access > /dev/null 2>&1
postfix reload > /dev/null 2>&1

Cosa otteniamo ? Il seguente file recipient_access:

esiste1@dominio.tld FILTER smtp-amavis:[localhost]:10024
esiste2@dominio.tld FILTER smtp-amavis:[localhost]:10024
...
dominio.tld 550 Illegal user.

Con questa piccola modifica, le email per utenti inesistenti saranno bloccate al loro primo contatto e non intaseranno piu' il server nel passaggio dei filtri successivi.
Funziona ? Non funziona ? Da una prima analisi mi parrebbe di si', vediamo domani cosa succede.
Update: Ecco alcuni numeri il giorno dopo:
Mail lecite:
grep "delivered" /var/log/syslog.0 | wc
2531 32931 370647
grep "Illegal user" /var/log/syslog.0 | wc
48161 1011383 13132925

Mi sembra un buon risultato.

20 Things I Learned From Tech Support

BestKevin — 2008-03-16T12:23:49+02:00

Beh, saranno anche vecchie e probabilmente note, ma non posso fare a meno di pubblicarle dopo averne letta una in un fortune nella firma di una mia email (create di volte in volta in automatico). Sono pezzi di verita' :) E quelle in neretto sono piu' vere delle altre.

As long as the world turns, users will still have problems

Substance abusers and computer operators are the only folks called users. This isn't by chance

When in doubt. Reboot

Sooner or later you will meet a person who types out the words "backslash" or forgets to plug in the power cord. If you haven't yet, just wait, you will

Fear the phone. No one just calls tech support to wish you good morning

No user will tell you the whole truth at the beginning of a call

"I didn't do anything" or "It just happened" Are the users mantra

As a support tech, it is your job to break down resistance and get the truth

This is so you can rub the lie in their face, fixing the issue is just a perk

Some people will never learn

This means you will always have a job

Maintain a calm voice, even if you're screaming on the inside

The hold button is your friend

Whatever you do, don't panic

The answer to all users questions should be "Trust me, I know what I'm doing" even if this is a bald-faced lie

Users can smell fear. Once you've lost control, all is lost

A user who is not listening to you anymore, but rather is trying "their own thing" is not worth your time. Simulate a telephone disconnect and hang up. Trust me, you're better off.

Sometimes fixing a computer is easier than figuring out why it was broken

Users always want a reason things are fixed. If you're not sure just lie. They won't know anyway. "A stray electron passed through the processor and caused..."

If possible ask to speak to the youngest person present

domainkeys su bestkevin.com

BestKevin — 2008-03-03T14:47:20+02:00

Gia' da un po' sto cercando metodi "alternativi" per limitare la ricezione di spam, ma anche di evitare che altri mi inviino email di avviso che li sto spammando quando, ovviamente, si tratta solo di email camuffate. Ciclicamente mi trovo a dover gestire valanghe di email. Fino ad ora mi sono limitato a inserire nel recipient_address di postfix una riga, ad esempio:
vodbestkevinmet@bestkevin.com 550 Sender is forged !!! *YOU* are spamming me. Please read http://www.spamcop.net/fom-serve/cache/329.html
Questo e' sufficente a non vedersi recapitate piu' email verso quel destinatario e nel giro di qualche ora dai log si vede che non arrivano proprio piu'. Probabilmente, anzi sicuramente, sara' cosi' anche in futuro, ma ho voluto adottare anche altri sistemi.
Il primo che ho adottato, molto banale, e' stato Sender Policy Framework, usato da Gmail, che in sostanza consiste nell'aggiungere ai dati della zona del proprio dominio alcune informazioni, in un campo TXT, su quali sono i server autorizzati ad inviare email per quel dominio. Ad esempio per bestkevin.com:
bestkevin.com. IN TXT "v=spf1 a mx -all"
infatti:
kevin@jenny:/etc/spamassassin$ dig +short TXT bestkevin.com
"v=spf1 a mx -all"
In entrata la verifica la faccio fare a spamassassin, collegato ad amavis.
Volendo aumentare questo genere di "protezione", ho installato anche il sistema DomainKeys, che oltre a funzionare un po' come SPF, aggiunge anche un livello di integrita' del messaggio, in quanto firmato dal server. A me interessa solo la verifica di identita' nell'invio.
Recupero quindi dal .bash_history un po' di informazioni :) considerando che il sistema e' una Debian GNU/Linux Etch. La base delle informazioni la potete trovare qui e qui.
Installiamo i pacchetti necessari. Manca una libreria di perl, o meglio quella di etch non e' aggiornata per cui si dovra' installare da CPAN.
su - Mai lavorare come root...ma tant'e' ;) mkdir DomainKey
cd DomainKey/
apt-get install libcrypt-openssl-rsa-perl
apt-get install libdigest-sha-perl libdigest-sha-perl1
apt-get install libdigest-sha-perl libdigest-sha1-perl
apt-get install liberror-perl
apt-get install libemail-address-perl
apt-get install libnet-server-perl
Preleviamo il programma che si occupera' di effettuare le firme dei messaggi in uscita e la verifica di quelli in entrata (a me interessa solo la prima parte lasciando a spamassassin la seconda):
wget http://downloads.sourceforge.net/dkimproxy/dkimproxy-1.0.1.tar.gz
tar xvfz dkimproxy-1.0.1.tar.gz
cd dkimproxy-1.0.1
mkdir /usr/local/sbin/dkimproxy
cpan
Qui, se e' la prima volta che lo lanciate, premete sempre invio tranne all'indicazione del mirror da usare per scaricare le librerie necessarie. Una volta arrivati alla shell di CPAN date il comando:
install Mail::DKIM
Proseguiamo...
./configure --prefix=/usr/local/sbin/dkimproxy/
make install
cd /usr/local/sbin/dkimproxy
adduser dkim
passwd dkim -d
cd etc/
openssl genrsa -out private.key 1024
openssl rsa -in private.key -pubout -out public.key
cd /usr/local/sbin/dkimproxy
chown -R dkim.dkim dkimproxy/
cd dkimproxy/etc/
chmod go-r private.key
mv dkimproxy_out.conf.example dkimproxy_out.conf
mv dkimproxy_in.conf.example dkimproxy_in.conf
cp /root/DomainKey/sample-dkim-init-script.sh /usr/local/sbin/dkimproxy/etc/init.d/dkimproxy.sh
ln -s /usr/local/sbin/dkimproxy/etc/init.d/dkimproxy.sh /etc/rc2.d/S90dkimproxy
/etc/rc2.d/S90dkimproxy start
Ora dovrebbe essere installato e funzionante. Io ho modificato lo script di avvio commentando nella sezione start) la chiamata a start-in) perche' come detto non mi interessa.
Vediamo cosa mettere nella zona del DNS. Semplicemente:
selector1._domainkey.bestkevin.com. IN TXT "k=rsa; t=s; p=M
IGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjoawNERYaU5QHfihMhEOLG4VlkM4iG
/QaRXKKJ8Kf2/UQtRrrN4uKPVEq1jvHwlz6et3gpBQCMp31FOMeGxKwKGCQjVPOD5tLs
7AB7Gas/JLBtONbktwy6wL5bsEa7osdxjqPzeIwGfgIVAav6RW17nLEKdnW4M+Roj/3r
sdiKQIDAQAB"
dove selector1 e' un nome scelto (tutti usano questo, quindi ho proseguito la tradizione), il resto va uguale cambiando il dominio e la parte della chiave pubblica che altro non e' che il contenuto del file public.key che avevamo generato, avendo l'accortezza di concatenare cio' che nel file e' su piu' righe.
Bisogna ora modificare il master.cf di postfix, considerate che io ho cambiato le porte di funzionamento da quelle di default 100XX con le 101XX in quanto ho amavis che gira sulle stesse:
cat /etc/postfix/master.cf
...
submission inet n - - - - smtpd
-o smtpd_etrn_restrictions=reject
-o smtpd_sasl_auth_enable=yes
-o content_filter=dksign:[127.0.0.1]:10127
-o receive_override_options=no_address_mappings
-o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

dksign unix - - - - 10 smtp
-o smtp_send_xforward_command=yes
-o smtp_discard_ehlo_keywords=8bitmime,starttls

127.0.0.1:10128 inet n - - - 10 smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

Vorrei farvi notare che a differenza degli howto online, qui postfix lavora in chroot, ed infatti il campo relativo di master.cf e' diverso. Per questo motivo e' necessario spostare tutto quello che abbiamo fatto, nella chroot di postfix:
mkdir /var/spool/postfix/usr mkdir /var/spool/postfix/usr/local/ mkdir /var/spool/postfix/usr/local/sbin mv /usr/local/sbin/dkimproxy /var/spool/postfix/usr/local/sbin ln -s /var/spool/postfix/usr/local/sbin/dkimproxy /usr/local/sbin/
L'ultima cosa da fare e' modificare spamassassin per dirgli di controllare lui le chiavi delle email in arrivo, ovvero nel file v312.pre togliere il commento alla riga relativa:

loadplugin Mail::SpamAssassin::Plugin::DKIM

Tutto qui, il sistema dovrebbe essere pronto (guardate magari i file di config di dkimproxy per verificare che si adattino alla vostra config, in particolare il nome del dominio).

Per fare una prova, mandate una mail a test@dkimtest.jason.long.name con oggetto dkim, e vedete cosa vi risponde, oppure mandatela ad un account su yahoo: dovrebbe dirvi, sotto al campo mittente una volta aperta la mail, che lo stesso e' stato verificato con DomainKeys.

Spero di non aver dimenticato nulla, se avete domande...mandate una mail :)

Backscatter

BestKevin — 2008-02-08T09:25:58+02:00

Gestire un server di posta a volte puo' richiedere di andare a snidare i problemi anche di altri, ad esempio di clienti che usano il tuo come relay host, per cui loro problemi di open relay o backscatter diventano anche i tuoi.
Uno dei server che gestisco e' nella lista di Backscatterer da un po' di tempo e sto cercando di venirne fuori, ma la cosa non e' facile con migliaia di domini e chissa' quanti server che usano quello da me gestito come relay host. Il primo passo e' stato togliere i backup MX, soprattutto su indicazione di altre persone, delegando la questione ad altri ;) nell'ottica di "non rimandare a domani quello che puo' fare oggi qualcun altro".
Ecco un esempio di quello che ho appena snidato:
kevin@kevin:~$ telnet xx.xx.xx.xx 25
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
220 srv.dominio.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at Fri, 8 Feb 2008 09:08:39 +0100
ehlo bestkevin.com
250-srv.dominio.com Hello [xx.xx.xx.xx]
mail from:
250 2.1.0 kevin@bestkevin.com....Sender OK
rcpt to:
250 2.1.5 nonesiste@dominio.com
data
354 Start mail input; end with .
pippo
.
250 2.6.0 Queued mail for delivery
quit
221 2.0.0 srv.dominio.com Service closing transmission channel
Connection closed by foreign host.

Dov'e' il problema ? Semplicemente che l'utente cavia (io in questo caso) riceve un report che dice che l'utente non esiste, con anche la mail originale allegata, e se questo fosse spam l'utilizzo del backscatter sarebbe un modo per inviarlo.
Come si evita ? Bisogna fare in modo che il server neghi la transazione SMTP non appena scopre che l'utente non esiste:
kevin@kevin:~$ telnet srv.miodominio.com 25
Trying yy.yy.yy.yy...
Connected to srv.miodominio.com.
Escape character is '^]'.
220 srv.miodominio.com ESMTP Postfix (Debian/GNU)
ehlo bestkevin.com
250-srv.miodominio.com
mail from:
250 Ok
rcpt to:
550 : Recipient address rejected: User unknown in virtual mailbox table
quit
221 Bye
Connection closed by foreign host.

In questo secondo caso non si e' dato tempo e modo al server di origine di spedirci la mail, accodarla e dopo verificare che non esiste il destinatario.

Salviamo OpenCon

BestKevin — 2007-09-18T10:10:50+02:00

Ricevo un'allarmante email:

From: fabioFVZ
Subject: [openbeer] Probabile cancellazione evento OpenCON
Ciao a tutti,
come potete immaginare, OpenCON e' gratis per i visitatori, ma ha dei costi non indifferenti.

Gli anni passati questi sono stati supportati da vari sponsors e dai corsi OpenBSD fatti da alcuni di noi.

OpenCON 2007, in questo momento, ha solo 1 sponsor e ha raccolto circa 1.000 euro fin'ora.

Il costo previsto della manifestazione e' di circa 10.000 euro.

Se per Domenica 30 Settembre non avremo raggiunto almento 6.000 euro l'evento sara' rinviato al 2008.

Chi vuole fare i corsi se mi inviano i dati di quando e dove che poi iniziamo la pubblicita'.

Comunque quest'anno dubito fortemente che si riesca a fare la manifestazione.

Mancano solo 2 settimane al 30.

OpenCon e' una conferenza dedicata ad OpenBSD che si e' tenuta dal 2004 in Italia e che raggruppa gli sviluppatori core del sistema operativo nonche' il fondatore/mentore Theo de Raadt.
OpenCon e' importante per vari motivi:

hackaton: raggruppa gli sviluppatori in quello che viene definito hackaton, una maratona di coding e bug fixing in previsione del rilascio della versione successiva, ed essendo gli sviluppatori in tutto il mondo non e' facile organizzare un evento che li raggruppi in un unico luogo fisico;
precede o attua il rilascio di nuove release: ogni 6 mesi circa viene rilasciata una nuova release di OpenBSD, uno di questi rilasci coincide o quasi con OpenCon;
stage e talk: la conferenza e' aperta, gratuitamente al pubblico, che puo' seguire direttamente dalla bocca degli sviluppatori, spiegazioni su nuove funzionalita' o sul funzionamento di demoni o parti del kernel;
potete parlare con loro: sembrerebbe una sciocchezza, ma poter parlare direttamente con gli sviluppatori puo' essere una possibilita' enorme per chi usa OpenBSD nella propria azienda, vuole richiedere il supporto di qualche hardware particolare, discuterne con chi mette le mani nel codice;

Il problema, oggi, e' che non ci sono abbastanza sponsor per supportare l'evento: bisogna pagare i locali, aiutare nelle spese di viaggio gli sviluppatori, il vitto e altro ancora, nulla rimane in tasca agli organizzatori. Per cui:
CFM - CALL FOR MONEY: se hai un'azienda che puo' o vuole sponsorizzare OpenCon fatti avanti, idem se hai conoscenze di OpenBSD e vuoi tenere dei corsi per raccolta fondi presso la tua citta', basta mandare una mail a info at openbeer dot it
Non c'e' molto tempo.