Capítulo 13. Seguridad

13.1. ¿Qué es un sandbox?
13.2. ¿Qué es securelevel?
13.3. BIND (named) esta escuchando en algunos puertos de numero alto. ¿Qué esta pasando?
13.4. ¡El demonio de Sendmail esta escuchando en el puerto 587 y además en el puerto estándar 25! ¿Qué esta pasando?
13.5. ¿Qué es esta cuenta de toor UID 0 ? ¿He sido comprometido?

13.1.

¿Qué es un sandbox?

Sandboxes un término de seguridad. Puede significar dos cosas:

  • Un proceso que se coloca adentro de un conjunto de paredes virtuales que están designadas para impedir que alguien que logra explotar el proceso no pueda explotar el ecosistema mayor.

    El proceso que puede correr adentro de estas paredes. Dado que nada de lo que el proceso haga con respecto a ejecutar código puede romper las paredes, una auditoría detallada del código es innecesaria para poder decir ciertas cosas acerca de su seguridad.

    Estas paredes pueden ser un ID de usuario, por ejemplo. Esta es la definición usada en las páginas de manual de security(7) y named(8).

    Considere el servicio ntalk, por ejemplo (vea inetd(8)). Este servicio solía correr con ID de usuario root. Ahora corre con ID de usuario tty. El usuario tty es un sandbox designado para hacer más difícil para alguien que ya ha irrumpido en el sistema mediante ntalk pueda comprometer el sistema más allá de esa ID de usuario.

  • Un proceso que se inserta en una simulación de la máquina. Esto significa que alguien que puede irrumpir en el proceso podría creer que puede irrumpir en la máquina entera pero esta, en efecto solo irrumpiendo en una simulación de esa máquina sin modificar ningún dato real.

    La manera más común de lograr esto es construir un ambiente simulado en un subdirectorio y luego correr el proceso dentro de un chroot en ese directorio de manera que / para ese proceso sea este directorio, en lugar de la verdadera / del sistema.

    Otro uso común es montar un sistema de archivos subyacente como de solo lectura y crear una capa de sistema de archivos encima del mismo que provea a un proceso una vista aparentemente de escritura en el sistema de archivos. El proceso puede creer que esta habilitado para escribir esos archivos, pero solo el proceso en cuestión ve los efectos, y otros procesos en el sistema no.

    Se hace un intento de que este tipo de sandbox sea tan transparente que el usuario (o el hacker) no se de cuenta de que esta usándola.

UNIX® implementa dos sandboxes principales. Uno es a nivel proceso, el otro es a nivel userid.

Cada proceso UNIX® esta completamente aislado de cualquier otro proceso UNIX®. Un proceso no puede modificar el espacio de direcciones de otro.

Un proceso UNIX® tiene por dueño una userid en particular. Si el ID de susuario no es el usuario root, es útil aislar el proceso de procesos adueñados por otros usuarios. El ID de usuario también se usa para aislar datos del disco.

13.2.

¿Qué es securelevel?

securelevel es un mecanismo de seguridad implementado en el kernel. Cuando un securelevel es positivo, el kernel restringe ciertas tareas; ni siquiera el superusuario (root) tiene permitido hacerlas. El mecanismo securelevel limita la habilidad de:

  • Borrar ciertas banderas de archivo, tales como schg (the system immutable flag).

  • Escribir a la memoria del kernel mediante /dev/mem y /dev/kmem.

  • Cargar modulos de kernel.

  • Alterar reglas del firewall.

Para verificar el estado del securelevel en un sistema corriendo:

# sysctl -n kern.securelevel

La salida contiene el valor actual del securelevel. Si es mayor a 0, al menos algunas de las protecciones de securelevel están habilitadas.

El securelevel de un sistema corriendo no puede ser reducido dado que esto arruinaría su propósito. Si una tarea requiere que el securelevel sea no-positivo, cambie las variables kern_securelevel y kern_securelevel_enable en /etc/rc.conf y reinicie.

Para más información acerca de securelevel y lo que hace en particular cada nivel, consulte init(8).

Aviso:

Securelevel no es una bala de plata; tiene varias deficiencias conocidas. Muchas veces provee un falso sentido de seguridad.

Uno de sus problemas mas importantes es que para que sea efectivo, todos los archivos usados en el proceso de inicio hasta que se ajuste securelevel deben estar protegidos. Si un atacante puede hacer que el sistema ejecute código antes de que se ajuste el securelevel (lo cual pasa bastante tarde en el proceso de inicio dado que algunas de las cosas que el sistema debe hacer al inicio no pueden hacerse con un securelevel elevado), sus protecciones están invalidadas. Mientras que la tarea de proteger todos los archivos usados en el proceso de inicio no es técnicamente imposible, si esto se logra, el mantenimiento del sistema se volverá una pesadilla dado que una persona tendría que apagar el sistema, o al menos cambiar a modo de un solo usuario, para modificar un archivo de configuración.

Este punto y otros son frecuentemente discutidos en las listas de correo, particularmente la lista de correo de seguridad de FreeBSD. Busque en los archivos aqui para una discusión extensiva. Se prefiere un mecanismo de granularidad más fina.

13.3.

BIND (named) esta escuchando en algunos puertos de numero alto. ¿Qué esta pasando?

BIND usa un numero al azar de puertos de número alto para consultas saliente. Las versiones recientes elijen un nuevo puerto UDP al azar para cada consulta. Esto puede causar problemas para algunas configuraciones de red, especialmente si un firewall bloquea paquetes UDP entrantes en puertos particulares. Para pasar ese firewall intente usar las opciones avoid-v4-udp-ports y avoid-v6-udp-ports para evitar elegir números de puertos al azar en un rango bloqueado.

Aviso:

Si un número de puerto (como el 53) es especificado mediante las opciones query-source o query-source-v6en /etc/namedb/named.conf, no se usara la selección al azar de puertos. Se recomienda fuertemente que estas opciones no se usen para especificar números de puerto fijos.

Felicitaciones por cierto. ¡Es buena práctica leer la salida de sockstat(1)y notar cosas raras!

13.4.

¡El demonio de Sendmail esta escuchando en el puerto 587 y además en el puerto estándar 25! ¿Qué esta pasando?

Las versiones recientes de Sendmail soportan una característica de envió de correo que corre sobre el puerto 587. Esto no esta soportado universalmente, pero esta creciendo en popularidad.

13.5.

¿Qué es esta cuenta de toor UID 0 ? ¿He sido comprometido?

No se preocupe. toor es una cuenta de superusuario alternativa, en donde toor es root escrito al revés. Su propósito es ser usada como un shell no estándar de manera que el shell por defecto para root no necesite cambiar. Esto es importante dado que los shells que no son parte del sistema base, pero que en su lugar son instalados desde ports o packages, se instalan en /usr/local/bin el cual, por defecto, reside en un sistema de archivos distinto. SI el shell de root esta localizado en /usr/local/bin y el sistema de archivos conteniendo /usr/local/bin) no esta montado, root no sera capaz de autenticarse para arreglar un problema y tenga que reiniciar al modo de un solo usuario para ingresar a la ruta de un shell.

Alguna gente usa toor para tareas diarias de root con un shell no estándar, dejando a root, con un shell estándar, para modo de un solo usuario o emergencias. Por defecto, un usuario no puede autenticarse usando toor dado quen o tiene una contraseña, de modo que autentiquese como root e ingrese una contraseña para toor antes de usarlo para autenticarse.

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.

Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.