Bologna, 24 novembre 2000 Unsolicited Bulk (UBE) (spamming) Francesco Gennai IAT - CNR

Presentazione sul tema: "Bologna, 24 novembre 2000 Unsolicited Bulk (UBE) (spamming) Francesco Gennai IAT - CNR"— Transcript della presentazione:

1 Bologna, 24 novembre 2000 Unsolicited Bulk Email (UBE) (spamming) Francesco Gennai IAT - CNR Francesco.Gennai@iat.cnr.it

2 Unsolicited Bulk Email (Spamming) UA = User Agent Originator = nodo che immette il messaggio in rete Relay = nodo di transito da Internet a Internet Delivery = nodo che consegna il messaggio allutente finale MS = Message Store (contiene le mailbox) MTA = Message Transfer Agent UA = User Agent Originator = nodo che immette il messaggio in rete Relay = nodo di transito da Internet a Internet Delivery = nodo che consegna il messaggio allutente finale MS = Message Store (contiene le mailbox) MTA = Message Transfer Agent MHS = Message Handling System UA UAUAMSMS SubmissionRelayDelivery Access RelayRelayDeliveryDeliveryOriginatorOriginator Relay MTA

3 Unsolicited Bulk Email (UBE) Meccanismi per controllare UBE tre categorie: Filtri Legali Economici

4 Filtri Euristici –controllo su origine messaggi –controllo su contenuto messaggio Cooperativi –etichettatura del messaggio –registro dei destinatari

5 Filtri Euristici controllo su origine messaggi Rifiuto connessioni IP da sorgenti UBE (UBE originator) Rifiuto sessioni TCP da sorgenti UBE (UBE originator) a livello di server SMTP Rifiuto messaggi SMTP da sorgenti UBE (UBE originator) in base al contenuto del comando MAIL FROM Rifiuto messaggi SMTP da sorgenti il cui dominio non corrisponde al proprio indirizzo IP

6 Rifiuto connessioni IP da sorgenti UBE (UBE originator)

7 Rifiuto sessioni TCP da sorgenti UBE (UBE originator) a livello di server SMTP

8 Rifiuto messaggi SMTP da sorgenti UBE (UBE originator) in base al contenuto del comando MAIL FROM

9 Rifiuto messaggi SMTP da sorgenti il cui dominio non corrisponde al proprio indirizzo IP

10 Filtri euristici controllo su contenuto messaggio A livello di message store (prima che lutente abbia scaricato i messaggi) A livello di mail client

11 A livello di message store

12 A livello di mail client

13 A livello di mail client (su precedente accettazione messaggi dallo stesso mittente)

14 Legali Legge –Controllo su mittente/destinatario –Controllo su relay Contratti –accordi tra provider ed utente

15 Economici Aumento dei costi di spedizione dei messaggi….. Introdurrebbe probabili limitazioni al servizio e-mail di Internet contrastando con alcuni dei modelli fondamentali che hanno consentito (e consentono) la diffusione di Internet

16 Identificazione Del messaggio –problemi nella scelta etichetta (Es. Commercial: è classificabile come commerciale un messaggio che ti invita a visitare un sito web ?) –associata con filtri attivi sul client di destinazione Del canale –porta diversa dalla 25 (SMTP) per traffico UBE –i provider potrebbere scegliere se offrire UBE ai propri clienti –tariffazione

17 Registrazione dei destinatari Registrazione presso le potenziali sorgenti di UBE –originatori di UBE poco onesti….. –troppe per pensare che un utente debba contattarle…. Registrazione in liste utilizzate da sorgenti di UBE –originatori di UBE poco onesti…. –stesso problema legato al numero elevato delle possibili liste presso cui doversi registrare

18 Utilizzo firma digitale Auteticazione End-to-End –permette il riconosimento immediato del mittente –difficilmente attuabile su larghissima scala Identificazione first-hop –autenticazione del MTA che ha accettato il messaggio da un proprio client –il provider ha il compito di garantire sullidentità del mittente (autenticazione SMTP)

19 Cosa fare quando si riceve UBE Si cancella e si continua a vivere tranquilli Si risponde al mittente (SCONSIGLIATO) Si riporta il problema ai nostri amministratori locali o direttamente ai siti che seguono questo tipo di problemi http://www.abuse.net Se il problema persiste si possono attivare filtri. (anche a livello server) SIEVE è un linguaggio per creare filtri in fase di standardizzazione IETF

20 Un cenno sul blocco relay Prevenire luso non autorizzato del proprio server di posta –differenziare sistemi locali da sistemi remoti semplice mediante controllo indirizzo IP –Messaggi provenienti da sistemi locali potranno essere indirizzati verso qualsiasi dominio Internet –Messaggi provenienti da sistemi remoti saranno accettati solo se destinati a domini gestiti dal server stesso o per i quali il server compare nella lista degli MX record.

21 Un cenno sul blocco relay (autenticazione SMTP) From: Marco.Verdi@qualcosa.it To: K.Newman@fnal.gov From: Mario.Rossi@qualcosa.it To: J.Smith@cuny.edu Firewall Email server Internet Terminal server Pc1Pc2Pcn qualcosa.it acme.it From: Luca.Bianchi@qualcosa.it To: S.Sting@fnal.gov From: S.Sting@fnal.gov To: Luca.Bianchi@qualcosa.it From: Marco.Verdi@qualcosa.it To: K.Newman@fnal.gov

22 Controllo via MAPS o ORBS Il server controlla se lindirizzo IP da cui proviene la connessione è listato in uno dei domini MAPS o ORBS. (Esempio: connessione da 147.48.67.98, il server SMTP fa una query a: 98.67.48.147.rbl.maps.com) Se la query ha successo: –rifiuta il messaggio –aggiunge un linea allheader (esempio: X-MAPS: messaggio sospetto ) e fa proseguire il messaggio verso la sua destinazione

23 Controllo via MAPS o ORBS Internet iat.cnr.it MX 10 mail.iat.cnr.it MX 20 mail.xx.cnr.it mail.iat.cnr.it mail.xx.cnr.it fw.qualcosa.edu = supporta controllo ORBS = NON supporta controllo ORBS Spammers utilizzano direttamente mail.xx.cnr.it !

24 Standard di base Posta elettronica Internet SMTP POP o IMAP File I/OSMTP Messaggio: RFC822 MIME UAUAUAUAMSMS... RelayDeliveryOriginator SMTP

25 UA SMTP OriginatorOriginator MTA Personal computer: Indirizzo IP Nome a dominio RFC822 From: To: CC: BCC: Subject: Mail From: Rcpt To: Server: Indirizzo IP Nome a dominio RelayRelay MTA A livello comunicazione SMTP: Nessun controllo su validità dellindirizzo From Lindirizzo To deve essere il valido indirizzo di destinazione Gli indirizzi IP sono validi per necessità di comunicazione tra i nodi di rete