Guía para evitar un escaneo de puertos

Escrito por David García Martín
Redes
6

Es práctica común entre los piratas informáticos escanear puertos para encontrar vulnerabilidades que aprovechar.

En este manual os explicamos unas nociones mínimas para estar seguros frente a esos escaneos.

Otro manual que publicaremos próximamente se encargará de explicar cómo hacer un escaneo de puertos.

Son 8 pequeños puntos que nos ayudarán a establecer un punto seguro en cualquier servidor o aplicación con acceso a la red.

1. Abre exclusivamente los puertos necesarios.

Un atacante buscará escanear probablemente con un robot y por fuerza bruta. Eso quiere decir que no sirve eso de “esto quien lo va a atacar si tardaría 10 horas”: los inicios de los ataques están automatizados.

2. Utiliza puertos que no sean un estándar

Cuando un atacante recoge información de un sistema, intentará seguramente hacerlo por puertos estándar es decir: el 1521 para Oracle, o el 8081 para un artifactory de Maven. En estos casos, sería ideal (aunque ello no constituye una seguridad por si misma) utilizar puertos no estándar que dificulten un poco al posible pirata informático.

3. Si no usas el puerto, ¿para qué lo quieres abierto?

Esta asertación parece una trivialidad pero no lo es en absoluto: la mayoría de administradores de sistemas, en sus inicios profesionales, olvidan cerrar o silenciar aquellos puertos que no se están usando. La diferencia entre cerrar y silenciar es que al cerrarlos, el puerto ofrecerá información de que está cerrado si está silenciado, no revelerá información de su estado.

4. Proteger el acceso a aquello que deba ser restringido y a sus conexiones.

Si se necesita ofrecer un servicio a algún usuario o empresa, pero es un servicio susceptible de ser atacado, debe ser protegido con sistemas de autentificación adecuados. Un claro ejemplo a evitar es o era, no se si estará corregido, el sistema de autentificación de Tuenti: por el puerto 80 sin encriptar.

Yo propongo como alternativa por ejemplo un SSL.

5. Usar métodos preventivos: Cortafuegos e IDS

Este punto es absolutamente imprescindible. Cuando se tiene un servicio público, éste debe tener sistemas preventivos que reaccionen de forma inteligente a los ataques. Es en este punto donde los IDS y los firewalls actúan. Un IDS reacciona de forma programada ajustándose a unas reglas definidas por el usuario, que además pueden ser dinámicas. El uso del firewall es sobradamente conocido y existen alternativas software y hardware bastante buenas.

Si además de esto, utilizas redundancia, es decir, dos Cortafuegos, por ejemplo, mejor que mejor.

6. Ocultar información.

Si un atacante necesita información para atacar nuestro sistema, parece lógico que le ofrezcamos la menor información posible. Ya hemos visto el silenciado de puertos; ahora vamos a explicar algunos detalles que muchos administradores de sistemas novatos desconocen:

Desactivar los banners de información de cualquier servicio. Cuando realizas una prueba, por ejemplo un SQL injection, es posible que la traza de error diga algo como “Apace Http 5.6.4” (versiones inventadas). Esa traza da idea del servicio que estamos usando y el posible atacante tiene un punto para comenzar a investigar. Aunque se puede silenciar para que no se envíe nada, lo ideal sería dar pistas falsas; devolver un servicio falso es mi opción recomendada: se puede falsificar la huella de la pila TCP/IP para engañar a los sistemas de detección de fingerprint, con lo cual los atacantes escogerían un punto de entrada equivocado e inútil.

7. Tener el software actualizado

Este punto es imprescindible y de sobra conocido por todos: un software antiguo contendrá errores y fallos de vulnerabilidad que cualquier script kiddie puede aprovechar para tumbarlo, secuestrarlo y otras lindezas.

8. Y por último: investigación sobre las últimas mejoras en seguridad.

No hay que perder de vista que la seguridad y sus atacantes mejoran constantemente. Uno de los puntos fuertes de un profesional de la seguridad es estar informado de las últimas novedades. Por ejemplo, aunque es un tema que nunca he tocado personalmente, es ofrecer un servicio sin ningún puerto abierto: no es imposibe, se pueden configurar reglas para, en determinados casos, abrir el puerto y proporcionar el servicio.


Continúa leyendo
  • Anónimo

    ¿no eran 10?, nos han hackeado los 2 últimos puntos… :-p

    • Una pequeña errata…gracias por el aviso! Ya está corregido.

      • Anónimo

        Se te ha pasado justo encima del primer punto: “Son 10 pequeños puntos que nos ayudarán a establecer….”

  • Solido

    Interesante 🙂

    • Se agradece el comentario, solido. 😀