Konfigutation mit öffentlichem IP-Subnetz
-
Der Cisco RT kann bleiben, muss er aber nicht. Da der nur eine Schnittstelle rein und eine raus hat, macht es keinen Sinn da eine DMZ aufzubauen.
Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.
-
Der Bereich zwischen dem Cisco und der pfSense ist die DMZ, die musst Du nicht erst neu bauen.
Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?
Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW? -
Was für ein Cisco Router ist das denn genau?
Modell, Nummer?Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich.
Wenn man schon eine DMZ baut dann auch richtig und nicht unnütz.
In Eurer ersten DMZ (ersten Zeichnung) ist der Cisco Router zu sehen und dahinter ein Fileserver
und dann ein ClearOS Server der entweder NAT oder NAT und Squid oder NAT, Squid und Snort
realisiert. Und dort ist der Fileserver genau an der richtigen Stelle! Aus dem Internet zu erreichen
und aus dem LAN zu erreichen. Und warum soolte der Filserver dann 100% ungeschützt im Internet
stehen? Ob ich nun am Cisco Router oder an der pfSense Ports öffne, diese "forwarde" und die Server
in der DMZ darüber zu erreichen sind ist doch fast egal, sie sind zu erreichen. Und völlig nackt und
zu 100% erreichbar ist wenn man vorne am WAN Interface alles auf Durchzug stellt, was natürlich
nicht anzuraten ist.Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen,
oder verstehe ich hier grade was falsch?Man stellt in der Regel die ganzen Server und Geräte die aus dem Internet zu erreichen sein sollen
eigentlich immer hinter das erste WAN Gerät (SPI/NAT/Firewall) und wenn man nicht eine extra DMZ
anlegt ist das dort, der gesamte Bereich der DMZ Bereich! Man spricht dann auch oft von dem "Border"
Gateway, Router oder Firewall und die zweite Instance dahinter die muss nicht, aber kann noch einmal
SPI/NAT oder eben nur Firewall bzw. IDS/IPS machen. Nur dann noch einmal eine dritte Instance dahinter
würde ich nicht machen wollen. Wofür NAT machen wenn ich dann alles nur wieder aufbohren muss?Der ISP würde das Netz auf die pfSense routen und die pfSense würde die PPPoE Einwahl machen.
Kann die pfSense das Gateway sein auf der WAN Seite und die LAN Seite geht über das WAN_GW?Ja das geht alles. Die Zeichnung ist etwas groß geworden daher würde ich empfehlen sie zu speichern und
dann zu betrachten!
-
Hallo Frank,
danke für deine ausführliche Antwort und die Zeichnung. Hat geholfen! Es ist ein Cisco 1840.
Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense. Die bekommt auf dem WAN IF (welche in den Cisco geht) eine öffentliche IP .66 und auf dem LAN IF die 192.168.0.1. Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.
In der pfSense werden viruelle IPs angelegt und diese dann per NAT auf die internen Dienste verteilt. Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.
Eine Frage habe ich noch:
Der ISP wird mir bei der Einrichtung behilflich sein. Dafür würde ich gerne das Webinterface über die Haupt IP (WAN .66) erreichbar machen. Das scheint nicht zu funktionieren. Wie kann ich das einrichten?
Unter FW –> Rules --> WAN habe ich eine Regel angelegt die sagt, dass rein über WAN IF und TCP from any to IP .66 auf HTTPS erlaubt. Das klappt aber nicht. -
Der Wunsch war es, einige Server (Exchange, MS Dynamics CRM, Atlassian Jira und Confluence etc.) extern verfügbar zu machen.
DAS ist gruselig. Die Dinger hängt man nicht nackt ans Netz. Empfiehlt dir niemand. Dafür gibts Reverse Proxies, die das verfügbar machen und nebenbei dafür Sorgen, dass eben zuverlässigere Komponenten am Netz hängen als das was da so normalerweise drauf läuft.
Das macht ja keinen Sinn, die Server sind ja dann nicht abgesichert und 100% öffentlich. Dann würde ich der pfSense lieber ein drittes Interface einbauen und hier die DMZ einsetzen, oder verstehe ich hier grade was falsch?
Wie Frank schon schreibt ist das nicht richtig, nur wenn die Server nackt am Netz hingen und der Cisco macht(e) ja NAT und kann sicher auch Regeln (auch wenn ich die nicht nehmen würde, er kanns wahrscheinlich).
Ich bin zwar normalerweise gegen so eine durchgeschleuste DMZ, aber tatsächlich besser als nix.
Die finale Entscheidung ist nun gefallen, wir lassen den Cisco erst mal stehen und der macht lediglich die Einwahl. Das NAT wird vom ISP wieder entfernt. Hinter den Cisco kommt dann unsere pfSense.
Bekommt der Cisco dann die .65 und das Netz geroutet? Wie routet der dann das Netz weiter? an die .66 die du auf die pfSense knoten willst? Macht kein Sinn, denn das Netz liegt dann ja schon auf. Verstehe also nicht ganz wie ihr das dann klöppeln wollt.
Die LAN Seite geht in unseren großen HP Switch und da kommt alles mit internen IP Adressen dran.
Und warum zum Geier nehmt ihr dann nicht - wenn es eh alles so billig war - ne neue APU Kiste, die erstens mehr Bumms hat und zweitens noch ein drittes Interface? Dann kann man auch ne ordentliche DMZ konfigurieren? Alternativ, wenn euer HP das hintendran kann - 2 getrennte VLANs machen und die Server die man Live stellen möchte da rein packen (oder deren Proxies). Das wirkt alles einfach sehr gebastelt und wenn man dann doch eh am Aufräumen ist, warum nicht richtig? :)
Die Möglichkeiten von Frank mögen valide sein (kein Affront dagegen :)) aber gruseln mich alle. Warum kein sauberes 3-Bein Setup implementieren?Grüße
-
Ich bin hier nur der ausführende Befehlsempfänger. Entscheidungen treffen andere Stellen. Ich kann immer nur mit meinen Ideen und euren Vorschlägen dahin wandern und das vorschlagen. Das macht mir langsam keinen Spaß mehr. Ich würde das so machen, wie ihr es sagt, auch wenn ich dafür neue Netzwerkkarten kaufen müsste. 2x 10 GBit Karte und fertig ist der Laden! Aber leider ist dem nicht so…
Ja, so wie es aussieht wird dem Cisco das NAT entzogen und der macht nur noch die Einwahl und routet das Netz auf die pfSense. Die hat am WAN IF bereits die public IP 66. Per SSH komme ich von draußen drau, per HTTPS aber nicht... Why? Wie mache ich das Webinterface vorübergehend per HTTPS von draußen aus erreichbar?
-
Also wenn ich mir das hier so alles anschaue dann würde ich einfach zwei neue Geräte anschaffen wollen.
Zum Einen eine fette Lösung für die Front und eine weniger gute aber dennoch schnelle Appliance dahinter.Also einfach den Cisco Router gegen eine flotte pfSense Lösung austauschen und dann neue Hardware
für die ClearOS Lösung dahinter. Kann ja weiterhin bleiben und Ihren Dienst verrichten soll aber auch
nicht der Flaschenhals sein.Irgend wann haben eben irgedn welche Leute zusammen mit den Leuten vom SANS Institute
die drei Hauptarten einer DMZ festgelegt, sicherlich gibt es dazu noch hunderte wenn nicht
sogar tausende Sublösungen gibt.- "Exposed Host" - pseudo DMZ
- DMZ Port in Hardware oder Software realisiert = true & dirty DMZ
- Dual homed oder "bastion host" Variante mit zwei Routern oder Firewalls = true & clean DMZ
Wird oft auch als Router oder Firewallkaskade bezeichnet.
Was jeder für sich nimmt und benutzt muss ernatürlich selber wissen und umsetzen
klar da scheiden sich die Geister immer und wenn die ClearOS "Kiste" hinter der pfSense Firewall,
so wie das netzwerk jetzt aufgebaut ist, laufen würde und das noch transparent als Snort und/oder
Squid Proxy wäre das auch noch vertretbar, aber so wie das jetzt geplant ist würde ich das nicht realisieren
wollen, und wozu auch? Cisco Router Ports auf und Route auf die pfSense dahinter die hat dann auch gleich
erst mal das NAT aufgebohrt und dann erst die Server freigeben? Die stehen doch im LAN und das soll doch
der geschützte Bereich sein der nicht?ISP –- Internet --- Modem --- Router/Firewall --- LAN
So und wenn nun einige Server Kontakt zum Internet brauchen hat der Admin doch ein Problem
oder nicht? Er muss die Server an das Internet anbinden und möchte keinen Kontakt zum Internet
seitens seines LANs haben. Man kann nun eine DMZ Software seitig oder mittels Hardware DMZ Port
aufsetzen oder aber zwei Geräte hintereinander setzen und dazwischen ist dann die DMZ und natürlich
auch die Server.- Sollte das OS am WAN interface einen Bug haben, steht dahinter noch ein anderes gerät mit einem
anderen OS drauf was am besten unterschiedlich ist. - Hat man sich verkonfiguriert sind nur die Server mit Internetkontakt davon betroffen aber nicht die LAN
Server und Arbeitsstationen. - Vorne terminiert man das VPN und realisiert den HTTP-Proxy zur DMZ hin und am zweiten Gerät weiter
hinten setzt man ISD/IPS ein.
Das wird sicher nicht die Lösung für immer sein, aber hauptsache es läuft langsam mal was.
und das nenne ich dann eben nur noch "blinden Aktionismus" ist nicht böse gemeint aber später will da
so oder so niemand noch einmal bei gehen!Aus dem pfSense Shop C2758 mit pfSense für den Cisco Router
XG-1540 oder einem kleinen Intel E3-12xxv3 mit 32 GB ECC RAM mit ClearOS dahinter und gut ist es.
alternativ kann man auch ein Supermicro C2758 und D-1540 Board dazu nehmen und gut ist es.
Die Server mittels eines Layer2 Switches und 10 GBit/s in der DMZ anbinden und die ClearOS
Lösung kann dann ja auch transparent laufen, also ohne NAT nur mittels Firewall und Snort. -
Du hast völlig Recht, ich würde mich da auch direkt so entscheiden, dass es die nächsten Jahre läuft wie es ist. Ich kann nur das ausführen, was ich genehmigt bekomme und das ist nun mal das was ich grade gesagt habe…
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?Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?
-
Noch mal die wichtige Frage: Wie kann ich die pf-Sense Web-Gui extern erreichbar machen mit der WAN IP?
Am besten gar nicht, sondern nur Einwahl via VPN und dann am besten nur wenn auf Deinem Gerät ein Radius
Zertifikat installiert ist, als zusätzliche Absicherung. Sollte einmal eine Bug auftauchen sei es nun in pfSense
oder SSH, oder irgendwo anders hast Du wenigstens kein Problem.LAN seitig würde ich VLAN1 als Admin VLAN benutzen und auch mittels Radius Zertifikat abgesichert.
WAN seitig nur via VPN und mit Radius Zertifikat abgesichert -
Es geht nur um die Hilfe des ISP, damit alles sicher ist. Das ist nur vorrübergehend und wir nur von Source (deren Firewall) erlaubt und ist HTTPS mit unserem Wildcard-Cert. Aber kurzzeitig offen muss sein.
-
@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.
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