110.2 Lección 1

110.2 Lección 1

Certificación:

LPIC-1

Versión:

5.0

Tema:

110 Seguridad

Objetivo:

110.2 Configuración de la seguridad del sistema

Lección:

1 de 1

Introducción

En este tema se explican cuatro formas básicas de mejorar la seguridad del host:

  1. Algunos comandos básicos y ajustes de configuración para mejorar la seguridad de la autenticación con contraseñas shadow.

  2. Cómo utilizar los superdaemons para escuchar las conexiones de red entrantes.

  3. Comprobación de los servicios de red en busca de demonios innecesarios.

  4. TCP wrappers como una especie de firewall simple.

Mejorar la seguridad de la autenticación con shadow password

Los componentes básicos de los datos de la cuenta de un usuario se almacenan en el archivo /etc/passwd. Este archivo contiene siete campos: nombre de inicio de sesión, userid, groupid, contraseña, comentario (también conocido como GECOS), ubicación del directorio principal y por último, el shell por defecto. Una forma sencilla de recordar el orden de estos campos es pensar en el proceso de inicio de sesión de un usuario: primero se introduce un nombre de inicio de sesión, en segundo lugar el sistema lo asignará a un userid (uid) y en tercer lugar a un groupid (gid). El cuarto paso pide una contraseña, el quinto busca el comentario, el sexto introduce el directorio personal del usuario y el séptimo paso establece el shell por defecto.

En los sistemas modernos la contraseña ya no se almacena en el archivo /etc/passwd, el campo de la contraseña sólo contiene una x minúscula, esto se hace porque el archivo /etc/passwd tiene que ser legible por todos los usuarios del sistema, así que no es una buena idea almacenar contraseñas allí. La x indica que la contraseña encriptada (hash) se almacena en el archivo /etc/shadow, el cual, no es legible para todos los usuarios, sólo para root.

Como se vió en el tema anterior, la configuración de las contraseñas se hace con los comandos passwd y chage. Puede revisar lo allí expuesto para refrescar el uso de dichos comandos.

Para evitar que todos los usuarios, excepto el usuario root, inicien sesión en el sistema temporalmente, el superusuario puede crear un archivo llamado i Este archivo puede contener un mensaje para los usuarios notificándoles por qué no pueden iniciar sesión (por ejemplo, notificaciones de mantenimiento del sistema). Para más detalles vea man 5 nologin. Tenga en cuenta que también hay un comando nologin que se puede utilizar para evitar un inicio de sesión cuando se establece como el shell por defecto para un usuario. Por ejemplo:

$ sudo usermod -s /sbin/nologin emma

Para más detalles consulte las páginas de manual del comando.

Cómo utilizar un superdemonio para escuchar las conexiones de red entrantes

Los servicios de red, (servidores web, correo electrónico, impresión, mensajería instantánea, transferencia de ficheros, etc..) suelen ejecutarse de forma independiente en modo residente (background), de manera que cada uno se inicia cuando se inicia el sistema, escucha en un puerto de red dedicado, ocupa un espacio en la memoria principal y mantiene en exclusiva un conjunto de recursos del sistema mientras esté activo. En un sistema clásico basado en SysVinit cada uno de estos servicios puede ser controlado por el comando service. En los sistemas actuales basados en systemd se utiliza systemctl para gestionarlos.  Esta forma de mantener vivos los servicios de red absorbe muchos recursos. Si se dispone de una elevada capacidad de cómputo, mucha memoria RAM y dispositivos de almacenamiento suficientes puede optarse por esta política, pero si es necesario economizar recursos, se debe aplicar el esquema de funcionamiento que proporciona el servicio conocido como superdemonio o superservidor.

El superdemonio, escuchaba todas las conexiones de red entrantes e iniciaba el servicio apropiado a petición. Este método de crear una conexión de red requiere un poco más de tiempo pero ahorra muchos recursos. Los superdemonios (superservidores) más conocidos son inetd y xinetd. En los sistemas actuales basados en systemd la unidad systemd.socket se puede utilizar de forma similar.

En esta sección, utilizaremos xinetd para interceptar las conexiones al demonio sshd y arrancar este demonio a petición para ilustrar cómo se utiliza el superdemonio.

Antes de configurar el servicio xinetd es necesario realizar algunos preparativos. No importa si utiliza un sistema basado en Debian o basado en Red Hat. Aunque estas explicaciones han sido probadas con Debian/GNU Linux 9.9 deberían funcionar en cualquier sistema GNU/ Linux actual que cuente con systemd, sin ningún cambio significativo. Primero asegúrese de que los paquetes openssh-server y xinetd están instalados. Ahora verifique que el servicio SSH funciona con:

$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-04-27 09:33:48 EDT; 3h 11min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 430 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 460 (sshd)
    Tasks: 1 (limit: 1119)
   Memory: 5.3M
   CGroup: /system.slice/ssh.service
           └─460 /usr/sbin/sshd -D

Compruebe también que el servicio SSH está escuchando en su puerto de red estándar 22:

# lsof -i :22
COMMAND  PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd    1194 root    3u  IPv4 16053268      0t0  TCP *:ssh (LISTEN)
sshd    1194 root    4u  IPv6 16053270      0t0  TCP *:ssh (LISTEN)

Finalmente detenga el servicio SSH con:

$ sudo systemctl stop sshd.service

En el caso de que quiera hacer este cambio permanente, es decir, que el servicio sshd deje de ser gestionado por systemd y lo controle el superdemonio xinetd, ejecute el comando systemctl disable sshd.service.

Ahora puede crear el archivo de configuración de xinetd /etc/xinetd.d/ssh con algunos ajustes básicos:

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}

Reinicie el servicio xinetd con:

$ sudo systemctl restart xinetd.service

Compruebe qué servicio está escuchando ahora las conexiones SSH entrantes.

$ sudo lsof -i :22
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
xinetd  24098 root    5u  IPv4 7345141      0t0  TCP 192.168.178.1:ssh (LISTEN)

Podemos ver que el servicio xinetd ha tomado el control para el acceso del puerto 22.

Aquí hay algunos detalles más sobre la configuración de xinetd. El archivo de configuración principal es /etc/xinetd.conf:

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

}

includedir /etc/xinetd.d

Además de la configuración por defecto, sólo hay una directiva para establecer un directorio de inclusión. En este directorio puede establecer un único fichero de configuración para cada servicio que quiera que sea gestionado por xinetd. Nosotros hemos hecho esto para el servicio SSH y hemos llamado al fichero /etc/xinetd.d/ssh. Los nombres de los ficheros de configuración pueden ser elegidos arbitrariamente, excepto los nombres de ficheros que contengan un punto (.) o que terminen con una tilde (~). Pero es una práctica generalizada nombrar el fichero con el nombre del servicio que se quiere configurar.

Algunos archivos de configuración en el directorio /etc/xinet.d/ ya son proporcionados por la distribución:

$ ls -l /etc/xinetd.d
total 52
-rw-r--r-- 1 root root 640 Feb  5  2018 chargen
-rw-r--r-- 1 root root 313 Feb  5  2018 chargen-udp
-rw-r--r-- 1 root root 502 Apr 11 10:18 daytime
-rw-r--r-- 1 root root 313 Feb  5  2018 daytime-udp
-rw-r--r-- 1 root root 391 Feb  5  2018 discard
-rw-r--r-- 1 root root 312 Feb  5  2018 discard-udp
-rw-r--r-- 1 root root 422 Feb  5  2018 echo
-rw-r--r-- 1 root root 304 Feb  5  2018 echo-udp
-rw-r--r-- 1 root root 312 Feb  5  2018 servers
-rw-r--r-- 1 root root 314 Feb  5  2018 services
-rw-r--r-- 1 root root 569 Feb  5  2018 time
-rw-r--r-- 1 root root 313 Feb  5  2018 time-udp

Estos archivos pueden ser utilizados como plantillas en el raro caso de que tenga que utilizar algunos servicios heredados como daytime, una implementación muy temprana de un servidor de tiempo. Todos estos archivos de plantilla contienen la directiva disable = yes.

Aquí hay más detalles sobre las directivas usadas en el archivo de ejemplo /etc/xinetd.d/ssh para ssh arriba.

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}
service

Muestra el servicio que xinetd debe controlar. Puede utilizar un número de puerto, como el 22, o el nombre asignado al número de puerto en /etc/services, por ejemplo ssh.

{

Los ajustes detallados comienzan con una llave de apertura.

disable

Para activar esta configuración, póngala en no. Si quiere desactivar la configuración temporalmente, puede ponerla en yes.

socket_type

Puede elegir stream para sockets TCP o dgram para sockets UDP y más.

protocol

Elija entre TCP o UDP.

wait

En el caso de las conexiones TCP, este valor suele ser no.

user

El servicio iniciado en esta línea será propiedad de este usuario.

server

Ruta completa del servicio que debe ser iniciado por xinetd.

server_args

Aquí puede añadir opciones para el servicio. Si es iniciado por un super-servidor, muchos servicios requieren una opción especial. Para SSH esta sería la opción -i.

flags

Puede elegir IPv4, IPv6 y otros.

interface

La interfaz de red que xinetd debe controlar. Nota: también puede elegir la directiva bind, que no es más que un sinónimo de interfaz.

}

Termina con un corchete de cierre.

Los sucesores de los servicios iniciados por el superservidor xinetd son unidades de socket systemd. Configurar una unidad de socket systemd es muy sencillo y fácil, porque ya existe una unidad de socket systemd predefinida para SSH. Asegúrese de que los servicios xinetd y SSH no se están ejecutando.

Ahora sólo tiene que iniciar la unidad de socket SSH:

$ sudo systemctl start ssh.socket

Para comprobar qué servicio está ahora escuchando en el puerto 22 utilizamos de nuevo lsof. Observe que aquí se ha utilizado la opción -P para mostrar el número de puerto en lugar del nombre del servicio en la salida:

$ sudo lsof -i :22 -P
COMMAND PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
systemd   1 root   57u  IPv6 14730112      0t0  TCP *:22 (LISTEN)

Para que esta sesión sea completa, debe intentar iniciar sesión en su servidor con un cliente SSH de su elección.

Tip

En caso de que systemctl start ssh.socket no funcione con su distribución, pruebe con systemctl start sshd.socket.

Comprobación de servicios en busca de daemons innecesarios

Por razones de seguridad, así como para controlar los recursos del sistema, es importante tener una visión general de los servicios que se están ejecutando. Los servicios innecesarios y no utilizados deben ser desactivados. Por ejemplo, si no necesita distribuir páginas web, no es necesario ejecutar un servidor web como Apache o nginx.

En los sistemas basados en SySVinit puede comprobar el estado de todos los servicios con lo siguiente:

$ sudo service --status-all

Verifique si cada uno de los servicios listados en la salida del comando son necesarios y desactive todos los servicios innecesarios con (para sistemas basados en Debian):

$ sudo update-rc.d SERVICE-NAME remove

O en los sistemas basados en Red Hat se utilizaría:

$ sudo chkconfig SERVICE-NAME off

En los sistemas modernos basados en systemd podemos utilizar lo siguiente para listar todos los servicios en ejecución:

$ systemctl list-units --state active --type service

A continuación, desactivaría cada unidad de servicio innecesaria con:

$ sudo systemctl disable UNIT --now

Este comando detendrá el servicio y lo eliminará de la lista de servicios, para evitar que se inicie en el próximo arranque del sistema.

Además, para obtener un estudio de los servicios de red en escucha, puede utilizar netstat en sistemas antiguos (siempre que tenga instalado el paquete net-tools):

$ netstat -ltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:mysql         0.0.0.0:*               LISTEN
tcp6       0      0 [::]:http               [::]:*                  LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*

O en los sistemas modernos, puede utilizar el comando equivalente ss (para “socket services”):

$ ss -ltu
Netid      State         Recv-Q        Send-Q      Local Address:Port           Peer Address:Port
udp        UNCONN        0             0                 0.0.0.0:bootpc              0.0.0.0:*
tcp        LISTEN        0             128               0.0.0.0:ssh                 0.0.0.0:*
tcp        LISTEN        0             80              127.0.0.1:mysql               0.0.0.0:*
tcp        LISTEN        0             128                     *:http                      *:*
tcp        LISTEN        0             128                  [::]:ssh                    [::]:*

TCP Wrappers como una especie de Firewall simple

En los tiempos en que no había cortafuegos disponibles para Linux, se utilizaban TCP Wrappers para asegurar las conexiones de red en un host. Hoy en día muchos programas ya no obedecen a los TCP wrappers. En las distribuciones recientes basadas en Red Hat (por ejemplo, Fedora 29) el soporte de TCP wrappers ha sido eliminado completamente. Para dar soporte a los sistemas Linux heredados que todavía utilizan TCP wrappers, es útil tener algunos conocimientos básicos sobre esta tecnología en particular.

Una vez más utilizaremos el servicio SSH como ejemplo básico; vamos a establecer con TCP wrappers una restricción consistente en impedir que el servicio sshd sea acesible desde posiciones que no  pertenezca a nuestra red local.
Primero, comprobamos si el demonio SSH utiliza la biblioteca libwrap que ofrece soporte a TCP wrappers:

$ ldd /usr/sbin/sshd | grep "libwrap"
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f91dbec0000)

Ahora, añadimos la siguiente línea en el archivo /etc/hosts.deny:

sshd: ALL

Finalmente, configuramos una excepción en el archivo /etc/hosts.allow para las conexiones SSH desde la red local:

sshd: LOCAL

Los cambios tienen efecto inmediato, no es necesario reiniciar ningún servicio. Puede comprobarlo con el cliente ssh.

Ejercicios guiados

  1. ¿Cómo se puede desbloquear la cuenta emma previamente bloqueada?

  2. Anteriormente la cuenta emma tenía una fecha de caducidad establecida. ¿Cómo se puede fijar la fecha de caducidad en nunca?

  3. Imagine que el servicio de impresión CUPS que gestiona los trabajos de impresión no es necesario en su servidor. ¿Cómo puede desactivar el servicio de forma permanente? ¿Cómo puede comprobar que el puerto correspondiente ya no está activo?

  4. Ha instalado el servidor web nginx. Cómo puede comprobar si nginx admite TCP wrappers ?

Ejercicios de exploración

  1. Compruebe si la existencia del archivo /etc/nologin impide el inicio de sesión del usuario root.

  2. ¿La existencia del archivo /etc/nologin impide el inicio de sesión sin contraseña con claves SSH?

  3. ¿Qué sucede en el inicio de sesión, cuando el archivo /etc/nologin contiene esta línea de texto login currently is not possible solamente?

  4. ¿Puede un usuario ordinario emma obtener información sobre el usuario root contenida en el fichero /etc/passwd por ejemplo con el comando grep root /etc/passwd?

  5. ¿Puede un usuario ordinario emma obtener información sobre el usuario root contenida en el fichero /etc/passwd por ejemplo con el comando grep root /etc/passwd?

  6. ¿Qué pasos hay que dar para habilitar y comprobar que el servicio heredado daytime sea manejado por xinetd? Tenga en cuenta que esto es sólo un ejercicio de exploración no hacer esto en un entorno de producción.

Resumen

En esta lección aprendió:

  1. En qué archivo se almacenan las contraseñas, así como algunos ajustes de seguridad de las contraseñas, por ejemplo, el tiempo de caducidad.

  2. El propósito del superdemonio xinetd y cómo hacerlo funcionar e iniciar el servicio sshd bajo demanda.

  3. Cómo comprobar qué servicios de red se están ejecutando y cómo desactivar los servicios innecesarios.

  4. La utilización de TCP Wrappers como una especie de cortafuegos simple.

Los comandos utilizados en esta lección incluyen:

chage

Cambiar la edad de la contraseña de un usuario.

chkconfig

Un comando clásico utilizado inicialmente en los sistemas basados en Red Hat para establecer si un servicio se iniciará en el momento del arranque o no.

netstat

Una utilidad clásica (ahora en el paquete net-tools) que mostrará los demonios que acceden a los puertos de red en un sistema y su uso.

nologin

Un comando que se puede utilizar en lugar del shell de un usuario para evitar que inicie sesión.

passwd

Se utiliza para crear o cambiar la contraseña de un usuario.

service

Método más antiguo para controlar el estado de un demonio, como detener o iniciar un servicio.

ss

El equivalente moderno a netstat, pero también muestra más información sobre los distintos sockets en uso en el sistema.

systemctl

El comando del sistema utilizado para controlar varios aspectos de los servicios y sockets en un ordenador utilizando systemd.

update-rc.d

Un comando clásico similar a chkconfig que habilita o deshabilita el arranque de un sistema en las distribuciones basadas en Debian.

xinetd

Un superdemonio que puede controlar el acceso a un servicio de red bajo demanda, dejando así un servicio inactivo hasta que se le pida que realice alguna tarea.

Respuestas a los ejercicios guiados

  1. ¿Cómo se puede desbloquear la cuenta emma previamente bloqueada?

    El superusuario puede ejecutar passwd -u emma para desbloquear la cuenta.

  2. Anteriormente la cuenta emma tenía una fecha de caducidad establecida. ¿Cómo se puede fijar la fecha de caducidad en nunca?

    El superusuario puede utilizar chage -E -1 emma para fijar la fecha de caducidad en nunca. Esta configuración se puede comprobar con chage -l emma.

  3. Imagine que el servicio de impresión CUPS que gestiona los trabajos de impresión no es necesario en su servidor. ¿Cómo puede desactivar el servicio de forma permanente? ¿Cómo puede comprobar que el puerto correspondiente ya no está activo?

    Como superusuario

    systemctl disable cups.service --now

    Ahora puede comprobar

    netstat -l | grep ":ipp "` o `ss -l | grep ":ipp "

  4. Ha instalado el servidor web nginx. Cómo puede comprobar si nginx admite TCP wrappers ?

    El comando

    ldd /usr/sbin/nginx | grep "libwrap"

    mostrará una entrada en caso de que nginx soporte TCP wrappers.

Respuestas a los ejercicios de exploración

  1. Compruebe si la existencia del archivo /etc/nologin impide el inicio de sesión del usuario root?

    El usuario root aún puede iniciar sesión.

  2. ¿La existencia del archivo /etc/nologin impide el inicio de sesión sin contraseña con claves SSH?

    Sí, también se impiden los inicios de sesión sin contraseña.

  3. ¿Qué sucede en el inicio de sesión, cuando el archivo /etc/nologin contiene esta línea de texto login currently is not possible solamente?

    Se mostrará el mensaje login currently is not possible y se impedirá el inicio de sesión.

  4. ¿Puede un usuario ordinario emma obtener información sobre el usuario root contenida en el fichero /etc/passwd por ejemplo con el comando grep root /etc/passwd?

    Sí, porque todos los usuarios tienen permiso de lectura para este archivo.

  5. ¿Puede un usuario ordinario emma obtener información sobre el usuario root contenida en el fichero /etc/passwd por ejemplo con el comando grep root /etc/passwd?

    No, porque los usuarios normales no tienen permiso de lectura para este archivo.

  6. ¿Qué pasos hay que dar para habilitar y comprobar que el servicio heredado daytime sea manejado por xinetd? Tenga en cuenta que esto es sólo un ejercicio de exploración no hacer esto en un entorno de producción.

    Primero, cambie el archivo /etc/xinetd.d/daytime y establezca la directiva disable = no. Segundo, reinicie el servicio xinetd systemctl restart xinetd.service (o service xinetd restart en sistemas con SyS-V-Init). Ahora puede comprobar si funciona nc localhost daytime. En lugar de nc también puede utilizar netcat.

Linux Professional Insitute Inc. Todos los derechos reservados. Visite el sitio web de Learning Materials: https://learning.lpi.org
Este trabajo está registrado bajo la Licencia Internacional Creative Commons Attribution-NonCommercial-NoDerivatives 4.0