Wir werden eine neue Anwendung auf einem Server bereitstellen und die Anwendung wird auf Port 8443 lauschen. Wir haben das Netzwerkteam gebeten, vor der Bereitstellung der Anwendung die Firewall für Port 8443 auf diesem Server zu öffnen. Derzeit lauscht keine Anwendung auf diesem bestimmten Port auf dem Server.
Gibt es eine Möglichkeit, sicherzustellen, dass die Firewall für den Port 8443 geöffnet ist?
Betriebssystem: Linux / Windows
Antwort1
Wenn Sie testen möchten, ob Sie von einem Remote-Rechner aus eine TCP-Verbindung herstellen können, installieren Sie OpenCSW auf diesem und dem Ziel-Rechner und installieren Sie netcat auf beiden. Dies ist die Syntax für die Verwendung von netcat zum Testen von TCP-Verbindungen:
nc -vz targetServer portNum
Um beispielsweise SSH auf „homeServer1“ zu überprüfen:
nc -vz homeserver1 22
Damit können Sie die Konnektivität auf TCP-Ebene vom Remote-System aus testen. Netcat kann auch so konfiguriert werden, dass es auf einem Port lauscht, anstatt als Client zu agieren. So lässt es sich auf TCP/8443 lauschen:
Auf dem Server, auf dem die Anwendung gehostet wird:nc -l homeserver1 8443
Auf einem Computer außerhalb der Firewall:nc -vz homeserver.fqdn 8443
Dies ist ein Beispiel für eine erfolgreiche Ausführung:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded!
Eine fehlgeschlagene Ausführung:
[jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443
nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused
Antwort2
Firewallssollenantworten mit einemICMP-Nachrichtwenn sie eine Anfrage blockieren. Dies ist jedoch nicht unbedingt der Fall (Sie werden interessiert seindieser schöne Artikel).
Sie können von außen testen, ob ein Port durch eine Firewall erreichbar ist und ob, wenn ja, irgendetwas darauf lauscht. Hier sind drei verschiedene Szenarien mit einer TCP-Anforderung, die Sie mit wiresharkoder einem anderen Paket-Sniffer beobachten können, und was Sie sehen werden:
1) Firewall lehnt Anfrage ab
Sie erhalten eine ICMP-Nachricht zurück und das Tool, das die Anfrage sendet, sollte Ihnen sofort etwas in dieser Art mitteilen („nicht erreichbar, Administrator gesperrt“ usw.). Mit „Tool“ meine ich den Client, den Sie zum Senden der Anfrage verwenden (ich habe verwendet telnet). Die Einzelheiten der Nachricht 1 hängen von der Konfiguration der Firewall ab, aber „Port nicht erreichbar“ ist wahrscheinlich die häufigste.
Dies könnte durch die Meldung „Keine Route zum Host“ angezeigt werden, es kann sich aber auch um subtilere Routing-Probleme handeln.
2) Firewall verwirft Paket
Es gibt keine Antwort, also wartet das Tool, bis die Zeit abläuft oder Ihnen langweilig wird.
3) Die Firewall lässt Pakete zu (oder es ist keine Firewall vorhanden), aber auf dem Port wird nichts abgehört.
Sie erhalten eine TCP RST/ACK-Nachricht zurück. Ich gehe davon aus, dass das TCP-Protokoll dies erfordert. Mit anderen Worten, wenn nichts auf dem Port lauscht, sendet das Betriebssystem selbst diese Antwort. Es kann schwierig sein, dies von #1 nur anhand dessen zu unterscheiden, was ein Tool meldet, denn esMaisagen in beiden Fällen dasselbe (die meisten unterscheiden jedoch wahrscheinlich zwischen „Verbindung abgelehnt“ und Nr. 1 „Netzwerk nicht erreichbar“). In einem Paket-Sniffer auf dem Client-Rechner beobachtet, sind Szenario Nr. 1 (ICMP-Ablehnungsnachricht) und Nr. 3 (TCP RST/ACK-Nachricht) klar verschieden.
Die einzige andere Möglichkeit besteht darin, dass das Paket von der Firewall durchgelassen wird und etwas zuhört, sodass Sie eine erfolgreiche Verbindung erhalten.
Mit anderen Worten: Vorausgesetzt, Ihr Netzwerk funktioniert im Allgemeinen einwandfrei, bedeutet dies bei Nr. 1 oder Nr. 2, dass eine Firewall den Zugriff auf den Port aktiv verhindert. Nr. 3 tritt ein, wenn Ihr Server nicht läuft, der Port aber erreichbar ist, und (das implizite) Nr. 4 bedeutet natürlich, dass die Verbindung erfolgreich hergestellt wurde.
- Z. B. "Port nicht erreichbar", "Host verboten", verschiedene andere Kombinationen vonHost/Port/AdministratorUndnicht erreichbar/verboten; suchen Sie in der Nachricht nach diesen, da sie ein eindeutiger Hinweis auf eine aktive IP-Firewall sind.
Antwort3
Mit dem Befehl können Sie netstatfeststellen, ob ein Port geöffnet ist und lauscht.
Beispiel
$ 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
Die Ausgabe zeigt Prozesse(Spalte ganz rechts)die auf TCP-Ports lauschen. Die Portnummern sind die Zahlen, die den Doppelpunkten nach den IP-Adressen folgen (0.0.0.0:111 wäre beispielsweise Port 111).
Die IP-Adressen zeigenLokalUndAusländische Adressen.Lokalwäre Ihr System währendAusländischwären alle Adressen, die entweder eine Verbindung zu Ihrem TCP-Port herstellen oder Sie eine Verbindung zu einem ihrer TCP-Ports herstellen.
Im Fall von Port 22 ist das der SSH-Daemon, der auf meinem System läuft.HÖRENfür Verbindungen. Sobald jemand versucht, eine Verbindung zum sshDaemon herzustellen, erstellt er eine Kopie von sich selbst und verschiebt diese Verbindung auf einen anderen Port, wobei TCP-Port 22 für weitere eingehende Verbindungen geöffnet bleibt.
Antwort4
Kürzlich erhielt ich dieselbe Anfrage und stieß auf diesen Thread. Ich konnte offene Ports auf der FW mit dem Befehl nc scannen, und zwar so, wie ich seine Ausgabe abfrage:
nc -v -w 1 -z -s *srcIP destIP port* 2>&1 | grep timed > /dev/null && echo closed || echo open
Wenn die Meldung „Timeout“ angezeigt wird, bedeutet das grundsätzlich, dass der Port auf der FW nicht geöffnet ist.