Archivi tag: exim

Modificare l’MTA di default su CentOS 6

Ho già parlato più volte di exim, definendolo come uno degli MTA più performanti in circolazione.

Exim_logo.jpg

Essendo la mia formazione sui sitemi *nix derivata principalmente da Debian, preferisco usare il suddetto MTA piuttosto che postfix e qmail. Badate bene, però, che non sto facendo un paragone tra i software in questione: la mia è semplicemente una scelta di ordine pratico, ovvero preferisco avere a che fare con applicativi che già conosco perchè, in tal modo, posso ridurre notevolmente la percentuale di errori ed i tempi di troubleshooting.

Dopo questa breve premessa veniamo al dunque: da 3 anni a questa parte i server sotto la mia gestione sono principalmente dei CentOS/Red Hat, i quali si avvalgono di postfix come MTA di default.

Per sostituire postfix con exim occorre seguire questi step:

1) scaricare exim mediante il comando:

 [root@server exim]#  yum install exim

2) stoppare postfix e rimuoverlo dalla lista dei demoni da avviare al boot:

[root@server exim]#  service postfix stop 

[root@server exim]#  chkconfig –level 2345 postifx off

3) abilitare exim come MTA di default ed avviarlo:

[root@server exim]#  chkconfig –level 2345 exim on

[root@server exim]#  service exim start

A questo punto possiamo fare una prova di invio email. Per far ciò è sufficiente utilizzare il comando mail e dare un’occhiata al file di log associato ad exim, ovvero /var/log/exim/main.log.

Se effettivamente l’invio avviene mediante exim il suddetto file dovrebbe popolarsi di nuove entry. Nel caso in cui ciò non avvenga possiamo lanciare il comando:

[root@server exim]# alternatives –display mta

per visualizzare gli MTA disponibili e successivamente procedere con la scelta del Mail Transfer Agent da utilizzare:

[root@server exim]# alternatives –config mta

There are 2 programs which provide ‘mta’.

  Selection    Command
———————————————–
*+ 1           /usr/sbin/sendmail.postfix
   2           /usr/sbin/sendmail.exim

Enter to keep the current selection[+], or type selection number: 2

digitando semplicemente 2.

Tentiamo l’invio di una nuova email e tutto dovrebbe funzionare correttamente.

A presto.

Spam bot sui server Web

Scenario

Due server Web in produzione, SO *nix e framework Drupal.

Problema

Una tonnellata di email dirette agli indirizzi di posta elettronica più disparati.

Premessa

Riassumendo, è proprio questo il problema che si è verificato nei giorni scorsi su alcuni server che gestisco. Ora, affinchè lo spam bot possa funzionare è indispensabile che sulla macchina sia installato ed in esecuzione un MTA, magari senza autenticazione. Si, lo so, non prevedere alcun meccanismo di autenticazione per le email in uscita è altamente sconsigliato, ma dipende strettamente da quello che ci devi fare. Mi spiego: su quelle macchine le uniche email che devono essere inviate sono quelle generate da alcuni strumenti di monitoring, quali logwatch, rkhunter e compagnia bella. Ergo, in realtà, l’MTA non fa altro che appoggiarsi ad uno smarthost per l’inoltro della posta elettronica, fornito dall’hosting provider (ed il cui unico filtro è rappresentato dall’indirizzo IP sorgente). In soldoni, se la richiesta proviene da un IP appartenente al pool della LAN relativa all’hosting provider, la mail viene inviata, altrimenti nisba.

 

spambot.jpg

Detto ciò, è bene precisare che l’MTA attivo su quelle macchine è exim e non Postfix (per una semplice ragione di dimestichezza, ovvero conosco meglio il primo rispetto al secondo).

Soluzione

La prima cosa che ho notato listando il contenuto delle directory su cui sono ospitati i siti Web è stata la presenza di file tipici di WordPress, ad esempio wp-config.php. Si, esatto, questo spam bot è stato pensato per ambienti WP, come abbia fatto ad intrufolarsi in un framework Drupal devo ancora scoprirlo. Quello che so, però, è che si comporta sempre allo stesso modo: infetta il server, prende possesso dell’MTA ed invia email a più non posso.

Dunque, come potete facilmente immaginare, per arginare il problema ho impostato determinate ACL su exim, definendole in base all’indirizzo email di destinazione. Infatti, poichè le email di monitoring sono destinate esclusivamente a me ed al webmaster, è bastato inserire la seguente direttiva nel file di configurazione dell’MTA in questione:

accept  hosts = vostro.indirizzo1@email.it : vostro.indirizzo2@email.it

Per rendere effettive tali modifiche è stato necessario riavviare exim:

[root@bqweb2 ~]# service exim restart

Non conoscendo il baco che ha consentito al malware di infiltrarsi sui server, ho deciso anche di tirar su uno scrip bash che controllasse il contenuto delle dir target ed in caso di anomalie mi inviasse un’apposita email. In questo modo ho realizzato un sistema di sicurezza proattivo.

Ecco lo scrip:

#!/bin/bash

destinatario=vostro.indirizzo@email.it

cd /var/www/

grep -HR "wp-config.php" * > botcheck;

if [ -s botcheck ];then

cat botcheck | mail -iv -s "Server Bqweb2 Infected!" $destinatario;

fi

rm botcheck;

exit 0;

Esso non fa altro che andare alla ricerca del file wp-config.php. Se lo trova mi avvisa in modo tale da poter fare pulizia della directory.

Appena avrò maggiori info sul baco che ha consentito allo spam bot di infilarsi sulle mie macchine le pubblicherò.

Alla prossima.