8
VLANs und Management-Netzwerk Best-Practice
Hallo miteinander,
ich tüftle noch ein wenig mit meiner VLAN-Geschichte herum und bin noch nicht ganz sicher, ob ich den richtigen Weg ansetze und wie man das am gescheitestens mit dem Management-Netzwerk löst. Als erstes mal eine grobe Skizze mit einer anschließenden Erklärung:
Erläuterung:
- Der coreSwitch ist ein C3560G der auch die einzelnen VLANs auf L3 routet. Dies ist der zentrale Punkt, von wo es aus weiter Richtung Firewall/Internet geht. Hinweis: VLAN1 mit der IP 172.16.254.1 ist das alte Netz, das abgelöst werden soll.
- Drei weitere Hilfsswitches (Switch2 + Switch3 + Switch4) sind jeweils mittels eines 802.1q trunks mit dem coreSwitch verbunden
- Die Clients+Drucker hängen verteilt an Switch2+3+4, dessen ports sind als "switchport mode access" und "switchport access vlan 200" konfiguriert sind, also im VLAN200. Das Subnet hierzu ist 172.19.200.0/24
- Die Server hängen am coreSwitch, dessen ports sind ebenfalls access ports im VLAN100. Das Subnet hierzu ist 172.19.100.0/24
- Für meine Switches+Router nutze ich das VLAN254, subnet 172.19.254.0/24, damit alle Netzwerkgeräte in einem extra VLAN liegen. Vor allem der coreSwitch und das LAN-interface der pfSense Firewall muss für alle erreichbar sein. Ich bin mir hier jedoch nicht sicher, ob das Sinn macht, ein extra VLAN für die paar Geräte anzulegen. Falls ich das nicht machen sollte, welchem VLAN sollte ich dann das interface des coreSwitches und der pfSense legen, damit die für alle, also auch für workstations und normale User erreichbar (pingbar und als gateway nutzbar) sind?
- Die Switches 2+3+4 haben lediglich ein VLAN253 interface, um sie für Admins im Management erreichbar zu machen. Da sie nicht routen oder als gateways fungieren, benötigen Sie meiner Ansicht nach auch keine weiteren IP-Adressen. HINWEIS! In der oben gezeigten Skizze habe ich mich verschrieben! Die IPs der Switche sind wie folgt: switch2=172.19.253.2, switch3=172.19.253.3, switch4=172.19.253.4
- Am coreSwitch Port Gi0/20 ist das em0 interface der pfSense Firewall verbunden. Dieser Port Gi0/20 ist als trunk 802.1q konfiguriert und trägt alle VLAN ids. Dessen native vlan id ist noch auf default also 1 eingestellt.
- Der interfaces der pfSense sehen momentan wie folgt aus...
- em1(WAN1) und em3(WAN2) sind die zwei Leitungen ins Internet
- em2 ist meine DMZ, dieses Interface ist mit einem Kabel an dem extra DMZ-Switch verbunden wo auch diverse DMZ-Server angeschlossen sind. Dies ist ein isolierter Switch und hat keine Verbindung sonstwohin.
Nun zu meinen Fragen:
(1) Laut Forenbeiträgen gesehen, dass mancheiner das management-Netzwerk absichtlich auf VLAN1 belässt, damit es untagged bleibt. Gründe hierfür waren: a.) wenn's mal brennt und man schnell konfigurieren muss, kann man ganz easy ein Notebook dranhängen, IP im jeweiligen Subnet vergeben und verbinden. Bei einem VLAN kann das evtl. schon problematischer oder hürdenreicher sein. Als andere Erklärung wird angegeben, dass b.) manche Hosts das MGMT-Netzwerk nur in VLAN1 legen können. Wie genau muss ich mir das vorstellen? Welche Art von Geräte wären das als Beispiel, damit ich mir darunter was vorstellen kann? Der hier wiederum meint, dass empfohlen wird das MGMT-Netz in ein tagged VLAN zu setzen. Irgendwie macht mich das ganz konfus und ich weiß nicht welchen Weg ich gehen sollte und wie man es "richtig" machen sollte.
(2) Dann werde ich noch ein BlackHole-Vlan mit der id 13 gründen und alle ungenutzten Ports auf meinen Switches als "switchport mode access" und "switchport access vlan 13" konfigurieren. Wenn also jemand unbefugt da ein Gerät reinhängt, dann schwirrt er eben mit anderen uninteressanten Geräten im VLAN13 herum und kann meinen produktiven Netzen nichts anhaben. Das ist soweit klar, und ich hoffe nicht allzukompliziert. (korrigiert mich falls ich das falsch aufgefasst haben sollte)
(3) zu dem native VLAN beschreibt der weiter oben bereits gezeigte Cisco-Link, dass im default vlan1 Kontrollpakete in einem Trunk übermittelt werden. Ich schätze mal, damit sind Sachen wie DTP und Bridge-Informationen gemeint, oder? Was mich aber verwirrt: es heißt: wenn das native VLAN von 1 auf xyz gewechselt wird, dann erfolgen diese Kontrollpakete ab sofort im "getaggten" Modus durch den trunk. Wieso? Ich dachte immer, ein default vlan (=native vlan) wird immer untagged übertragen. Bitte um Aufklärung
EDIT: In diesem Cisco Dokument heißt es ganz unten, dass controll traffic IMMER auf VLAN1 übertragen wird, also auch dann wenn das native vlan auf einer andere id gewechselt wurde. Kann man daraus resultierend sagen, dass der control traffic also immer durch VLAN1 gejagt wird und zwar TAGGED ?
Momentan neige ich also dazu:
- VLAN253 fürs Management zu nutzen und auf den switches, die kein routing machen sollen oder als gateway genutzt werden, konfiguriere ich nur ein VLAN253 interface mit ner IP-Adresse, über die der jeweilige Switch angesprochen und konfiguriert wird. Zum Konfigurieren/Verbinden auf den switch wird nur ssh encrypted zugelassen
- ein VLAN666 als BlackHole-VLAN zu erstellen und alle ungenutzten Ports auf meinen Switches mit diesem VLAN666 als access ports zu konfigurieren und sie zusätzlichen mit "shutdown" abzuschalten
- auf all den ports (auf alle switche) das native vlan auf id 3 abzuändern (vlan3 wird bisher nirgends genutzt und ist somit frei).
Ist das ok so, oder gibt's da was einzuwenden?
(4) Wie ganz oben in der Erklärung schon gefragt: wie sollte ich eurer Meinung nach die Verbindung zwischen coreSwitch c3560g und dem em0/LAN Interface der pfSense herstellen? Ein Trunk muss es ja auf jeden Fall sein, da ich mehrere ids bis zur Firewall hin übertragen möchte. Aber wie sollte die Verbindung zwischen coreSwitch + pfSense Schnittstelle verlaufen? Momentan kann ich die pfSense sowohl via 172.19.254.254 als auch über 172.19.253.254 erreichen. Also ich komm entweder via VLAN253 oder VLAN254 an sie ran. Das VLAN253 will ich ja eigentlich für Management nutzen, aber ich muss die pfSense doch auch mittels einer "anderen" IP-Adresse für die "normale-LAN-Hosts" erreichbar machen können. In welchem VLAN? Oder gar keins und ich setz native vlan einfach auf <irgendetwas> ?
(5) Achja... momentan würde ja jeder auf das Management-Netz kommen können, weil noch keine ACLs auf dem coreSwitch konfiguriert sind und globales ip-routing aktiviert ist. Damit ich jedoch nur Admins den Zugriff auf das Management-Netz VLAN253(172.19.253.0/24) gestatte sehe ich momentan zwei Lösungen:
...a.} die Arbeitsrechner der Admins sind mit mindestens 2 Netzwerkkarten ausgestattet oder sind 802.1q-fähig, damit sie in mehreren VLANs arbeiten können. Dann würde eine NIC (oder virtuelle NIC) eben im VLAN200(172.19.200.0/24) liegen, also dort wo alle andren Clients üblicherweise liegen, damit sie im produktiven Netz arbeiten können. Und die zweite NIC (bzw. virtuelle NIC) würde im VLAN253(172.19.254.0/24) konfiguriert, damit die Admins sich mit dem MGMT-Netz verbinden können. Dazu müsste ich die Switchports, an denen die Admin-PCs hängen, als 802.1q trunk konfigurieren und die entsprechenden vlan ids eben erlauben, damit die mitübertragen werden (tagged)
...b.} die Admins-PCs haben keine zweite NIC, oder sind nicht VLAN-fähig. Somit haben die wie jeder andere Mitarbeiter eine 172.19.200.xy/24 IP und sind als "switchport mode access" im VLAN200 konfiguriert. In dem coreSwitch müsste ich dann wohl eine ACL erstellen, die explizit die statische IP-Adresse von Admin1 und Admin2 erlaubt, auf das VLAN253er Netz zu gelangen und alle anderen werden gedroppt. Seh ich das richtig oder lieg ich komplett falsch? Falls ja, wie sehe so eine ACL-Regel richtig konfiguriert aus für die zwei in der Skizze angegebenen Admins mit IPs 172.19.200.101 und 172.19.200.102 ? Diese b)-Möglichkeit ist aber wohl nicht so die gute Art schätze ich, oder?
Jetzt ist's schon spät und ich bin müde. Ich freue mich auf konstruktive Kritik und einigen Antworten zu meinen noch offenen Fragen. Vielen herzlichen Dank euch Allen.
Schönes Wochenende,
Pangu
ich tüftle noch ein wenig mit meiner VLAN-Geschichte herum und bin noch nicht ganz sicher, ob ich den richtigen Weg ansetze und wie man das am gescheitestens mit dem Management-Netzwerk löst. Als erstes mal eine grobe Skizze mit einer anschließenden Erklärung:
Erläuterung:
- Der coreSwitch ist ein C3560G der auch die einzelnen VLANs auf L3 routet. Dies ist der zentrale Punkt, von wo es aus weiter Richtung Firewall/Internet geht. Hinweis: VLAN1 mit der IP 172.16.254.1 ist das alte Netz, das abgelöst werden soll.
- Drei weitere Hilfsswitches (Switch2 + Switch3 + Switch4) sind jeweils mittels eines 802.1q trunks mit dem coreSwitch verbunden
- Die Clients+Drucker hängen verteilt an Switch2+3+4, dessen ports sind als "switchport mode access" und "switchport access vlan 200" konfiguriert sind, also im VLAN200. Das Subnet hierzu ist 172.19.200.0/24
- Die Server hängen am coreSwitch, dessen ports sind ebenfalls access ports im VLAN100. Das Subnet hierzu ist 172.19.100.0/24
- Für meine Switches+Router nutze ich das VLAN254, subnet 172.19.254.0/24, damit alle Netzwerkgeräte in einem extra VLAN liegen. Vor allem der coreSwitch und das LAN-interface der pfSense Firewall muss für alle erreichbar sein. Ich bin mir hier jedoch nicht sicher, ob das Sinn macht, ein extra VLAN für die paar Geräte anzulegen. Falls ich das nicht machen sollte, welchem VLAN sollte ich dann das interface des coreSwitches und der pfSense legen, damit die für alle, also auch für workstations und normale User erreichbar (pingbar und als gateway nutzbar) sind?
- Die Switches 2+3+4 haben lediglich ein VLAN253 interface, um sie für Admins im Management erreichbar zu machen. Da sie nicht routen oder als gateways fungieren, benötigen Sie meiner Ansicht nach auch keine weiteren IP-Adressen. HINWEIS! In der oben gezeigten Skizze habe ich mich verschrieben! Die IPs der Switche sind wie folgt: switch2=172.19.253.2, switch3=172.19.253.3, switch4=172.19.253.4
- Am coreSwitch Port Gi0/20 ist das em0 interface der pfSense Firewall verbunden. Dieser Port Gi0/20 ist als trunk 802.1q konfiguriert und trägt alle VLAN ids. Dessen native vlan id ist noch auf default also 1 eingestellt.
- Der interfaces der pfSense sehen momentan wie folgt aus...
- em1(WAN1) und em3(WAN2) sind die zwei Leitungen ins Internet
- em2 ist meine DMZ, dieses Interface ist mit einem Kabel an dem extra DMZ-Switch verbunden wo auch diverse DMZ-Server angeschlossen sind. Dies ist ein isolierter Switch und hat keine Verbindung sonstwohin.
Nun zu meinen Fragen:
(1) Laut Forenbeiträgen gesehen, dass mancheiner das management-Netzwerk absichtlich auf VLAN1 belässt, damit es untagged bleibt. Gründe hierfür waren: a.) wenn's mal brennt und man schnell konfigurieren muss, kann man ganz easy ein Notebook dranhängen, IP im jeweiligen Subnet vergeben und verbinden. Bei einem VLAN kann das evtl. schon problematischer oder hürdenreicher sein. Als andere Erklärung wird angegeben, dass b.) manche Hosts das MGMT-Netzwerk nur in VLAN1 legen können. Wie genau muss ich mir das vorstellen? Welche Art von Geräte wären das als Beispiel, damit ich mir darunter was vorstellen kann? Der hier wiederum meint, dass empfohlen wird das MGMT-Netz in ein tagged VLAN zu setzen. Irgendwie macht mich das ganz konfus und ich weiß nicht welchen Weg ich gehen sollte und wie man es "richtig" machen sollte.
(2) Dann werde ich noch ein BlackHole-Vlan mit der id 13 gründen und alle ungenutzten Ports auf meinen Switches als "switchport mode access" und "switchport access vlan 13" konfigurieren. Wenn also jemand unbefugt da ein Gerät reinhängt, dann schwirrt er eben mit anderen uninteressanten Geräten im VLAN13 herum und kann meinen produktiven Netzen nichts anhaben. Das ist soweit klar, und ich hoffe nicht allzukompliziert. (korrigiert mich falls ich das falsch aufgefasst haben sollte)
(3) zu dem native VLAN beschreibt der weiter oben bereits gezeigte Cisco-Link, dass im default vlan1 Kontrollpakete in einem Trunk übermittelt werden. Ich schätze mal, damit sind Sachen wie DTP und Bridge-Informationen gemeint, oder? Was mich aber verwirrt: es heißt: wenn das native VLAN von 1 auf xyz gewechselt wird, dann erfolgen diese Kontrollpakete ab sofort im "getaggten" Modus durch den trunk. Wieso? Ich dachte immer, ein default vlan (=native vlan) wird immer untagged übertragen. Bitte um Aufklärung
EDIT: In diesem Cisco Dokument heißt es ganz unten, dass controll traffic IMMER auf VLAN1 übertragen wird, also auch dann wenn das native vlan auf einer andere id gewechselt wurde. Kann man daraus resultierend sagen, dass der control traffic also immer durch VLAN1 gejagt wird und zwar TAGGED ?
Momentan neige ich also dazu:
- VLAN253 fürs Management zu nutzen und auf den switches, die kein routing machen sollen oder als gateway genutzt werden, konfiguriere ich nur ein VLAN253 interface mit ner IP-Adresse, über die der jeweilige Switch angesprochen und konfiguriert wird. Zum Konfigurieren/Verbinden auf den switch wird nur ssh encrypted zugelassen
- ein VLAN666 als BlackHole-VLAN zu erstellen und alle ungenutzten Ports auf meinen Switches mit diesem VLAN666 als access ports zu konfigurieren und sie zusätzlichen mit "shutdown" abzuschalten
- auf all den ports (auf alle switche) das native vlan auf id 3 abzuändern (vlan3 wird bisher nirgends genutzt und ist somit frei).
Ist das ok so, oder gibt's da was einzuwenden?
(4) Wie ganz oben in der Erklärung schon gefragt: wie sollte ich eurer Meinung nach die Verbindung zwischen coreSwitch c3560g und dem em0/LAN Interface der pfSense herstellen? Ein Trunk muss es ja auf jeden Fall sein, da ich mehrere ids bis zur Firewall hin übertragen möchte. Aber wie sollte die Verbindung zwischen coreSwitch + pfSense Schnittstelle verlaufen? Momentan kann ich die pfSense sowohl via 172.19.254.254 als auch über 172.19.253.254 erreichen. Also ich komm entweder via VLAN253 oder VLAN254 an sie ran. Das VLAN253 will ich ja eigentlich für Management nutzen, aber ich muss die pfSense doch auch mittels einer "anderen" IP-Adresse für die "normale-LAN-Hosts" erreichbar machen können. In welchem VLAN? Oder gar keins und ich setz native vlan einfach auf <irgendetwas> ?
(5) Achja... momentan würde ja jeder auf das Management-Netz kommen können, weil noch keine ACLs auf dem coreSwitch konfiguriert sind und globales ip-routing aktiviert ist. Damit ich jedoch nur Admins den Zugriff auf das Management-Netz VLAN253(172.19.253.0/24) gestatte sehe ich momentan zwei Lösungen:
...a.} die Arbeitsrechner der Admins sind mit mindestens 2 Netzwerkkarten ausgestattet oder sind 802.1q-fähig, damit sie in mehreren VLANs arbeiten können. Dann würde eine NIC (oder virtuelle NIC) eben im VLAN200(172.19.200.0/24) liegen, also dort wo alle andren Clients üblicherweise liegen, damit sie im produktiven Netz arbeiten können. Und die zweite NIC (bzw. virtuelle NIC) würde im VLAN253(172.19.254.0/24) konfiguriert, damit die Admins sich mit dem MGMT-Netz verbinden können. Dazu müsste ich die Switchports, an denen die Admin-PCs hängen, als 802.1q trunk konfigurieren und die entsprechenden vlan ids eben erlauben, damit die mitübertragen werden (tagged)
...b.} die Admins-PCs haben keine zweite NIC, oder sind nicht VLAN-fähig. Somit haben die wie jeder andere Mitarbeiter eine 172.19.200.xy/24 IP und sind als "switchport mode access" im VLAN200 konfiguriert. In dem coreSwitch müsste ich dann wohl eine ACL erstellen, die explizit die statische IP-Adresse von Admin1 und Admin2 erlaubt, auf das VLAN253er Netz zu gelangen und alle anderen werden gedroppt. Seh ich das richtig oder lieg ich komplett falsch? Falls ja, wie sehe so eine ACL-Regel richtig konfiguriert aus für die zwei in der Skizze angegebenen Admins mit IPs 172.19.200.101 und 172.19.200.102 ? Diese b)-Möglichkeit ist aber wohl nicht so die gute Art schätze ich, oder?
Jetzt ist's schon spät und ich bin müde. Ich freue mich auf konstruktive Kritik und einigen Antworten zu meinen noch offenen Fragen. Vielen herzlichen Dank euch Allen.
Schönes Wochenende,
Pangu
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: 254193
Url: https://administrator.de/contentid/254193
Ausgedruckt am: 24.11.2024 um 03:11 Uhr
8 Kommentare
Neuester Kommentar
Hi
zu Punkt 1 Management Netzwerk:
wir haben das bei uns vollständig auf allen Switchen anliegen, dort "rankommen" tut nur unser Management- und Monitoring-Server (darüber verwalten wir das auch alles und nicht von den eigenen Clients aus), das Netz an sich kommt nicht ins Internet und wird nicht geroutet.
zu Punkt 2 "BlackHole"
das würde ich so definitiv nicht umsetzen, da würde ich mir eher die Arbeit mit einem Radius Server machen, so dass bekannte Geräte ins interne Netz kommen und alles andere ins Quarantäne Netz verschoben wird, dann muss man nicht immer händisch überall eingreifen wenn man etwas umstellt oder die Geräte an andere Plätze setzt
zu Punkt 3 "native VLAN"
wir haben das bei allen Geräte auf VLAN777 geändert, da wir das VLAN_1 an anderer Stelle benötigen, das liegt aber auch an keinen Port an der zu einem anderen Switch rübergeht. Unsere VLANs in den Uplinks sind Tagged - wobei auch die Ports auf allen Switchen festgelegt sind (da wir nur Brocade im Einsatz haben ist das i.d.R. immer Port 1-4 & die Glasfaserports - bei den Access-Switchen).
zu Punkt 4 "Management VLAN und pFense"
Ich denke mal, dass die beiden VLANs sich mittels eines Layer3 Routers finden und somit auch die Zugriffe untereinander geroutet werden, wie im Punkt 1 geschrieben, wird das Management VLAN nicht geroutet bei uns, ich würde das Grundsätzlich auch ausschalten und nur für bestimmte Geräte freischalten zwecks Management
zu Punkt 5 "Management Netz"
wir auch in Punkt 1 beschrieben, ich würde nicht jedem Client-Rechner der Admins zugriff geben, dass lässt sich sicherer über einen oder mehrere Verwaltungsserver lösen wo man dann auch alle notwendigen Tools installieren kann die man ggf. benötigt.
Just my 2 Cent
clSchak
zu Punkt 1 Management Netzwerk:
wir haben das bei uns vollständig auf allen Switchen anliegen, dort "rankommen" tut nur unser Management- und Monitoring-Server (darüber verwalten wir das auch alles und nicht von den eigenen Clients aus), das Netz an sich kommt nicht ins Internet und wird nicht geroutet.
zu Punkt 2 "BlackHole"
das würde ich so definitiv nicht umsetzen, da würde ich mir eher die Arbeit mit einem Radius Server machen, so dass bekannte Geräte ins interne Netz kommen und alles andere ins Quarantäne Netz verschoben wird, dann muss man nicht immer händisch überall eingreifen wenn man etwas umstellt oder die Geräte an andere Plätze setzt
zu Punkt 3 "native VLAN"
wir haben das bei allen Geräte auf VLAN777 geändert, da wir das VLAN_1 an anderer Stelle benötigen, das liegt aber auch an keinen Port an der zu einem anderen Switch rübergeht. Unsere VLANs in den Uplinks sind Tagged - wobei auch die Ports auf allen Switchen festgelegt sind (da wir nur Brocade im Einsatz haben ist das i.d.R. immer Port 1-4 & die Glasfaserports - bei den Access-Switchen).
zu Punkt 4 "Management VLAN und pFense"
Ich denke mal, dass die beiden VLANs sich mittels eines Layer3 Routers finden und somit auch die Zugriffe untereinander geroutet werden, wie im Punkt 1 geschrieben, wird das Management VLAN nicht geroutet bei uns, ich würde das Grundsätzlich auch ausschalten und nur für bestimmte Geräte freischalten zwecks Management
zu Punkt 5 "Management Netz"
wir auch in Punkt 1 beschrieben, ich würde nicht jedem Client-Rechner der Admins zugriff geben, dass lässt sich sicherer über einen oder mehrere Verwaltungsserver lösen wo man dann auch alle notwendigen Tools installieren kann die man ggf. benötigt.
Just my 2 Cent
clSchak
1+5) nunja, einen dedizierten Management-/Monitoringserver zu haben ist ja an sich ok, aber dann connecten sich also die zugriffsberechtigten Admins jedesmal auf diesen Host (per RDP, VNC, SSH, oder wie verbindet ihr euch drauf?) und führen die gewünschte Tätigkeit durch? Klappt das auch problemlos remote über VPN ? Ich denke wohl schon, aber das würde gleichzeitig auch bedeuten, dass ihr ein Routing eingerichtet habt, so daß ihr via VPN auf diese Management-Station draufkommen könnt, oder nicht? Und wenn ihr aber Routing eingerichtet habt, dann ist ja der ursprüngliche Zweck (=die zwangshafte Trennung auf eine dedizierte Station) wiederum sinnlos. Die zentrale Mgmt-Station ist ja ziemlich geschickt, auch wegen der ganzen Tools die man nur einmal installiert und zur Verfügung habt. Aber wenn's mal wirklich brennt und man schnell ran muss um ein Gerät zu administrieren, was macht ihr wenn eure Management-Station auch vom Problem betroffen ist (Murphy's law) ? dann sollte man doch mindestens einen Port am Switch als Noteingang mit dem jeweiligen MGMT-VLAN als access static switchport konfiguriert haben, so dass man sein Laptop anstöpseln kann, sich 'ne IP aus der passenden subnet verpasst, um auf die jeweilig zu administrierenden Hosts verbinden zu können. Oder nicht? Und remote über VPN wird das alles noch schwieriger, weil eben Routing zwingend erforderlich wird. Korrigiert mich falls ich falsch liegen sollte
2) FreeRadius auf GNU/Linux wäre auch meine erste Wahl gewesen, das habe ich bereits überprüft und mir Gedanken gemacht. Ursprünglich wollte ich das auch so. Aber wie es leider Gottes Murphy so haben wollte ==> die eingesetzten Switche überall verteil können nicht 802.1X, lediglich 3-5 Switche können das. Aber die Workstations sind noch vereilt an vielen anderen Switches angeschlossen, die leider nicht 802.1X fähig sind, somit kann ich das nicht durchsetzen, leider. Deshalb habe ich jetzt mal ein BlackHole-VLAN 888 eingerichtet und konfiguriere alle ungenutzten Ports als access switchports auf diese id 888 und zusätzlich "shutdown".
3) ich plane bei allen eingesetzten Trunkports das native vlan 99 einzusetzen, außer: bei bestimmten Ports an denen am anderen Ende irgendwo Hosts hängen, die es mir nicht gestatten das Management VLAN anzugeben. Da normalerweise das Management-interface immer untagged übertragen wird, kann ich durch "native vlan 254" diese Geschichte so auf mein management-Netz mit der id 254 umlenken. Bitte korrigiert mich auch hier, falls das ein falscher Gedankenansatz wäre
4) wenn ich deine unter Punkt eins aufgeführte Möglichkeit nutzen sollte, wäre das auch sinnvoll das Management-Netz nirgends zu routen und erscheint auch in meinen Augen sehr sinnvoll. Das geht natürlich nur, falls ich das so umsetzen sollte wie du. Andernfalls dachte ich mir eben, dass ich am coreSwitch wo zentral alle VLANs reinlaufen und geroutet werden, einfach eine ACL bastle, die nur bestimmte IP-Adressen (von den Admins) erlauben, aufs management-VLAN draufzukommen. Hier wäre natürlich noch eine Sicherheitslücke offen: wenn ein Angreifer die IP-Adresse eines Admin-Clients kennen würde, so könnte er versuchen, sich diese zu schnappen. Deshalb ist diese einfachste von mir beschriebene Methode nicht besonders zu empfehlen in meinen Augen. Die andere bessere Möglichkeit wäre halt: die Workstations der Administratoren verfügen über 802.1q fähige NICs und richten eine zusätzliche virtuelle (oder von mir aus eine zweite NIC einbauen, also völlig autark) Netzwerkschnittstelle auf das management-VLAN ein, so daß sie Zugriff auf das management-VLAN erhalten. Dadurch dass an dem switchport, an dem diese Admin-Workstations dranhängen als trunk konfiguriert ist und das management VLAN nur an diesen ports mitübertragen wird, besteht keine Sicherheitsgefahr mehr, dass ein "fremder" Zugriff aufs mgmt-vlan erhält. Ist das soweit richtig wie ich es beschrieben habe oder irre ich mich?
2) FreeRadius auf GNU/Linux wäre auch meine erste Wahl gewesen, das habe ich bereits überprüft und mir Gedanken gemacht. Ursprünglich wollte ich das auch so. Aber wie es leider Gottes Murphy so haben wollte ==> die eingesetzten Switche überall verteil können nicht 802.1X, lediglich 3-5 Switche können das. Aber die Workstations sind noch vereilt an vielen anderen Switches angeschlossen, die leider nicht 802.1X fähig sind, somit kann ich das nicht durchsetzen, leider. Deshalb habe ich jetzt mal ein BlackHole-VLAN 888 eingerichtet und konfiguriere alle ungenutzten Ports als access switchports auf diese id 888 und zusätzlich "shutdown".
3) ich plane bei allen eingesetzten Trunkports das native vlan 99 einzusetzen, außer: bei bestimmten Ports an denen am anderen Ende irgendwo Hosts hängen, die es mir nicht gestatten das Management VLAN anzugeben. Da normalerweise das Management-interface immer untagged übertragen wird, kann ich durch "native vlan 254" diese Geschichte so auf mein management-Netz mit der id 254 umlenken. Bitte korrigiert mich auch hier, falls das ein falscher Gedankenansatz wäre
4) wenn ich deine unter Punkt eins aufgeführte Möglichkeit nutzen sollte, wäre das auch sinnvoll das Management-Netz nirgends zu routen und erscheint auch in meinen Augen sehr sinnvoll. Das geht natürlich nur, falls ich das so umsetzen sollte wie du. Andernfalls dachte ich mir eben, dass ich am coreSwitch wo zentral alle VLANs reinlaufen und geroutet werden, einfach eine ACL bastle, die nur bestimmte IP-Adressen (von den Admins) erlauben, aufs management-VLAN draufzukommen. Hier wäre natürlich noch eine Sicherheitslücke offen: wenn ein Angreifer die IP-Adresse eines Admin-Clients kennen würde, so könnte er versuchen, sich diese zu schnappen. Deshalb ist diese einfachste von mir beschriebene Methode nicht besonders zu empfehlen in meinen Augen. Die andere bessere Möglichkeit wäre halt: die Workstations der Administratoren verfügen über 802.1q fähige NICs und richten eine zusätzliche virtuelle (oder von mir aus eine zweite NIC einbauen, also völlig autark) Netzwerkschnittstelle auf das management-VLAN ein, so daß sie Zugriff auf das management-VLAN erhalten. Dadurch dass an dem switchport, an dem diese Admin-Workstations dranhängen als trunk konfiguriert ist und das management VLAN nur an diesen ports mitübertragen wird, besteht keine Sicherheitsgefahr mehr, dass ein "fremder" Zugriff aufs mgmt-vlan erhält. Ist das soweit richtig wie ich es beschrieben habe oder irre ich mich?
Unsere Management Systeme haben NIC die VLAN fähig sind, haben uns ein paar gebrauchte DL360G5 besorgt (wir haben 3 Management Systeme die fest zugeordnet sind, kosten um die 200€ je Stück), zu dem haben alle Admin-Account eine 2 Faktor Authentifizierung (haben wir mit der Anschaffung der neuen Fortinets auch direkt implementiert) und somit ist der entsprechende Zugriff sauber reglementiert 
.
Und ja wir haben ein voll geroutetes Netz bei uns und alle Switche können 802.1x,
Und wenn du dein Netz 100% dicht haben willst, darf es keinen Kontakt zum Internet haben, egal über welchem Weg.
.Und ja wir haben ein voll geroutetes Netz bei uns und alle Switche können 802.1x,
Und wenn du dein Netz 100% dicht haben willst, darf es keinen Kontakt zum Internet haben, egal über welchem Weg.
Und wie greifst du also auf eine management-Station zu im Falle eines dringenden notwendigen Eingriffes, wenn du nicht in der Firma, sondern zu Hause bist?
VPN, wenn das DirectAccess down sein sollte, dann via L2TP und dann via RDP auf die Management Systeme. Damit der gesamte externe Zugriff wegbricht müssten 2 Hausanschlüsse ausfallen (2 Unterschiedliche Anbieter) und die Wahrscheinlichkeit ist gering.
Und wenn alles Stricke reißen muss man halt die 14km zur Firma fahren - aber dann hat man ohnehin ganz andere Probleme ...
Und wenn alles Stricke reißen muss man halt die 14km zur Firma fahren - aber dann hat man ohnehin ganz andere Probleme ...
wie genau funktioniert das? Ist OpenVPN dasselbe oder was ganz anderes? Mit L2TP bzw. IPSec hatte ich bisher nicht gearbeitet. Hab ich irgendwelche Vor-/Nachteile wenn ich diese Lösung dem OpenVPN bevorzugen würde? Vielleicht kannst du mir das kurz erklären wie das genau abgewickelt wird?
die Lösung ist ja die gleiche, nur das wir dafür die Firewall nutzen und keine OpenSource Geschichte. Die Management-Server sind alle auch über das reguläre LAN erreichbar lassen aber nur eine 2 Faktor Authentifizierung zu, ansonsten kommt man dort nicht drauf - die haben lediglich einen dedizierten Netzwerkport im Management LAN um dort darauf Zugriff zu haben.
Das gleiche System ist beim Monitoring eingestellt, nur das hier zusätzlich ein SMTP Relay für das absetzen von Meldungen konfiguriert ist, damit die Geräte im Management LAN auch Mails absetzen können.
Das gleiche System ist beim Monitoring eingestellt, nur das hier zusätzlich ein SMTP Relay für das absetzen von Meldungen konfiguriert ist, damit die Geräte im Management LAN auch Mails absetzen können.
Auch wenn das etwas vom eigentlich Thema abschweift ... Jetzt war ich echt neugierig und musste lesen was es mit L2TP auf sich hat. Ich muss ehrlich zugestehen, dass ich mich bisher noch nie mit PPTP oder IPSec auseinandergesetzt hatte. Ich hatte nur im Hinterkopf "Finger weg von PPTP, weil es unsicher ist!". Nachdem ich mir dies, das, jenes und klick denke ich, dass ich mit OpenVPN weiterhin ganz gut fahre. Vor allem setz ich das jahrelang ein und hab schon 'nen Dutzend Installationen hinter mir. Also werd ich wohl brav OpenVPN weiternutzen, auch auf meiner neuen pfSense. Nun zurück zum Haupt-Thema ...
wie machen's denn all die anderen, mich würden auch andere Meinungen interessieren. Freue mich auf euer feedback
@clshak: soweit vielen herzlichen Dank für dein feedback
wie machen's denn all die anderen, mich würden auch andere Meinungen interessieren. Freue mich auf euer feedback
@clshak: soweit vielen herzlichen Dank für dein feedback
