La seguridad es un trabajo que que comienza y termina en el administrador de sistema. Aunque que los sistemas multiusuario BSD UNIX® posean una seguridad inherente, el trabajo de construir y mantener mecanismos de seguridad adicionales para que los usuarios sean aún más “honestos” es probablemente una de las mayores tareas de la administración de sistemas. Los sistemas son tan seguros como uno los haga, y no hay que olvidar que los problemas de seguridad compiten con la comodidad a la que tendemos los humanos. Los sistemas UNIX son capaces de ejecutar una gran cantidad de procesos simultáneamente, muchos de los cuales son servidores, lo que significa que las entidades externas pueden conectarse y “hablar” con ellos. Del mismo modo que las minicomputadoras de ayer se convirtieron en los sistemas de escritorio de hoy en día, la seguridad se va convirtiendo en un problemas más y más acuciante.
La seguridad bien entendida se implementa en capas, a la manera de una “cebolla”. Básicamente lo que se hace es crear la mayor cantidad posible de capas de seguridad, para más tarde monitorizar el sistema en busca de intrusos. No es conveniente exagerar la seguridad, ya que interferiría con la detección, y la detección es uno de los aspectos más importantes de cualquier mecanismo de seguridad. Por ejemplo, no tiene mucho sentido activar la bandera schg (consulte chflags(1)) en cada binario del sistema, ya que aunque protegería en cierto modo los binarios, haría que cualquier cambio que pudiera realizar un atacante una vez dentro del sistema fuera más difícil de detectar o incluso hacerlo del todo imposible.
La seguridad del sistema depende también de estar preparados para distintos tipos de ataque, incluyendo intentos de “tirar” la máquina o dejarla en un estado inutilizable, pero que no impliquen intentos de comprometer el usuario root Los problemas de seguridad pueden dividirse en diferentes categorías:
Ataques de denegación de servicio (DoS).
Comprometer cuentas de usuarios.
Comprometer root a través de servidores accesibles.
Comprometer root desde cuentas de usuario.
Creación de puertas traseras (“Backdoors”).
Un ataque de denegación de servicio es una acción que priva al sistema de los recursos requeridos para su funcionamiento normal. Generalmente, los ataques DoS son mecanismos de fuerza bruta que intentan “tumbar” el sistema o hacerlo inutilizable sobrecargando la capacidad de sus servidores o de la pila de red. Algunos ataques DoS intentan aprovechar errores en la pila de red para “tumbar” el sistema con un solo paquete. Estos últimos únicamente pueden solucionarse aplicando al kernel una actualización que subsane el error. Los ataques a servidores muchas veces pueden solucionarse configurando las opciones apropiadas para limitar la carga del sistema en condiciones adversas. Los ataques de fuerza bruta a redes son más complicados. Los ataques con paquetes enmascarados, por ejemplo, son casi imposibles de detener, a menos que desconecte el sistema de Internet. Puede ser que no “tiren” el sistema, pero saturarán la conexión a Internet.
Comprometer una cuenta de usuario es mucho más común que un ataque DoS. Muchos administradores de sistemas todavía ejecutan servidores estándar telnetd, rlogind, rshd y ftpd en sus máquinas. Estos servidores, por defecto no operan a través de conexiones cifradas. El resultado es que se si se tiene una base de usuarios de tamaño medio, tarde o temprando la contraseña de uno (o más) de sus usuarios será descubierta durante sus accesos al sistema desde ubicaciones remotas.(que es, por otra parte, la forma más común y más cómoda de acceder a un sistema). El administrador de sistemas atento analizará sus logs de acceso remoto en busca de direcciones origen spspechosas, incluso entre los accesos al sistema.
Se debe asumir siempre que, una vez que el atacante tiene acceso a una cuenta de usuario, el atacante puede comprometer la cuenta root. En realidad en un sistema bien mantenido y asegurado el acceso a una cuenta de usuario no necesariamente da al atacante acceso a root. Esta precisión es importante porque sin acceso a root el atacante difícilmente podrá esconder sus huellas; podrá, como mucho, hacer poco más que sembrar el caos en los ficheros del usuario o “tirar” la máquina. Comprometer cuentas de usuario es muy común porque los usuarios tienden a no tomar las precauciones que toma el administrador.
Los administradores de sistemas deben tener presente que existen muchas formas potenciales de comprometer la cuenta root de una máquina. El atacante puede conocer la contraseña de root, el atacante puede encontrar un error en un servidor que se ejecuta como root y ser capaz de comprometer root a través de una conexión de red a ese servidor; puede ser que el atacante sepa de la existencia de un error en un programa suid-root que le permita comprometer root una vez dentro de una cuenta de usuario. Si un atacante encuentra la manera de comprometer la cuenta root de una máquina puede que no necesite instalar una puerta trasera. Muchos de los agujeros root encontrados y cerrados hasta la fecha implican una cantidad considerable de trabajo para el atacante limpiando todo después del ataque, así que la mayoría de los atacantes instalan puertas traseras. Una puerta trasera facilita al atacante una forma sencilla de recuperar el acceso de root al sistema, pero también proporciona al administrador de sistemas inteligente una forma de detectar la intrusión. Si hace imposible a un atacante la instalación de una puerta trasera puede estar actuando en detrimento de su seguridad, porque no cerrará el agujero que el atacante encontró para accder al sistema la primera vez que lo hizo.
Las medidas de seguridad se implementan en un modelo multicapa (tipo “cebolla”), que puede categorizarse del siguiente modo:
Asegurar root y cuentas administrativas.
Asegurar los servidores que se ejecuten como root los binarios suid/sgid.
Asegurar cuentas de usuario.
Asegurar el fichero de contraseñas.
Asegurar el núcleo del kernel, los dispositivos en bruto y el sistema de ficheros.
Detección rápida de cambios hechos al sistema.
Paranoia.
La siguiente sección de este capítulo tratará los puntos de arriba con mayor profundidad.
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>.