¿Cómo sé que 2ubuntu3.9 tiene los últimos parches de seguridad?
Esto no es un simple. No todas las vulnerabilidades enumeradas en la página de seguridad de Apache son relevantes para la versión que se incluye con Ubuntu. Ubuntu distribuye la versión 2.4.18 con parches backported que consideran relevantes.
El punto de partida para ver lo que está arreglado sería el Changelog y compárelo con la lista de errores publicados por Apache.
Pero, no se encuentra un CVE en el Registro de cambios no significa que la versión enviada sea vulnerable contra esto. Por ejemplo, CVE-2018-8011 es que se considera que solo afecta a Apache 2.4.33 y no la versión 2.4.18 enviada con xenial . Similar a la información en CVE-2018-1333 y CVE-2018-11763 dicen que el código específico donde no se incluye la vulnerabilidad en la versión incluida con xenial ( "no afectado (código no creado)" ).
Por lo tanto, para saber si una vulnerabilidad específica sigue siendo un problema con la versión enviada, debe buscar en el Registro de cambios y si no encuentra el CVE, debe verificar por qué no se reparó, es decir porque no afectó a la versión como fue enviada.
¿Cómo puedo saber si mi versión de Ubuntu Apache es segura?
La idea básica de esta pregunta es un poco incorrecta. Que algún software no sea vulnerable a un CVE conocido no significa que sea seguro. Si se descubren nuevas vulnerabilidades, el software no se vuelve mágicamente inseguro hasta que se arregla el CVE: antes era inseguro, pero los problemas recién detectados aún no se conocen ampliamente.
Hay varios factores a considerar para determinar si un software es lo suficientemente seguro para un propósito específico. Uno es probablemente el historial del software: el software que se usa ampliamente pero que solo tuvo problemas de baja gravedad en el pasado es probablemente más confiable en comparación con el software que tuvo muchos problemas serios en el pasado, aunque todos los problemas conocidos parecen solucionarse saber. Por ejemplo, definitivamente no confiaría en Flash incluso después del último parche de seguridad, pero solo espero que el próximo problema aparezca en unas pocas semanas (generalmente lo hace) y que los atacantes conozcan y ya usen problemas que aún no se han publicado.
Para mantener el riesgo bajo (y administrado) también es relevante el impacto que los problemas de seguridad en el software podrían causar. Limitar el impacto potencial al usar el software solo para cosas poco importantes puede limitar el riesgo, al igual que mitigar los problemas potenciales al ejecutar el software con bajos privilegios, monitorear actividades sospechosas, etc.