@Kobold: Ich sehe den Sinn für diesen ganzen ClearOS Quatsch nicht. Entweder ich schaffe alte Zöpfe ab, dann auch richtig, oder eben nicht. Warum soll ich - wenn man jetzt schon den Cisco rauswirft - auch noch irgendein altes anderes RouterOS da rumgammeln lassen. Das erschließt sich nicht.
Und über irgendwelche theoretischen SANS oder sonstwelche DMZ Niederschriebe schreibe ich eigentlich nicht. Das ist schön wenn sich da mal jemand hingesetzt und das entworfen hat. Wir haben aber 2015 und die Situation ist eine andere, wie sich jemand mal überlegt hat das zu benennen. Als das festgelegt wurde (ich habe noch Firewall und Security Lektüre aus der Zeit) wurde im DMZ Segment auch noch von echten gerouteten Adressen ausgegangen. Das ist heute nicht mehr so, weil oftmals 1:1 NAT oder sonstiges zum Einsatz kommt und Kunden nur noch kleinere - wenn überhaupt - Netze bekommen. Die dann noch extra zu segmentieren oder aufzulegen verschwendet dann Adressen. Theorie ist da schön, in der Praxis seh ich das eben anders :) Und nach meiner Erinnerung hat keiner der sich auch nur im Entferntesten Security Guy schimpft, jemals "Exposed Host" und "DMZ" im gleichen Satz in den Mund genommen. Das ist schlicht eine Verunglimpfung eines Ausdrucks, denn billig-SOHO-Router Hersteller irgendwann mal eingeführt haben, um das als tolles Feature mit einem Security Ausdruck zu bewerfen. Aber mit dem Prinzip DMZ hat das nicht mal Ansatzweise zu tun (denn DMZ impliziert einen begrenzteren/abgegrenzten Security Level der kleiner als Vollzugriff/Internet aber größer als abgeschottetes LAN ist).
Aus dem Grund sehe ich auch nicht ein, warum ich mit extra Kisten alles kompliziert machen sollte:
WAN / Internet
:
: DialUp-/PPPoE-/Cable-/whatever-Provider
:
.-----+-----.
| Gateway | (or Router, Modem, whatever)
'-----+-----'
|
WAN | PPPoE / Ethernet
|
.-----+-----. priv. DMZ .------------.
| pfSense +-------------+ DMZ-Server |
'-----+-----' 172.16.16.1 '------------'
|
LAN | 10.0.0.1/24
|
.-----+------.
| LAN-Switch |
'-----+------'
|
...-----+------... (Clients/Servers)
Klassisches Dreibein mit DMZ Achse. Läuft. Und man muss nicht an 2-3 Kisten suchen, warum zum Geier irgendwas nicht läuft.
@Marc
2x 10Gbit/s…
Wozu? Ich sehe nirgends Anwendungsbereiche, wo du irgendwas mit 10GE bräuchtest. Finde ich dann doch recht unnötig.
Sollte ich doch noch wiedererwartend eine andere Sache dürfen, wie genau ist die vorgehensweise wenn alle Server (auch die die nicht dreigegeben werden sollen) VMs auf zwei Windows Hyper-V Servern sind?
Dann müssten die Hyper-V Server beide in die DMZ und dann ist auch das frei was nicht raus soll, oder?
Nein, deshalb wären gerade Switche gut, die eben VLANs können. Ich würde sowieso die Server NIE direkt ans Netz hängen, auch nicht via 1:1 NAT, denn das fügt keinerlei Sicherheit hinzu. Gerade Exchange (OWA) hängt dann nackt am Netz und sollte mal wieder nen Patch Day versaut sein, hast du hinterher noch Streß weil der Mailserver tot ist.
Deshalb kann man - bspw. in eine DMZ oder zum Teil auch direkt via pfSense - diverse Dienste einfach mit (reverse) Proxy betreiben. Für OWA/Exchange geht das m.W. unter anderem mit Squid und/oder HAProxy, die dann einfach die Daten initial annehmen und an Exchange weiterreichen. Wenn aber von außen jemand lustige Probes fährt um irgendwelche IIS Lücken zu finden, wird er am HAProxy oder Squid eben nicht weit kommen. Dito für deine anderen Atlassian Kisten. Da schreibt Atlassian ja sogar selbst, dass man Jira/Confluence und Co. am Besten nochmal mit einem Apache/NGinx vornedran Proxy'en sollte. Schon allein, weil du dann nicht auf krumme Ports zugreifen musst, aber auch um ggf. Caching und Security noch mit reinzubringen (und ggf. TLS hinzuzufügen bzw. Offloaden zu können).
Darum sehe ich auch keinerlei Traffic WAN<->DMZ, DMZ<->LAN oder WAN<->LAN, der jetzt >1GBit/s wäre und da ich bezweifle, dass ihr 10GBE Dark Fiber angebunden seid ;) sehe ich da nirgends einen Grund für eine pfSense mit 10G Interface.
VLANs würden sich positiv bemerkbar machen, denn du könntest damit ggf. Maschinen auf dem HyperV hochfahren und deren Interface an einem extra VLAN betreiben, das auf der pfSense eben wie eine DMZ aufliegt. Damit wäre der Hypervisor selbst nicht exponiert, und nur die VM würde dann ggf. mit einer anderen Maschine im normalen LAN reden. Diese Kommunikationsbeziehungen am Besten festhalten (aufschreiben, Netzplan) und dann die Regel genauso festzurren. Dann ist auch nicht mehr erlaubt als es sein muss und damit alles OK -> mehr Filtern geht dann nur auf Applikationsebene und das ist immer ne andere Baustelle.
Von der bisherigen Erzählung würde ich aber Frank zustimmen: ein C2758er Atom Server mit 8 Kerner Atom und 8GB RAM sollte da DICKE reichen. Wir haben auch 2 solche Kisten vor unserem Office (CARP Cluster wegen Ausfallsicherheit), sind 1HE Supermicro Superserver und funktionieren super und sind wirklich sehr fix und für den Job durchaus ausreichend,
Grüße
Grüße
