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 capítulo se explican cuatro formas básicas de mejorar la seguridad del host:

Algunos comandos básicos y ajustes de configuración para mejorar la seguridad de la autenticación con contraseñas shadow.
Cómo utilizar los superdaemons para escuchar las conexiones de red entrantes.
Comprobación de los servicios de red en busca de demonios innecesarios.
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.

Aunque en los sistemas modernos la contraseña ya no se almacena en el archivo /etc/passwd. En su lugar, el campo de la contraseña sólo contiene una x minúscula. El archivo /etc/passwd tiene que ser legible por todos los usuarios. Por lo tanto, 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. Este archivo no debe ser legible para todos los usuarios.

La configuración de las contraseñas se hace con los comandos passwd y chage. Ambos comandos cambiarán la entrada para el usuario emma en el archivo /etc/shadow. Como superusuario puede configurar la contraseña para el usuario emma con el siguiente comando:

$ sudo passwd emma
New password:
Retype new password:
passwd: password updated successfully

A continuación, se le pedirá dos veces que confirme la nueva contraseña.

Para listar el tiempo de expiración de la contraseña y otros ajustes de expiración de la contraseña para el usuario emma utilice:

$ sudo chage -l emma
Last password change					: Apr 27, 2020
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

Para evitar que el usuario emma se registre en el sistema, el superusuario puede establecer una fecha de caducidad de la contraseña que preceda a la fecha actual. Por ejemplo, si la fecha de hoy fuera 2020-03-27, podría caducar la contraseña del usuario utilizando una fecha más antigua:

$ sudo chage -E 2020-03-26 emma

Como alternativa, el superusuario puede utilizar:

$ sudo passwd -l emma

para bloquear la cuenta temporalmente mediante la opción l de passwd. Para probar los efectos de estos cambios, intente iniciar sesión como la cuenta emma:

$ sudo login emma
Password:
Your account has expired; please contact your system administrator

Authentication failure

Para evitar que todos los usuarios, excepto el usuario root, inicien sesión en el sistema temporalmente, el superusuario puede crear un archivo llamado /etc/nologin. 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, como los servidores web, los de correo electrónico y de impresión, suelen ejecutarse como independiente que escucha en un puerto de red dedicado. Todos estos servicios se ejecutan uno al lado del otro. En un sistema clásico basado en Sys-V-init cada uno de estos servicios puede ser controlado por el comando service. En los sistemas actuales basados en systemd se utiliza systemctl para gestionar el servicio. En épocas anteriores, la disponibilidad de recursos informáticos era mucho menor. Ejecutar muchos servicios en modo autónomo no era una buena opción. En su lugar, se utilizaba el llamado superdemonio, que escuchaba las conexiones de red entrantes e iniciaba el servicio apropiado a petición. Este método de crear una conexión de red requería un poco más de tiempo. Los superdemonios 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 demostrar 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 en Red Hat. Aunque estas explicaciones han sido probadas con Debian/GNU Linux 9.9 deberían funcionar en cualquier sistema 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 utilice 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 super-servidor 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 SyS-V-init 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. El servicio en nuestro host de ejemplo debe ser accesible desde la red local solamente. 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

¿Cómo se puede desbloquear la cuenta emma previamente bloqueada?
Anteriormente la cuenta emma tenía una fecha de caducidad establecida. ¿Cómo se puede fijar la fecha de caducidad en nunca?
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?
Ha instalado el servidor web nginx. Cómo puede comprobar si nginx admite TCP wrappers ?

Ejercicios de exploración

Compruebe si la existencia del archivo /etc/nologin impide el inicio de sesión del usuario root.
¿La existencia del archivo /etc/nologin impide el inicio de sesión sin contraseña con claves SSH?
¿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?
¿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?
¿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?
¿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ó:

En qué archivo se almacenan las contraseñas, así como algunos ajustes de seguridad de las contraseñas, por ejemplo, el tiempo de caducidad.
El propósito del superdemonio xinetd y cómo hacerlo funcionar e iniciar el servicio sshd bajo demanda.
Cómo comprobar qué servicios de red se están ejecutando y cómo desactivar los servicios innecesarios.
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

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

El superusuario puede ejecutar passwd -u emma para desbloquear la cuenta.
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.
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 "
```
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

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