Verifica se è possibile raggiungere una porta su un sistema remoto (senza telnet)

Ai vecchi tempi, telnetvedevamo se una porta su un host remoto era aperta: telnet hostname porttentava di connettersi a qualsiasi porta su qualsiasi host e ti dava accesso al flusso TCP grezzo.

In questi giorni, i sistemi su cui lavoro non hanno telnet installato (per motivi di sicurezza) e tutte le connessioni in uscita a tutti gli host sono bloccate per impostazione predefinita. Nel tempo, è facile perdere traccia di quali porte sono aperte a quali host.

Esiste un altro modo per verificare se una porta su un sistema remoto è aperta, utilizzando un sistema Linux con un numero limitato di pacchetti installati e telnetnon è disponibile?

Bash è stato in grado di accedere alle porte TCP e UDP per un po '. Dalla pagina man:

/dev/tcp/host/port
    If host is a valid hostname or Internet address, and port is an integer port number
    or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
    If host is a valid hostname or Internet address, and port is an integer port number
    or service name, bash attempts to open a UDP connection to the corresponding socket.

Quindi potresti usare qualcosa del genere:

xenon-lornix:~> cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_6.2p2 Debian-6
^C pressed here

Taa Daa!

Bello e prolisso! Dalle pagine man.
Porta singola:

nc -zv 127.0.0.1 80

Porte multiple:

nc -zv 127.0.0.1 22 80 8080

Gamma di porte:

nc -zv 127.0.0.1 20-30

Netcat è uno strumento utile:

nc 127.0.0.1 123 &> /dev/null; echo $?

Verrà emesso 0se la porta 123 è aperta e 1se è chiusa.

Il metodo più semplice, senza utilizzare un altro strumento, come ad esempio socat, è come descritto nella risposta di @lornix sopra. Questo è solo per aggiungere un esempio reale di come si farebbe uso del psuedo-dispositivo /dev/tcp/...all'interno di Bash se si volesse, per esempio, verificare se un altro server aveva una determinata porta accessibile tramite la riga di comando.

Esempi

Supponiamo di avere un host sulla mia rete chiamato skinner.

$ (echo > /dev/tcp/skinner/22) >/dev/null 2>&1 \
    && echo "It's up" || echo "It's down"
It's up

$ (echo > /dev/tcp/skinner/222) >/dev/null 2>&1 && \
    echo "It's up" || echo "It's down"
It's down

Il motivo per cui vuoi racchiudere le echo > /dev/...parentesi in questo modo (echo > /dev/...)è perché se non lo fai, quindi con i test delle connessioni che sono inattivi, otterrai questi tipi di messaggi.

$ (echo > /dev/tcp/skinner/223) && echo hi
bash: connect: Connection refused
bash: /dev/tcp/skinner/223: Connection refused

Questi non possono essere semplicemente reindirizzati /dev/nullpoiché provengono dal tentativo di scrivere dati sul dispositivo /dev/tcp. Quindi catturiamo tutto l'output all'interno di un comando secondario, ovvero (...cmds...)reindirizziamo l'output del comando secondario.

Ho scoperto che curlpotrebbe svolgere il lavoro in modo simile a telnet, e curlti dirò anche quale protocollo si aspetta l'ascoltatore.

Costruisci un URI HTTP dal nome host e dalla porta come primo argomento a curl. Se curlpuò connettersi, segnalerà una mancata corrispondenza del protocollo e l'uscita (se l'ascoltatore non è un servizio Web). Se curlnon è possibile connettersi, si verificherà il timeout.

Ad esempio, la porta 5672 sull'host 10.0.0.99 è chiusa o bloccata da un firewall:

$ curl http://10.0.0.99:5672
curl: (7) couldn't connect to host

Tuttavia, da un sistema diverso, è possibile raggiungere la porta 5672 sull'host 10.0.0.99 e sembra che stia eseguendo un listener AMQP.

$ curl http://10.0.0.99:5672
curl: (56) Failure when receiving data from the peer
AMQP

È importante distinguere tra i diversi messaggi: il primo errore è stato perché curlnon è stato possibile connettersi alla porta. Il secondo errore è un test di successo, sebbene curlprevisto un listener HTTP anziché un listener AMQP.

[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.193.173 6443
nc: connect to 192.168.193.173 port 6443 (tcp) failed: Connection refused

[admin@automation-server 1.2.2]# nc -v -z -w2 192.168.194.4 6443
Connection to 192.168.194.4 6443 port [tcp/sun-sr-https] succeeded!

Spero che risolva il tuo problema :)

Ecco una riga:

</dev/tcp/localhost/11211 && echo Port is open || echo Port is closed

usando la sintassi di Bash spiegata nella risposta di @lornix .

Per ulteriori informazioni, consultare: Guida avanzata di script Bash: capitolo 29. /deve/proc .

Ho lottato per un giorno intero perché nessuna di queste risposte sembrava funzionare per me. Il problema è che la versione più recente di ncnon ha più il -zflag, mentre l'accesso diretto via TCP (come secondo @lornix e @slm) fallisce quando l'host non è raggiungibile. Alla fine ho trovato questa pagina , dove finalmente ho trovato non uno ma due esempi funzionanti:

1. nc -w1 127.0.0.1 22 </dev/null

   (la -wbandiera si occupa del timeout e </dev/nullsostituisce la -zbandiera)

2. timeout 1 bash -c '(echo > /dev/tcp/127.0.0.1/22) >/dev/null 2>&1'

   (il timeoutcomando si occupa del timeout e il resto proviene da @slm)

Quindi, utilizzare semplicemente &&e / o ||(o anche $?) per estrarre il risultato. Speriamo che qualcuno troverà queste informazioni utili.

Combinando le risposte di @kenorb e @Azukikuru potresti testare la porta aperta / chiusa / protetta da firewall.

timeout 1 bash -c '</dev/tcp/127.0.0.1/22 && echo Port is open || echo Port is closed' || echo Connection timeout

Un altro approccio con arricciatura per raggiungere qualsiasi porta

curl telnet://127.0.0.1:22

Ecco una funzione che sceglierà uno dei metodi in base a ciò che è installato sul tuo sistema:

# Check_port <address> <port> 
check_port() {
if [ "$(which nc)" != "" ]; then 
    tool=nc
elif [ "$(which curl)" != "" ]; then
     tool=curl
elif [ "$(which telnet)" != "" ]; then
     tool=telnet
elif [ -e /dev/tcp ]; then
      if [ "$(which gtimeout)" != "" ]; then  
       tool=gtimeout
      elif [ "$(which timeout)" != "" ]; then  
       tool=timeout
      else
       tool=devtcp
      fi
fi
echo "Using $tool to test access to $1:$2"
case $tool in
nc) nc -v -G 5 -z -w2 $1 $2 ;;
curl) curl --connect-timeout 10 http://$1:$2 ;;
telnet) telnet $1 $2 ;;
gtimeout)  gtimeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
timeout)  timeout 1 bash -c "</dev/tcp/${1}/${2} && echo Port is open || echo Port is closed" || echo Connection timeout ;;
devtcp)  </dev/tcp/${1}/${2} && echo Port is open || echo Port is closed ;;
*) echo "no tools available to test $1 port $2";;
esac

}
export check_port

Non dovrebbe essere disponibile sulla confezione, ma prova con nmap.

come riferimento, espandendo la risposta di @peperunas:

il modo di usare nmap per testare è:

nmap -p 22 127.0.0.1

(l'esempio sopra utilizza localhost a scopo dimostrativo)

Se devi testare più che sul sistema, puoi utilizzare il nostro strumento di test dda-serverpec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) per tali attività. Puoi definire le tue aspettative

{:netcat [{:host "mywebserver.com" :port "443"}
          {:host "telnet mywebserver.com" :port "80"}
          {:host "telnet mywebserver.com" :port "8443"}]}

e testare queste aspettative sia su localhost che su host remoti (connettersi tramite ssh). Per i test remoti devi definire un target:

{:existing [{:node-name "test-vm1"
             :node-ip "35.157.19.218"}
            {:node-name "test-vm2"
             :node-ip "18.194.113.138"}]
 :provisioning-user {:login "ubuntu"}}

È possibile eseguire il test con java -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Sotto il cofano stiamo usando Netcat come indicato sopra ...