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>.