TCP und UDP sind separate Transportprotokolle, obwohl die Portnummer gleich ist. Das Ergebnis auf der einen Seite zeigt nicht automatisch den Status des Dienstes auf der anderen Seite an.

Grundlegender Ansatz

Der TCP-Verbindungsaufbauprozess erzeugt unterschiedliche Antworten. UDP ist verbindungslos; Ein geöffneter Dienst bleibt möglicherweise stumm, wenn die entsprechende Anwendungsnachricht nicht gesendet wird. Daher reicht in den meisten Fällen keine Antwort in UDP allein nicht aus, um offene, geschlossene und gefilterte Möglichkeiten zu unterscheiden.

Anwendungsschritte

  1. Schreiben Sie das gesteuerte Protokoll mit der Portnummer; Sagen Sie nicht einfach, dass 53 offen ist.
  2. Wählen Sie die dokumentierte Transportmethode des Dienstes aus und prüfen Sie diese nach Möglichkeit auf Anwendungsebene.
  3. Timeout als fehlgeschlagene Verbindung aufzeichnen; Geben Sie ohne ausreichende Beweise kein definitives Off-Label-Produkt ab.

Praxisbeispiel

Während die TCP 53-Verbindung für DNS erfolgreich sein kann, werden UDP-Anfragen möglicherweise gefiltert. Im umgekehrten Fall funktionieren kleine UDP-Anfragen, Transaktionen, die TCP erfordern, schlagen fehl. Hinter derselben Nummer können sich zwei unterschiedliche Zugriffsrichtlinien verbergen.

Interpretieren Sie das Ergebnis richtig

Offener Port gewährleistet nicht den Gerätetyp oder die Softwareversion. Dienste können auf nicht standardmäßigen Ports ausgeführt werden. Durch die Trennung der Portbeobachtung im Inventar von der Serviceantwort und der vom Gerät gemeldeten Identität wird eine Fehlklassifizierung reduziert.

Quelle und Nachlese

Protokoll- oder Befehlsdetails: RFC 768. Die Schritte und das Beispielszenario sind redaktionelle Erzählungen von IPScan.