Welche Ports verwendet Postgres hinter ner Firewall tatsächlich

Hallo Leute,
ich scanne das internet schon ne ganze Weile nach einem ansich recht trivialen Problem (wie ich dachte).

Ich beabsichtige, für einen Kunden einen richtig dicken Postgres-Server mit entsprechender Bandbreite angebunden übers Internet bereitzustellen. Der Zugriff erfolgt von Windows-PC’s aus über postgres win32 odbc Treiber.

Damit die Mitarbeiter auch auf den Server zugreifen können, bin ich nun gehalten, den Firewall-Administratoren eine Spezifikation zur erforderlichen Konfiguration an die Hand zu geben.

Nachdem deren Firewalling an Fort Knox erinnert (kein einziger offener Port vom Mitarbeiter-Arbeitsplatz), und sie neben circuit-firewalling auch firewalling auf application-level betrieben, bin ich etwas unsicher… :frowning:

Und nun meine Frage:
Ist euch bekannt, ob der port 5432 (in and out) für die Kommunikation mit einem Postgresql-server absolut ausreicht oder verwendet Postgres weitere Ports die z.B. Daten zum client zurückführen, zb. für Query-Results, slave-connections, etc etc oder so… die gesondert freigegeben werden müssen.

Vielen Dank im Voraus


Jochen

5432/TCP reicht aus. Ich würde dies aber nicht ohne Grund im Internet prostituieren, VPN-Lösungen existieren. Und ein SSH-Tunnel ist die einfachste VPN-Lösung in diesem Falle. Das bei den Clients offensichtlich NAT im Spiel ist, ist Dir aber klar, oder?

Andreas

Hallo Andreas,
erstmal danke für Deine schnelle Antwort!

5432/TCP reicht aus.

Tausend Dank, das wars, was ich gehofft hatte :slight_smile:

Ich würde dies aber nicht ohne Grund im Internet prostituieren, VPN-Lösungen existieren.

Ja, absolut deiner Meinung, ist allerdings bei deren Infrastruktur nicht ohne weiteres umsetzbar, alleine in Deutschland haben die was um die 50 Standorte mit jeweils einem Internet-Gateway (und entsprechender Firewall). 50 Abteilungen davon zu überzeugen, ein VPN einzurichten würde zu lange dauern, der Server soll im Januar in produktion gehen :wink:
Datenbank-Serverseitig wird nur Traffic von von deren Gateways akzeptiert werden, das geppart mit SSL-Verschlüsselung sollte fürs erste mal reichen.

VPN’s kommen vielleicht später ins Spiel.

Und ein SSH-Tunnel ist die einfachste VPN-Lösung in diesem Falle.

Yo, damit besteht aber das gleiche Problem wie bei nem klassischen VPN, nicht darstellbar derzeit.

Das bei den Clients offensichtlich NAT im Spiel ist, ist Dir aber klar, oder?

Klar wird da NAT im Spiel sein, siehst du darin ein Problem?


Vielen Dank


Jochen

5432 sollte vollkommen ausreichen, PostgreSQL selber lauscht auch an keinem anderen Port … so du dann auch wirklich 5432 konfiguriert hast :wink:

Das NAT sollte kein Problem darstellen, solange die Mitarbeiter nicht mal länger eine Datenbank Shell offen lassen als NAT seinen Timeout hat.

Nun ja.

Die Clients hier in der Firma z.B. haben kein NAT nach außen. Zum Pornoseitenbrausen g gibt es einen Proxy, für Mail einen internen Mailserver, der das dann macht. Ansonsten gibt es kein Routing von Clients (mein Rechner ausgenommen) nach außen. Das hat den Charme, daß, falls doch mal sich so ein Windoze was einfängt (was es in meiner Niederlassung noch nicht gab…), dieser dann nach außen keinen Schaden anrichtet. (es sei denn via dem Proxy). Außerdem kann keiner Dinge tun, die er nicht für die Arbeit braucht. Ich sag nur Tauschbörsen.

Will sagen: einerseits eine Konfiguration, wo Clients direkten Weg ins Internet haben und andererseits ‘Firewalls’.


Andreas

Hallo Andreas,
danke für deine Antwort, jetzt bin ich verwirrt :wink:

Das bei den Clients offensichtlich NAT im Spiel ist, ist Dir aber klar, oder?



Klar wird da NAT im Spiel sein, siehst du darin ein Problem?



Die Clients hier in der Firma z.B. haben kein NAT nach außen. Zum Pornoseitenbrausen g gibt es einen Proxy, für Mail einen internen Mailserver, der das dann macht. Ansonsten gibt es kein Routing von Clients (mein Rechner ausgenommen) nach außen.

g Das entspricht ungefähr auch dem beschriebenen Szenario. Allerdings bin ich mir nicht recht sicher, ob ich Dich richtig verstehe, was den ‘direkten’ von Clients Zugang ins Netz angeht.

Der übliche Weg (und den werden auch die Pakete zu meinem Datenbankserver gehen) sollte doch in deinem Netzwerkumfeld ebenso wie bei denen wiefolgt aussehen:

Client-> default internal Gateway -> ggf. weitere internal Gateways -> Firewall -> Internet -> Firewall von Datenbankserver -> Gateway von Datenbankserver-> Datenbankserver -> und wieder zurück

Das NAT übernimmt in jedem Fall doch deine (oder deren) Firewall, oder? Und da kannst Du doch dann fein einstellen, auf welche IP du welchen Port zulassen möchtest, oder?

Vielleicht tut sich grade eine Wissenslücke bei mir auf, aber über NAT, daher auch meine nochmalige Nachfrage, habe ich mir nie große Gedanken gemacht …

Was für Probleme kann es damit geben, ausser vielleicht, dass es kein NAT gibt (wovon nicht auszugehen sein dürfte)


Danke im Vorraus

Jochen

Danke ads,
schon wieder was neues gelernt.

Das NAT sollte kein Problem darstellen, solange die Mitarbeiter nicht mal länger eine Datenbank Shell offen lassen als NAT seinen Timeout hat.

hmm, NAT timeoout klingt unschön.

Hast Du auch ne Idee, wo dieser Timeout so ungefähr liegt? … und was man dagegen unternehmen könnte? … muss man denn gegen diesen Timeout überhaupt etwas unternehmen? … und ob man den in einem hinreichend aufmunitionierten Systemunfeld irgendwo einstellen kann?

Mein infantiles Gemüt versucht mich grade dahingehend zu beruhigen, dass der Timeout garantiert nicht zwischen query und rückgabe der Ergebnisse auftreten wird, sondern wenn überhaupt irgendwann zwischen zwei queries, weil die faulen Mitarbeiter tatsächlich ne Mittagspause machen :wink:

Falls der Postgres-ODBC-Client vor jeder query einen neuen connect durchführt, sollte dies unschädlich sein …

Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss … ?

zum thema

5432 sollte vollkommen ausreichen, PostgreSQL selber lauscht auch an keinem anderen Port … so du dann auch wirklich 5432 konfiguriert hast :wink:

Es wird nicht der Port 5432 werden, eher vielleicht der Port 54213 oder so. Denke, wenn der dann auch fein administriert wurde :slight_smile: dürfts egal sein, oder?

Danke im Voraus


Jochen

Sicher, wenn das sauber gemacht ist ist das alles kein Problem. In der Realität hatte ich mal das Vergnügen mit einer Firma, die ein nicht kleines Client-Netz hatten, von denen einer oder einige wenige verseucht waren. Da kamen hunderte Viren in kurzer Zeit her. Da dort alle Clients ungehindert NAT hatten, hatten die ein Problem. Und nach einem Tag oder so bat ich dann deren Provider, die abzuklemmen. Und dann war Ruhe. Schließlich sehe ich nicht ein, unsere Bandbreite als Lehrgeld für deren Blödheit zu opfern.

Also, ich hab nix gegen NAT, wenn es gebraucht wird. Deren EDV-Sicherheit scheint ja auch nicht Dein Problem zu sein, oder?

Andreas

Also zwischen Query und Ergebnis tritt der höchstens auf, wenn der Query paar Minuten braucht :wink:
Irgendwo in /proc kann man das auch konfigurieren, aber ich weiss nicht mehr, wo. Das habe ich das letzte Mal für 2.4 Linux Kernel gemacht und seitdem hat sich einiges getan.


Mein infantiles Gemüt versucht mich grade dahingehend zu beruhigen, dass der Timeout garantiert nicht zwischen query und rückgabe der Ergebnisse auftreten wird, sondern wenn überhaupt irgendwann zwischen zwei queries, weil die faulen Mitarbeiter tatsächlich ne Mittagspause machen > :wink: >

Da kann ich dir zustimmen :wink:


Falls der Postgres-ODBC-Client vor jeder query einen neuen connect durchführt, sollte dies unschädlich sein …

Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss … ?

Ja, die Verbindung ist danach tot und muss neu aufgebaut werden. Alle Änderungen, die nicht committed sind, werden von PostgreSQL automatisch zurückgerollt.


Es wird nicht der Port 5432 werden, eher vielleicht der Port 54213 oder so. Denke, wenn der dann auch fein administriert wurde > :slight_smile: > dürfts egal sein, oder?

Sollte kein Problem darstellen.

Hi ads,

Oder könnte dein Kommentar gar bedeuten, dass Du davon ausgehst (erlebt hast), dass mit dem timeout-ereignis auch die gesamte odbc-verbindung abgebrochen wird und neu initialisiert werden muss … ?



Ja, die Verbindung ist danach tot und muss neu aufgebaut werden. Alle Änderungen, die nicht committed sind, werden von PostgreSQL automatisch zurückgerollt.

na das sind mal richtig schlechte nachrichten :angry:

Hast Du auch ne Lösung für das Problem gefunden? Regelmäßige pseudoqueries auf den server wäre das einzige, was mir dazu aus dem stehgreif einfällt …

was meinst du?

Danke

Jochen

Für die Commits? Wenn du eine Transaktion 15 Minuten (das war früher der Timeout) offen hälst, hast du sowieso das Problem, das deine Änderungen andere Transaktionen für 15 Minuten blockieren. Solange du bloss offene Transaktionen ohne Änderungen hast, ist das kein Problem.

Hi Andreas,

Deren EDV-Sicherheit scheint ja auch nicht Dein Problem zu sein, oder?

Genau so isses:-)

Ich danke dir sehr für deine Hiilfe

Hi ads,

Wenn du eine Transaktion 15 Minuten (das war früher der Timeout) offen hälst, hast du sowieso das Problem

yo, ein verdammt großes sogar :wink: Nö, ich halte keine Transaktionen über 15 minuten offen, sowas mach ich nicht, das meinte ich aber auch nicht.

Ich dachte eher an Methoden zur Verhinderung des Abbruchs der ODBC-Verbindung …


Grüße Jochen

Ich bin ganz und gar nicht davon Überzeugt, dass so das grundlegende Problem gelöst werden kann…

Die betreiben ihren Aufwand bestimmt nicht, um Sessions zu betreiben, die regelmäßig mit pseudo - querys zur Analyse einladen.

Das sehe ich irgendwo auch nicht als Problem des Betreibens einer Datenbank an.

Daher stellt sich mir die Frage, ob es wirklich darum geht, eine Datenbank ständig online zu halten und über das Internet - wenn ich das richtig sehe, ohne “Tunnel” - ständig verfügbar zu haben.

Den Timeout können die Admins in der Firma natürlich leicht hochsetzen - es geht ja nicht nur um die pg, auch z. B. eine Firewall kann so eingestellt sein, dass nach x-zeit ohne Nutzeraktivität die Verbindung abgebaut wird. Von aktiven Komponenten im Netz ganz zu schweigen - auch die können so konfiguriert sein, dass die Session ohne Aktivität abgebaut wird. Der Client kann zusätzlich nicht nur nach 10 Minuten den Bildschirmschoner starten, sondern auch nach x-zeit ohne Nutzeraktivität dem Server mitteilen, dass er nicht mehr gebraucht wird…

Geht aus der Beschreibung nicht wirklich hervor.

Ohnehin wäre zu prüfen, ob ein anderer Ansatz nicht sinnvoller wäre: die Applikation auf dem Client startet einen Agenten, der auf dem DB - Server ausgeführt wird und sein Ergebnis zurückmeldet, wenn er fertig ist - oder, falls die Session zwischenzeitlich abgebaut wurde, wenn sich der betreffende User wieder anmeldet.

Das ist zwar nicht mehr ganz so einfach, hat aber in so einem Umfeld möglicherweise mehr “Charme”…

Grüße
W.K.

Ich verdeutliche mal, was ich mit meinem vorherigen Beitrag ausdrücken wollte.

Und dies ist mit Sicherheit nicht die einzige und alleinige Anwendung, die auf den Clients läuft. Da sei MS vor: selbst das OS ist “geschwätzig”. Und hat deshalb Mechanismen, die Last auf den Servern und Netzwerkverbindungen - egal ob im LAN oder WAN - zu reduzieren. Zum Beispiel, in dem Rechner, die “im Schlaf” liegen, weil kein Benutzer davor sitzt und Aktivitäten entfaltet vom Internet getrennt, Sessions - egal ob stateful oder stateless - terminiert und ODBC oder JDBC - Konnektions getrennt werden. Darauf hat ein reiner Datenbankentwickler nur sehr bedingt Einfluss: der Client unterscheidet sehr wohl zwischen “Nutzeraktivität” und “polling”.

Das sind anscheinend echte Witzbolde: solange die Dir nicht sagen, an welchen Stellen in ihrem Netz welche Zeitbegrenzung / Restriktion zuschlägt, bist Du ganz arm dran… Du kannst denen jetzt zwar sagen, ich brauche nur den Port 5432/TCP, beispielsweise - und, greifen die tatsächlich nativ vom Client auf localhost:5432 zu ? Natürlich nicht, es werden also mehr Ports beteiligt sein. Irgendwie müssen die Clients ja auf den Server kommen…

Fehler erkannt? Ein WINDOWS - Client, der auf keinem Port lauscht, startet vermutlich gar nicht, weil das OS “Dicke Backen” macht. Mindestens der localhost und die Ports für die lokalen Dienste müssen offen sein. Vermutlich meinst Du, dass kein Port über das Internet direkt erreichbar ist. Dafür gibt es NAT…

Da brauchst Du die Einstellung für auch… Nicht bloss die von Dir den Port…

Die Frage ist beantwortet - ich wollte lediglich darauf Hinweisen, dass es damit möglicherweise nicht getan ist. Es ist ja nicht nur die PostgreSQL, die von solchen Applikationen betroffen ist!

Wenn das Sicherheitsumfeld nicht Dein Problem ist, dann liefere eine DB ab, die läuft. Soll sich doch deren Sicherheitsbeauftragter oder wie der Typ genannt wird, Gedanken um die Verfügbarkeit machen. Die kannst Du - siehe oben - ohnehin so gut wie gar nicht Lösen.

Die pg nimmt sich den TCP/5432 bei einer Installation ohne Anpassungen. Auf dem localhost - also dem Datenbankserver.

Wie der über das Netz erreicht und angesprochen werden kann: Dein Problem?

Falls nicht: gut so.

Falls doch: schreib noch mal. Da werden wir vermutlich nur Stückweise durchkommen, bis alle möglichen und unmöglichen “Störer” ermittelt und alle Fehlerquellen umschifft sind…

Grüße
W.K.

Um ein weiteres Problem mal zu erwähnen, welches ich vorher “vergessen” gabe:

Gibt es in diesem Firmennetz so etwas wie einen “Single - Sign - On”?

Falls ja, wird es so richtig lustig…

Es ist sicher nett, daß Du helfen willst. Aber es wäre u.U. sinnvoller, nix zu sagen. Zumindest, wenn man keine Ahnung hat.

Andreas

Ich habe in einem System mit der Einstufung “Secure High” eine Postgre aufgesetzt und eine browserfähige Anwendung zur Interaktion über JBOSS implementiert. Alles mit den Standardeinstellungen bei der Installation. 5432 für die pg sollte also reichen.

Was mir in diesem Umfeld störend aufgefallen ist, sind die Sicherheitsrichtlinien: man sollte bei jedem Neustart des Servers, auf dem die DB läuft, überprüfen, ob die pg auch wirklich läuft.

Wenn zum Beispiel in diesem System ein Kerberos aktiv ist, kann ein unter Last gesetzter DB - Server schon mal vergessen oder für weniger wichtig halten - Sicherheit der Transaktion geht vor -, sich mit der Systemzeit zu synchronisieren. Und dann kann man den Prozessen beim “absterben” zusehen. Kerberos ist für so etwas ziemlich empfindlich.

Geht so weit, dass das Konto für den User “postgre” deaktiviert wird.

Solche Feinheiten können nur im Dialog mit den für die Sicherheit Verantwortlichen geklärt werden - Versuch macht Klug gilt hier nur eingeschränkt.

Grüße
W.K.

Das war ein Versuch, den Beteiligten drastisch vor Augen zu führen, dass ihre Aktivitäten allein nicht für die Ergebnisse gelten können.

Schwer “überzeichnet”.

Die Folgerung daraus ist allerdings ebenso schwer daneben. Und auch nicht Nachvollziehbar…

Na klar, ich habe von vernetzten Systemen keine Ahnung - bloss weil ich Fragen zu einer ganz speziellen Datenbank gestellt habe?

Da schneidet jemand Teile aus einer komplexen Antwort, erklärt sie als Unsinn - die sie isoliert auch sind - und spricht dem Poster jede Fachkenntnis ab.

Was ist das hier. Politik oder ein Forum, welches sich mit Computerfragen befasst?

Ich mach jetzt ungefähr 30 Jahre mit “Computers” rum - da ist ganz sicher, dass der Typ keine Ahnung haben kann.

Erst recht nicht mit aktuellen Systemen, weil die “Verstehen” ja nur Mausschubser".

Nö. Schau Dir an, was Du aus welchem Post Du was “ausgeschnitten” hast.

Die Sache mit der "Ahnung " können wir anderswo weiter Diskutieren.

Nö, wozu. Schau, der Thread war seit über einer Woche an sich beendet, weil beantwortet. Punkt eins. Punkt zwei ist, daß Dein Gerede von offenen Ports und so weiter sachlich falsch war.

Aber ich hab keinen Bock, das zu diskutieren. Weder hier noch woanders. Weil, da gibt es nix zu diskutieren. Du kannst Dir gern ‘TCP/IP Illustrated, Volume 1’ von W. Richard Stevens vornehmen.

Wenn Du wie eine Mimose nun reagierst so ist das Dein Problem und auch kein Thema, über das sich eine Diskussion lohnt. Weder hier noch woanders.

Andreas