Welche Ports verwendet Postgres hinter ner Firewall tatsächlich

Um des Friedens willens, hier noch mal, was der Fragesteller wollte:

Ich beabsichtige, für einen Kunden einen richtig dicken Postgres-Server mit entsprechender Bandbreite angebunden übers Internet bereitzustellen.

Du kannst davon ausgehen, das interne Rechtevergaben auf interne Server etc. des Kunden in diesem Szenario exakt belanglos sind, solange die Clients den Server auf Protokoll TCP Zielport des Servers 5432 erreichen und Antworten von diesem Server wieder den Client erreichen. Es reicht also Routing, zumindest für den im Internet stehenden Server, wahrscheinlich mit NAT. Ob die Admins des Kunden das Routing für nur diesen einen Server und nur für TCP/5432 beschränken, ist deren Problem.

Und ja, dazu müssen auf den Clients exakt keine Ports offen sein. Von daher sind aus Sprüche wie “es werden also mehr Ports beteiligt sein. Irgendwie müssen die Clients ja auf den Server kommen…” Unsinn. Genauso Unsinn wie “Ein WINDOWS - Client, der auf keinem Port lauscht, startet vermutlich gar nicht, weil das OS “Dicke Backen” macht.”, weil dies z.B. Default von Windows98 ist oder auch von XP, wenn man sich an NT-Dienste sicher konfigurieren und abschalten (Windows 2000/XP) - www.ntsvcfg.de hält.


Andreas, 3. Advent wünschend.

Ich habe auch kein gesteigerters Interesse daran, eine abgeschlossene Diskussion sinnlos zu verlängern. Allerdings hatte ich angenommen, dass eine derartige Fragestellung durchaus noch mal aufkommen könnte und wollte lediglich auf die Probleme in einem Kundennetzwerk hinweisen, die einem DB - Entwickler ja nicht immer sofort bekannt sein müssen.

Und herzlichen Dank für die Mühe - der Link war tatsächlich interessant.

Im Gegenzug eine hoffentlich ebenso interessante Information: das letzte OS von MS, welches die C4 - Kriterien der US - Streitkräfte (und in der Folge auch der NATO) für “Secure High” erhielt, war NT 4.0 (soweit mir bekannt mit SP 3 und höher). Allerdings auch nur für den Client und nicht im Netzwerk.

In größeren Netzwerken ist es üblich, eine zentrale Administration vorzuhalten - die könnte ohne offene Ports auf den Clients gar nicht funktionieren. Zudem wird in solchen Netzwerken gerne eine zentrale Rechteverwaltung vorgenommen - auch die funktioniert nicht, wenn der Client keine offenen Ports hat.

Zentrale Software - Verteilung / Updateverwaltung, Remote Control zur Fehlerbehebung durch einen Admin: alles ohne offene Ports im INTERNEN NETZ nicht zu machen. Der Einsatz von “mobile (moving) Clients” verschärft diese Probleme noch, wenn selbige Zugriff auf Daten im Firmennetzwerk brauchen. Wie ich aus den Beiträgen ntnehmen konnte, hält die betreffende Firma nichts von einem VPN in einer DMZ.

Was ist mit einem 3 - Tier - Modell? Das der Port der DB gebraucht wird, ist klar. Das ODBC genutzt wird, ist auch schon eine hilfreiche Angabe. Damit ist aber immer noch nicht geklärt, welches Frontend auf dem Client läuft…

Wichtig ist, wenn sich der DB - Entwickler um diese Dinge nicht zu kümmern braucht, gut für ihn.

Das hatte ich aber auch deutlich geschrieben.

Der Nächste muss sich aber möglicherweise damit befassen, zumindest bis zum Applikationserver. Da wollte ich einfach nur jetzt schon Informationen zu anbieten. Mehr nicht.

Von mir aus können wir diesen Dialog hier beenden. Ich werde mich in Zukunft präziser Ausdrücken, um solche Mißverständnisse gar nicht erst aufkommen zu lassen.

Okay?

Ebenfalls schönen dritten Advent.

Grüße
W.K.

Na sicher.

Btw.: Du scheint Ahnung von Kerberos zu haben. Da hat jemand anders eine Frage zu…

Andreas.

Ich will ja jetzt keine Panik aufkommen lassen…

Aber aus ganz anderem Grund habe ich meine private Umgebung heute mal untersucht.

Linux 10.1 mit VMware 5.5 in dem als Gast ein XP - Home läuft.

Da bin ich mal mit “netstat -a -b” heran gegangen. Ergebnis: angeblich “horcht” die Postgre auch auf den Port 1029/UDP.

Keine Ahnung, ob darüber auch informationsaustauch läuft - ich wollte es nur erwähnt haben.

Grüße
W.K.

Leute, leute, hätte nie gedacht, dass mein Thread nochmal derart explodieren könnte …

Aber habt euch doch a bisslerl lieb, is doch bald Weihnachten :wink:

ZU deiner letzten Anmerkung, w.k.

Trotzdem vielen Dank für den Hinweis, besorgt bin ich allerdings noch nicht, mein netstat hatte ich davor schon gecheckt, listet brav nur die konfigurierten Ports …

Vielleicht liegts am Testumfeld, ich bevorzuge pure linux-Server (Debian) ohne VMware-Krimskrams …


Grüße

Jochen

Ich habe mir heute mal zweck´s der Gaudi das auf einem MacBook (mit Leopard) angeschaut: da werden die Anfragen an die pg lustigerweise auf Ports in einem Bereich über 45000 gemappt…

Zumindest, wenn mehr als eine gestartet wird.

Wie MS das regelt, dass laut netstat brav alle am 5432 lauschen, ist mir ohnehin ein Rätsel.

Aber vielleicht verstehe ich das System ja nur nicht…

Grüße
W.K.

Hmm, für Anfragen an die DB wäre ein Source-Port von wasweissich 45000 schon ok, nur der Destination-port sollte besser 5432 sein.

Aber ich denke dem ist auch so. Oder es liegt an einem der vielen kleinen klickibunti administrationsfrontends (nur n Scherz, ich mag auch macs, solange ich sie nicht anschalten muss) :wink:

Dankdir

jochen

Möglich. Vielleicht hilft Dir folgender Gedankengang:

  • das grundlegende ist erst einmal IP, das _I_nternet _P_rotokoll
  • dieses kennt Sub-Protokolle, z.B. UDP mit der Protokollnummer 17, ICMP mit Protokllnummer 1 oder TCP mit der Protokollnummer 6. Eine Liste dieser Nummern und Protokolle liefert Dir übrigend ein ‘cat /etc/protocols’, Nutzer alternativer Systeme finden das auch auf den Seiten der IANA unter Protocol Numbers
  • PostgreSQL nutzt TCP, also Protokoll 6. Dieses wiederum nutzt Ports. Davon gibt es jede Menge, so ca. 65.000
    Und zwar sowohl einen als Ziel als auch einen als Quelle.
  • Damit hat ein IP-Datenpaket, welches PostgreSQL nutzt, 5 Merkmale: Protokol 6, Sourceadresse, Destinationadresse, Sourceport, Destinationport.
  • damit ein Client einen Server finden und sich mit ihm verbinden kann, muß es also wissen: Protokoll 6, Ziel-IP, Zielport 5432. Damit der Server darauf antworten kann, gibt der Client natürlich auch noch seine eigene Adresse mit.
    Nicht erwähnt bis jetzt ist der Sourceport. Damit hat der Clientrechner die Chance, mehrere Verbindungen zu einem Server aufzubauen. Das OS vergibt dynamisch jedem startendem Client, welches sich mit dem Server verbindet, einen Sorceport. Diese Dinge stehen nun alle in so einem Datenpaket, und damit ist eine Client-Server-Verbindung exakt definiert. Der TCP/IP-Stack des Servers kann so alles korrekt zuordnen.

Das macht nicht nur PG so, sondern z.B. jeder Browser, jeder Mailclient bei POP oder IMAP, Telnet, SSH und so weiter. Und das ist so bei *NIX und auf Kleinweich und auf IP sprechenden Spielkonsolen. TCP-Serverdienste haben immer als Destinationport einen fixen und als Sourceport einen vom jeweiligen OS vergebenen Port. Hier unterscheiden sich die OS z.T. bei der Vergabe.

Erwähnte ich das Buch von Stevens schon einmal? Nennt sich ‘TCP/IP Illustrated’. Lesenswert, wenn man das System TCP/IP verstehen will.


Andreas