RootUsers (Español)

La mayoría de nosotros estaría familiarizado con el simple comando ‘ping’ basado en ICMP que nos permite probar una respuesta básica desde algún dispositivo conectado a la red. Si bien es ideal para la solución de problemas básicos, no nos permite confirmar si el host en particular en el otro extremo está respondiendo en puertos TCP o UDP donde es probable que se proporcionen la mayoría de los servicios.,

Ping no es la solución de problemas de red, si un firewall bloquea el tráfico ICMP entrante, entonces un ping no tendrá éxito, lo que puede producir una falsa percepción de que el host está caído ya que no responde al ping, sin embargo, otros servicios podrían responder bien.

alternativamente, si bien ping puede regresar bien con una respuesta, no indica si un servidor web está respondiendo en el puerto 80 para solicitudes HTTP, el servidor web puede haber fallado y ya no responder.

entonces, si ping está basado en ICMP, ¿podemos golpear un puerto TCP o UDP para la respuesta en su lugar?, La respuesta es sí, echemos un vistazo.

Enter tcping

tcping es una de esas herramientas que se puede utilizar para comprobar que un puerto TCP está respondiendo, hay algunas versiones disponibles, sin embargo, uso esta: http://www.elifulkerson.com/projects/tcping.php

el manual está en la misma página, básicamente puede ejecutar un comando similar al siguiente.

Aquí estamos usando tcping para comprobar el puerto 443 en google.com. como se puede ver, el puerto se muestra como abierto y respondiendo, si el puerto no está abierto, se mostrará como sin respuesta después de 2000ms de forma predeterminada.,

También puede usar telnet para probar la conectividad TCP a un puerto, sin embargo, la herramienta tcping proporciona otras características como se describe en la sección de uso aquí. Algunas de estas características incluyen ser capaz de ejecutar continuamente la prueba que permite una forma de generar tráfico para que usted tenga cuidado en las capturas de paquetes en vivo, así como el tiempo de respuesta.

¿qué pasa con UDP?

como UDP es un protocolo sin conexión, determinar si está respondiendo es un poco diferente., Un ‘ping’ TCP funciona realizando un apretón de manos de tres vías, la fuente enviará un SYN al destino, el destino responderá con un SYN-ACK, y la fuente enviará un ACK completando el apretón de manos y estableciendo la conexión. Como UDP no establece una conexión, no podemos simplemente buscar esto para determinar si el puerto está respondiendo, sino que necesitamos enviar datos específicos y ver si recibimos una respuesta.

nmap es una gran herramienta para esto, puede descargarlo y usarlo para escanear puertos de una dirección de destino para determinar qué puertos están abiertos.,

en este ejemplo estamos preguntando si 8.8.8.8 está respondiendo en el puerto UDP 53, ya que sirve DNS esperaríamos que estuviera abierto.

el resultado abierto / filtrado se usa cuando nmap no puede determinar si el puerto está abierto o filtrado, es posible que el puerto abierto no haya dado una respuesta. Muestra que el servicio ha sido identificado como ‘dominio’ ya que es para servir DNS. He probado esto en algunos otros servidores DNS en Internet y algunos se muestran como abiertos solo confirmando que están respondiendo.

NMAP también se puede usar para comprobar que un puerto TCP está abierto de manera similar, simplemente cambie-sU a-sT.,

por qué un puerto puede no responder

hay algunas razones simples por las que un puerto puede no responder a su prueba.

• un firewall está bloqueando el tráfico: puede haber un firewall que se ejecuta entre el origen y el destino filtrando el tráfico dependiendo de las reglas en su lugar, incluso si sabe que el destino debe responder en un puerto en particular.
• El destino puede no estar escuchando en el puerto: en pocas palabras, el destino al que está tratando de conectarse puede no tener ningún servicio escuchando en el puerto especificado, por lo que no habrá ninguna respuesta., Esto también puede suceder si un servicio se ha detenido, por ejemplo, si detiene Apache, un servidor web ya no responderá a las solicitudes del puerto 80.
• Hay algún otro problema de red entre la fuente y el destino del tráfico: podría haber cualquier número de problemas de conectividad de red entre la fuente y el destino, si es posible, verifique la red, sin embargo, si el tráfico atraviesa Internet, estará limitado en lo que puede verificar.,

puede comprobar la conectividad a lo largo de la ruta del tráfico ejecutando una captura de paquetes con algo como Wireshark o tcpdump, esto le mostrará a dónde está llegando el tráfico y dónde está siendo detenido a lo largo de la ruta. Puede ejecutarlo en los servidores de origen y destino, así como en dispositivos intermedios a los que tenga acceso, como firewalls o enrutadores. Siga el flujo de tráfico hasta que determine dónde está el problema.,

resumen

mientras realiza un ‘ping’ TCP a un destino, puede confirmar si está respondiendo según lo previsto, aunque hay algunas razones por las que el puerto puede no responder como se indica. UDP se puede comprobar, sin embargo, es un poco más difícil estar seguro de si está recibiendo correctamente una respuesta, por lo que las pruebas no siempre son confiables, lo que tiene sentido ya que UDP no es un protocolo confiable. Estas pruebas pueden ser útiles al probar la seguridad al confirmar si los puertos están abiertos o cerrados.