Hablando sobre seguridad en Linux

Uno de los aspectos más importante de un técnico de sistemas Linux es velar por la seguridad informática de los sistemas. No paran de aparecer noticias en los medios de ataques Ransomware pidiendo un rescate económico a las empresas para devolverles sus sistemas que, al fin y al cabo, son sus negocios.

Por lo tanto, es impreativo proteger el sistema de ataques. Se pueden escribir libros enteros sobre el tema pero, en este artítulo, voy a enumerar algunos de los aspectos básicos para proteger los sistemas Linux que, espero, sean de utilidad.

Medidas básicas para protegernos de un ataque Ransomware

Proteger un entorno de servidores físicos Linux con redundancia frente a un ataque de ransomware es crucial para garantizar la disponibilidad y la integridad de los datos y servicios. Aquí hay una serie de medidas que podemos tomar para proteger el sistema y minimizar el impacto en caso de un ataque de ransomware:

1. Segmentación de red: Dividir la red en segmentos para limitar la propagación del ransomware. Esto significa que, si un servidor se ve comprometido, el ataque no se propagará fácilmente a otros servidores en la red.

2. Actualizaciones y parches: Mantener todos los sistemas operativos, software y aplicaciones actualizados con los últimos parches de seguridad. Los ransomware a menudo explotan vulnerabilidades conocidas.

3. Firewalls y listas blancas: Utilizar firewalls para bloquear el tráfico no deseado y asegurarse de que sólo se permita el tráfico necesario. Podemos considerar la implementación de listas blancas para autorizar aplicaciones y servicios específicos.

4. Control de acceso: Limitar el acceso a los servidores solo a personal autorizado y aplica el principio de privilegio mínimo. Utilizar autenticación de dos factores (2FA) siempre que sea posible.

5. Monitorización y detección de amenazas: Implementar sistemas de monitoreo de seguridad que alerten sobre comportamientos anómalos o sospechosos.

6. Copia de seguridad y recuperación de datos:

   – Realizar copias de seguridad periódicas y automatizadas de todos los datos críticos.

   – Almacenar las copias de seguridad en ubicaciones aisladas y seguras, como medios externos o en la nube.

   – Probar regularmente la capacidad de restaurar los datos desde las copias de seguridad para garantizar que sean viables.

7. Segmentación de usuarios y privilegios: Dividir a los usuarios en grupos y otorgar permisos basados en roles. Los usuarios no deben tener acceso a recursos o sistemas que no sean necesarios para sus funciones.

8. Formación y concienciación: Educar a los empleados sobre las amenazas de seguridad, cómo identificar correos electrónicos de phishing y cómo actuar si sospechan de un ataque de ransomware. La formación puede ayudar a prevenir la infección inicial.

9. Políticas de ejecución de archivos: Configurar políticas que limiten la ejecución de archivos solo a aquellos que son necesarios para las operaciones diarias.

10. Aislamiento de servidores comprometidos: Si un servidor se ve comprometido, desconéctalo de la red lo antes posible para evitar la propagación del ransomware a otros servidores.

11. Evaluación de la seguridad: Realizar auditorías de seguridad periódicas y pruebas de penetración para identificar posibles vulnerabilidades antes de que los atacantes las exploten.

¿Cuáles son los logs de Linux más importantes que deberíamos mirar cuando recibimos un ataque Ransomware?

Cuando tenemos sospechas de que un sistema Linux ha sido víctima de un ataque de ransomware, es esencial revisar los logs del sistema para tratar identificar los servicios vulnerables y entender cómo ocurrió el ataque. A continuación, se mencionan algunos de los registros más importantes que a revisar:

1. Logs de autenticación (auth.log o secure):

• /var/log/auth.log (en sistemas basados en Debian/Ubuntu) o /var/log/secure (en sistemas basados en Red Hat/CentOS).
• Buscaremos intentos de inicio de sesión no autorizados o actividades sospechosas, como acceso a cuentas de administrador.

1. Logs del servidor web:

• /var/log/apache2/access.log (para Apache) o /var/log/nginx/access.log (para Nginx).
• Buscaremos solicitudes HTTP inusuales o patrones de acceso inesperados que puedan indicar un ataque web.

1. Logs del sistema:

• /var/log/syslog o /var/log/messages.
• Revisaremos eventos generales del sistema, como reinicios inesperados, errores del kernel o eventos de hardware.

1. Logs de seguridad:

• /var/log/security o /var/log/audit/audit.log.
• Estos logs registran eventos de seguridad, como cambios en políticas de seguridad, intentos de acceso a recursos protegidos y auditorías de seguridad.

1. Logs de firewall (iptables o firewalld):

• /var/log/iptables.log o /var/log/firewalld.
• Buscaremos conexiones bloqueadas o permitidas por el firewall que no deberían estar allí.

1. Logs de bases de datos:

• Si nuestro servidor ejecuta una base de datos, como MySQL o PostgreSQL, revisa los registros de la base de datos en busca de actividad inusual o intentos de acceso no autorizados.

1. Logs de aplicaciones:

• Los registros específicos de las aplicaciones que se ejecutan en tu servidor pueden contener información relevante sobre actividades sospechosas. Esto dependerá de las aplicaciones específicas que estés ejecutando.

1. Logs de correos electrónicos:

• /var/log/mail.log o /var/log/maillog.
• Buscaremos intentos de envío de correo no autorizados o actividad de spam.

1. Logs de monitorización y seguridad de terceros:

• Si utilizamos soluciones de monitorización o seguridad de terceros, revisaremos sus registros en busca de alertas o eventos relacionados con el ransomware.

1. Logs de integridad de archivos:
   • Utilizaremos herramientas como Tripwire o AIDE, por citar un par, para verificar la integridad de los archivos en busca de cambios inesperados.

Al revisar estos registros, buscaremos patrones de actividad inusual, eventos de autenticación fallidos, conexiones inusuales o cualquier otro comportamiento sospechoso. También es importante implementar una solución de detección de intrusiones o un sistema de gestión de eventos de seguridad para automatizar la detección de amenazas y alertas tempranas en tiempo real.

Persistencia a nivel de servicio

La persistencia de un servidor UNIX físico es la capacidad de mantener los datos y el estado del servidor en caso de un fallo del sistema.

Esto se puede lograr mediante una variedad de métodos, como el almacenamiento en cabinas de disco, softwares de alta disponibilidad como ServiceGuard o Veritas Cluster, por citar alguno de ellos, la redundancia a nivel de tarjetas de red o balanceadores de carga.

Los siguientes son algunos de los beneficios de la persistencia de servidores UNIX físicos:

• Protección de datos: La persistencia ayuda a proteger los datos y el estado del servidor en caso de un fallo del sistema.
• Continuidad del negocio: La persistencia ayuda a garantizar que el servidor siga funcionando en caso de un fallo del sistema, lo que puede ayudar a mantener la continuidad del negocio.
• Mejor rendimiento: La persistencia puede ayudar a mejorar el rendimiento del servidor al proporcionar un acceso más rápido a los datos y al estado del sistema. Es habitual configurar diferentes servicios en diferentes nodos del cluster para repartir la carga entre varios servidores.

La mejor opción de persistencia para un servidor UNIX físico dependerá de las necesidades específicas de cada entorno.

Configurar un entorno con alta disponibilidad es la mejor manera de mantener el servicio activo cuando sufrimos alguna avería hardware, problema software o ataque en alguno de los servidores, ya que siempre tendremos otro servidor disponible que pueda prestar el servicio a los usuarios.

Si queréis saber cómo se monta un cluster podéis echarle un vistazo a estos tutoriales:

• Guía de ServiceGuard
• Guía de Veritas Cluster
• Guía de Pacemaker
• Configuración de un balanceador de carga con HAProxy

Fichero authorized_keys

Si te suena a chino lo que es el fichero authorized_keys, echa un vistazo al manual de SSH.

El archivo «authorized_keys» es un componente clave en los sistemas UNIX y Linux que se utiliza para la autenticación remota mediante SSH (Secure Shell). Sirve como un mecanismo de seguridad que permite a un usuario o una entidad confiable acceder de forma segura a una cuenta de usuario en un sistema remoto sin necesidad de una contraseña. Aquí hay una explicación más detallada:

1. Autenticación sin contraseña: El archivo «authorized_keys» permite la autenticación sin contraseña para las conexiones SSH. En lugar de ingresar una contraseña cada vez que se inicia una sesión SSH, el sistema verifica si la clave pública del cliente SSH coincide con una de las claves públicas listadas en el archivo «authorized_keys».

2. Claves públicas y privadas: SSH utiliza un sistema de claves pública y privada para la autenticación. El usuario remoto genera un par de claves: una clave pública y una clave privada. La clave pública se copia en el archivo «authorized_keys» en el sistema al que se desea acceder, mientras que la clave privada se mantiene en secreto en el dispositivo del usuario. El sistema remoto utiliza la clave pública para verificar la identidad del usuario.

3. Seguridad mejorada: La autenticación basada en claves SSH es considerada más segura que la autenticación basada en contraseñas porque las claves son largas y difíciles de adivinar, y no se envían por la red. Además, el acceso a la clave privada se protege mediante una contraseña o una frase de contraseña, lo que agrega una capa adicional de seguridad.

4. Gestión de acceso: El archivo «authorized_keys» permite a los administradores de sistemas controlar quién tiene acceso a una cuenta específica en un sistema. Pueden agregar o eliminar claves públicas en este archivo para permitir o revocar el acceso de usuarios específicos.

Para agregar una clave pública al archivo «authorized_keys», generalmente se realiza mediante el comando `ssh-copy-id` o copiando manualmente la clave pública en el archivo authorized_keys del sistema remoto al que nos queremos conectar.

Para generar una nueva clave pública y privada, utilizaremos el comando ssh-keygen -t rsa.

Es importante tener en cuenta que se debe mantener la seguridad de las claves privadas en todo momento, ya que proporcionan acceso a las cuentas de usuario.

¿Cómo puede utilizar un atacante el fichero authorized_keys para su propio beneficio?

El archivo «authorized_keys» en sistemas UNIX y Linux se utiliza para proporcionar autenticación segura mediante SSH, y su uso está diseñado para ser administrado por los propios usuarios o administradores de sistemas.

Sin embargo, si un atacante obtiene acceso no autorizado al archivo «authorized_keys», podría comprometer la seguridad del sistema de varias maneras:

1. Añadir una clave pública maliciosa: Un atacante con acceso al archivo «authorized_keys» podría agregar su propia clave pública en ese archivo. Esto le daría acceso remoto al sistema sin necesidad de una contraseña, siempre y cuando pueda acceder al sistema con la clave privada correspondiente.

2. Reemplazar claves legítimas: Un atacante podría reemplazar las claves públicas legítimas en el archivo «authorized_keys» con sus propias claves públicas. Esto les permitiría acceder a cuentas de usuario legítimas sin permiso.

3. Eliminar claves legítimas: Si un atacante elimina las claves públicas legítimas del archivo «authorized_keys», los usuarios legítimos ya no podrían acceder a través de SSH.

Medidas de seguridad del fichero authorized_keys

Para proteger el archivo «authorized_keys» y evitar que los atacantes lo utilicen de manera maliciosa. Algunas buenas prácticas de seguridad que todo administrador de sistemas debería conocer, son:

1. Restringir el acceso al sistema: Limitar el acceso físico y lógico al servidor para evitar que los atacantes accedan al sistema. Utilizar medidas de seguridad físicas y de red, como firewalls, para reducir o anular ataques al sistema.

2. Cifrar las claves privadas: Almacenar las claves privadas de SSH en un lugar seguro y protégelas con una contraseña o una frase de contraseña fuerte. Esto evita que un atacante pueda utilizar la clave privada si la obtiene.

3. Utilizar contraseñas fuertes: Siempre configurar contraseñas fuertes para las cuentas de usuario y deshabilitar la autenticación basada en contraseña en favor de la autenticación basada en clave pública, siempre que sea posible.

4. Control de acceso: Limitar quién tiene acceso al archivo «authorized_keys» y a las cuentas de usuario en general. Sólo los usuarios autorizados tengan permiso para modificar este archivo.

5. Monitorización y auditoría: Establecer un sistema de registro y auditoría para realizar un seguimiento de las actividades en el sistema, lo que puede ayudar a detectar cambios no autorizados en el archivo «authorized_keys» (auditd).

Usuarios locales

Protegerse contra un atacante que intenta crear usuarios locales con intenciones maliciosas en un sistema requiere de medidas de seguridad adecuadas. Aquí hay algunas recomendaciones para ayudarte a fortalecer la seguridad y prevenir la creación no autorizada de usuarios locales:

1. Mantener el sistema actualizado: Asegúrate de que el sistema operativo y todo el software estén actualizados con los últimos parches de seguridad. Los atacantes a menudo buscan vulnerabilidades en versiones antiguas del software.

2. Utilizar contraseñas seguras: Exige contraseñas fuertes para las cuentas de usuario. Una contraseña fuerte debe incluir una combinación de letras mayúsculas y minúsculas, números y caracteres especiales. Además, establece políticas de cambio de contraseña periódico.

3. Limitar el acceso: Implementa el principio de privilegio mínimo. Esto significa que los usuarios deben tener solo los permisos necesarios para realizar sus tareas. Evita otorgar permisos de administrador a menos que sea absolutamente necesario.

4. Control de acceso físico: Protege físicamente el hardware del servidor o la estación de trabajo para evitar que alguien pueda acceder físicamente al sistema y crear usuarios locales.

5. Auditoría y registro: Habilita el registro de auditoría en el sistema para realizar un seguimiento de las actividades de usuario. Esto te permitirá detectar actividades sospechosas y rastrear quién creó o modificó usuarios.

6. Bloqueo de acceso remoto no autorizado: Configura firewalls y herramientas de seguridad para bloquear el acceso remoto no autorizado al sistema. Limita las conexiones a través de SSH, RDP u otros protocolos a direcciones IP específicas y utiliza autenticación de dos factores si es posible.

7. Seguridad física: Asegura que los servidores y las estaciones de trabajo estén ubicados en lugares físicamente seguros y restringidos para evitar el acceso no autorizado.

8. Monitorización de seguridad: Implementa soluciones de monitoreo de seguridad y sistemas de detección de intrusiones para detectar actividades anómalas o intentos de creación de usuarios no autorizados.

9. Utilizar soluciones de gestión de identidad y acceso: Implementa soluciones de gestión de identidad y acceso (IAM) que permitan un control más granular sobre quién puede crear y administrar usuarios locales.

10. Supervisión constante: Mantner una supervisión constante de los registros de eventos y realiza análisis de seguridad de forma regular para detectar posibles amenazas.

Implementación de medidas de seguridad específicas para sistemas Linux

1. Desactivar cuentas de usuario innecesarias:

   – Revisar regularmente las cuentas de usuario y desactivar o eliminar aquellas que no sean necesarias.

   – Utilizar el comando `userdel` para eliminar cuentas de usuario y el comando `passwd -l` para bloquear cuentas temporalmente.

2. Configuración de sudo:

   – Limitar el uso del comando `sudo` solo a usuarios necesarios y específicos.

   – Utilizar el archivo `/etc/sudoers` para definir las políticas de sudo con precisión, permitiendo acciones específicas y limitando el acceso a comandos críticos.

3. Bloqueo de acceso directo a la cuenta root:

   – Deshabilitar el acceso directo a la cuenta root a través de SSH y otros métodos. En su lugar, permitir el acceso con cuentas de usuario normales y luego usa `sudo` para realizar tareas administrativas.

4. Seguridad de SSH:

   – Cambiar el puerto predeterminado de SSH para dificultar los ataques automatizados. Modifica el archivo `/etc/ssh/sshd_config` para cambiar el puerto.

   – Utilizar autenticación de clave pública en lugar de contraseñas siempre que sea posible.

   – Configurar `Fail2Ban` o herramientas similares para bloquear automáticamente direcciones IP después de varios intentos fallidos de inicio de sesión por SSH.

5. SELinux (Security-Enhanced Linux)

   – Considerar habilitar SELinux, una característica de seguridad que proporciona políticas de seguridad más estrictas y controles adicionales sobre el acceso de usuario y aplicación.

Advertencia: SELinux es un producto complejo de administrar que puede provocar incidencias en el servicio si no se configura correctamente. Es altamente improbable configurarlo de manera adecuada la primera vez, por lo que no se recomienda activarlo en sistemas que ya estén prestando servicio en producción, sino, implementarlo en nuevos sistemas.

6. Control de recursos y límites:

   – Utilizar herramientas como `ulimit` para establecer límites en los recursos que los usuarios pueden consumir, como el uso de CPU, memoria y procesos.

7. Registro de auditoría avanzado:

   – Configurar un sistema de registro avanzado, como el uso de `auditd`, para realizar un seguimiento detallado de actividades en el sistema. Esto ayudará a identificar acciones maliciosas.

8. Firewall y filtrado de tráfico:

    – Utilizar firewalls como `iptables`, `firewalld` o cortafuegos físicos para controlar el tráfico de red y asegurarte de que solo los servicios necesarios estén accesibles desde el exterior.

Cuentas de dominio

Proteger un sistema Linux contra ataques que buscan tomar el control de cuentas de dominio es esencial para mantener la seguridad y la integridad de tus sistemas. Aquí tenemos algunas prácticas recomendadas para protegerse contra este tipo de ataques:

1. Mantener el sistema actualizado:

   – Asegurarse de que el sistema operativo, el kernel y todas las aplicaciones estén actualizadas con los últimos parches de seguridad.

2. Fortalecer las contraseñas:

   – Utilizar contraseñas largas y complejas para todas las cuentas de usuario.

   – Implementar políticas de contraseñas que requieran cambios periódicos y eviten el uso de contraseñas comunes.

3. Habilitar la autenticación multifactor:

   – Activar la autenticación multifactor siempre que sea posible, especialmente para cuentas de administrador y usuarios privilegiados.

4. Control de acceso basado en roles

   – Usar sistemas de control de acceso basados en roles para garantizar que sólo las cuentas autorizadas tengan acceso a los recursos adecuados.

5. Eliminar cuentas innecesarias

   – Revisar y eliminar regularmente las cuentas de usuario innecesarias, especialmente las cuentas predeterminadas que puedan ser vulnerables.

6. Monitorización de actividad sospechosa

   – Implementar sistemas de monitorización y registro de actividad para detectar y alertar sobre comportamientos inusuales o sospechosos.

7. Firewalls y filtrado de red

   – Configurar firewalls y reglas de filtrado de red para restringir el acceso no autorizado a servicios y puertos críticos o innecesarios.

8. Respaldo regular de datos:

    – Realizar copias de seguridad regulares de tus datos importantes y verifica que los procedimientos de restauración funcionen correctamente.

Perfiles de usuario

En los sistemas Linux existen varios ficheros que se ejecutan cada vez que un usuario inicia una sesión: /etc/profile /etc/profile.d $HOME/bash_profile $HOME/bash_login $HOME/profile.

Estos ficheros pueden ser objeto de un ataque malicioso y debemos seguir algunas nomas de seguridad para que esto no suceda:

1. Establecer permisos adecuados:

Asegurarse de que sólo el propietario tenga permisos de escritura en estos archivos y que el resto de los usuarios solo tengan permisos de lectura. Podemos hacerlo utilizando el comando `chmod`:

sudo chmod 644 /etc/profile /etc/profile.d/*

chmod 644 ~/.bash_profile ~/.bash_login ~/.profile

Esto garantiza que solo el propietario pueda modificar estos archivos, mientras que otros usuarios solo pueden leerlos.

2. Configurar el propietario y el grupo adecuadamente:

Asegurarse de que el propietario de estos archivos sea el usuario root y que el grupo sea también root. Puedes hacerlo con el comando `chown`:

sudo chown root:root /etc/profile /etc/profile.d/*

3. Implementar autenticación de dos factores:

Habilitar la autenticación de dos factores para acceder al sistema. Esto agrega una capa adicional de seguridad al requerir que los usuarios proporcionen un segundo factor de autenticación además de la contraseña.

4. Auditar estos ficheros con auditd

5. Realiza copias de seguridad:

Realizar copias de seguridad regulares de estos archivos de configuración importantes para que podamos restaurarlos en caso de que se vean comprometidos.

XDG Autostart

¿Qué es XDG Autostart?

XDG Autostart se refiere a un estándar que define cómo se deben gestionar y ejecutar las aplicaciones automáticamente al iniciar sesión en un entorno de escritorio (FreeDesktop.org).

Las aplicaciones que deseen registrarse para ejecutarse automáticamente deben proporcionar un archivo de escritorio (archivo .desktop) que siga las especificaciones de XDG Autostart. Estos archivos .desktop contienen información sobre la aplicación y las instrucciones necesarias para que el entorno de escritorio las inicie automáticamente.

A continuación, se muestran algunos aspectos clave de XDG Autostart:

1. Ubicación de los archivos .desktop: Los archivos .desktop de inicio automático se almacenan en directorios específicos, como `$XDG_CONFIG_HOME/autostart` o `$XDG_CONFIG_DIRS/autostart`, donde `$XDG_CONFIG_HOME` es generalmente `~/.config` y `$XDG_CONFIG_DIRS` suele ser `/etc/xdg`. Los archivos .desktop en estas ubicaciones especifican qué aplicaciones deben iniciarse automáticamente para el usuario o globalmente.

2. Contenido de los archivos .desktop: Los archivos .desktop incluyen información sobre la aplicación, como su nombre, ejecutable, icono y otras propiedades. También pueden contener instrucciones sobre cuándo y cómo se debe iniciar la aplicación, como si debe ejecutarse solo una vez al inicio o en cada inicio de sesión. Ejemplo:

# cat xdg-user-dirs.desktop

[Desktop Entry]

Type=Application

Name=User folders update

TryExec=xdg-user-dirs-update

Exec=xdg-user-dirs-update

StartupNotify=false

NoDisplay=true

X-GNOME-Autostart-Phase=Initialization

X-KDE-autostart-phase=1

#

3. Gestión por parte del entorno de escritorio: El entorno de escritorio es responsable de leer estos archivos .desktop y asegurarse de que las aplicaciones especificadas se ejecuten automáticamente según las instrucciones proporcionadas. Esto puede incluir la ejecución de comandos o la configuración de variables de entorno según sea necesario.

Aprende a añadir un acceso directo en el escritorio de GNOMe

Medidas de seguridad para que un atacante no pueda utilizar XDG Autostart

La explotación de XDG Autostart por parte de un atacante para obtener el control del sistema generalmente requeriría que el atacante tuviera acceso previo al sistema o que pueda manipular los archivos y configuraciones del sistema.

A continuación, se presenta un escenario hipotético de cómo un atacante podría aprovechar XDG Autostart y algunas medidas para evitarlo:

1. Acceso al sistema: El atacante primero tendría que ganar acceso al sistema, ya sea a través de la explotación de una vulnerabilidad, la obtención de credenciales válidas o algún otro método de acceso no autorizado.

2. Manipulación de archivos de inicio automático: Una vez que el atacante tiene acceso al sistema, podría intentar manipular los archivos .desktop en las ubicaciones de inicio automático de XDG (por ejemplo, en `~/.config/autostart` o `/etc/xdg/autostart`) para incluir su propio archivo .desktop malicioso. Este archivo podría apuntar a un programa o script que permita al atacante tomar el control del sistema o realizar acciones maliciosas.

3. Ejecución maliciosa: Cuando el usuario afectado inicia sesión en su entorno de escritorio, el gestor de inicio automático del entorno de escritorio puede ejecutar el programa malicioso especificado en el archivo .desktop manipulado, lo que permitiría al atacante realizar acciones no autorizadas en el sistema.

MEDIDAS DE SEGURIDAD PARA EVITAR LA EXPLOTACIÓN

Para evitar que un atacante aproveche XDG Autostart para obtener el control del sistema, se deben tomar las siguientes medidas:

1. Mantener el sistema seguro: Es fundamental implementar medidas de seguridad sólidas para evitar que los atacantes obtengan acceso no autorizado al sistema en primer lugar. Esto incluye la actualización regular del sistema, el uso de contraseñas fuertes y la implementación de cortafuegos y otras medidas de seguridad.

2. Control de acceso: Restringir el acceso físico y lógico al sistema para que solo las personas autorizadas puedan manipular archivos y configuraciones en las ubicaciones de inicio automático de XDG.

3. Auditoría y monitorización: Implementar herramientas de auditoría y monitoreo para supervisar cambios en los archivos y configuraciones de inicio automático. Esto puede ayudar a detectar cambios no autorizados (auditd).

4. Eliminación de archivos sospechosos: Revisar regularmente las ubicaciones de inicio automático de XDG en busca de archivos .desktop sospechosos o desconocidos y eliminarlos.

5. Políticas de seguridad: Establecer políticas de seguridad que restrinjan la ejecución de programas en ubicaciones de inicio automático, lo que puede ayudar a prevenir la ejecución de programas desconocidos o no autorizados.

6. Limitar privilegios: Los usuarios deben tener los privilegios mínimos necesarios para ejecutar programas en las ubicaciones de inicio automático. Esto ayuda a limitar el daño potencial si un atacante logra ejecutar un programa malicioso.

Scripts RC (Run Control)

¿Qué son los scripts RC?

Los scripts RC son parte fundamental del sistema de inicio de Linux y se utilizan para configurar y controlar los servicios y procesos que se ejecutan durante el arranque del sistema. Dos de los scripts RC más comunes en sistemas Linux son `rc.local` y los scripts en el directorio `rc.d`. Sin embargo, es importante mencionar que estos scripts pueden variar según la distribución de Linux que estés utilizando, ya que cada distribución puede implementar su propio sistema de inicio.

1. rc.local:

   – El archivo `rc.local` es un script que se utiliza para ejecutar comandos o programas personalizados al inicio del sistema.

   – Se encuentra en `/etc/rc.local` en muchas distribuciones, pero en algunas versiones recientes, como Ubuntu 18.04 y posteriores, este archivo se desaconseja y no se crea por defecto. En su lugar, se sugiere usar systemd para administrar servicios y tareas al inicio.

   – Los comandos o programas que se colocan en `rc.local` se ejecutan con privilegios de superusuario (root) al arrancar el sistema.

2. rc.d:

   – El directorio `rc.d` (que significa Run Control Directory) es un conjunto de directorios y archivos que se utiliza para controlar la secuencia de inicio y apagado de servicios y demonios en sistemas Linux. Los archivos en este directorio suelen ser enlaces simbólicos a scripts de inicio y parada ubicados en otros directorios.

   – El diseño exacto del sistema `rc.d` puede variar según la distribución, pero los directorios y archivos típicos que puedes encontrar en él incluyen `rc0.d`, `rc1.d`, `rc2.d`, …, `rc6.d`, donde cada directorio está asociado a un nivel de ejecución (runlevel) específico.

   – Los niveles de ejecución (runlevels) representan diferentes estados en los que puede estar el sistema, como el modo de usuario único, el modo multiusuario, el modo de rescate, etc.

   – Los scripts dentro de estos directorios se ejecutan automáticamente al cambiar de un nivel de ejecución a otro. Por ejemplo, los scripts en `rc2.d` se ejecutarán cuando el sistema entre en el nivel de ejecución 2.

Es importante destacar que en sistemas Linux modernos, especialmente aquellos que utilizan systemd como sistema de inicio, la gestión de servicios y tareas al inicio se realiza principalmente a través de unidades de systemd en lugar de scripts RC tradicionales. systemd es un sistema de inicio más avanzado y flexible que ha reemplazado en gran medida a los scripts RC en muchas distribuciones.

¿Cómo puede un atacante explotar los scripts RC?

Aquí hay algunas formas en las que un atacante podría intentar explotar los scripts RC:

1. Inyección de comandos maliciosos en rc.local:

   – Si un atacante puede modificar el archivo `rc.local`, podría inyectar comandos maliciosos que se ejecutarán con privilegios de superusuario (root) al iniciar el sistema.

   – Estos comandos podrían utilizarse para crear cuentas de usuario maliciosas, abrir puertas traseras o realizar otras acciones dañinas.

2. Reemplazo de enlaces simbólicos en los directorios rc.d:

   – En algunos sistemas, los servicios se inician mediante enlaces simbólicos en los directorios `rc.d`. Un atacante podría intentar reemplazar estos enlaces con versiones maliciosas que ejecuten código no autorizado al inicio.

   – Esto podría utilizarse para iniciar servicios o aplicaciones maliciosas que comprometan la seguridad del sistema.

3. Manipulación de secuencias de ejecución en rc.d:

   – Si un atacante puede manipular la secuencia en la que se ejecutan los scripts en los directorios `rc.d`, podría intentar alterar la secuencia normal de inicio para ejecutar comandos maliciosos antes o después de lo previsto.

   – Esto podría utilizarse para interferir con el funcionamiento normal del sistema o abrir oportunidades para ataques adicionales.

4. Elevación de privilegios:

   – Si un atacante puede explotar scripts RC para ejecutar comandos con privilegios de superusuario, podría intentar realizar una elevación de privilegios para obtener acceso total al sistema.

   – Esto podría implicar la explotación de vulnerabilidades en el kernel o en otros componentes del sistema para obtener acceso de superusuario.

5. Desactivación de servicios de seguridad:

   – Un atacante podría intentar desactivar servicios de seguridad importantes que se inician durante el arranque, como firewalls o sistemas de detección de intrusiones.

   – Esto abriría el sistema a ataques adicionales.

¿Cómo podemos protegernos?

Para mitigar estos riesgos, es esencial seguir buenas prácticas de seguridad, como:

– Limitar el acceso a los archivos y directorios relacionados con el sistema de inicio.

– No otorgar permisos de escritura innecesarios en los archivos de inicio.

– Mantener el sistema operativo y los servicios actualizados para parchear posibles vulnerabilidades.

– Utilizar herramientas de monitorización y registro de actividad para detectar intentos de explotación.

– Considerar la implementación de sistemas de prevención de intrusiones y cortafuegos para reforzar la seguridad.

– Sustituir RC por servicios generados en Systemd, ya que es un sistema de servicios más moderno y seguro.

El comando Trap

El comando `trap` en Linux se utiliza para establecer acciones personalizadas que deben ejecutarse cuando un proceso recibe una señal específica.

Las señales son mecanismos de comunicación entre procesos y el sistema operativo que permiten a un proceso notificar a otro proceso o a sí mismo sobre eventos o situaciones particulares.

El comando `trap` es especialmente útil para gestionar señales y realizar acciones específicas en respuesta a ellas.

El formato básico del comando `trap` es el siguiente:

trap ‘comando’ señal

Donde:

– `comando` es el comando o conjunto de comandos que deseas ejecutar cuando se reciba la señal especificada.

– `señal` es el nombre de la señal a la que deseas asociar el comando. Algunas señales comunes son `SIGINT` (generada al presionar Ctrl+C en la terminal), `SIGTERM` (señal de terminación), `SIGHUP` (señal de terminal cerrada) y muchas más.

Aquí hay algunos ejemplos de cómo se puede usar `trap`:

1. **Manejo de la señal SIGINT (Ctrl+C)**:  

   trap ‘echo «Se presionó Ctrl+C. No se permite la interrupción.»‘ SIGINT

Este comando evitará que un script se interrumpa cuando se presione Ctrl+C y mostrará un mensaje en su lugar.

2. **Liberación de recursos al finalizar un script**:

   trap ‘limpiar_recursos’ EXIT

En este ejemplo, `limpiar_recursos` es una función que se ejecutará cuando el script termine o se cierre. Esto es útil para liberar recursos o realizar limpieza antes de que el script finalice.

3. **Ignorar una señal**:

   trap » SIGTERM

Este comando evitará que el proceso reaccione a la señal `SIGTERM`, lo que significa que no se terminará si recibe esta señal.

4. **Restaurar la acción predeterminada**:

   trap – SIGINT

Con este comando, se restaura la acción predeterminada (generalmente la terminación del proceso) cuando se recibe la señal `SIGINT`.

Mecanismos de defensa ante un ataque malicioso

Para evitar que un atacante utilice señales o el comando `trap` para tomar el control del sistema, es importante implementar buenas prácticas de seguridad. A continuación, algunas recomendaciones:

1. Limita los privilegios de los usuarios: No ejecutar aplicaciones o procesos con privilegios elevados a menos que sea necesario. Utilizar cuentas de usuario con permisos mínimos para tareas normales y, sólo cuando sea necesario, cambiar a una cuenta con privilegios administrativos.

2. Utilizar medidas de autenticación fuertes: Refuerza la autenticación en tu sistema mediante contraseñas seguras, autenticación de dos factores (2FA) y, si es posible, autenticación de tarjeta inteligente o biométrica.

3. Controlar el acceso remoto: Utilizar métodos seguros como SSH (Secure Shell) en lugar de protocolos más antiguos y menos seguros. Configurar el acceso remoto para utilizar autenticación segura y asegúrarse de que las contraseñas sean fuertes.

4. Monitorizar y auditar: Implementar herramientas de monitoreo y auditoría para rastrear el comportamiento del sistema y detectar actividad sospechosa. Esto te ayudará a identificar rápidamente cualquier intento de explotación.

5. Firewalls y control de puertos: Utilizar firewalls para controlar el tráfico de red y limitar el acceso a los puertos solo a los servicios necesarios. Cerrar o bloquear puertos innecesarios para minimizar la superficie de ataque.

6. Actualizaciones de seguridad: Mantener el sistema y todas las aplicaciones actualizadas con las últimas correcciones de seguridad. Las vulnerabilidades conocidas son a menudo explotadas por atacantes.

7. Configurar `trap` con precaución: Evitar permitir que los usuarios no confiables definan trampas (traps) y señales personalizadas. Limitar su uso solo a scripts y procesos confiables.

Módulos del kernel

¿Qué son los módulos del kernel LKM?

Los módulos del kernel, conocidos como Loadable Kernel Modules (LKM), son una característica importante en muchos sistemas operativos basados en el kernel de Linux, incluido el propio kernel de Linux.

Estos módulos permiten la carga y descarga dinámica de código en el kernel del sistema operativo sin necesidad de reiniciar el sistema completo:

1. Carga y descarga dinámica: Los LKM permiten agregar funcionalidad al kernel de Linux sin tener que recompilar ni reiniciar el kernel ni el sistema completo. Esto facilita la incorporación de nuevos controladores de dispositivos, sistemas de archivos, protocolos de red y otras características al sistema operativo en tiempo de ejecución.

2. Aislamiento y seguridad: Los módulos del kernel se ejecutan en el” espacio del kernel”, lo que significa que tienen acceso completo a los recursos y funciones del kernel. Sin embargo, debido a su capacidad para cargar y descargar dinámicamente, los errores en los módulos pueden ser menos destructivos que los errores en el kernel principal. Además, los LKM pueden estar sujetos a políticas de seguridad y mecanismos de aislamiento para limitar su acceso y garantizar la estabilidad del sistema.

3. Ejemplos de uso: Los LKM se utilizan para una variedad de propósitos, incluyendo la adición de controladores de dispositivos para hardware específico, la implementación de sistemas de archivos adicionales, la adición de características de seguridad, la creación de módulos de cifrado, la implementación de protocolos de red personalizados y mucho más. Los módulos se pueden cargar o descargar según sea necesario, lo que ayuda a mantener el núcleo lo más pequeño y eficiente posible.

4. Herramientas de gestión: El sistema operativo Linux proporciona herramientas como `insmod`, `rmmod` y `lsmod` para cargar, descargar y listar módulos del kernel. Los módulos se suelen almacenar en el directorio `/lib/modules/<versión_del_kernel>/kernel/` y tienen la extensión `.ko` (Kernel Object).

¿Cómo puede un atacante utilizar los módulos del kernel?

A continuación, se presentan algunos escenarios de cómo un atacante podría aprovechar los LKM y algunas estrategias para defenderse:

1. Rootkit: Los atacantes pueden cargar módulos del kernel que actúen como rootkits, ocultando actividades maliciosas en el sistema. Estos rootkits pueden ocultar procesos, archivos y conexiones de red, dificultando la detección de actividades maliciosas.

2. Explotación de vulnerabilidades: Si un atacante encuentra una vulnerabilidad en un controlador de dispositivo o en un módulo del kernel, podría cargar un módulo malicioso para aprovechar esa vulnerabilidad y obtener acceso privilegiado al sistema.

3. Creación de puertas traseras: Un atacante podría desarrollar un módulo del kernel malicioso que le otorgue acceso persistente al sistema, incluso después de un reinicio. Esto se utiliza comúnmente para mantener el acceso no autorizado al sistema.

4. Intercepción de tráfico de red: Los módulos del kernel también se pueden utilizar para interceptar y manipular el tráfico de red, lo que podría permitir ataques de escucha, redirección o suplantación de identidad.

¿Cómo defendernos contra el abuso de los módulos del kernel?

1. Principio de menor privilegio: Limitar el acceso y los privilegios otorgados a los usuarios y procesos en el sistema. Esto reduce la superficie de ataque y hace que sea más difícil para los atacantes cargar módulos maliciosos.

2. Actualizaciones y parches: Manter el kernel y los controladores de dispositivos actualizados con las últimas correcciones de seguridad. Las vulnerabilidades conocidas son un vector común de ataque.

3. Monitorización y auditoría: Implementar sistemas de monitoreo y auditoría que puedan detectar actividades inusuales en el sistema, como la carga de módulos del kernel no autorizados o la modificación de archivos del sistema.

4. Firmas digitales: Firmar digitalmente los módulos del kernel para garantizar su integridad y autenticidad. Esto dificultará la carga de módulos maliciosos que no estén firmados correctamente.

5. Políticas de seguridad estrictas: Establecer políticas de seguridad que restrinjan la capacidad de cargar módulos del kernel solo a usuarios y procesos autorizados.

6. Control de acceso físico: Limitar el acceso físico a sistemas críticos, ya que el acceso físico al hardware puede facilitar la manipulación de módulos del kernel.

7. Auditoría de código y revisión de parches: Realizar auditorías de seguridad y revisiones de código en los módulos del kernel y en las contribuciones a la comunidad para detectar posibles problemas de seguridad.

¿Cómo se firma, digitalmente, un módulo del kernel?

Para firmar digitalmente un módulo del kernel, generalmente se siguen estos pasos:

1. Genera un par de claves: Debes generar un par de claves criptográficas: una clave privada y una clave pública. La clave privada se mantendrá en secreto, mientras que la clave pública se utilizará para verificar la autenticidad de los módulos firmados.

2. Crea un certificado: Utiliza la clave privada para generar un certificado X.509, que incluirá la clave pública y otra información relevante, como el nombre del emisor, la fecha de vencimiento, etc. Puedes utilizar herramientas como OpenSSL para crear el certificado.

3. Firma el módulo: Utiliza la clave privada para firmar digitalmente el módulo del kernel que deseas cargar. La mayoría de las distribuciones de Linux proporcionan una herramienta llamada `sign-file` que simplifica este proceso. Por ejemplo, en sistemas basados en Debian, puedes usar el comando `sign-file` de la siguiente manera:

   sign-file sha256 <ruta_de_la_clave_privada> <ruta_del_certificado> <ruta_del_módulo>

4. Copia el certificado: Asegúrate de que el certificado se encuentre en un lugar accesible por el sistema al cargar el módulo. Por lo general, esto implica copiar el certificado (archivo `.cert`) a un directorio específico en `/lib/modules/<versión_del_kernel>/kernel/`.

5. Carga el módulo firmado: Ahora puedes cargar el módulo firmado en el kernel. El sistema verificará automáticamente la firma digital del módulo utilizando la clave pública contenida en el certificado. Si la verificación es exitosa, se permitirá la carga del módulo.

6. Configuración de UEFI/Secure Boot (opcional): Si estás utilizando un sistema con UEFI y Secure Boot habilitado, es posible que debas asegurarte de que tu certificado y clave pública estén registrados en el sistema UEFI. Esto garantiza que solo se carguen módulos firmados digitalmente en el kernel durante el proceso de inicio.

Servicios de Linux con Systemd

Para este punto, puedes revisar el artículo Systemd/Systemctl – Configuración de Servicios en RedHat donde hablo sobre su funcionamiento y medidas de seguridad a tener en cuenta.

Entradas en cron

El cron de Linux es un servicio que sirve para programar tareas en el sistema. Tienes más información en artículo Comandos básicos de Linux relacionados con los procesos.

¿Cómo podemos evitar un ataque malicioso a través de cron?

Para evitar un ataque malicioso a través de la configuración de cron en un sistema Linux, es importante seguir buenas prácticas de seguridad y considerar las siguientes recomendaciones:

1. Mínimo privilegio: Asegúrarse de que las tareas programadas a través de cron tengan los permisos mínimos necesarios para funcionar correctamente. No debemos conceder más privilegios de los necesarios para ejecutar la tarea.

2. Usuarios privilegiados: Limitar el acceso a la configuración de cron. Solo los usuarios autorizados deben poder modificar los archivos crontab. Los ficheros `cron.allow` y `cron.deny` para controlar quién tiene acceso. Estos ficheros están en /etc.

3. Archivos crontab seguros: Asegurarse de que los archivos crontab no sean editables por usuarios no autorizados. Estos archivos suelen ubicarse en directorios como `/var/spool/cron/crontabs/` o `/etc/cron.d/`. Restringiremos los permisos de estos directorios para evitar modificaciones no autorizadas.

4. Validación de rutas: Verificar que las rutas a los scripts o comandos que se ejecutan en las tareas cron sean correctas y seguras. Evitar usar rutas relativas. Esto evita que un atacante cambie la ruta para ejecutar un comando malicioso.

5. Registro de actividades: Habilitar el registro de todas las actividades de cron. Esto te permitirá monitorear cualquier actividad inusual o intentos de ataque.

6. Escaneo de malware y antivirus: Utilizar herramientas de escaneo de malware y antivirus para verificar regularmente los archivos y scripts ejecutados a través de cron.

7. Auditoría y revisión regular: Realizar auditorías y revisiones periódicas de las tareas programadas en cron para asegurarse de que no haya cambios maliciosos en las configuraciones.

Comando «at»

El comando «at» es una utilidad de línea de comandos en sistemas operativos basados en Linux y Unix que se utiliza para programar la ejecución de tareas o comandos en un momento específico en el futuro.

Con «at», podemos especificar cuándo deseamos que se ejecute un comando, y el sistema lo ejecutará en ese momento programado.

Puede ser útil para automatizar tareas que deben realizarse en momentos específicos o para ejecutar comandos en horarios programados.

El comando «at» se utiliza de la siguiente manera:

1. Escribe «at» seguido de la hora y la fecha en la que deseas que se ejecute el comando. Por ejemplo:

   at 15:30

2. Luego, el sistema te permitirá ingresar el comando que queremos ejecutar una vez que llegue el momento especificado. Después de ingresar el comando, presionamos «Ctrl+D» para guardar y programar la tarea.

3. La tarea se programará y se ejecutará en el momento especificado.

Por ejemplo, si queremos que un script llamado «mi_script.sh» se ejecute a las 15:30, lo haremos de la siguiente manera:

«`bash

at 15:30

./mi_script.sh

Ctrl+D

«`

Para poder utilizar el comando «at», el servicio «atd» tiene que estar arrancado y, además, es posible que necesitemos los permisos adecuados para programar tareas con “at”.

Medidas de precaución

1. Restringir el acceso a «at»: Limitar quién puede utilizar el comando «at» en el sistema. Podemos hacerlo configurando el archivo «/etc/at.deny» para denegar el acceso a usuarios no autorizados y asegurándonos de que sólo los usuarios de confianza tengan acceso a «at».
2. No usar “at”. Podemos utilizar cron o Systemd timers para programar tareas y dejar parado el servicio atd.

David Martínez Perales

Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.

Más sobre mí en el este enlace,