LUK
25-05-2012, 13:40
En anteriores post ya hemos hablado sobre la tremenda utilidad que tiene la herramienta nmap. Se ha comentado funcionalidades (http://www.securityartwork.es/2009/06/08/nmap-scripting-engine-nse/), optimizaciones (http://www.securityartwork.es/2011/11/17/optimizando-nmap/) y demás investigaciones (http://www.securityartwork.es/2012/03/23/calculo-del-rtt-en-nmap/). Sin embargo, esta herramienta puede ser peligrosa si alguien malintencionado quisiera usarla contra nuestra red. Recordemos que nmap se usa principalmente para descubrir host activos en una red, mostrar sus servicios disponibles, versión de servicio, de sistema operativo, etc. En definitiva, información muy útil para alguien que pretenda hacer maldades.
Por tanto, continuando con la manía que tenemos los que nos preocupa la seguridad de nuestros equipos, vamos a conocer qué medidas se pueden aplicar para ponérselo un poco más difícil a los chicos malos.
1. Conócete a ti mismo
A pesar de ser una frase muy recurrente, tanto en la seguridad informática, filosofía griega o como frase típica de Sun Tzu, la mejor manera de despreocuparte de los escaneos de nmap es teniendo pleno conocimiento de lo que pueden averiguar de tu red, haciendo una serie de análisis de visibilidad externos e internos. Lanza escaneos, desde diferentes subredes, tanto fuera como dentro del perímetro. Comprobarás además si los firewalls están correctamente configurados o ha habido una regla olvidada que haya podido suponer un riesgo. Podrás descubrir servicios vulnerables, si usamos nmap además como herramienta de fingerprinting. Una vez hecha la valoración de la visibilidad, estaremos en condiciones de bloquear servicios, cerrar puertos, parchear vulnerabilidades, etcetc.
Esta práctica, convirtiéndola en periódica, convierte a nmap en una poderosa herramienta de servicios sospechosos. La utilidad Ndiff (http://nmap.org/ndiff/) incluida en la suite de nmap, permite comparar resultados de escaneos, avisando de nuevos puertos descubiertos. Así se podría identificar posibles puertas traseras, o servicios que no deberían estar iniciados. Por ejemplo, si esta herramienta detecta que ha detectado el puerto 7777 como nuevo en un servidor de DMZ, es para preocuparse, ¿verdad?
2. Política por defecto DROP
Esta recomendación no se debería implantar únicamente para dificultar el escaneo al atacante, sino porque protege la red de forma más precisa. Básicamente, en una política por defecto ACCEPT DROP (gracias a ignaciopollo (http://imastic.com/) por darse cuenta de la errata) de un firewall, permites pasar tráfico hacia cualquier puerto excepto los definidos en una lista negra. En la política por defecto DROP, se filtra todo el tráfico excepto el definido por una lista blanca.
Explicaré esta consecuencia con un ejemplo: nmap lanza una sonda hacia un puerto concreto de una máquina al que se está auditando. Si hay un firewall en medio con política ACCEPT, dejará pasar esa sonda salvo que se haya configurado que ese puerto debe estar filtrado. Por tanto, el firewall dejará pasar todas las sondas que envíe nmap durante el escaneo, excepto las pocas sondas que se haya filtrado. Ocurre entonces que cuando llega un intento de conexión a un puerto cerrado de un equipo, éste responde de forma activa que el puerto está cerrado. Nmap recibe este dato y comprende que debe continuar su escaneo con el siguiente puerto.
http://www.securityartwork.es/wp-content/uploads/2012/05/a.jpg
Teniendo un firewall con política DROP, todas las sondas que envíe nmap quedarán filtradas, exceptuando las que estén definidas en la lista blanca. Por tanto, cada vez que se envíe una sonda hacia un puerto no alcanzable, el paquete se descartará. Entonces nmap esperará un tiempo hasta dar por perdida la sonda y la reenviará otra vez, hasta un número máximo de intentos para darse por vencido y pasar al siguiente puerto.
http://www.securityartwork.es/wp-content/uploads/2012/05/b.jpg
Haciendo números, el escaneo del primer ejemplo tardará únicamente el tiempo que se tarde en enviar las sondas hacia el objetivo, y recoger sus respuestas, obviando las retransmisiones por paquetes perdidos. En el segundo ejemplo, nmap se esperará un tiempo en recibir la respuesta hasta dar por perdido el paquete, multiplicado por el número de reintentos, y a su vez multiplicado por el número de puertos filtrados. En total, es una cantidad de tiempo considerable, desperdiciado en esperas y más esperas.
Un escaneo con timings agresivos y bien optimizados, hacia los 64K puertos, puede variar de un par de minutos a cerca de una hora, dependiendo la configuración de los cortafuegos que hayan por medio.
3. Esconde servicios
Nmap tiene una lista de los puertos más usuales. Un escaneo por defecto, sin especificar qué rango de puertos se quiere auditar, tira de esa lista, escoge los 1000 puertos más utilizados para intentar encontrar alguno abierto. Esta lista usualmente está en /usr/share/nmap/nmap-services por si queréis consultarla. Es interesante en algunos casos cambiar el puerto a la escucha de un servicio por un puerto “oscuro” que no sea muy usual. A pesar del típico dicho de “seguridad por oscuridad” no es una buena opción, esta práctica puede ser útil, librándote de un escaneo rápido, y además, de bastante malware que busca servicios típicos para lanzarles ataques por fuerza bruta.
4. Confundir la detección de SSOO
Este “tweak” lo vi hace poco y me resultó curioso. Nmap tiene un fichero de 2MB con huellas de una gran cantidad de dispositivos. Cuando activamos la opción de OS fingerprinting, nmap hace más de 30 pruebas, determinando con bastante acierto el dispositivo y sistema operativo, en función de los resultados obtenidos. Una de esas pruebas es determinar el TTL por defecto. Dependendiendo del sistema operativo, el valor varía bastante. En el caso de Linux, es 64. No obstante, es un parámetro bastante sencillo de modificar.
Veamos un ejemplo:
~# nmap -O 192.168.1.100
[...]
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:kernel:2.6
OS details: Linux 2.6.17 2.6.36
Observamos como en este ejemplo acierta bastante con el sistema operativo de la máquina auditada. Modificando el valor del TTL por defecto:
~# echo 83 > /proc/sys/net/ipv4/ip_default_ttl
por un valor inusual, obtendríamos ahora este resultado:
No exact OS matches for host (If you know what OS is running on it, see
http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.61TEST2%E=4%D=4/18%OT=22%CT=1%CU=42601%PV=Y%DS=1%DC=D%G=Y%M=080
OS:027%TM=4F8EAFE6%P=x86_64¬unknown¬linux¬gnu)SEQ( SP=C8%GCD=1%ISR=C9%TI=Z%C
OS:I=Z%II=I%TS=8)OPS(O1=M5B4ST11NW5%O2=M5B4ST11NW5 %O3=M5B4NNT11NW5%O4=M5B4S
OS:T11NW5%O5=M5B4ST11NW5%O6=M5B4ST11)WIN(W1=16A0%W 2=16A0%W3=16A0%W4=16A0%W5
OS:=16A0%W6=16A0)ECN(R=Y%DF=Y%T=54%W=16D0%O=M5B4NN SNW5%CC=Y%Q=)T1(R=Y%DF=Y%
OS:T=54%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T =54%W=16A0%S=O%A=S+%F=AS%
OS:O=M5B4ST11NW5%RD=0%Q=)T4(R=Y%DF=Y%T=54%W=0%S=A% A=Z%F=R%O=%RD=0%Q=)T5(R=Y
OS:%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y% DF=Y%T=54%W=0%S=A%A=Z%F=R
OS:%O=%RD=0%Q=)T7(R=Y%DF=Y%T=54%W=0%S=Z%A=S+%F=AR% O=%RD=0%Q=)U1(R=Y%DF=N%T=
OS:54%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD =G)IE(R=Y%DFI=N%T=54%CD=S
OS:)
Nos indica que no ha podido encontrar equivalencia con la huella obtenida. A pesar de que si que se puede leer “linux” entre los valores recogidos, no es capaz de afinar tanto como con el ejemplo anterior.
No obstante, en la práctica esto no suele ser tan bonito. Además de estos parámetros, nmap utiliza otros indicios para averiguar el tipo de sistema, como los banners de servicios. SSHd suele ser bastante chivato y por desgracia no hay ninguna opción para cambiar o silenciar este banner:
# nmap -sV -p22 192.168.1.100
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5 (protocol 2.0)
Otro indicio es encontrar una aplicación que es específica de un sistema operativo concreto. Por ejemplo, un servidor web IIS, con bastante probabilidad estará ejecutándose en una máquina Windows, salvo que sea una honey, claro ;)
5. Otras “recomendaciones no recomendables”
Hay que tener mucho cuidado con la protección activa ante escaneos. En el caso de disponer de un IPS, debemos estar muy seguros de que la parametrización está bien afinada y que lo que se está detectando no hay falsos positivos. En determinados escenarios, es muy difícil hacer esto posible. Más peligroso todavía es añadir las IPs atacantes a cuarentena, o filtrado automático al firewall. Si un atacante detecta este comportamiento, podría lanzar un nmap con IPs spoofeadas, pudiendo forzar al sistema a filtrar IPs arbitrarias.
Otra medida más discutible es si añadir reglas al IDS para detectar escaneos. El hecho de que nuestra red está siendo escaneada probablemente no sea muy relevante como para preocuparse. Si nuestra red es grande, y el sistema de detección de intrusos está integrado con un SIEM, podrían llegar un gran número de alertas a lo largo del día, generando ruido innecesario. No obstante, si contamos con un sistema de correlación de alertas, que utilice este dato para contrastarlo con otros eventos, si que puede ser realmente útil recopilar esta información. Por ejemplo, un nmap desde una IP, por sí solo no es muy relevante, pero si hemos registrado un acceso por SSH un tiempo después de un escaneo desde esa misma IP, como hechos aislados no parece relevante, pero si se correla esta información, podríamos estar ante un potencial acceso no autorizado al sistema.
Por José L. Chica (http://www.securityartwork.es/author/jchica/) @ http://www.securityartwork.es/2012/05/22/defensas-contra-nmap/
Por tanto, continuando con la manía que tenemos los que nos preocupa la seguridad de nuestros equipos, vamos a conocer qué medidas se pueden aplicar para ponérselo un poco más difícil a los chicos malos.
1. Conócete a ti mismo
A pesar de ser una frase muy recurrente, tanto en la seguridad informática, filosofía griega o como frase típica de Sun Tzu, la mejor manera de despreocuparte de los escaneos de nmap es teniendo pleno conocimiento de lo que pueden averiguar de tu red, haciendo una serie de análisis de visibilidad externos e internos. Lanza escaneos, desde diferentes subredes, tanto fuera como dentro del perímetro. Comprobarás además si los firewalls están correctamente configurados o ha habido una regla olvidada que haya podido suponer un riesgo. Podrás descubrir servicios vulnerables, si usamos nmap además como herramienta de fingerprinting. Una vez hecha la valoración de la visibilidad, estaremos en condiciones de bloquear servicios, cerrar puertos, parchear vulnerabilidades, etcetc.
Esta práctica, convirtiéndola en periódica, convierte a nmap en una poderosa herramienta de servicios sospechosos. La utilidad Ndiff (http://nmap.org/ndiff/) incluida en la suite de nmap, permite comparar resultados de escaneos, avisando de nuevos puertos descubiertos. Así se podría identificar posibles puertas traseras, o servicios que no deberían estar iniciados. Por ejemplo, si esta herramienta detecta que ha detectado el puerto 7777 como nuevo en un servidor de DMZ, es para preocuparse, ¿verdad?
2. Política por defecto DROP
Esta recomendación no se debería implantar únicamente para dificultar el escaneo al atacante, sino porque protege la red de forma más precisa. Básicamente, en una política por defecto ACCEPT DROP (gracias a ignaciopollo (http://imastic.com/) por darse cuenta de la errata) de un firewall, permites pasar tráfico hacia cualquier puerto excepto los definidos en una lista negra. En la política por defecto DROP, se filtra todo el tráfico excepto el definido por una lista blanca.
Explicaré esta consecuencia con un ejemplo: nmap lanza una sonda hacia un puerto concreto de una máquina al que se está auditando. Si hay un firewall en medio con política ACCEPT, dejará pasar esa sonda salvo que se haya configurado que ese puerto debe estar filtrado. Por tanto, el firewall dejará pasar todas las sondas que envíe nmap durante el escaneo, excepto las pocas sondas que se haya filtrado. Ocurre entonces que cuando llega un intento de conexión a un puerto cerrado de un equipo, éste responde de forma activa que el puerto está cerrado. Nmap recibe este dato y comprende que debe continuar su escaneo con el siguiente puerto.
http://www.securityartwork.es/wp-content/uploads/2012/05/a.jpg
Teniendo un firewall con política DROP, todas las sondas que envíe nmap quedarán filtradas, exceptuando las que estén definidas en la lista blanca. Por tanto, cada vez que se envíe una sonda hacia un puerto no alcanzable, el paquete se descartará. Entonces nmap esperará un tiempo hasta dar por perdida la sonda y la reenviará otra vez, hasta un número máximo de intentos para darse por vencido y pasar al siguiente puerto.
http://www.securityartwork.es/wp-content/uploads/2012/05/b.jpg
Haciendo números, el escaneo del primer ejemplo tardará únicamente el tiempo que se tarde en enviar las sondas hacia el objetivo, y recoger sus respuestas, obviando las retransmisiones por paquetes perdidos. En el segundo ejemplo, nmap se esperará un tiempo en recibir la respuesta hasta dar por perdido el paquete, multiplicado por el número de reintentos, y a su vez multiplicado por el número de puertos filtrados. En total, es una cantidad de tiempo considerable, desperdiciado en esperas y más esperas.
Un escaneo con timings agresivos y bien optimizados, hacia los 64K puertos, puede variar de un par de minutos a cerca de una hora, dependiendo la configuración de los cortafuegos que hayan por medio.
3. Esconde servicios
Nmap tiene una lista de los puertos más usuales. Un escaneo por defecto, sin especificar qué rango de puertos se quiere auditar, tira de esa lista, escoge los 1000 puertos más utilizados para intentar encontrar alguno abierto. Esta lista usualmente está en /usr/share/nmap/nmap-services por si queréis consultarla. Es interesante en algunos casos cambiar el puerto a la escucha de un servicio por un puerto “oscuro” que no sea muy usual. A pesar del típico dicho de “seguridad por oscuridad” no es una buena opción, esta práctica puede ser útil, librándote de un escaneo rápido, y además, de bastante malware que busca servicios típicos para lanzarles ataques por fuerza bruta.
4. Confundir la detección de SSOO
Este “tweak” lo vi hace poco y me resultó curioso. Nmap tiene un fichero de 2MB con huellas de una gran cantidad de dispositivos. Cuando activamos la opción de OS fingerprinting, nmap hace más de 30 pruebas, determinando con bastante acierto el dispositivo y sistema operativo, en función de los resultados obtenidos. Una de esas pruebas es determinar el TTL por defecto. Dependendiendo del sistema operativo, el valor varía bastante. En el caso de Linux, es 64. No obstante, es un parámetro bastante sencillo de modificar.
Veamos un ejemplo:
~# nmap -O 192.168.1.100
[...]
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:kernel:2.6
OS details: Linux 2.6.17 2.6.36
Observamos como en este ejemplo acierta bastante con el sistema operativo de la máquina auditada. Modificando el valor del TTL por defecto:
~# echo 83 > /proc/sys/net/ipv4/ip_default_ttl
por un valor inusual, obtendríamos ahora este resultado:
No exact OS matches for host (If you know what OS is running on it, see
http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.61TEST2%E=4%D=4/18%OT=22%CT=1%CU=42601%PV=Y%DS=1%DC=D%G=Y%M=080
OS:027%TM=4F8EAFE6%P=x86_64¬unknown¬linux¬gnu)SEQ( SP=C8%GCD=1%ISR=C9%TI=Z%C
OS:I=Z%II=I%TS=8)OPS(O1=M5B4ST11NW5%O2=M5B4ST11NW5 %O3=M5B4NNT11NW5%O4=M5B4S
OS:T11NW5%O5=M5B4ST11NW5%O6=M5B4ST11)WIN(W1=16A0%W 2=16A0%W3=16A0%W4=16A0%W5
OS:=16A0%W6=16A0)ECN(R=Y%DF=Y%T=54%W=16D0%O=M5B4NN SNW5%CC=Y%Q=)T1(R=Y%DF=Y%
OS:T=54%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T =54%W=16A0%S=O%A=S+%F=AS%
OS:O=M5B4ST11NW5%RD=0%Q=)T4(R=Y%DF=Y%T=54%W=0%S=A% A=Z%F=R%O=%RD=0%Q=)T5(R=Y
OS:%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y% DF=Y%T=54%W=0%S=A%A=Z%F=R
OS:%O=%RD=0%Q=)T7(R=Y%DF=Y%T=54%W=0%S=Z%A=S+%F=AR% O=%RD=0%Q=)U1(R=Y%DF=N%T=
OS:54%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD =G)IE(R=Y%DFI=N%T=54%CD=S
OS:)
Nos indica que no ha podido encontrar equivalencia con la huella obtenida. A pesar de que si que se puede leer “linux” entre los valores recogidos, no es capaz de afinar tanto como con el ejemplo anterior.
No obstante, en la práctica esto no suele ser tan bonito. Además de estos parámetros, nmap utiliza otros indicios para averiguar el tipo de sistema, como los banners de servicios. SSHd suele ser bastante chivato y por desgracia no hay ninguna opción para cambiar o silenciar este banner:
# nmap -sV -p22 192.168.1.100
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5 (protocol 2.0)
Otro indicio es encontrar una aplicación que es específica de un sistema operativo concreto. Por ejemplo, un servidor web IIS, con bastante probabilidad estará ejecutándose en una máquina Windows, salvo que sea una honey, claro ;)
5. Otras “recomendaciones no recomendables”
Hay que tener mucho cuidado con la protección activa ante escaneos. En el caso de disponer de un IPS, debemos estar muy seguros de que la parametrización está bien afinada y que lo que se está detectando no hay falsos positivos. En determinados escenarios, es muy difícil hacer esto posible. Más peligroso todavía es añadir las IPs atacantes a cuarentena, o filtrado automático al firewall. Si un atacante detecta este comportamiento, podría lanzar un nmap con IPs spoofeadas, pudiendo forzar al sistema a filtrar IPs arbitrarias.
Otra medida más discutible es si añadir reglas al IDS para detectar escaneos. El hecho de que nuestra red está siendo escaneada probablemente no sea muy relevante como para preocuparse. Si nuestra red es grande, y el sistema de detección de intrusos está integrado con un SIEM, podrían llegar un gran número de alertas a lo largo del día, generando ruido innecesario. No obstante, si contamos con un sistema de correlación de alertas, que utilice este dato para contrastarlo con otros eventos, si que puede ser realmente útil recopilar esta información. Por ejemplo, un nmap desde una IP, por sí solo no es muy relevante, pero si hemos registrado un acceso por SSH un tiempo después de un escaneo desde esa misma IP, como hechos aislados no parece relevante, pero si se correla esta información, podríamos estar ante un potencial acceso no autorizado al sistema.
Por José L. Chica (http://www.securityartwork.es/author/jchica/) @ http://www.securityartwork.es/2012/05/22/defensas-contra-nmap/