Będziemy wdrażać nową aplikację na serwerze, a aplikacja będzie nasłuchiwała na porcie 8443. Poprosiliśmy zespół sieci o otwarcie zapory ogniowej dla portu 8443 na tym serwerze przed wdrożeniem aplikacji. Żadna aplikacja aktualnie nie nasłuchuje na tym konkretnym porcie na serwerze.
Czy w każdym razie mogę się upewnić, że zapora jest otwarta dla portu 8443
System operacyjny: Linux / Windows
Odpowiedzi:
Jeśli chcesz sprawdzić, czy możesz nawiązać połączenie TCP ze zdalnego komputera, zainstaluj OpenCSW na tym i na komputerze docelowym i zainstaluj netcat na obu. Oto składnia używania netcata do testowania połączeń TCP:
nc -vz targetServer portNum
Na przykład, aby sprawdzić SSH na „homeServer1”:
nc -vz homeserver1 22
Umożliwia to przetestowanie łączności na poziomie TCP ze zdalnego systemu. Netcat można również skonfigurować tak, aby nasłuchiwał na porcie, a nie działał jako klient. Aby go nasłuchiwał na TCP / 8443:
Na serwerze, na którym będzie przechowywana aplikacja: nc -l homeserver1 8443
Na komputerze, który znajduje się poza zaporą: nc -vz homeserver.fqdn 8443
To jest przykład udanego wykonania:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Nieudane wykonanie:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Zapory ogniowe powinny odpowiadać komunikatem ICMP, gdy blokują żądanie. Jednak niekoniecznie tak jest ( ten ciekawy artykuł zainteresuje Cię ).
Możesz przetestować z zewnątrz, aby sprawdzić, czy port jest dostępny przez zaporę ogniową, a jeśli tak, to czy coś nasłuchuje. Oto trzy różne scenariusze związane z żądaniem TCP, które możesz obserwować za pomocą wiresharkinnego sniffera pakietów, i co zobaczysz:
1) Zapora sieciowa odrzuca żądanie
Otrzymujesz z powrotem wiadomość ICMP, a narzędzie wysyłające żądanie powinno natychmiast powiedzieć ci coś w tym celu („nieosiągalny, zabronione przez administratora” itp.) Przez „narzędzie” rozumiem klienta, którego używasz do wysłania żądania (użyłem telnet). Szczegóły komunikatu 1 zależą od konfiguracji zapory, ale „port nieosiągalny” jest prawdopodobnie najczęstszy.
„Brak trasy do hosta” może to oznaczać, ale może również wskazywać na bardziej subtelne problemy z routingiem.
2) Firewall upuszcza pakiet
Brak odpowiedzi, więc narzędzie czeka, aż upłynie limit czasu lub nudzisz się.
3) Firewall zezwala na pakiet (lub nie ma firewalla), ale na porcie nic nie nasłuchuje.
Otrzymujesz z powrotem komunikat TCP RST / ACK. Zakładam, że wymaga tego protokół TCP. Innymi słowy, jeśli nic nie nasłuchuje na porcie, sam system operacyjny wysyła tę odpowiedź. Odróżnienie tego od numeru 1 może być trudne tylko na podstawie tego, co raportuje narzędzie, ponieważ w obu przypadkach może powiedzieć to samo (najprawdopodobniej jednak odróżnia to jako „odmowę połączenia” od nr 1, „sieć nieosiągalna” ). Scenariusz nr 1 (komunikat odrzucenia ICMP) i nr 3 (komunikat TCP RST / ACK) obserwowane w snifferze pakietów na komputerze klienckim są wyraźnie różne.
Jedyną inną opcją jest przepuszczenie pakietu przez zaporę ogniową i coś nasłuchuje, aby uzyskać udane połączenie.
Innymi słowy: zakładając, że ogólnie sieć działa poprawnie, jeśli uzyskasz numer 1 lub 2, oznacza to, że zapora ogniowa aktywnie uniemożliwia dostęp do portu. # 3 nastąpi, jeśli twój serwer nie działa, ale port jest dostępny, i oczywiście (domyślnie) # 4 to udane połączenie.
Możesz użyć polecenia, netstataby sprawdzić, czy port jest otwarty i nasłuchuje.
$ netstat -anp | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox
tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox
tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh
tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh
Dane wyjściowe pokazują procesy (kolumna najdalej po prawej) , które nasłuchują na portach TCP. Numery portów to liczby następujące po dwukropkach po adresach IP (0.0.0.0:111 to na przykład port 111).
Adresy IP pokazują adresy lokalne i zagraniczne . Lokalny będzie twoim systemem, podczas gdy obcy będzie dowolnym adresem łączącym się z twoim portem TCP lub z jednym z ich portów TCP.
Tak więc w przypadku portu 22 jest to demon ssh działający w moim systemie, to SŁUCHANIE połączeń. Gdy ktoś spróbuje połączyć się z sshdemonem, forsuje kopię siebie i wypycha to połączenie do innego portu, utrzymując port TCP 22 otwarty dla dodatkowych połączeń w miarę ich wchodzenia.
netstat -a -P tcp -f inet | awk '/LISTEN$/ {print $0}'
Konfiguracja i status konfiguracji zapory zależy od zapory / systemu operacyjnego.
Możesz spróbować z server2:
nmap server1
Ostatnio dostałem tę samą prośbę i przyszedłem do wątku. Byłem w stanie przeskanować otwarte porty na FW za pomocą polecenia nc, w ten sposób, gdy sprawdziłem jego dane wyjściowe:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Zasadniczo, jeśli dostanę „limit czasu”, oznacza to, że port nie jest otwarty na FW.
Możesz użyć narzędzia online, takiego jak www.firewallruletest.com, aby sprawdzić, czy zewnętrzne hosty mogą nawiązywać połączenia TCP.
nczgłasza komunikat „Odmowa połączenia”, gdy port jest dostępny, ale nie ma nasłuchiwania, a „Sieć jest nieosiągalna”, gdy żądanie zostało odrzucone przez zaporę ogniową za pośrednictwem icmp (co oznacza, że może lub nie może istnieć usługa na porcie ). Jeśli zapora sieciowa upuści pakiet zamiast go odrzucić,ncpo prostu zawiesi się na chwilę.