Messages

1861

German - Deutsch / Re: DMZ hinter FritzBox die internes WLAN bereitstellt

« on: March 28, 2017, 01:48:28 pm »

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

1862

German - Deutsch / Re: OPENVPN - Keine Paket Fragmentierung

« on: March 28, 2017, 01:21:42 pm »

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

1863

German - Deutsch / Re: OpenVPN welcher Port?

« on: March 28, 2017, 01:19:02 pm »

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.

1864

German - Deutsch / Re: DNS Resolver vs. DNS Forwarder

« on: March 27, 2017, 10:41:18 am »

> 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

1865

German - Deutsch / Re: Proxy (Verständnis)Frage - TLS/SSL

« on: March 24, 2017, 11:51:23 am »

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/

1866

German - Deutsch / Re: DNS Resolver vs. DNS Forwarder

« on: March 21, 2017, 11:59:57 am »

> 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.

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

1867

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 02:55:38 pm »

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

1868

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 02:38:37 pm »

> 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

1869

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 02:14:04 pm »

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

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

1870

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 11:19:14 am »

Hallo Helge,

Diskussion ist immer toll, gerade bei solch einem Thema

Auch spielt es kaum eine Rolle (bin jetzt lieber etwas vorsichtiger  ) wenn Geräte im LAN stehen und rein Sicherheitstechnisch der Super-GAU sind, aber keine Internetverbindung besitzen. Dafür ist nun mal die Firewall da, um dafür zu sorgen. Auch kann man in LAN mehrere Bereiche mit unterschiedlichen Sicherheitsanforderungen definieren und die  per Router / Firewall von einander trennen.

Also ich finde es durchaus bedenklich, SGAU Geräte im LAN zu haben Das können wie gesagt Gründe sein wie bspw. dass nicht alle Leute auf diese Geräte zugreifen sollen, das kann aber auch schlicht sein, dass diese ggf. trotzdem anfällig sind. Und auch in einem LAN können Probleme auftreten, die Client-induziert sind. Sprich: ein falscher Download/Klick und ein schlechter Tag der AV Software und des Kopfs, der den Rechner bedient und man hat einen Zombie im LAN. Und dann sollte der vielleicht nicht unbedingt an die Kamerabilder, NAS Daten o.ä. so problemlos rankommen. Cryptlocker, Locky und Co. waren da fiese Beispiele. Klar waren da auch mitunter Netzlaufwerke mit drunter die gefallen sind, aber ggf. nicht der ganze Server o.ä. und kann damit wieder aus einem Backup hergestellt werden. Solche Schädlinge scannen ja gerne dann mal ihre Umgebung und je weniger sie dann sehen, umso weniger Blödsinn können sie anrichten.

Eine DMZ kenne ich nur als einen Bereich, der einen geringeren bzw. gar keinen Schutzbedarf hat. Dienste die aus dem Internet erreichbar sein müssen, können nicht zu 100% abgesichert werden. Deswegen stehen Webserver oder andere Dienste in der DMZ, um den Zugriff vom Internet aus zu gewährleisten aber das eigentliche LAN nicht zu gefährden.

Geringen würde ich zwar gegen geringeren austauschen, aber ja. Keinen Schutzbedarf gibt es heute eigentlich nirgends mehr. Die Zeiten sind leider vorbei, heute sind da Botnetze, (D)DOS und Co nur Mausklicks und PayPal entfernt und teils als SaaS Lösung outgesourced. Keinen Schutzbedarf gibts heute eigentlich nicht mehr - es sei denn du gießt den Rechner in Blei ein und verbuddelst ihn im Boden

Webserver und Co stehen in der DMZ, weil sie Dienste nach außen zur Verfügung stellen (anders als die Clients im LAN) und daher Zugriff von außen brauchen. Aber nur Zugriff auf die Dienste, nicht auf generell alles. Also nur weil ein Server in der DMZ steht, heißt das nicht, dass er nicht firewalled sein kann, sondern nur dass für ihn (überhaupt) ein (strengeres) Regelset definiert ist, als für das LAN (meist Block All).

Wen das ganze Architektur Thema interessiert, dem kann ich auch heute noch den O'Reilly "Building Internet Firewalls" empfehlen. Ja der ist alt (2005) aber es geht da weniger um sich ständig ändernde Filtersyntax und Tools, sondern eher um ganz generell die Nomenklatur und der Aufbau von diversen Firewalling Mechanismen und Architekturen. Zweibein, Dreibein (Mehrbein), nachgeschaltet, etc. Bastion Host, DMZ, usw. werden dort ganz ausführlich behandelt und auch mit Beispielen belegt.

1871

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 11:08:33 am »

> demilitarisiert = kein Schutz = exposed to internet

Interessant, die Auffassung habe ich in 20 Jahren bislang noch nie gelesen DMZ heißt m.W.n. in keinerlei Literatur zu Security Konzepten, dass hier komplett "exposed" wird. Das ist eine Auffassung, die irgendwelche günstigen Routerhersteller mal angefangen haben, die den Begriff DMZ plötzlich mit exposed Host gleichgesetzt haben. Aber das war schon damals nicht richtig und für viele sehr verwirrend. "Exposing Services", was eine DMZ tun soll, ist aber nicht gleichzusetzen mit "fully exposed", was leider einige Hersteller verbrochen haben.

Richtig ist aber, dass es in diesem Fall - wenn eigentlich keine Ports nach außen geöffnet werden weil der Zugriff lediglich via VPN erfolgen soll - es keine DMZ im klassischen Sinne ist. Es ist vllt. eher als weiteres LAN zu betrachten, das entsprechend "firewalled" sein sollte. Aber ich glaube das artet in Nitpicking bei dem Begriff aus

1872

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 09:26:16 am »

> In eine DMZ gehören Server die vom bösen Internet und Intranet aus erreichbar sein sollen.

Ich möchte nicht auf Formalien herumreiten, aber laut meinem durchaus begrenzten Wissen ist eine DMZ genau das - eine demilitarized Zone, sprich eine Zone mit sicherheitstechnisch kontrolliertem Zugang. Ob das sich jetzt auf Internet, LAN oder beides bezieht ist eigentlich egal. Im Fall von Kameras wäre das - zumindest wenn man ein Auge Richtung Firmeneinsatz wirft - durchaus beides der Fall, denn ich will ja vielleicht nicht unbedingt, dass andere Leute/Mitarbeiter die Kameras anschauen können, sondern nur ein begrenzter Personenstamm oder nur ich. Also schirme ich hier nicht nur vom WAN, sondern ggf. auch vom LAN ab. Das ist zumindest mein Ansatz dabei. Natürlich: wenn das nicht nötig/gewollt oder gewünscht ist, kann man die theoretisch auch ins LAN packen. Praktisch gab es aber durch die jüngsten IoT Botnetze genug Gründe, solche embedded Server Kisten lieber woanders als ins LAN zu packen

Grüße

1873

German - Deutsch / Re: Netzplanung: Brauche Hilfe bei DMZ und ADSL

« on: March 17, 2017, 08:53:02 am »

Guten Morgen

Aaalso:

> Wichtig war es mir die IP Kameras in einer DMZ einzusperren, jedoch über VPN von außen Zugriff zu erhalten.

Das ist schonmal ein kluger Ansatz. Es gibt leidigerweise genug IP Kameras die offen im Netz rumschwirren, weil sie nie sauber abgesichert wurden und der Nutzer "mal eben von unterwegs mit ner App" drauf zu greifen wollte...

> Ports wollte ich auf meiner "FW1" eigentlich keine öffnen und für das VPN lieber eine zweite Firewall "FW2" nutzen.

DAS allerdings macht IMHO überhaupt keinen Sinn. VPN ist ja genau dafür da, eben keine anderen Ports öffnen zu müssen als VPN. Ob das nun auf fwl01 oder fwl02 geschieht ist doch nebensächlich. Im Gegenteil du bekommst eher noch mehr Probleme bezüglich Routing, asymmetrische Routen etc. mit rein als dass es dir effektiv einen Nutzen bringt. Macht aus meiner Sicht überhaupt keinen Sinn (für dich).

> Aus Security Sicht, wie schlimm ist es für IPSec oder OpenVPN Verbindungen von außen (WAN) auf der Firewall zu erlauben und die notwendigen Ports freizuschalten?

VPN sollen Sicherheit bringen. Dass der Dienst entsprechend erreichbar sein muss versteht sich von selbst. Korrekt konfiguriert besteht hier kein Risiko, da sich niemand einloggen kann ohne alle Parameter und Schlüssel zu kennen.

> Bin ich da zu übervorsichtig? Lohnt sich an der Stelle der DMZ Aufwand überhaupt?

Bezüglich der Kameras? JA! Zweite Firewall bzw. extra VPN Gegenstelle - not so much

> Die meisten Angriffe von Außen kommen ja eh über 443 und 80/ 8080 oder?

Nö. Darüber kommen die meisten Skriptattacken, ja. Aber Angriffe gibt es inzwischen am Laufenden Band auf die unterschiedlichsten Ports. Gerade wenn bspw. irgend ein IoT Device wie Kamera, Kühlschrank, Toaster etc. eben mal wieder entdeckt wird, dass es unsichere Defaults hat... oder Netgear Router

> Ich hatte von einer NAT DMZ Umsetzung aus dem M0n0wall Handbuch gelesen.

DMZ ist Firewall Basic Wissen Das hat nicht M0n0wall erfunden Aber schön, dass du die korrekte Implementation von DMZ gelesen hast und nicht das was teils Routerhersteller daraus gemacht haben... *kopfauftisch*

> Aber das kann man ja nicht länger DMZ nennen (im klassischen Sinne),

Warum?

> gerade wenn ich mir was zu UDP hole punching durchlese. 

Was haben Attacken wie diese mit dem Konzept DMZ zu tun? Das Konzept DMZ sieht eine Zone vor, die andere (geringere) Sicherheitsbedürfnisse hat, weil sie Dienste extern bereitstellen (Webserver bspw.) und daher von WAN Seite erreichbar sein sollen, selbst aber bspw. keinen Zugriff aufs LAN haben sollen. Zugriff VOM LAN aus aber soll bspw. gestattet sein etc.

Es geht bei Firewall Architekturen mehr um die Abschirmung von Zonen unterschiedlicher Nutzung und Sicherheit. Bspw. sollte dein LAN bei guter Planung NULL Zugriff von extern brauchen (gut - ist heute mit Spielen etc. auch nicht mehr ganz so einfach aber im Enterprise Sektor gehts genau daraum).

> Bekomme ich mein Netz so umgebaut, dass die DMZ Implementation doch noch funktioniert?

Warum funktioniert sie denn nicht?

> - Ports auf FW2 öffnen, nicht auf FW 1

siehe oben - m.E. unnötig

> - Das Modem nicht durch eine Fritzbox ersetzen um Doppel-NAT zu verhindern

Doppel-NAT Panik wird überbewertet IMHO. Ich fahre das Setup zwangsweise bei Kabelanbietern schon jahrelang ohne Probleme und mit einem laufenden Cluster hintendran

> - Zugriff auf die Kameras (DMZ) aus dem Internet nur über VPN, jedoch ggf. SSH aus dem LAN in die DMZ

Dafür ist so eine DMZ ja da Also durchaus richtige Überlegung.

> Ich bin über jede Hilfestellung dankbar.

Bitte sehr

Wie gesagt denk nicht so überkompliziert (was 2. Firewall mit VPN angeht etc.), das bringt nur wieder neue Probleme und Angriffspunkte mit rein.

- Eine Firewall
- Konfiguration als "Dreibein" - also WAN, DMZ, LAN
- Auf WAN entweder IPsec oder OpenVPN annehmen -> was du willst sei dir überlassen
- Zugriff von VPN auf DMZ erlauben - ggf. zweiten VPN User oder zweites VPN definieren wenn man noch LAN Zugriff möchte und das getrennt sein soll
- LAN Zugriff überallhin(?) erlauben oder eben überall außer DMZ und DMZ nur von bestimmten IPs oder nur auf SSH Port o.ä.
- und dann nach und nach weitere Dinge aktivieren wie deinen Virenscanner etc.

Viele Grüße

1874

German - Deutsch / Re: [GELÖST] HA/CARP und mehrere VLANs

« on: March 16, 2017, 10:05:57 am »

Sehr gern. Freut mich dass es geholfen hat.

1875

German - Deutsch / Re: Raspberry Pi 2011.12 & OPNsense?

« on: March 13, 2017, 11:10:49 am »

Ganz doof gesagt wird er für OPNsense schlicht die falsche Architektur haben, denn bislang habe ich nur in Erinnerung, dass es die 16.6.7(?) Version mal als Versucht für den Pi(1) gab. Ein Release für den Pi2 auf Basis von neuem FreeBSD habe ich bislang nirgends gesehen. Deshalb wirst du den Pi momentan noch eher weniger gebrauchen können.