Product SiteDocumentation Site

Capítulo 11. Servicios de red: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

11.1. Servidor de correo
11.1.1. Instalación de Postfix
11.1.2. Configuración de dominios virtuales
11.1.3. Restricciones para recibir y enviar
11.1.4. Configuración de «listas grises» (greylisting)
11.1.5. Personalización de filtros basados en el receptor
11.1.6. Integrating an Antivirus Filter
11.1.7. Luchando contra el spam con SPF, DKIM y DMARC
11.1.8. SMTP autenticado
11.2. Servidor web (HTTP)
11.2.1. Instalación de Apache
11.2.2. Añadiendo soporte para SSL
11.2.3. Configuración de servidores virtuales («virtual hosts»)
11.2.4. Directivas comunes
11.2.5. Analizadores de registros
11.3. Servidor de archivos FTP
11.4. Servidor de archivos NFS
11.4.1. Protección de NFS
11.4.2. Servidor NFS
11.4.3. Cliente NFS
11.5. Configuración de espacios compartidos Windows con Samba
11.5.1. Servidor Samba
11.5.2. Cliente Samba
11.6. Proxy HTTP/FTP
11.6.1. Instalación
11.6.2. Configuración de un caché
11.6.3. Configuración de un filtro
11.7. Directorio LDAP
11.7.1. Instalación
11.7.2. Relleno del directorio
11.7.3. Administración de cuentas con LDAP
11.8. Servicios de comunicación en tiempo real
11.8.1. Parámetros DNS para los servicios RTC
11.8.2. Servidor TURN
11.8.3. Servidor Proxy SIP
11.8.4. Servidor XMPP
11.8.5. Servicios corriendo en el puerto 443
11.8.6. Agregando WebRTC
Los servicios de red son los programas con los que los usuarios interactúan en su trabajo diario. Son la punta del iceberg del sistema de información y este capítulo se centra en ellos; las partes ocultas en las que se basan son la infraestructura que ya hemos descripto anteriormente. Normalmente requieren la tecnología de cifrado descrita en Sección 10.2, “Certificados X.509”.

11.1. Servidor de correo

Los administradores de Falcot Corp eligieron Postfix como servidor de correo electrónico debido a su fiabilidad y su facilidad de configuración. De hecho, su diseño fuerza a que cada tarea sea implementada en un proceso con el mínimo conjunto de permisos, lo que es una gran medida paliativa contra problemas de seguridad.

11.1.1. Instalación de Postfix

El paquete postfix incluye el demonio SMTP principal. Otros paquetes (como postfix-ldap y postfix-pgsql) añaden funcionalidad adicional, incluyendo el acceso a bases de datos. Sólo debe instalarlos si sabe que los necesitará.
Durante la instalación del paquete se realizan varias preguntas Debconf. Las respuestas permiten crear una primera versión del archivo de configuración /etc/postfix/main.cf.
La primera pregunta es sobre el tipo de instalación. Sólamente dos de las respuestas propuestas son relevantes en caso de tener un servidor conectado a Internet: «Sitio de Internet» e «Internet con smarthost». La primera es apropiada para un servidor que recibe correo entrante y envía el correo saliente directamente a los destinatarios, y por lo tanto se adapta al caso del Falcot Corp. La segunda es apropiada para un servidor que recibe correo de forma normal pero que envía el correo saliente a través de otro servidor SMTP intermedio — el «smarthost» — en lugar de enviarlo directamente al servidor de los destinatarios. Esto es especialmente útil para individuos con una dirección IP dinámica puesto que muchos servidores de correo rechazan los mensajes que vienen desde este tipo de dirección. En este caso, el smarthost es normalmente el servidor SMTP del ISP que siempre suele estar configurado para aceptar los correos provenientes de sus clientes y reenviarlos correctamente. Este tipo de instalación (con un smarthost) también es útil para servidores que no estén conectados permanentemente a Internet puesto que impide tener que gestionar una cola de mensajes no entregables que tienen que volver a ser enviados más tarde.
La segunda pregunta es sobre el nombre completo de la máquina y se utiliza para generar las direcciones de correo a partir de los nombres de usuario locales; el nombre completo de la máquina se convierte en la parte de la dirección que sigue a la arroba («@»). En el caso de Falcot, la respuesta debería ser mail.falcot.com. Esta es la única pregunta que se hace de forma predeterminada, pero la configuración que genera no es lo suficientemente completa para las necesidades de Falcot, por lo que los administradores deben ejecutar dpkg-reconfigure para poder personalizar más parámetros.
Una de las preguntas adicionales pide los nombres de los dominios relacionados con la máquina. La lista inicial incluye su nombre completo así como también algunos sinónimos de localhost, pero el dominio principal falcot.com tiene que ser agregado de forma manual. En general se deberían añadir todos los dominios para los que esta máquina debe ejercer como servidor MX; en otras palabras, todos los dominios para los cuales el DNS anuncie que esta máquina aceptará correo. Esta información acaba siendo escrita en la variable mydestination del archivo de configuración principal de Postfix — /etc/postfix/main.cf.
Rol del registro DNS MX al enviar un correo

Figura 11.1. Rol del registro DNS MX al enviar un correo

En algunos casos, la instalación también puede preguntar desde qué redes se permitirá enviar correo a través de la máquina. En la configuración predeterminada, Postfix únicamente acepta correos que provengan desde la propia máquina; normalmente agregará la red local. Los administradores de Falcot Corp añadieron la red 192.168.0.0/16 al valor predeterminado. Si no se realiza esta pregunta durante la instalación, la variable de configuración correspondiente es mynetworks, tal y como puede verse en el ejemplo siguiente.
El correo local también puede ser entregado mediante procmail. Esta herramienta permite a los usuarios clasificar su correo en función de reglas contenidas en su archivo ~/.procmailrc. Tanto Postfix y Exim4 sugieren procmail por defecto, pero hay alternativas comomaildrop o filtros Sieve.
Después de este paso, los administradores obtuvieron el siguiente archivo de configuración; será usado en las siguientes secciones como punto de partida para agregar alguna funcionalidad adicional.

Ejemplo 11.1. Archivo /etc/postfix/main.cf inicial

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

11.1.2. Configuración de dominios virtuales

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

11.1.2.1. Alias de dominio virtual

Un «alias de dominio virtual» («virtual alias domain») únicamente contiene alias, es decir direcciones que únicamente reenvían los correos hacia otras direcciones.
Para habilitar un dominio de este tipo, agregue su nombre a la variable virtual_alias_domains y establezca un archivo de traducción de direcciones en la variable virtual_alias_maps.
virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
El archivo /etc/postfix/virtual describe la relación con una sintaxis muy sencilla: cada línea contiene dos campos separados por espacios en blanco; el primer campo es el nombre del alias y el segundo es una lista de las direcciones de correo a las que se redirigen. La sintaxis especial @dominio.com abarca todos los alias pertenecientes a un dominio.
webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# El alias siguiente es genérico y abarca todas las direcciones
# del dominio falcotsbrand.com que no están incluidas explícitamente
# en este archivo.
# Estas direcciones reenvían el correo al usuario con el mismo nombre
# del dominio falcot.com
@falcotsbrand.com           @falcot.com
Después de cambiar /etc/postfix/virtual, la tabla postfix /etc/postfix/virtual.db necesita ser actualizada utilizando sudo postmap /etc/postfix/virtual.

11.1.2.2. Casillas de dominio virtual

Los mensajes dirigidos a una casilla de dominio virtual son almacenados en casillas que no están asignadas a un usuario local del sistema.
Activar una casilla de dominio virtual requiere agregar este dominio en la variable virtual_mailbox_domains y hacer referencia a un archivo de asociación de casillas en virtual_mailbox_maps. El parámetro virtual_mailbox_base contiene el directorio en el que se almacenarán todas las casillas.
virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
El parámetro virtual_uid_maps (o virtual_gid_maps respectivamente) hace referencia al archivo que contiene la asociación entre las direcciones de correo y el usuario de sistema (o grupo respectivamente) «dueño» de la casilla correspondiente. Para lograr que todas las casillas pertenezcan al mismo usuario/grupo, la sintaxis static:5000 asigna un UID/GID fijo (aquí el valor 5000).
Nuevamente, la sintaxis del archivo /etc/postfix/vmailbox es bastante directo: dos campos separados con espacios en blanco. El primer campo es una dirección de correo en alguno de los dominios virtuales y el segundo campo es la ubicación de la casilla asociada (relativa al directorio especificado en virtual_mailbox_base). Si el nombre de la casilla finaliza con una barra (/), se almacenarán los correos en formato maildir; de lo contrario se utilizará el formato mbox tradicional. El formato maildir utiliza un directorio completo para almacenar una casilla, cada mensaje individual es almacenado en un archivo separado. Por el otro lado, en el formato mbox se almacena toda la casilla en un archivo y cada línea que comience con «From (From es seguido por un espacio) indica el comienzo de un nuevo mensaje.
# Se almacena el correo de Jean como maildir, con
# un archivo por correo en un directorio dedicado
jean@falcot.org falcot.org/jean/
# Se almacena el correo de Sophie en un archivo
# «mbox» tradicional con todos los correos
# en un solo archivo
sophie@falcot.org falcot.org/sophie

11.1.3. Restricciones para recibir y enviar

La cantidad creciente de correo masivo no solicitado (spam) hace necesario ser cada vez más estricto al decidir qué correos debe aceptar un servidor. Esta sección presenta alguna de las estrategias incluidas en Postfix.
Si las reglas de rechazo son demasiado estrictas, puede ocurrir que incluso que se bloquee tráfico de correo electrónico legítimo. Es por eso un buen hábito comprobar las restricciones y evitar el rechazo permanente de peticiones durante este tiempo usando la directiva soft_bounce = yes. Al preceder una directiva de dirección con warn_if_reject, solo se registra un mensaje en vez de rechazar la petición.

11.1.3.1. Restricciones de acceso basadas en IP

La directiva smtpd_client_restrictions controla qué máquinas pueden comunicarse con el servidor de correo.
Cuando una variable contiene una lista de reglas, como en el siguiente ejemplo, estas reglas son evaluadas en orden desde la primera hasta la última. Cada regla puede aceptar el mensaje, rechazarlo o dejar la decisión de qué hacer a reglas posteriores. Por lo tanto, el orden importa y cambiar el orden en el que están establecidas las reglas puede provocar un comportamiento completamente diferente.

Ejemplo 11.2. Restricciones basadas en la dirección del cliente

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net
La directiva permit_mynetworks, como primera regla, acepta todos los correos que provienen de equipos en la red local (definida por la variable de configuración mynetworks).
La segunda directiva normalmente rechazará correos que provienen de equipos sin una configuración de DNS completamente válida. Esta configuración válida significa que la dirección IP está asociada a un nombre y que este nombre, además, resuelve a dicha dirección IP. Generalmente, esta restricción es demasiado estricta ya que muchos servidores de correo no tienen un DNS inverso para su dirección IP. Esto explica porqué los administradores de Falcot agregaron el modificador warn_if_reject antes de la directiva reject_unkown_client: este modificador convierte el rechazo en una simple advertencia guardada en los registros. Los administradores pueden revisar la cantidad de mensajes que hubiesen sido rechazados si esta regla hubiese sido aplicada y luego tomar decisiones informadas si desean activarla.
The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.
Las últimas cuatro reglas rechazan cualquier mensaje que provenga de un servidor incluido en una de las listas negras indicadas. RBL es un acrónimo de Remote Black List (lista negra remota), y RHSBL que significa Right-Hand Side Black List (lista negra del lado derecho). La diferencia es que la última lista direcciones IP, mientras que la primera lista nombres de dominios. Hay varios servicios de este tipo. Listan dominios y direcciones IP con mala fama, servidores mal configurados que los spammers utilizan para redirigir sus correos, así como equipos que no siendo servidores de correo legítimos están infectados con algún gusano o virus y actúan como tales.

11.1.3.2. Revisión de la validez de las órdenes EHLO o HELO

Cada intercambio SMTP comienza con una orden HELO (o EHLO), seguido del nombre del servidor de correo que envía. Puede ser interesante comprobar la validez de este nombre. Para hacer cumplir las restricciones listadas en smtpd_helo_restrictions totalmente, la opción smtpd_helo_required necesita estar habilitada. De lo contrario, los clientes se saltarían las restricciones sin enviar ninguna orden HELO/EHLO.

Ejemplo 11.3. Restricciones en el nombre anunciado con EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org
La primera directiva permit_my_networks permite que todas las máquinas en la red local se presenten libremente. Esto es importante ya que algunos programas de correo no respetan esta parte del protocolo SMTP de forma suficientemente correcta y pueden presentarse a sí mismos con nombres sin sentido.
The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
reject_rhsbl_helo permite especificar una lista negra para comprobar el nombre del equipo en una RHSBL.
Utilizar permit_mynetworks como la primera regla tiene un efecto secundario interesante: las reglas siguientes sólo serán aplicadas a los equipos fuera de la red local. Esto permite rechazar todos los equipos que se anuncien a sí mismos como parte de la red falcot.com, por ejemplo agregando una línea falcot.com REJECT ¡No es parte de nuestra red! en el archivo /etc/postfix/access_helo.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Cada mensaje tiene un remitente anunciado con la orden MAIL FROM del protocolo SMTP; nuevamente, puede validar esta información de varias formas.

Ejemplo 11.4. Verificación de remitente

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net
La tabla /etc/postfix/access_sender asocia algún tratamiento especial a algunos remitentes. Esto generalmente significa enumerar algunos remitentes en una lista negra o blanca.
The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.
Finalmente, la regla reject_non_fqdn_sender rechaza los correos que dicen provenir de direcciones sin un nombre de dominio completamente calificado. En la práctica significa rechazar correos que provienen de usuario@equipo: la dirección debe anunciarse como usuario@equipo.example.com o usuario@example.com.
La regla reject_rhsbl_sender rechaza remitentes en base al servicio (basado en dominios) RHSBL.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Cada correo tiene al menos un receptor, anunciado con la orden RCPT TO en el protocolo SMTP. Estas direcciones también requieren validación, aún si pueden ser menos relevantes que las verificaciones realizadas en la dirección del remitente.

Ejemplo 11.5. Verificación de receptor

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit
reject_unauth_destination es la regla básica que requiere que los mensajes externos estén destinados a nosotros; se rechazarán los mensajes que sean enviados a una dirección que no sea gestionada por este servidor. Sin esta regla, el servidor se convierte en una forma abierta de reenvío que permite que los spammers envíen correos no solicitados; por lo tanto esta regla es obligatoria y preferentemente debe estar ubicada cerca del principio de la lista para evitar que otras reglas autoricen el mensaje antes que se verifique su destino.
La regla reject_unlisted_recipient rechaza los mensajes enviados a usuarios locales que no existen, lo que tiene sentido. Finalmente, la regla reject_non_fqdn_recipient rechaza direcciones que no sean completamente calificadas; esto hace imposible enviar un correo a jean o jean@equipo y necesita, en cambio, utilizar la dirección completa como literal@equipo.falcot.com o jean@falcot.com.
La directiva permit al final no es necesaria. Pero puede ser útil al final de una lista de restricciones para hacer la explícita la política predeterminada.

11.1.3.5. Restricciones asociadas con la orden DATA

Se emite la orden DATA en SMTP antes del contenido del mensaje. No provee ninguna información en sí misma además de anunciar lo que seguirá. Todavía puede ser sujeta a verificación.

Ejemplo 11.6. Verificación de DATA

smtpd_data_restrictions = reject_unauth_pipelining
Las directivas reject_unauth_pipelining causa que se rechace el mensaje si el remitente envía una orden antes que se envía la respuesta a la orden anterior. Esto previene una optimización común utilizada por los robots de spammers ya que no tienen el menor interés en las respuestas y sólo están interesados en enviar tantos correos como sea posible en el menor tiempo posible.

11.1.3.6. Implementación de restricciones

Si bien las órdenes anteriores validan la información en las varias etapas del intercambio SMTP, Postfix sólo envía el rechazo en sí como respuesta a la orden RCPT TO por defecto.
Esto significa que aún si se rechaza el mensaje debido a una orden EHLO no válida, Postfix conoce el remitente y el receptor cuando anuncia un rechazo. Luego puede registrar un mensaje más explícito de lo que podría si se hubiera interrumpido la transacción al comienzo. Además, una cantidad de clientes SMTP no esperan fallos en las primeras órdenes de SMTP y estos clientes no se molestarán tanto por este rechazo tardío.
Una ventaja final de esta opción es que las reglas pueden acumular información durante las varias etapas del intercambio SMTP; esto permite definir permisos más precisos, como rechazar conexiones remotas si se anuncia como un remitente local.
La regla smtpd_delay_reject controla el comportamiento por defecto.

11.1.3.7. Filtros basados en el contenido del mensaje

El sistema de validación y restricción no estaría completo sin una forma de realizar verificaciones en el contenido de los mensajes. Postfix diferencia las verificaciones en las cabeceras del correo de aquellas sobre el cuerpo del mensaje.

Ejemplo 11.7. Habilitación de filtros basados en contenido

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
Ambos archivos contienen una lista de expresiones regulares (normalmente conocidas como regexps o regexes) y las acciones asociadas que se deben disparar cuando las cabeceras (o cuerpo) del mensaje coincida con la expresión.

Ejemplo 11.8. Archivo /etc/postfix/header_checks de ejemplo

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Su email contiene VIRUS/ DESCARTAR notificación de virus
El primero revisa la cabecera que menciona el software de correo; si es GOTO Sarbacane (un software en correo masivo), el mensaje es rechazado. La segunda expresión revisa el asunto del mensaje; si menciona una notificación de virus podemos decidir no rechazar el mensaje sino, en cambio, descartarlo inmediatamente.
Utilizar estos filtros es un arma de doble filo ya que es sencillo crear reglas demasiado genéricas y, en consecuencia, perder correos legítimos. En estos casos, no sólo se perderán los mensajes sino que sus remitentes recibirán mensajes de error no deseados (y molestos).

11.1.4. Configuración de «listas grises» (greylisting)

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.
Postfix no provee listas grises de forma nativa, pero posee una funcionalidad en la que la decisión de aceptar o rechazar un mensaje dado puede ser delegada a un programa externo. El paquete postgrey contiene dicho programa, diseñado para interactuar con su servicio de delegación de políticas de acceso.
Una vez que instaló postgrey, éste se ejecutará como un demonio que escucha en el puerto 10023. Luego puede configurar postfix para utilizarlo si agrega el parámetro check_policy_service como una restricción adicional:
smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.
La principal desventaja de las listas grises es que demorará mensajes legítimos, lo que no siempre es aceptable. También aumenta la carga en los servidores que envían muchos correos legítimos.

11.1.5. Personalización de filtros basados en el receptor

Sección 11.1.3, “Restricciones para recibir y enviar” y Sección 11.1.4, “Configuración de «listas grises» (greylisting)” revisaron muchas de las restricciones posibles. Todas son útiles para limitar la cantidad de spam recibido, pero también tienen su desventajas. Por lo tanto, es más y más común, personalizar el conjunto de filtros según el receptor. En Falcot Corp, las listas grises son interesantes para la mayoría de los usuarios pero entorpece el trabajo de algunos usuarios que necesitan una latencia baja en sus correos (como el servicio de soporte técnico). De forma similar, el servicio comercial a veces tiene problemas para recibir correos de algunos proveedores asiáticos que pueden encontrarse en listas negras; este servicio solicitó una dirección sin filtros para poder intercambiar correspondencia.
Postfix provee tal personalización de filtros con el concepto de «clases de restricción». Declarará las clases en el parámetro smtpd_restriction_classes de la misma forma que smtpd_recipient_restrictions. La directiva check_recipient_access define luego una tabla que asocia un receptor dado con el conjunto de restricciones apropiadas.

Ejemplo 11.9. Definición de clases de restricción en main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Ejemplo 11.10. El archivo /etc/postfix/recipient_access

# Direcciones sin filtro
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Filtros agresivos para algunos usuarios privilegiados
joe@falcot.com         aggressive

# Regla especial para el administrador de la lista de correos
sympa@falcot.com       reject_unverified_sender

# Listas grises de forma predeterminada
falcot.com             greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.
The Falcot administrators selected clamav from the homonymous package.
La tarea de interactuar entre el antivirus y el servidor de correo le corresponde a clamav-milter. Un «milter» (apócope de «filtro de correo»: «mail filter») es un programa de filtrado diseñado especialmente para interactuar con servidores de correo. Un milter utiliza una interfaz de programación de aplicaciones (API: «Application Programming Interface») que provee un rendimiento mucho mejor que los filtros ajenos a los servidores de correo. Sendmail introdujo inicialmente a los milters, pero Postfix los implementó poco después.
Una vez que instaló el paquete clamav-milter, debería reconfigurar el milter para que ejecute en un puerto TCP en lugar del zócalo con nombre predeterminado. Puede lograr esto ejecutando dpkg-reconfigure clamav-milter. Cuando se le pregunte por la «Interfaz de comunicación con Sendmail», responda «inet:10002@127.0.0.1».
La configuración estándar de ClamAV se ajusta a la mayoría de las situaciones, pero puede personalizar algunos parámetros importantes con dpkg-reconfigure clamav-base.
El último paso involucra decirle a Postfix que utilice el filtro recientemente configurado. Esto es tan simple como agregar la siguiente directiva a /etc/postfix/main.cf:
# Revisión de virus con clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
Si el antivirus causa problema, puede comentar esta línea; deberá ejecutar systemctl reload postfix para que se tenga en cuenta el cambio.
Todos los mensajes gestionados por Postfix ahora pasarán a través del filtro antivirus.

11.1.7. Luchando contra el spam con SPF, DKIM y DMARC

El gran número de correos no solicitados enviados cada día ha llevado a la creación de varios estándares, que tratan corroborar que el equipo que envía un mensaje está autorizado y que no se ha manipulado el correo. Los siguientes sistemas están todos basados en DNS y requieren no solo que los administradores tengan control sobre el servidor de correo, sino también sobre el DNS para el dominio en cuestión.

11.1.7.1. Ingrando el Convenio de Remitentes (Sender Policy Framework [SPF])

El Convenio de Remitentes (SPF en inglés) se usa para comprobar si se permite a un determinado servidor de correo enviar correos para un dominio determinado. Se configura principalmente mediante DNS. Se sintaxis de la entrada a realizar se explica con detalle en:
The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.
Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all
Echemos un vistazo rápido a la entrada de falcot.org.
# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
Indica que la IP del remitente debe coincidir con el registro A para el dominio que envía, debe estar listada en uno de los Mail Exchange Resource Records para el dominio actual, o debe ser una de las tres direcciones IP4 mencionadas. Todos los demás equipos deben marcarse como que no se les permite enviar correo al dominio del remitente. Lo último se llama un «fallo suave» y está pensado para marcar el correo como corresponde, pero todavía aceptarlo.
El servidor de correo postfix puede comprobar el registro SPF para correos entrantes usando el paquete postfix-policyd-spf-python, un intermediario de normas escrito en Python. El archivo /usr/share/doc/postfix-policyd-spf-python/README.Debian describe los pasos necesarios para integrar en postfix el intermediario, así que no lo repetiremos aquí.
La configuración se realiza en el archivo /etc/postfix-policyd-spf-python/policyd-spf.conf, que está documentado de forma completa en policyd-spf.conf(5) y /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Los parámetros de configuración principales son HELO_reject y Mail_From_reject, que configuran si los correos deberían ser rechazados (Fail) o aceptados precediendo una cabecera (False), si las comprobaciones fallan. Lo último es muchas veces útil cuando el mensaje todavía se procesará por un filtro de spam.
Si el resultado está pensado para usarse por opendmarc (Sección 11.1.7.3, “Integrando Autenticación de Mensajes Basada en Dominios, Informes y Conformidad (DMARC, en inglés)”), debería darle a Header_Type el valor AR.
Tenga en cuenta que spamassassin contiene un complemento para comprobar el registro SPF.

11.1.7.2. Integrando DomainKeys (DKIM) Firmando y Comprobando

El estándar Domain Keys Identified Mail (DKIM) es un sistema de autentificación del remitente. El transporte de agente de correo, aquí postfix, añade una firma digital asociada con el nombre de dominio a la cabecera de los correos salientes. La parte receptora puede validar el cuerpo del mensaje y los archivos de cabecera comprobando la firma con una clave pública, que se recibe de los registros de los DNS de los remitentes.
Las herramientas necesarias se incluyen en los paquetes opendkim y opendkim-tools.
Primero debe crearse la clave privada con la orden opendkim-genkey -s SELECTOR -d DOMINIO. SELECTOR debe ser un nombre único para la clave. Puede ser tan simple como «correo» o la fecha de creación, si tiene pensado alternar las claves.

Ejemplo 11.11. Crear una clave privada para firmar los correos de falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*
Esto creará los archivos /etc/dkimkeys/mail.private y /etc/dkimkeys/mail.txt y asignará la propiedad apropiada. El primer archivo contiene la clave privada, y el último la clave pública que necesita añadirse al DNS:
Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
El paquete opendkim en Debian tiene un tamaño de clave predeterminado de 2048 bits. Por desgracia algunos servidores DNS solo manejan entradas de texto con una longitud máxima de 255 caracteres, lo cual es excedido por el tamaño de clave predeterminado elegido. En este caso, use la opción -b 1024 para elegir un tamaño de clave más pequeño. Si opendkim-testkey tiene éxito, la entrada se ha ajustado correctamente. Aquí se explica la sintaxis de la entrada:
Para configurar opendkim, se deben elegir SOCKET y RUNDIR en /etc/default/opendkim. Tenga en cuenta que SOCKET debe ser accesible desde postfix en su entorno con chroot. La configuración adicional se realiza en /etc/opendkim.conf. Lo que sigue es un extracto de configuración, que se asegura de que Domain "falcot.com" y todos los subdominios (SubDomain) están firmados por el Selector "mail" y la única clave privada (KeyFile) /etc/dkimkeys/mail.private. La Canonicalization "relaxed" para tanto la cabecera como el cuerpo tolera una modificación ligera (por el software de una lista de correo, por ejemplo). El filtro se ejecuta tanto en modo (Mode) de firmado ("s" de signing) como de verificación ("v"). Si una firma falla al validar (On-BadSignature), el correo debería ponerse en cuarentena ("q" de quarantine).
[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim
También es posible usar varios selectores/claves (KeyTable), dominios (SigningTable) y especificar equipos internos o de confianza (InternalHosts, ExternalIgnoreList), lo que puede enviar correo mediante el servidor como uno de los dominios que firman sin credenciales.
Las siguientes directivas en /etc/postfix/main.cf hacen que postfix use el filtro:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345
Para diferenciar el firmado y la verificación a veces es más útil añadir en su lugar las directivas a los servicios en /etc/postfix/master.cf.
Hay más información disponible en el directorio /usr/share/doc/opendkim/ y en las páginas de manual opendkim(8) y opendkim.conf(5).
Tenga en cuenta que spamassassin contiene un plugin para comprobar el registro DKIM.

11.1.7.3. Integrando Autenticación de Mensajes Basada en Dominios, Informes y Conformidad (DMARC, en inglés)

El estándar Autenticación de Mensajes Basada en Dominios, Informes y Conformidad (DMARC, en inglés) puede usarse para definir una entrada DNS TXT con el nombre _dmarc y la acción que se debería tomar cuando los correos que contienen su dominio como el equipo remitente fallen al validar usando DKIM y SPF.
Echemos un vistazo a las entradas de dos grandes proveedores:
# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
Yahoo tiene una política estricta para rechazar (reject) todos los correos que aparentan enviarse desde Yahoo, pero fallan las comprobaciones DKIM y SPF. Google Mail (Gmail) propaga una política muy relajada en la que tales mensajes del dominio principal aún deben aceptarse (p=none). Para subdominios deben marcarse como spam (sp=quarantine). A las direcciones dadas en la clave rua se les puede enviar informes agregados DMARC. La sintaxis completa se explica aquí:
El servidor de correo postfix puede usar también esta información. El paquete opendmarc contiene el filtro de correo necesario. De forma similar a opendkim, SOCKET y RUNDIR deben elegirse en /etc/default/opendmarc (para zócalos de Unix debe asegurarse de que se pueden encontrar dentro del chroot de postfix). El archivo de configuración /etc/opendmarc.conf contiene comentarios detallados, y también se explica en opendmarc.conf(5). Por defecto, los correos que fallan la validación DMARC no se rechazan, sino se marcan añadiendo un campo de cabecera apropiado. Para cambiar esto, use RejectFailures true.
El filtro de correo se añade entonces a smtpd_milters y non_smtpd_milters. Si configuramos los filtros de correo opendkim y opendmarc para funcionar en los puertos 12345 y 54321, la entrada en /etc/postfix/main.cf tiene este aspecto:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321
En su lugar, el milter también se puede aplicar selectivamente en /etc/postfix/master.cf.

11.1.8. SMTP autenticado

Para poder enviar correos es necesario poder acceder a un servidor SMTP; también requiere que dicho servidor SMTP permita el envío de correos. Para usuarios móviles, puede ser necesario cambiar la configuración de su cliente SMTP regularmente, ya que el servidor SMTP de Falcot rechaza los mensajes que provienen de direcciones IPs que no parecen pertenecer a la compañía. Existen dos soluciones: o bien los usuarios móviles instalan un servidor SMTP en sus equipos, o utilizan el servidor de la compañía con alguna forma de autenticarse como empleados. No se recomienda la primera solución ya que el equipo no estará conectado permanentemente y no podrá volver a intentar enviar mensajes en caso de problemas; nos centraremos en la última solución.
La autenticación SMTN en Postfix depende de SASL (capa de seguridad y autenticación simple: «Simple Authentication and Security Layer»). Necesitará instalar los paquetes libsasl2-modules y sasl2-bin, y luego registrar una contraseña en la base de datos SALS para cada usuario que necesite autenticarse en el servidor SMTP. Puede hacerlo con el programa saslpasswd2 que toma varios parámetros. La opción -u define el dominio de autenticación, que debe coincidir con el parámetro smtpd_sasl_local_domain en la configuración de Postfix. La opción -c permite crear un usuario y la opción -f permite especificar el archivo a utilizar si necesita almacenar la base de datos SALS en una ubicación diferente a la predeterminada (/etc/sasldb2).
# saslpasswd2 -u `postconf -h myservidor` -f /var/spool/postfix/etc/sasldb2 -c jean
[... ingrese la contraseña de jean dos veces ...]
Note que se creó la base de datos SASL en el directorio de Postfix. Para poder asegurar consistencia, también convertimos /etc/sasldb2 en un enlace simbólico que apunta a la base de datos utilizada por Postfix con ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
Ahora necesitamos configurar Postfix para que utilice SASL. Primero necesita agregar al usuario postfix al grupo sasl para que pueda acceder a la base de datos SASL. También necesitará agregar algunos parámetros nuevos para activar SASL y necesita configurar el parámetro smtpd_recipient_restrictions para permitir que los clientes autenticados por SASL puedan enviar correos libremente.

Ejemplo 11.12. Activación de SASL en /etc/postfix/main.cf

# Activar autenticación SASL
smtpd_sasl_auth_enable = yes
# Definir el dominio de autenticación SASL
smtpd_sasl_local_domain = $myhostname
[...]
# Agregar permit_sasl_authenticated antes de reject_unauth_destination
# permite reenviar correos enviados por usuarios autenticados por SASL
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]
Normalmente es buena idea no enviar contraseñas en una conexión no cifrada. Postfix permite usar diferentes configuraciones para cada puerto (servicio) en el que se ejecuta. Todas ellas pueden configurarse con diferentes reglas y directivas en el archivo /etc/postfix/master.cf. Para desactivar la autentificación por completo para el puerto 25 (servicio smtpd) añada la siguiente directiva:
smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]
Si por alguna razón los clientes usan una orden AUTH desactualizada (algunos clientes de correo muy viejos lo hacen), se puede habilitar la interoperabilidad con estos usando la directiva broken_sasl_auth_clients.