MAC access-lists und access groups funktionieren nicht auf c2960

[Poison Nuke 10]

Hio,

 

ich versuche gerade über mac access lists den Datenverkehr weiter zu kontrollieren.

Rein vom Konzept her auch von der Beschreibung von Cisco her sollte es ja eigentlich so wie IP Access lists sein, sprich es wird bei jedem Paket der MAC Header gegen die ACL verglichen und wenn ein Paket auf kein permit Argument der ACL passt wird es verworfen.

 

Oder nicht?

 

 

weil, hier die Konfig:

 

c2960-lanbase-mz.122-35.SE5.bin


interface FastEthernet0/12
description xyz
switchport mode access
switchport access vlan 245
switchport protected
switchport port-security
switchport port-security violation restrict
switchport port-security mac-address xxxx.xxxx.xxxx
ip access-group fa12 in
storm-control broadcast level 1.00
storm-control unicast level 90.00
storm-control action trap
mac access-group fa12a in
no cdp enable
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
ip dhcp snooping limit rate 1
end



sh access-lists
Extended IP access list fa12
   10 permit ip host xx.xx.xx.xx any
   20 permit ip host yy.yy.yy.yy any
Extended MAC access list fa12a
   deny   any any

 

 

sollte grundlegend dafür sorgen das am Port 12 gar nix mehr geht, oder?

Nur das eigenwillige ist, der Computer daran ist weiterhin online.

Wenn ich hingegen den ARP Cache des Computers lösche, dann geht gar nix mehr.

 

D.h. vom Verhalten her bewirkt die ACL nur, dass keine ARP Request mehr gesendet werden können, aber sämtlicher anderer Datenverkehr an bekannte MAC Adressen geht weiterhin.

 

 

Nur da ich keine Option "ethertype 0x0806" gemacht habe, wird es ja an sich nicht auf ARP begrenzt oder wird per default nur ARP überhaupt geprüft?

[Poison Nuke 10]

Wie ich jetzt herausgefunden habe:

 

die 2960 unterstützen MACLs nur für nicht IP Traffic. D.h. alles was kein IP Paket ist, wird davon beeinflusst. Da ARP kein IP Traffic ist, wurden natürlich die ARP Pakete geblockt, aber alles andere ging durch.

 

das muss man auch erstmal wissen...weil grundleged ist es schon ganz schön ungewöhnlich, da MAC ja immerhin unterhalb der IP Ebene arbeitet und es daher völlig egal ist, was der nächste Layer für ein Format hat. Naja, dann ist das halt wohl so und man kann sagen die MACL auf den 2960 und 2950 sind unbrauchbar. Man muss es dann offenbar auf den Ingress ACLs der nächsten Switche machen. Auch wenn das grundlegend auch wieder gegen die Philosophie von Cisco ist, man sollte den Traffic möglichst nah an der Quelle / Ziel filtern, je nach Richtung.

[Wordo 11]

Was erwartest du von einem Layer2 Switch?

[Poison Nuke 10]

das er eben auf Layer2 arbeitet und nicht noch nach Layer3 schaut und erst anhand von Layer3 entscheidet, ob er seine Arbeit auf Layer2 fortsetzt oder nicht. Also genau DAS was man erwartet von einem L2 Switch.

[Wordo 11]

Wie ich jetzt herausgefunden habe:

 

die 2960 unterstützen MACLs nur für nicht IP Traffic. D.h. alles was kein IP Paket ist, wird davon beeinflusst. Da ARP kein IP Traffic ist, wurden natürlich die ARP Pakete geblockt, aber alles andere ging durch.

 

 

Aber das ist doch genau was du willst?

[Poison Nuke 10]

ne, die MAC Access List sollte sich auf ALLE Pakete auswirken. Ich wollte damit damit zusätzlich zur Port Security noch einige weitere Sachen steuern, z.B. sollten die angeschlossenen Computer nicht in der Lage sein, Verbindung zu bestimmten MACs aufzunehmen. Bei einer reinen L2 Funktionalität vom Switch wären damit sämtliche Pakete betroffen gewesen und es hätte den gewünschten Effekt. So hingegen ist die MACL vollkommen unwirksam bis halt auf dass kein ARP mehr geht wenn man ein deny any macht.

 

frag mich zwar überhaupt welchen Sinn Cisco in den MACLs sieht, wenn sie praktisch wirkungslos sind aber ok, ich löse es jetzt ja wie gesagt mit einer VACL auf dem Coreswitch.

[Wordo 11]

Der Sinn sei mal dahingestellt, aber hier stehts doch ganz klar:

 

Catalyst 2960 Switch Software Configuration Guide, Rel. 12.2(46)SE - Configuring Network Security with ACLs [Cisco Catalyst 2960 Series Switches] - Cisco Systems

 

Understanding ACLs:

IP ACLs filter IPv4 traffic, including TCP, User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), and Internet Control Message Protocol (ICMP).

 

Ethernet ACLs filter non-IP traffic.

 

Ich wuerde fuer sowas private VLANs nehmen (geht nicht mit 2960) oder halt IP ACLs.

 

Die VACL bringt dir nix wenn die Pakete von 2960 Port 1 zu Port 2 laufen .. da laeuft nichts durch den Core.

[Poison Nuke 10]

private VLANs sind auf den 2960 aktiv, sie unterstützen ja PVLAN edge, genau das was gebraucht wird. Damit geht jeder Traffic so oder so erstmal über den Core.

 

und IP ACLs können einfach rein vom Prinzip nicht das was gebraucht wird. Geht ja auch gar nicht. MAC und IP basierte Kommunikation ist halt was grundverschiedenes.

 

 

grundlegend soll es am Ende einfach eine verschärfte Version von PVLANs werden. Und mittels der Möglichkeiten der 2960 und den VACL über die 6500er ist das ja nun auch wie gewünscht (hoffentlich) realisierbar. Ich war halt der Hoffnung ich könnte schon die MAC Filterung direkt auf den 2960 machen lassen, rein von der Konzeption her, dass Filterregeln so nah wie möglich am Ursprung ausgeführt werden sollten.

[Otaku19 33]

warum macht man sich eigentlich die ganze Arbeit um eine Source die einfacher nicht zu fälschen ist ? Gehört das zusätzlich zu einem ausgefuchsten 802.1X design für Clients die 802.1X nicht können ?

[Poison Nuke 10]

dank manuell konfigurierter MAC Adressen über Portsecurity wird da nicht viel mit fälschen sein, wenn man sich auf die Portsecurity der 2960er verlassen kann. Bisher hatte die uns aber nicht im Stich gelassen.

 

und wozu umständliches, aufwändiges und mit Problemen verbundenes 802.1x?

Alles wird manuell vorkonfiguriert auf den Switchen (IPs und MACs usw), damit braucht man gar nicht erst eine Authentifzierung. Somit kann ein Rechner auch erst dann online kommen, wenn wir ihn manuell freischalten. Perfekt sag ich da nur. Eine bessere lösung gibt es auch gar nicht.

[Otaku19 33]

du verstehst nicht auf was ich hinaus will, wenn mir eien dieser mac adressen bekannt ist, dann trag ich die bei mir ein und fertig. Schon kann ich alles ws der richtige Besitzer dieser Adresse ebenfalls tun. Mir gehts also schon um den ersten Schritt bei einem sicheren Netz...der Authentifizierung, und die ist wenn man sich auf etwas unzuverlässiges wie die MAC Adresse verlässt eben nicht sicher.

 

Es geht atmo nichts über 802.1X, richtig implementiert tut sich da ein Angreifer schon verdammt schwer....und ihr tut euch grade bei gossen Netzen um vieles einfacher.

[Poison Nuke 10]

du verstehst mich scheinbar nicht richtig:

 

die MAC Adresse ist fest auf dem Port konfiguriert. Es ist UNMÖGLICH, dass irgendwer sich diese MAC adresse klaut weil dazu muss er auch zeitgleich die Kontrolle über den Rechner haben für den diese aktiviert ist.

 

Was bringt es jemanden, die MAC Adresse von einem anderen Rechner zu fälschen, wenn für seinen Port diese gar nicht aktiv ist? Er kann doch nur eine einzige MAC für seinen Rechner verwenden, dass ist diese welche wir von der Administration für seinen Switchport aktiviert haben. Da wir Administratoren auch die einzigen sind, die physikalisch Zugang zu den Rechnern und Switchports haben (die User loggen sich ausschließlich remote auf die Computer ein), kann auch niemand ein Kabel umstecken oder so).

 

 

ich wüsste nicht wie 802.1x auch nur im Ansatz so einfach, zweckmäßig und effektiv arbeiten sollte. Weil für diese Methode bei uns ist Rechnerseitig nichts nötig. Einfach nur die MAC Adresse bei der Installation notieren und dann wird das ganze auf den Switchport konfiguriert. Sobald der User versucht die MAC oder IP zu ändern, geht diese MAC einfach nicht oder der ganze Rechner ist offline und wir haben einen Eintrag in unserem Log.

 

 

Und das Ziel von diesem Thread hier war nicht das, weil das jetzt beschriebene mit der Portsecurity läuft schon seit ner ganzen Weile...hier im Thread geht es darum, die IntraVLAN Kommunikation auf Null zu reduzieren, sprich privateVLANs, was durch die 2960 halt nur durch ein paar Kunststücke möglich ist, sprich protected Ports auf den 2960 und eine VACL auf den 6500.

 

Da die Rechner nur die MAC nutzen können, die wir am Switchport eingetragen haben und der Coreswitch nur die Pakete forwarded, wo die ZielMAC die vom Gateway ist, wie sollte da jetzt irgendeiner auch nur im Ansatz in der Lage sein etwas anderes zu machen als was wir ihm explizit erlaubt haben?

[Servidge 10]

Naja, "Portsecurity" mit der MAC Adresse ist dennoch so eine Sache. Den 0815 User behinderst du da mit, ist schon klar. Aber an ein IPconfig /all zu kommen und wenn der User mal nicht da ist sich an diesen Port zu klemmen, oder auch nur dazwischen ist da halb so schweer. So manch ein Hardwarehersteller macht es noch einfacher da die MAC Adresse gleich mit auf den Inventaraufkleber gedruckt wird. Da ist es dann selbst für die Puzfrau einfach das abzlesen.

 

Ein ordentliches 802.1x Konzept ist da meiner Meinung nach besser und auch skalierbarer. Außerdem ist es sobald es mal eingerichtet ist mit weniger Arbeitsaufwand verbunden. Das hängt aber auch immer mit der Größe des Netzes sowie der Anzahl an Änderungen zusammen.

 

Aber jedem Netzwerkadmin das was er möchte. Ich würde es auch nicht gerne sehen wenn jemand bei mir rummosert ;)

[Poison Nuke 10]

ich habe doch extra geschrieben, die einzigen, die physikalisch überhaupt in der Lage sind an die Kabel zu kommen, sind die Netzwerkadmins ;)

es ist zu 100% ausgeschlossen, dass irgendein anderer an die Hardware (Switche, Kabel, Rechner) rankommt, außer den Admins selbst. Wenn doch, dann hätten wir ein arges Sicherheitsproblem :D

 

Und jetzt erkläre mir mal, wenn da kein User in der Lage ist, überhaupt die Kabel zu Gesicht zu bekommen, wie er jetzt noch etwas anstellen sollte ;)

 

und in unserem Anwendungsfall ist 802.1x schlichtweg nicht realisierbar weil so ziemlich sämtliche auf den Markt bekannten Betriebsysteme zum Einsatz kommen und die Administration meist zu 100% dem User selbst obliegt. Und da dann noch viele User ihr eigenes Betriebssystem installieren, ohne unser zutun, wäre das einfach zuviel Aufwand da dann auch noch eine funktionierende RADIUS authentifizierung ans Laufen zu bekommen. Ich wüsste nichtmal wie das unter Citrix Xen oder einem ESXi oder vsphere oder so gehen sollte. Habs zumindest noch nie gehört dass die das könnten.

[Wordo 11]

Also sowas in der Art wie Hetzner oder S4Y :) Sag das doch gleich ... ;)

Ne, die Diskussion ist wirklich bisschen vom Thema weg, kommt halt immer aufs Szenario an.

 

Protected Ports am Edge und VACLs sind da doch am einfachsten ...