Usando bash `/ dev / udp`, ¿cómo sabría si el puerto estaba abierto?

No tengo acceso a, netcato nmapeso estoy tratando de usar, bashy los /dev/udp/archivos especiales para probar los puertos.

Podría hacer algo como:

echo "" > /dev/udp/example.com/8000

Pero $?siempre es 0cuando se usa UDP. ¿Supongo que es porque ese es el valor de retorno del echo ""comando correcto?

Básicamente estoy tratando de replicar lo que puedo hacer nmapy netcat:

nmap -sU -p 8000 example.com | grep open >/dev/null && echo 'open'
nc -z -u example.com 8000 && echo 'open'

¿Cómo haría esto /dev/udp?

Para tcp, solo verificando $?. Si la conexión falla, $?no será 0:

$ >/dev/tcp/google.com/81
bash: connect: Network is unreachable
bash: /dev/tcp/google.com/81: Network is unreachable
$ echo $?
1

Tomará tiempo bashdarse cuenta de que la conexión falló. Puedes usar el tiempo de espera de para activar bash:

$ timeout 1 bash -c '>/dev/tcp/google.com/80' &&
  echo Port open ||
  echo Port close
Port open

Probar el puerto udp es más complejo.

Estrictamente hablando, no hay un estado abierto (por supuesto, udp es un protocolo sin estado ) con udp. Solo hay dos estados con udp, escuchando o no . Si el estado no es , obtendrá un destino ICMP inalcanzable .

Desafortunadamente, el cortafuegos o el enrutador suelen descartar esos paquetes ICMP, por lo que no estará seguro de qué estado del puerto udp.

En general, no puedes.

A diferencia de TCP, UDP no tiene conexión. No puede detectar que un puerto está abierto simplemente haciendo una conexión de no hacer nada como lo puede hacer con TCP. Por el contrario, debe enviar datos al puerto y ver qué sucede, y los detalles de UDP implementados en el mundo real dificultan la interpretación de los resultados. Incluso herramientas sofisticadas de nivel de paquete como nmapno pueden decir con certeza si hay un programa escuchando un determinado puerto UDP. nmapclasifica los puertos UDP en tres grupos:

1. Definitivamente abierto. El envío de un paquete al puerto provocó una respuesta de datos de la máquina de destino.
2. Definitivamente cerrado. El envío de un paquete al puerto provocó un mensaje "Destino ICMP inalcanzable" de la máquina de destino.
3. Abierto o filtrado. Enviar un paquete al puerto no provocó ninguna respuesta. Tal vez hay un cortafuegos que deja caer los paquetes; tal vez hay un programa escuchando y nmapsimplemente no ha descubierto cómo obtener una respuesta; tal vez el usuario tuvo mala suerte y todos los paquetes se perdieron en tránsito.