Sprawdź, czy port w systemie zdalnym jest osiągalny (bez telnet)

W dawnych czasach telnetsprawdzaliśmy, czy port na zdalnym hoście był otwarty: telnet hostname portpróbował połączyć się z dowolnym portem na dowolnym hoście i dać ci dostęp do surowego strumienia TCP.

Obecnie w systemach, na których pracuję, nie ma zainstalowanego Telnet (ze względów bezpieczeństwa), a wszystkie połączenia wychodzące do wszystkich hostów są domyślnie blokowane. Z czasem łatwo stracić orientację, które porty są otwarte dla których hostów.

Czy istnieje inny sposób sprawdzenia, czy port w systemie zdalnym jest otwarty - przy użyciu systemu Linux z zainstalowaną ograniczoną liczbą pakietów i telnetnie jest dostępny?

Bash od dłuższego czasu ma dostęp do portów TCP i UDP . Ze strony podręcznika:

/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.

Możesz więc użyć czegoś takiego:

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

Taa Daa!

Miły i pełny! Ze stron podręcznika.
Pojedynczy port:

nc -zv 127.0.0.1 80

Wiele portów:

nc -zv 127.0.0.1 22 80 8080

Zakres portów:

nc -zv 127.0.0.1 20-30

Netcat to przydatne narzędzie:

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

Wyjdzie, 0jeśli port 123 jest otwarty i 1jeśli jest zamknięty.

Najprostsza metoda bez użycia innego narzędzia, takiego jak socat, jest opisana w powyższej odpowiedzi @ lornix. To po prostu dodać faktyczny przykład wykorzystania urządzenia psuedo /dev/tcp/...w Bash, jeśli chcesz, powiedzmy, przetestować, czy inny serwer ma dany port dostępny za pośrednictwem wiersza poleceń.

Przykłady

Powiedz, że mam hosta w mojej sieci o nazwie 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

Powodem, dla którego chcesz zawijać echo > /dev/...nawiasy w ten sposób, (echo > /dev/...)jest to, że jeśli tego nie zrobisz, to przy testach połączeń, które nie działają, pojawią się tego rodzaju wiadomości.

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

Nie można ich po prostu przekierować, /dev/nullponieważ pochodzą one z próby zapisania danych na urządzeniu /dev/tcp. Przechwytujemy więc wszystkie dane wyjściowe w ramach podrzędnego polecenia, tj. (...cmds...)I przekierowujemy dane wyjściowe tego polecenia.

Odkryłem, że curlmoże to zrobić zadanie w podobny sposób telnet, a curlnawet powie ci, jakiego protokołu oczekuje słuchacz.

Skonstruuj identyfikator URI HTTP z nazwy hosta i portu jako pierwszy argument curl. Jeśli curlmożna się połączyć, zgłosi niezgodność protokołu i zakończy działanie (jeśli nasłuchiwanie nie jest usługą internetową). Jeśli curlnie można się połączyć, upłynie limit czasu.

Na przykład port 5672 na hoście 10.0.0.99 jest zamknięty lub zablokowany przez zaporę:

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

Jednak z innego systemu można uzyskać dostęp do portu 5672 na hoście 10.0.0.99 i wydaje się, że działa on jako detektor AMQP.

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

Ważne jest, aby rozróżniać różne komunikaty: pierwsza awaria była spowodowana brakiem curlpołączenia z portem. Druga porażka to test powodzenia, choć curloczekiwany jest odbiornik HTTP zamiast odbiornika 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!

Mam nadzieję, że to rozwiąże twój problem :)

Oto jedna linijka:

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

przy użyciu składni Bash wyjaśnionej w odpowiedzi @lornix .

Aby uzyskać więcej informacji, sprawdź: Advanced Bash-Scripting Guide: Rozdział 29. /devi/proc .

Walczyłem cały dzień, ponieważ żadna z tych odpowiedzi nie działała dla mnie. Problem polega na tym, że najnowsza wersja ncnie ma już -zflagi, podczas gdy bezpośredni dostęp przez TCP (zgodnie z @lornix i @slm) nie działa, gdy host jest nieosiągalny. W końcu znalazłem tę stronę , na której w końcu znalazłem nie jeden, ale dwa działające przykłady:

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

   ( -wflaga ustala limit czasu i </dev/nullzastępuje -zflagę)

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

   ( timeoutpolecenie zajmuje limit czasu, a reszta pochodzi z @slm)

Następnie po prostu użyj &&i / lub ||(lub nawet $?), aby wyodrębnić wynik. Mam nadzieję, że ktoś uzna te informacje za przydatne.

Łącząc odpowiedzi z @kenorb i @Azukikuru, możesz przetestować port otwarty / zamknięty / firewalled.

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

Inne podejście z zawinięciem do osiągnięcia dowolnego portu

curl telnet://127.0.0.1:22

Oto funkcja, która wybierze jedną z metod w zależności od tego, co jest zainstalowane w systemie:

# 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

Nie powinno być dostępne na twoim pudełku, ale spróbuj nmap.

dla odniesienia, rozwijając odpowiedź @peperunas:

sposobem użycia nmap do testowania jest:

nmap -p 22 127.0.0.1

(powyższy przykład używa localhost do celów demonstracyjnych)

Jeśli chcesz przetestować więcej niż na systemie, możesz użyć naszego narzędzia testowego dda-serverspec ( https://github.com/DomainDrivenArchitecture/dda-serverspec-crate ) do takich zadań. Możesz określić swoje oczekiwania

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

i przetestuj te oczekiwania na hoście lokalnym lub na hoście zdalnym (połącz przez ssh). W przypadku testów zdalnych musisz zdefiniować cele:

{: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"}}

Możesz uruchomić test z java -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Pod maską używamy netcata tak jak wyżej ...