17
ACLs und verschiedene Sicherheitzonen
Moin,
Ich bin mir nicht ganz sicher, in welchen Bereich ich mit dieser Anfrage muss, daher stelle ich das zunächst mal in den allgemeinen Netzwerkbereich.
Um mein Problem zu erläutern hole ich mal etwas aus:
Wir wollen unser Netz grundlegend neu konzeptionieren und in dem Rahmen diverse VLAN's einziehen. Um da nun nicht jedes VLAN über die Firewall zu routen wollen wir möglichst viele VLAN's auf dem Coreswitch terminieren lassen und sie eben nicht über die Firewall führen. Das hat natürlich Performance-Gründe. Die Kommunikationbeziehungen zwischen diesen VLAN's sollen dann mittels ACLs geregelt werden - soweit so wundervoll. Bis hierhin noch kein echtes Problem. Ach ja: Der Coreswitch wird ein Aruba-Switch der CX83xx Series oder der CX84xx Series - das steht noch nicht abschließend fest, dürfte für die Fragestellung aber auch keine wesentliche Rolle spielen.
Unsere Idee ist nun aber, neben den diversen VLAN's verschiedene (ich nenne es mal) "Sicherheitszonen" zu etablieren. Innerhalb dieser Zonen reicht es uns, die Kommunikation mittels ACL's zu beschränken - sobald aber auf eine andere Zone zugegriffen werden soll, soll der Traffic dann aber über die Firewall führen. Ich denke, am besten erkläre ich das anhand eine Beispiels - ich verwende der Einfachheit halber eines mit 10 VLAN's.
Diese 10 VLAN's sollen in 2 Zonen unterteilt werden. D.heisst dann also:
)
Die VLAN's innerhalb einer Zone sollen je nach ACL-List problemlos mit den anderen VLAN's in der gleichen Zone kommunizieren können - so könnte ein Client aus VLAN 6 z.B ein Device aus VLAN 10 über bestimmte Ports erreichen, ohne das dieser Traffic über die Firewall geleitet wird.
Das gleiche gilt für ein Device aus VLAN 12, dass zu einem Device aus VLAN 15 will.
Wenn jetzt aber ein Client aus VLAN 6 mit einen Device aus VLAN 12 komunizieren will, dann würden wir das ganze eben doch gern über die Firewall führen, Und genau an der Stelle komme ich ins Schwimmen? Wenn ich die VLAN's alle auf dem Switch terminieren lasse, kennt er die zugehörigen Netze. Folglich wird er diese direkt routen wollen. D.h. er lässt die Firewall ganzlich aussen vor. Wenn ich die VLAN's aber alternativ auf der Firewall terminieren lasse, wird wiederum jeglicher Traffic (auch der innerhalb einer Zone) darüber geführt. Das allerdings würden wir gern umschiffen.
Ich denke also, ich müsste auf dem Switch irgendwie voneinander isolierte Bereiche schaffen, die unabhängig voneinander agieren - sprich, die die Netze der anderen Bereiche nicht kennen und dann über ein jeweils definiertes default Gatway routen. Ich habe aber gerade kein Idee, wie ich das umsetzen müsste.
Könnte mir da jemand auf die Sprünge helfen?
Wahrscheinlich sehe mal wieder ich den Wald vor lauter Bäumen nicht und ich brauche nur das richtige Stichwort um mich danach in Grund und Boden zu schämen, dass ich es nicht wusste
Ich bin mir nicht ganz sicher, in welchen Bereich ich mit dieser Anfrage muss, daher stelle ich das zunächst mal in den allgemeinen Netzwerkbereich.
Um mein Problem zu erläutern hole ich mal etwas aus:
Wir wollen unser Netz grundlegend neu konzeptionieren und in dem Rahmen diverse VLAN's einziehen. Um da nun nicht jedes VLAN über die Firewall zu routen wollen wir möglichst viele VLAN's auf dem Coreswitch terminieren lassen und sie eben nicht über die Firewall führen. Das hat natürlich Performance-Gründe. Die Kommunikationbeziehungen zwischen diesen VLAN's sollen dann mittels ACLs geregelt werden - soweit so wundervoll. Bis hierhin noch kein echtes Problem. Ach ja: Der Coreswitch wird ein Aruba-Switch der CX83xx Series oder der CX84xx Series - das steht noch nicht abschließend fest, dürfte für die Fragestellung aber auch keine wesentliche Rolle spielen.
Unsere Idee ist nun aber, neben den diversen VLAN's verschiedene (ich nenne es mal) "Sicherheitszonen" zu etablieren. Innerhalb dieser Zonen reicht es uns, die Kommunikation mittels ACL's zu beschränken - sobald aber auf eine andere Zone zugegriffen werden soll, soll der Traffic dann aber über die Firewall führen. Ich denke, am besten erkläre ich das anhand eine Beispiels - ich verwende der Einfachheit halber eines mit 10 VLAN's.
Diese 10 VLAN's sollen in 2 Zonen unterteilt werden. D.heisst dann also:
- Zone 1: VLAN 6 bis 10
- Zone 2: VLAN 11 bis 15
)Die VLAN's innerhalb einer Zone sollen je nach ACL-List problemlos mit den anderen VLAN's in der gleichen Zone kommunizieren können - so könnte ein Client aus VLAN 6 z.B ein Device aus VLAN 10 über bestimmte Ports erreichen, ohne das dieser Traffic über die Firewall geleitet wird.
Das gleiche gilt für ein Device aus VLAN 12, dass zu einem Device aus VLAN 15 will.
Wenn jetzt aber ein Client aus VLAN 6 mit einen Device aus VLAN 12 komunizieren will, dann würden wir das ganze eben doch gern über die Firewall führen, Und genau an der Stelle komme ich ins Schwimmen? Wenn ich die VLAN's alle auf dem Switch terminieren lasse, kennt er die zugehörigen Netze. Folglich wird er diese direkt routen wollen. D.h. er lässt die Firewall ganzlich aussen vor. Wenn ich die VLAN's aber alternativ auf der Firewall terminieren lasse, wird wiederum jeglicher Traffic (auch der innerhalb einer Zone) darüber geführt. Das allerdings würden wir gern umschiffen.
Ich denke also, ich müsste auf dem Switch irgendwie voneinander isolierte Bereiche schaffen, die unabhängig voneinander agieren - sprich, die die Netze der anderen Bereiche nicht kennen und dann über ein jeweils definiertes default Gatway routen. Ich habe aber gerade kein Idee, wie ich das umsetzen müsste.
Könnte mir da jemand auf die Sprünge helfen?
Wahrscheinlich sehe mal wieder ich den Wald vor lauter Bäumen nicht und ich brauche nur das richtige Stichwort um mich danach in Grund und Boden zu schämen, dass ich es nicht wusste
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1639429907
Url: https://administrator.de/forum/acls-und-verschiedene-sicherheitzonen-1639429907.html
Ausgedruckt am: 22.12.2024 um 15:12 Uhr
17 Kommentare
Neuester Kommentar
Ich denke, ich habe die Lösung gefunden. Das Zauberwort heisst VRF. Wenn ich jede "Zone" als eine VRF-Instanz anlege, sollte ich das hinbekommen. Für jede andere Idee (oder auch Argumente gegen diese Idee) bin ich aber weiterhin dankbar
Das kann man so machen bedeutet aber einen erheblichen Mehraufwand. VRF sind ja quasi Layer 3 VLANs also in sich völlig getrennte Layer 3 Domains.
Viel einfacher ist du gibst diesen "sicheren" VLANs keine IP Adresse auf dem Core Switch. Folglich können diese dort auch nicht geroutet werden.
Du schleifst diese VLANs dann rein Layer 2 technisch nur tagged durch den Core durch und terminierst diese dann im L3 nur auf der Firewall.
Der Core Switch bekommt über sein Transfer Netz (siehe Layer 3 VLAN Konzept) dann schlicht und einfache eine statische Route auf diese IP Netze und fertisch iss de Lack !
Das Konzept ist so viel einfacher zu managen als ein VRF Konzept das bei deiner Anforderung technisch nicht ganz passend ist. VRFs nutzt man wenn man innerhalb eines Netzes mehrere getrennte Mandanten (Tennants) hat die man auch L3 technisch völlig trennen muss. Das wäre bei deiner Anforderung mit Kanonen auf Spatzen. Machen kann man das natürlich wenn man den erheblichen Mehraufwand nicht scheut.
Es führen halt viele Wege nach Rom...
Viel einfacher ist du gibst diesen "sicheren" VLANs keine IP Adresse auf dem Core Switch. Folglich können diese dort auch nicht geroutet werden.
Du schleifst diese VLANs dann rein Layer 2 technisch nur tagged durch den Core durch und terminierst diese dann im L3 nur auf der Firewall.
Der Core Switch bekommt über sein Transfer Netz (siehe Layer 3 VLAN Konzept) dann schlicht und einfache eine statische Route auf diese IP Netze und fertisch iss de Lack !
Das Konzept ist so viel einfacher zu managen als ein VRF Konzept das bei deiner Anforderung technisch nicht ganz passend ist. VRFs nutzt man wenn man innerhalb eines Netzes mehrere getrennte Mandanten (Tennants) hat die man auch L3 technisch völlig trennen muss. Das wäre bei deiner Anforderung mit Kanonen auf Spatzen. Machen kann man das natürlich wenn man den erheblichen Mehraufwand nicht scheut.
Es führen halt viele Wege nach Rom...
1
Hi aqui,
erst mal Danke für die Rückmeldung. Natürlich hast du recht: In dem Beispiel ist das Kanonen auf Spatzen. Dein Vorschlag ist natürlich deutlich einfacher umsetzbar - aber die Crux liegt ja darin, dass ich eben vermeiden möchte, jeglichen VLAN-übergreifenden Traffic durch die Firewall zu jagen - ich möchte in der Regel den Performance-Vorteil nutzen, den mir ein CoreSwitch als Hochleistungsswitch da bietet:
erst mal Danke für die Rückmeldung. Natürlich hast du recht: In dem Beispiel ist das Kanonen auf Spatzen. Dein Vorschlag ist natürlich deutlich einfacher umsetzbar - aber die Crux liegt ja darin, dass ich eben vermeiden möchte, jeglichen VLAN-übergreifenden Traffic durch die Firewall zu jagen - ich möchte in der Regel den Performance-Vorteil nutzen, den mir ein CoreSwitch als Hochleistungsswitch da bietet:
- Wenn ein Application-Server zu seinem SQL-Server will, dann soll der nicht über die Firewall müssen (das wäre z.B VLAN 6 zu VLAN 9) - das möchte ich hochperformant zur Verfügung stellen
- Wenn ein Client aus der Buchaltung zu einem Drucker will, soll der nicht über die Firewall müssen (Das wäre z.B VLAN 11 zu VLAN 14) - Perfomancetechnisch ist das bei dem konkreten Beipiel jetzt zwar nicht unbedingt relevant, aber hier geht es mir dann auch primäre darum, die reine Menge an Traffic von der Firewall fernzuhalten, damit die performancetechnisch nicht irgendwann wegen derartigen "Kleinkram" an ihre Grenzen kommt
- Wenn aber ein Client zum Server will - dass soll über die Firewall abgesichert werden (Das wäre z.B. VLAN 11 zu VLAN 6)
Ganz ehrlich - Ich finde Deine Vorhaben, die komplette Security auszuhebeln (weder VLANs noch Access Listen sind sicher) ziemlich gewagt. Wer sich einen Hochleistungs-Core-Switch ins Netz stellt, sollte an der Firewall nicht sparen. Wer bei Firewalls auch heute noch nur an den Perimeter denkt und sein internes Netz außen vor lässt, bewegt sich auf ziemlich dünnem Eis.
Unterschiedliche Netzsegmente sollten immer durch Firewalls getrennt werden, erst recht, wenn es um kritische Traffic Flows wie User zu Server geht. Du musst, in Zeiten wie diesen, davon ausgehen, dass Deine Clients kompromittiert sind und Deine Server immer angreifbar.
Unterschiedliche Netzsegmente sollten immer durch Firewalls getrennt werden, erst recht, wenn es um kritische Traffic Flows wie User zu Server geht. Du musst, in Zeiten wie diesen, davon ausgehen, dass Deine Clients kompromittiert sind und Deine Server immer angreifbar.
Ich denke, du hast da etwas falsch verstanden - vielleicht habe ich mich aber auch nicht klar genug ausgedrückt:
Ich will die Security ja in keiner Weise aushebeln - wir planen die VLAN's allerdings sehr kleinteilig und daher haben wir verschiedene "Security-Zonen" definiert, innerhalb derer wir nach einer Risikoabschätzung damit leben können, dass der Traffic zwischen den sich darin befindlichen VLAN's eben nicht zwangsläufig über eine Firewall laufen muss.
Das ist z.B bei unterschiedliche Client-VLAN's der Fall - da kommt es uns primär darauf an, Broadcast-Domains zu schaffen(Sei es pro Gebäude oder Etage etc.). Wenn man sich jedoch von einer solchen Zone in eine andere bewegen will, dann muss man zwangsweise über die Firewall. Das ist z.B. natürlich dann der Fall, wenn ein Client an einen Application Server oder einen File-Server ran will. Das kann aber auch nötig werden, wenn ein bestimmtes Client-VLAN gesondert von anderen Client-VLAN's abgeschottet werden soll (z.B dass der Finanzbuchhaltung).
Auch die Domain-Controller werden sicherlich in einer anderen Security-Zone liegen, als z.b. simple Fileserver. Du siehst also: Ich habe das Thema Sicherheit durchaus im Blick
Aber um das oben schon mal genannte Beispiel wieder aufzugreifen: Application-Server und deren SQL-Server würden wir zwar in unterschiedlichen VLAN's sehen - allerdings in der gleichen Security-Zone: Dann lassen wir per ACL nur den SQL-Port von einem VLAN zum anderen zu und wir haben einen akzeptablem Mix von Performance und Sicherheit. Den Mehrwert, derartigen Traffic zwischen Application-Server und SQL-Server extra über eine Firewall laufen zu lassen, sehen wir derzeit nicht.
Ich will die Security ja in keiner Weise aushebeln - wir planen die VLAN's allerdings sehr kleinteilig und daher haben wir verschiedene "Security-Zonen" definiert, innerhalb derer wir nach einer Risikoabschätzung damit leben können, dass der Traffic zwischen den sich darin befindlichen VLAN's eben nicht zwangsläufig über eine Firewall laufen muss.
Das ist z.B bei unterschiedliche Client-VLAN's der Fall - da kommt es uns primär darauf an, Broadcast-Domains zu schaffen(Sei es pro Gebäude oder Etage etc.). Wenn man sich jedoch von einer solchen Zone in eine andere bewegen will, dann muss man zwangsweise über die Firewall. Das ist z.B. natürlich dann der Fall, wenn ein Client an einen Application Server oder einen File-Server ran will. Das kann aber auch nötig werden, wenn ein bestimmtes Client-VLAN gesondert von anderen Client-VLAN's abgeschottet werden soll (z.B dass der Finanzbuchhaltung).
Auch die Domain-Controller werden sicherlich in einer anderen Security-Zone liegen, als z.b. simple Fileserver. Du siehst also: Ich habe das Thema Sicherheit durchaus im Blick
Aber um das oben schon mal genannte Beispiel wieder aufzugreifen: Application-Server und deren SQL-Server würden wir zwar in unterschiedlichen VLAN's sehen - allerdings in der gleichen Security-Zone: Dann lassen wir per ACL nur den SQL-Port von einem VLAN zum anderen zu und wir haben einen akzeptablem Mix von Performance und Sicherheit. Den Mehrwert, derartigen Traffic zwischen Application-Server und SQL-Server extra über eine Firewall laufen zu lassen, sehen wir derzeit nicht.
Ok, dann habe ich Dich in der Tat missverstanden. Mir macht aber trotzdem noch dieser Punkt zu schaffen:
Wenn eine der beiden Maschinen kompromittiert wird, hast Du keine Barriere mehr, die lateralen Bewegungen von Angreifern oder Schadcode unterbindet.
Ich würde mir das nochmal überlegen. Gute Firewalls kosten weitaus weniger Performance, als man allgemein hin annimmt. Vieles ist hardwarebeschleunigt, und wenn ein Traffic Flow erst mal etabliert ist, ist die Firewall auch nicht langsamer, als ein Router oder Switch - vorausgesetzt, sie ist mit den entsprechenden Interfaces ausgestattet.
Wenn ein Application-Server zu seinem SQL-Server will, dann soll der nicht über die Firewall müssen (das wäre z.B VLAN 6 zu VLAN 9) - das möchte ich hochperformant zur Verfügung stellen
Wenn eine der beiden Maschinen kompromittiert wird, hast Du keine Barriere mehr, die lateralen Bewegungen von Angreifern oder Schadcode unterbindet.
Ich würde mir das nochmal überlegen. Gute Firewalls kosten weitaus weniger Performance, als man allgemein hin annimmt. Vieles ist hardwarebeschleunigt, und wenn ein Traffic Flow erst mal etabliert ist, ist die Firewall auch nicht langsamer, als ein Router oder Switch - vorausgesetzt, sie ist mit den entsprechenden Interfaces ausgestattet.
Ja - ich stimme dir zu, dass es sicherlich diskussionswürdig ist, wie hoch man da das Security-Level wählt bzw. wie man eine solche Security-Zone letztlich definiert. Das habe ich auch hier schon am eignen Leib mitgemacht .
Im Ergebnis haben wir dann auch diverse Zonen definiert, in denen wir die verschiedensten Server deutlich voneinander getrennt belassen. z.B Domain, Controller, FileServer, Application-Server - die und andere stehen letztlich jeweils abgesichert für sich.
Wie gesagt diente das bisher gesagte primär als Beispiel um mein Vorhaben generell zu verdeutlichen. Der Ausgestaltung der einzelnen Sicherheitszonen ging letztlich in jedem Fall eine konkrete Risikobewertung voraus. So gesehen, denke ich dass wir da gut aufgestellt sind - aber natürlich gehen diesbezüglich die Meinungen immer auseinander.
Um hier nun aber nicht in eine generelle Diskussion über Sicherheitsbedenken auszuschweifen, würde ich an dieser Stelle gern wieder zum eigentlichen Kern meiner Frage zurückkommen: Wie kann ich mein Vorhaben technisch am besten umsetzen? Wie gesagt ist meine bisherige Idee die, verschiedene VRF-Instanzen zu etablieren.
.Im Ergebnis haben wir dann auch diverse Zonen definiert, in denen wir die verschiedensten Server deutlich voneinander getrennt belassen. z.B Domain, Controller, FileServer, Application-Server - die und andere stehen letztlich jeweils abgesichert für sich.
Wie gesagt diente das bisher gesagte primär als Beispiel um mein Vorhaben generell zu verdeutlichen. Der Ausgestaltung der einzelnen Sicherheitszonen ging letztlich in jedem Fall eine konkrete Risikobewertung voraus. So gesehen, denke ich dass wir da gut aufgestellt sind - aber natürlich gehen diesbezüglich die Meinungen immer auseinander
.Um hier nun aber nicht in eine generelle Diskussion über Sicherheitsbedenken auszuschweifen, würde ich an dieser Stelle gern wieder zum eigentlichen Kern meiner Frage zurückkommen: Wie kann ich mein Vorhaben technisch am besten umsetzen? Wie gesagt ist meine bisherige Idee die, verschiedene VRF-Instanzen zu etablieren.
dass ich eben vermeiden möchte, jeglichen VLAN-übergreifenden Traffic durch die Firewall zu jagen
Das tust du ja gar nicht, denn es ist ja einzig nur dieser Traffic in diese speziellen Sicherheitszonen/VLANs.Aber OK, rein auf die Performance bezogen hast du Recht.
Allerdings wenn es rein nur das Client VLAN ist wie du oben ja selber sagst versteht man deinen Ansatz nicht wirklich.
Dann versiehst du eben rein nur das Client VLAN nicht mit einer IP auf dem L3 Core und terminierst das L3 technisch auf der Firewall.
So rennt dann aller Traffic vom und zum Client Segment über die Firewall aber alles andere geht über den L3 Switch. Da wäre dann mit VRFs zu arbeiten bei nur einem Segment völlig unsinnig.
die lateralen Bewegungen von Angreifern oder Schadcode unterbindet.
Das kann man heute nicht mehr so sagen. Gute Core Switches haben heutzutage allesamt eine Flow Analyse die auch in höhere Layer sehen kann (sFlow, NetFlow). Mit einem einsprechenden IDS/IPS kann man heutzutage auch direkt auf dem Core sichere Konzepte umsetzen ohne alles über eine entsprechend skalierbare und damit sehr teure Firewall zu schleusen. In sofern ist das Konzept des TOs schon ein gängiges mit aktueller Hardware.Ein einziges Segment wie das Client Segment sollte die Firewall schon verkraften können...
Zitat von @aqui:
die lateralen Bewegungen von Angreifern oder Schadcode unterbindet.
Das kann man heute nicht mehr so sagen. Gute Core Switches haben heutzutage allesamt eine Flow Analyse die auch in höhere Layer sehen kann (sFlow, NetFlow). Mit einem einsprechenden IDS/IPS kann man heutzutage auch direkt auf dem Core sichere Konzepte umsetzen ohne alles über eine entsprechend skalierbare und damit sehr teure Firewall zu schleusen.Da kann ich Dir nur bedingt zustimmen. Im Grundsatz hast Du Recht, aber NetFlow z.B. kann auf Layer 7 nicht viel anrichten (zumal es ohnehin nur "beobachtende" Funktion hat). Vor allem nicht, wenn wir über verschlüsselten Traffic (SSL/TLS) sprechen, den Du mit einer vernünftigen Firewall durchaus aufbrechen kannst. Der Großteil des Traffics ist heute aber verschlüsselt.
Der Switch/Router mit Neflow kann nur auf Verbindungsereignisse schauen. Ob da jetzt, sagen wir mal, eine Pass the Hash Attacke abläuft oder sich ein Angreifer in einer auf Verbindungsebene erlaubten SSH Verbindung von Maschine zu Maschine hangelt, kriegst Du da nicht mit.
Selbst wenn Du ein IPS mit in den Flow hängst (der den Switch/Router, nebenbei bemerkt, entsprechend teurer macht) hast Du Dich an der Stelle nur marginal verbessert. Es bietet einen gewissen Schutz, klar, aber keinen ausreichenden.
In sofern ist das Konzept des TOs schon ein gängiges mit aktueller Hardware.
Ja, durchaus. Ich hatte ihn auch ursprünglich schlicht missverstanden. Mit dem, was er vorhat, ist er allemal besser aufgestellt, als viele andere.
Wahrscheinlich sehe mal wieder ich den Wald vor lauter Bäumen nicht und ich brauche nur das richtige Stichwort um mich danach in Grund und Boden zu schämen, dass ich es nicht wusste
Da ich den Thread jetzt mit meinem ganzen Security Gefasel etwas von Deiner eigentlichen Frage abgelenkt habe, versuche ich mal, Dir bei Deinem eigentlichen Problem zu helfen
Das Stichwort, das Du suchst, nennt sich "Policy Based Routing".
Ich weiß jetzt nicht, ob das auf Aruba Switchen funktioniert, aber es funktioniert definitiv auf Cisco Switchen. Also auf jeden Fall mal einen Versuch wert.
Mit Policy Based Routing kannst Du anhand von bestimmten Parametern die Routing Tabelle "überschreiben" oder "umgehen". Dabei definierst Du Regeln, die beschreiben, dass ein bestimmtes Ziel über einen anderen Weg zu erreichen ist, als über die lokale Routing Tabelle vorgegeben.
Also um bei Deinem Beispiel zu bleiben, Du hast VLAN 6 und 12, die beide direkt am Switch terminiert sind. Da beide Netze "directly connected" sind, routet der Switch direkt zwischen beiden Netzen. Das kannst Du auch mit einer statischen Route nicht ändern, weil directly connected Routen in der Routing Tabelle eine höhere Priorität haben, als statische Routen.
Hier kommt dann PBS ins Spiel. Du definierst eine Policy am Eingangs-Interface, die sinngemäß so aussieht:
if destination = subnet of VLAN 12 then route to ip_address_of_firewallUm auch die Rückantworten des Ziels in VLAN 12 über die Firewall zu leiten, richtest Du am dortigen Interface eine Policy Route für die andere Richtung ein.
Policy Routen "überschreiben" die interne Routing Tabelle, sprich, Deine Routen für die directly connected Netze greifen nicht mehr.
Soweit die Theorie. Ob und wie das auf einem Aruba löppt, musst Du selbst rausfinden
Mittels Policyrouting directly connected Routen überschreiben zu wollen ist - sofern überhaupt machbar - viel aufwändiger und fehleranfälliger, als VRF. Davon kann ich nur abraten. VRF ist das Mittel der Wahl.
Ich betreibe für eine Kommune ein stadteigenenes Glasfaserernetz, über welches sämtliche städtischen Einrichtungen - von der Kernverwaltung über Betriebshof, Bibliothek und Kultureinrichtungen, über Schulen und Kitas bis hin zu steuerbaren Polleranlagen und dergleichen - an zwei Rechenzentren angebunden sind. Auch hier gibt es sowohl zwischen den verschiedenen Einrichtungen als auch innerhalb der gleichen Einrichtung verschiedene Sicherheitszonen im Sinne von Teilnetzen, welche gegeneinander abgegrenzt werden müssen und zwischen denen ggf. nur stark reglementierter Verkehr zugelassen ist. Diese Reglementierung übernimmt ein Fortigate-Cluster, weil die Fortigate - anders als andere Firewallanbieter - den Traffic größtenteils auf speziellen ASICs auslagert und damit in der Regel mit Wirespeed arbeitet. Dennoch entlasten wir die Fortigate zusätzlich von unnötigen Routingaufgaben, indem wir IP-Netze, zwischen denen keinerlei Reglementierung des Traffics nötig ist, jeweils zu einer VRF VPN-Instance auf dem Core-Switch zusammenfassen. Innerhalb der VPN-Instance routet der Coreswitch in Wirespeed, ohne die Uplinks zum Fortigatecluster zu belasten. Nur Traffic, welcher zwischen verschiedenen Sicherheitszonen nötig ist, wird zur Segmentierungsfirewall geroutet.
Anders als es der TO vor hat, setzen wir jedoch innerhalb der gleichen VRF VPN-Instance keine Switch-ACLs ein. Davon würde ich auch allein schon aus administrativen Gründen abraten. Switch-ACLs arbeiten in der Regel nur non-stateful in Hardware. Nur wenige Switch-Hersteller bieten hardwarebeschleunigtes stateful ACL-Processing an und dafür braucht man in der Regel dann ein spezielles Erweiterungsmodul, welches selten günstiger ist, als eine passend dimensionierte Firewall.
Aufgrund des Erfordernisses, den Antworttraffic statisch zulassen zu müssen, sind non-stateful ACLs sehr mühselig und ungenau. Solchen Traffic beregelt man m.M.n. besser mit einer SPI-Firewall.
Gruß
sk
Ich betreibe für eine Kommune ein stadteigenenes Glasfaserernetz, über welches sämtliche städtischen Einrichtungen - von der Kernverwaltung über Betriebshof, Bibliothek und Kultureinrichtungen, über Schulen und Kitas bis hin zu steuerbaren Polleranlagen und dergleichen - an zwei Rechenzentren angebunden sind. Auch hier gibt es sowohl zwischen den verschiedenen Einrichtungen als auch innerhalb der gleichen Einrichtung verschiedene Sicherheitszonen im Sinne von Teilnetzen, welche gegeneinander abgegrenzt werden müssen und zwischen denen ggf. nur stark reglementierter Verkehr zugelassen ist. Diese Reglementierung übernimmt ein Fortigate-Cluster, weil die Fortigate - anders als andere Firewallanbieter - den Traffic größtenteils auf speziellen ASICs auslagert und damit in der Regel mit Wirespeed arbeitet. Dennoch entlasten wir die Fortigate zusätzlich von unnötigen Routingaufgaben, indem wir IP-Netze, zwischen denen keinerlei Reglementierung des Traffics nötig ist, jeweils zu einer VRF VPN-Instance auf dem Core-Switch zusammenfassen. Innerhalb der VPN-Instance routet der Coreswitch in Wirespeed, ohne die Uplinks zum Fortigatecluster zu belasten. Nur Traffic, welcher zwischen verschiedenen Sicherheitszonen nötig ist, wird zur Segmentierungsfirewall geroutet.
Anders als es der TO vor hat, setzen wir jedoch innerhalb der gleichen VRF VPN-Instance keine Switch-ACLs ein. Davon würde ich auch allein schon aus administrativen Gründen abraten. Switch-ACLs arbeiten in der Regel nur non-stateful in Hardware. Nur wenige Switch-Hersteller bieten hardwarebeschleunigtes stateful ACL-Processing an und dafür braucht man in der Regel dann ein spezielles Erweiterungsmodul, welches selten günstiger ist, als eine passend dimensionierte Firewall.
Aufgrund des Erfordernisses, den Antworttraffic statisch zulassen zu müssen, sind non-stateful ACLs sehr mühselig und ungenau. Solchen Traffic beregelt man m.M.n. besser mit einer SPI-Firewall.
Gruß
sk
1
Tolles Feedback ! Ein klassisches Bilderbuch VRF Netz. Besser hätte man es nicht beschreiben können. 👍
Zitat von @aqui:
Tolles Feedback ! Ein klassisches Bilderbuch VRF Netz. Besser hätte man es nicht beschreiben können. 👍
Tolles Feedback ! Ein klassisches Bilderbuch VRF Netz. Besser hätte man es nicht beschreiben können. 👍
Nunja. Ein "klassisches" Einsatzszenario für VRF wäre - wie Du es oben bereits zutreffend angemerkt hattest - tatsächlich eher die Dienstleistungen eines Providers für interne Netze mehrerer voneinander unabhängiger Kunden, deren interne Netze sich IP-technisch durchaus überschneiden können. Das ist in dem von mir vorgestellten Einsatzszenario nicht der Fall. Da hier alle "Kunden" vom gleichen Dienstleister betreut werden und letztlich "zum gleichen Verein" gehören, gibt es selbstverständlich für alle ein übergreifendes IP-Adressdesign ohne Überlappungen, um notwendige Kommunikationsbeziehungen zwischen den verschiedenen Einrichtungen und auch zwischen verschiedenen Sicherheitszonen der selben Einrichtung abbilden zu können. Mein Beispiel sollte lediglich zeigen, dass es durchaus üblich und zielführend ist, VRF lediglich dafür zu nutzen, die Last auf einer Segmentierungsfirewall zu senken. Und das ist ja das Anliegen des TO.
Gruß
sk
Zitat von @sk:
Mittels Policyrouting directly connected Routen überschreiben zu wollen ist - sofern überhaupt machbar - viel aufwändiger und fehleranfälliger, als VRF. Davon kann ich nur abraten. VRF ist das Mittel der Wahl.
Mittels Policyrouting directly connected Routen überschreiben zu wollen ist - sofern überhaupt machbar - viel aufwändiger und fehleranfälliger, als VRF. Davon kann ich nur abraten. VRF ist das Mittel der Wahl.
Das mit dem "überschreiben" der Routen war metaphorisch gemeint, daher auch die Anführungszeichen. Policy Routen haben jedenfalls eine höhere Priorität, als die Routingtabelle. Wenn eine PBS Policy matcht, findet kein Route Lookup mehr statt, die directly connected Route greift dann nicht. Das funktioniert 100%
Ob das jetzt aufwendiger oder fehleranfälliger ist, sei mal dahingestellt. Ob man in der Config jetzt ein paar Zeilen für PBS Policies drin stehen hat, oder eben ein paar Zeilen für die VRF Config, macht keinen Unterschied. Fehler kann man in beiden Fällen machen.
Wie andere hier schon angemerkt haben, sind VRFs eigentlich für größere multi-tenant Umgebungen gedacht. Funktioniere natürlich auch im Kleinen. Aber gerade da würde ich mir zwei Mal überlegen, welche Komplexität ich mir ans Bein binde. 2-3 Route Policies sind schnell geschrieben und auch schnell wieder aufgelöst, wenn ich sie nicht mehr brauche.
1
Wow - war jetzt über Weihnachten länger nicht da und dann dieses wirklich tolle Feedback. Ihr habt mir sehr geholfen, denn auch wenn die meinungen teils widersprüchlich sind, habe ich eine Menge guter Argumente für verschiedene Lösungswege erhalten. Ich werde die jetzt mal unserer konkreten Anforderung gegenüberstellen, die ich ja nur im groben beschrieben habe. Ich denke die von sk beschriebene Szenario samt Lösungsvorschlag kommt dem am nächsten. Alles in allem kann ich aber sagen: Meine Frage ist bestens beantwortet
Danke Euch allen!
Danke Euch allen!
1
Wo war denn da etwas widersprüchlich ? Alle Beteiligten sind da eher einer Meinung.
Hauptsache ist ja du hast einen Lösungsweg.
Hauptsache ist ja du hast einen Lösungsweg.
OK - hast recht. Da habe ich mich falsch ausgedrückt: Ich meinte unterschiedlich
.Aber genau das hatte ich im Prinzip ja erfragt: Welche Lösungsmöglichkeiten gibt es? Und mir wurden dankenswerterweise unterschiedliche aufgezeigt.
