Blog

Archive for enero, 2017

Portfix informa “Connection timed out” pero el telnet funciona

Índice de claves

  • Postfix connection cache
  • Postfix caching connection timeout
  • Postfix insiste en informar “Connection timed out”

Introducción

Si encuentra que está recibiendo informes de “connection timeout” de “Mail deliveries” o directamente desde el log como el que sigue:

Jan 11 07:32:14 server-smtp-01 postfix/error[11965]: 62E6DEBAD: to=, relay=none, delay=17159, delays=17159/0.04/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mailserver.xx.es[194.X.187.X]:25: Connection timed out)

..y al mismo tiempo, está ejecutando operaciones de telnet y funcionan sin problemas::

telnet 194.X.187.X 25
Trying 194.X.187.X...
Connected to 194.X.187.X.
Escape character is '^]'.
220 mailserver.xx.es ESMTP

En este contexto, incluso si reinicia el servicio de Postfix sigue encontrando que los errores persisten y sigue reportando “Connection timed out”.

Al mismo tiempo, ya ha comprobado que ningún firewall está bloqueando la conexión: por ejemplo, root puede tener permitido hacer telnet mientras que el usuario “postfix” no.

¿Porqué Postfix sigue reportando “Connection timed out”?

Todos estos “Connection timed out” informados por Postfix son usualmente causados por el módulo de postfix de cacheo de estado de conexiones (postfix connection cache): http://www.postfix.org/CONNECTION_CACHE_README.html

Este código de cache es usado por Postfix para acelerar las operaciones y para evitar seguir hablando con hosts lentos o que están fallando. Es una mejora para el rendimiento que, en algunos casos, puede causarle problemas.

En algún momento del pasado, el servidor SMTP de destino comenzó a fallar con un timeout. Luego, este estado fue cacheado por Postfix, causando este problema.

¿Cómo resolver el “Connection timed out” cuando telnet funciona?

Primero, intente revisar la configuración “smtp_connect_timeout” para incrementarlo. Por defecto viene configurado a 30 segundos. No lo incremente por encima de 90 porque le causará otros problemas.

Después de eso, ejecute los siguientes comandos para reencolar los correos y luego reiniciar postfix. Recuerde que esto reintentará todo:

postsuper -r ALL
/etc/init.d/postfix restart

Posted in: Postfix

Leave a Comment (0) →

Controlando el “content filter” Amavis con Valvula (protocolo “access policy delegation”)

Índice de claves

Resumen

Controlando los correos comprobados o producidos por el servidor de “Content filter” (Amavis) con el servidor de delegación de políticas de acceso (Valvula)configurado en Postfix.

Introdución

Debido al modo en que funciona Postfix cuando configuras el parámetro “content filter =”, donde configuras Amavis o cualquier otro servidor de “Content Filter”, esto hace que todos los correos que entran en la cola de Postfix sean envaidos a Amavis (o el servidor de “Content filter” que tenga configurado) de manera que el correo sea procesado y a su vez, si todo está correcto, ese correo regresará a Postfix a través de un puerto interno diferente (típicamente 10025/tcp).

Desde aquí, asumiremos que el servidor de “Content Filter” es Amavis y Valvula como servidor de delegación de política. Si este no es el caso, este artículo sigue siendo relevante para su configuración.

Una vez que Amavis ha decidido que todo está correcto, ese correo es enviado de nuevo a Postfix en un puerto dedicado, usualmente declarado como sigue en  /etc/postfix/master.cf:

# amavis connection, messages received from amavis 
127.0.0.1:10025 inet n - y - - smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o smtpd_restriction_classes=
 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject 
 -o mynetworks=127.0.0.0/8
 -o strict_rfc821_envelopes=yes
 -o receive_override_options=no_address_mappings

Como puede ver, cualquier correo será aceptado en el puerto (10025/tcp) mientras que venga de localhost (confianza total).

Sin embargo, el problema que queremos resolver es como enfrentarnos a correos originados desde el servidor internamente (enviados por el comando mail/maildrop) o porque sean enviados por mailman (o alguna configuración del propio servidor de “Content Filter” que también puede producir correos por si mismo) y que estos sean controlados/supervisados por Valvula (access policy server).

En este caso, con la configuración anterior no hará que los correos producidos por Amavis sean controlados por Valvula.

Qué hay que cambiar para que el servidor de políticas sea llamado

Con esta información identificada, en el caso de que sea necesario filtrar los correos enviados de regreso a Postfix por el servicio de “Content Filter”, puede actualizar el siguiente parámetro:

        -o smtpd_recipient_restrictions=permit_mynetworks,reject

..para que sea lo siguiente:

        -o smtpd_recipient_restrictions=check_policy_service,inet:127.0.0.1:3579,permit_mynetworks,reject

Esta esta la configuración recomendada para Core-Admin, donde la parte relevante es “127.0.0.1:3579″ y que tiene que ser actualizada con su configuración local.

De esta manera, cuando Amavis termine, ese correo tendrá que ir también através de Valvula cuando vuelva a Postfix.

Interacciones que puede causar esta configuración

Este cambio hará que Valvula (o el servidor de políticas que tenga configurado) que sea llamado 2 veces por cada correo recibido. Primero cuando el correo es recibido y segundo, cuando es recibido después que Amavis termina de procesar el correo.

Porqué no configurar esto por defecto

Esta configuración aquí descrita puede ser interesante en algunos escenarios.

Para el caso de un servidor de correo dedicado, esta configuración no es útil/necesaria. Nos referimos “servidores de correo dedicados” aquellos que no tienen un software de gestión de listas, páginas webs o cualquier otro software que pueda proucir correos internamente y que sea necesario limitarlos, bloquearlos o descartarlos.

Por otro lado, esta información puede no ser interesante en todos aquellos casos conde esta limitación pueda ser en origen (actualizando la configuración del servicio produciendo estos correos a limitar) o incluso la configuración de Postfix authorized_submit_users.

Resumiendo, esta no es la única configuración disponible para limitar/controlar correos desde dentro del servidor usando el servicio de delegación de política de acceso (http://www.postfix.org/SMTPD_POLICY_README.html).

Posted in: Administrador de Correo, Amavis, Postfix, Seguridad, Valvula

Leave a Comment (0) →

Let’s Encrypt: la revolución silenciosa

Let’s encrypt: la revolución silenciosa de los certificados SSL

Let's encrypt logoSi ha tenido que comprar un certificado digital SSL —terminología antigua, ya que en realidad ahora todo es TLS [2] — sabrá que tienen un coste y que ese coste lo pagamos debido a que una entidad “confiable” pone su “firma digital” en nuestro certificado para que los navegadores, a su vez, y por esta cadena de “confianza”, acepte nuestro certificado.

Y de eso va la tecnología SSL/TLS: de confianza.

Criptografía asimétrica: el resumen más corto de la historia

Para poder entender porqué SSL/TLS es tan importante para la seguridad del Internet de hoy en día y ese “verde” característico que aparece cuando escribimos https:// en nuestro sitio favorito, tenemos que entender qué es la Critografía Asimétrica [1] y qué relación guarda con eso que hemos dicho antes: “la confianza”.

Brevemente, la critografía asimétrica permite generar una llave pública y una privada de tal modo que todo lo que sea cifrado con el certificado público, sólo podrá ser descifrado por la llave privada (que es la que queda instalada en el servidor y que nunca saldrá de allí: salvo fallo de seguridad).

Sobre este pilar de criptografía matemática se fundamenta todo el protocolo TLS [2] (versión evolucionada del SSL), el cual proporciona una serie de intercambios para que el cliente que conecta con el servidor, pueda recibir y aceptar una serie de indicaciones que permite intercambiar mensajes de manera segura.

Sin embargo, aquí hay un “pero” y radica en esa parte “de intercambiar de manera segura” información.

La pata que le falta para completar SSL/TLS: la confianza

Lo único que asegura SSL/TLS es que el emisor y el receptor, una vez completada la negociación, podrán intercambiar mensajes con la seguridad de que sólo el emisor y el receptor son partícipes de la conversación: nadie podrá espiar mientras los mensajes están en tránsito.

Sin embargo, el gran problema a solucionar es el siguiente: ¿cómo asegurar que estamos hablando con el servidor que queremos y no otro que está interceptando la comunicación?

Ahí es donde entra la cadena de confianza y las certificadoras digitales que todos conocemos, como, por nombrar algunas: GeoTrust, Thawte, Verisign, Comodo…

¿Qué milla extra venían aportando las certificadoras?

Con todas las piezas técnicas sobre el tablero, la pieza que nos falta para completar el puzle son las compañias que tienen reputación, que
son conocidas previamente, y que debido a acuerdos previos, han consegido que sus certificados de firma –simplificando algo el proceso– estén reconocidos por la mayoría de navegadores.

Debido a que los navegadores aceptan y confian en estos certificados, todo lo que sea firmado por ellos, será también reconocido y aceptado
sin error.

¿Qué aporta Let’s encrypt?

La base fundacional del proyecto es: certificados gratis para todos. ¿Y sin tener que pagar a las autoridades de certificación legacy?

Sí. Entonces ¿cuál es el truco? No hay truco.

Sin embargo, hay que entender su origen para saber cuál es su objetivo.

Let’s encrypt es una iniciativa apoyada por grandes de la industria y que necesitan que sus dispositivos, intranets y portales de gestión, etc, puedan tener un certificado reconocido por todos los navegadores.

Después de todo, ¿qué impide a estas compañías llegar a los mismos acuerdos con los navegadores para que sus certificados sean reconocidos?

Combinando esta inclusión con un protocolo de validación y despliegue, let’s encrypt no sólo proporciona certificados que son totalmente reconocidos y sin costes: sino que automatiza la solicitud y configuración del certificado quitando al administrador la molesta tarea de solicitar y configurar un certificado.

Entonces, ¿desaparecerán las entidades de certificación?

En nuestra opinión, no. Se tendrán que especializar en emitir certificados que requieran una nueva milla adicional. También seguirán conservando la certificación de certificados para empresas y organismos. Ahí es donde let’s encrypt “no quiere llegar” (aunque podría).

[1] https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica
[2] https://es.wikipedia.org/wiki/Transport_Layer_Security

Posted in: Let's Encrypt, Seguridad, SSL/TLS

Leave a Comment (0) →