Seguridad en sistemas_de_correo_electronico

Universidad de Deusto
Facultad de Ingenieria DESI – 2014/2015
. . . . . . . . .
Seguridad en sistemas de correo electrónico DESI - 2014/2015
Seguridad en sistemas deSeguridad en sistemas de
correo electrónicocorreo electrónico
Diploma de Especialización en Seguridad de la Información
2014/2015
Álvaro Marín Illera
alvaro@hostalia.com
alvaro.marin@acens.com

. . . . . . . . .
ContenidoContenido
Introducción/DNS
Protocolos de correo electrónico
Formato de mensajes: RFC822/MIME
Intercambio de mensajes: SMTP
Recogida de mensajes: POP3/IMAP4
Servidores de correo
Sendmail
Postfix
Exim
Qmail
MS Exchange/Open-Xchange/Zimbra
SPAM
¿Qué es el SPAM?

. . . . . . . . .
ContenidoContenido
Estadísticas/Botnets/Phishing/Legislación...
Medidas anti-SPAM
Restricciones a nivel de MTA
Realtime Blackhole Lists
SpamAssassin
Medidas avanzadas anti-SPAM
SPF, DomainKeys, DKim
Greylists
RateLimit/Tarpitting/GeoIP
Medidas anti-Virus
Antivirus a nivel de servidor
Pasarelas de correo
Amavis/MailScanner

. . . . . . . . .
1971: A partir del SNDMSG, Ray Tomlison usa
ARPANET para enviar el primer e-mail -> @servidor
1977: estándar para mensajes ARPANET: RFC733
1982: RFC 822 y RFC 821 : SMTP
1989: Primer intercambio comercial
1994: RFC 1725 : Post Office Protocol
2000: primeros programas anti-spam
2003: Alan Ralsky, “The king of spam”
2005...: Técnicas avanzadas de detección de spam
2008: Caso McColo
IntroducciónIntroducción

. . . . . . . . .
Características del correo electrónico:
- No requiere una presencia en ambos extremos
- Barato (~gratis), depende de la conexión utilizada
- Fácil de utilizar
- Permite movilidad
- Permite el envío de diferentes archivos adjuntos
- Diferentes usos: personal, profesional, público...etc
- Envío casi instantáneo
Es el servicio más utilizado en Internet.
Actualmente está en “peligro” debido a las amenazas (spam, virus...).
Las redes sociales le han quitado algo de tráfico también.
SMTP es un protocolo antiguo y que no está orientado a la seguridad.

. . . . . . . . .
Arquitectura básica:
- Agente de usuario (MUA)
Programas para leer/escribir mensajes
Ej: Thunderbird, Outlook...
- Agente de transferencia (MTA)
Transmite mensajes entre máquinas
Ej: Sendmail, Postfix, MS Exchange...
Estándares involucrados:
- Formato del mensaje: RFC822/MIME
- Resolución de nombres: DNS (MX o A en su defecto)
- Protocolo de envío de mensajes : SMTP/ESMTP
- Protocolo de recogida de mensajes: POP/IMAP

. . . . . . . . .
Introducción DNSIntroducción DNS
Los servicios de e-mail interactúan con servidores DNS de
forma continua, básicamente, para saber a dónde enviar (a
qué IP) el correo para un determinado destinatario.
Un servicio de correo necesitará por tanto saber:
- Registro A del dominio
- Registro MX del dominio
- PTR de la IP del cliente
- Otros registros (TXT, SPF...)
Es un servicio continuamente consultado por lo que el acceso
al servidor DNS deberá ser lo más rápido posible (tener una
caché local es lo idóneo).

. . . . . . . . .

. . . . . . . . .
El registro más importante relacionado con el correo es el
registro MX (el registro A del dominio será usado a falta de este).
Indica a dónde se debe enviar el correo para el dominio en
cuestión (obviamente, puede ser distinto al “www”).
El registro MX debe:
- ser un hostname FQDN (Fully Qualified Domain Name)
- nunca debe ser ni una IP ni un registro CNAME
- el hostname debe resolver correctamente su registro A
El registro MX puede:
- componerse de varias entradas
- tener prioridades para esas distintas entradas

. . . . . . . . .
$dig mx acens.com
acens.com. IN MX 10 mx.acens.com.
$dig a mx.acens.com
mx.acens.com. IN A 217.116.0.227
$dig mx hotmail.com
hotmail.com. IN MX 5 mx4.hotmail.com.
$dig mx gmail.com
gmail.com. IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. IN MX 5 gmail-smtp-in.l.google.com.

. . . . . . . . .
Otros registros importantes relacionados con el e-mail son:
- Registro TXT: usado para SPF, DKIM...y otras infos,
como cómo deslistarse de un rechazo por lista
negra (RBL).
- Registro PTR: registro inverso, apunta a un hostname
Es conveniente que dicho hostname apunte
también a dicha IP (rechazos SMTP):
$ dig -x 82.194.66.207 +short
relay07.dns-servicios.com.
$ dig a relay07.dns-servicios.com. +short
82.194.66.207

. . . . . . . . .
Introducción RFCsIntroducción RFCs
Resumen de RFCs involucrados:
- Formato de los mensajes
- RFC 822
- RFC 2045 - MIME
- Cómo enviamos los mensajes
- RFC 821: SMTP
- RFC 1869: ESMTP | RFC 4954: Ext AUTH
- RFC 2487: SMTP bajo TLS
- Cómo recogemos los mensajes
- RFC 1939: POP3
- RFC 3501: IMAP4
- RFC 2595: POP3 e IMAP4 bajo TLS

. . . . . . . . .
RFC 822RFC 822
RFC 822: Formato estándar de mensajes de texto en Internet
Formato del mensaje completo:
- Cabeceras:
Formato: Nombre-cabecera: valor <CR><LF>
Generadas por MUAs o MTAs
Orden aleatorio
En NVT ASCII
- Cuerpo del mensaje:
En NVT ASCII
Solo texto (para otros contenidos, ver ext. MIME)
Máximo 1000 caracteres/línea
Ejemplo:

. . . . . . . . .
RFC 822RFC 822
Return-Path: <split@splitcc.net>
X-Original-To: alvaro@hostalia.com
Delivered-To: alvaro@hostalia.com
Received: from mail.splitcc.net (169.Red-80-25-85.staticIP.rima-
tde.net [80.25.85.169])
by mail.hostalia.com (Postfix) with ESMTP id C868668031B
for <alvaro@hostalia.com>; Sat, 21 Jan 2006 14:16:44 +0100
(CET)
Received: by mail.splitcc.net (Postfix, from userid 1003)
id 2635D1337D; Sat, 21 Jan 2006 14:16:40 +0100 (CET)
Date: Sat, 21 Jan 2006 14:16:38 +0100
From: Alvaro Marin <split@splitcc.net>
To: alvaro@hostalia.com
Subject: Prueba mensaje
Message-ID: <20060121141638.50de4e31@basajaun>
Mensaje de prueba

. . . . . . . . .
MIMEMIME
MIME: Multi-Purpose Internet Mail Extensions - RFC 2045
Solventa los problemas de RFC 822:
- Solo admite NVT ASCII
- Lenguas latinas (ñ, á...)
- Lenguas no latinas (hebreo, ruso, chino...)
- Imágenes, sonido, vídeo...
Define 5 nuevas cabeceras:
- MIME-Version: debe estar presente para que el
mensaje sea tratado como MIME. Actualmente 1.0.
- Content-type: cómo interpretar un objeto del cuerpo
del mensaje (text/plain; charset=us-ascii).
- Content-Transfer-Encoding: cómo está codificado el
objeto (por defecto 7bits (NVT ASCII)).
- Content-Description: descripción del objeto.
- Content-Id: valor único identificativo del objeto.

. . . . . . . . .
MIMEMIME
Tipos predefinidos para Content-type (type/subtype; parameter=value):
- text/plain : texto plano
text/plain; charset=us-ascii (por defecto)
text/plain; charset=iso-8859-X
- text/html : texto html
- multipart: cuando el mensaje tiene varias partes
- image: el cuerpo es una imagen (image/jpeg, image/gif...)
- video: el cuerpo es un vídeo (video/mpeg...)
Opciones para Content-Transfer-Encoding:
- 7-bit: NVT ASCII (línea < 1000)
- 8-bit: NVT ASCII + otros caractares (línea < 1000)
- quoted-printable: textos con pocos caracteres no NVT ASCII
(por ejemplo, mensajes en castellano)
- base64: codifica datos binarios (aumenta de tamaño)

. . . . . . . . .
MIMEMIME
Mensaje en castellano:
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Mensaje multiparte:
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary=Multipart_Sat__21_Jan_2006_15_38_40_+0100_6v7h2cun_NTQHy9L
--Multipart_Sat__21_Jan_2006_15_38_40_+0100_6v7h2cun_NTQHy9L
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
prueba jpg
--Multipart_Sat__21_Jan_2006_15_38_40_+0100_6v7h2cun_NTQHy9L
Content-Type: image/jpeg; name=prueba.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=prueba.jpg
/9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKgAAAA...
--Multipart_Sat__21_Jan_2006_15_38_40_+0100_6v7h2cun_NTQHy9L--

. . . . . . . . .
UNICODEUNICODE
Unicode es un estándar de codificación de caracteres (>100mil).
Se codifica de 3 formas distintas, que transforman el código de
mapa Unicode en una secuencia de bits:
- UTF-8 : longitud variable, de 1 a 4 bytes
- UTF-16: longitud variable, 2 o 4 bytes
- UTF-32: código de 32 bits
El más usado es UTF-8:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

. . . . . . . . .
RFC 821RFC 821
RFC 821: SMTP, Simple Mail Transfer Protocol
Protocolo estándar para enviar mensajes:
MUA → MTA
MTA ↔ MTA
Data de 1984, antiguo y simple => inseguro
Usa DNS continuamente:
- Resolver el registro MX del registro destinatario
- Resolver el registro A del resultado anterior
- Resoluciones inversas
Usa el puerto TCP:
- 25: SMTP

. . . . . . . . .
RFC 821RFC 821
Algunos comandos (NVT ASCII) del protocolo SMTP:
- HELO: “saludo” inicial en el que el cliente indica quién
es (su dominio o hostname o IP). Se podría
traducir como : “Hello, I am <domain>”.
- MAIL FROM: indica quién es el que envía. Por ejemplo:
MAIL FROM: alvaro@hostalia.com
- RCPT TO: indica la dirección del destinatario. Por ej:
RCPT TO: alvaro@rigel.deusto.es
- DATA: punto de comienzo en el que se empezará a
enviar el cuerpo del mensaje. Acabará con una
línea con un “.”.
- QUIT: cierra la conexión
Ejemplo:

. . . . . . . . .
RFC 821RFC 821
$telnet mail.splitcc.net 25
Trying 80.25.85.169...
Connected to 80.25.85.169.
Escape character is '^]'.
220 mail.splitcc.net ESMTP ready
HELO mail.hostalia.com
250 mail.splitcc.net
MAIL FROM: alvaro@hostalia.com
250 Ok
RCPT TO: split@splitcc.net
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Este es un mensaje de prueba para el Master.
.
250 Ok: queued as CF52B1337C
QUIT
221 Bye
Connection closed by foreign host.

. . . . . . . . .
RFC 821RFC 821
Algunas respuestas ante comandos SMTP:
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path>
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
500 Syntax error, command unrecognized
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
2XX/3XX=> successful 4XX=>temporary errors 5XX=>permanent errors

. . . . . . . . .
RFC 821RFC 821
MAIL FROM: Origen del mensaje.
RCPT TO: Destinatario del mensaje.
No confundir con cabeceras “From:” y “To:” de la sección DATA.
$telnet mail.splitcc.net 25
Trying 80.25.85.169...
220 mail.splitcc.net ESMTP ready
helo mail.hostalia.com
250 mail.splitcc.net
mail from: alvaro@hostalia.com <- ENVELOPE SENDER
250 Ok
rcpt to: split@splitcc.net <- ENVELOPE RECIPIENT
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Asunto del mensaje
From: fromenelMUA@dominio.com <- FROM SECCIÓN DATA
To: toenelMUA@dominio.com <- TO SECCIÓN DATA
Este es un mensaje de prueba para el Master.
.
250 Ok: queued as CF52B1337C
quit
221 Bye
Connection closed by foreign host.

. . . . . . . . .
RFC 821RFC 821
Ejemplo: envío un mensaje con mi MUA poniendo:
To: alvaro@rigel.deusto.es, split@splitcc.net
El MUA conectará con el MTA y enviará los siguientes comandos:
El MTA preguntará por el MX de rigel.deusto.es y se conectará a él; en el
momento de introducir el RCPT pondrá:
Seguidamente preguntará por el MX de splitcc.net, se conectará a él y
pondrá:
Ambos desinatarios tendrán como cabecera “To:” la original que puso el
MUA, pero la cabecera RCPT TO será diferente (Delivered-To).

. . . . . . . . .
Protocolo SMTPProtocolo SMTP
SMTP SMTP
PC-Cliente
Servidor
Cliente
Servidor
Destino
To: user@master.com
mail.master.com
El mensaje es
depositado en el
buzón del usuario
destinatario

. . . . . . . . .
DNS “.”
Protocolo SMTP+DNSProtocolo SMTP+DNS
SMTP SMTP
PC-Cliente
Servidor
Cliente
Servidor Destino
DNS MTA-Cliente
DNS
DNS “com.”
DNS “master.com.”
mail.master.com
To: user@master.com
mail.master.com
¿MX?
DNS “.”
DNS “com.”
DNS “master.com.”
¿mail.master.com?
IP
DNS

. . . . . . . . .
Protocolo ESMTPProtocolo ESMTP
Protocolo ESMTP, RFC 1869 (a partir del 1425 y 1651)
Extensión del protocolo SMTP anterior para mostrar extensiones
soportadas (autenticación, cifrado...).
El cliente deberá usar el nuevo comando “EHLO” en vez del “HELO”
habitual. Compatibilidad “hacia atrás”.
El servidor responde con los comandos/extensiones ESMTP que soporta:
$ telnet mail.hostalia.com 25
...
220 mail.hostalia.com ESMTP
EHLO cliente.dominio
250-mail.hostalia.com
250-PIPELINING
250-SIZE 102400000
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

. . . . . . . . .
Autenticación SMTPAutenticación SMTP
Extensión SMTP que permite la autenticación (RFC 4954)
¿AUTENTICACIÓN? cliente da credenciales antes de enviar
¿Para qué la queremos/necesitamos?
Los servidores SMTP permitirán correo hacia los
dominios que tengan configurados como propios.
Si queremos poder enviar a otros dominios (hacer relay)
- Especificar IPs a las cuales queremos permitir
- Determinados usuarios → autenticación SMTP
Si lo dejamos abierto...OPEN RELAY

. . . . . . . . .
Bounces y DSNBounces y DSN
El protocolo SMTP establece que si el servidor remoto tiene
problemas al entregar un mensaje, se genere un bounce (<>) en
base a la cabecera Return-Path.
Delivery Status Notification, RFC 1891 (y otros), extensión para
SMTP, que da soporte para otras notificaciones (no solo fallos).
En el RCPT, con 2 posibles parámetros:
- NOTIFY (SUCCESS,FAILURE,DELAY)
- ORCPT indica la dirección del RCPT original (por si FW)
En el MAIL FROM otros 2 posibles parámetros:
- RET (FULL,HDRS) para indicar qué devolver
- ENVID identificador “Original-Envelope-Id”

. . . . . . . . .
No confundir con Message Disposition Notification (RFC 3798) y su
cabecera Disposition-Notification-To (MUA).
Ejemplo DSN:
# telnet relay02.dns-servicios.com 25
220 relay02.dns-servicios.com ESMTP
ehlo mail
250-relay02.dns-servicios.com
...
250 DSN
mail from: alvaro@hostalia.com RET=HDRS ENVID=MASTER
250 2.1.0 Ok
rcpt to: alvaro@splitcc.net NOTIFY=SUCCESS,FAILURE
250 2.1.5 Ok

. . . . . . . . .
This is the mail system at host hostalia.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
The mail system
<cuentaquenoexiste1234@hotmail.com>: host mx4.hotmail.com[65.55.92.184] said:
550 Requested action not taken: mailbox unavailable (in reply to RCPT TO
Command)
Reporting-MTA: dns; hostalia.com
X-Postfix-Queue-ID: F23E01550129
X-Postfix-Sender: rfc822; alvaro@hostalia.com
Arrival-Date: Fri, 14 Feb 2014 16:05:13 +0100 (CET)
Final-Recipient: rfc822; cuentaquenoexiste1234@hotmail.com
Original-Recipient: rfc822;cuentaquenoexiste1234@hotmail.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx4.hotmail.com
Diagnostic-Code: smtp; 550 Requested action not taken: mailbox unavailable

. . . . . . . . .
Cabeceras SMTPCabeceras SMTP
Las más importantes y que más información pueden dar:
- Cabecera Received : es añadida por cada MTA por el que el
mensaje pasa. Nos permite saber la ruta de un mensaje,
tiempo que ha sido retenido en cada MTA...
- Cabecera Return-Path: la genera el MDA final indicando cuál es
el emisor real del mensaje, a partir del MAIL FROM. Es
usada cuando hay que generar un bounce.
- Cabecera Reply-To: la dirección a la que responder o enviar las
respuestas. Es añadido por el emisor. Muy común en
listas de correo, en las que quien escribe es distinto a
quien hay que responder (la lista).
- Cabecera Delivered-To : dirección a la que realmente es
entregado el mensaje (sin alias).

. . . . . . . . .
Cabeceras completasCabeceras completas
Return-Path: <alvaro@hostalia.com>
Delivered-To: 1almarin@rigel.deusto.es
Received: from mail.hostalia.com (ws.hostalia.com [82.194.64.2])
by gr-1.deusto.es (Postfix) with ESMTP id 1CD1724B56D
for <alvaro@rigel.deusto.es>; Sat, 20 Jan 2007 11:31:47 +0100 (CET)
Received: from basajaun (169.Red-80-25-85.staticIP.rima-tde.net [80.25.85.169])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.hostalia.com (Postfix) with ESMTP id 3CDA06807DF
for <alvaro@rigel.deusto.es>; Sat, 20 Jan 2007 11:31:45 +0100 (CET)
Date: Sat, 20 Jan 2007 11:31:44 +0100
From: Alvaro Marin <alvaro@hostalia.com>
To: alvaro@rigel.deusto.es
Subject: Prueba
X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by amavis at mail.deusto.es

. . . . . . . . .
SSL over SMTPSSL over SMTP
SSMTP se usa(ba) como medida de seguridad para enviar
mensajes SMTP (e info de autenticación) de forma cifrada.
Se habilita el puerto TCP:465 en el servidor que espera
conexiones sobre SSL. Toda la comunicación es bajo SSL, sin
opción alguna. Usado para comunicación cliente → servidor.
Nunca ha sido RFC, es un puerto “reservado” por la IANA para
ello en el draft de SSLv3 (SSL tampoco ha sido nunca RFC,
empezó con TLSv1 en el RFC 2246).
Por ejemplo:
openssl s_client -connect smtp.gmail.com:465

. . . . . . . . .
RFC 2487 - 3207RFC 2487 - 3207
RFC 2487: soporte de TLS para SMTP (Enero 1999)
Especifica la extensión TLS para el servicio SMTP a través del
comando STARTTLS, al que el servidor debe responder con:
220 Ready to start TLS
501 Syntax error (no parameters allowed)
454 TLS not available due to temporary reason
Si se recibe el 220, el cliente debe comenzar la negociación TLS
antes de introducir más comandos.
openssl s_client -starttls smtp -connect smtp.gmail.com:25
RFC 3207: actualización de Febrero 2002 al RFC 2487 =>
hace referencias al RFC 2476, Submission Port

. . . . . . . . .
RFC 2476RFC 2476
RFC 2476: Message Submission, 1998
Protocolo para enviar mensajes: MUA → MTA
Se basa en el uso del puerto 587 en vez del habitual 25.
Requiere cambiar la configuración del cliente de correo.
Propone la autenticación y cifrado (a través de TLS) para
envíos por este puerto.
Usando esto, tenemos:
- Podemos aplicar diferentes políticas 25 Vs 587
- Protección ante malware
- ISPs de conectividad pueden filtrar TCP:25

. . . . . . . . .
Protocolos de recogidaProtocolos de recogida
Protocolos de recepción de correo almacenado en el servidor.
SMTP SMTP
PC-Cliente
Servidor
Cliente
Servidor
Destino
To: user@master.com
PC-Receptor
POP/IMAP

. . . . . . . . .
Protocolo POP3Protocolo POP3
Protocolo POP3, RFC 1939.
Accede al buzón del usuario y se descarga los mensajes.
Usa TCP:110 y TCP:995 para POP3S (RFC 2595).
Protocolo simple: 13 comandos con respuestas +OK o -ERR.
$telnet servidor 110
...
+OK Hello there.
user alvaro <- usuario
+OK Password required.
Pass ********** <- contraseña
+OK logged in.
list <- listar mensajes del buzón
+OK POP3 clients that break here, they violate STD53.
1 1406
2 1594
.
top 1 10 <- 10 primeras líneas del mensaje 1
retr 1 <- ver todo el mensaje 1
dele 1 <- borrar el mensaje 1
quit <- efectuar cambios y salir

. . . . . . . . .
Protocolo IMAP4Protocolo IMAP4
Protocolo IMAP4, RFC 3501.
Más sofisticado y con más opciones que POP3.
Se accede directamente al buzón del servidor donde el usuario puede
crear/borrar directorios, mover mensajes...etc.
Usa los puertos TCP:143 y TCP:993 para IMAP4S (RFC 2595).
$ telnet 192.168.1.10 143
Trying 192.168.1.10...
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2004
Double Precision, Inc. See COPYING for distribution information.
1 CAPABILITY
* CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION
1 OK CAPABILITY completed
2 LOGIN split password
2 OK LOGIN Ok.
NAMESPACE
NAMESPACE NO Error in IMAP command received by server.
3 NAMESPACE
* NAMESPACE (("INBOX." ".")) NIL (("#shared." ".")("shared." "."))
3 OK NAMESPACE completed.

. . . . . . . . .
MTAsMTAs
Existen muchos programas que implementan las funciones que
debe realizar un MTA.
Las características que más se suelen valorar son:
- Capacidad de tratar correo concurrentemente
- Velocidad de entrega local/remota
- Extensibilidad y funciones implementadas
- Estabilidad
- Tratamiento de la cola
Entre los más conocidos se encuentran:
- Sendmail
- Postfix
- Exim
- Qmail
- MS Exchange

. . . . . . . . .
MTAs - SendmailMTAs - Sendmail
Sendmail es uno de los MTAs más viejos que existen.
Implementado para los UNIX existentes en su época.
Al ser el más antiguo, dispone también de una larga lista de
vulnerabilidades en el pasado que le han dado una fama de
“inseguro”, aunque actualmente no sea así.
Muy configurable pero a la vez, muy complejo de configurar.
Versión actual: 8.14.9
Creador: Eric Allman
Página: www.sendmail.org

. . . . . . . . .
MTAs - PostfixMTAs - Postfix
Postfix aparece como alternativa a Sendmail, dando una mayor
facilidad de instalación/configuración.
Dispone de los comandos que disponía Sendmail.
Muy extensible y adaptable (LDAP,MySQL,SASL,TLS...)
Desarrollo muy activo. Arquitectura modular. Gran comunidad.
Centrado en la rapidez y la seguridad.
Versión estable: 2.11.3
Versión desarrollo: 2.12
Creador: Wietse Venema
Página: www.postfix.org

. . . . . . . . .
MTAs – EximMTAs – Exim
Exim es un MTA creado en la Universidad de Cambridge.
No tiene tanta fama como los anteriores, pero también es
ampliamente usado.
Dispone de bastantes ventajas sobre otros MTAs:
- Capaz de hacer llamadas a Perl (creación de funciones propias)
- Herramientas y comandos muy potentes:
- exim -Mrm ID
- exim -M ID
- exim -Mvh ID
- exim -Mvb ID
- exiqgrep patrón
- exigrep patrón
Su última versión es la 4.82 (www.exim.org).

. . . . . . . . .
Qmail es un MTA creado por D.J. Bernstein (djbdns).
Su licencia no permitía la distribución de binarios, por lo que
había que compilar siempre su código fuente (hasta Nov 2007).
Nuevas funcionalidades => parchear código y compilar.
Por defecto, por ejemplo, falta soporte para cosas como DSN.
Difícil de configurar, en varios archivos.
Su última versión es la 1.0.6 (www.qmail.org)
MTAs – QmailMTAs – Qmail

. . . . . . . . .
MTAs + suites colaborativasMTAs + suites colaborativas
Microsoft Exchange es un “MTA” que incorpora otras
funcionalidades adicionales como buzones compartidos, agendas,
libretas de direcciones, conectividad móvil...etc.
Utiliza el protocolo MAPI para comunicarse con los clientes.
Configuración limitada en comprobaciones SMTP/DNS y sistema
antispam.
Integración completa con el Directorio Activo y por tanto, con toda
la infraestructura Microsoft de la organización.
Webmail integrado muy potente, OWA.

. . . . . . . . .
Open-Xchange nace como alternativa a MS Exchange.
Empresas como 1&1 lo usan y lo apoyan.
Dispone de partes que son software libre y otras que son
cerradas.
Servicios a añadir a infraestructura existente.
Soporte para:
- Webmail AJAX
- Calendario, agendas de contactos, tareas...compartidas
- Carpetas públicas/privadas para documentos
- Conectividad con redes sociales
- Importación de contactos desde FB o Linkedin
- Acceso a otros buzones
- Soporte para acceso móvil

. . . . . . . . .
Zimbra es una suite colaborativa perteneciente a Telligent
(antes, de VMWare y antes de Yahoo).
Dispone de partes de código libre y otras de código cerrado.
Soporte para lo comentado con Open-Xchange y además, chat
entre contactos, wiki compartido...etc.
Dispone de los llamados zimlets, especie de plugins para
aumentar las funcionalidades (VoIP, integraciones...).
El producto dispone de componentes como Postfix, ClamAV,
SpamAssassin, MySQL, Courier...etc.

. . . . . . . . .
MTAsMTAs
Configuraciones típicas:
- Gateway de entrada (relay)
- Gateway de salida (relayhost)
- Balanceo carga
INTERNET
relay
MTA interno
INTERNET
MTA externo
LAN
relayhost
INTERNET
LAN

. . . . . . . . .
SPAMSPAM
Mensajes de correo comerciales no solicitados.
El origen de éstos suelen ser servidores de correo mal
configurados, gusanos, CGIs no protegidos...etc.
Supone una gran amenaza para la continuidad y eficacia del
correo electrónico ya que puede llegar a colapsar los MTAs.
Se invierte mucho dinero en intentar frenarlo.
Las últimas cifras hablan que +90% de los e-mails son spam.

. . . . . . . . .
SPAMSPAM
¿Porqué se envía spam? => se vende a través de él y es un
buen negocio para el emisor (muy barato).
Cómo se envía el spam:
- Falsificando los From de los correos
- Recogiendo los destinatarios de webs, news...etc.
- Usando servidores mal configurados
- Usando ordenadores “zombies” =>filtrado puerto SMTP
- Por medio de ataques a CGIs, PHPs, ASPs...
- Inyección de código en formularios web
- ...
El SPAM en estadísticas:

. . . . . . . . .
SPAMSPAM
------------
SMTP connections: 30259950
Procesados: 532959
NOQUEUE+Procesados: 43137157
Clean mail: 238992 - 0.55%
Marked(delivered) mail: 56983 - 0.13%
Spam(deleted) mail: 236984 - 0.55%
Backscatter: 36242
NOQUEUE RBL-SpamCop: 2041236 - 4.73%
NOQUEUE RBL-SpamHaus: 604147 - 1.40%
NOQUEUE RBL-DnsSrv: 755893 - 1.75%
NOQUEUE RBL-CTIPD: 37487187 - 86.90%
NOQUEUE RBL-CTIPD-BLACK: 34566853 - 80.13%
NOQUEUE RBL-CTIPD-GREY: 2920334 - 6.77%
NOQUEUE Greylisted: 830483 - 1.93%
(autowhitelisted: 5284)
NOQUEUE RBL-PBL: 52005 - 0.12%
NOQUEUE PTR: 29889 - 0.07%
Rate Limit: 619073 - 1.44%
NOQUEUE HostRejected: 56199 - 0.13%
NOQUEUE DomainNotFound: 112624 - 0.26%
NOQUEUE FQDN: 682 - 0.00%
NOQUEUE RcptRejected: 141 - 0.00%
NOQUEUE MalformedDNS: 131 - 0.00%
NOQUEUE RelayDenied: 14508 - 0.03%
------------

. . . . . . . . .
SPAMSPAM

. . . . . . . . .
SPAMSPAM
Fuente: Microsoft 1H2013

. . . . . . . . .
SPAMSPAM
Países habituales emisores de spam:
- USA
- China
- Rusia
- UK
- Ucrania
- Japón
- Brasil
- Francia
- India
- Italia
SpamHaus proporciona estadísticas al respecto:
http://www.spamhaus.org/statistics/countries.lasso
http://www.spamhaus.org/statistics/spammers.lasso

. . . . . . . . .
SPAM-BotnetsSPAM-Botnets
El principal problema actual del spam son las BOTNETs.
Un bot es un tipo de malware que permite el control total del
ordenador donde está instalado (zoombie).
Una botnet es un conjunto de bots controlado de forma
centralizada.
Objetivos:
- Envío de spam
- DDoS
- Hosting de phishing
- Robo de credenciales (bancarias...)

. . . . . . . . .
PhishingPhishing
Uno de los objetivos de las botnets es la propagación de phishing.
El phishing usa la ingeniería social para conseguir credenciales de
usuarios de forma fraudulenta (acceso a bancos, por ej.).
Al usuario le llega vía e-mail una URL que dice ir al sitio “oficial”
pero va a otro: http://www.banco.com@members.tripod.com/
También vía keyloggers, man-in-the-middle...etc.
Fuente: Microsoft 1H212

. . . . . . . . .
PhishingPhishing
www.antiphishing.org
Prevenir:
- Desde el lado del ISP => evitar entregar correos de phishing
- Desde el usuario => educación
http://wombatsecurity.com/antiphishing_phil/index.html

. . . . . . . . .
Ejemplos de botnets (nombre,bots,spam generado):
- Conficker 10,000,000+ 10 billion/day
- Kraken 495,000 9 billion/day
- Srizbi 450,000 60 billion/day
- Bobax 185,000 9 billion/day
- Rustock 150,000 30 billion/day
El spam creado por servidores mal configurados, scripts de
envío...etc es mínimo comparado al recibido desde las botnets.
Las botnets disponen de un servidor “Command & Control” a los
que los bots tienen acceso vía IRC y que el creador puede
controlar.
También existen métodos de control vía HTTP, p2p...

. . . . . . . . .
Fuente: Microsoft, Top 10 bot families detected by MS anti-malware tools

. . . . . . . . .
Fuente: MS 1H2012

. . . . . . . . .
Srizbi (Jun 2007) fue una de las botnets más importantes.
Tiene como base, Reactor Mailer:

. . . . . . . . .
El “worker” es el trojano que lleva su propio nombre, Srizbi.
- Infecta máquinas Windows (driver de dispositivo)
- Pila TCP propia para evitar firewalls y monitorizaciones
“Reactor Mailer” dispone una web con la que se pueden crear on-line
los mensajes de spam con soporte para plantillas, GD...etc.
Detección de Srizbi:
- Tráfico hacia 208.72.168.0/23, HTTP sobre TCP:4099 (AOL)
- GET y POST contienen bot-serials únicos
GET /g/[14 digs bot-serial]-[4 dígs del bot-version]
- Ya existen reglas en SpamAssassin
- Cabecera Message-ID siempre empieza por 000
- Diferencia entre versiones de OE en el mensaje
- Hora siempre a UTC +000
- Diferencias en HELO, cmds SMTP...etc entre OE y Srizbi
- La pila TCP/IP tiene un fingerprint único

. . . . . . . . .
Srizbi tenía muchos de sus servidores Command&Control en un
direccionamiento IP de un ISP llamado McColo (USA).
En Noviembre de 2008 el resto de ISPs dejan de hacer peering
con McColo por lo que queda “desconectado”de Internet.
Posteriormente Srizbi migra sus C&C a Estonia hasta que
Microsoft incluye Srizbi en su herramienta de borrado de
malware (Feb 2009), empezando ya a desaparecer.

. . . . . . . . .
RBN (Russian Business Network) es una organización del
“cibercrimen” de origen ruso (San Petersburgo, 2006). Dividida
en muchas suborganizaciones con diferentes ASNs.
Este ISP es otro conocido en el mundo de Internet, según
SpamHaus, el que alberga más contenidos ilegales del mundo.
Alberga sitios de malware, phishing, pornografía infantil...etc.
Son los creadores de software como Mpack, completos “kits de
malware”.
Se le atribuye la botnet Storm y ataques DDoS a Georgia o
como el recibido por Estonia en Abril del 2007.

. . . . . . . . .
Microsoft pide (Feb 2010) a Verisign que se cierren 227
dominios asociados (C&C) a la botnet Waledac, la cuál envía
cerca de 1'5millones de mensajes de spam al día.
La Guardia Civil cierra (Mar 2010) la botnet Mariposa,
deteniendo a sus 3 creadores.
- Casi 13millones de equipos en más de 190 países
- Descubierta en Mayo de 2009 por Defense Intelligence
- Robo de credenciales bancarias
- Alquiler de subredes a otros (spam, phishing...)
- Infección del PC por p2p,IExplorer... (+autorun.inf)
Microsoft cierra la botnet Rustock (Mar 2011), demandando y
consiguiendo cerrar servidores de control de la botnet.

. . . . . . . . .
En Julio de 2012 la botnet GRUM (existente desde 2007) es
bloqueada. Enviaba 18billones de spam al día (18% mundial).
La empresa Fire Eye, lleva la pista de los servidores hasta
Panamá; el ISP logra poner fuera de servicio los servidores.
Pero una vez que Grum está fuera de juego...

. . . . . . . . .
Reaparece Festi, una botnet que existía desde 2009. Con cerca
de 300mil bots, mientras que GRUM tenía unos 120mil.
Pero Cutwail parece que es la botnet más grande con más de 1
millón de bots (troyano Pushdo), capaces de generar 74 billones
de mensajes al día, además de ser usados para lanzar ataques
DDoS contra la CIA, el FBI, Twitter o PayPal.
Microsoft dispone de un sitio web con numerosa información
sobre malware,spam,phishing,bots... :
http://www.microsoft.com/security/sir/

. . . . . . . . .
Pero...¿Qué puede hacer el ISP ante sus clientes infectados?
El RFC 6551 tiene algunas respuestas:
- Detección de bots en su red
- Analizador de tráfico (netflow)
- NIDS, indicadores varios (DNS, SMTP...)...
- Avisos de otros ISPs
- Notificación a los usuarios
- Vía email/correo postal/teléfono...
- Walled Gardens

. . . . . . . . .
Colaboraciones inter-ISPsColaboraciones inter-ISPs
El caso de McColo es un claro ejemplo de colaboración entre
ISPs para acabar con una red de malware.
Existen diferentes foros/congresos donde los ISPs y diversos
organismos (policiales, judiciales...) se reúnen para:
- Crear confianza (face2face)
- Llegar a acuerdos mínimos
- Acordar nuevas políticas y tendencias
- Por ej: uso de SPF, uso de DKIM, puerto 587...
Dos ejemplos de estos foros son:
- Nivel estatal: Foro Abuses www.abuses.es
- Nivel mundial: MAAWG www.maawg.org

. . . . . . . . .
LegislaciónLegislación
España:
- Denunciar ante la Agencia de Protección de Datos
- La LSSI dice:
1. Queda prohibido el envío de comunicaciones publicitarias o promocionales por
correo electrónico[...]que previamente no hubieran sido solicitadas o expresamente
autorizadas por los destinatarios de las mismas.
2. Lo dispuesto en el apartado anterior no será de aplicación cuando exista una
relación contractual previa, siempre que el prestador hubiera obtenido de forma
lícita los datos de contacto del destinatario y los empleara para el envío de
comunicaciones comerciales referentes a productos o servicios de su propia empresa
que sean similares a los que inicialmente fueron objeto de contratación con el cliente.
Infracción grave: + de 3 envíos/año, multa de 30.001 hasta 150.000 euros.
Infracción leve: cuando no sea grave, multa de hasta 30.000 euros.

. . . . . . . . .
Anti-SPAMAnti-SPAM
Existen actualmente numerosas medidas anti-spam, tanto
comerciales como gratuitas.
La mejor será aquella que de menos falsos positivos (mensajes
legítimos marcados como SPAM) y detecte más mensajes SPAM.
La más conocida puede que sea SpamAssasin.
Diferentes técnicas: a nivel de MTA, listas negras, software
analizador...etc.
Debe tenerse en consideración que perder mensajes legítimos
por el uso de un filtro da al traste el uso del correo electrónico.
Posible solución: MARCAR (por ejemplo, mediante cabeceras) y
que el cliente decida qué hacer.

. . . . . . . . .
Anti-SPAMAnti-SPAM
Restricciones a nivel de MTA.
Se pueden poner una serie de reglas o restricciones a nivel del
propio MTA (en el momento de recibir el mail, antes de
procesarlo). Éstas se suelen hacer:
- client: denegar la conexión a la IP en concreto,
chequear si tiene registro PTR...
- helo: chequear el dominio pasado al comando HELO, si
cumple el RFC...
- mail from: chequear que la dirección es correcta, el
dominio resuelve a un registro A...
- rcpt to: sintaxis correcta, usuario válido...

. . . . . . . . .
Anti-SPAMAnti-SPAM
Listas negras (RBL - Realtime Blackhole List o DNSBL)
Listas públicas en Internet en las que se añaden IPs de
spammers conocidos. Fundamental tenerlas en nuestro MTA.
El MTA se configura para que las consulte:
- Se coge la IP del cliente (Ej: 183.3.184.11)
- Se le añade el dominio de la lista que deseamos
consultar, por ej: 11.184.3.183.rbl.dns-servicios.com.
- Hacemos una consulta DNS preguntando por el reg. A:
$dig 11.184.3.183.rbl.dns-servicios.com +short
127.0.0.1
- Además, podemos preguntar por el registro TXT:
$dig TXT 11.184.3.183.rbl.dns-servicios.com +short
"Blocked - see http://rbl.dns-servicios.com/rbl.php?ip=183.3.184.11"
- Rechazo del email (nivel RCPT) → bounce del emisor.

. . . . . . . . .
Anti-SPAMAnti-SPAM
Listas negras (RBL - Realtime Blackhole List o DNSBL)
Las más conocidas son:
- SpamCop: www.spamcop.net
- SpamHaus: www.spamhaus.org, se divide en:
- SBL: IPs verificadas de spammers
- XBL: máquinas con gusanos, exploits...etc
- PBL: rangos de IPs residenciales, dinámicas...
- ZEN: las tres anteriores en una
- PSBL de Spamikaze, ReturnPath, Barracuda...
- De pago: Commtouch, Cloudmark...
Hay que estar atento a su evolución y ratio de Falsos Positivos.
Ver: http://www.abuses.es/docus/urln.html

. . . . . . . . .
Anti-SPAMAnti-SPAM
Además de los métodos comentados anteriormente, que
consumen pocos recursos, existen programas específicos para
el análisis de los mensajes.
Se suelen basar en reglas (+ IA en algunos casos).
Posibles problemas:
- Consumen muchos recursos (CPU+RAM) en el análisis
de los mensajes (cabeceras+cuerpo).
- Pueden dar falsos positivos.
- Debe de configurarse y estar atentos a ver cómo
evoluciona la detección.
- Si las reglas quedan obsoletas => no se detecta nada.

. . . . . . . . .
SpamAssassinSpamAssassin
Uno de los programas más conocidos (v3.4)
Escrito en PERL (ahora bajo el proyecto Apache).
Utiliza una serie de reglas estáticas y puede usar redes
bayesianas para el aprendizaje de nuevo conocimiento.
Analiza el mensaje sumándole puntos por coincidir una de sus
reglas o “conocimiento aprendido”, por ejemplo:
Content analysis details: (9.1 points, 4.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.5 FROM_ENDS_IN_NUMS From: ends in numbers
1.7 MSGID_FROM_MTA_ID Message-Id for external message added locally
2.3 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date
0.1 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL
0.5 WEIRD_PORT URI: Uses non-standard port number for HTTP
0.0 HTML_60_70 BODY: Message is 60% to 70% HTML
1.5 HTML_IMAGE_ONLY_12 BODY: HTML: images with 800-1200 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
1.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar to background
1.2 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.4 FROM_HAS_ULINE_NUMS From: contains an underline and numbers/letters

. . . . . . . . .
SpamAssassin solamente se encarga de marcar los e-mails.
Añadiendo “reports” como el anterior o añadiendo ciertas
cabeceras:
X-Relay-Information: AntiSPAM and AntiVIRUS on relay01
X-Relay-MsgID: 884825EA77C.00000
X-Relay-SpamCheck: no es spam, SpamAssassin (no almacenado, puntaje=2.691,
requerido 5.5, CTASD_SPAM_UNKNOWN -0.10, HTML_FONT_FACE_BAD 0.29,
HTML_FONT_SIZE_LARGE 0.00, HTML_MESSAGE 0.00, MIME_HTML_ONLY 0.20,
MSGID_FROM_MTA_HEADER 0.00, MSGID_RANDY 2.60,
RCVD_IN_RPSS_HIGH -0.10, RELAYCOUNTRY_ES -0.20)
X-Relay-SpamScore: ss
Deberá ser por tanto el MTA u otro software quien se encargue
de borrarlos en base al número de puntos sacados, si es lo que
pretendemos.

. . . . . . . . .
Viagra Sex Penis ...
SPAM
0/1 0/1 0/1 0/1
0/1
Prob(SPAM=1|V=1,S=0,P=1)=0
sa-learn mail SPAM=1
Prob(SPAM=1|V=1,S=0,P=1)=1
Redes Bayesianas de SpamAssassin => APRENDIZAJE

. . . . . . . . .
Plugins interesantes de SpamAssassin:
- BayesStore : diferentes formas de guardar las bases de
datos bayesianas (MySQL, pgsql, db...)
- RelayCheck : comprueba de qué países son los
servidores por los que ha pasado el email.
- URIDNSBL: listas negras para los dominios de las URLs
que aparezcan en el email.
- FuzzyOCR : “lector” de imágenes contra emails con
imágenes adjuntas.
- DCC, Razor, Pyzor...etc

. . . . . . . . .
DCC, Pyzor, RazorDCC, Pyzor, Razor
DCC, Pyzor y Razor son 3 herramientas colaborativas de
identificación de mensajes de SPAM.
Su funcionamiento se basa en hashes de cada mensaje que son
comprobados con una base de datos pública de hashes ya
conocidos como bulk/spam.
Se integran con SpamAssassin, de tal forma que cuando un
mensaje es encontrado en la BD, se le asigna una serie de
puntos.
Disponen de herramientas para reportar mensajes.

. . . . . . . . .
DCCDCC
DCC (Distributed Checksum Clearinghouses) es un sistema
distribuido de checksums. Cada cliente DCC envía los hashes de
cada mensaje que analiza, a su servidor que los comparte con
los servidores vecinos.
Si un hash se ve muchas veces => bulk => spam
# /usr/local/bin/dccproc -CQ < spam/057C3878051.00000
X-DCC--Metrics: relayout02.dns-servicios.com 1154; Body=2 Fuz1=2 Fuz2=many
reported: 0 checksum server
From: 2b3b8c26 301c597e a7da3eff c998a8a1
Message-ID: b7b36de7 7b90b3a1 9cfdbeb4 a05fa6bd
Received: b59c7c58 5696d621 9384b309 3e5bd634
Body: cdd9481c c80c0fc5 33b3300a 1e36cef1 2
Fuz1: eb939141 ebfbfc52 560a3793 f3768a62 2
Fuz2: 6be3fd50 5bcc097c 0ebb4d39 79b97b68 many

. . . . . . . . .
Falsificación del remitenteFalsificación del remitente
Aparte de los programas del estilo de SpamAssassin (Dspam,
bogofilter...etc), existen nuevos sistemas de detección de SPAM
en base a la falsificación del FROM desde el cuál llega un
determinado e-mail.
Los más conocidos son SPF y DomainKeys y ambos usan el
sistema DNS para tal cometido.
Estos sistemas no son antispam como tales, sino que el hecho
de que el spam es de origen falsificado la gran mayoría de las
veces, provoca que se use para esta práctica.

. . . . . . . . .
SPFSPF
SPF – Sender Policy Framework.
Registro TXT del dominio + agente SPF en el MTA destino.
Permite la detección de falsificación de direcciones del <MAIL
FROM>.
En el registro TXT del DNS del dominio se publican las
direcciones IP de los MTAs que están permitidos enviar correo
con dirección origen una de dicho dominio (@dominio).
El MTA receptor, consultará el registro para ver si la IP origen
está en las IPs permitidas.
Por ejemplo:
$ dig txt +short gnu.org
"v=spf1 ip4:199.232.76.160/27 ip4:199.232.41.64/27
ip4:199.232.41.0/28 ?all"

. . . . . . . . .
SPFSPF
MTA destino.com
MTA origen
SMTP
DNS gnu.org
¿TXT?
TXT: v=spf1 ip4:199.232.76.160/27
ip4:199.232.41.64/27
ip4:199.232.41.0/28 ?all
SMTP
From: rms@gnu.org
To: user@destino.com
/dev/null/dev/null
SPF
From: rms@gnu.org
To: user@destino.com

. . . . . . . . .
DKIMDKIM (Domain Keys Identified Mail), RFC 6376, es una idea
desarrollada a partir de DomainKeys e IdentifiedMail que
garantiza que un mensaje procede de un determinado sitio.
Usa claves públicas/privadas para certificar el origen de un e-
mail a través de DNS.
Un servidor que gestiona un dominio, crea dos claves, la pública
la publica en un registro TXT de su DNS y la privada la usa para
crear la firma digital de los mensajes añadiendo el resultado en
una cabecera del propio mensaje a enviar.
El servidor destino, consultará la clave pública y chequeará que
se corresponde con la clave que ha firmado el mensaje.
DKIMDKIM

. . . . . . . . .
Ejemplo de cabecera de firma digital correo saliente de Yahoo:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s1024; t=1392398504;
bh=FBBKRNuUfFx3gheZiAGaIR4V/kzm96btkqEDjFeqWfQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-
Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
b=4zWQ3z8nmHvx2luEdwp+AiudgY+ahYTFZ/ScUPvlc9C3jPrlbJ7Rur2qqxeP17qciB/WxrpyuQ9NJ/U1nhQPdK5
6Q6ZeGMGvKMZ+hog0BYNE5cHrkE3xqPmsDn73bU3hWkb+XhpfdTiQQFQLMEzQEorhw+E0qaM4b8entejjL7I
=
A partir de la cabecera, cogemos el selector para consultar el
registro TXT del dominio, donde está la clave pública:
$ dig txt s1024._domainkey.yahoo.es +short
"k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2P8LjnTD8
V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm""JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/
xhy+1xtj4RkdV7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB; n=A 1024 bit key;"
Juntando DKIM y SPF aparece DMARC: www.dmarc.org
DKIMDKIM

. . . . . . . . .
GreyListsGreyLists
La “técnica” de GreyListing consiste en una mezcla entre listas
negras y listas blancas.
La primera vez que se recibe un email, el MTA devuelve un error
temporal 4XX, de tal forma, que si el MTA origen sigue el RFC,
deberá de volver a intentar la entrega del mensaje pasados X
minutos. Cuando se reintenta el envío, se deja pasar y la IP se
mete en una lista blanca.
Página: http://projects.puremagic.com/greylisting/
Necesidad de instalar un agente en el MTA que se encargue de
gestionar los errores.

. . . . . . . . .
MTA origen MTA remoto
SMTP
ERROR 450
SMTP
SMTP
El mensaje es
guardado en la
cola. Pasado un
tiempo se
reintentará el envío.
Lista gris
GreyListsGreyLists

. . . . . . . . .
GreyListsGreyLists
El MTA origen recibiría un mensaje como:
450 <******@origen.com>: Recipient address rejected: Greylisted for 5 minutes
Pasado el tiempo de reintento del MTA origen, se reenviará el
mensaje, y si han pasado 5 minutos (en este caso) será
finalmente entregado.
Muchos spammers no usan un MTA para enviar mensajes, sino
un agente SMTP que entrega directamente el mensaje al MTA
destino, por lo que con esto evitaríamos muchos mensajes.
Problemas: retraso en entregas, servidores mal configurados...
El MTA origen recibiría un mensaje como:
450 <******@origen.com>: Recipient address rejected: Greylisted for 5 minutes
Pasado el tiempo de reintento del MTA origen, se reenviará el
mensaje, y si han pasado 5 minutos (en este caso) será
finalmente entregado.
Muchos spammers no usan un MTA para enviar mensajes, sino
un agente SMTP que entrega directamente el mensaje al MTA
destino, por lo que con esto evitaríamos muchos mensajes.
Problemas: retraso en entregas, servidores mal configurados...

. . . . . . . . .
GreyListsGreyLists
Impacto de implantación de Greylisting a nivel SMTP:

. . . . . . . . .
RateLimitRateLimit
Consiste en imponer límites de conexiones concurrentes, por
tiempo...etc a nivel SMTP. Rechazaremos temporalmente las
conexiones que los superen.
Insertar retardos en las respuestas SMTP del servidor de correo.
TarpittingTarpitting

. . . . . . . . .
Geolocalización IPGeolocalización IP
En base al país de procedencia del correo electrónico, podemos
realizar diferentes acciones sobre él:
- Greylisting / Blacklisting / Marcado...
Además, podemos combinarlo con otras medidas:
- GeoIP + RBLs => greylisting / blacklisting...
Lo proporciona: http://www.maxmind.com/es/geolocation_landing
Ejemplo:
# geoiplookup 61.245.172.54
GeoIP Country Edition: LK, Sri Lanka

. . . . . . . . .
Anti-VIRUSAnti-VIRUS
Otra de las amenazas del correo electrónico son los virus,
gusanos...etc que se transmiten vía e-mail.
Mucho consumo de recursos al analizar adjuntos grandes.
Prevenir que ciertos correos pasen al antivirus, bloqueando
extensiones peligrosas (.exe, .scr, .pif, .com...) y evitando que el
antivirus se ejecute para ellos.
Uno de los más usados es el antivirus libre ClamAV
(www.clamav.net).

. . . . . . . . .
Pasarelas de correoPasarelas de correo
Para la mejor integración del propio MTA con los antivirus,
sistemas antispam y otra serie de filtros o analizadores, existen
las pasarelas de correo.
Su tarea es recibir o coger el correo del MTA y gestionar todas
las llamadas a los antivirus y antispam.
La pasarela puede ser capaz de eliminar correos directamente
(por ejemplo, los que tengan un virus, tengan muchos puntos de
spam...).
Los más conocidos:
- Amavis
- MailScanner

. . . . . . . . .
Amavisd-newAmavisd-new
Amavisd-new es una pasarela creada a partir del antiguo Amavis.
Página: http://www.ijs.si/software/amavisd/
Escrito en PERL.
Interfaz entre el MTA y los antivirus, sistemas antispam...
Funciona de tal forma, que el MTA entrega al correo al puerto
TCP:10024 donde escucha amavisd-new. Cuando éste termina de
hacerle los chequeos y pasarlo por los analizadores, se devuelve
al puerto TCP:10025 del MTA.
Debemos de tener por tanto, dos demonios smptd corriendo, uno
para aceptar la conexiones externas SMTP y otro para las
conexiones de Amavisd-new.

. . . . . . . . .
MailScannerMailScanner
MailScanner es un programa escrito en Perl por Julian Field.
Página: www.mailscanner.info
Se trata de un demonio que va analizando los mensajes que
coge de la cola de entrada del MTA. Una vez analizados, los
deposita en la cola de salida del MTA.
MailScanner comprobará el mensaje con reglas de filtrado de
extensiones de archivos, listas negras, analizadores antispam,
antivirus...etc

. . . . . . . . .
Las características que tiene MailScanner son:
- Interfaz con SpamAssassin (y otros)
- Interfaz con antivirus
- Poner en cuarentena virus, spam etc...
- Diferentes acciones dependiendo de los puntos del SA
- Chequea extensiones de archivos en busca de dobles
extensiones, ext. peligrosas (exe,scr,pif...)...
- Anti-phishing
- Chequea mails con ataques HTML, Scripts...
- Reportes a destinatarios, emisores, admins...
- Añadido de cabeceras personalizadas
- Listas negras/blancas por usuario, dominio...
- Caché del resultado del SpamAssassin
- Casi toda directiva puede ser un archivo
- Detecta SaneSecurity en ClamAV
- ...

. . . . . . . . .
MailScanner
Incoming Queue
Outgoing Queue
MTA
SMTP
MTA SMTPlocal
Anti-SPAM
Anti-Virus
Internet
Internet
DCC
Razor
Pyzor
RBLs
(BATCH)

. . . . . . . . .
MailWatchMailWatch
MailWatch es una interfaz web que permite, entre otras cosas:
- Liberar de cuarentena mensajes
- Estadísticas de virus, relays, spam...etc
- Listas blancas/negras en MySQL
- Acceso por usuario/admin de dominio/admin total
- Configuraciones distribuidas vía PHP-XMLRPC
Se configura indicando en la configuración de MailScanner, que
por cada mail que procese haga una INSERT en una base de
datos. Posteriormente, mediante PHP, con MailWatch se
acceden a todos esos emails.
Sitio web: http://mailwatch.sf.net

. . . . . . . . .
MailWatchMailWatch

. . . . . . . . .
Solución completaSolución completa

. . . . . . . . .
RecomendacionesRecomendaciones
Recomendaciones de postmaster a postmaster ;-)
- Configurar correctamente el registro A del hostname
- Configurar correctamente el registro PTR
- Configurar correctamente el registro A del PTR
- Configurar correctamente los MX (=registro A)
- Autenticar toda clase de envío a través del servidor
- Cuidado con los formularios web
- Leer abuse@ y postmaster@ para posibles notificaciones
- Revisar logs cada cierto tiempo
- Monitorizar el estado de la cola
- Controlar los mailings de los usuarios
- ...

. . . . . . . . .
Enlaces de interésEnlaces de interés
http://www.rediris.es/mail/aupREDIRIS.es.html
http://www.abuses.es
http://www.spamhaus.org
http://www.spamcop.net
http://postmaster.hostalia.com
http://postmaster.aol.com
http://www.alvaromarin.com ;-)

Seguridad en sistemas_de_correo_electronico

Recommended

Recommended

More Related Content

Similar to Seguridad en sistemas_de_correo_electronico

Similar to Seguridad en sistemas_de_correo_electronico (20)

More from Alvaro Marin

More from Alvaro Marin (7)

Recently uploaded

Recently uploaded (20)

Seguridad en sistemas_de_correo_electronico