DIA 1, Taller: Hacia un correo electrónico limpio y seguro Ponencia: Métodos AntiSpam basados en autenticación de remitente Enrique Curiel Foruria Coordinador Desarrollo Software INTECO-CERT (Ciudadanos) 21/11/2007 1er ENCUENTRO NACIONAL DE LA INDUSTRIA DE SEGURIDAD
Agenda 1. Problemática actual del SPAM 2. Deficiencias del protocolo SMTP 3. Autenticación y reputación del remitente 4. SPF 5. DKIM 6. S/MIME 2
Problemática actual del spam Entre el 60% y el 90% del correo que reciben muchas organizaciones es spam, variando según la fuente y el sector estudiado Infraestructuras sobredimensionadas Pérdidas de productividad Genera desconfianza entre los usuarios hacia la S.I. en general Se distribuye mayoritariamente mediante BOTNETS Clara motivación económica para infectar con virus ordenadores conectados a Internet. 3
El negocio del spam Problemática actual del spam $ Spam $ Negocio dudoso $ Botnet Open Relay Usuarios de correo Buzones llenos Infecciones con Malware Servidores reventados $ 4
Deficiencias del protocolo SMTP El protocolo SMTP nace hace 25 años: RFC 821 - SIMPLE MAIL TRANSFER PROTOCOL Jonathan B. Postel - August 1982 +----------+ +----------+ +------+ User <--> SMTP +------+ Sender- Commands/Replies Receiver- +------+ SMTP <--------------> SMTP +------+ File <--> and Mail <--> File System System +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP Model for SMTP Use 5
Deficiencias del protocolo SMTP Hace 25 años, la comunidad de Internet es muy pequeña y no hay abusones No hay ningún tipo de autenticación del remitente (ni usuario ni dominio) Las cabeceras From se pueden suplantar trivialmente Los métodos anti-spam más usados habitualmente examinan: IP de origen del mensaje Contenido (filtros bayesianos, patrones) 6
Métodos de autenticación de remitente Necesitan acuerdo entre remitente y receptor Aceptación amplia en la comunidad de Internet Legislación o recomendaciones gubernamentales Retro-compatibles con protocolo SMTP actual Encarecer el coste de envío de correo no deseado Pero asequible para la mayoría de usuarios Los dominios de Internet cuestan (poco) dinero Utilicemos DNS! Oportunidades de negocio en la implantación de estos sistemas 7
SPF Dos propuestas no compatibles en todos los casos: Sender Policy Framework (Open Source) http://www.openspf.org/ Sender Id Framework (Microsoft) http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx Se basan en especificar en registros TXT en DNS desde que relés se puede enviar correo de ese dominio Podemos establecer la reputación según nombres de dominio 8
SPF Ejemplo: midominio.com IN A 1.1.1.1 correo.midominio.com IN A 1.1.1.2 midominio.com IN MX correo.midominio.com midominio.com IN TXT "v=spf1 a mx a:correo.midominio.com ~all" Versión SPF Permitido desde registro A Permitido desde registro MX Permitido desde este A No permitido desde más sitios 9
DKIM Domain Keys Identified Mail http://dkim.org Basado en Yahoo! Domain Keys y Cisco Identified Internet Mail Amplio respaldo de la industria Propuesto al IETF, Internet Draft Utiliza criptografía de clave asimétrica Firma cuerpo de mensaje y parte de las cabeceras en el servidor de salida Publicación de clave pública en DNS Verificación en el servidor de destino (posible en el cliente) 10
DKIM Mensaje firmado con clave privada Mensaje verificado Servidor MTA remitente/ firmante Servidor MTA Receptor/ verificador Buzón de Correo Publicación Clave Pública DNS Obtención Clave Pública De nuevo, la reputación se basa en el nombre de dominio 11
DKIM Ventajas sobre SPF Además de reputación y verificación, permite asegurar integridad del mensaje Puede extenderse a autenticación de remitente No hay propuestas incompatibles Inconvenientes Mayor complejidad de implementación Algunas MTAs o servicios (listas de correo) pueden modificar los mensajes e invalidar la firma 12
S/MIME Por qué reinventar la rueda? S/MIME (Secure Multiporpuse Internet Mail Extensions) implementa correo seguro cifrado, integridad, autenticación, no repudio S/MIME lleva varios años en funcionamiento RFC 2633 - S/MIME Version 3 Message Specification (Junio de 1999) RFC 3581: S/MIME Version 3.1 - Message Specification (Julio 2004) Cambios menores Soportado por la mayoría de clientes de correo 13
S/MIME y PKI S/MIME utiliza certificados X.509 Estándar de Internet RFC 3280(X.509 v3): Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Aprovecha la infraestructura de PKI existente. Utilizada por numerosas aplicaciones: SSL, IPSec, SmartCard (DNIe), etc Amplio apoyo de la industria Puede utilizarse: Entre clientes de correo (extremo a extremo) Entre servidores (experiencia en INTECO-CERT) Entre clientes y servidores (boletines INTECO-CERT) 14
S/MIME A pesar de todo, S/MIME tiene poca difusión Desconocimiento del usuario Necesidad de educación Manejo de certificados raíz De nuevo, podemos basar la reputación en el nombre de dominio Propuesta: publicación de certificados raíz en DNS El certificado raíz para usuario@midominio.com estaría en el DNS de midominio.com 15
S/MIME como anti-spam Alicia Mensaje firmado Por usuario o MTA Mensaje Verificado por usuario o MTA Servidor MTA remitente/ firmante Servidor MTA Receptor/ verificador Buzón de Correo CA dominio DNS Obtención Certificado Benito Publicación Certificado Raíz 16
S/MIME como AntiSpam Problemas: Rendimiento: Un certificado pesa unos 2-3 KB Una CRL puede hacerse muy grande Recomendable OCSP (Online Certificate Status Protocol) Seguridad Si un usuario firma sus propios mensajes, y su PC es comprometido (lo que hacen actualmente los spammers), se puede suplantar su identidad 17
Gracias 18