Archivi tag: chiave privata

Configurare DKIM come milter su Postfix e CentOS 6

Il DKIM (DomainKeys Indentified Mail) è un sistema per riconoscere univocamente le email provenienti dai domini che lo implementano, eliminando così il problema del mail spoofing e mitigando il problema del phishing/spamming. Esso si basa su un sistema di crittografia asimmetrica (RSA, chiave pubblica e privata), ed aggiunge all’header delle email (nel campo DKIM-Signature) alcuni tag necessari per l’identificazione delle stesse (ed eventualmente per la decifratura del corpo del messaggio).

dkim-process1

In soldoni, il destinatario dell’email ricava la chiave pubblica associata al dominio mittente da un record DNS di tipo TXT e la usa per decriptare il messaggio appena ricevuto (che era stato cifrato dal mittente utilizzando la chiave privata di quel dominio).

I dettagli sul funzionamento di tale sistema (con il segnificato dei vari tag aggiunti all’header) potete trovarli qui.

In questo post descriverò la procedura per integrare DKIM con Postfix su piattaforma CentOS 6.2 ed utilizzarlo come milter (con funzionalità di anti mail spoofing, anti phishing ed anti spam).

Per prima cosa installiamo il pacchetto opendkim:

[root@antispam ~]# yum install opendkim

ed impostiamo l’avvio automatico di tale servizio per i diversi runlevels:

[root@antispam ~]# chkconfig --levels 2345 opendkim on

Ora generiamo il keypair per il nostro dominio:

[root@antispam ~]# mkdir -p etc/opendkim/keys/vostrodominio.com/
[root@antispam ~]# /usr/sbin/opendkim-genkey -D /etc/opendkim/keys/vostrodominio.com/ -d vostrodominio.com -s default

e salviamo chiave pubblica e privata all’interno della giusta directory, previa definizione dell’owner:

[root@antispam ~]# chown -R opendkim:opendkim /etc/opendkim/keys/vostrodominio.com
[root@antispam ~]# mv /etc/opendkim/keys/vostrodominio.com/default.private /etc/opendkim/keys/vostrodominio.com/default

Editiamo il file /etc/opendkim.conf e settiamo per prima cosa il giusto pathname delle chiavi:

KeyFile /etc/opendkim/keys/vostrodominio.com/default

e successivamente definiamo la modalità di funzionamento di opendkim:

Mode v

ovvero, essendo installato su un server che funge da anti spam, il demone in questione dovrà solo verificare che le email provenienti dai domini che supportano DKIM siano autentiche (la v sta appunto per verify).

A questo punto editiamo il file /etc/postfix/main.cf ed aggiungiamo le seguenti direttive:

smtpd_milters           = inet:127.0.0.1:8891
non_smtpd_milters       = $smtpd_milters
milter_default_action   = accept

avviamo opendkim:

[root@antispam ~]# service opendkim start

e ricarichiamo la configurazione di postfix:

[root@antispam ~]# service postfix reload

Per verificare che tutto stia funzionando correttamente è sufficiente osservare l’output del comando:

[root@antispam ~]# tail -f /var/log/maillog | grep dkim

e fare delle prove di invio da domini che supportano DKIM (ad esempio gmail) e da domini che non lo supportano. Se in entrambi i casi la mail viene correttamente recapitata a destinazione allora abbiamo la certezza che il nostro nuovo sistema sta funzionando come dovrebbe.

Alla prossima.

Cisco PIX 501 ed il fingerprint SSH (non visualizzabile da CLI)

Qualche tempo fa, mentre provavo ad abilitare l’SSH sul mio PIX 501, ho cercato di visualizzare il fingerprint che viene generato dopo aver creato la coppia di chiavi RSA pubblica/privata.

pix 501,sshv1,sshv2,rsa1,rsa2,exploit,ssh 1.5,fingerprint,chiave pubblica,chiave privata

Con mio enorme stupore, dopo una breve ricerca su Internet e diversi tentativi da console, ho constatato che tale fingerprint non è visualizzabile direttamente dalla CLI del PIX.

L’unico comando presente da linea di comando è il seguente:

NightFirewall# sh ca mypubkey rsa

che consente di visualizzare la chiave pubblica usata dal firewall in questione, ma non il suo fingerprint.

Inoltre, dando un’occhiata al file .ssh/known_host presente nella mia home, ho notato che il fingerprint salvato è diverso da quelli associati agli host SSHv2. Questo a mio avviso è imputabile a due fattori:

1) L’uso di RSA1 anzichè RSA2 per la generazione del fingerprint stesso;

2) La versione del protocollo SSH utilizzata dal firewall (ovvero la 1.5).

Un modo per visualizzare il fingerprint del PIX 501 però esiste, e si basa su nmap:

nightfly@nightbox:~$ sudo nmap -sS -A <IP PIX 501>

Starting Nmap 5.00 ( http://nmap.org ) at 2011-09-05 20:30 CEST
Interesting ports on *.*.*.*:
Not shown: 998 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      Cisco SSH 1.25 (protocol 1.5)
|_ ssh-hostkey: 1024 **:**:**:**:6f:62:05:dd:a6:3b:43:1f:**:**:**:** (RSA1)

Mistero svelato.

PS: i lameri che volessero fare dei tentativi di exploit verso la mia macchina (poichè l’SSH 1.5 è palesemente vulnerabile), sappiano che tale servizio non è pubblicato all’esterno ed accetta connessioni solo da determinati host della rete interna. Ergo abbandonate qualunque idea bellicosa.

A presto.

SSH: autenticazione mediante scambio delle chiavi

Il protocollo SSH (acronimo si Secure SHell), viene utilizzato per stabilire una connessione cifrata con determinati host, in modo da ottenere accesso alla loro interfaccia a linea di comando (CLI).

Ora, l’accesso vero e proprio alla macchina remota può evvenire seguendo diverse strade, ad esempio mediante l’inserimento di opportune credenziali di accesso (username e password) oppure mediante uno scambio di chiavi (pubbliche). Quest’ultima modalità di accesso risulta estremamente utile quando un determinato host deve connettersi via SSH ad un altro in modo automatizzato (ad esempio attraverso un cronjob schedulato). Un caso molto diffuso riguarda l’upload via SCP dei log relativi ai vari dispositivi di rete direttamente sul logserver.

Vediamo ora come predisporre i nostri dispositivi per lo scambio automatico delle chiavi. Per prima cosa occorre generare, su ciascun host, una coppia di chiavi pubblica/privata (RSA a 2048 bit). E’ possibile fare ciò mediante il comando:

nightfly@nightbox:~$ ssh-keygen

Durante la procedura di generazione delle chiavi è buona norma utilizzare una passphrase non vuota. Essa verrà adoperata per criptare la nostra chiave privata.

In particolare, la chiave pubblica verrà salvata all’interno del file id_rsa.pub nella direcotory nascosta .ssh presente nella home del nostro utente.

A questo punto connettiamoci all’host remoto via SSH in modo da aggiungere il suo fingerprint all’interno dei file known_hosts, anch’esso posizionato nella dir .ssh. Tale procedura si rende necessaria in quanto SSH prevede l’identificazione dell’host remoto e l’aggiunta esplicita (mediante popup di conferma) del suo fingerprint tra gli host fidati.

Una volta identificato l’host remoto occorre generare una coppia di chiavi anche su di esso. Il comando è del tutto identico a quello utilizzato sul notro PC.

Ora possiamo procedere con copia/incolla della nostra chiave pubblica sull’host remoto, salvandola all’interno del file authorized_keys, dopo averlo creato mediante il comando:

nightfly@nightbox:~/.ssh$ touch authorized_keys

e dopo avergli assegnato i permessi 600:

nightfly@nightbox:~/.ssh$ chmod 600 authorized_keys

Tale procedura va eseguita anche sul nostro PC, nel caso in cui dovesse essere il logserver ad effettuare una richiesta di connessione verso di noi. Ovviamente, in tal caso, all’interno del nostro file authorized_keys andrà copiata la chiave pubblica del server.

Attenzione: condizione necessaria affinchè tutto funzioni è che l’utente del nostro PC (che lancia la connessione SSH) e quello del logserver per il quale è stato definito il file authorized_key coincidano.

A presto.

PS: Grazie a Max per i prezioni suggerimenti.