Messages

Wir werden IMHO noch viel mehr "böses" lesen, bevor es besser wird. Durch solche gehypte Buzzwords wie das von der Kanzlerin groß gelobte Industrie 4.0 werden wir eine Masse an IoT und sonstigen Gegenständen aus dem Alltag und Haushalt erleben, die eben "I4.0"-like einfach mal ne Netzwerkbuchse oder - noch schlimmer - WLAN spendiert bekommen. Leider wird das aber meist von Leuten designed, die bislang keinerlei Ahnung von Netzwerken, Infrastruktur und vor allem: Sicherheit, Authentifizierung und Autorisierung haben.  Bei vielen ist es damit getan, dass sie ihrem Gerät ne RJ45 Buchse und nen IP Stack spendieren. Dass solche Kisten dann aber plötzlich (planlos oder geplant) am Internet hängen ... nun davon haben wir ja schon den ersten Fallout gesehen. Standardpasswörter, in HW verdrahtete Logins, alte Cypher etc. die nicht nachgerüstet werden können, etc. etc. wird man nun leider noch viel häufiger antreffen, denn kein Hersteller will jetzt nicht mehr "smart" sein. Und daraus nun die Perlen zu ziehen, die sich wirklich ordentlich mit dem Thema beschäftigt haben wird schwer...

Warum sollte die Sense das nicht können? :o

Davon abgesehen, braucht es dafür OpnSense per se nicht wirklich. Du kannst die DynDNS Geschichten auch per DDNS (RFC2136) machen sofern die Domain, die die Einträge haben soll bei einem Provider ist (oder dir selbst), und das ordentlich unterstützt wird. Dann entfällt irgendein DynDNS Dienstleister und du machst es noch dazu mit deinem eigenen Domainnamen.

Ist natürlich ein wenig Glaubensfrage, aber ich hab in all meinen Jahren bisher noch immer keinen wirklich gelungen ausgeführten Angriff gegen VLAN Konfigurationen gesehen. Wenn der Switch nicht gerade völlig panne ist und die Konfiguration halbwegs durchdacht, bin ich der Meinung, dass das für den Einsatzzweck genügt. Ich weiß ja nicht in welchem Stil du was extern anbieten willst und ob das deine Heim-Leitung ist, aber ich würde behaupten wollen, dafür reichts dicke. :)

Grüße

> Aus Sicherheitsgründen. So bin ich sicher, dass die FritzBox schon nur 443/TCP (und 80/TCP) an OPNsense weitergibt.
> Klar ist mehr Aufwand als der Exposed Host aber stört mich nicht, da nehme ich lieber den Tick mehr Sicherheit ;)

Was hat das mit Sicherheit zu tun? Gefilter wird eh sinnvollerweise auf der Sense. Ob du vorher dem Guffelfilter oder dem NATting der Fritz Box mehr traust als einem Gerät dass du selbst baust und das tut was du ihm sagst, sei mal dahingestellt, aber Sinn macht es für mich nicht, ein Mehr an Sicherheit kann ich auch nicht erkennen. Denn nur weil du alles weiterleitest erlaubst du es an der Sense trotzdem nicht. Plus du hast unnötig höheren Komplexitätsaufwand wenn mal was an Ports dazukommt und bist bei Debugging immer an zwei Geräten dran. Da sehe ich keinen Gewinn.

> daher kein Problem.

Jein. Du nutzt trotzdem DHCP und verlässt dich so bei der IP Vergabe auf externe Geräte. Statische IPs booten schneller, sind weniger fehleranfälliger und man hat zusätzlich die externe Abhängigkeit raus, dass die Sense bzw. der DHCP dort laufen muss damit die VMs überhaupt sinnvoll laufen. Finde ich weniger sinnvoll. Ohne diese Abhängigkeit kann man problemlos auch mal eine Test VM oder eine neue VM deployen ohne dass man zusätzlich vorher Hand an die Firewall anlegen muss. Ich sehe da nur unnötige externe Abhängigkeit.

> sondern auch noch einen WLAN Accesspoint, der Strom zieht.

Dafür aber je nach AP auch wesentlich mehr Möglichkeiten. Zudem sind viele APs auch per PoE fütterbar (Strom) somit keine wahnsinnigen Killerverbraucher. Die Rechnung kannst du dann selbst aufmachen, ob dich die paar Cent für den AP arm machen ;) Zudem wird die vorgeschaltete Fritzbox bei abgeschaltetem WLAN Modul auch weniger Strom verbrauchen, somit ist die Bilanz nicht ganz so schwarz. Und nur wegen umgerechnet ein paar Euro im Jahr eine schlechte(re) Lösung mit sich rumschleppen - da musst du auch deine eigene Arbeitszeit und sinnvolles Arbeiten mit einberechnen, was dir das wert ist.

> Die FritzBox einfach durch einen Router mit 2 Interfacen (DMZ und LAN) + WLAN zu ersetzen ist leider auch schwierig, da die FritzBox auch DECT macht....

Davon hatte ich auch nichts geschrieben, die Fritte kann vorgeschaltet ja problemlos Upstream Router/Gateway plus DECT machen. Ist ja kein Drama. Aber alles andere abschalten, WLAN aus, Ports 3-4 abschalten (oder Eco) etc. und du wirst sehen dass die Kiste auch weniger Strom braucht. Und die Sense als exposed Host dahinter und als richtige Firewall bauen.

> spricht eigentlich auch überhaupt nichts dagegen es so zu lassen oder?

Für mich persönlich spricht da alles dagegen. Weil es komplett verkehrte Welt ist. Man baut sinnvollerweise eine Firewall Architektur von böse nach gut auf bzw. von untrustworthy nach fully trusted. WAN/Internet ist dabei rote Zone, da glaube ich gar nichts. Ergo ist WAN draußen. Da die Fritte meist vom Provider kommt oder gestellt wird, gehört die für mich ebenso als WAN behandelt, ergo haben da auch keine LAN Clients oder sonstwas drin zu suchen. Bei der Fritzbox kann ich keinerlei Filter wirklich setzen. Das ist für mich keine echte Firewall sondern ein freundliches Bastelwerk. Heißt aber auch, hinter der Fritzbox ist alles plötzlich "fully trusted" und darf einfach mit dem Netz sprechen. Und jetzt setzt du dahinter plötzlich noch ne Zone, die eigentlich eher "partially trusted" ist. Also die nur begrenzt sicher ist, da sie aktiven Kontakt mit der Außenwelt hat. Wo du Traffic reinlässt. Und den leitest du vorher aber komplett durch deine trusted Zone durch. Sorry, das wäre mir (subjektiv) an der Stelle völlig abwegig vom Aufbau her.

Grüße

> Was verwendet ihr für OpenVPN?

1194/udp normal, 443/tcp für den Ausnahmefall, genau wegen

> Genauer gesagt geht es mir z.B. um Hotel-WLANs (auch im Ausland), öffentliche WLANs bei Starbucks usw.
> Was kann man denn noch empfehlen, was in den meisten public WLANs offen ist?

Im Zweifelsfall ist bei den meisten offenen Netzen nämlich aus genau diesem Grund außer 80/443 kaum was offen, sehr viele Betreiber keine Lust haben, dass man aus deren Netzen dann irgendwelche Mailbomben zündet o.ä.
Deshalb kann man sich meist nur auf 80/443 verlassen, dass das offen ist.

Dazu wäre es schön wenn du überhaupt einmal das Problem beschreiben könntest, anstatt zu sagen, was du möchtest ;)

Hi,

> Die VM läuft auf einem CentOS in KVM und hat folgende Netzwerkkarten:

So ich verstehe hast du eine größere Hardware und da mehrere VMs die du mit der Sense dann nach außen hin absicherst. Korrekt?

>  - Eine Netzwerkkarte (INTERN) ist eine Bridge zum physikalischen Interface des Servers.

Ist die Bezeichnung intern nicht irreführend, wenn es die Seite ist, die du der Fritzbox zukehrst? Dann wär es ja eher WAN/extern?

>  - Die zweite Netzwerkkarte (DMZ) ist in einem virtuellen KVM Netzwerk (die DMZ).

So weit so gut :)

> Internet > FritzBox > [ OPNsense Interface INTERN  | OPNsense Interface DMZ ] < VMs im virtuellen DMZ Netz.

Nochmal die Frage: warum INTERN - aus Sicht der Sense ist das Interface doch WAN/Upstream, nicht Intern?
Sollte somit auf keinen Fall das default LAN Interface mit den Standard Regeln (allow any) sein!

>  - Route: 10.2.0.0/24 via 10.0.0.254 (Route zur DMZ via OPNsense)
>  - Port-Forwarding für z.B. TCP/443 zu 10.0.0.254 (OPNsense)

Warum so umständlich und nicht einfach exposed Host auf die 10.0.0.254? Wenn die Fritz nur WLAN macht und damit default NAT nach außen ist das egal und keine Beeinträchtigung. Man hat aber nur einen Punkt an dem ma konfiguriert und muss nicht an 2 Kisten herumschrauben.

> Im Netzwerk DMZ befindet sich z.B. eine Apache-VM die von OPNsense per DHCP eine IP bekommt und OPNsense als default Gateway nutzt.

Server VMs sollten kein DHCP nutzen. Das ist zwar praktisch aber in solch einem Setup sehr ungünstig, da sich die IPs ändern könnten wenn kein static mapping gemacht wird. Und wenn dieses schon gemacht wird - warum dann nicht gleich die VM statisch konfigurieren? Damit sind die meisten VMs auch noch schneller am Start und können fixer booten.

> Nun geht Traffic aus dem Internet erstmal von der FritzBox über die interne IP 10.0.0.254 (OPNsense) in die DMZ.
> 1. Wie kritisch seht ihr dieses Sicherheitsproblem?

Da sehe ich da kein Sicherheitsproblem, sondern eher ein Verständigungsproblem von dir. Dein Interface "Intern" ist nicht intern, sondern WAN / extern und muss auch so konfiguriert sein. Dein Interface DMZ ist eigentlich das "intern" bzw. LAN Interface, denn du willst abgehend Kommunikation erlauben (deine VM muss ja bspw. Updates etc. machen können) aber eingehend filtern (bspw. nur 443 reinlassen). Ergo ist deine Sicht auf die Sense falsch. Konfigurierst du das andersrum ist da auch kein Sicherheitsproblem (warum sollte es auch eins sein?)

> 2. Wie könnte ich das Netzwerk schlauer aufbauen?
(...)

Dein einziges Problem ist, dass du verkrampft am WLAN der Fritte fest hältst. Der Rest deiner Idee ist absolut stimmig und würde wesentlich mehr Sinn machen -> das ganze als Dreibein aufzuziehen und die Fritzbox lediglich als Uplink Gateway mit eigenem Transfernetz zu nutzen.

Daher meine Empfehlung (sehr ähnlich zu deinem:)

Theoretisch könnte ich die FritzBox in ein anderes Netz setzten und an ein neues/separates Interface der OPNsense VM hängen.
Dannn hätte OPNsense die folgenden Interface:
- EXT (Netz der FritzBox, z.B. 10.5.0.254 / 24)
- LAN (Alle internen Geräte, 10.0.0.254 / 24)
- DMZ (Alle VMs im virtuellen DMZ auf KVM, 10.2.0.254 / 24)

1) Fritzbox auf relativ nahe "Default" einstellen. Sprich: Meist haben die Kisten 192.168.178.0/24 als Netz. Nutze das. Verändere nur wenig, wie bspw. eben deine Provider/Einwahl Einstellungen und ansonsten setze die Sense auf 192.168.178.2 oder 254 und erstelle ein exposed Host Setting mit der IP der Sense. Bitte die Sense hier NICHT auf DHCP einstellen oder solche Ideen. Das hat schon mehrfach mehr Probleme als Lösungen gebracht!
-> Warum: Da die FB eh nicht wirklich genutzt wird, nahe an den Defaults bleiben und die Konfiguration sichern. Das hilft Probleme zu vermeiden mit Fehlkonfiguration und wenn man die Kiste austauschen muss, ist schnell ein Minimalbetrieb wieder möglich (da eine Ersatz Fritte ebenfalls mit den Defaults kommt, kann man die einfach anschließen und hat meist sofort schon wieder Internet an der Sense womit man erstmal wieder arbeiten kann).

2) Kauf dir einen günstigen Access Point oder nutze ein anderes vorhandenes Gerät dafür. Packe den ggf. auf ein eigenes Interface der Sense oder hänge die Geräte auf Wunsch ins LAN/intern, aber hänge sie hinter die Sense. Dafür, die zu schützen, ist sie da und das ist ihr Job. Nutze sie.

3) LAN für interne Geräte

4) DMZ für deine restlichen VMs

Das wäre mein präferierter Aufbau (bzw. nutze ich selbst im Lab so seit Jahren schon).

Grüße
Jens

Wo ist daran denn das Problem? Ein Paket kann eben 1500 nicht übersteigen ohne gesplittet zu werden. Das ist normal und OK. Und je nach verwendetem Protokoll (TCP/UDP) und Einwahl via Provider (IP vs. PPPoE) ist hier noch mehr oder weniger Overhead abzuziehen. Wenn Pakete > 1472 nicht durch kommen, dann heißt das, dass an dieser Grenze mit Headern und Einpacken die 1500 erreicht sind und mehr nicht geht. Daran sollte man dann ggf. die MTU des Tunnels anpassen und dann sollte das auch keine Probleme geben.

Grüße

Danke. Ich glaube ich versuche OpenVPN auf 444/TCP lauschen zu lassen und den nginx Anfragen auf vpn.[domain] weiterleiten zu lassen an die OPNsense DMZ IP auf 444.
So kommen Anfragen per 443/TCP rein, zum nginx und von dort zum OpenVPN.

Macht gerade für mich gar keinen Sinn? Wozu den OpenVPN dann auf 444 laufen lassen, dann kannst du ihn auch einfach an localhost binden. Warum übrigens nicht andersherum? OpenVPN hat ja explizit die Möglichkeit Verbindungen als Proxy zu beantworten, die nicht VPN sind. Dazu muss dann auch keine Subdomain o.ä. herhalten. Einfach OpenVPN auf 443/tcp hören lassen und als Custom Commands des Servers noch

port-share x.x.x.x 443

für die IP, wo die restlichen Zugriffe auf 443 hin sollen.

> Was der wohl auflösen wird? :-(

Aye, wenn das als URL bzw. FQDN im Alias eingetragen ist, werden die natürlich sporadisch aufgelöst damit der Filter die IPs davon blocken kann, was dann auch die Abfragen im Client Stil erklärt, da die Sense das selbst auflöst. :)

Aber ist doch gut, dann haben wirs ja gefunden :D

Außer dem Artikel von heise kann ich dazu noch empfehlen:

https://www.linkedin.com/pulse/9-reasons-intercept-https-marnix-dekker
sowie Kris' Blog
http://blog.koehntopp.info/index.php/1280-10-reasons-not-to-do-https-interception/

> Hier tritt aber meine Paranoia in den Vordergrund und sagt mir: "ich vertraue den amerikanischen root Servern nicht". Auf jeden Fall mehr als meinem ISP, aber dennoch.

Das ist aber quatsch. Es ist völlig egal, ob das jetzt ein US Root ist oder nicht, aber irgendwo steht nunmal der Root der Zone bspw. .org. Und das wird dann eben recht häufig auch mal ein US Server sein. Entweder vertraut man DNS oder nicht, da gehört dann Vertrauen in die großen ROOTs mit rein. Die zudem meist Anycast ausliefern und das aus Servern in deiner Nähe, als auch bspw. eben Europa oder Deutschland.

> Nun bietet OpenNIC Tier 1 Root Server an als Alternative, aber wie zum Geier kriegt man das wieder in Unbound konfiguriert frag ich mich da. Fragen über Fragen. :P

Unnötiger schnickschnack meines Erachtens. OpenNIC macht nicht einen eigenen ROOT, sondern macht das um (zu alten Zeiten als es kaum gTLDs gab) eigene Domain TLDs nach eigenem Gusto anbieten zu können. Braucht aber nun wirklich kein Mensch. Dass man mehr freie und performante DNS Server brauchen könnte - keine Frage - dafür ist OpenNIC toll. Aber ich brauche keine alternativen ROOTs mit eigenen eingepflegten Zusatz TLDs denen ich dann auch wieder "trauen" muss, dass sie keine Zone wie bspw. .org mit was eigenem Überschreiben.

> Vor ein paar Jahren gab es da doch mal einen Angriff genau auf diese Art um DNS Anfragen auf Webseiten mit Werbe-Bannern aufzulösen.

Ist bei genug Anbietern und ISPs immer noch Gang und Gäbe. Nicht Werbebanner aber es gibt genug "schlechte" DNSe, die bspw. bei einem NXDomain eigene Seiten ausliefern als "Alternative". Was DNS im Grunde schon kaputt macht (weil es kein negatives Caching gibt, sondern der Client denkt, er hat was korrekt aufgelöst, obwohl es Werbung oder ISP Bullshit ist).

Grüße

Auch wenn OT: Verbunden via VPN oder sonstiges? Generelle DNS Server Settings? NTP?

> Warum...warum...warum nur habe ich schon immer den Eindruck, dass in Deutschland viele Dinge etwas ganz anderes bedeuten als im Rest der Welt.

Verstehe ich nicht was du meinst :) Wie gesagt die Definitionen von DMZ und Co sind älter als Wikipedia ;)

> Warum meine sense Microsoft-Mist auflösen will kannst du sicher auch nicht beantworten, oder?

Doch, das sieht mir nach Windows 8.1 respektive Windows 10 Telemetrie Datenaustausch aus. Zumindest passen die aufgerufenen Domains ziemlich genau :)

Das dachte ich mir dass das jetzt kommt ;) Lies dazu mal den deutschen Eintrag, der ist IMHO korrekter in der Auffassung. Aber auch der englische schreibt nicht "System" sondern "Service". Natürlich wird ein Service exponiert - 80, 443, wasauchimmer :) Aber nicht das komplette System wird exponiert. Nebenbei: Nur weils in Wikipedia steht... und so :D

Ansonsten volle Zustimmung. Bridging etc. sehe ich heute auch eher als überflüssig - es sei denn im Ausnahmefall WLAN im internen Netz wenn da eh nur kontrollierte Clients drin sind (zu Hause bspw.). Aber alles andere sollte man heute durchaus auftrennen und kontrollieren. Da flötet einfach zu viel mit Daten im Netz herum :)