OPNsense Forum
International Forums => German - Deutsch => Topic started by: elektron on August 27, 2018, 11:49:25 am
-
moin netzgemeinde
ich habe hier folgenden aufbau
fritzbox7590---opnsense---switch---nas
am switch haengen natuerlich alle clients und wlang wird ueber eine alte fritzbox vom switch aus betrieben.
ich habe nun einen accont bei sel#host und will vom i-netz aus die nas ansprechen.
in der opnsense habe ich die dyndns konfiguriert. portweiterleitungen von der wanschnittstelle auf die lanschnittstelle sind eingetragen.
wo muss ich nun die dyndns aktivieren...auf der fritzbox, auf der opnsense oder auf der nas ?
irgendwie hat das nicht recht hin. vorher war die nas ohne die OPNsense einwandfrei zu erreichen.
hat einer eine idee ?
lg
e!
-
Hallo,
ich habe zuhause genau das gleiche realisiert, ich habe es wie folgt gelöst:
die DYNdns in die Fritte eingetragen, dann eine Portweiterleitung an die OPN erstellt.
und eine NAT Regel dafür angelegt.
funktioniert einwandfrei.
Gruß
Rocker
-
Moin,
wie Rocker bereits geschrieben hat: dyndns auf der FritzBox einrichten.
In der FritzBox würde ich dann die OPNsense als Exposed-Host einrichten (Aller Traffic von außen wird durch die FritzBox an die OPNsense geroutet). Da brauchst Du Dich gar nicht mehr um die FritzBox zu kümmern.
Anschließend kannst du dann auf der OPNsense die Portweiterleitung auf das NAS einrichten, wobei ich mir gleich überlegen würde, ob ein grundsätzlicher Zugriff nur per VPN nicht die bessere Wahl wäre! Da bietet die OPNsense ja alle Möglichkeiten.
Gruß
Dirk
PS: Wenn die OPNsense hinter der Fritbox hängt dürfen die RFC1918-Netze in der WAN-Konfiguration der OPNsense nicht geblockt werden!
-
Liebe Community,
mein Netzwerk Setup ist in etwa so eingerichtet wie bei meinem Vorredner:
Internet --- Fritzbox7590 -(192.168.178 subnet)- opnsense -(192.168.2 subnet)- switch --- nas
Sinn soll nun sein, die NAS über das Internet zu erreichen. Die DynDNS ist erfolgreich an der Fritzbox eingerichtet. Die Portweiterleitung harperts nun aber. Die Bogon Netzwerke werden blockiert, ansonsten RFC1918 Addressen aber nicht. Eine exposed host Einstellung wollte ich vermeiden.
NAT wurde eingerichtet und die automatisierte Regel auf der WAN Schnittstelle wurde auch erstellt. Jetzt bin ich mir nicht sicher ob die Eingaben bei NAT stimmen:
autom. Firewallregel WAN:
IPv4 TCP *(Quelleadresse) *(Quellport) 192.168.x.x(Ziel) 5000(Zielport) *(Gateway)
NAT:
WAN TCP *(Quelladresse) *(Quellports) 192.168.x.x(Zieladresse) 5000(Zielport) 192.168.x.x(NAT) 5000
Müssen noch eigenständig Regeln an der OPT1 eingetragen werden?
außerdem Fehlermeldung: Default deny rule bei igb1 (WAN)
Jemand Ideen? Danke!
-
> Eine exposed host Einstellung wollte ich vermeiden.
Wie soll dann die OPNsense die Daten abbekommen von der FB?
Willst du wirklich für jeden Schnick und Schnack jedes Mal 2 Geräte pflegen und an der Sense UND der FB schrauben bis es geht? Ist doch wirklich unnötig!
> autom. Firewallregel WAN:
Da automatisch stimmt die auch, wenn ist was mit dem Forwarding falsch.
> WAN TCP *(Quelladresse) *(Quellports) 192.168.x.x(Zieladresse) 5000(Zielport) 192.168.x.x(NAT) 5000
Solang du überall alles aus-x-t ist das sinnlos da helfen zu wollen, weil man den Fehler nicht sieht. Private Adressen auszu-x-en ist auch sinnbefreit, es kann dir eh niemand von außen an deine Geräte ran.
Trotzdem nochmal: Wenn du an der FRITZBOX KEINE WEITERLEITUNG machst, wird auch bei der Sense nichts ankommen. Darum schreibt man auch überall "macht exposed Host auf Sense" rein, damit man alles sauber zentral über die Sense regeln kann und nicht jeden Schnipsel an 2 Geräten rumkonfigurieren muss. So weißt du nicht ob dir der Filter oder das NAT an der FB dazwischengrätscht.
-
Liebe Community,
unter zur Hilfename des englischsprachigen Tutorials gelang das Portforwarding ganz zügig. Zum einen sollte man einen Aliasnamen für den entsprechenden Host nutzen sowie die Besonderheiten in den erweiterten Einstellungen.
Ein Hinweis noch für die DynDNS Nutzung, die stets nur auf einem Gerät (hier Fritzbox) laufen darf, da sonst Fehlermeldungen seitens des Betreibers produziert werden.
Danke für den Hinweis, daß man an zwei Geräten herumschrauben muss, aber letztendlich ging es dann doch mit den Aliasen ziemlich fix. Nun haben wir zumindest die Möglichkeit geschaffen ohne exposed host zu arbeiten.
Grüße
OPNsenseN00b
-
> Nun haben wir zumindest die Möglichkeit geschaffen ohne exposed host zu arbeiten.
Um neugierig zu sein: und was genau soll das für einen Vorteil bringen?
> Ein Hinweis noch für die DynDNS Nutzung, die stets nur auf einem Gerät (hier Fritzbox) laufen darf
DynDNS sollte selbstredend nur von einem System aktualisiert werden, welches das ist, sollte aber relativ egal sein, denn auch die Sense kann das m.W. selbst übernehmen.
Grüße Jens
-
> Nun haben wir zumindest die Möglichkeit geschaffen ohne exposed host zu arbeiten.
Um neugierig zu sein: und was genau soll das für einen Vorteil bringen?
Nun letzendlich soll eine mehrstufige Firewall hergestellt werden über dessen exakten Aufbau noch entschieden werden soll. Als Ziell soll ein Postfix Server hinter einer zweiten Firewall laufen bzw. in einer internen DMZ. Zunächst ging es mir aber darum einfach zu beginnen.
Beste Grüße
OPNsenseN00b
-
> Nun letzendlich soll eine mehrstufige Firewall hergestellt werden über dessen exakten Aufbau noch entschieden werden soll. Als Ziell soll ein Postfix Server hinter einer zweiten Firewall laufen bzw. in einer internen DMZ. Zunächst ging es mir aber darum einfach zu beginnen.
Vielleicht verstehe ich die Intention nicht, aber ich sehe die FB keinesfalls als Firewall an, sondern eher als Router auf der WAN Seite, dem ich aus $Gründen nicht vertraue und den ich nicht als "eigenes Gerät" ansehe. Dementsprechend sehe ich darin auch keine Firewall - auch wenn sie sich darin gerne so schimpft ;)
Den DMZ Wunsch verstehe ich schon, der lässt sich heute aber meist simpler mit einem "Dreibein" (Host mit 3 Netzbereichen) einfacher und ähnlich sicher konzipieren als ein altes klassisches zweistufiges Design mit 2 Firewalls und zwei Beinen. Zudem gibt es Diskussionen, dass ein "Dreibein" gegenüber der mehrstufigen Hierarchie weiterhin Vorteile hat, da bei einer Kompromittierung der FWL1 und ggf. Übernahme eines Hosts in der DMZ der Verkehr des LANs nicht durch die DMZ läuft um ins Internet zu gehen, was die Isolationsschicht eigentlich sogar verbessert.
Aber das nur mal eingeworfen, bin trotzdem gespannt, was ihr da baut :)
-
Moin liebe Community,
ich habe kurzum auf die zur Verfügung gestellten Netzdiagramme bzw. Firewall Architekturen zurückgegriffen und teilweise modifiziert. Mit der vorgeschlagenen mupltiplen DMZ wäre es prinzipiell möglich, beliebig viele Instanzen in Reihe zu schalten. Die Firewallarchitektur ließe sich also je nach Bedarf an das Sicherheitsbedürfnis anpassen. Je weiter von der Providerseite in der Architektur entfernt, desto restriktiver werden die zu überwindenen Hürden. Inwieweit sich dies so sinnvoll umsetzen läßt, ist in Teilen fraglich, eben nur eine Idee.
WAN / Internet
:
: DialUp-/PPPoE-/Cable-/whatever-Provider
:
.-----+-----.
| Gateway | (or Router, CableModem, whatever)
'-----+-----'
|
WAN | IP or Protocol
|
.-----+------. externe DMZ .------------.
| OPNsense1 +-----------------+ DMZ-Server| z.B. Webserver, DNS
'-----+------' OPT1 '------------'
|
LAN1 |
|
.-----+------. LAN1 .----------.
---| LAN-Switch+-------+Mailserver| z.B. postfix
'-----+------' '----------`
|
LAN1 |
|
.-----+------. interne DMZ .-------------.
|OPNsense2 +-----------------+ File-Server | z.B MySQL
'-----+------' OPT2 '-------------'
|
LAN2 |
|
.-----+------. LAN2 .-----------.
---| LAN-Switch+-------+LAN-Clients|
'-----+------' '-----------`
-
Ja das kann man natürlich machen. Ich würde aber wetten, dass du das in keinerlei größerem Setup jemals so finden wirst. :) Und auch wenn wir inwzischen OT sind ist die Diskussion und der Austausch spannend :)
Ich habe selbst noch die alten O'Reilly Schmöker zu Hause im Regal. Building Internet Firewalls. Bastion Hosts. Security. Alles tolle Grundlagenwerke. Und dort werden die verschiedenen Ansätze auch durchaus noch erläutert und geklärt. Das höchste der Gefühle was ich in meinen 20+ Jahren Praxis aber - selbst in großen Firmen - gesehen haben, waren zwei Schichten. Eine externe, eine interne. So wie du es schon fast mit drei Schichten hintereinander packst, sehe ich das nie. Zumal dein Beispiel für mich mehrere Probleme aufweist:
- Webserver in DMZ, völlig OK. Dito DNS. Was aber bringt den Mailserver dazu "hinter" den anderen beiden zu stehen? Das macht keinen Sinn. Ein Mailserver hat oft genug ein noch wesentlich höheres Aufkommen an externen Verbindungen als ein Webserver oder DNS, wenn der nicht in der DMZ steht, wer dann! Ein ausgehender oder rein interner Mailserver mag im LAN dafür OK sein.
- Datenbank die Verbindungen schnell von Diensten in der DMZ handeln muss in ein 1-2 Hop entferntes anderes Netz packen? Meh... Kann man machen, ist aber kaum sinnvoll. DBs sind allermeistens Backends, über die eh nicht vom Internet zugegriffen wird, sondern aus der gleichen Zone (DNS, Mail bspw.) und die das auch schnell ohne viel Overhead handeln muss. Zugriffe sind da meist eh nur auf Servicelevel erlaubt (also 3306/tcp bspw.) und wenn dir jemand den Mail/Web/DNS knackt und dort die Zugangsdaten ausliest, kann er eh alles was der Service kann. Zugriff auf Server ist hoffentlich eh nur per SSH möglich (und per Key) somit sind die meisten Angriffsvektoren die Software und Bugs daraus. Lädt dir jemand auf den Webserver eine PHP Shell (oft genug der Fall), dann kann er aus den PHP Configs auch die DB Info auslesen. Ein besserer Schutz in einem anderen VLAN/DMZ bringt das der DB somit kaum.
- Je nachdem wie Paranoid man da rangeht, könnte man argumentieren, dass Multi-Tier Architekturen immer auch anfällig sein könnten für Paket Mitschnitte (tcpdump) (wenn Switche dumm genug agieren, da gibts leider immer wieder genug Geschichten). Das hat man an der Stelle natürlich bei einem größeren zentralen System mit 3-4 diversen DMZ LAN/VLANs nicht in der Art.
Und wem der letzte Punkt theoretisch vorkommt: U.a. von HP gab es große Switchreihen für Enterprise Einsatz (andere Hersteller hatten das auch), bei denen es intern Bugs bei den MAC Adress Tables und Switchport Bindings gab. Mit dem Resultat dass u.a. Kundenserver an einem Switchport Traffic von anderen Servern mitempfangen haben. Ein "tcpdump" war dort damals sehr(!) interessant und aufschlußreich... Trat übrigens bei einem großen deutschen Hoster auf, also kein vereinzeltes kleines Problem ;)