RedIRIS - Configuracion del Sendmail (IRISCF v 4.2)

3.3 Mecanismos de control de acceso

Estos mecanismos permiten, mediante el uso de tres directivas en el fichero-mc, el control de acceso a las funciones que sendmail ofrece como manejador de mensajes a los demas nodos de la Red. Estas directivas permiten:

Especificar si se desea realizar un control basado en las definiciones realizadas en cuanto al dominio interno y (en caso de que se empleen) los dominios virtuales, bien sobre el destinatario o sobre el remitente del mensaje. Para ello se emplea la directiva CHECKTYPE.
Definir que clase de comprobacion debe hacerse sobre el remitente o destinatario de un mensaje, segun lo especificado por CHECKTYPE. Para ello se emplean las directivas CHECKMODE y PWFILE.
Emplear un conjunto de ficheros especificos que detallan el modo de acceso permitido en cada caso, mediante la directiva CHECKMAP.

Estos mecanismos pueden utilizarse y combinarse de manera absolutamente independiente, de acuerdo con las politicas de control de acceso que cada organizacion desee seguir. Esto incluye tambien a las facilidades de control de acceso que sendmail incluye a partir de la version 8.9.0. En cualquier caso, hay ciertas reglas de precedencia que son consecuencia, por un lado, del funcionamiento del protocolo SMTP y, por otro, del esquema que impone sendmail para los mecanismos de control de acceso. Como es evidente, el que uno de estos procedimientos deje pasar un mensaje no implica que los demas lo hagan y, reciprocamente, si un mecanismo de control rechaza un mensaje es irrelevante que los mecanismos de aplicacion posterior lo hubieran aceptado. Las reglas de precedencia son las siguientes:

La aplicacion de los mecanismos de control de acceso se hace de acuerdo con el orden en que se lleva a cabo la transaccion SMTP: en primer lugar se aplican los relativos al nodo cliente, a continuacion los relativos al remitente del mensaje, en tercer lugar los que controlan el receptor del mensaje y, por ultimo, los que emplean el remitente y el receptor a la vez.
El esquema que impone sendmail implica que, para cada fase de la transaccion SMTP, se apliquen primero las reglas derivadas de directivas CHECKMAP, a continuacion las derivadas de CHECKTYPE y CHECKMODE, y por ultimo las correspondientes a las facilidades de control de acceso proporcionadas por sendmail.

Los "Mecanismos de seguridad basados en..." (del formulario de generacion) utilizan las directiva CHECKTYPE.Esta directiva CHECKTYPE admite un argumento, que puede ser la palabra "from" (para indicar que la validacion debe hacerse sobre las direcciones de los remitentes) o la palabra "to" (para indicar que la validacion debe hacerse sobre las direcciones de los destinatarios).

En el caso de CHECKTYPE(to) los mecanismos de control de acceso se aplican sobre la direccion incluida en el comando SMTP "RCPT to:". Los comandos no aceptados se rechazan con un codigo de "550 Relaying denied". En el caso de CHECKTYPE(to) se aplican sobre la direccion incluida en el comando SMTP "RCPT to:".
En el caso de CHECKTYPE(from) los mecanismos de control de acceso se aplican sobre la direccion incluida en el comando SMTP "MAIL from:". Los comandos no aceptados se rechazan con un codigo de "550 Unauthorized sender".

El "Ambito de comprobacion..."(del formulario de generacion) utilizan las directiva CHECKMODE

Para CHECKMODE(loose) los comandos SMTP son aceptados siempre que:
- La direccion sea local.
- La direccion sea del dominio interno.
- La direccion sea de un dominio virtual, si esta en uso.
- La direccion sea de cualquier subdominio del dominio interno.
- El cliente que mando el comando este en cualquier subdominio del dominio interno, para CHECKTYPE(to)
- El cliente que mando el comando este en cualquier subdominio de un dominio virtual (si se usan), para CHECKTYPE(to)
Para CHECKMODE(strict) los comandos SMTP son aceptados siempre que:
- La direccion sea local.
- La direccion sea del dominio interno.
- La direccion sea de un dominio virtual, si esta en uso.
- La direccion sea de un nodo del dominio interno.
- El cliente que mando el comando este en el dominio interno, para CHECKTYPE(to).
- El cliente que mando el comando este en un dominio virtual (si se usan), para CHECKTYPE(to).

Para ilustrar el uso de estas directivas supongamos una estafeta de nivel 1 que sirve al dominio virtual "dom.vir.es" y que requerimos que acepte correo para todos los subdominios del dominio interno. La configuracion que debemos de rellenar seria:

Nivel de la Estafeta: Nivel 1
Dominios virtuales para los que la Estafeta es responsable: dom.vir.es
Mecanismos de seguridad en la Estafeta basados en: Receptor(to)
Ámbito de comprobación: Exclusivamente el dominio

"Utilizar ficheros de control (mapas) para ..." (del formulario de generacion) implica el uso de a directiva CHECKMAP la cual acepta un identificador de mecanismo de control de acceso como argumento. Los identificadores validos para estos mecanismos, sus modos de empleo y sus caracteristicas los siguientes:

rejrelay Utiliza el contenido del fichero /etc/mail/rejrelay como una lista de nombres DNS y direcciones IP para los que se rechazaran conexiones. Cualquier comando SMTP que envie un nodo con un nombre DNS o una direccion IP incluido en el fichero sera rechazado con el codigo "550 Access denied". Los nombres y direcciones en /etc/mail/rejrelay pueden ser especificados de manera parcial. Cualquier nodo que este contenido en un dominio o una red que aparece en el fichero vera rechazados sus comandos SMTP.
Con un fichero /etc/mail/rejrelay con el siguiente contenido:
```
nodo.dominio.es
.otro-dominio.es
1.1.1.
		
```
sendmail rechazara cualquier comando SMTP enviado desde la maquina nodo.dominio.es o desde cualquier nodo en el dominio otro-dominio, ademas de rechazar los comandos que vengan de nodos en la red 1.1.1.0.
authfrom Emplea el contenido del mapa /etc/mail/authfrom para comprobar si los comandos SMTP "MAIL from:" (que especifican el remitente del sobre SMTP del mensaje) deben ser aceptados. El fichero fuente del mapa puede contener lineas de dos formas. La primera es:
```
["client:"][ < DireccionIP >|< NombreDNS >|"LOCAL"|"ALL" ] ["trust"|"allow"|"deny"]
```
que son aplicables a la direccion IP o nombre DNS del nodo que ha enviado el comando MAIL. Tanto DireccionIP como NombreDNS pueden especificar direcciones IP y nombres de dominio completos como parciales: en este caso, DireccionIP debe terminar por un punto y NombreDNS debe comenzar por un punto. "LOCAL" se aplica a las direcciones IP locales (0 y 127.0.0.1) y los nombres DNS reconocidos por sendmail como pertenencientes al nodo que lo esta ejecutando. "ALL" permite especificar una politica por defecto.La segunda es:
```
[ < DireccionEmail > | < NombreDNS > |"LOCAL"|"ALL"] ["allow"|"deny"]
```
que son aplicables a la direccion utilizada en el comando MAIL. DireccionEmail es una direccion completa de correo, NombreDNS es un nombre de dominio, bien completo o bien parcial (en cuyo caso debe comenzar por un punto), y los valores "LOCAL" y "ALL" pueden ser utilizados para definir una politica de acceso por defecto. El valor "LOCAL" corresponde a todas las direcciones de correo locales (es decir, que no vengan seguidas un sufijo de la forma "@dom.inio") y "ALL" corresponde a cualquier direccion, sea cual sea su formato.
El segundo campo en los dos tipos de lineas indica la accion a tomar.
Para las lineas aplicables al nodo cliente, "trust" implica aceptar el comando sin ninguna comprobacion adicional, "allow" indica que deben comprobarse las reglas especificadas para la direccion del remitente, y "deny" provoca que el comando sea directamente rechazado con el codigo "550 Acces denied". Si para una determinada combinacion de direccion IP y nombre DNS (incluyendo "ALL") no hay una regla "client:" adecuada en el mapa, se pasa a la comprobacion de las reglas para la direccion del remitente (esto es equivalente a "client:ALL allow"). Para las reglas aplicables a la direccion del remitente, "allow" implica aceptar el comando "MAIL from:", mientras que "deny" significa que el comando sera rechazado con el codigo "550 Access denied". Si para un determinado valor del argumento del comando no se encuentra una entrada adecuada en el mapa (incluyendo "LOCAL" y "ALL") el comando MAIL es aceptado por este procedimiento.
El empleo de un mapa implica que debe ser generado a partir del fichero fuente con el comando "makemap", dentro del directorio /etc/mail:

makemap hash authfrom < authfrom
Por ejemplo, dado un fichero /etc/mail/authfrom con las siguientes entradas:
```
client:.cero.es		trust
client:100.100.100.	trust
client:LOCAL		trust
client:ALL		allow
client:.spam.com	deny
uno.es			allow
.dos.es			allow
LOCAL			allow
alguien@uno.es		deny
ALL			deny
		
```
se aceptara cualquier comando MAIL que provenga de nodos en el dominio "cero.es", que tengan una direccion IP en la red 100.100.100.0 o que se hayan originado en el nodo local. Por otra parte, rechazara cualquier comando MAIL que venga de nodos en el dominio "spam.com". Cuando la conexion haya sido establecida por cualquier otro nodo, sendmail aceptara unicamente comandos MAIL que contengan direcciones locales de remitentes del mensaje, en el dominio "uno.es", y en cualquir subdominio de "dos.es" (sin incluir a "dos.es" en particular), mientras que rechazara cualquier otro comando, incluidos los que contengan como remitente la direccion "alguien@uno.es".
authto Funciona de forma absolutamente equivalente a "authfrom", actuando para el comando SMTP "RCPT to:" (la direccion del destinatario en el sobre SMTP del mensaje) y la direccion que se proporciona como parametro del comando. Utiliza el mapa /etc/mail/authto, cuyo fichero fuente tiene la misma sintaxis que la descrita en el caso anterior.
Para crear el mapa a partir del fichero fuente, debe utilizarse el comando "makemap" en el directorio /etc/mail:

makemap hash authto < authto
Por ejemplo, dado un fichero /etc/mail/authto con las siguientes entradas:
```
client:.cero.es		trust
client:100.100.100.	trust
client:LOCAL		trust
client:ALL		allow
client:.spam.com	deny
uno.es			allow
.dos.es			allow
LOCAL			allow
alguien@uno.es		deny
ALL			deny
		
```
sendmail aceptara cualquier comando RCPT que provenga de nodos en el dominio "cero.es", que tengan una direccion IP en la red 100.100.100.0 o que se hayan originado en el nodo local. Por otra parte, rechazara cualquier comando RCPT que venga de nodos en el dominio "spam.com".
Cuando la conexion haya sido establecida por cualquier otro nodo, sendmail aceptara unicamente comandos RCPT que contengan direcciones locales de destinatarios del mensaje, en el dominio "uno.es", y en cualquir subdominio de "dos.es" (sin incluir a "dos.es" en particular), mientras que rechazara cualquier otro comando, incluidos los que contengan como destinatario la direccion "alguien@uno.es".
authcompat Usa el contenido del mapa /etc/mail/authcompat para determinar si un mensaje puede progresar a traves de sendmail, a partir de las direcciones y los dominios a los que pertenezcan el remitente y el destinatario. El fichero fuente del mapa puede contener lineas de dos tipos:
```
"from:" [ < DireccionEmail > | < NombreDNS > |"LOCAL"|"ALL"] ["trust"|"allow"|"deny"]

"to:"[ < DireccionEmail > | < NombreDNS>|"LOCAL"|"ALL"] ["trust"|"allow"|"deny"]
```
Las lineas del primer tipo se aplican a la direccion del remitente y las del segundo tipo a la direccion del destinatario. Las mismas consideraciones relativas a "ALL", "LOCAL", "NombreDNS" y "DireccionEmail" discutidas mas arriba son aplicables aqui. Las reglas para decidir si un mensaje progresa o no a traves de sendmail son las siguientes:
- Si cualquiera de los dos direcciones da como resultado "trust", el mensaje es reenviado hacia su destino.
- Si no hay ningun valor "trust" y alguna de las direcciones (o la politica por defecto en cada caso) da como resultado "deny", el mensaje se rechaza con un codigo "554 Relay operation not allowed".
- Si no se obtiene ningun resultado para ninguna de los dos direcciones el mensaje es reenviado hacia su destino.
El empleo de un mapa implica que debe ser generado a partir del fichero fuente con el comando "makemap", dentro del directorio /etc/mail:
makemap hash authcompat < authcompat
Por ejemplo, dado un fichero /etc/mail/authcompat con las siguientes entradas:
```
from:alguien@uno.es	deny
to:alguien@uno.es	deny
from:uno.es		allow
to:uno.es		allow
from:.uno.es		allow
to:.uno.es		allow
from:ALL		deny
to:ALL			deny
		
```
sendmail solamente conmutara los mensajes con origen y destino dentro del dominio "uno.es", con excepcion de los que vayan hacia o desde "alguien@uno.es". Estos mensajes y todos los que no sean intradominio seran rechazados.
Otro ejemplo interesante es la posibilidad de limitar el uso de sendmail como estafeta de salida o de entrada para ciertos dominios. Dado un fichero /etc/mail/authcompat con el siguiente contenido:
```
from:uno.es		trust
to:uno.es		trust
from:LOCAL		trust
to:LOCAL		trust
from:ALL		deny
to:ALL			deny
		
```
sendmail solamente aceptara mensajes dirigidos a direcciones locales o que se encuentren en "uno.es", o que provengan de direcciones con las mismas caracteristicas.