nmap zeigt closed Ports am WAN - wie kommt das zustande?

Rico

Ohne zu wissen wie genau du gescannt hast lässt sich die Frage so oder so nicht beantworten.

-Rico

slu

Sorry, eigentlich wollte ich das mit in den ersten Beitrag schreiben und hab es vergessen:

nmap FQDN
Starting Nmap 7.70 ( https://nmap.org ) at 2020-10-25 23:04 CET
Nmap scan report for FQDN (XXX.XX.XX.XXX)
Host is up (0.043s latency).
rDNS record for XXX.XX.XX.XXX: xxxxxxx.dip0.t-ipconnect.de
Not shown: 997 filtered ports
PORT     STATE  SERVICE
443/tcp  open   https
5060/tcp closed sip
5061/tcp closed sip-tls

Nmap done: 1 IP address (1 host up) scanned in 4.44 seconds

Ich hab nmap nur mit der FQDN ohne extra Parameter aufgerufen.

Bob.Dig

@slu Vielleicht UPnP?

slu

Kann ich ausschließen, zumindest ist es auf der pfSense komplett deaktiviert.

JeGr

War der nmap als root oder normaler User? Das ändert das Verhalten.

Für root ist der Default dann nmap -sS während es für normale User nmap -sT ist, sofern sich da in den Versionen nix getan hat. Das eine ist ein half-open scan, das andere ein TCP connect scan, die beide anders ablaufen und unterschiedliche Ergebnisse liefern können.

Zudem scannt man ohne zusätzliche Eingabe nur die Top 1000 Ports der NMAP Liste. Wenn also bestimmte Ports nicht auftauchen, dann kann das auch schlicht dran liegen, dass du sie nicht gescannt hast weil sie in der Liste nicht enthalten waren.

Zuletzt kommts auf den Scantyp (oben) an, was für Ergebnisse du hast, genauso wie auf dein Standardverhalten was die Firewall extern macht. Bei Block any wird keine Antwort geschickt. Kein Reset etc. Bei Reject schon. Die Antwort hängt also auch von deinen Regeln aufm WAN und den Diensten ab.

slu

@JeGr said in nmap zeigt closed Ports am WAN - wie kommt das zustande?:

War der nmap als root oder normaler User? Das ändert das Verhalten.

Ich hab beide versucht und zusätzlich als root noch einmal mit der Option -sS und einmal mit -sT, das Ergebnis ist immer das selbe.

Zudem scannt man ohne zusätzliche Eingabe nur die Top 1000 Ports der NMAP Liste. Wenn also bestimmte Ports nicht auftauchen, dann kann das auch schlicht dran liegen, dass du sie nicht gescannt hast weil sie in der Liste nicht enthalten waren.

Das ist soweit klar und ein wichtiger Hinweis. Für mich unklar ist weshalb 5060/5061 "closed" sind, irgendwas muss ja das TCP Paket beantwortet haben.

Zuletzt kommts auf den Scantyp (oben) an, was für Ergebnisse du hast, genauso wie auf dein Standardverhalten was die Firewall extern macht. Bei Block any wird keine Antwort geschickt. Kein Reset etc. Bei Reject schon. Die Antwort hängt also auch von deinen Regeln aufm WAN und den Diensten ab.

Am WAN Interface gibt es keine Regel für 5060/5061.
Auf Block steht "RFC 1918 networks" und "Reserved Not assigned by IANA".

Was wir natürlich haben ist ein Asterisk der hinter der pfSense läuft, der muss ja irgendwie von außen erreichbar sein und hält damit die TCP Verbindung offen. Wäre das nicht die Erklärung warum das "closed" kommt?

Allerdings kann ich mir dann wieder nicht erklären weshalb ich das Verhalten auf beiden VDSL Anschlüssen habe (es ist ein Failover konfiguriert, der Asterisk sollte damit immer nur über die primäre Leitung raus gehen).

Wird für mich noch etwas spannend, würde der Sache aber gerne auf den Grund gehen.

JeGr

@slu said in nmap zeigt closed Ports am WAN - wie kommt das zustande?:

Das ist soweit klar und ein wichtiger Hinweis. Für mich unklar ist weshalb 5060/5061 "closed" sind, irgendwas muss ja das TCP Paket beantwortet haben.

Nein muss es nicht. Das ist genau das, was die NMAP Dokumentation sagt, dass es eben manche Dinge als false positive "vermutet" eben weil KEIN Paket zurückkommt. Normaler Host der ein Paket für einen closed Port bekommt - sendet Reset der Verbindung weil da gibbet nichts. Block any Regel -> sendet nichts. NMap vermutet weil NICHTS zurückkommt, dass der port gefiltert oder closed ist, weil nichts zurückkommt.

Aber völlig egal: ob filtered, closed oder gar nicht auftauchend - zu ist zu ;)

Was wir natürlich haben ist ein Asterisk der hinter der pfSense läuft, der muss ja irgendwie von außen erreichbar sein und hält damit die TCP Verbindung offen. Wäre das nicht die Erklärung warum das "closed" kommt?

Wenn dem so wäre, würde ich im Strahl kotzen. Das würde nämlich bedeuten, dass ein XY-Scanner von Timbuktu West laufend plötzlich weiß, dass bei mir ein VoIP Gerät SIP spricht, obwohl er KEINE Antwort bekommt. Wenn ihr auf dem WAN KEINE Portweiterleitung für 5060/5061 habt die von ANY aus frei ist, dann kann kein Gerät von außen einfach sagen "ach ja der Port ist offen, weil was von INNEN nach außen geht". Wenn dem so wäre könnten wir alle Firewalls einpacken. Das wäre Information Leakage hoch 9000.
Der EINZIGE der sowas sagen kann, wäre dein ISP der DIREKT deine Leitung angrabbelt und via tcpdump o.ä. deinen abgehenden Traffic sieht. Aber wenn irgendeine Dubios-IP von außen einfach via nmap sagen könnte "ey da läuft SIP" schule ich auf Gartenbau um und geh Bäume fällen. ;)

Bob.Dig

Möglicherweise gibt es ja doch eine Freigabe, vielleicht unter NAT 1:1.

slu

@JeGr said in nmap zeigt closed Ports am WAN - wie kommt das zustande?:

Nein muss es nicht. Das ist genau das, was die NMAP Dokumentation sagt, dass es eben manche Dinge als false positive "vermutet" eben weil KEIN Paket zurückkommt. Normaler Host der ein Paket für einen closed Port bekommt - sendet Reset der Verbindung weil da gibbet nichts. Block any Regel -> sendet nichts. NMap vermutet weil NICHTS zurückkommt, dass der port gefiltert oder closed ist, weil nichts zurückkommt.

Aber völlig egal: ob filtered, closed oder gar nicht auftauchend - zu ist zu ;)

Du trifft es auf den Punkt, jetzt ist der Knoten in meinem Kopf beseitigt

Um jetzt noch ein schönes Ergebnis mit nmap zu bekommen gibt man einfach --open als Option mit

slu

@Bob-Dig said in nmap zeigt closed Ports am WAN - wie kommt das zustande?:

Möglicherweise gibt es ja doch eine Freigabe, vielleicht unter NAT 1:1.

Kann ich ausschließen, des Rätsels Lösung ist tatsächlich die Annahme von nmap das Ports geschlossen sind.