SPF - CaFeLUG

Transcripción

SPF - CaFeLUG

Antispam con
Postfix
Sobre el disertante
Efraim Wainerman
Títulos Universitarios
●
●
Licenciado en Sistemas de Información, Universidad Nacional de Luján,
2005.
Analista Programador en Computación, Facultad de Ingeniería, Universidad
Nacional de la Pampa, 2001
Actividad laboral
●
Administración de redes y sistemas, docencia universitaria
Participación en LUGs
●
cafelug
●
unlux.
e-mail: efraim_y_mi_dominio_es_linuxmail.org
Objetivos y motivación de la
charla
¿Qué es el spam?
Según Wikipedia
Se llama spam, correo basura o sms basura a los
mensajes no solicitados, habitualmente de tipo publicitario,
enviados en grandes cantidades (incluso masivas) que
perjudican de alguna o varias maneras al receptor
¿Que es Postfix?
Postfix es un MTA (agente de transporte
de correo) de acuerdo a la terminología de
SMTP
RFC 5321, SMTP: http://tools.ietf.org/html/rfc5321
Responsabilidades de un MTA
●
Enviar y recibir mensajes de correo
electrónico a través de internet
●
Realizar el delivery local
●
Puede actuar como relay y redireccionar
mensajes
Formas de atacar el spam
●
Analizando el contenido de los mensajes
- En el servidor: DSPAM, spamassassin,
postfix, etc.
- En el cliente: mozilla thunderbird (icedove),
otros clientes usando spamassassin, spambayes,
etc.
Formas de atacar el spam (cont.)
●
Analizando el origen de los mensajes
- Listas negras: de dominios, de IPs, etc
- Mecanismos de autenticación de e-mail
(estándares o propuestas):
- SPF
- DKIM (Domainkeys)
- SenderID
Formas de atacar el spam (cont.)
●
Otros criterios
- Validez del remitente (campo from, puede
chequearse el dominio o adicionalmente el usuario)
- Validez de la ip de origen (reverse DNS)
- Helo requerido y Helo válido por DNS
- Que el servidor reintente el envío (greylisting) rfc
5321
- Geolocalización de los clientes
- etc.
Criterios de implementación de un
filtro antispam
¿Es tolerable tener falsos positivos en un servidor
que rechaza los mensajes de spam?
¿y si utilizara un filtro que sólo los marcase?
¿Por qué implementar un antispam
en el MTA?
●
Seguridad
- Mitiga los ataques vía e-mail al servidor
corporativo o a los usuarios finales.
- Puede ayudar a mejorar la reputación de
nuestro dominio al reducir el spam que suplanta
nuestra identidad hacia otros dominios y evitando
que nuestro servidor genere rebotes hacia
terceros (backscatter)
en el MTA? (cont.)
Eficiencia
- Menor costo computacional de los chequeos
- Cola de mensajes más reducida
- Ahorro de ancho de banda externa al no
permitir el delivery de los mensajes de spam
proveniente de clientes remotos
- Ahorro de ancho de banda interna al no
realizarse el delivery de los mensajes de spam
hacia los servidores corporativos y la posterior
descarga hacia las estaciones de trabajo
●
en el MTA? (cont.)
- Ahorro de espacio de almacenamiento al no
realizarse el delivery local o hacia los servidores
corporativos del spam
- Reducción de costo computacional derivado
de la reducción del tráfico analizado por los filtros
de contenido
●
Claridad en la política antispam
en el MTA? (cont.)
●
Eficacia
- Eliminación de mensajes perdidos sin aviso
- Los mensajes de spam no llegan al usuario
final
Ejemplo de una sesión SMTP
$ telnet mail.midominio.com.ar 25
Trying a.b.c.d...
Connected to mail.midominio.com.ar.
Escape character is '^]'.
220 Este es el servidor de mail de midominio.com.ar
helo mail.dominiocliente.com.ar
250 mail.midominio.com.ar
mail from:<[email protected]>
250 2.1.0 Ok
rcpt to:<[email protected]>
250 2.1.0 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: esto es una prueba
.
250 2.0.0 Ok: queued as 93691D8293
Mecanismos
Mecanismos – Listas negras
Listas negras
Pueden ser listas de
- IPs / subredes
- Dominios: se puede usar para chequear el
campo mail from, para chequear el parámetro en
el helo o para identificar a conjuntos de IPs
mediante reverse DNS
- remitentes
- palabras o claves en el cuerpo del mensaje o
en campos determinados
Listas negras (cont.)
Tipos de chequeo
Online
RBL (Real-time Blackhole List, Block List o
Blacklist) o DNSBL (DNS-based Blackhole List,
Block List o Blacklist)
Offline
Tablas hash en formato Berkeley DB
Ventajas
- Eficiencia
- Simplicidad
- Efectividad
Desventajas (aplicable sobre las bases de
datos masivas)
- Confiabilidad dudosa sobre las políticas de
inclusión y exclusión de servidores
- Inclusión de subredes IP pertenecientes a
ISPs que permiten enviar spam a sus clientes
Referencias
● Recursos sobre listas negras:
http://spamlinks.net/filter-bl.htm
● Posición de la EFF (Electronic Frontier
Foundation) sobre la implementación de
antispam:
http://w2.eff.org/spam/position_on_junk_email.php
● The Spam Problem: Moving Beyond RBLs
http://www.whirlycott.com/phil/antispam/rbl-bad
/rbl-bad.html
Autenticación de e-mail
●
SPF (Sender Policy Framework)
●
DKIM (Domainkeys Identified Mail)
●
Sender ID
Autenticación de e-mail - SPF
SPF (Sender Policy Framework)
●
Permite corroborar que el remitente de un mensaje es
válido porque proviene una ip autorizada por la
organización o de lo contrario rechazarlo o marcarlo
como spam.
●
Utiliza chequeos en un registro especial de DNS (TXT)
●
Estandarizado por la IETF, última definición en la RFC
4408
Sintaxis
Elementos de la sintaxis de SPF
●
●
●
●
Version
Mecanismos
Calificadores
Modificadores
Referencias
http://www.openspf.org/SPF_Record_Syntax
Autenticación de e-mail – SPF – Sintaxis
Versión
v=spf1
Actualmente la versión 1 es la única definida en el
estándar
Mecanismos de SPF
all | ip4 | ip6 | a | mx | ptr | exists | include
Autenticación de e-mail – SPF – Sintaxis - Mecanismos
all
Identifica a todos los hosts y generalmente va al
final
Ejemplo
Denegar a cualquier host
“-all”
ip4 e ip6
Especifica una dirección o subred IP
Ejemplo
“ip4:111.111.0.0/16”
a
Identifica a cualquier host del dominio
a
a/<máscara ip>: Si la ip del host no coincide
a:<dominio>
a:<dominio>/<máscara ip>
Ejemplo
“a:midominio.com.ar/24”
mx
cualquier registro mx del dominio
mx
mx/<máscara ip>
mx:<dominio>
mx:<dominio>/<máscara ip>
Ejemplo
“mx”
ptr
La resolución inversa de DNS de la ip del cliente da por
resultado un nombre de host perteneciente al dominio
ptr
ptr:<dominio>
Ejemplo
“ptr:miotrodominio.com.ar”
exists
Verifica si un cierto dominio se puede resolver
exists:<dominio>
Ejemplo
exists:ciertodominio.com.ar
include
Incluye las directivas SPF en otro dominio
Ejemplo
include:otrodominio.com.ar
Calificadores
+ Pass
- Fail
~ SoftFail
? Neutral
Modificadores
redirect | exp
Autenticación de e-mail – SPF – Sintaxis - Modificadores
redirect
Similar a include
Ejemplo
redirect=otrodominio.com.ar
Autenticación de e-mail – SPF – Sintaxis - Modificadores
exp
permite brindar un mensaje de error personalizado para
el rechazo del mensaje incluyendo un string en el
registro TXT de otro dominio
Ejemplo
exp=miotrodominio.com.ar
Ejemplos
- "v=spf1 mx -all"
- "v=spf1 ip4:x.y.z.r ~all"
- "v=spf1 a mx ip4:a.b.c.d ~all”
- “v=spf1 include:miotrodominio.com.ar ?all"
Módulos de SPF para Postfix
●
Postfix-policyd-spf-perl (recomendado)
●
postfix-policyd-spf-python
●
tumgreyspf
●
Whitelister (recomendado sin reject)
Ventajas
Estándar de internet
●
Fácil de implementar
●
Implementación liviana (usa consultas DNS)
●
Evita los rebotes masivos (backscatter) y puede
preservar la reputación de nuestro dominio.
●
En general no debería presentar falsos positivos
porque usa una configuración explícita del dominio del
cliente
●
Desventajas
Puede causar falsos positivos dependiendo de la
implementación/configuración, por ejemplo chequeo de
helo (recomendado en la RFC), errores de sintaxis en el
registro TXT
●
Si tenemos el registro de SPF definido en nuestro
dominio: debemos prever las posibles contingencias (por
ejemplo tener que usar una IP alternativa, todas las
posibles IPs deberían estar contempladas previamente
porque los registros DNS no se pueden cambiar
rápidamente)
●
Desventajas (cont.)
Si tenenmos chequeo de SPF en el cliente: puede
causar falsos positivos cuando otro dominio tiene una
contingencia
●
Los grandes de la industria y otros implementan
definiciones con softail (“?all”) o neutral (“~all”)
●
Bajo nivel de implementación
●
DKIM (DomainKeys Identified Mail)
- Provee autenticación e integridad a los mensajes
- Utiliza búsquedas en DNS y criptografía asimétrica
Estandarizado por la IETF
- RFC 4870: Domain-Based Email Authentication
Using Public Keys Advertised in the DNS (DomainKeys)
- RFC 4871: DomainKeys Identified Mail (DKIM)
Signatures
Autenticación de e-mail - DKIM
Ventajas
Estándar de internet
●
Provee autenticidad e integridad a los
mensajes
●
Autenticación de e-mail - DKIM
Desventajas
Mayor costo computacional que sus
contrapartes basadas en DNS
●
Posibilidad de falsos positivos debido a
problemas de interoperabilidad con filtros de
contenido
●
Complejidad de implementación -> bajo nivel
de adopción -> baja eficacia
●
Sender ID
- Es un proyecto experimental de Microsoft de
fusionar Caller ID (otro proyecto de Microsoft) con
SPF
- Definiciones en los borradores RFC 4406,
4405, 4407 y 4408 (SPF)
- Funcionalidad similar a SPF pero mayor
complejidad
Autenticación de e-mail – Sender ID
Sender ID (cont.)
- Incosistencias técnicas (conflicto con otras
RFCs)
- Resistido por los mayores representantes del
software libre (Debian, Apache, Postix, etc) por no
ser implementable sin violar varias patentes de
Microsoft
- Aprobación como estándar de la IETF
denegada
Chequeo de IP de origen
Existencia de resolución inversa de DNS (reverse
DNS)
Ventajas
●
Fácil de implementar
●
Implementación liviana (usa consultas DNS)
Desventajas
●
Alto nivel de falsos positivos por mala configuración
de DNS en enlaces corporativos
●
No detecta hosts de ISPs que tienen configuración de
reverse DNS para sus clientes con IP dinámica
Geolocalización de IPs
Permite bloquear, redirigir a un filtro de
contenido (por la característica de las tablas de
Postfix) o aceptar tráfico según la ubicación
geográfica de un cliente SMTP
Tipos de chequeo
Online
a través de la librería geoip
Offline
a través de una tabla con rangos de redes ip
(cidr)
Ventajas
●
Permite aplicar políticas diferenciadas según la
localización geográfica de los clientes
●
Permite reducir los falsos positivos, retrasos o costo
computacional generados por otros mecanismos
Desventajas
●
falsos positivos por inexactitud de las bases de datos
●
No detección de organizaciones que terciarizan su
servicio de relay de correo
Referencias
Base de datos de IPs (compatible MySQL):
http://www.iplocationtools.com/databases/ipinfodb_one_table
●
Página man de tablas cidr en Postfix:
http://www.postfix.org/cidr_table.5.html
●
Extensión para soporte ACLs en Postfix:
http://www.apolicy.org/cgi-bin/moin.cgi/AclList
●
Validez del remitente
Se pueden chequear dos componentes del campo
from (Envelope From)
Existencia del dominio
(reject_unknown_sender_domain)
●
Existencia de la cuenta de usuario
(reject_unverified_sender)
●
Ventajas
●
Simplicidad
●
Eficacia
●
Eficiencia
Desventajas
●
Generación de tráfico DNS
●
En el caso del chequeo de la cuenta de usuario
- demora del chequeo
- abuso de los recursos del cliente -> bloqueo
Análisis del parámetro del comando Helo
Tipos de restricciones
Que el comando Helo sea obligatorio
(smtpd_helo_required)
●
Que el parámetro pasado en el Helo sea un FQDN
válido (reject_non_fqdn_hostname)
●
Que el parámetro pasado en el Helo sea un nombre
DNS válido (reject_invalid_hostname)
●
Que el parámetro pasado en el Helo sea un host DNS
existente (reject_unknown_hostname)
●
Que el parámetro pasado en el Helo no pertenezca a
una lista negra (check_helo_access)
●
Análisis del parámetro del comando Helo
Ventajas
●
Simplicidad
●
Eficacia
●
Eficiencia
Desventajas
●
En caso de exigir que el parámetro sea un FQDN,
host DNS válido o existente genera falsos positivos por
malas configuraciones de los MTAs (problema
compartido con un punto recomendado en la definición
de SPF)
●
En caso de exigir que el parámetro sea host DNS
existente: generación de tráfico DNS
Greylisting
Módulos para Postfix
●
postgrey
●
tumgreyspf
Greylisting (cont.)
Ventajas
●
Simplicidad de implementación
●
Muy alta eficacia
●
Eficiencia
●
Casi inexistencia de falsos postivos
Desventajas
●
Demora de mensajes
●
Ampliación de colas en los clientes -> aumento de
consumo de recursos
Ejemplo de configuración en Postfix
Archivo /etc/postfix/master.cf:
# Política de SPF creación del demonio con socket
spfcheck unix n
n
0
spawn
user=policyd-spf argv=/usr/bin/postfix-policyd-spf-perl
Archivo /etc/postfix/main.cf:
...
myhostname = mail.midominio.com.ar
…
# Permitir localhost y la red interna
mynetworks = 127.0.0.0/8 10.0.1.0/16
# Opción 2: configuración cerrada permitiendo sólo host autorizados
# mynetworks = 127.0.0.0/8 10.0.1.1/32
...
mydestination = midominio.com.ar
relay_domains = $mydestination
…
smtpd_banner = Este es el servidor de mail de midominio.com.ar
# Configuración para relay: definición de usuarios válidos
local_recipient_maps = hash:/etc/postfix/usuarios_permitidos
Ejemplo de configuración en Postfix (cont.)
Archivo /etc/postfix/main.cf (cont.):
# No verificar usuario del from
disable_vrfy_command = yes
# Necesario para SPF
policy_time_limit = 3600
smtpd_delay_reject = yes
# Chequeos de Helo
smtpd_helo_required = yes
smtpd_helo_restrictions =
check_helo_access
hash:/etc/postfix/bloqueados_dominios_puntuales,
check_helo_access hash:/etc/postfix/bloqueados_helo
smtpd_recipient_restrictions=
# Evitamos que el servidor sea un relay abierto
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
# Chequeo de listas blancas/negras internas
check_recipient_access hash:/etc/postfix/usuarios_validos,
check_client_access hash:/etc/postfix/permitidos_servidores,
check_client_access hash:/etc/postfix/permitidos_dominios_puntuales,
check_client_access hash:/etc/postfix/bloqueados_bl_ip_manual,
check_client_access hash:/etc/postfix/bloqueados_dominios_puntuales
smtpd_recipient_restrictions= # Continuación
# Whitelister (puede aceptar, dejar pasar ,desactivamos el reject)
check_policy_service inet:127.0.0.1:10000,
# Chequeo de greylisting (puede demorar con 450 o dejar pasar)
check_policy_service inet:127.0.0.1:60000,
# Chequeo de SPF (puede aceptar, rechazar con 550 o dejar pasar)
check_policy_service unix:private/spfcheck,
smtpd_recipient_restrictions= # Continuación
# Geolocalización: acepto redes ip de Argentina si pasaron los chequeos
# anteriores
check_client_access cidr:/etc/postfix/rangos_ip_argentina_manual,
check_client_access cidr:/etc/postfix/rangos_ip_argentina_masivo,
# Configuración de prueba: listas negras masivas offline
warn_if_reject check_client_access hash:/etc/postfix/bl_masiva1
warn_if_reject check_client_access hash:/etc/postfix/bl_masiva2,
warn_if_reject check_client_access hash:/etc/postfix/bl_masiva3
/etc/postfix/usuarios_validos:
[email protected] DUNNO
[email protected] DUNNO
...
midominio.com.ar REJECT
/etc/postfix/permitidos_servidores:
111.111.111.111 OK
google.com OK
yahoo.com
OK
yahoo.com.ar OK
hotmail.com OK
gov.ar
OK
gob.ar
OK

SPF - CaFeLUG

Transcripción

Documentos relacionados

Servidor de Mail (Postfix)

Servidor de correo con Postfix + Spamassassin + Dovecot