22
Freigaben aus LAN in DMZ routen
Hallo Zusammen
Ich sitze seit Stunden vor einem Problem und vermute, dass ich einen Denkfehler habe oder mir selbst im Weg stehe
Mein etwas vereinfacht dargestelltes Netz (teilweise virtualisiert auf ESX und mit vLan, aber spielt keine Rolle):
Was will ich?
Was verstehe ich, was nicht?
Entschuldigt den langen Text, aber ich hoffe, dass mir so jemand helfen kann.
Gruss
Everdt
Ich sitze seit Stunden vor einem Problem und vermute, dass ich einen Denkfehler habe oder mir selbst im Weg stehe
Mein etwas vereinfacht dargestelltes Netz (teilweise virtualisiert auf ESX und mit vLan, aber spielt keine Rolle):
- Die pfSense blockt alles aus der DMZ ab.
- Zugriff LAN - DMZ funktioniert alles
- Zugriff Internet-DMZ funktioniert alles
Was will ich?
- Ich möchte ein Netzlaufwerk vom NAS (192.168.1.6) auf dem Ubuntu-Server (192.168.10.11) mounten.
- Bisher war der Ubuntu-Server im LAN, somit gab es das Problem nicht.
- Bisher habe ich das über die fstab mit folgendem Inhalt gemacht: //192.168.1.11/<Freigabe> /media/<Mountpoint> cifs username=NAME,password=GEHEIM 0 0
Was verstehe ich, was nicht?
- Mir ist klar, dass ich auf der pfSense ein Portforwarding auf das NAS machen muss
- Mir ist nicht klar, was ich von wo nach wo routen muss (IP und Ports)
- Mir ist nicht klar, wie ich dem Ubuntu-Server sage, wo er das Share findet und dieses dann mounte
Entschuldigt den langen Text, aber ich hoffe, dass mir so jemand helfen kann.
Gruss
Everdt
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 354808
Url: https://administrator.de/contentid/354808
Printed on: April 26, 2024 at 08:04 o'clock
22 Comments
Latest comment
Moin,
als erste Frage:
Wer ist das Gateway für den UBUNTU-Server?
Wenn es die IPFire-Kiste ist, kannst du an der pfSense einstellen was du willst, der Ubuntu-Server schickt seine Anfrage für 192.168.1.* an die IPFire-Kiste. Wenn die nur Pakete aus dem WAN ins LAN vice versa zulässt, wirst du aus der DMZ kein Paket ins LAN bekommen.
Gleiches könnte für die Routing-Tabelle in der IPFire gelten, wobei ich das mal ausschließe, da sonst vermutlich keinerlei Pakete aus dem WAN im LAN ankommen würden. Prüfe das aber mal zur Sicherheit
Wenn du nicht über die IPFIRE gehen willst, wäre eine weitere Option, ein statisches Routing im UBUNTU-Server zu setzen:
192.168.1.0/24 via 192.168.10.2/24, natürlich dann die FW in der pfSense entsprechend straff einstellen.
Halte ich aber für fragwürdig: wird der UBUNTU-Server in der DMZ kompromitiert, kommt der auch automatisch an das NAS dran.
Eine seperate SIcherheitsinstanz (ext. Firewall) wäre da sicherlich besser geeignet, denke ich.
Gruß
em-pie
als erste Frage:
Wer ist das Gateway für den UBUNTU-Server?
Wenn es die IPFire-Kiste ist, kannst du an der pfSense einstellen was du willst, der Ubuntu-Server schickt seine Anfrage für 192.168.1.* an die IPFire-Kiste. Wenn die nur Pakete aus dem WAN ins LAN vice versa zulässt, wirst du aus der DMZ kein Paket ins LAN bekommen.
Gleiches könnte für die Routing-Tabelle in der IPFire gelten, wobei ich das mal ausschließe, da sonst vermutlich keinerlei Pakete aus dem WAN im LAN ankommen würden. Prüfe das aber mal zur Sicherheit
Wenn du nicht über die IPFIRE gehen willst, wäre eine weitere Option, ein statisches Routing im UBUNTU-Server zu setzen:
192.168.1.0/24 via 192.168.10.2/24, natürlich dann die FW in der pfSense entsprechend straff einstellen.
Halte ich aber für fragwürdig: wird der UBUNTU-Server in der DMZ kompromitiert, kommt der auch automatisch an das NAS dran.
Eine seperate SIcherheitsinstanz (ext. Firewall) wäre da sicherlich besser geeignet, denke ich.
Gruß
em-pie
Moin.
Du must lediglich die CIFS-Ports (135,137 und 445 wenn micht nicht alles täuscht) für neue Verbindungen von (DMZ)Ubuntu an (LAN)NAS freigeben.
lg,
Slainte
Ich möchte ein Netzlaufwerk vom NAS (192.168.1.6) ...
fstab mit folgendem Inhalt gemacht: //192.168.1.11/<Freigabe>
Ist das ein Tipfehler?fstab mit folgendem Inhalt gemacht: //192.168.1.11/<Freigabe>
Mir ist klar, dass ich auf der pfSense ein Portforwarding auf das NAS machen muss
Mit Portforwarding hat das nichts zu tun.Mir ist nicht klar, was ich von wo nach wo routen muss (IP und Ports)#
Die Routen sollten schon passen, beide Netze sind ja local für die pfSenseMir ist nicht klar, wie ich dem Ubuntu-Server sage, wo er das Share findet und dieses dann mounte
Gemounted wird nach wie vor von 192.168.1.6 - die NAS IP ändert sich ja nicht.Du must lediglich die CIFS-Ports (135,137 und 445 wenn micht nicht alles täuscht) für neue Verbindungen von (DMZ)Ubuntu an (LAN)NAS freigeben.
lg,
Slainte
Danke für die Inputs.
Der erste Fehler wäre also gefunden: "natürlich" ist das Gateway des Ubuntu-Servers die ipFire unter 192.168.10.1
Kurz zu meinen Firewall-Configs:
Wie meinst du "nicht über die ipFire gehen willst"?
Das mit dem statischen Routing wollte ich eben nicht, deshalb war meine Frage, wie ich dem Ubuntuserver sage, wo/wie er das NAS findet...
Dem Ubuntuserver als Gateway die pfSense geben geht ja nicht, da er sich auf der WAN-Seite dieser Firewall befindet, oder?
Gruss
Everdt
Wer ist das Gateway für den UBUNTU-Server?
Wenn es die IPFire-Kiste ist, kannst du an der pfSense einstellen was du willst, der Ubuntu-Server schickt seine Anfrage für 192.168.1.* an die IPFire-Kiste. Wenn die nur Pakete aus dem WAN ins LAN vice versa zulässt, wirst du aus der DMZ kein Paket ins LAN bekommen.
Wenn es die IPFire-Kiste ist, kannst du an der pfSense einstellen was du willst, der Ubuntu-Server schickt seine Anfrage für 192.168.1.* an die IPFire-Kiste. Wenn die nur Pakete aus dem WAN ins LAN vice versa zulässt, wirst du aus der DMZ kein Paket ins LAN bekommen.
Der erste Fehler wäre also gefunden: "natürlich" ist das Gateway des Ubuntu-Servers die ipFire unter 192.168.10.1
Kurz zu meinen Firewall-Configs:
- beide blocken grundsätzlich alles von aussen ab, was nicht von innen angefragt wurde
- Gateway der ipFire ist durch den ISP vergeben (DHCP)
- ipFire wäre in der DMZ der DHCP (ausgeschaltet, da nur statische IP)
- Gateway der pfSense ist die ipFire
- auf der ipFire (WAN-DMZ) sind gewisse Regeln eingerichtet, z.B. Portforwarding zum Ubuntuserver
- es wird NICHTS vom WAN ins LAN durchgelassen, was nicht angefragt wurde, sondern wenn überhaupt ausschliesslich in die DMZ
Wenn du nicht über die IPFIRE gehen willst, wäre eine weitere Option, ein statisches Routing im UBUNTU-Server zu setzen:
192.168.1.0/24 via 192.168.10.2/24, natürlich dann die FW in der pfSense entsprechend straff einstellen.
Halte ich aber für fragwürdig: wird der UBUNTU-Server in der DMZ kompromitiert, kommt der auch automatisch an das NAS dran.
Eine seperate SIcherheitsinstanz (ext. Firewall) wäre da sicherlich besser geeignet, denke ich.
192.168.1.0/24 via 192.168.10.2/24, natürlich dann die FW in der pfSense entsprechend straff einstellen.
Halte ich aber für fragwürdig: wird der UBUNTU-Server in der DMZ kompromitiert, kommt der auch automatisch an das NAS dran.
Eine seperate SIcherheitsinstanz (ext. Firewall) wäre da sicherlich besser geeignet, denke ich.
Wie meinst du "nicht über die ipFire gehen willst"?
Das mit dem statischen Routing wollte ich eben nicht, deshalb war meine Frage, wie ich dem Ubuntuserver sage, wo/wie er das NAS findet...
Dem Ubuntuserver als Gateway die pfSense geben geht ja nicht, da er sich auf der WAN-Seite dieser Firewall befindet, oder?
Gruss
Everdt
Ich möchte ein Netzlaufwerk vom NAS (192.168.1.6) ...
fstab mit folgendem Inhalt gemacht: //192.168.1.11/<Freigabe>
Ist das ein Tipfehler?fstab mit folgendem Inhalt gemacht: //192.168.1.11/<Freigabe>
Ja, da habe ich mich vertippt
Mir ist klar, dass ich auf der pfSense ein Portforwarding auf das NAS machen muss
Mit Portforwarding hat das nichts zu tun.Ich dachte ich muss die Ports für cifs auf das NAS forwarden? Ist dem nicht so?
Mir ist nicht klar, was ich von wo nach wo routen muss (IP und Ports)#
Die Routen sollten schon passen, beide Netze sind ja local für die pfSenseMir ist nicht klar, wie ich dem Ubuntu-Server sage, wo er das Share findet und dieses dann mounte
Gemounted wird nach wie vor von 192.168.1.6 - die NAS IP ändert sich ja nicht.Jein, die DMZ ist für die pfSense WAN = ROT
Du must lediglich die CIFS-Ports (135,137 und 445 wenn micht nicht alles täuscht) für neue Verbindungen von (DMZ)Ubuntu an (LAN)NAS freigeben.
Das wäre dann ja doch ein Portforwading?
Ich glaub ich steh wirklich auf dem Schlauch... sorry dafür.
Gruss
Everdt
Du must lediglich die CIFS-Ports (135,137 und 445 wenn micht nicht alles täuscht) für neue Verbindungen von (DMZ)Ubuntu an (LAN)NAS freigeben.
Das wäre dann ja doch ein Portforwading?
Nein, das sind Firewall Regeln... "Erlaube Port 445 von Ubuntu an NAS" - dabei wird immer die IP der NAS verwendet, niemals die IP der pfSense.
@em-pie
Wenn die komm. LAN->DMZ funktioniert, würde ich mir über die IPFire erstmal keine Gedanken machen
Zitat von @SlainteMhath:
@em-pie
Wenn die komm. LAN->DMZ funktioniert, würde ich mir über die IPFire erstmal keine Gedanken machen
@em-pie
Wenn die komm. LAN->DMZ funktioniert, würde ich mir über die IPFire erstmal keine Gedanken machen
Jo, hast du recht... Wenn man mal genauer drüber nachdenkt
Naja, aber somit hat er jetzt zumindest auf dem Schirm, dass die Pakete in jedem Fall über die IPFire "rutschen", da diese ja offensichtlich das Gateway für die DMZ ist, da die Kommunikation LAN-DMZ zunächst zu funktionieren scheint....
Naja, aber somit hat er jetzt zumindest auf dem Schirm, dass die Pakete in jedem Fall über die IPFire "rutschen", da diese ja offensichtlich das Gateway für die DMZ ist, da die Kommunikation LAN-DMZ zunächst zu funktionieren scheint....
Naja vielleicht gibt's ja auch einen entsprechenden routing Eintrag auf dem Ubuntu... aber da würde ich jetzt mit Hinsicht auf den Kenntnisstand des TOs nicht drauf eingehen 
Die pfSense blockt alles aus der DMZ ab.
WAS ist denn die DMZ ? Das 192.168.10.0er Segment ?Wäre ja Blödsinn, denn das ist keine richtige DMZ. Oder ist das das Segment wo das NAS drin ist ??
Naja, aber somit hat er jetzt zumindest auf dem Schirm, dass die Pakete in jedem Fall über die IPFire "rutschen", da diese ja offensichtlich das Gateway für die DMZ ist, da die Kommunikation LAN-DMZ zunächst zu funktionieren scheint....
Naja vielleicht gibt's ja auch einen entsprechenden routing Eintrag auf dem Ubuntu... aber da würde ich jetzt mit Hinsicht auf den Kenntnisstand des TOs nicht drauf eingehen Nun, als ursprünglicher Oracle DBA und nun Projektleiter ERP bin ich wohl in der IT Zuhause, aber wie du absolut richtig erkannt hast: definitiv nicht im Bereich Netzwerk
Aber ich stell mich aktuell echt doof an:
Wollt ihr mir sagen, dass ich auf der ipFire eine Route erstellen soll, um alle Pakete für das NAS an die WAN-Seite der pfSense zu schicken? Und dort dann die entsprechenden Ports öffnen?
Also: Ubuntu --> ipFire (Gateway) --> pfSense (192.168.10.2) (Ports offen) --> NAS
Naja vielleicht gibt's ja auch einen entsprechenden routing Eintrag auf dem Ubuntu... aber da würde ich jetzt mit Hinsicht auf den Kenntnisstand des TOs nicht drauf eingehen
Ich dachte, dass das eben nicht so sein soll, wie em-pie im ersten Post erklärt hat...?
Zitat von @aqui:
Wäre ja Blödsinn, denn das ist keine richtige DMZ. Oder ist das das Segment wo das NAS drin ist ??
Die pfSense blockt alles aus der DMZ ab.
WAS ist denn die DMZ ? Das 192.168.10.0er Segment ?Wäre ja Blödsinn, denn das ist keine richtige DMZ. Oder ist das das Segment wo das NAS drin ist ??
Das versteh ich jetzt nicht. Wieso sollte das 192.168.10.0/24 Segment nicht die DMZ sein?
Kommst du denn aktuell irgendwie an die Ubuntu-Kiste dran (SSH)?
Wenn ja, mach mal ein traceroute auf das NAS vom Uuntu-Server aus.
Dann wissen wir schon mal, welchen Weg die Kiste geht
@aqui
in meinen Augen hat er doch genau eine DMZ abgegildet: https://www.elektronik-kompendium.de/sites/net/0907241.htm
Der Ubuntu-Server steht in der DMZ, das einzige, was er nur vor hat, ist von der DMZ aus einen Zugriff zur NAS zu ermöglichen.
Wenn ja, mach mal ein traceroute auf das NAS vom Uuntu-Server aus.
Dann wissen wir schon mal, welchen Weg die Kiste geht
@aqui
in meinen Augen hat er doch genau eine DMZ abgegildet: https://www.elektronik-kompendium.de/sites/net/0907241.htm
Der Ubuntu-Server steht in der DMZ, das einzige, was er nur vor hat, ist von der DMZ aus einen Zugriff zur NAS zu ermöglichen.
Kommst du denn aktuell irgendwie an die Ubuntu-Kiste dran (SSH)?
Wenn ja, mach mal ein traceroute auf das NAS vom Uuntu-Server aus.
Dann wissen wir schon mal, welchen Weg die Kiste geht
Wenn ja, mach mal ein traceroute auf das NAS vom Uuntu-Server aus.
Dann wissen wir schon mal, welchen Weg die Kiste geht
Das geht alles. Anbei die Ergebnisse:
@aqui
in meinen Augen hat er doch genau eine DMZ abgegildet: https://www.elektronik-kompendium.de/sites/net/0907241.htm
Der Ubuntu-Server steht in der DMZ, das einzige, was er nur vor hat, ist von der DMZ aus einen Zugriff zur NAS zu ermöglichen.
in meinen Augen hat er doch genau eine DMZ abgegildet: https://www.elektronik-kompendium.de/sites/net/0907241.htm
Der Ubuntu-Server steht in der DMZ, das einzige, was er nur vor hat, ist von der DMZ aus einen Zugriff zur NAS zu ermöglichen.
Puh... und ich dachte schon ich hätte noch n grösseres Problem
Hallo,
also normaler weise baue ich hinter einen Router oder eine Firewall nur eine zweite wenn da niemand hinter
kommen soll und das zweite Netzwerk auch vom ersten mittels unterschiedlicher Firmware komplett
abgeschottet sein soll. Denn das erste Netzwerk kann dann entweder Ports geöffnet haben und es
können auch Protokolle weitergeleitet werden.
Wenn man so eine Dual Homed oder Bastion Host Sache aufsetzt dann auch alles in die DMZ rein was von
außen erreichbar sein soll. Also auch das NAS. Ansonsten einen Switch dahinter und einen in die DMZ Zone
rein und man spart sich gleich die zweite Firewall komplett auf zum spielen, üben oder als Ersatz oder gar
für einen HA Einsatz mit nur einer Firewall Software.
Gruß
Dobby
also normaler weise baue ich hinter einen Router oder eine Firewall nur eine zweite wenn da niemand hinter
kommen soll und das zweite Netzwerk auch vom ersten mittels unterschiedlicher Firmware komplett
abgeschottet sein soll. Denn das erste Netzwerk kann dann entweder Ports geöffnet haben und es
können auch Protokolle weitergeleitet werden.
Wenn man so eine Dual Homed oder Bastion Host Sache aufsetzt dann auch alles in die DMZ rein was von
außen erreichbar sein soll. Also auch das NAS. Ansonsten einen Switch dahinter und einen in die DMZ Zone
rein und man spart sich gleich die zweite Firewall komplett auf zum spielen, üben oder als Ersatz oder gar
für einen HA Einsatz mit nur einer Firewall Software.
Gruß
Dobby
Hallo,
also normaler weise baue ich hinter einen Router oder eine Firewall nur eine zweite wenn da niemand hinter
kommen soll und das zweite Netzwerk auch vom ersten mittels unterschiedlicher Firmware komplett
abgeschottet sein soll. Denn das erste Netzwerk kann dann entweder Ports geöffnet haben und es
können auch Protokolle weitergeleitet werden.
Wenn man so eine Dual Homed oder Bastion Host Sache aufsetzt dann auch alles in die DMZ rein was von
außen erreichbar sein soll. Also auch das NAS. Ansonsten einen Switch dahinter und einen in die DMZ Zone
rein und man spart sich gleich die zweite Firewall komplett auf zum spielen, üben oder als Ersatz oder gar
für einen HA Einsatz mit nur einer Firewall Software.
also normaler weise baue ich hinter einen Router oder eine Firewall nur eine zweite wenn da niemand hinter
kommen soll und das zweite Netzwerk auch vom ersten mittels unterschiedlicher Firmware komplett
abgeschottet sein soll. Denn das erste Netzwerk kann dann entweder Ports geöffnet haben und es
können auch Protokolle weitergeleitet werden.
Wenn man so eine Dual Homed oder Bastion Host Sache aufsetzt dann auch alles in die DMZ rein was von
außen erreichbar sein soll. Also auch das NAS. Ansonsten einen Switch dahinter und einen in die DMZ Zone
rein und man spart sich gleich die zweite Firewall komplett auf zum spielen, üben oder als Ersatz oder gar
für einen HA Einsatz mit nur einer Firewall Software.
Da geb ich dir grundsätzlich in allem Recht. Leider ist das "NAS" ein Storagesystem im 5-stelligen Eurobereich (ich habs gebraucht und sehr viel günstiger gekriegt), darum fällt das weg. Ich will den Nutzen unbedingt in der DMZ und im LAN haben.
Mal davon abgesehen, dass ich sonst noch ein zweites Storagegerät haben müsste, was zu teuer und auch unsinnig wäre.
Das Einzige, was eventuell möglich wäre:
Das Storagesystem hat mehrere physikalische Nics. Ich könnte natürlich einen davon ins vLan der DMZ und die anderen in das vLan intern hängen.
Aber: bei dieser Lösung verliere ich die Möglichkeit, den Durchsatz per LACP zu erhöhen....
btw:
Stell ich mich so schwierig an?
Ich dachte, dass das ein nicht all zu unübliches Problem ist und ich einfach nicht weiss wie. Langsam habe ich den Eindruck, dass meine Idee, wie das Problem zu lösen sei nicht dem Standart entspricht...
Hallo nochmal,
Firewall auch eine DMZ aufmachen kann, und die kann man auch noch mittels Snort oder Suricata gut absichern!
Und wenn man eine Dual Homed DMZ oder Router Kaskade anlegt, dann wird in der Regel und aus Sicherheitsgründen
dort kein Port geöffnet und auch kein Protokoll weitergeleitet, ansonsten ist das ganze Konstrukt völlig wertlos und
man wäre mit einem ordentlichen Switch und einer Firewall die ein LAN und eine DMZ bereit stellt wesentlich besser
oder übersichtlicher gefahren! Ist wie bei den Gefängnissen wo erst eine Tür bzw. ein Tor geöffnet wird und wenn das
dann wieder geschlossen wird, dann erst wir die zweite Tür oder das Tor geöffnet. Und wenn nun beide Türen oder
Tore zugleich geöffnet werden dann ist das Sicherheitspotential dieser "Schleuse" völlig wertlos! Eventuell erklärt
das meine Ablehnung an Dein Anliegen etwas besser.
abgesichert, gar keine frage, ansonsten ist es immer besser alles was Kontakt zum Internet haben soll in die
DMZ zu stellen und alles was keinen Kontakt zum Internet haben soll in das LAN.
eben auch gerne einmal machen wollen was möglich ist, nur ob das eben immer Sinn macht ist eben eine andere
Frage. Ich kaufe zusätzlich keinen Sicherungsriegel für die Tür und lasse dann das Fenster auf!
anders, aber bei einigen Sachen gibt es früher oder später eben immer Probleme damit und dann ist das eben
sagen wir mal aus Erfahrung vorher besser jemandem davon abzuraten als später andere Probleme mit Ihm
zu lösen.
Ich würde heute gar keinen Port mehr am WAN öffnen wollen oder Protokolle weiterleiten, denn das ist einfach zu
gefährlich und man kann auch alles gut per VPN erreichen. und wenn dort etwas stehen muss oder soll, dann lieber
ein altes gebrauchtes NAS kaufen und dort alles drauf packen und wenn dem dann was passieren sollte ist das auch
kein Problem. Macht aber auch jeder anders, also nimm mir das nicht so "krumm", andere Leute haben auch andere
Meinungen dazu und dafür ist so ein Forum ja auch nicht schlecht!
Gruß
Dobby
Da geb ich dir grundsätzlich in allem Recht. Leider ist das "NAS" ein Storagesystem im 5-stelligen Eurobereich
(ich habs gebraucht und sehr viel günstiger gekriegt), darum fällt das weg.
Ob billig oder teuer ist doch im Endeffekt egal oder? Es geht hier doch darum das man mittels einer (pfSense)(ich habs gebraucht und sehr viel günstiger gekriegt), darum fällt das weg.
Firewall auch eine DMZ aufmachen kann, und die kann man auch noch mittels Snort oder Suricata gut absichern!
Und wenn man eine Dual Homed DMZ oder Router Kaskade anlegt, dann wird in der Regel und aus Sicherheitsgründen
dort kein Port geöffnet und auch kein Protokoll weitergeleitet, ansonsten ist das ganze Konstrukt völlig wertlos und
man wäre mit einem ordentlichen Switch und einer Firewall die ein LAN und eine DMZ bereit stellt wesentlich besser
oder übersichtlicher gefahren! Ist wie bei den Gefängnissen wo erst eine Tür bzw. ein Tor geöffnet wird und wenn das
dann wieder geschlossen wird, dann erst wir die zweite Tür oder das Tor geöffnet. Und wenn nun beide Türen oder
Tore zugleich geöffnet werden dann ist das Sicherheitspotential dieser "Schleuse" völlig wertlos! Eventuell erklärt
das meine Ablehnung an Dein Anliegen etwas besser.
Ich will den Nutzen unbedingt in der DMZ und im LAN haben.
Dann stelle ich das in die DMZ rein und kann aus dem LAN auch drauf zugreifen, fertig.Mal davon abgesehen, dass ich sonst noch ein zweites Storagegerät haben müsste, was zu teuer und auch
unsinnig wäre.
Verstehe ich jetzt nicht so ganz, man kann auch mittels Linux und Jails arbeiten und dann ist das etwas besserunsinnig wäre.
abgesichert, gar keine frage, ansonsten ist es immer besser alles was Kontakt zum Internet haben soll in die
DMZ zu stellen und alles was keinen Kontakt zum Internet haben soll in das LAN.
Das Einzige, was eventuell möglich wäre:
Das Storagesystem hat mehrere physikalische Nics. Ich könnte natürlich einen davon ins vLan der DMZ und
die anderen in das vLan intern hängen.
Stell Dir doch mal bitte vor dass Du die Tür abschließt und dann das Fenster und die Balkontür offen lässt!Das Storagesystem hat mehrere physikalische Nics. Ich könnte natürlich einen davon ins vLan der DMZ und
die anderen in das vLan intern hängen.
Aber: bei dieser Lösung verliere ich die Möglichkeit, den Durchsatz per LACP zu erhöhen....
Das ist doch wieder eine ganz andere Sache.btw:
Stell ich mich so schwierig an?
Ich denke heute ist das so, dass viele Leute sich selber mit der EDV/IT auseinander setzten müssen und dannStell ich mich so schwierig an?
eben auch gerne einmal machen wollen was möglich ist, nur ob das eben immer Sinn macht ist eben eine andere
Frage. Ich kaufe zusätzlich keinen Sicherungsriegel für die Tür und lasse dann das Fenster auf!
Ich dachte, dass das ein nicht all zu unübliches Problem ist und ich einfach nicht weiss wie. Langsam habe
ich den Eindruck, dass meine Idee, wie das Problem zu lösen sei nicht dem Standart entspricht...
Standard hin oder her da kann man ja immer drüber diskutieren, und jeder macht es anders oder braucht esich den Eindruck, dass meine Idee, wie das Problem zu lösen sei nicht dem Standart entspricht...
anders, aber bei einigen Sachen gibt es früher oder später eben immer Probleme damit und dann ist das eben
sagen wir mal aus Erfahrung vorher besser jemandem davon abzuraten als später andere Probleme mit Ihm
zu lösen.
Ich würde heute gar keinen Port mehr am WAN öffnen wollen oder Protokolle weiterleiten, denn das ist einfach zu
gefährlich und man kann auch alles gut per VPN erreichen. und wenn dort etwas stehen muss oder soll, dann lieber
ein altes gebrauchtes NAS kaufen und dort alles drauf packen und wenn dem dann was passieren sollte ist das auch
kein Problem. Macht aber auch jeder anders, also nimm mir das nicht so "krumm", andere Leute haben auch andere
Meinungen dazu und dafür ist so ein Forum ja auch nicht schlecht!
Gruß
Dobby
@em-pie
Eigentlich ist das nach Definition keine wirkliche DMZ.
Der gesamte Traffic des Client Segments an der pfSense plus der gesamte NAS Traffic gehen ja über dieses "DMZ" Segment. Eine wahre DMZ ist immer ein isoliertes Segment ohne Durchgangstraffic.
Sowas Gruseliges kann man dann nicht wirklich als DMZ bezeichnen, denn das ist Bastelkram aber sicher keine DMZ in dem Sinne..
Wenn überhaupt, dann müsste das Koppelsegment was die pfSense mit der ipFire verbindet eine isolierte Punkt zu Punkt Verbindung sein und die DMZ dann ein entsprechend gesichertes Segment was an der pfSense hängt wie Clients oder NAS.
Dann könnte man von einer DMZ sprechen.
Aber abgesehen davon klappt das natürlich auch so in diesem etwas gewöhnungsbedürftigen Design.
Mit den richtigen Regeln auf der pfSense ist da natürlich keine Tat das sofort zum Fliegen zu bringen.
Eigentlich ist das nach Definition keine wirkliche DMZ.
Der gesamte Traffic des Client Segments an der pfSense plus der gesamte NAS Traffic gehen ja über dieses "DMZ" Segment. Eine wahre DMZ ist immer ein isoliertes Segment ohne Durchgangstraffic.
Sowas Gruseliges kann man dann nicht wirklich als DMZ bezeichnen, denn das ist Bastelkram aber sicher keine DMZ in dem Sinne..
Wenn überhaupt, dann müsste das Koppelsegment was die pfSense mit der ipFire verbindet eine isolierte Punkt zu Punkt Verbindung sein und die DMZ dann ein entsprechend gesichertes Segment was an der pfSense hängt wie Clients oder NAS.
Dann könnte man von einer DMZ sprechen.
Aber abgesehen davon klappt das natürlich auch so in diesem etwas gewöhnungsbedürftigen Design.
Mit den richtigen Regeln auf der pfSense ist da natürlich keine Tat das sofort zum Fliegen zu bringen.
Hallo Zusammen
Besten Dank für die bis jetzt eingegangenen Inputs und Beiträge.
Das Thema ist sehr interessant und die vielen Ansichten durchaus bereichernd.
Aber:
Nun, um das ganze etwas zu vereinfachen eine Frage, unabhängig ob das so sinnvoll ist und/oder man es anders machen sollte:
Was muss ich wie und wo machen, um es genau so wie im ursprünglichen Post angefragt zu realisieren?
--> muss ich via ipFire zurück auf die pfSense oder nicht? welche Ports wo wie warum öffnen? usw....
Sobald ich das begriffen habe, kann ich mir auch Gedanken über andere Lösungen machen
Danke und Gruss
Everdt
Besten Dank für die bis jetzt eingegangenen Inputs und Beiträge.
Das Thema ist sehr interessant und die vielen Ansichten durchaus bereichernd.
Aber:
- Ob es nun eine "echte DMZ" oder eine "dirty DMZ" ist, ist mir persönlich eigentlich egal, denn wichtig für mich ist nur, dass alle aus dem Internet erreichbaren Geräte nicht im LAN stehen. So wie dargestellt habe ich es im Studium gelernt und dieser Lösung vertraue ich.
- Das Storagesystem in die DMZ stellen will ich nicht, da darauf auch Daten sind, welche nicht aus dem Internet erreichbar sein sollen und auch bei erfolgreicher Kompromittierung des Ubuntuservers maximal die Daten auf dem entsprechenden Share/Volume/iscsi gefährdet sind
- Ein zweites, billiges NAS für die DMZ kommt aufgrund der Datenmenge (>10TB) nicht in Frage
Nun, um das ganze etwas zu vereinfachen eine Frage, unabhängig ob das so sinnvoll ist und/oder man es anders machen sollte:
Was muss ich wie und wo machen, um es genau so wie im ursprünglichen Post angefragt zu realisieren?
--> muss ich via ipFire zurück auf die pfSense oder nicht? welche Ports wo wie warum öffnen? usw....
Sobald ich das begriffen habe, kann ich mir auch Gedanken über andere Lösungen machen
Danke und Gruss
Everdt
Am Ubuntu:
Route ins Netz 192.168.1.0/24 mit Gateway 192.168.10.2 eintragen
An der pfSense
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6
Das sollte eigentlich ausreichend sein, ausgehend davon, das auf der pfSense alles LAN -> WAN freigegeben ist.
Route ins Netz 192.168.1.0/24 mit Gateway 192.168.10.2 eintragen
An der pfSense
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6
Das sollte eigentlich ausreichend sein, ausgehend davon, das auf der pfSense alles LAN -> WAN freigegeben ist.
Statische Routen auf den Servern sollte man besserr vermeiden. Dort immer nur ein Default Gateway eintragen und die Route am Gateway selber eintragen. Router sollen routen
Also etwas abgewandelt und ausführlicher:
Am Ubuntu:
Default Route auf die IP Fire
Auf der IP Fire:
Statische Route ins Netz 192.168.1.0 /24 mit Gateway 192.168.10.2 (pfSense) eintragen
An der pfSense
Am WAN Port den Zugriff von RFC 1918 Netzen erlauben (Haken entfernen in Interfaces -> WAN -> Block Private and loopback networks )
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6 mit einer Regel am WAN Port
Achtung: Das klappt außschliesslich nur wenn das NAS die Session auf den Ubuntu Server initiiert. Also wenn das NAS ein entsprechedes Mapping aufbaut.
Soll es auch umgekehrt gehen das der Ubuntu Server eine Verbindung auf das NAS aufbauen kann musst du zwingend noch eine NAT 1:1 Regel erstellen, denn ansonsten bleibt der Unbuntu Verbindungsversuch an der NAT Firewall der pfSense hängen. Diese macht ja NAT am WAN Port.
Wenn diese Richtung Ubuntu -> NAS auch gewollt ist sollte man sinnvollerweise das NAT komplett deaktivieren auf dem WAN Port im pfSense Setup.
Das wars...damit klappt das auf Anhieb.
Also etwas abgewandelt und ausführlicher:
Am Ubuntu:
Default Route auf die IP Fire
Auf der IP Fire:
Statische Route ins Netz 192.168.1.0 /24 mit Gateway 192.168.10.2 (pfSense) eintragen
An der pfSense
Am WAN Port den Zugriff von RFC 1918 Netzen erlauben (Haken entfernen in Interfaces -> WAN -> Block Private and loopback networks )
Ziel-Ports 137/udp, 138/udp 139/tcp und 445/tcp freigeben von WAN/192.168.10.11 -> LAN/192.168.1.6 mit einer Regel am WAN Port
Achtung: Das klappt außschliesslich nur wenn das NAS die Session auf den Ubuntu Server initiiert. Also wenn das NAS ein entsprechedes Mapping aufbaut.
Soll es auch umgekehrt gehen das der Ubuntu Server eine Verbindung auf das NAS aufbauen kann musst du zwingend noch eine NAT 1:1 Regel erstellen, denn ansonsten bleibt der Unbuntu Verbindungsversuch an der NAT Firewall der pfSense hängen. Diese macht ja NAT am WAN Port.
Wenn diese Richtung Ubuntu -> NAS auch gewollt ist sollte man sinnvollerweise das NAT komplett deaktivieren auf dem WAN Port im pfSense Setup.
Das wars...damit klappt das auf Anhieb.
1Vielen Dank, so hab ich es nun zum fliegen gebracht
An alle:
Besten Dank für die vielen Inputs und Vorschläge.
Ich habe mir etwas Gedanken dazu gemacht, was ich mal gelernt habe und was ich Kunden dauernd empfehle und musste feststellen, dass ich selbst gegen vieles davon verstosse
Nach langem probieren, nachdenken und lesen sieht meine Lösung nun wie folgt aus:
- Ubuntu steht in der DMZ
- Ein zweiter, kleinerer und billiger NAS-Speicher (Synology) steht auch in der DMZ
- Das Storagesystem steht im LAN
- Die pfSense (LAN-DMZ) ist auf WAN-Seite geschlossen und es wird nichts geroutet, geöffnet oder sonst etwas
- Die Daten auf dem DMZ-NAS werden in der Nacht via cronjob AUS dem LAN heraus synchronisiert
Begründung:
- Was aus dem Internet erreichbar ist gehört nicht ins LAN
- Muss ich wirklich so viele Daten permanent aus dem Internet erreichbar haben? --> nach genauerer Analyse ist die Antwort NEIN und der Zusatz: das will ich eigentlich gar nicht
- Storage in der DMZ würde bedeuten, dass Daten, welche nicht ins Internet gehören, trotzdem dort liegen würde --> NoGo
- KISS
Somit nochmals Danke an alle und Thema geschlossen.
Gruss
Everdt
so hab ich es nun zum fliegen gebracht
Glückwunsch ! was ich mal gelernt habe und was ich Kunden dauernd empfehle und musste feststellen, dass ich selbst gegen vieles davon verstosse
Einsicht ist der erste Weg zur Besserung ! ist auf WAN-Seite geschlossen und es wird nichts geroutet,
Du meinst den WAN Port, oder ? Aber das nix geroutet wird ist natürlich Unsinn. Die FW muss ja routen wenn irgendwelcher Traffic fliessen muss wie auch immer. Ohne Routing hättest du Stillstand.War wohl eher ein Freudscher Versprecher
Letztlich sind aller alle deine Lösungsansätze absolut richtig und OK. Die Begründung umso mehr.
Fazit: Entspanntes Wochenende...
Du meinst den WAN Port, oder ? Aber das nix geroutet wird ist natürlich Unsinn. Die FW muss ja routen wenn irgendwelcher Traffic fliessen muss wie auch immer. Ohne Routing hättest du Stillstand.
War wohl eher ein Freudscher Versprecher
War wohl eher ein Freudscher Versprecher
Es wird nichts von aussen reingelassen, was nicht von innen angefragt wurde. Kein Portöffnung, Weiterleitungen, usw.
Selbstverständlich wird nicht nichts geroutet (doppelte Verneinung am Freitag, jetzt wirds heftig
)Einsicht ist der erste Weg zur Besserung !
Man ist ja bemüht
Letztlich sind aller alle deine Lösungsansätze absolut richtig und OK. Die Begründung umso mehr.
Fazit: Entspanntes Wochenende...
Fazit: Entspanntes Wochenende...
Das wünsch ich dir auch.