Zugriff auf NAS aus der DMZ

[evilox]

Hallo Zusammen,

in meiner DMZ steht ein Debian Server, der von außen via FTP erreichbar ist. Die Daten, auf die zugegriffen werden sollen, liegen allerdings auf einem NAS (auch Debian) im LAN.

Ich suche nun einen eleganten Weg, ein Verzeichnis (read-only) auf dem FTP Server in der DMZ zu mounten, ohne mir zu große Löcher von der DMZ in Richtung LAN zu reißen.

Im Moment tendiere ich zu sshfs, womit sich der zu öffnende Port auf SSH beschränken würde, suche aber eigentlich eher nach einer Lösung, dass ich von der DMZ keine Ports in Richtung LAN öffnen muss, sondern aus dem LAN das Share in Richtung DMZ pusten kann.

Vielleicht hat ja jemand eine ähnliche Anforderung gehabt und kann da mit ein paar Erfahrungswerten dienen, oder einfach einen Anstoss liefern um aus der Betriebsblindheit zu kommen

Vielen Dank schon mal,

Evilox

 

[Thunderbyte]

DMZ ist eigentlich immer eine schlechte Idee, da alle Ports eines dort stehenden Servers in der Regel angreifbar sind.

Wo ist das Problem, mittels selektiver Portweiterleitung für BEIDE FTP Server NUR FÜR FTP (bzw andere Dienste) Zugriff zu gewähren? Das Read-Only ist eine Accountsache auf dem NAS, das hat mit der Vernetzung nichts zu tun. Wenn es zwei FTP Server hinter der gleichen IP sind, musst Du halt bei einem den Port ändern (z.b. 21 und 2121) und beide Ports zu ihren unterschiedlichen Zielen weiterleiten.

 

[evilox]

Ich glaube, ich wurde da missverstanden, noch mal etwas Licht ins Dunkle:

Es gibt keine zwei FTP Server, sondern nur einen, der in der DMZ steht, das ist auch so gewollt. Die Daten, die der FTP Server bereitstellt, liegen allerdings nicht auf dem FTP Server, sondern auf einem anderen Server (NAS).

Der aktuelle Stand ist, dass der FTP Server via NFS den Pfad vom NAS gemountet hat, allerdings befinden sich derzeit beide Server im LAN, die DMZ kommt jetzt neu.

In der neuen DMZ soll nur der FTP Server stehen, das NAS soll im lokalen Netzwerk bleiben. Nun möchte ich allerdings nicht das relativ unsichere NFS verwenden um die Daten auf dem FTP Server bereitzustellen und damit riesige Löcher in die Firwall von der DMZ in Richtung LAN aufreißen (dann kann ich die DMZ ja gleich weglassen), sondern suche nach einer Portsparsameren Lösung um die Daten bereitzustellen.

Aus dem LAN kann ich auf die Server der DMZ voll zugreifen, aber aus der DMZ will ich natürlich nicht, dass man einfach so in Richtung LAN kommt.

                        I N T E R N E T
				|
			F I R E W A L L
			|	      |
			LAN           DMZ
			|	      |
			NAS           FTP
			|	      |
			 ====MOUNT===>

 

[TerraX]

Dann solltest Du die Kommunikationsregeln an der Firewall der inneren DMZ-Grenze zum LAN entsprechend festlegen. Du kannst ja nicht nur Port aufmachen sondern durchaus festlegen, dass Dein FTP-Server nach intern nur mit dem NAS auf einem Protokollport Deiner Wahl reden darf. Mit einer Firewall kann man nicht nur "Ports öffnen" sondern auch Kommunikationsbeziehungen festlegen, was auch der eigentliche Zweck ist.

 

[evilox]

Ja, das ist klar. Meine Frage zielt mehr darauf ab, ob es eine Möglichkeit gibt, die Daten an den FTP Server zu präsentieren, ohne Ports von der DMZ in Richtung LAN zu öffnen.

Also zum Beispiel einen SSHFS Mount rückwärts zu gestalten:

SSH vom NAS (LAN) auf den FTP Server (DMZ) und rückwärts durch diesen Tunnel einen mount durchzuführen.

Kann ja sein, dass es nichts gibt, was meiner Idee entspricht, das wäre ja auch ein Ergebnis

 

[Thunderbyte]

Ja, das ist klar. Meine Frage zielt mehr darauf ab, ob es eine Möglichkeit gibt, die Daten an den FTP Server zu präsentieren, ohne Ports von der DMZ in Richtung LAN zu öffnen.

Und Du hast offensichtlich TerraX nicht verstanden:

Du kannst per Firewall eine Kommunikationsbeziehung (Mount des NAS auf dem FTP Server) nur zwischen diesen beiden Zielen erlauben. Wenn Du dann nur den FTP Port und/oder das Protokoll per Firewall auf den FTP Server freigibst, was soll da schon möglich sein?

Ich bin mir nicht sicher, ob wir das gleiche unter DMZ verstehen, ich gehe mal davon aus, dass Du nicht einen Exposed Host damit meinst, sondern ein per Firewall reglementiertes Sondernetz für Server, die von außen zugänglich sind.

Wenn Du per Regeln nun die Beziehungen zwischen beiden Netzen sehr feinkörnig (z.B. port-/protokollbasiert) regeln kannst, dann spricht doch wirklich nichts gegen eine sehr rigide FW Regelpolicy, die die gewünschten Beziehungen ermöglicht und alles andere verbietet.

 

[evilox]

Doch ich habe TerraX verstanden, allerdings kenne ich die Lösungsmöglichkeiten, die sich mir bieten, wenn ich Policybased den Zugriff in mein LAN öffne, danach habe ich aber nicht gefragt.

Ich spreche hier auch nicht über einen Exposed Host, sondern über ein gesondertes Netz, auf einem eigenen Interface der Firewall.

Es geht mir hier ja nicht darum, zu diskutieren, ob das zulassen eines Ports / Protokolls in Richtung LAN ein vernachlässigbares Risiko darstellt, sondern zu Erfahren ob alternative Ideen gibt, bei denen das nicht nötig wäre.

Wenn es die nicht gibt, weiß ich ja, was zu tun ist und danke trotzdem jedem der sich hier eingebracht hat. Ich will nur verhindern, dass ich eine gute Lösung übersehe und später doppelte Konfigurationsarbeit habe.

 

[TerraX]

Eine reine Push-Option ist m.E. nicht möglich. Es muss einen Kommunikationskanal in beide Richtungen geben, sonst weiß das NAS ja nicht, welches File angefordert wird.

 

[storvi]

Hallo,

den von dir beschriebenen Aufbau kenne ich und setze ich bei mir auch so ein. Ich habe jedoch aufgrund der flexibleren Einsatzmöglichkeiten auf WebDAV gewechselt, da :

1. HTTPS Verschlüsselt
2. Reverseproxy einfach zu implementieren (dein "DMZ"-Server)
3. Authentisierungsverfahren besser als Username / Passwort (Zertifikate, OneTimePassword...)
4. Auch viele Clients vorhanden

Gerade die Tatsache, dass ich zum einen auf Client-Zertifikate als Authentisierung setzen kann (mein Laptop + Smartcard), sowie für meine Frau auf ein Token mit OTPs (Lehrerin + Schulrechner) vereinfachen den Zugriff sehr. Zusätzlich kannst du auch einfach einen webbasierten Filemanager auf dem Proxy installieren...

Gruß
Markus

 

[TerraX]

Hmm, ich skizziere mal eine klassische DMZ

... pöses Internet >>>| outer Firewall |<<< Frontendsysteme >>>| inner Firewall <<< Backendsysteme >>> lokales LAN

Ich sehe 2 Optionen:

a) der FTP-Server (Frontend) included/mounted ein Verzeichnis vom NAS (Backend) über die inner Firewall kann dezidiert geregelt werden, dass nur der FTP-Server mit dem NAS eine Verbindung initiieren darf

b) das öffentliche Verzeichnis befindet sich tatsächlich auf dem FTP-Server und wird im NAS included/gemounted. Hier wird geregelt, dass nur das NAS mit dem FTP-Server eine Verbindung aufnehmen darf und nicht umgekehrt.

Die Möglichkeiten von SPI sind natürlich begrenzt, daher muss das Protokoll/Filesystem dazu passen.

Verschlüsselung ist auch mit FTP problemlos realisierbar und macht nur bis zum Frontend i.d.R. wirtschaftlich Sinn.

In dem vom TE skizzierten Szenario sehe ich für einen Reverse-Proxy wenig Sinn, da selbiger eigentlich eher für Load-Balancing und dem zentralen Verteilen verschiedener Anfragen auf die entsprechenden Backend-Systeme zuständig ist.

Wenn der Zugriff via WebDAV gewünscht ist, würde ich eher dazu tendieren, gleich einen Apache unter die Frontendsysteme zu stellen und dann Variante B anzuwenden.

 

[storvi]

In "meinem" WebDAV-Konstrukt macht der Reverseproxy HTTPs-Offloading (intern reicht mir in dem Anwendungsfall HTTP) und zusätzlich die Authentisierung.

Zusätzliche läuft auch der Webclient auf dem Reverseproxy, so dass die Daten ausschließlich in der MZ sind.

Gibt sicherlich mehrere Wege nach Rom

Gruß
Markus

 

[evilox]

Viele tolle Ansätze, danke für eure Ideen..

Den ersten Feldversuch habe ich nun mit einem SSHFS Mount, rückwärts durch einen SSH Tunnel gemacht, das hat auf Anhieb gut geklappt.

Ich mache also von vom LAN eine SSH Session zum FTP Server und mounte dann mit SSHFS rückwärts durch den SSH Tunnel das Verzeichnis.

So brauche ich keinen Port in das LAN zu öffnen und trage nur noch das Risiko, dass jemand den Tunnel hijackt.