Crash2001 Geschrieben 14. November 2011 Teilen Geschrieben 14. November 2011 Hallo zusammen, bei Cisco Geräten kann man ja normalerweise zum konfigurieren auf Consolenebene in ein Interface rein gehen und dort dann eine Access-Liste einbinden und dabei noch angeben, ob eingehende oder ausgehende Filterung. Bei der VSS vermisse ich diese Option jedoch bei den ganz normalen physikalischen Interfaces (L2 Switchports). Bei Port Channels ist es leider auch nicht möglich. Im vlan Interface gibt es diese Möglichkeit, doch dort bringt sie mir absolut nichts. Aus Sicherheitsgründen, und weil die Pakete nicht überall benötigt werden, sollen die HSRP Hello Pakete(UDP, Port 1985, Target: Multicast-Adresse 224.0.0.2) auf die Ports beschränkt werden, wo sie nötig sind und auf den anderen Ports sollen die Pakete entsprechend blockiert / rausgefiltert werden. Ich habe mir bereits mehrere Access-Listen (erweiterte und Standard) zum testen gemacht, aber ich bekomme die Accesslisten nicht entsprechend auf die Interface drauf, wo ich sie haben müsste. Ich kann sie irgendwie nur an Stellen einbinden, wo sie mir nichts bringt (L3-Interface allgemein). Dort wo ich sie benötigen würde, bekomme ich die Option "ip access-group [Nr] out" nicht angeboten. Bei den vlan Interfaces, die HSRP mit einem anderen L3-Switch sprechen sollen, kann ich den HSRP Traffic ja nciht blocken, da er ja dort benötigt wird. Wo anders wird mir aber irgendwie gar nciht angeboten, einen entsprecehnden Traffic zu blockieren. Hat vielleicht jemand eine Idee, wie ich es dennoch realisieren könnte? Hardware: Cisco 6509-E Supervisor Engine: VS-S720-10G IOS: S72033-ipservicesk9-mz.122-33.SXI4a Auf der Cisco Seite steht auch genau das, dass nur dort gefiltert werden kann, wo der Traffic auch durch geht - durch die vlan-Interface... in meinem Fall macht das aber wenig Sinn, da ja sonst HSRP nicht mehr funktionieren würde. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 14. November 2011 Teilen Geschrieben 14. November 2011 Also ich verstehe den Grund nicht, warum man HSRP filtern sollte. Wenn du es für ein VLAN konfigurierst bekommen alle Ports in diesem VLAN das HSRP und damit, meiner Meinung nach, niemand, der es nicht brauchen würde. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Crash2001 Geschrieben 15. November 2011 Autor Teilen Geschrieben 15. November 2011 (bearbeitet) Es ist einfach ein Sicherheitsaspekt. HSRP ist standardmässig nicht per Passwort gesichert (obwohl dies möglich wäre). Damit nun nicht die Gefahr besteht, dass sich jemand mit einem kleinen Router anstöpselt und zum Standardgateway für eines oder mehrere der Netze wird, möchte ich es halt einfach überall dort blocken, wo es nichts zu suchen hat. Das wäre in dem Falle jetzt z.B. auf den Access-Ports bzw auf den Ports, die zu den Access-Switchen gehen, damit nicht jeder Access-Port einzeln geblockt werden müsste, sondern einfach nur die 2 Uplink Ports. Zudem bin ich der Ansicht, dass HSRP-Pakete auf Access-Ports einfach nichts zu suchen haben - genausowenig wie z.B. Routingprotokolle oder irgendwelche andere Pakete, bei denen Informationen preisgegeben werden, oder aber die ein Sicherheitsrisiko mit sich bringen. Aus dem Grunde möchte ich sie halt bereits vom Core aus zu den Access-Switchen blocken, da diese eh alle nur Layer 2 sind und somit nicht am HSRP-Prozess teilnehmen. Beim Sniffen (Wireshark) stören diese Pakete natürlich auch - klar kann ich sie auch so aus dem rip rausfiltern, aber das ist jedes Mal wieder zusätzlicher Arbeitsaufwand. Nenn mir bitte einen Grund, wieso es sinnvoll wäre, dass ein User ein HSRP Paket bekommen sollte. :confused: Er nimmt nicht am HSRP Prozess teil, also sollte er auch nicht mit entsprechenden Paketen "belästigt" werden. HSRP passwortgesichert zu machen ist der nächste Schritt. Den darf ich aber leider nicht mal eben so unterm Tag machen, sondern dafür wird dann ein Change eingetragen (nächste Zeit erst mal Frozen Zone, das heisst vor Januar/Februaer wird das nichts)... Mir ist es halt Ende letzter Woche beim meinen eigenen Netzwerkverkehr zum analysieren rippen wieder aufgefallen und wollte dann jetzt mal was dagegen unternehmen. Bearbeitet 15. November 2011 von Crash2001 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lordy Geschrieben 15. November 2011 Teilen Geschrieben 15. November 2011 Du darfst neue ACLs einführen aber kein HSRP-Passwort setzen? Interessante Policy. Natürlich brauch ein Client-Rechner die HSRP-Pakete nicht, aber wenn du neue ACLs setzt solltest du die CPU-Auslastung im Auge behalten. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Crash2001 Geschrieben 15. November 2011 Autor Teilen Geschrieben 15. November 2011 Wenn du mal genau lesen würdest, dann würdest du selber sehen, dass das was du schreibst nicht das ist, was ich schrieb. Ich darf durchaus ein HSRP Passwort setzen. Nur darf ich die Änderung zurzeit nicht implementieren aufgrund einer Frozen Zone, da dies zu kurzzeitigen Problemen (bis es auf der anderen Seite auch eingestellt ist plus Zeit x) führen könnte. Eine Alternative wäre halt den HSRP Prozess zu löschen und neu anzulegen, aber dabei wechselt der aktive und standbye Router ja durchaus auch mal, wenn man nicht den aktiven zuerst anlegt... Dies dann pro HSRP-Prozess, von denen knapp 100 existieren, summiert sich dann doch schon auf (bei beiden Wegen)... Wenn man den HSRP-Prozess einseitig mit Passwort versieht, dann fällt die Verbindung zu den anderen HSRP-Teilnehmern (die ja noch kein Passwort vergeben haben) kurzzeitig aus. Somit existieren dann quasi zwei HSRP-Prozesse. Der eine mit nur einem MItglied und der andere mit den restlichen Mitgliedern. Erst wenn dort auch das Paswort eingegeben ist, können sie wieder miteinander kommunizieren und es gibt nur noch einen HSRP Master. Implementiert man hingegen eine einfach Filterliste, so muss man definitiv nicht befürchten, dass 2 oder mehr Geräte mal eben aktiver HSRP Master (Standardgateway, doppelte IPs und sonstige daraus resultierende Probleme) werden könnten deswegen, sondern maximal fällt die Verbindung auf dem entsprechenden Port mal kurzzeitig für < 1s aus. Die Auslastung ist definitiv nicht das Problem bei der VSS, da sie nicht sonderlich viel zu tun hat bisher. Ich werde jetzt mit dir aber nicht weiter über den Sinn und Zweck davon diskutieren, sondern ich möchte das implementieren, da es durchaus Sinn macht. Leider finde ich jedoch keinerlei Möglichkeit, es entsprechend zu konfigurieren. Wer kann mir dabei helfen, oder mir vielleicht eine alternative Konfigurationsmöglichkeit, die genau das macht, nennen? Es muss doch auf einem 6500er VSS möglich sein, dass man auf Switchingports eine Filterliste packt und nicht nur auf vlan-Interface und L3-Ports (da gehts ja afaik auch). Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.