El servidor Proxy Squid es vulnerable a un ataque de denegación de servicio al manejar conexiones SSL/TLS

Escrito por Sergio De Luz

Squid es uno de los servidores Proxy más conocidos y utilizados en todo el mundo, su principal característica es que proporciona un muy buen rendimiento y es muy configurable, pudiendo modificar en detalle el comportamiento en una red local para que sus usuarios salgan a Internet a través de este Proxy. Ahora se ha descubierto que algunas versiones son vulnerables a una denegación de servicio al manejar conexiones SSL/TLS, a continuación os contamos todos los detalles.

La denegación de servicio que se puede realizar al servidor Proxy Squid es porque maneja incorrectamente las peticiones SSL/TLS a otros servidores externos. Un cliente de confianza (alguien que está en la parte de la intranet) podría provocar este error aunque el servicio TLS o SSL no estuviera configurado en el propio servidor proxy. Tanto el software del cliente (por ejemplo un navegador web) como un servidor web remoto o local mal configurado, podría desencadenar este problema y llevar a cabo una denegación de servicio sin quererlo.

Mitigación de este fallo en las versiones afectadas

Aunque una gran cantidad de versiones Squid no son vulnerables a este fallo de seguridad, hay algunas que sí lo son, pero se pueden tomar ciertas medidas para mitigar la denegación de servicio.

La primera medida es deshabilitar por completo el protocolo https, de esta forma al no poder conectarse un cliente a una web que utilice este protocolo, no tendremos el problema anteriormente mencionado. Para configurarlo simplemente abrimos el archivo de configuración squid.conf en la parte de http_access e incorporamos las siguientes reglas:

acl HTTPS proto HTTPS
http_access deny HTTPS

La segunda medida es la de retransmitir el tráfico HTTPS a través de un servidor Proxy no vulnerable, de esta manera todas las peticiones se podrán realizar sin tener el problema de seguridad. Es importante destacar que este método no funcionaría si tenemos activado SSL-bump.

La tercera medida que podemos tomar es la de bloquear todos los puertos de las conexiones HTTPS menos el 443 (el típico para este tipo de conexiones), de esta forma evitaremos ataques simples que podrían provocar el fallo del servicio. Para poder incorporar esta medida de mitigación deberemos configurar lo siguiente:

 

acl</span> <span class="hps">HTTPS</span> <span class="hps">proto</span> <span class="hps">HTTPS</span>
<span class="hps">http_acces</span> <span class="hps">niegan</span> <span class="hps">HTTPS</span>! <span class="hps">SSL_ports

 

Versiones de Squid afectadas por el fallo de seguridad

Las versiones de Squid afectadas por este fallo de seguridad son la 3.5.13, y las versiones 4.0.4 y 4.0.5. El resto de versiones no son vulnerables, además si a estas versiones a la hora de compilar el proxy se ha decidido no utilizar la librería OpenSSL, tampoco seríamos vulnerables.

Nueva versión de Squid y el parche que lo soluciona ya está disponible

Las nuevas versiones de Squid que solucionan este problema de seguridad son las Squid 4.0.6 y 3.5.14, podremos actualizar el Proxy desde los repositorios oficiales o aplicar manualmente el parche.

Os recomendamos acceder al aviso de seguridad del equipo de desarrollo de Squid donde encontraréis todos los detalles sobre este fallo que podría provocar una denegación de servicio en Squid.

Últimos análisis

Valoración RZ
7
Valoración RZ
9
Valoración RZ
8
Valoración RZ
8
Valoración RZ
8
Valoración RZ
8
Valoración RZ
10