MISURE ANTI-MAIL-SPAM ====================== In queste pagine troverete le istruzioni per mettere in atto le misure tecniche attualmente possibili per limitare il problema del "mail spamming", ovverosia dell'utilizzazione di mailer SMTP da parte di utenti non autorizzati per ottenere l'invio di decine di migliaia di messaggi di e-mail, di solito contenenti messaggi non richiesti dai destinatari. Le prime misure da adottare consistono nel prevenire l'accesso al servizio SMTP (port 25 del tcp) su macchine non configurate o non sorvegliate da parte del mondo esterno, nonche' nel disabilitare il relay per conto terzi sui sendmail principali (i mailer di sezione) (ed ovviamente anche su ogni altra macchina che risulti possibile "proteggere" opportunamente. In particolare, per i mailer di sezione (BSD Sendmail UNIX e VMS-Sendmail) e' stata preparata una configurazione che proibisce il mail relay non autorizzato. Per i router Cisco (quelli di frontiera tra la vostra LAN ed il resto del mondo) vi diamo di seguito il filtro opportuno per rendere "invisibili" le macchine con servizio SMTP non opportunamente protetto. Per ogni ulteriore informazione, contattateci sulla lista mailing@infn.it ------------------------------------------------------------------------------- Configurazione del BSD Sendmail UNIX. Istruzioni per il filtraggio del relay. Sulla URL ftp://ftp.infn.it/pub/Network/mailing/unix/config Troverete i nuovi files: domain.m4 host.mc relay.mc sendmail.cR che permettono di bloccare sul sendmail il servizio di relay non autorizzato. Il relativo README e' qui di seguito: antispam.README --------------- I prototipi di file di configurazione presenti in questa directory (validi per la versione 8.8.8) permettono l'implementazione di un filtro che elimina la possibilita` di usare la macchina come mail relay a meno di non essere esplicitamente autorizzato. I domini autorizzati vengono listati nel file /etc/sendmail.cR (uno per riga). Tra i domini autorizzati, nel file di configurazione del mail relay ci saranno i domini di sua pertinenza, compresi eventuali domini per il quale funge da mailer di backup. Un esempio di file sendmail.cR XX.infn.it Xlungo.infn.it YY.infn.it Ylungo.infn.it sci.uniroma1.it dove XX e' la sigla del PROPRIO domini di sezione, Xlungo e' il nome lungo del proprio dominio di sezione (solo per la posta elettronica) (ad esempio MI.infn.it e Milano.infn.it). se fate da mailer secondario (se avete degli MX record che puntano verso il vostro mailer di sezione) anche la per la sezione YY (Ylungo), allora dovete inserire anche questi domini, e se fate da mailer secondario per un qualsiasi altro dominio (ad esempio per sci.uniroma1.it) allora dovete inserire anche quello. DI conseguenza la configurazione MINIMA di tale file contiene almeno XX.infn.it Xlungo.infn.it Si noti che in questo modo le connessioni pop remote sono autorizzate solo in lettura (previa digitazione della password); per poter inviare da sede remota mail tramite il proprio account, il pop client deve essere configurato in modo da usare come smtp server il mail relay locale. Questa protezione viene vanificata se un qualche host nel dominio non e` configurato in questo modo (passi o non passi per il mail relay in uscita). ------------------------------------------------------------------------------- Configurazione del VMS-Sendmail per impedire il relay non autorizzato: Il controllo del mail relay per VMS-Sendmail e' realizzato tramite il contenuto del file GV2$DIR:SMTP_RELAY.; Se tale file e' assente, oppure "vuoto", il relay viene autorizzato per qualsiasi tipo di mittente/destinatario, cioe' in pratica non viene applicata alcuna misuare anti-spam. Il file GV2$DIR:SMTP_RELAY.; per una tipica sezione va configurato cosi: (deve contenere TUTTI i domini, con wildcard e senza, che sono o vostri o per i quali fate relay) *.Xlungo.infn.it Xlungo.infn.it *.XX.infn.it XX.infn.it dove XX e' la sigla della vostra sezione/laboratorio e Xlungo e' il nome esteso della vostra sezione/laboratorio (esempio: MI.infn.it e Milano.infn.it). Il file GV2$DIR:SMTP_HOST_ALIASES.; invece deve contenere ANCHE le definizioni ^*.dominio dei vostri domini locali ^*.Xlungo.infn.it ^*.XX.infn.it Se il vostro mailer fa da relay anche per altri domini, ad esempio per univXY.it, non dimenticatevi di inserire anche questi nei due files indicati per permettere il relativo transito dei mail. Nel file di log GV2$DIR:GIVEME2_SMTP_IN.LOG troverete indicati sia ai casi di transito con successo (linee RECEIPT) che quelli di rigetto (linee REJECT), nonche' l'indicazione se il messaggio e' stato considerato di origine locale (loc) o remote (rem). ----------------------------------------------------------------------------- Configurazione del/dei Cisco di frontiera per impedire l'accesso dall'esterno alle macchine non sicure: Sui router Cisco e' possibile creare delle access list che selezionano per tipo di accesso e per tipo di protocollo e servizio richiesto. Le access-list di questo tipo sono nel range numerico 101 - 199, e l'esempio proposto utilizza la lista 101. Il software Cisco legge le access-list dall'alto verso il basso, fermandosi al primo match di condizione esatto che trova. Quindi bisogna porre attenzione nell'ordine in cui la lista viene scritta. In questo esempio, le sole macchine autorizzate a ricevere chiamate sulla porta 25 (SMTP) dall'esterno sono gli host 140.105.2.8 e 140.105.4.3, mentre tutti gli altri servizi di rete restano abilitati per tutti gli altri host della LAN (reti 140.105.2.0 e 140.105.4.0, con netmask 255.255.255.0) access-list 102 permit tcp any host 140.105.2.8 access-list 102 permit tcp any host 140.105.4.3 access-list 102 deny tcp any 140.105.2.0 0.0.0.255 eq smtp access-list 102 deny tcp any 140.105.4.0 0.0.0.255 eq smtp access-list 102 permit ip any any Una tale access-list va applicata alla interfaccia (ethernet o seriale) di ENTRATA verso la vostra LAN. In pratica se sulla vostra LAN si arriva tramite linea serial0, dovrete applicarla a serial0, se si arriva dal mondo esterno tramite etherne1, allora applicherete li la access-list. Esempio per entrata tramite serial0: interface serial0 description 2MB input line from XYZ ip address 140.105.234.1 255.255.255.0 ip access-group 102 in Una simile configurazione NON impedisce alle macchine interne di parlare SMTP tra di loro, e permette alle macchine interne di trasmettere direttamente posta elettronica a tutto il mondo esterno. Tuttavia impedisce al mondo esterno di accedere direttamente alla porta 25 (SMTP) delle macchine non autorizzate. Bisogna pertanto porre estrema attenzione in questo: infatti se esistono utenti che si fanno inviare e-mail con il nome diretto dell'host interno, allora bisogna fare in modo che gli host interni siano visibili tramite il mailer ufficiale di sezione dal mondo esterno. Questo si realizza o utilizzando una wildcard MX record per il dominio *.XX.infn.it IN MX 10 mailrelay.XX.infn.it. oppure indicando uno per uno gli host interni con record MX opportuni: host1.XX.infn.it IN MX 10 mailrelay.XX.infn.it. host2.XX.infn.it IN MX 10 mailrelay.XX.infn.it. host3.XX.infn.it IN MX 10 mailrelay.XX.infn.it. Il mailrelay.XX.infn.it va configurato in modo che sappia indirizzare in modo statico internamente i propri host. La configurazione "statica" e' diversa a seconda che si utilizzi VMS-Sendmail oppure BSD sendmail. Su VMS-Sendmail vanno inseire delle opportune entry statiche dentro GV2$DIR:SMTP_ROUTES.: del tipo: host1.XX.infn.it SMTP host1.XX.infn.it 25 host2.XX.infn.it SMTP host1.XX.infn.it 25 host3.XX.infn.it SMTP host1.XX.infn.it 25 Su BSD Sendmail il sistema si realizza invece con una configurazione "ad hoc" dentro il proprio DNS: per ciuscun host (host1, host2 e host3 nel nostro esempio) si inseriscono 2 MX record, il primo verso l'host stesso (che pero' e' irraggiungibile dal- l'esterno a causa del filtro sul router), ed il secondo a preferenza piu' bassa verso il mailer centrale "sicuro" (e raggiungibile anche dall'esterno: host1 IN MX 10 host1.XX.infn.it. host1 IN MX 20 mailrelay.XX.infn.it. host2 IN MX 10 host2.XX.infn.it. host2 IN MX 20 mailrelay.XX.infn.it. host3 IN MX 10 host3.XX.infn.it. host3 IN MX 20 mailrelay.XX.infn.it. Dall'esterno il primo MX fallisce bloccato dal cisco e viene utilizzato il secondo, dall'interno invece il mail server riesce a mandare direttamente a host. ------------------------------------------------------------------------------- ATTENZIONE: il filtraggio sul router e' una misura MOLTO sicura ma anche MOLTO RESTRITTIVA (e' un vero firewall!) per cui va utilizzato per ora per tamponare la situazione di emergenza, in attesa di sistemare in modo opportuno le macchine interne. Esso andra' utilizzato anche i futuro solo nei casi in cui la siatuazione di configurazione di macchine interne sia incontrolla- bile (ma in molti siti sara' necessario mantenerlo...) ------------------------------------------------------------------------------- Problemi con il "set forward" di VMS MAIL: Problema: se su un host "interno" di XX.infn.it che utilizza VMS un utente si inserisce il "Set Forward" di VMSMail verso un indirizzo esterno, il mailer centrale rifiuta il transito per ogni messaggio proveniente dall'esterno e diretto verso l'utente. Infatti il VMSMail conserva come mittente quello originale esterno, e sostituisce come destinatario l'indirizzo "esterno" indicato dal "set forward". Il risultato e' un messaggio dove sia mittente che destinatario sono "esterni" e quindi il mailer centrale lo rifiuta. In pratica il "set forward" invece di fare un forward fa un "bounce", che e' una azione del tutto diversa dal vero "forward". Il "bounce" (che mantiene mittente originale) e' una cosa incompatibile con qualsiasi filtering (sia anti-spam, che i piu' tradizionali firewall). Purtroppo, anche in linea teorica, non ci sono soluzioni per il bounce: il bounce non si puo' fare se c'e' un firewall o un filtro anti-spam. Se inveve il forward viene fatto da interfacce utente corrette (e non da VMSMail) i filtri anti-spam sono "inocui". Il problema e' quindi come impedire che gli utenti si settino il forward in modo sbagliato usando VMSMail (piu' in generale gli utenti dovrebbero proprio smettere di usare VMSMail perche' ha almeno un altra decina di gravi difetti ed errori di impostazione nel suo modo di "interpretare erroneamente" gli standard di mail). Possibili workaround: esaminare con procedura centralizzata i set forward degli utenti, ed eliminarli, sostituendoli con i VERI forward fatti a livello di aliases: Le procedura centralizzata va fatta girare periodicamente (una volta al giorno ad esempio). I set forward utente sono esaminabili da account privilegato con il comando: MAIL> show forward/user=* e poi sostituiti con il vero alias dentro smtp_aliases.db. In questo modo il mail NON arriva mai sulla macchina dove c'e' il set forward sballato di VMSMail, ma riparte direttamente dalla macchina mailer verso la destinazione finale. Per le macchine Unix il problema non c'e' perche' i files .forward modificano invece correttamene il mittente da remoto in locale. La procedura di "eliminazione" del set forward VMSMail e' la sola possibile soluzione.