Source-IP Adresse eines Requests ermitteln

Entwicklung Prozedurale Sprachen
1

Hi Leute,
vermutlich mach ich mich grad lächerlich, aber nichtsdestotrotz will ich’s wagen.

Ich denke grade darüber nach, ob es nicht nützlich sein könnte, die SourceIP, von der ein Request an die DB gestellt wird, zu ermitteln.

Hintergrund:
Datenbank im Internet, Clients in mehreren (nur teilweise verbundenen) Subnetzen, die über eine Vielzahl von Gateways (mehr als 100, niemand kennt die genaue Anzahl tatsächlich (kein Scherz, allerdings mit einer Einschränkung, vielleicht ich auch niemanden, der den kennt, wer weiss, wer die genaue Anzahl kennt) :wink: ) auf die DB zugreifen werden. NAT ist involviert.

Siehe hierzu auch http://www.pg-forum.de/sonstige-installationsprobleme/1953-welche-ports-verwendet-postgres-hinter-ner-firewall-tats-chlich.html#post9659


Da sich die DB im Internet befindet, macht eine Access-Restriction auf Firewall und auf DB-Ebene nach Source IP (also IP des gegnerischen Gateways) durchaus Sinn.

Frage:
Nachdem mir niemand eine vollständige Liste aller Gateways geben kann, denke ich daräber nach, eine solche dynamisch zu erzeugen und sowohl postgres lifesystem als auch firewall (iptables/shorewall) dynamisch zu konfigurieren.

Ab hier Gedankenexperiment:
Während des Login Prozesses (im Client) wird ein Connect auf eine nur für diesen Zweck bereitgestellte DB durchgeführt. Ist dieser erfolgreich (was mittels UserPass und pwd sichergestellt werden kann), liest, und jetzt wirds interessant, Postgres die Source-IP (also die des involvierten Gateways) des Requests aus und schreibt diese irgendwo hin.

Anschließend wird mittels geeigneter Methoden, trigger oder externe Prozedur oder was weiss ich (soweit bin gedanklich ich noch nicht) die Firewall und die pg_hba.conf dynamisch um diese (nun verifizierte) Source IP erweitert.

Frage 1a.)
Kann ich mit pg irgendwie die Source-IP auslesen, bestimmt, oder?

Frage 1b.)
Wie würdet Ihr die Datenspeicherung lösen? ich denke an nen Trigger /plpgsql

Frage 1c.)
Wie würdet Ihr die Firewall- und postgres pg_hba.conf-Manipulation lösen (ich denke hier an einen cronjob auf perl oder php basis, hätte aber natürlich viel lieber was realtime-fähiges, also dynamische Konfiguration von iptables)

Frage 1d.)
Weitere Gedanken und Ideen willkommen.

Server:
Debian (current stable, Kernel 2.6.aktuell), Postgres 8.1


Ein Merci für jeden Gedanken

2

pg_stat_activity, Spalte client_addr.

Hintergrund:
Datenbank im Internet, Clients in mehreren (nur teilweise verbundenen) Subnetzen, die über eine Vielzahl von Gateways (mehr als 100, niemand kennt die genaue Anzahl tatsächlich (kein Scherz, allerdings mit einer Einschränkung, vielleicht ich auch niemanden, der den kennt, wer weiss, wer die genaue Anzahl kennt) > :wink: > ) auf die DB zugreifen werden. NAT ist involviert.

Dann siehst Du aber nicht mehr die IP des Clients.

Siehe hierzu auch > http://www.pg-forum.de/sonstige-installationsprobleme/1953-welche-ports-verwendet-postgres-hinter-ner-firewall-tats-chlich.html#post9659


Da sich die DB im Internet befindet, macht eine Access-Restriction auf Firewall und auf DB-Ebene nach Source IP (also IP des gegnerischen Gateways) durchaus Sinn.

Frage:
Nachdem mir niemand eine vollständige Liste aller Gateways geben kann, denke ich daräber nach, eine solche dynamisch zu erzeugen und sowohl postgres lifesystem als auch firewall (iptables/shorewall) dynamisch zu konfigurieren.

Dazu mußt Du dann die pg_hba.conf zur Laufzeit ändern und zumindest ein Reload durchführen, u.U. sogar ein Neustart (bin mir grad ned sicher). Schlechte Idee IMHO. Allgemein ist IP-based Security keine wirklich gute Idee.

Ab hier Gedankenexperiment:
Während des Login Prozesses (im Client) wird ein Connect auf eine nur für diesen Zweck bereitgestellte DB durchgeführt. Ist dieser erfolgreich (was mittels UserPass und pwd sichergestellt werden kann), liest, und jetzt wirds interessant, Postgres die Source-IP (also die des involvierten Gateways) des Requests aus und schreibt diese irgendwo hin.

Anschließend wird mittels geeigneter Methoden, trigger oder externe Prozedur oder was weiss ich (soweit bin gedanklich ich noch nicht) die Firewall und die pg_hba.conf dynamisch um diese (nun verifizierte) Source IP erweitert.

Frage 1a.)
Kann ich mit pg irgendwie die Source-IP auslesen, bestimmt, oder?

Ja. siehe oben.

Frage 1b.)
Wie würdet Ihr die Datenspeicherung lösen? ich denke an nen Trigger /plpgsql

plpgsql ist eine trusted language, es kan nicht nach außerhalb kommunizieren. Man könnte mit LISTEN/NOTIFY arbeiten.

Frage 1c.)
Wie würdet Ihr die Firewall- und postgres pg_hba.conf-Manipulation lösen (ich denke hier an einen cronjob auf perl oder php basis, hätte aber natürlich viel lieber was realtime-fähiges, also dynamische Konfiguration von iptables)

Siehe oben, extra Prozeß mit LISTEN/NOTIFY. Aber ehrlich gesagt würde ich das gar nicht wollen.

Frage 1d.)
Weitere Gedanken und Ideen willkommen.

Ich vermute, Du suchst für eine vorhandene Lösung ein passendes Problem.


Andreas

3

Hi Andreas,
danke für deine (wie immer) schnelle Antwort.

Ich muss mir die pg_stat_activity erstmal ansehen, hab ich bisher noch nie benutzt(schäm).

Ein paar Dinge vorab:

Ja, ein Reload würde reichen.

@Schlechte Idee: seh ich teilweise auch so, aber ich hätt halt gern nen Filter auf die IP’s der Gateways, wenns irgendwie (mit vertretbarem Aufwand geht), um die DB für unbefugte dicht zu machen

Wieso nicht, wäre ip-based security das nicht eine sinnvolle Ergänzung zu md5 auth und ssl? Wieso würdest Du darauf verzichten?

Interessiert mich ehrlich, ich wills eigentlich auch nicht machen, aber es wäre halt ein netter Ansatz, um die DB noch etwas besser vor den Portscanner-Kids zu schützen.

Würdest Du dich an meiner Stelle ausschließlich auf die Sicherheitsmechanismen von Postgres verlassen? Ist Postgres wirklich derart secure?

Wenn nein, wie würdet Du denn die Db sichern? (Ich bin von meinem Ansatz auch nicht wirklich begeistert …)

Wie meinen? Glaubste ich hab sowas schon geschrieben oder wie? Nö, da überschätzt du mich :slight_smile:

Oder gibts bereits n Paket das sowas könnte?


Grüße


Jochen

4

IP-based Security ist darum eher nicht sinnvoll, weil IP-Adressen leicht zu fälschen, leicht umzuleiten und leicht zu vergeben sind. Solange die Kontrolle über die Vergabe der IP-Adressen nicht bei dir liegt und solange du nicht wirksam durchsetzen kannst, das ich z.B. mit meinem Laptop ankomme und eine IP im Netzwerk einfach so benutze, ist dein Vorschlag nicht brauchbar.

Es gibt bessere Methoden, dabei einen Zugriffsschutz zu realisieren. Du könntest zum Beispiel den Client mittels eines VPN authentisieren, bei dem der Client ebenfalls ein Zertifikat beibringen und sich ausweisen muss.

5

Du hast selbst geschrieben, daß da viel NAT im Spiel ist und viele Leute hinter den Gateway(s) sitzen. Will da einer die Kollegen ärgern, triggert er Deinen IP-Filter. Boom.

Interessiert mich ehrlich, ich wills eigentlich auch nicht machen, aber es wäre halt ein netter Ansatz, um die DB noch etwas besser vor den Portscanner-Kids zu schützen.

Wenn es das nur ist: anderen Port benutzen. Oder Port-Knocking benutzen.

Würdest Du dich an meiner Stelle ausschließlich auf die Sicherheitsmechanismen von Postgres verlassen? Ist Postgres wirklich derart secure?

Es gab seit zig Jahren keine remote Probleme mit PG. Und es gab auch so fast keine Security-Probleme. Es gab mal vor 1 Jahr oder so etwas im Zusammenhang mit fernöstlichen Zeichenkodierungen. Aber auch nur ohne realen Exploit und nur für authentifizierte Nutzer. Natürlich schließt das nix aus, besagt aber doch schon einiges zur Qualität.

Wenn nein, wie würdet Du denn die Db sichern? (Ich bin von meinem Ansatz auch nicht wirklich begeistert …)

Kannst Du die Source-IP’s nicht eingrenzen? Falls nein: VPN-Lösungen? Falls nein: normale Dinge wie Port verbiegen und/oder bei Erkennen von Scans FW-Regeln. Die hba on-the-fly zu verwursteln würde ich eher nicht machen.

Eher problematisch sind Dinge wie SQL-Injection authentifizierter Benutzer. Dagegen helfen Deine Ideen nicht.

Andreas

6

Hi ads,

Ja,
es ist klar, Ich hätte auch viel lieber ein paar vpn-tunnel, über die der traffic abgewickelt wird.

Aber nimm bitte an, dass alle Methoden, die eine Eingriffe irgend einer Art in die internen Netze (in denen sich die Clients befinden) bedingen, wenn überhaupt nicht binnen 12-Monatsfrit realisiertbar sind.

Wir bekommen ein Routing durch die Frirewall für alle Worksations des Konzerns auf eine IP, ein Port (DB-Server). Mehr nicht.

So z.B. wurde die Istallation eines VPNCLients auf deren Workstations bereits abgelehnt.

Danke


Jochen

7

Ich denke, du (und ads) habt Recht, ich werde den Gedanken verwerfen.

Ports sind eh schon verbogen, scandetection ebenfalls aktiviert, usw. usw.

Vielleicht drehen wir das Verfahren einfach um, wer sich nicht connecten kann soll seinen Benutzerservice anrufen und die IP des Gateways herausfinden lasen.

Danke für eure hilfe

Jochen

8

Ja, in Ordnung. Dann wäre meine Antwort an den Kunden:
In diesem Fall können wir keine vernünftige Sicherheit gewährleisten. Dazu noch einige Beispiele dokumentiert, warum das nicht greift.

Dann hat sich die Sache für mich erledigt.

9

:wink: Haste Recht, aber so is das halt manchmal mit Weltkonzernen…