Inicio > Incidentes > Puertos abiertos a nivel TCP , cerrados a nivel de aplicación

Puertos abiertos a nivel TCP , cerrados a nivel de aplicación

jueves, 8 de marzo de 2018 Dejar un comentario Ir a comentarios

Con el incremento de los anchos de bandas y la aparición de herramientas como ZMAP cada vez son más frecuentes los “researchers” y las empresas/organizaciones de “Threat Alert” que se dedican a reportar a en los buzones de seguridad de las organizaciones la existencia de problemas de seguridad porque hay un puerto “abierto” en un equipo.

El problema es que muchas veces es verdad que en ese equipo concreto esta el servicio “escuchando” en ese puerto,  pero eso NO SIGNIFICA que el servicio/aplicación este abierto en internet,  lo que lleva el tener que explicar una y otra vez a estas organizaciones y CERT(marca registrada)/CSIRT  nacionales/regionales/globales, de todo tipo, que sí, hay un servicio escuchando   pero no ,  el servicio en cuestión  no esta permitido fuera,  por lo que se trata de una falsa alarma.

Un ejemplo se tiene por ejemplo con los servidores de memcached, (puerto 11211 , UDP y TCP) , que permiten una amplificación  brutal como se vio en ataque contra GitHub a principios de Marzo de 2018, se puede comprobar que el mensaje es distinto para un servicio permitido tras un cortafuegos  y cuando estos sistemas bloquean el tráfico:

Tráfico permitido:

echo "version" | nc -v -i 5 130.XXX.YYY.ZZZ 11211
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 130.XXX.YYY.ZZZ:11211.
VERSION 1.4.17
Ncat: Idle timeout expired (5000 ms).

Tráfico denegado:

echo "version" | nc -v -i 5 130.XXX.YYY.ZZZ 11211
Ncat: Version 6.45 ( http://nmap.org/ncat )
Ncat: Connected to 130.XXX.YYY.ZZZ:11211.
Ncat: Idle timeout expired (5000 ms).

 

¿Qué es lo que pasa ?, pues la razón de este comportamiento la tienen los llamados “Firewall de siguiente  generación“, (qué igual habría que llamarlos de  generación “T” ) todavía no han evolucionado a la siguiente generación.   Estos sistemas permiten   filtrar a nivel de aplicación o más (“capa 7 ” en el antiguo modelo OSI de redes, capa “4” en el módelo de TCP/IP),

Estos cortafuegos analizan el tráfico y toman la decisión de cortar o dejar pasar el tráfico cuando saben que tipo de trafico hay, por ejemplo pueden permitir el tráfico “DNS” pero denegar  el “HTTP”, aunque vaya en una conexión por el puerto de DNS (53/UDP), pero claro tienen que ver que tráfico de datos circular antes tomar la decisión.

Como la mayoría de estos escanners “globales”, solo comprueban ya sea por “TCP SYN” o por establecimiento completo de conexión que hay un servicio escuchando en un puerto, no distinguen después si efectivamente el  servicio esta permitido en el cortafuegos y al final  alguna de estas organizaciones de “spam de alertas” envían información  no verificada sobre un problema que no es tal.

 

Categories: Incidentes Tags:
  1. Sin comentarios aún.
  1. Sin trackbacks aún.