LPIC-1 Capítulo 10

EN ESTE CAPÍTULO SE ABARCAN LOS SIGUIENTES OBJETIVOS DEL EXAMEN:

• 110.1 : Realizar tareas administrativas de seguridad (3)
• 110.2 : Configurar la seguridad del host (3)
• 110.3 : Proteger los datos mediante técnicas de encriptación (3)

Proteger el sistema

Hoy en día la mayoría de los ordenadores se encuentran conectados a Internet. Estar conectado a Internet aporta innumerables ventajas a nuestra sociedad, es como salir al exterior pero sin realmente dar un paso de donde nos encontramos. Esto, sin pensarlo, nos parece incluso seguro, nos da la sensación de ser menos vulnerables pero realmente es todo lo contrario, estar conectado a Internet significa prácticamente exponer en cierta forma nuestro ‘yo‘ mas íntimo, a través de fotografías, vídeos, conversaciones, datos bancarios, etc… es por ello que cada día debemos de ser mas conscientes y dedicar mas tiempo, esfuerzo o economía a protegernos del exterior.

En las siguientes secciones veremos algunos puntos básicos a tener en cuenta cuando utilizamos un dispositivo tanto con acceso a red como si nos limitamos a un uso local. Tener un ‘agujero‘ de seguridad en nuestro dispositivo, en el mejor de los casos significaría que solo ese dispositivo se vería comprometido pero en la mayoría de las veces, solamente se trata de una puerta de acceso al interior de nuestra red, red en la que podemos tener servidores con importantes servicios ejecutándose o numerosa información personal que de ninguna de las maneras queremos que sea accedida por terceras personas. Existen muchos puntos a tener en cuenta para ser realmente eficaces con respecto a la posibilidad de parar a un atacante pero este curso abarcará solamente aquellos que se encuentran al nivel exigido para aprobar la certificación y que con serán los siguientes:

Administrar la seguridad local

• Crear contraseñas fuertes contra ataques de fuerza bruta
• Control de acceso al sistema
• Límites y cuotas de usuarios
• Permisos sobre archivos: nosuid, nodev, noexec
• Habilitación de hosts
• Módulos PAM

Administrar la seguridad de la red

• Técnicas utilizadas en los ataques y contramedidas
• Controlar los puertos de red que se están utilizando
• Comprobar las conexiones de red existentes y los servicios que las provocan
• Utilizar un súper servidor con el que poder limitar el acceso de una forma mas controlada
• Protección mediante Firewalls
• Sistemas de detección de intrusos (IDS)

Administrar la seguridad local

El uso de contraseñas

Quizás el primer paso para acceder a un sistema, independientemente de la técnica utilizada para localizar el sistema en cuestión y sus vulnerabilidades (de ser un ataque en red) como el uso de la ingeniería social, un keylogger o cualquier otro método para tomar el control de un sistema de forma local, es acceder a la cuenta de un usuario de manera que se obtenga un punto de partida para continuar con un ataque, ya sea al propio sistema o equipos conectados a la red. Un equipo sin contraseña o con una contraseña lo suficientemente débil como para ser averiguada en poco tiempo mediante fuerza bruta allanaría el terreno aportado este punto necesario para tomar el control. Es por ello que debemos de seguir unas pautas para generar una contraseña de cuenta lo suficientemente robusta como para ser vencida rápidamente por un ataque de fuerza bruta, además no basta con generarla una vez si no que lo conveniente sería ir mortificándola cada cierto tiempo de manera que si un atacante obtuvo nuestra contraseña, se encuentre con que somos como mínimo una victima poco perezosa, en este caso deberá de volver a intentar tener acceso al sistema. Este será nuestro primer pequeño muro a construir. Algunas de las pautas a seguir para evitar riesgo con respecto a las contraseñas serían:

• Utilizar contraseñas seguras: Podemos utilizar alguna técnica para generar nuestra contraseña por ejemplo, crear una combinación aleatoria de letras mayúsculas y minúsculas, dígitos y signos de puntuación. Una buena forma de empezar sería escribir una frase que tenga (o no) que ver con la cuenta o programa. Imaginemos que vamos a crear una contraseña para el correo electrónico, podríamos hacer algo así; “cuando abro mi correo solo tengo spam“. Vamos a trabajar sobre esta frase, de momento vamos a seleccionar las dos primeras letras de cada palabra quedando algo así “cuabmicosotesp“. Ahora vamos a cambiar una vocal si y otra no por un dígito tal que así “cu4bmic0sot3sp”. Con esto la contraseña tomaría suficiente fuerza pero si queremos podemos separar la contraseña en dos partes mediante un guión bajo o signo de exclamación “cu4bmic_0sot3sp” o “cu4bmic!0sot3sp”. Con esto hemos conseguido una contraseña lo suficientemente segura. Podríamos seguir implementando seguridad a nuestra contraseña como por ejemplo invertir el orden o ampliando el pajar. La expresión “ampliar el pajar” viene de buscar una aguja en un pajar, y no es mas que aumentar la longitud de la contraseña mediante la repetición de caracteres, en nuestro caso podría quedar definitivamente así (inversión + ampliación) “0sot3sp!!!!!!!!cu4bmic”. Parece paranoico pero nuestro nivel de paranoia será (o debería serlo) directamente proporcional a la criticidad de la información que queremos ocultar.

Información: Existen programas como John the Ripper que podemos aplicar sobre nuestra propia base de datos de contraseñas encriptadas para localizar contraseñas pobres.

• Cambiar la contraseña con frecuencia: Sería interesante a la hora de crear una cuenta en el equipo hacerlo de manera que cada cierto tiempo el sistema nos obligue a modificar la contraseña. Podemos hacer esto directamente a la hora de crear la cuenta mediante useradd o una vez creada mediante la herramienta chage o usermod.
• Utilizar contraseñas ocultas: En el Capítulo 7 ya se comentó la importancia de usar contraseñas shadow (/etc/shadow) en lugar del antiguo mecanismo que permitía que un atacante pudiese leer el archivo /etc/passwd y localizar la contraseña directamente. Hoy en día todas las distribuciones utilizan por defecto contraseñas shadow. No obstante podemos modificar esto con los comandos pwconv y pwunconv que implementan o no contraseñas shadow respectivamente.
• Mantener las contraseñas en secreto: Aunque parezca arcaico no hay nada mas ‘seguro‘ que mantener la contraseña escrita en un papel al que acudir cuando la necesitamos, aunque realmente lo mejor es memorizarla, pero…
• Utilizar protocolos seguros de acceso remoto: Mas adelante hablaremos sobre protocolos o métodos de conexión remota, pero adelantamos que lo mejor es conectar a través de ssh, ya sea a ftp, escritorio o consola remota, o bien copiar archivos (sftp, ssh -X, ssh, y scp respectivamente). Esto encriptará nuestra contraseña. Deberemos de desactivar Telnet, FTP y otros protocolos que emplean contraseñas en texto plano.
• Tener cuidado con la ingeniería social: práctica que implica engañar a personas fingiendo ser por ejemplo un administrador de sistemas o cualquier otra persona de responsabilidad en la materia, para que estas le entreguen sus contraseñas. Este sería el método sencillo pues esto puede llevar a conversaciones suficientemente elaboradas por aquel que emplea la ingeniería social de modo que nos esté sacando información valiosa sin ni siquiera darnos cuenta. Es posible que no digamos en ningún momento nuestra contraseña pero quizás si le estemos ofreciendo el método de llegar a ella. Una práctica relacionada es el phishing (o pesca telemática) en la que un atacante crea un sitio web falso o envía un correo electrónico fingiendo ser otra persona, de manera que la víctima se lo crea y revele algún dato sensible, como su número de tarjeta de crédito.

Controlando el acceso al sistema

Como se ha comentado en la sección anterior, el acceso al sistema mediante una cuenta de usuario puede ser el primer paso para comenzar un ataque hacia el interior de la red o del propio sistema. Según se mire, puede que tener el control de una cuenta sea el primer o segundo muro, dependiendo si el atacante a tenido que saltar diferentes obstáculos para llegar a través de la red hacia el sistema o bien estamos ante un ataque directo físico, como por ejemplo un compañero hostil de nuestro entorno que conoce nuestra contraseña y accesa al sistema. En cualquiera de los casos es de suma importancia mantener un control sobre quien o que usuario está iniciando sesión en nuestro equipo o servidor que administramos. Para ello Linux pone a nuestro disposición varias herramientas y archivos que mantienen un control sobre la entrada y salida de usuarios, herramientas que ya hemos estudiado en su correspondiente capítulo y que son algunas como who, users, w, lastlog, last, lastb o finger, este último en desuso por sus vulnerabilidades. Repasemos el uso de estas herramientas y los archivos implicados:

• last y lastb: Muestran un histórico de los usuarios que han conectado y desconectado al sistema así como intentos de sesión fallidos, respectivamente. Los archivos binarios que corresponden a estos comandos son (por defecto) /var/log/wtmp y /var/log/btmp
• lastlog: Otro comando que nos permite ver un histórico de entradas al sistema, pero esta vez de todos los usuarios del sistema hayan o no iniciando sesión alguna vez. Este comando despliega el contenido del archivo de registro binario /var/log/lastlog
• w, who y users: El comando ‘w‘ muestra los usuarios conectados actualmente en el sistema y el uso que hacen de este (procesos ejecutados) mientras que who solo muestra los usuarios conectados en ese momento en la máquina. Ambos por defecto despliegan el contenido del archivo binario /etc/utmp. Con who además podemos ver el usuario actual (como con whoami) si usamos su opción -m o desplegar el contenido de /var/log/wtmp (como hace last por defecto) si le pasamos el nombre de archivo (con ruta absoluta) como argumento. El comando users tiene un comportamiento similar a who pero ofrece menos información.

Como podemos comprobar, el uso de los archivos de registros de acceso al sistema son de vital importancia aunque no del todo fiables pues un atacante podría manipularlos de manera que oculte sus accesos. Estos archivos deberían de tener los permisos 644 sin afectar por ello al funcionamiento del sistema de registros. A continuación veremos como implementar una mínima seguridad sobre estos archivos.

Atributos de un archivo

Existen ciertos atributos para los archivos que pueden ayudar a incrementar la seguridad de un sistema. No vamos a estudiar todos los que existen pero si alguno de ellos que nos pueden ser de utilidad. La herramienta para implementar el uso de atributos de archivos es chattr y su sintaxis es la utilizada para la gran mayoría de los comandos Linux: ‘# Comando [opciones] archivo(s)‘, solo que en las opciones usaremos los signos +, – o = para añadir, quitar o dar exactamente unos atributos a uno o varios archivos respectivamente.

Nota: Podemos ver los atributos de un archivo con lsattr.

Acabamos de ver la importancia de los archivos de registro de accesos al sistema y sabemos que pueden ser atacados por un intruso bien de forma manual o a través de rootkits. Para añadir un extra de seguridad a estos archivos podríamos hacer que tomaran el atributo ‘a‘ de manera que el archivo fuera abierto exclusivamente para añadir información, nunca para borrarlo. Solo root puede hacer uso de este atributo, de manera que si la seguridad del sistema se ha visto comprometida por un intruso a nivel de root, solo sería cuestión de tiempo que el atacante modificara el atributo con chattr -a archivo y modificase o eliminase el archivo. No obstante de no tener privilegios de root, estaríamos teniendo constancia de la entrada del intruso al sistema. Otro atributo interesante es ‘i‘ con el que haremos que un archivo sea inmutable, es decir, no se puede escribir en el, modificar permisos, enlazan con ln, eliminar, etc… Al igual que pasa con el anterior atributo solo root puede activar o desactivarlo. Podríamos usar este atributo para hacer inmutable ciertos archivos de interés que no suelen ser modificados con regularidad, como archivos de configuración de /etc/, el archivo de contraseñas de usuario, etc…

Nota: Cuando activamos el atributo i debemos de tener en cuenta que ni siquiera root podrá modificar el archivo, a menos que desactive el atributo.

Otros atributos a destacar, aunque menos importantes que los dos anteriores son s y S. Si eliminamos un archivo que tenía activado el atributo s, el sistema rellenará sus bloques con ceros en lugar de efectuar un simple unlink. De esta manera dificultamos la tarea de recuperación de un archivo por parte de un atacante, aunque una vez mas esto solo supondrá una pérdida de tiempo para un atacante experimentado. El atributo S lo que hace es escribir los datos directamente al disco sin esperar a sync de aquellos archivos que lo tengan activado. Esto no muy significante, pero de apagarse nuestro equipo en el momento en el que un atacante entra al sistema, mantendremos esa información en el archivo de registro.

Para terminar vamos a nombrar otros atributos quizás útiles en determinadas circunstancias:

• El atributo A hace que la fecha de último acceso en un archivo no sea modificada
• Cuando un directorio tiene activo el atributo D los datos serán escritos de forma síncrona en el disco. Idéntico a S solo que S trabaja sobre archivos.
• Un archivo con el atributo u activado podrá ser recuperado con alguna herramienta destinada a tal fin.

Limitar el acceso a root

Acceder como root directamente al sistema suele ser desaconsejable, por varias razones, entre ellas, que no deja ningún rastro en los archivos de registro de acceso. En el capítulo 7 se trato el uso de herramientas como su y sudo, mejores opciones para acceder como root al sistema. Recordemos que con su – podemos cambiar a root bajo su entorno (gracias a ‘–‘), mientras que con sudo podemos ejecutar un programa con privilegios de root siempre y cuando tengamos correctamente configurado el archivo /etc/sudoers. Hablaremos de como configurar este archivo al final de la sección.

También podemos usar su -c “programa” para ejecutar ‘programa‘ con privilegios de root, aunque esto también suele usarse en scripts que solo root puede ejecutar pero que posteriormente queremos que sea un determinado usuario el que sea tutor o propietario de dicha ejecución. Imaginemos que tenemos una tarea de sistema bajo anacron (tareas que solo root puede ejecutar) pero el programa que queremos ejecutar es de nuestro usuario particular y además (aunque root pueda hacerlo) queremos que lo ejecute nuestro usuario, para conseguir esto podremos crear una tarea anacron que llame a un script cuyo contenido sea similar a:

!/bin/bash

# Ejecutar 'programa' con usuario 'miusuario'
su - 'miusuario' -c "/home/'miusuario'/bin/'programa'

De esta manera root ejecutará la tarea anacron (en este caso este pequeño script) que a su vez llamará a nuestro programa con nuestro usuario.

El archivo /etc/nologin aplica un concepto de seguridad especialmente radical. Si este archivo está presente, sólo root podrá acceder al ordenador.

Configurando /etc/sudoers

Para comenzar a editar este archivo lo abriremos con el comando visudo:

$ visudo /etc/sudoers

Vamos a suponer que realizaremos una configuración avanzada. Lo primero que deberemos de hacer será crear grupos de comandos para luego asignárselos a uno, varios o todos los usuarios, de manera que puedan hacer uso de ellos mediante la herramienta sudo:

# Crear grupos de comandos (Alias) - También podemos crear Alias para grupos, usuarios, equipos y "ejecutar con" (Runas)
 Cmnd_Alias ALMACENAMIENTO = /sbin/fdisk, /sbin/sfdisk, /bin/mount
 Cmnd_Alias PROCESOS = /bin/nice, /bin/kill, /usr/bin/killall

# Definir quien podrá usar los grupos de comandos
# El grupo sys puede usar todos los comandos de ambos grupos (ALMACENAMIENTO y PROCESOS)
 %sys ALL=ALMACENAMIENTO,PROCESOS

# El grupo disk podrá utilizar todos los comandos de ambos grupos y además sin requerir de la password
 %disk ALL=ALMACENAMIENTO NOPASSWD:ALL

# El grupo wheel podrá usar todos los comandos en todas las máquinas y sin password
 %wheel ALL:(ALL) NOPASSWD:ALL

# El usuario nebul4ck podrá usar todos los comandos del grupo proceso solo en la máquina freeser y con el uso de password
 nebul4ck freeser = PROCESOS ALL

# El usuario kafka podrá ejecutar unos determinados comandos en la máquina freeser sin requerir de autenticación:
 kafka freeser = NOPASSWD: /bin/kill, /sbin/fdisk, /bin/chmod, /bin/chown

# El usuario darkns podrá ejecutar ciertos comandos con permisos del usuario nebul4ck y con el grupo kafka:
 darkns blouder = (nebul4ck:kafka) /bin/ls, /usr/bin/lprm, /bin/chmod

La configuración de este archivo puede llegar a ser bastante compleja por lo que no vendría mal acudir a las páginas man de sudoers. Podremos usar comodines o crear el particular Alias “Runas” para permitir a ciertos usuarios ejecutar unos determinados comandos como si fuese un usuario específico. Para ejecutar un comando con un usuario o grupo distinto especificado en un Alias Runas podríamos hacerlo así:

$ sudo -u <usuario> <comando>
$ sudo -u <usuario> -g <grupo> <comando>
$ sudo -g <grupo> <comando>

Restringir el acceso a root

Podríamos hacer que el acceso de root al sistema estuviese restringido, algo que no se suele hacer, pero que si trabajamos sobre el archivo /etc/sudoers de manera que tengamos los permisos necesarios para realizar la mayoría de tareas cotidianas sin poner en riesgo la seguridad del sistema, podemos trabajar a diario con un usuario particular limitado a root en ciertos aspectos, evitando así que un intruso se haga con el control pleno a través de root y comprometa nuestro equipo. Lo primero que deberíamos de hacer sería adaptar el archivo de configuración de sudo (/etc/sudoers) de manera que nos otorguemos el derecho de uso de ciertas herramientas de administración del sistema a nuestro usuario particular, luego, desactivaremos el acceso a bash de root editando la línea de /etc/passwd tal que así:

root:x:0:0:root:/root:/usr/sbin/nologin

A partir de este momento no podremos acceder a consola como root ni emplear la herramienta su –

Nota: Cuando estudiemos la herramienta ssh veremos como restringir el acceso remoto de root al sistema, de manera que primero debamos de acceder vía ssh con un usuario estándar pasando luego a root.

Definir límites y cuotas a los usuarios

En ocasiones una medida de seguridad puede ser la definición de una serie de límites a los usuarios que hacen uso del sistema de forma que se proteja en cierto modo el uso que hacen de este. Existen diferentes formas de definir límites en el sistema que varían en función del objeto que queremos limitar. Por ejemplo, si lo que queremos es imponer un límite sobre la explotación de recursos que realiza un usuario en el sistema, como el uso de memoria, tiempo de CPU, número de procesos podremos editar el archivo /etc/security/limits.conf o utilizar la herramienta ulimit. Si lo que queremos es imponen un límite en el uso del espacio del disco duro del ordenador o servidor o el número de archivos abiertos simultáneamente por un usuario concreto, podremos utilizar el sistema de cuotas que nos ofrece Linux. Este último método ya se explicó en el capítulo – 4 en la sección “Administrar cuotas de disco”, de todos modos volveremos a refrescar nuestra memoria en esta sección.

Definir límites de accesos, procesos y memoria

La imposición de límites como el número máximo de accesos permitidos, procesos ejecutados de forma simultánea, memoria utilizada o tiempo de CPU es preferible hacerla mediante un módulo PAM (Pluggable Authentication Module, Módulo de autenticación conectable) llamado pam_limits. Esto se hace modificando su archivo de configuración /etc/security/limits.conf cuyo formato de línea es el siguiente:

dominio tipo elemento valor

donde:

• Dominio : Es la entidad a la que se le aplica el límite. Puede ser un usuario, un @grupo o un ‘*‘ (lo que coincidiría con todo el mundo.
• Tipo : Se indica el tipo de límite a imponer. Se pueden definir límites estrictos (hard) o flexibles (soft) cuya diferencia radica en que los límites hard son impuestos por root y no se pueden sobrepasar, mientras que los límites soft pueden ser sobrepasados temporalmente. Para indicar que un límite es tanto hard como soft podemos hacerlo con ‘–‘
• Elemento : Especifica que tipo de elemento es el que se limita, por ejemplo, core limita el tamaño de los archivos de volcado del kernel, data limita el tamaño del área de datos de un programa, fsize limita el tamaño de los archivos creados por el usuario o grupo limitado, nofile para limitar el número de archivos de datos abiertos, rss tamaño del proceso residente, stack para limitar el tamaño de la pila, con cpu limitaremos el número de minutos que un proceso puede hacer uso de la CPU, nproc para el número de procesos concurrentes, maxlogins limita el número de accesos simultáneos y priority la prioridad de acceso.

Nota: Los elementos data, rss y stack están relacionados con la memoria consumida por un programa.

• Valor : Indica el valor que será aplicado al límite.

Un ejemplo en el que se limita el tiempo de CPU en 2 minutos de forma estricta para un determinado grupo podría ser:

@migrupo    hard    cpu   2

El tiempo de CPU se cálcula en función del tiempo que la CPU está procesando activamente datos del usuario. Existe otro límite que mide el tiempo de inactividad del usuario, como por ejemplo cuando la consola del usuario está activa pero no hay en ejecución ninguna tarea.

La otra manera de imponer estos límites es empleando la herramienta ulimit. Para ello haremos uso de la siguiente sintaxis:

ulimit [opciones [limite]]

En paralelo a los elementos de limitación anteriormente mencionados usaremos para ello la opción -c (para los volcados del kernel), -f (para el tamaño de los archivos creados por consola por un usuario), -u (para el número de procesos que puede ejecutar un usuario), -t (para limitar el tiempo de CPU en segundos en vez de minutos), -v (define el tamaño total de memoria virtual disponible para la consola), -s (define el tamaño máximo de la pila de memoria), -m (limita el tamaño máximo del conjunto residente), -d (limita el tamaño del conjunto de datos de los programas) y -l (define el tamaño máximo que se puede bloquear en la memoria).

Si lo que queremos es especificar un tipo de límite concreto utilizaremos -H o -S para especificar hard o soft respectivamente.

Para conocer los parámetros actuales de ulimit, pasaremos la opción -a

Advertencia: Como ulimit es un comando nativo de bash, su utilidad como herramienta de seguridad del sistema es limitada. Si los usuarios tienen acceso a herramientas GUI de inicio de sesión o pueden acceder al sistema saltándose bash de algún modo (por ejemplo mediante SSH, dependiendo de como esté configurado), las restricciones impuestas por ulimit carecerán de sentido.

Aplicar cuotas de disco

Como ya se estudió en el capítulo – 4 podemos aplicar límites de cuotas de disco para determinados usuarios o grupo, de manera que cuando se rebase el límite se informe al usuario. Con esto podemos prevenir el desbordamiento de espacio de ciertas particiones que podrían resultar críticas para el sistema. Por ejemplo si tenemos el /home de los usuarios o el directorio /tmp en la misma partición que la raíz ‘/’ y no tenemos un control sobre el uso que se está haciendo de esta, podemos acabar por dejar el sistema inutilizable al llenar la partición. Para prevenir esto podemos implantar el sistema de cuotas, por lo que nuestro kernel deberá de estar compilado con los módulos que ofrecen soporte para las cuotas y además deberemos de usar como root una serie de herramientas, tales como edquota, repquota, quotacheck y quota.

Al igual que con los limites impuestos en el módulo pam_limits también podemos crear quotas estrictas (hard) o flexibles (soft) con un periodo de gracia.

Nota: Para profundizar en el sistema de cuotas de disco volver al Capítulo – 4 sección “Administrando cuotas de disco”

Permisos sobre archivos

Algo que deberemos de tener en cuenta si queremos hacer poco a poco nuestro sistema mas seguro, y digo poco a poco porque nunca será suficiente y porque ya llevamos aprendidas algunas técnicas pero evidentemente quedan mas, entre ellas por ejemplo el conocer los permisos con los que cuentan los archivos de nuestro sistema. Evidentemente es difícil mantener un control sobre todos los archivos o scripts del sistema pero si seguimos unos patrones podremos identificar gran parte de ellos. Algunas de las acciones que podemos realizar para detectar o prevenir vulnerabilidades son la detección de archivos o scripts con los bits especiales (suid, sgid y sticky bit), prestar especial atención a los parámetros con los que montamos una partición, ficheros con permisos de escritura cuando en realidad no existe motivo especial por el que deban de tenerlo, ficheros extraños como por ejemplo aquellos que no poseen un propietario o ficheros cuya configuración puede resultar peligrosa como los .hosts aunque a estos le dedicaremos una sección.

SUID, SGID y Sticky Bit

Seguir el rastro a estos archivos puede resultar una tarea sencilla y eficaz pues como ya sabemos, el que un archivo o en especial un script tenga alguno de estos bits activados puede resultar en un agujero de seguridad para el sistema, ya que un script con el bit suid activado puede hacer que un intruso eleve sus privilegios tomando el control del sistema. Para localizar los archivos con bits especiales podremos usar el comando find de la siguiente manera:

# find / -perm +7000 -type f

Nota: Usamos -type d si queremos localizar directorios o anulamos esta opción para localizara a todos. Igualmente podemos restringir la búsqueda a tan solo archivos con suid (+4000), sgid (+2000) o con sticky bit (+1000)

Cuando realizamos una búsqueda con -perm +4000 es decir estamos buscando archivos con el suid activado, deberán de aparecer aquellos programas para los que un usuario corriente tiene acceso de ejecución por ejemplo, si un usuario quiere cambiar su contraseña necesitará acceder al comando passwd, o si necesita cambiar diferentes características de su cuenta con chfn o chsh. Igualmente necesitará acceso a programas como mount, ping, su o sudo. Hay que prestar especial atención a todos los de la lista por si hubiese alguno que no entendemos porque lo tiene, y tras buscar por Internet o las páginas man llegamos a la conclusión de que determinado archivo no debería de tenerlo, podemos empezar a pensar de que nuestro equipo quizás esté comprometido.

nosuid, nodev, noexec

En la mayoría de las ocasiones, o al menos es una buena práctica, el tener una partición para cada uno de los siguientes directorios /home, /usr, /var y /tmp por diferentes razones. Si creemos que son demasiadas particiones, podemos entonces aislar a /home y /var del resto (que entonces compartirán partición con ‘/’) y si aún así tampoco estamos muy convencidos, se aconseja que como mínimo que el /home se encuentre en una partición independiente por motivos de seguridad, comodidad y flexibilidad (entre otros).

Si hemos seguido este buen y ya conocido consejo y tenemos particiones independientes, deberemos entonces de controlar la configuración de /etc/fstab. Normalmente salvo casos excepcionales no existe una buena razón que nos obligue a ejecutar scripts con los bits suid y sgid activados en los directorios /home de los usuarios, o en aquellas particiones con permisos de escrituras para usuarios no root, por lo que una medida que podremos tomar será añadir la opción (si es que no viene ya por defecto) nosuid a estas particiones. Podemos también evitar la creación de archivos de bloques o caracter y ejecución de programas en estos directorios y en /var con las opciones nodev y noexec respectivamente.

Archivos con permisos de escritura

Otra búsqueda que podemos realizar por el sistema es aquella que localice a archivos o directorios que contienen activados el permiso de escritura para todos los usuarios. Es evidente que no querremos dejar que un invitado, intruso, atacante, compañero hostil o cualquier otra persona non grata pueda modificar archivos que consideramos importantes, vulnerables o que simplemente no queremos perder su control, sin mas y mucho menos que un directorio caiga en manos de estos dándoles directamente permisos para añadir o eliminar contenido en él. Para localizar estos archivos y directorios podemos usar el siguiente termino de búsqueda con find:

# find / -perm -2 [-type f|d] -print

Esto imprimirá una larga lista que seguramente resulte bastante tediosa de seguir, por lo que podemos limitar la búsqueda por aquellos directorios que mas nos interesen. Los enlaces simbólicos serán añadidos a la lista pero como sabemos el permiso definitivo será el que tenga el archivo al que enlaza. También aparecerán bastantes archivos bajo /var.

Archivos sin propietario

Los archivos sin propietario pueden ser un indicio de que alguien ajeno a nosotros a estado fisgoneando nuestro sistema, por lo que no estaría de mas dar un repaso en busca de estos archivos.

# find / -nouser -o -nogroup -print

Habilitación de hosts

Durante el capítulo – 6 cuando configuramos el equipo para permitir el acceso remoto de otras aplicaciones al servidor X del sistema, vimos la importancia del comando xhost con el que se indicaba un host o usuario al que permitir acceso remoto mediante X. En el sistema, dependiendo de a que o para quien otorguemos permisos para una determinada acción, como dar acceso al servidor de X a aplicaciones o usuarios remotos, se crean unos determinados ficheros que de tener una configuración incorrecta o poco cuidada pueden resultar en agujeros de seguridad en el sistema. Aunque siempre será mejor utilizar protocolos seguros como ssh, vamos a citar algunos archivos con los que a la hora de configurarlos si se necesitase, deberíamos de andar con cuidado.

• ~/.rhost : Cuando este archivo está presente en el directorio /home de un usuario significa que se ha creado una relación entre este usuario y otro usuario o máquina de la red. En otras palabras estaremos dando acceso mediante los comandos (rcp, rlogin, rexec, etc…) sin contraseña a los usuarios y máquinas especificados en este archivo. Por ello deberemos de tener bastante cuidado a quien ofrecemos nuestro sistema. Un intruso podría utilizar este archivo para crear relaciones con máquinas externas.
• /etc/hosts.equiv : Es exactamente igual que el archivo anterior pero mas peligroso aún, ya que se crean relaciones a nivel de máquina especificando que servicios, usuarios y grupos pueden acceder sin contraseña a los servicios. Un sigo ‘+‘ otorgará permisos a “cualquier” máquina.

Nota: Normalmente estos archivos ya no suelen existen a consecuencia del uso de protocolos seguros como ssh.

Módulos PAM

Los módulos PAM son bibliotecas compartidas que implementan un método que permiten al administrador del sistema controlar cómo se realiza el proceso de autenticación de los usuarios en determinados programas. Las bibliotecas PAM se encuentran en /lib/security mientras que los archivos de configuración para cada aplicación que los utiliza se instalan bajo el directorio /etc/pam.d. Algunas de las aplicaciones que utilizan estos módulos para la autenticación de usuarios podrían ser: cron, su, sudo, samba, login, mdm, xdm, gdm, kdm…

Una línea típica de estos ficheros de configuración podría ser:

modulo flag ruta-al-modulo argumentos

donde:

• Modulo : indica el requisito a realizar como por ejemplo, que sea necesario la autenticación (auth), que se trate de un acceso restringido (account), tareas a realizar cuando un usuario entra o sale (session), indicar la contraseña (password)
• flag o bandera de control : especifican las necesidades. Que sea un requisito (requisite), necesario (required), suficiente (sufficient) o opcional (optional). Otra posibilidad para las banderas de control es utilizar la sintaxis ‘valor y acción‘
• ruta al módulo o path
• Argumentos : dependiendo de cada módulo podremos pasar uno u otros argumentos.

A modo de ejemplo se van a mostrar solo tres líneas de uno de los archivos de configuración, algo que no será suficiente. Los módulos PAM son material que no se abarca en LPIC-1 y que solo se han comentado como base de conocimiento. Si se desea profundizar mas, como siempre se recomiendo las páginas man, HOWTOs de Internet, foros, etc…

auth required pam_unix.so nullok

account required pam_unix.so

session optional pam_lastlog.so

Notas del autor:

• Agradeceré infinitamente vuestro apoyo en www.facebook.com/4adminsys

• Para ampliar los conocimientos podéis pasaros por www.nebul4ck.wordpress.com

Curso LPIC-1 400 Capítulo 10 por nebul4ck se distribuye bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Puede contratar ExtreHost para temas profesionales con sus servidores. No lo dude, contáctenos.