Archivi tag: centos

Modificare l’encryption method delle password utente su CentOS

Premessa

In questo blog ho più volte parlato di digest, di algoritmi di cifratura one-way e compagnia bella. Una cosa è chiara: MD5 non è la scelta migliore da fare quando si parla di cifratura delle password. Infatti, la sua naturale evoluzione, ovvero SHA, presenta una maggiore robustezza (aka resistenza debole e forte alle collisioni), dovuta anche alle dimensioni del digest che genera. Proprio per questo motivo, sono solito abilitare sui miei server l’algoritmo SHA512 per la cifratura delle password utente.

sha, md5, one-way, sha512, passwd, shadow, digest, centos

SHA512 su CentOS

Sostituire MD5 con SHA512 su CentOS è sicuramente banale. Il primo step consiste nell’identificare il tipo di cifratura attualmente utilizzato dal nostro sistema:

[root@host ~]# authconfig --test | grep hashing

Se l’output è simile al seguente:

password hashing algorithm is md5

significa che stiamo utilizzando MD5. Per sostituirlo con SHA512 basta digitare (da utente root):

[root@host ~]# authconfig --passalgo=sha512 --update

L’ultimo step consiste nell’aggiornare le password degli utenti. In questo caso potete fare 2 scelte:

1) aggiornare voi le password degli utenti (se le conoscete);

2) richiedere all’utente l’aggiornamento delle password al prossimo login.

Nel primo caso è sufficiente lanciare il comando:

[root@host ~]# passwd <nomeutente>

mentre, per forzare il cambio password da parte dell’utente occorre digitare:

[root@host ~]# chage -d 0 <nomeutente>

Enjoy.

Mettere in ascolto snmpd su un’interfaccia specifica

Recentemente ho riscontrato diverse grane con il demone snmpd installato su una macchina CentoOS 5.

snmpLogo.jpg

Durante le operazioni di troubleshooting ho deciso di mettere in ascolto il demone in questione su una specifica interfaccia, avendo a che fare con un host dual-homed. Per la precisione, tale host presentava due interfacce di rete più una loopback, ovvero:

eth0 IP 10.0.0.1

eth1 IP 192.168.2.1

lo IP 127.0.0.1

Dove la eth1 è utilizzata per l’heartbeat del cluster.

Lanciando un netstat -ano | grep :161 ottenevo il seguente output:

udp        0      0 0.0.0.0:161                 0.0.0.0:*                               off (0.00/0/0)

Ciò significava che il demone stava in ascolto su tutte le interfacce. Ad ulteriore riprova di ciò lanciavo un snmpwalk -v2c -c publickey dapprima diretto verso l’IP dell’eth0, poi verso l’IP dell’eth1 ed infine verso l’IP della loopback. In tutti casi alla query era seguita una risposta.

Bene, decidevo quindi che l’snmpd doveva rimanere in ascolto solo sull’IP dell’eth0. Mi posizionavo dunque nella directory /etc/init.d ed accedevo al file snmpd mediante un editor di testo:

 [nightfly@linuxbox ~]# cd /etc/init.d
 [nightfly@linuxbox init.d]# nano snmpd

Nella fattispecie, la riga di mio interesse era la seguente:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid -a"

Che ho modificato nel seguente modo:

OPTIONS="-LS4d -Lf /dev/null -p /var/run/snmpd.pid 10.0.0.1 -a"

Successivamente, riavviavo il demone snmp mediante il comando:

[nightfly@linuxbox init.d]# service snmpd restart

e verificavo che fosse effettivamente attivo lanciando il comando:

[nightfly@linuxbox init.d]# service snmpd status

ottenendo come output:

snmpd (pid  2499) is running...

Tutto sembrava funzionare alla grande. Verificavo infine che il demone fosse in ascolto solo sull’indirizzo 10.0.0.1:

udp        0      10.0.0.1:161                 0.0.0.0:*                               off (0.00/0/0)


Con mio grande piacere constatavo che finalmente snmpd stava in ascolto su una sola interfaccia, eliminando il problema dei continui restart dello stesso.

A presto.

Postfix: configurazione minimale

Premesso che esistono tantissimi mail agent per i sistemi *nix, questa guida ha come scopo quello di illustrare una configurazione minimale (ma funzionale) di postfix su CentOS.

Per prima cosa è necessiario installare tale applicativo. Per semplicità utilizzeremo yum:

[nightfly@centosbox ~]# yum install postfix

Una volta completata l’installazione del pacchetto occorre passare alla sua configurazione. In particolare, vogliamo che postfix invii ad un server SMTP esterno (smarthost) il nostro messaggio di posta, il quale verrà successivamente recapitato sulla nostra mailbox (ad esempio @email.it).

A tal proposito, sarà necessario creare il file sender_canonical all’interno della dir /etc/postfix:

[nightfly@centosbox postfix]# touch sender_canonical

La sintassi da utilizzare all’interno di questo file è la seguente:

<nome utente> <indirizzo di posta da usare come mittente>

Ad esempio:

nightfly nightfly@miodominio.it

Ovviamente il nome del dominio deve essere valido, altrimenti il server SMTP esterno risponderà picche.

A questo punto lanciamo il comando:

[nightfly@centosbox postfix]# postfix sender_canonical

attraverso il quale postfix creerà un file sender_canonical.db da utilizzare per individuare l’indirizzo di posta del mittente in fase di invio.

Modifichiamo infine il file main.cf aggiungendo la seguente stringa:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Riavviamo postfix:

[nightfly@centosbox postfix]#service postfix restart

ed inviamo una mail di prova utilizzando il comando mail:

[nightfly@centosbox postfix]# mail vostroindirizzo@email.it

Diamo un’occhiata al file messages nella dir /var/log, magari utilizzando un | grep postfix:

[nightfly@centosbox postfix]#cat /var/log/messages | grep postfix

e se otteremo un output simile al seguente:

Oct 29 10:24:42 test-monitor postfix/smtp[7611]: 80FC8301F1: to=<indirizzo@email.it>, relay=mx.email.it[212.97.34.36]:25, delay=0.32, delays=0.07/0/0.04/0.22, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C4F714400C)

vuol dire che la nostra mail è stata inviata con successo.

See ya.