¿Cómo demuestro OpenSSH redhat / centos patchlevel a los auditores?

Question

¿Cómo demuestro OpenSSH redhat / centos patchlevel a los auditores?

#1 de Robert Mennell (1 votos)
#2 de munkeyoto (0 votos)
#3 de jas- (0 votos)

3

Un problema común es que Redhat backports security corrige dejando a OpenSSH con una versión antigua, pero no vulnerable, de rpm y ssh versión cadena en Redhat y CentOS. Esto engaña a los auditores.

Aparentemente, la solución es proporcionar las SA de Redhat al auditor. ¿Pero cuáles? ¿Cómo exactamente hago esto? ¿Necesito compilar un SA para cada vulnerabilidad?

(Lo que estoy intentando en este momento es actualizarme a las rpm más recientes que figuran en una SA, y luego proporcionar las SA más recientes debe demostrar la solución del paquete más reciente).

audit centos

pregunta DigitalRoss 21.04.2016 - 00:49

fuente

3 respuestas

Lea otras preguntas en las etiquetas audit centos

Nginx reenviando hosts no deseados a Django ¿Por qué gethosbyname () es tan malo como get () por diseño?

score 1 · Answer 1

Proporcionar el SA y la versión debería ser lo suficientemente bueno ya que se ha implementado el parche SSH. Si tienen problemas con esto, tendrían que asumirlo con el control de versión de Redhat.

Después de todo, si puedes demostrar que el ataque no funcionará porque ha sido parchado, el número de versión no significa nada. Ya está parcheado, independientemente de lo que diga la versión.

score 0 · Answer 2

Lo que debe abordar es el problema, y si el problema se soluciona o no, o si existe un control de compensación para solucionar la vulnerabilidad. Si no hay un parche para una vulnerabilidad, estaría fuera de cumplimiento; sin embargo, si tuviera reglas que ilustraran que había bloqueado todo, pero que solo permitiera la confianza (fuentes verificadas), ahora tiene un control de compensación. Entonces, mientras confía en Redhat para emitir una actualización, dependiendo de cuál sea el problema con SSH, puede crear reglas en hosts.deny o reglas de firewall para minimizar el riesgo. Todo depende de su enfoque. No hay una respuesta definitiva. Proporcionar a Redhat SA hace poco ya que podrían venir de cualquier lugar (cualquier sistema, incluso una copia de pastebin). Mostrar lo que hizo para minimizar el riesgo / impacto debería ser suficiente para los auditores en caso de que no haya un parche disponible.

score 0 · Answer 3

Redhat proporciona el CVE necesario para empaquetar la información de la versión.

Para cualquier CVE proporcionado, la versión del paquete puede (y como he encontrado en mi propia experiencia) puede no corresponder a la versión original del paquete. La fuente de ejemplo del desarrollador para el paquete ABC es v0.0.3, que trata el CVE 1.1 donde RedHats RPM de ABC está en v0.0.2x para la versión 6 y en v0.0.3 para la versión 7.

El problema real con una auditoría de este tipo requeriría un poco de trabajo extra para garantizar la conformidad debido a la necesidad de refinar la versión de RPM con la versión de los proveedores y las notas de seguridad.

El método más sencillo IMHO sería verificar el RPMS para el paquete afectado, hacer una referencia cruzada con el código del paquete original que trata el CVE y asegurarse de que existe en el RPMS.