Evitando anzuelos: Cómo luchar contra los ataques de spear-phishing (II)

En el artículo anterior se planteaban una serie de medidas a aplicar en el servidor de correo para protegernos de correos maliciosos. Continuamos con más medidas aplicables.

DKIM (DomainKeys Identified Mail)

DKIM es otra medida de seguridad que se puede aplicar de forma totalmente transparente en nuestros correos electrónicos (es decir, que podemos activarla y si el destinatario de los correos elige no verificarla no afecta en absoluto a su entrega).

El funcionamiento de DKIM es a grandes rasgos el siguiente:

1. El usuario pulsa sobre enviar el correo (no hay modificaciones esta parte).
2. El correo llega al servidor emisor, y éste recoge una serie de datos (habitualmente el cuerpo del mensaje o el cuerpo y las cabeceras) y las firma digitalmente con la clave privada del servidor de correo.
3. Al correo se le añade una nueva etiqueta en la cabecera, denominada DKIM-Signature, en la que se incluyen entre otros metadatos como el algoritmo de cifrado, qué datos vienen firmados, la fecha del firmado y una etiqueta especial denominada selector (que indica qué clave pública ha sido empleada, ya que DKIM permite el tener múltiples claves).
4. El correo es enviado.

En la parte de cliente el proceso de verificación sigue estos pasos:

1. El servidor recibe el correo, y comprueba las cabeceras del mismo, encontrando la cabecera DKIM-Signature. Si está configurado para verificarla, la examinará y extraerá los datos necesarios (selector, algoritmo de cifrado, qué está firmado, fecha de expiración entre otros).
2. Se extrae de las cabeceras el dominio origen de la comunicación, y se realiza una consulta DNS contra el dominio construido de la forma siguiente:
   selector. _domainkey.dominio (ej: dkim._domainkey.twitter.com)
3. La consulta DNS debería devolver la clave pública pareja de la empleada para firmar el mensaje, por lo que el servidor receptor del mismo puede proceder a su validación.
4. Si la firma valida correctamente, el servidor seguirá con el resto de comprobaciones y, de ser correctos, entregará el mensaje al buzón del usuario. En el caso de que falle la validación puede rechazar el mensaje o habilitar un mensaje de advertencia (en función de las capacidades del servidor).

Para que un atacante pudiera falsificar un correo en este escenario, tendría que ser capaz de generar la firma digital correcta, lo que implica el tener la clave privada del servidor de correo. En este escenario el atacante tendría que tener el control completo del servidor origen, por lo que se espera que la probabilidad de que esto suceda sea pequeña.

La configuración y validación de DKIM es sensiblemente más compleja que SPF y más prona a errores. Por ejemplo, cualquier modificación al cuerpo del mensaje una vez firmado (como la típica coletilla del antivirus de “Escaneado por…”) provocará el fallo de la validación DKIM.

Se recomienda proceder como en el caso de SPF: Configurar de forma inicial la validación DKIM para que solo emita una advertencia cuando la firma no sea correcta. Una vez resueltas las posibles incidencias (aquí tenéis un excelente validador DKIM) se puede reconfigurar en modo más restrictivo (una buena práctica es no rechazar nunca los mensajes sino moverlos a una cuarentena).

Un efecto colateral de DKIM es que permite autenticar que un correo electrónico ha salido de un servidor específico, algo que como curiosidad ha sido empleado para validar algunos correos exfiltrados del DNC (partido demócrata norteamericano) y publicados en WikiLeaks.

Se puede encontrar más información sobre DKIM en su RFC o en su página oficial.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC se apoya sobre SPF y DKIM para ofrecer servicios de informes y políticas sobre qué hacer con los correos que no pasan dichas validaciones. Cuando se configura DMARC, se crea un registro DNS con la forma _dmarc.ejemplo.com que contiene una serie de valores como: qué hacer con un mensaje que no pasa la validación, o distintas direcciones de correo electrónico donde recibir informes.

Esta quizás sea la parte más interesante de DMARC, ya que permite recibir informes agregados de correos que son enviados por nuestro servidor y que no pasan las validaciones (lo que puede ayudarnos a detectar situaciones en las que nuestros correos tengan problemas).

Especialmente interesante en nuestro entorno es la función forense, en la que los correos que no pasen los filtros son enviados a la dirección que indiquemos (lo cual puede ser interesante para detectar posibles intentos de ataque que pretendan falsificar nuestra identidad, aunque en casos concretos el volumen de respuestas puede ser considerable).

Se puede encontrar más información sobre DMARC en su RFC o en su página oficial.

Bloqueo de extensiones potencialmente peligrosas

Una vez el correo pasa por los controles anteriores, el servidor está convencido de que el origen ha sido suficientemente verificado. Sin embargo, eso no implica que el correo sea benigno (un atacante puede haber tomado el control de una cuenta de correo y usarla para enviar los correos maliciosos, por ejemplo). Es por ello por lo que ahora es necesario verificar que el contenido del correo no es malicioso.

Aquí entran los sistemas de antispam y antivirus de cada servidor de correo, que afortunadamente a día de hoy se encuentran en la mayoría de las empresas (consejo: hacer que el antivirus del servidor de correo sea distinto del que está en los equipos informáticos es una buena práctica muy acertada).

Desgraciadamente, los antivirus distan mucho de ser perfectos, y muchos correos maliciosos pueden engañarlos con cierta facilidad y ser entregados. Una medida de seguridad adicional pasa por bloquear ficheros con extensiones maliciosas, de forma que sean bloqueados o redirigidos a una cuarentena (cuidado con la verificación de ficheros, que debería ser siempre basada en las cabeceras del fichero y no en la extensión del mismo, que puede ser falsificada sin esfuerzo).

Se puede encontrar que una base de extensiones a bloquear en este artículo de Microsoft, pero la norma básica es: si puede ejecutarse, no lo vamos a recibir.

Bloqueo de ficheros especiales

Hay tres tipos de ficheros que son especialmente de interés en este punto: los ficheros comprimidos, los protegidos por contraseña y los de gran tamaño. Estos ficheros habitualmente no pueden ser examinados por el antivirus del servidor (sobre todo con esquemas de compresión poco habituales como .ace, .bz2 o el venerable .arj) y en muchos casos son entregados directamente por el servidor de correo.

Se recomienda en primer lugar analizar sobre los logs del servidor de correo las cifras de estos ficheros problemáticos, y en el caso de los comprimidos, el desglose por algoritmos de compresión. En el caso de los ficheros comprimidos, se recomienda dejar pasar únicamente aquellas extensiones que puedan ser reconocidas y analizadas por el antivirus (habitualmente .zip y .rar no suelen dar problemas, pero habría que estudiar caso por caso).

En el caso de los ficheros de gran tamaño es posible aumentar el tamaño del fichero máximo en el propio antivirus (con el consiguiente coste de rendimiento del servidor, que habría que vigilar). Para los ficheros protegidos por contraseña, solo queda la opción de redirigirlos a la cuarentena (y que sea el usuario el que los solicite haciéndose responsable de su contenido).

En este punto deberíamos hacer una mención especial a los ficheros cifrados. El cifrado de ficheros es una buena práctica de seguridad, muy habitual en entornos de alta seguridad. Sin embargo, un fichero cifrado no va a poder ser analizado por el antivirus, algo que tendrá que ser tenido en cuenta. Se recomienda reconocer qué tipo de cifrado se emplea en la Organización de forma autorizada y dejar pasar únicamente ese tipo de fichero.

Monitorización de las medidas aplicadas

Por nuestra experiencia en varios clientes de gran tamaño, la implantación de estas medidas es bastante costosa debido a todos los problemas que pueden aparecer debido a configuraciones no del todo correctas por parte de terceros y a nuestra propia configuración (a lo que hay siempre que sumar los consabidos “casos particulares”).

Dado que el correo electrónico es un servicio crítico para muchas organizaciones, se recomienda la implantación gradual de estas medidas, y siempre mediante controles lo menos agresivos posibles (monitorización en primer lugar y luego cuarentena, nunca rechazo directo).

Un punto muy a tener en cuenta es la posibilidad de algunos productos de permitir devolver un mensaje de rechazo que indique al origen que el correo no ha sido entregado. No se recomienda dicha opción ya que estamos dando pistas a un posible atacante (por ejemplo, un spammer al que le estamos confirmando que la dirección de correo es válida y activa).

De la misma forma, es importante comunicar a los usuarios la implantación de dichas medidas, facilitando canales mediante los cuales puedan contactar con los administradores del correo y ser capaces de recuperar de la cuarentena ficheros necesarios para su trabajo.

En el siguiente artículo entraremos en las medidas aplicables al puesto de usuario, y hablaremos de qué podemos hacer con todos los correos maliciosos recibidos.

Fuente: Securityartwork.es