Seguridad en Unix y redes - El servicio SMTP

El servicio SMTP (Simple Mail Transfer Protocol, puerto 25 TCP) se utiliza para transferir correo electrónico entre equipos remotos; estas máquinas pueden ubicarse físicamente en la misma sala, en la misma universidad, o en la otra parte del mundo, a miles de kilómetros de distancia. Este servicio suele ser atendido por un demonio denominado sendmail, que ha sido uno de los que más problemas de seguridad ha tenido a lo largo de la historia de Unix; y no es para menos: se trata de un software muy complejo y potente - incluso demasiado para las necesidades de la mayoría de servidores -, por lo es inevitable que en su código existan bugs; para hacernos una idea del grado de complejidad de sendmail simplemente tenemos que echarle un vistazo a su fichero de configuracion principal, /etc/sendmail.cf. Existen incluso libros casi dedicados exclusivamente a este archivo ([CA97a], [CA97b]...).

---

Una medida de protección básica para nuestro servicio SMTP, y que muchos administradores desconocen, es la posibilidad de servir sendmail desde inetd en lugar de hacerlo como un demonio independiente, y por tanto poder restringir el acceso al mismo mediante TCP Wrappers. En la mayoría de organizaciones existe un servidor de correo principal que es el encargado de recoger el mail para todas las direcciones `*@*.upv.es'; el resto de equipos sólo recibirán correo desde este equipo - o desde otro que sirve sólo a un subdominio, y que a su vez recibe sólo desde el principal -. Entonces, parece claro que si nuestro sendmail sólo recibe correo válido desde una máquina, lo lógico es configurarlo para que sólo acepte peticiones desde ella: en lugar de lanzar el demonio al arrancar el sistema, en uno de los scripts de /etc/rc.d/ o similar, lo serviremos desde inetd. Para esto necesitamos en primer lugar modificar el script correspondiente para que sendmail no se lance como demonio en el arranque: en lugar de invocarlo como `sendmail -bd -q15m' lo haremos como `sendmail -q15m'. Ademas, es necesario identificar el servicio en /etc/services, con una línea como la siguiente:
luisa:~# grep smtp /etc/services smtp 25/tcp mail luisa:~#

Tras reconocer el servicio, hemos de añadir una línea en /etc/inetd.conf indicando cómo se ha de ejecutar sendmail cuando inetd reciba una petición en el puerto 25; dicha línea es similar a la siguiente:

luisa:~# grep smtp /etc/inetd.conf smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs luisa:~#

Una vez realizados estos cambios podemos controlar el acceso a nuestro servicio SMTP mediante TCP Wrappers; por ejemplo, en el caso de la Universidad Politécnica, el servidor de correo principal se denomina vega.cc.upv.es. Para que sólo esta máquina nos pueda enviar correo, incluiremos una línea como la siguiente en /etc/hosts.allow:

luisa:~# grep sendmail /etc/hosts.allow sendmail: vega.cc.upv.es luisa:~#

El resto de sistemas no han de estar autorizados a conectar al puerto; esto incluye también a la máquina local: para un correcto funcionamiento de nuestro sistema de correo, ni siquiera hace falta que localhost tenga permiso para acceder a su puerto 25. En [Gon97] se explica cómo combinar estas restricciones ofrecidas por TCP Wrappers con un cortafuegos como TIS Firewall Toolkit; en esta obra también se habla con más detalle de los problemas que puede implicar el correo electrónico, y por supuesto de cómo solucionarlos.

---

Evidentemente, esto es aplicable a sistemas que reciban correo de un único mailer; si debemos configurar el propio mailer de la organización, que por lo general recibirá correo de un número indeterminado de máquinas, no podemos bloquear el acceso a su sendmail de esta forma. No obstante, en este caso podemos aplicar unas medidas de seguridad simples, como realizar una consulta inversa a DNS para asegurarnos de que sólo máquinas registradas envían correo o no permitir que nuestro sistema reenvíe correo que no provenga de direcciones registradas bajo su dominio. Estas medidas, básicas para evitar problemas de spam y mail bombing, son necesarias en la configuración de los sistemas de cualquier entidad.