Ideas y métodos para la recuperación de emergencia y la resolución de problemas de fallas de SELinux en EC2

Descripción general

SELinux, el nombre completo de Security-Enhanced Linux, es un módulo de seguridad que proporciona un mecanismo de control de acceso obligatorio para el sistema. El sistema operativo que instala y habilita el módulo SELinux marcará una marca de seguridad especial para cada proceso y recurso del sistema, llamada el contexto SELinux y Permitir o denegar el acceso según la información del contexto SELinux.

La comunidad de desarrolladores de tecnología en la nube de Amazon proporciona a los desarrolladores recursos tecnológicos de desarrollo global. Hay documentos técnicos, casos de desarrollo, columnas técnicas, vídeos de formación, actividades y concursos, etc. Ayude a los desarrolladores chinos a conectarse con las tecnologías, ideas y proyectos más avanzados del mundo, y recomiende desarrolladores o tecnologías chinos destacados a la comunidad global de la nube. Si aún no lo has seguido/recopilado, no te apresures a leerlo cuando lo veas. ¡ Haz clic aquí para convertirlo en tu tesoro técnico!

De acuerdo con los requisitos básicos de protección del nivel de seguridad de la red nacional, el sistema de tercer nivel "debe establecer marcas de seguridad para sujetos y objetos importantes y controlar el acceso del sujeto a los recursos de información con marcas de seguridad" en el nivel de un entorno informático seguro, de modo que debe pasar la evaluación de nivel tres de seguridad nacional. Todos los sistemas deben habilitar SELinux en el sistema.

Nota: La imagen oficial del sistema de Amazon, Amazon Linux 2022, tiene SELinux habilitado con la política Enforcing de forma predeterminada.

A medida que la aplicación de SELinux se generaliza cada vez más, también aumentan los fallos del sistema causados por configuraciones inadecuadas de SELinux. En casos graves, es posible que el sistema no se inicie. y Ideas para solucionar problemas en AWS.

Dos métodos para la recuperación de emergencia de EC2

Acceso a la consola serie EC2

Si el host defectuoso cumple con los requisitos previos para el acceso a la consola en serie y el acceso a la consola en serie está habilitado, puede usar directamente el acceso a la consola en serie EC2 para recuperación de emergencia y solución de problemas. La consola en serie no requiere que su instancia EC2 tenga ninguna capacidad de red. Usando una consola serie, puede ingresar comandos en su instancia como si su teclado y monitor estuvieran conectados directamente al puerto serie de la instancia. Las sesiones de la consola serie persisten tras los reinicios y paradas de la instancia. Durante el reinicio, puede ver todos los mensajes de inicio desde el principio. La consola serie no está habilitada de forma predeterminada y requiere autorización explícita antes de poder usarse. El método específico es el siguiente:

1. Otorgue permiso a la cuenta para ejecutar la consola serie. La política de IAM recomendada es la siguiente:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:GetSerialConsoleAccessStatus",
                "ec2:EnableSerialConsoleAccess",
                "ec2:DisableSerialConsoleAccess"
            ],
            "Resource": "*"
        }
    ]
}

Después de configurar esta política, la cuenta podrá ver la opción "Acceso a la consola serie EC2" cuando se conecte a la instancia EC2. El valor predeterminado inicial es "Prohibido". Debe hacer clic en "Administrar" y configurarlo en "Permitir". Una vez completado, la cuenta estará disponible. El acceso a la consola serie EC2 estará disponible.

2. Antes de iniciar sesión en el servidor EC2 a través de la consola serie, también necesitamos establecer un usuario y contraseña para EC2 que permita iniciar sesión con una contraseña en la consola serie. Utilice el método SSH predeterminado para iniciar sesión de forma remota en el servidor EC2. Después de iniciar sesión, utilice passwd para establecer la contraseña. A continuación se utiliza root como ejemplo:

[ec2-user ~]$ sudo passwd root

3. Deshabilite SELinux para recuperación de emergencia. Para fallas del sistema causadas por SELinux, primero podemos deshabilitar SELinux para recuperación de emergencia y solución de problemas. Después de iniciar sesión en el servidor a través de la consola serie, modifique directamente /etc/selinux/config y configure SELINUX=disabled, y luego reinicie el servidor para que surta efecto.

Ejemplo de rescate

Para los servidores que no admiten el acceso a la consola en serie, o que lo admiten pero no estaban habilitados anteriormente, también podemos usar instancias de rescate para realizar una recuperación de emergencia en hosts fallidos de SELinux. La operación específica es la siguiente:

Lance una nueva instancia de Amazon EC2 en una nube privada virtual (VPC) utilizando la misma imagen de máquina de Amazon (AMI) que la instancia comprometida y en la misma zona de disponibilidad. La nueva instancia se convertirá en su instancia de "rescate". Alternativamente, puede usar una instancia existente a la que tenga acceso, pero solo si usa la misma AMI que la instancia comprometida y está en la misma zona de disponibilidad.
Separe el volumen raíz de Amazon Elastic Block Store (Amazon EBS) (/dev/xvda o /dev/sda1) de la instancia comprometida . Tome nota del nombre del dispositivo para asegurarse de que sea el mismo cuando se vuelva a conectar más tarde.
Adjunte el volumen de EBS como dispositivo secundario (/dev/sdf) a la instancia de rescate.
Utilice SSH para conectarse a su instancia de rescate.
Conviértase en root, use lsblk para identificar el nombre correcto del dispositivo y guárdelo para usarlo durante todo el proceso:

$ sudo -i
# lsblk
# rescuedev=/dev/xvdf1

NOTA : El dispositivo (/dev/xvdf1) puede estar conectado a la instancia de rescate con un nombre de dispositivo diferente. Utilice el comando lsblk para ver los dispositivos de disco disponibles y sus puntos de montaje para determinar el nombre de dispositivo correcto.

6. Seleccione el punto de montaje temporal apropiado para usar y asegúrese de que exista; use /mnt a menos que el punto de montaje ya esté en uso.

# rescuemnt=/mnt
# mkdir -p $rescuemnt

7. Monte el sistema de archivos raíz desde el volumen adjunto:

# mount $rescuedev $rescuemnt

Nota : Si falla el montaje del volumen, verifique dmesg|tail. Si el registro muestra conflictos de UUID, utilice la opción -o nouuid.

8. Modifique el archivo de configuración de SELinux

# cd /mnt/rescuemnt
# vi ./etc/selinux/config

9. Una vez completado, desinstale el dispositivo auxiliar:

# exit
# umount $rescuemnt

10. Separe el volumen secundario (/dev/sdf) de la instancia EC2 de rescate y conéctelo a la instancia original como /dev/xvda o /dev/sda1 (volumen raíz). Asegúrese de que esto sea lo mismo que se ve en el paso 2. / 11. Inicie la instancia EC2 y luego verifique si la instancia se reinicia normalmente.

Análisis de registros de SELinux

Una vez restaurado el sistema, nuestro primer paso es analizar el registro de interceptación de SELinux y analizar qué procesos interceptados por SELinux causaron la excepción del sistema. Por defecto, los registros de interceptación de SELinux se registran en los archivos /var/log/audit/audit.log y /var/log/messages . Tanto para auditoría como para mensajes, podemos acceder a ellos a través de la palabra clave "AVC" (Access Vector Cache) caché vectorial) que filtra los registros interceptados por SELinux, aquí están los registros de denegación de AVC (y las llamadas al sistema asociadas) de ejemplo (para conocer el significado específico del formato de registro, consulte el enlace oficial de RedHat ):

type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" 
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file 

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" 
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Al analizar el registro de interceptación de SELinux, se puede identificar la información del proceso y del archivo de ruta interceptados por SELinux cuando ocurre la falla.

Nota: Si el proceso anormal interceptado no se puede identificar visualmente mediante el análisis del registro, dado que tanto la auditoría como el mensaje tienen funciones de archivo de forma predeterminada, también puede comparar y analizar el registro de interceptación en el momento de la falla con el registro de interceptación en el período de tiempo normal. para identificar el momento en que ocurrió la falla Procesos interceptados adicionales.

Restablecimiento de etiqueta de contexto de proceso

Hay dos formas de analizar etiquetas de contexto: una es analizar directamente los campos de contexto del sujeto y el objeto en el registro de interceptación, incluido el análisis de usuarios, roles, tipos y niveles de SELinux. Este análisis requiere que los administradores tengan un conocimiento muy profundo de SELinux Comprenda que los requisitos son altos.

Como método de solución de problemas simple pero más práctico, para sistemas que solo habilitan la política SELinux predeterminada, podemos usar el servicio rhel-autorelabel para restaurar y restablecer la etiqueta de contexto del proceso del sistema y luego comparar los atributos de la etiqueta del archivo antes y después del reinicio. Identificar excepción en la etiqueta de contexto del proceso.

Para los atributos de etiqueta de archivo, tenemos dos métodos de comparación: uno es la comparación manual. Podemos usar el comando del sistema "ls -z file" para ver y registrar el valor de la etiqueta de contexto del archivo antes y después del reinicio. Este método de comparación es adecuado para comparar una pequeña cantidad de archivos; el otro es instalar la herramienta de verificación de integridad de archivos AIDE en el sistema, agregar los archivos que deben compararse al archivo aide.conf y realizar la comparación automáticamente. El modo de utilizar AIDE es el siguiente:

cp /etc/aide.conf /etc/aide.conf_bak（可选，备份原始conf文件）
vi /etc/aide.conf (可选，在默认的基础上增加需要对比的文件，来源可以是日志分析识别到的一个或多个异常进程)
aide --init 
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
aide --check

El comando de operación para habilitar el servicio rhel-autorelabel es el siguiente:

systemctl enable rhel-autorelabel
touch /.autorelabel
reboot
#系统重启后，将会对文件重打SELinux上下文标签

Verificación de causa de falla

Después de identificar la causa específica de la falla de la etiqueta mediante el restablecimiento de la etiqueta y el análisis comparativo, podemos probar el comando del sistema chcon para modificar la etiqueta de contexto del proceso anormal a un valor correcto o incorrecto, verificar si la anomalía desaparece o reaparece y así determinar la causa del fallo causa raíz.

Resumir

Este artículo se centra en la "falla de etiqueta", una fuente común de fallas de SELinux, y analiza las ideas y métodos del análisis de fallas de SELinux. Sin embargo, en el entorno real, hay muchas razones para las fallas del sistema, e incluso las fallas de SELinux todavía tienen muchas posibilidades. , por lo que es necesario consultar los archivos de registro del sistema y los documentos oficiales se analizan en detalle.

El autor de este artículo.

Wang Jun Feng

El consultor de seguridad del equipo de servicios profesionales de tecnología en la nube de Amazon es responsable de la consultoría, el diseño y la implementación del cumplimiento de la seguridad en la nube, soluciones de seguridad en la nube, etc., y se compromete a brindar las mejores prácticas de seguridad para que los clientes migren a la nube y resuelvan las necesidades de seguridad de los clientes al migrar a la nube.

Fuente del artículo: https://dev.amazoncloud.cn/column/article/63186bc260678178b03b8104?sc_medium=regulartraffic&sc_campaign=crossplatform&sc_channel=CSDN