Usando o '/ dev / udp' do bash, como saberia se a porta estava aberta?

Question

Eu não tenho acesso a netcat ou nmap , por isso estou tentando usar bash e os arquivos /dev/udp/ especiais para testar portas.

Eu poderia fazer algo como:

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

Mas $? é sempre 0 ao usar o UDP. Estou assumindo que é porque esse é o valor de retorno do comando echo "" correto?

Estou basicamente tentando replicar o que posso fazer com nmap e netcat :

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

Como eu faria isso com /dev/udp ?

    

Answer 1

Para tcp, apenas verificando $? . Se a conexão falhou, $? não será 0 :

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

Demora algum tempo até que bash perceba que a conexão falhou. Você pode usar o tempo limite para acionar bash :

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

O teste da porta do udp é mais complexo.

Estritamente falando, não existe um estado open (claro, o protocolo udp é stateless ) com o udp. Existem apenas dois estados com o udp, ouvindo ou não . Se o estado não for , você receberá um Destino do ICMP Inacessível .

Infelizmente, o firewall ou o roteador costumam remover esses pacotes ICMP, então você não tem certeza do estado da porta udp.

    

Answer 2

Em geral, você não pode.

Ao contrário do TCP, o UDP é sem conexão. Você não pode detectar que uma porta está aberta simplesmente fazendo uma conexão do tipo nada com ela, como acontece com o TCP. Em vez disso, você precisa enviar dados para a porta e ver o que acontece, e os detalhes de UDP como implementadas no mundo real fazem interpretação dos resultados difícil. Mesmo sofisticadas ferramentas de nível de pacote como nmap não pode dizer com certeza se há um programa de ouvir uma determinada porta UDP. nmap classifica as portas UDP em três grupos:

1. Definitivamente aberto. O envio de um pacote para a porta provocou uma resposta de dados da máquina de destino.
2. Definitivamente fechado. Envio de um pacote para o porto provocou uma mensagem "ICMP Destino inacessível" da máquina destino.
3. aberto ou filtrado. Enviar um pacote para a porta não provocou resposta alguma. Talvez haja um firewall que esteja descartando os pacotes; talvez haja um programa escutando e nmap não tenha descoberto como obter uma resposta; talvez o usuário tenha acabado azarado e todos os pacotes foram perdidos em trânsito.