PDF de programación - Herramientas de seguridad en FreeBSD

Herramientas de seguridad en FreeBSD
Este artículo pretende dar una idea general de las características de seguridad de FreeBSD, un sistema operativo
Unix libre. FreeBSD contiene una serie de opciones que pueden ser configuradas para reducir el riesgo de
compromiso del sistema. Un sistema FreeBSD bien configurado puede ofrecer muy buenos servicios a los
usuarios y ser muy resistente a posibles ataques.

Introducción
Cualquier administrador de sistemas Unix o network manager en la necesidad de trabajar con servidores de red
estables y de alto rendimiento debería considerar la posibilidad de integrar alguno de los sistemas libres y
considerarlos como alternativa a los sistemas operativos comerciales convencionales. Mientras FreeBSD y
sistemas similares ofrecen una alternativa de bajo coste en estaciones de trabajo y servidores, desde el punto de
vista de la seguridad no está tan claro. Antes de introducirnos en la exploración de FreeBSD, quisiera
comentar que la relación entre los sistemas Unix y la seguridad en Internet es ya un tópico. Existen numerosos
libros y otros recursos que discuten los diferentes elementos implicados en este tema, algunos de los cuales
están incluidos en las referencias citadas al final de este artículo. En particular, al lector interesado le
recomiendo "Practical Unix and Internet Security" y "Firewalls and Internet Security".
OpenBSD, un sistema relativamente cercano a FreeBSD, está siendo desarrollado con el objetivo de reforzar la
seguridad de sistemas basados en BSD. FreeBSD incorpora e incorporará las soluciones a problemas de
seguridad identificados por OpenBSD. Más información de OpenBSD en:

http://www.openbsd.org/

Sumario de conceptos de seguridad
En general, un sistema debe ser tan seguro físicamente como sea necesario, y el sistema solo debe tener los
servicios y programas privilegiados que sean estrictamente necesarios para el nivel de operaciones deseado.
Las siguientes secciones tratan diferentes áreas de seguridad con más detalle.

Sistema físico y cónsola
Con acceso físico al sistema, un atacante puede seleccionar la opción -s en el prompt de arranque y obtener un
shell con privilegios de root en modo monousuario. Para evitar esto, si el sistema no está físicamente en un
lugar seguro, es una buena idea marcar la consola como insegura en /etc/ttys para que el sistema requiera el
password de root al entrar en modo monousuario. Mira el man de init(8) para más detalles. Si, como decimos,
el sistema no se encuentra en un lugar seguro, no debería tener disquetera. Un atacante puede usar el boot
prompt para arrancar un kernel retocado o montar el floppy como la partición raíz, pasando por alto cualquier
protección establecida en /etc/ttys.

Programas setuid y Daemons
Los problemas con demonios y programas setuid son explotados habitualmente por los crackers para obtener
privilegios de root en los sistemas. Es aconsejable tener instalados el menor número posible de daemons y
programas setuid en los sistemas para reducir los posibles problemas en caso de que se descubra algún tipo de
vulnerabilidad en éstos.

Daemons
La idea con los daemons es desactivar todos y cada uno de ellos que no sean estrictamente necesarios. Edita los
ficheros /etc/rc.conf y /etc/inetd.conf para desactivar los servicios no usados. Por ejemplo, si los servicios
rlogin o rsh no son necesarios, pueden ser desactivados en /etc/inetd.conf comentándolos con el símbolo #. De
la misma manera, si el daemon de impresión lpr no es necesario, pon la opción lpd_enable en el fichero
/etc/rc.conf a "NO".
Otra estrategia es reemplazar los daemons que son conocidos por haber tenido problemas de seguridad por
otros que nos provean de los mismos servicios pero que hayan sido desarrollados teniendo en cuenta la
seguridad. Por ejemplo, mientras en FreeBSD se mantiene el sendmail relativamente actualizado, podríamos
reemplazarlo por el programa qmail, diseñado y escrito enteramente pensando en la seguridad. Qmail está
disponible en http://www.qmail.org/.

Programas setuid
Los programas setuid son programas especiales en el sistema que se ejecutan con los privilegios del propietario
del programa, sea cual sea el usuario que lo esté ejecutando. Por ejemplo el programa PPP /usr/sbin/ppp
realiza algunas operaciones que solo están permitidas al usuario root, por lo que tiene activado el bit de setuid,
y su propietario es root. Como resultado, cuando cualquier usuario ejecuta ppp, éste se ejecuta con los
permisos de seguridad del usuario root. Mira el man de chmod(1) para más información sobre el bit de setuid
y otros permisos. Los programas setuid son un problema de seguridad, por que algunos programas tienen bugs
que permiten a los crackers aprovecharse de ellos. Provocar problemas de overrun y sobreescribir el stack con
código maligno es un sistema común de ataque en programas setuid. Desde el momento en que el programa se
está ejecutando con privilegios de root, el código del cracker se ejecuta con los privilegios de root. La manera
más sencilla de revisar los programas setuid y setgid en el sistema es ejecutar los comandos:

find / -perm -4000 -print
find / -perm -2000 -print

Usando la lista generada de ficheros setuid y setgid, puedes determinar los que no son necesarios para tu
sistema. Usa el comando "chmod gu-s nombre_fichero" para desactivar los bits de setuid y setgid.

Sistemas de ficheros
Un sistema donde los sistemas de ficheros de los usuarios están separados de los sistemas de ficheros que
contienen los programas ejecutables y ficheros de dispositivos pueden parar ataques potenciales o "back doors".
Un método de obtener acceso de root o dejar una "back door" para obtener ese acceso posteriormente es crear
un ejecutable setuid o crear un fichero especial de dispositivo que permita acceso de escritura a la memoria del
sistema. Las opciones nosuid y nodev pueden ser usadas en /etc/fstab en sistemas de ficheros que no deban
contener setuid o ficheros de dispositivos. Mira el man de mount(8) y fstab(5).
Estas opciones pueden ser usadas en sistemas de ficheros en los cuales los usuarios pueden crear ficheros. Es
muy buena idea separar los directorios que contengan ficheros de usuarios, como /home, /tmp, /var/tmp en un
sistema de ficheros separado del /usr. Las opciones nosuid y nodev son especialmente importantes en sistemas
que monten unidades NFS de sistemas inseguros o no fiables. Un usuario avanzado del otro sistema podría
crear un ejecutable setuid-root o un dispositivo /dev/kmem-equivalent en el servidor, y usar a continuación ese
fichero en el cliente para obtener privilegios de root. La opción noexec puede ser muy útil en un sistema de
ficheros montado desde un servidor no fiable.

Monitorizando el sistema de ficheros
Algunos ataques a sistemas se realizan mediante el sistema de ficheros Unix, normalmente abusando de
daemons o programas setuid. Típicamente estos programas crean o cambian ficheros de configuración, como el
fichero de usuario .rhosts, permitiendo el acceso al sistema. Estos ataques se previenen cerrando "agujeros" en
los daemon y programas setuid, pero estos agujeros deben ser encontrados primero. Es recomendable reducir la
posibilidad de estos ataques o su detección inmediata monitorizando el sistema.
FreeBSD envía diariamente un informe de seguridad al usuario root. Chequea los posibles nuevos o
modificados programas setuid y ficheros de dispositivos. Si aparece un nuevo programa setuid, la hora o el
tamaño cambia misteriosamente, o aparece un nuevo UID 0 (root), es probablemente el momento de investigar.
Pero, si un sistema ha sido sabiamente crackeado, los informes no indicarán ningún problema, por que el script
de seguridad y sus ficheros de datos son vulnerables a ser falseados. Solo tripwire (mira más adelante), cuando
está correctamente instalado y usado, puede detectar de manera fiable que un sistema ha sido comprometido.
Desafortunadamente, debido a la manera en la que el sistema es escaneado por programas setuid, es posible que
el resultado del informe cambie, causando una falsa alarma ocasional en la sección de "setuid files and devices"
del informe de seguridad.

Monitorización avanzada con tripwire
Tripwire es un package que monitoriza el sistema de ficheros para prevenir los cambios en ficheros y permisos.
Las instrucciones de instalación del programa nos dan una excelente visión del package y del procedimiento
correcto de instalación. Esencialmente, tripwire debería ser instalado e inicializado en un sistema totalmente
seguro y no comprometido. El fichero ejecutable de tripwire, lincado como un ejecutable estático para evitar el
uso de las librerías compartidas del sistema, y su fichero de base de datos, que contiene las firmas digitales que
verifican la integridad de los ficheros del sistema, deberían ser escritos en un soporte de solo lectura. Después,
cuando tripwire es usado para verificar la integridad de un sistema, debería ser invocado directamente desde su
ejecutable en el soporte de solo lectura. Una posibilidad es instalar el ejecutable y la base de datos en un floppy
de 3.5" y de solo lectura.

rhosts y hosts.equiv

Si los servicios de red de shell remota (rshell) o login remoto (login) están activados en /etc/inetd.conf, los
ficheros /etc/hosts.equiv y .rhosts son importantes para la seguridad. El fichero hosts.equiv define los sistemas
que tienen usuarios reconocidos por nuestro sistema para que no les sea requerido el password al realizar la
conexión. Cada fichero $HOME/.rhosts define los sistemas remotos y usuarios que pueden usar esta cuenta sin
tener que dar un password. Mira el man de hosts.equiv(5) para más información, pero esencialmente, ningún
nombre de sistema debería figurar en estos ficheros a no ser que los hosts y redes sean de total y absoluta
confianza.
Ten en cuenta que si la línea + + aparece en estos ficheros, el sistema es totalmente inseguro y cualquier
usuario de cualquier sistema puede hacer un log