postgreSQL Forward (port 5432)

Hi,

Hab hier ein SMC-Router, und möchte postgreSQL von einem internen rechner freigeben. Portweiterleitung TCP, Port 5432. Hab parallel auch ein port 80 forward eingerichtet. funktioniert einwandfrei. Also sollte das ganze auch funktionieren. Klappt jedoch nicht. D.h. es muss noch irgendwas anderes weitergeleitet werden.
Da ja der Http-service ähnlich funktioniert sollte das jedoch ohne weiteres funktionieren?

Jemand eine Idee?

Samstag, 29. März 2008 21:01:23 Unrecognized attempt blocked from 84.172.236.xx:1128 to 87.165.170.xx TCP:5432
Samstag, 29. März 2008 21:01:26 Unrecognized attempt blocked from 84.172.236.xx:1128 to 87.165.170.xx TCP:5432
Samstag, 29. März 2008 21:01:32 Unrecognized attempt blocked from 84.172.236.xx:1128 to 87.165.170.xx TCP:5432
Samstag, 29. März 2008 21:02:19 Unrecognized attempt blocked from 84.172.236.xx:1129 to 87.165.170.xx TCP:5432
Samstag, 29. März 2008 21:02:22 Unrecognized attempt blocked from 84.172.236.xx:1129 to 87.165.170.xx TCP:5432
Samstag, 29. März 2008 21:02:28 Unrecognized attempt blocked from 84.172.236.xx:1129 to 87.165.170.xx TCP:5432

Laut lock wird das auch aus der pipe genomen. Jemand ne ahnung?

PG sollte eigentlich nur 5432 nutzen Grübel
Wieso meldet das Log denn unerkannte Zugriffe auf dem Port - und wer generiert dieses Log? Weil da drin wird ja auf Port 5432 zugegriffen, das sollte also eigentlich keinen Fehler ergeben.

PG benötigt einzig und alleine 5432, wenn man es beim Default beläßt. Man sollte dem PG aber auch sagen, daß es an allen Adressen lauschen soll (postgresql.conf -> listen_addresses = ‘*’). Außerdem braucht es auch eine passende pg_hba.conf. Guggst Du Doku notfalls.

Davon abgesehen wäre es u.U. sinnvoller, 5432 NICHT ins Internet zu prostituieren, sondern sowas wie einen SSH-Tunnel zu nutzen. Aber das ist Deine Sache.

Wie hast Du festgestellt, daß 80 funktioniert? Läuft auf dem Rechner, wo PG ist, auch ein HTTP-Server und hast Du DESSEN Seiten gesehen?

Samstag, 29. März 2008 21:01:23 Unrecognized attempt blocked from 84.172.236.xx:1128 to 87.165.170.xx TCP:5432

>

Keine Ahnung was das ist, aber es ist kein Log von PG. Das ist auch eine öffentliche Adresse, Dein 87.165.170.xx. Wilde Vermutung: Das ist Dein Router, und darauf ist a) kein PG und b) blockt er es und c) Dein Port-80 - Test lieferte Dir die Bedienoberfläche des Routers und nicht des PC's dahinter.
\
<br>
> Laut lock wird das auch aus der pipe genomen. Jemand ne ahnung?

Parse error in mod_logic.

Andreas

Keine Ahnung was das ist, aber es ist kein Log von PG.

das ist sein router log … der router blockt die anfrage … er muss also schauen, dass der port 5432 geroutet wird - bzw. die adresse auch vom router “akzeptiert”

Jep. War ein Router-Problem. Dachte, dass evt. jemand ne Idee hat was das sein könnte. Problem leider und diesen Voraussetzungen noch nicht gelöst. Hab Übergangsweise eine andere Lösung gefunden. Werde hier ebenfalls dann Weitere posten. Danke für die Hilfe!


Zum Thema SSH-Tunnel.
Ich Möchte für meine Kunden ein paar Datenbanken zur Verfügung stellen. Klar ich werde nicht verhindern können, wenn jemand etwas Böses will, dass er meine Datenbank Lahm legt. Die frage ist wie könnte man solche Dinge generell unterbinden?

Kann ich nicht nur bestimmte Query Typen zulassen?

Antwort von Radio Erewan: im Prinzip Ja.

Du könntest Nutzer definieren. Und zwar so, daß diese nur nur SELECT machen darf. Dann schreibst Du Funktionen, mit denen man auch Daten inserten kann, diese sind dann ‘security definer’ und gehören einem User, das Insert-Rechte hat. Zum Abfragen von Tabellen kannst Du VIEWS definieren, oder SRF’s. Der User hat dann auch keine Select-Rechte auf die Tabellen. Man könnte das ziemlich weit treiben…

Natürlich können Deine User dann nur noch das, was Du vorgibst. Ob das so gewollt ist, weiß ich nicht.

Das hat aber nix mit SSH-Tunnel zu tun, der wäre lediglich nur dazu, vor dem Zugriff eine anerkannt sichere Authentifizierung (Hint: PublicKey-Verfahren) zu machen, und evtl. auch die in SSH eingebaute Komprimierung zu nutzen.

Andreas

Im Prinzip haben die User lediglich “Select”-Rechte. Keine Update/Insert & co sollen diese User auf die Datenbank haben. Derzeit habe ich eine primitive Lösung - Eine Gruppe mit Leserechten auf die einzelnen Datenbanken, der die User zugeordnet sind.

Gibt es hierfür besondere Kritische Aspekte, die man präventiv schon entgegenwirken kann?


Hmm… Views halten mich doch nur bezüglich Änderungen einer DB ab? Selects kann ich doch wie gewöhnlich weiter anfragen?

Mit VIEWS gehen Dinge wie folgt:

test=# create table geheim (id int, name text, gehalt float);
CREATE TABLE
test=*# copy geheim from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> 1    ich     1000
>> 2    du      2000
>> 3    baer    3000
>> \.
test=*# commit;
COMMIT
test=# create view view_geheim as select * from geheim where name = current_user;
CREATE VIEW
test=# grant select on  view_geheim to mitarbeiter;
GRANT
test=*# commit;
COMMIT
test=# \q
kretschmer@pegasus:~$ psql -U baer test
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

test=> select * from geheim;
ERROR:  permission denied for relation geheim

test=> select * from view_geheim;
 id | name | gehalt
----+------+--------
  3 | baer |   3000
(1 row)

Ich habe als DB-Admin die Tabelle und den VIEW angelegt und Select-Rechte auf den View an die Gruppe Mitarbeiter gegeben. Dann als Mitarbeiter eingeloggt. Ein Select auf die Tabelle geht nicht, ein Select auf den View liefert nur das, was der Mitarbeiter sehen darf.

Andreas

Okay alles klar, danke! Vorweg noch eine Frage. Wenn ich nur reine Selects auf Datenbanken hat. Welche Möglichkeit gäbe es die Datenbank lahm zu legen und kann man diesen Dingen entgegenwirken?



select *, a*b, md5(a*b) from generate_Series(1,10) a cross join generate_Series(1,10) b;

erzeugt Dir on-the-fly mal eben 100 Result-Datensätze, dazu noch a bissl CPU-Last für die md5()-Geschichte. Erhöhe nun im Select die obere Grenze für generate_series() bis zur Schmerzgrenze.

Andreas

Okay und kann ich sowas evt. deaktivieren? Evt. die Funktionen abschalten oder einfach Überschreiben, dass die nichts mehr machen und 1 zurückgeben? :smiley:

Nein.

Andreas

Und ich kann dagegen rein gar nichts machen?

Du könntest statement_timeout auf einen sinnvollen Wert setzen, weil man vielleicht davon ausgehen kann, daß ‘böse’ Selects, die fett Speicher verbraten, auch eine Weile brauchen, dies zu tun. Das ist aber so, als ob Du mit der Schrotflinte im Schlafzimmer eine Mücke erlegen wölltest - Kollateralschäden vorprogrammiert.

Wenn Du Deinen Usern nicht traust, dann lass sie nicht auf die DB.

Andreas

Wenn Du Deinen Usern nicht traust, dann lass sie nicht auf die DB.

Naja, ich will meinen Usern daten zur Verfügung stellen. Schwarze Schafe werden immer dabei sein. :angry:

Du könntest statement_timeout auf einen sinnvollen Wert setzen, weil man vielleicht davon ausgehen kann, daß ‘böse’ Selects, die fett Speicher verbraten, auch eine Weile brauchen, dies zu tun. Das ist aber so, als ob Du mit der Schrotflinte im Schlafzimmer eine Mücke erlegen wölltest - Kollateralschäden vorprogrammiert.

Okay, das ist eig. kein Problem ich weiß, dass man max 1min pro Query brauchen darf. Mit ein paar Speicher & Ressourcen Einstellen meinst du nicht kommt man weit?

Noch einmal: es gibt da keinen sinnvollen Weg. Die Speicher-Einstellungen, die PG bietet, haben einen anderen Zweck. Wenn Du z.B. work_mem runtersetzt, dann heißt das nicht, daß Du da böse Selects limitierst. Es passiert lediglich, daß bei regulären Selects u.U. suboptimale Pläne erstellt werden, weil PG dann z.B. nicht im Speicher sortiert, sondern auf der Platte. Man nennt das dann auch Eigentor.

Andreas

Wie akretschmer sagt: wenn du die Speichereinstellungen runter drehst, schießt du dir selbst in den Fuß. Die Anfragen der User werden mehr Performance fressen als sie mit optimalen Einstellungen benötigen.
Aber eigentlich wolltest du ja das Gegenteil erreichen.

Also, Klartext: wenn du Angst hast, das jemand deine DB missbraucht, lass ihn nicht drauf. Das ist bei einer Datenbank genauso wie überall anders auch: wenn du etwas zu vermieten hast und Angst haben musst, dass der Mieter damit Unsinn baut - dein Risiko. Gegen Schadensbegrenzung hilft vielleicht eine Versicherung, aber der Schaden ist trotzdem erst mal da.

Das ist schon richtig. Nur … bei einer Autovermietung hat das kein Auswirklich auf andere Mieter!! Und das ist derzeit der springende Punkt. Ich will nicht, wenn einer Misst baut, dass alle anderen mit in Leidenschaft gezogen werden.



Okay mal ein anderer Ansatz…

Derzeit hab ich meine Datenbank Kopier-geschützt, indem ich in der Netzwerk-Protokoll-Ebene die Pakete tracke den Traffic für jeden User bestimme (Jede IP Wird zu einem bestimmten User aufgelöst). Jeder User hat dabei ein Traffic Limit pro Tag, sollte dieses Überschritten werden, wird dieser erstmal für einen Zeitraum gesperrt. funktioniert momentan schonmal recht gut.

Kann man das nicht parallel auch diese Problem übertragen? D.h. befor ein TCP/IP Query-Paket überhaupt erst zum Server kommt, wird erstmal die Anfrage zwischengespeichert und auf korrektheit geprüft. Der Query wird dann einige Tests unterzogen, ob es ein “bösartiger” oder ein “gutartiger” Query ist. Sollte dem so sein, passiert er die pipeline zum postgreSQL Server andererseits nicht.
Da die User von außen max. 1-5 Query’s pro Minute brauchen, sollte das performance-technisch kein problem sein.


Da müsste man sich mal einarbeiten, welche Flags bei einem Query-Start und Query-Ende gesetzt sind, damit man sehen kann wo ein Query anfängt und aufhört.
Jemand ne Ahnung wo ich da schnell brauchbare Infos finde? Werd schonmal in den Docs suchen … :slight_smile:

Ich verweise mal auf die letzte Zeile in meiner Signatur.

Na ja, da brauch ich einfach nichts weiter sagen :slight_smile: Danke für euere Hilfe