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:
-
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.
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 ejemplossh
. {
-
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 enyes
. socket_type
-
Puede elegir
stream
para sockets TCP odgram
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 directivabind
, que no es más que un sinónimo deinterfaz
. }
-
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 |
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
-
¿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 ennunca
?
-
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 usuarioroot
.
-
¿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 textologin currently is not possible
solamente?
-
¿Puede un usuario ordinario
emma
obtener información sobre el usuarioroot
contenida en el fichero/etc/passwd
por ejemplo con el comandogrep root /etc/passwd
?
-
¿Puede un usuario ordinario
emma
obtener información sobre el usuarioroot
contenida en el fichero/etc/passwd
por ejemplo con el comandogrep 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 serviciosshd
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 ennunca
?El superusuario puede utilizar
chage -E -1 emma
para fijar la fecha de caducidad en nunca. Esta configuración se puede comprobar conchage -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 usuarioroot
?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 textologin 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 usuarioroot
contenida en el fichero/etc/passwd
por ejemplo con el comandogrep 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 usuarioroot
contenida en el fichero/etc/passwd
por ejemplo con el comandogrep 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 directivadisable = no
. Segundo, reinicie el servicio xinetdsystemctl restart xinetd.service
(oservice xinetd restart
en sistemas con SyS-V-Init). Ahora puede comprobar si funcionanc localhost daytime
. En lugar denc
también puede utilizarnetcat
.