Como administrador de sistemas, es posible que ya haya experimentado la alegría (?) de que un profesional de seguridad o gestión de riesgos audite sus sistemas. Las herramientas de seguridad utilizadas por los auditores generalmente escanean los sistemas y producen un informe para el auditor que destaca las vulnerabilidades encontradas en el sistema escaneado, que luego el auditor presenta al equipo que administra los sistemas. La expectativa es que el equipo de administración y gestión resuelva las vulnerabilidades reportadas. Sin embargo, para las distribuciones empresariales de Linux, las soluciones recomendadas por el auditor pueden no ser la mejor opción para que las aplique la organización.
Obteniendo la información
Comenzando con un ejemplo, muchas de estas herramientas de auditoría comienzan escaneando puertos de un sistema de destino y conectándose a puertos abiertos para recopilar datos sobre los servicios que ofrece la máquina. Aquí hay un escaneo de puerto de ejemplo de mi propio sistema, generado por nmap comando:
[root@somebox ~]# nmap 10.200.157.174
Starting Nmap 6.40 ( http://nmap.org ) at 2020-01-29 13:40 CET
Nmap scan report for 10.200.157.174
Host is up (0.000010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds
A partir de este resultado, puede ver que los puertos 22, 80 y 111 están disponibles para los servicios que se conectan a este sistema. Es probable que una herramienta de auditoría de seguridad se conecte a cada uno de estos puertos para determinar qué se está ejecutando en ellos, o podría usar una utilidad de creación de perfiles para recopilar y analizar estos datos. Usaré el telnet comando para conectarse al puerto 80 de esta máquina para determinar qué se está ejecutando allí:
[root@somebox ~]# telnet 10.200.157.174 80
Trying 10.200.157.174...
Connected to 10.200.157.174.
Escape character is '^]'.
help
HTTP/1.1 400 Bad Request
Date: Wed, 29 Jan 2020 12:46:39 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
Connection closed by foreign host.
Después de establecer la conexión, tuve que hacer una solicitud del servicio. En este caso, escribí la palabra "ayuda" que, según el servicio, podría ser un comando. Sin embargo, para el servicio que se ejecuta en el puerto 80 de este sistema, la ayuda no es un comando entendido. Como resultado, se produce un error. En el encabezado, puede ver una buena cantidad de información sobre el sistema y el servicio. Específicamente, el servicio en este puerto es Apache versión 2.4.6.
Efectivamente, si verifico esta información mirando una yum list , Apache versión 2.4.6 es la versión instalada y ejecutándose en la máquina:
[root@somebox ~]# yum list httpd
… output truncated…
Installed Packages
httpd.x86_64 2.4.6-89.el7_6.1 @rhel-x86_64-workstation-7.6
Manejo del informe del auditor
Aquí es donde las cosas empiezan a ponerse interesantes. En mi experiencia, lo que sucede es que el informe de auditoría aterriza en el escritorio y dice algo como:
Se detectó una versión antigua de Apache (2.4.6) que tiene varias vulnerabilidades que se han cerrado en las versiones más nuevas de Apache.
Recomendación:Instale la versión actualizada de Apache, 2.4.41, la más reciente.
En este punto, como implementación empresarial de Linux, debe detenerse. Comprenda que el informe del auditor destaca que, de acuerdo con la información de escaneo del sistema, este sistema puede tener vulnerabilidades abiertas. El informe del auditor es correcto en cuanto a que instalar la versión más reciente de Apache de apache.org resolvería ese problema. Sin embargo, como sistema Linux empresarial, es probable que estas vulnerabilidades potenciales ya estén cerradas en la versión de Apache implementada actualmente en el sistema.
Tenga en cuenta que la versión del sistema es 2.4.6-89.el7_6.1, donde 2.4.6 es el número de versión real y el número de versión adicional para este paquete es 89.el7_6.1. Las distribuciones Enterprise Linux a menudo corrigen los problemas de las versiones más recientes y retroportan esas correcciones a una base de código anterior, luego compilan una versión actualizada de este paquete de software anterior. Para Red Hat Enterprise Linux, el sistema operativo en mi sistema de ejemplo, los ingenieros que administran el paquete Apache rastrean estos cambios aplicados a través de este número de versión adicional en el paquete rpm.
Algunos auditores ya saben sobre esto, y algunas herramientas también dan cuenta de este tipo de gestión de software. A veces, sin embargo, trabajará con alguien que utiliza una herramienta de escaneo menos sofisticada. No solo eso, esta persona también podría no saber que la versión anterior de Apache en este sistema es la correcta versión instalada en esta máquina, y que las vulnerabilidades de seguridad que preocuparían a la gente de seguridad o administración de riesgos ya están cerradas. Y como administrador del sistema, a menudo le corresponde a usted explicar por qué su organización no debe instalar la versión más actualizada de este paquete, en contra de la recomendación del auditor.
En mi experiencia, una de las mejores maneras de ilustrar este punto es mirar los datos adicionales incluidos con la versión de Linux empresarial de este paquete de software. Muchas distribuciones empresariales de Linux utilizarán funciones como el registro de cambios de RPM para resaltar estos datos. Aquí está la información de mi sistema de ejemplo:
[root@somebox ~]# rpm -q httpd --changelog
* Tue Jun 25 2019 Lubos Uhliarik <> - 2.4.6-89.1
- Resolves: #1719722 - CVE-2018-1312 httpd: Weak Digest auth
nonce generation in mod_auth_digest
… output truncated …
De acuerdo con el aviso de CVE vinculado anteriormente, esta vulnerabilidad no se solucionó en Apache hasta después del 2.4.29. Sin embargo, puede ver en el resultado del registro de cambios de este paquete que se ha actualizado y aplicado una corrección para CVE-2018-1312 al código base instalado actualmente, que se basa en Apache 2.4.6. Este hecho significa que mi sistema de ejemplo no es vulnerable a este exploit, a pesar de ser una versión anterior del software Apache.
¿Por qué es todo esto importante? Probablemente, si está utilizando una distribución empresarial de Linux, lo está haciendo porque desea mantener al mínimo los cambios, los posibles conflictos y otros problemas de desajuste de software. Actualizar Apache, como lo indica la recomendación de auditoría, sería contrario al objetivo de mantener los cambios al mínimo. Si es un cliente con soporte comercial, es probable que su proveedor ya no admita problemas relacionados con Apache en esta máquina si cambia a una versión que no se envía con su distribución.
Resumiendo
Para sobrevivir a un informe de auditoría, como el ejemplo anterior, debe trabajar con el auditor para asegurarse de que comprenda cómo se mantienen los paquetes empresariales de Linux (que la versión que se muestra en el puerto puede no ser la misma que la versión instalada en el sistema) , y que el empaquetador de Linux empresarial generalmente mantiene versiones anteriores de estos paquetes para tener en cuenta las vulnerabilidades que un auditor, un profesional de seguridad informática o un asociado de administración de riesgos pueden encontrar. El uso de datos como la información del registro de cambios puede ayudar a demostrar este concepto de backporting y administración de paquetes empresariales de Linux.
¿Quiere probar Red Hat Enterprise Linux? Descárguelo ahora gratis.