Reverse Proxy - iptables - Packetfilter?

[tschulian]

Reverse Proxy - iptables - Packetfilter? Anbei ein kurzes Schema + Erklärung

Erklärung:

1. Client --> SOLL-Kommunikation mit ReverseProxy auf Port X, Port Y und Port Z

2. Unix ReverseProxy --> Umleitung & Prüfung der Clientkommunikation

3. IPTables --> Prüfung der Clientkommunikation ob wirklich über Port X, Port Y und Port Z (und verwerfen aller Anfragen die nicht über Port X,Y oder Z erfolgen

4. Packetfilter --> Filtern der Datenpackets die über Port X,Y,Z erfolgen (inkl. Limitierung? Falls möglich?)

5. Application-Server --> erhält nun die überprüften Daten des Unix ReverseProxys.

Was ich darüber wissen möchte:

- Gibt es überhaupt die Möglichkeiten den Datentraffic derart Umzuleiten und zu prüfen oder ist sowas generell nicht möglich? (vorallem die Limitierung von Packets?)

- gibt es vordefinierte Unix Distributionen die sowas bieten können?

- gibt es jemanden der sowas schon Mal in ähnlicher Weise konfiguriert hat?

[SaJu]

Es gibt Firewall-Distributionen, die so etwas können.

Beispiele:

- https://www.pfsense.org

- www.ipfire.org - Home

[tschulian]

Hast du Erfahrungen damit?

[sas86ks]

Auch wenn es OT ist erlaube ich mir mal folgende Bemerkung:

Paket (deutsch) und packet (englisch)

[tschulian]

Reverse Proxy - iptables - Packetfilter sind doch alles englische Begriffe, wo ist das Problem?

EDIT: ich sehe Datenpackete z.B.

Ja in der Hektik wohl durchgemischt. Sry

[SaJu]

Ich habe IPFire als Abschlussprojekt installiert. Zusätzlich wurde mir von vielen Seiten her PFSense empfohlen, was eine sehr gute Alternative gewesen wäre. Jetzt würde ich auch eher dazu tendieren.

[tschulian]

Okay, kann der PFSense genau das, was ich vorhabe?

Client -> "proxy um reale IP des servers zu vertuschen" -> iptable um nur spezifische ports weiterzuleiten -> paketfilter

Kommt er auch vielen vielen gleichzeitigen Verbindungen klar?

Sehr undurchsichtig wie das alles angegeben ist, und ein haufen Zeit zu investieren ohne vorher zu wissen, ob die Funktionen zur Verfügung stehen.

[GoaSkin]

Kannst du vielleicht mal mit normalen Sätzen erklären, was du eigentlich willst oder muss man Autist sein, um dich zu verstehen?

erster Begriff -> zweiter Begriff -> Dritter Begriff ergibt keinen Sinn, auch wenn alles englische Wörter sind.

[tschulian]

Also bin meinem Ziel schon verdammt nahe. Will mit IPtables eine Art Proxy verwirklichen.

Dieser kann und soll nur auf bestimmten Ports weiterleiten.

Und den Usern ist nur die IP des Unix Proxys bekannt.

Also alle Anfragen gehen an den unix Server dieser leitet dann den eingehenden Traffic auf Port X an die öffentliche IP: 5.5.5.5 weiter.

Habe momentan folgende Einstellungen:

# um den Server für Ping verfügbar zu machen

iptables -A INPUT -p icmp -j ACCEPT


# soll den eingehenden Traffic an die spezifische Zieladresse senden

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 5.5.5.15:80

iptables -t nat -A POSTROUTING -p tcp -d 4.4.4.4 --dport 80 -j SNAT --to-source 5.5.5.5

Aber es wird nichts weitergeleitet... Bin ratlos.

[GoaSkin]

Eventuell kann man hier statt einer IPTables-Umleitung einfach den Stone-Proxy einsetzen (ein kleiner Open Source Proxy-Server, der auf einem TCP-Port lauscht, um sich bei einer eingehenden Verbindung mit einem anderen Server zu verbinden und die Ein- und Ausgabe durchschleift).

Ansonsten leitet man per DNAT-Anweisung zwar Pakete an ein anderes Ziel um, die Absender-Adresse bleibt aber erhalten und der Ziel-Server addressiert seine Pakete prinzipiell auch an Diese. D.h. die Quell-IP muss für den Ziel-Server trotz Umleitung prinzipiell irgendwie erreichbar sein. Das regelt deine zweite iptables-Zeile so nicht. Aber es ist auch eine knifflige Sache. Mit 'stone' geht es einfacher.

Willst du IPtables nutzen, musst du als Kriterium nehmen: Verkehr kommt von der Server-IP und vom Quellport 80. Wenn dies der Fall ist, muss die Quell-IP durch die Firewall-IP ersetzt werden. Oder du richtest ein generelles NAT für den vom Server ausgehenden Datenverkehr ein. Ist aber knifflig. Stone nutzen ist einfacher.

Ubuntu Manpage: stone - a simple TCP/IP packet repeater

[tschulian]

Habe jetzt eine fast gute Lösung.

Das einzige was jetzt falsch ist, dass jetzt in meiner Anwendung auf dem richtigen Server immer die IP des Proxy steht. Hab rausgefunden das es am Masquerading liegt, finde aber keine Lösung wie mans ohne Masquerading schaffen kann...

iptables -t nat -A PREROUTING -p tcp --dport 21 -j DNAT --to-destination 1.3.39.179:21

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 1.3.39.179:80

iptables -t nat -A POSTROUTING -j MASQUERADE

Bearbeitet 23. November 2014 von tschulian

[GoaSkin]

Es ist vollkommen richtig, dass man hier Masquerading einrichten muss. Der eigentliche Server versieht die Antwort-Pakete schließlich mit seiner eigenen Absender-IP und die Firewall muss Diese durch ihre Eigene dann ersetzen, da der Client ja eigentlich die IP der Firewall adressiert. Man kann aber die POSTROUTING-Regel anhand von Kriterien so erweitern, dass das Masquerading nur bei diesen Verbindungen Anwendung findet - d.h. die Regel nach Bedarf nach IP, Port und Interface anhand von weiteren Kriterien einschränken.

[tschulian]

Okay ich hab jetzt was rausgefunden nach ca 12 Stunden durchgehend probieren. Die iptables dienen zu aller erst als Filter alles was durch diese kommt wird / soll per haproxy an meinen applicationserver weitergeleitet werden

Das heißt: mein 3zeiler ist garnicht verkehrt aber in meinem Fall nutzlos, da ich ja die IP der User sehen muss am Ende. Werde heute mal versuchen den haproxy zu konfigurieren

Bearbeitet 26. November 2014 von tschulian