Usando bash's / / dev / udp`, come faccio a sapere se la porta era aperta?

Non ho accesso a netcato nmapalmeno sto provando a utilizzare bashe i /dev/udp/file speciali per testare le porte.

Potrei fare qualcosa del tipo:

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

Ma $?è sempre 0quando si utilizza UDP. Suppongo sia perché questo è il valore di ritorno del echo ""comando corretto?

Sto sostanzialmente cercando di replicare ciò che sono in grado di fare nmape netcat:

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

Come lo farei con /dev/udp?

Per tcp, sto solo controllando $?. Se la connessione non è riuscita, $?non sarà 0:

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

Ci vorrà del tempo per bashrendersi conto che la connessione non è riuscita. È possibile utilizzare il timeout per attivare bash:

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

Il test della porta udp è più complesso.

A rigor di termini, non esiste uno stato aperto (ovviamente udp è un protocollo senza stato ) con udp. Ci sono solo due stati con udp, in ascolto o meno . Se lo stato non lo è , si otterrà una destinazione ICMP non raggiungibile .

Sfortunatamente, il firewall o il router spesso rilasciano quei pacchetti ICMP, quindi non si sarà sicuri dello stato della porta udp.

In generale, non puoi.

A differenza di TCP, UDP è senza connessione. Non è possibile rilevare che una porta è aperta semplicemente effettuando una connessione "fai niente" come puoi con TCP. Piuttosto, è necessario inviare dati alla porta e vedere cosa succede, ei dettagli di UDP implementati nel mondo reale rendono difficile l'interpretazione dei risultati. Anche strumenti sofisticati a livello di pacchetto come nmapnon possono dire con certezza se c'è un programma che ascolta una determinata porta UDP. nmapclassifica le porte UDP in tre gruppi:

1. Sicuramente aperto. L'invio di un pacchetto alla porta ha provocato una risposta di dati dal computer di destinazione.
2. Sicuramente chiuso L'invio di un pacchetto alla porta ha generato un messaggio "Destinazione irraggiungibile ICMP" dal computer di destinazione.
3. O aperto o filtrato. L'invio di un pacchetto alla porta non ha prodotto alcuna risposta. Forse c'è un firewall che fa cadere i pacchetti; forse c'è un programma in ascolto e nmapnon ha ancora capito come ottenere una risposta; forse l'utente è stato sfortunato e tutti i pacchetti sono stati persi durante il trasporto.