4
Cisco ACL ans Interface binden
Guten Morgen zusammen,
ich möchte gerne eine ACL Regel mit einem IP Adressbereich und UDP Protokoll an ein Interface binden dessen Pakete nicht weitergegeben werden.
Der Rest der Pakete soll dann aber weitergeben werden.
Switch: Cisco Catalyst 2960x, IOS: 152-4.E8
Von: beliebig
An: IPv4: 239.255.0.0/16
Dienst: UDP Alle
Aktion: verweigern
Port: 1
Dann die Permit Rule für TCP
von: beliebig
an: beliebig
Dienst: TCP
Aktion: erlauben
Port: 1
Dann die Permit Rule für UDP
von: beliebig
an: beliebig
Dienst: UDP
Aktion: erlauben
Port: 1
Habe schon etwas gegoogelt und mit der Cisco Hilfe folgende Config erstellt. Klick
Passt das so?
Gruß
Max
ich möchte gerne eine ACL Regel mit einem IP Adressbereich und UDP Protokoll an ein Interface binden dessen Pakete nicht weitergegeben werden.
Der Rest der Pakete soll dann aber weitergeben werden.
Switch: Cisco Catalyst 2960x, IOS: 152-4.E8
Von: beliebig
An: IPv4: 239.255.0.0/16
Dienst: UDP Alle
Aktion: verweigern
Port: 1
Dann die Permit Rule für TCP
von: beliebig
an: beliebig
Dienst: TCP
Aktion: erlauben
Port: 1
Dann die Permit Rule für UDP
von: beliebig
an: beliebig
Dienst: UDP
Aktion: erlauben
Port: 1
Habe schon etwas gegoogelt und mit der Cisco Hilfe folgende Config erstellt. Klick
config
config#access-list INBOUND extended deny ip 239.255.0.0 255.255.0.0 any
config#access-list INBOUND deny udp
config#access-list INBOUND permit tcp
config#access-list INBOUND extended permit ip any any
config# interface gi1/0/1
config-if# access-group input INBOUNDPasst das so?
Gruß
Max
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 514160
Url: https://administrator.de/contentid/514160
Printed on: April 25, 2024 at 21:04 o'clock
4 Comments
Latest comment
Hallo,
nein, passt so eher nicht....
ist ein deny für alle IP Pakete.
Ergo werden hiermit alle Pakete aus dem Netz 239.255.0.0 verworfen.
Danach UDP zu verbieten ist nutzlos...
Bis dahin kommt die ACL gar nicht
Und dann TCP erlauben bringt auch nichts
Was soll das permit ip any any?
brammer
nein, passt so eher nicht....
> config#access-list INBOUND extended deny ip 239.255.0.0 255.255.0.0 anyist ein deny für alle IP Pakete.
Ergo werden hiermit alle Pakete aus dem Netz 239.255.0.0 verworfen.
Danach UDP zu verbieten ist nutzlos...
Bis dahin kommt die ACL gar nicht
Und dann TCP erlauben bringt auch nichts
Was soll das permit ip any any?
brammer
1
Die ACL ist in der Tat syntaktisch falsch zu den Anforderungen. Auch das Kommando einer Named ACL ist falsch.
access-list INBOUND extended deny ip 239.255.0.0 255.255.0.0 any
Würde alles was VON der Absender IP nach irgendwohin geht blocken. Stimmt also nicht zu dem was oben gefordert ist.
access-list INBOUND deny udp
Verbietet (deny) generell UDP Traffic obwohl oben explixit "erlauben" (permit) gefordert ist. Das man Grundlegendes wie Ja und Nein sprich Permit und Deny verwechselt ist sollte eigentlich nicht passieren...!
access-list INBOUND extended permit ip any any erlaubt wieder alles. Damit ist dann auch TCP inkludiert und macht dann die TCP Regel überflüssig.
Also mal der Reihe nach....:
Alles von irgendwoher (any) soll an die Zieladresse 239.255.0.0/16 verboten werden:
ip access-list INBOUND deny ip any 239.255.0.0 0.0.255.255
Danach soll generell alles was UDP und TCP ist erlaubt (permit) werden.
ip access-list INBOUND permit udp
ip access-list INBOUND permit tcp
So das dann die finale Regel logisch und einfach so lautet:
ip access-list INBOUND deny ip any 239.255.0.0 0.0.255.255
ip access-list INBOUND permit udp any any
ip access-list INBOUND permit tcp any any
Diese wird dann ans Interface gebunden:
interface gig1/0/1
ip access-group INBOUND inbound
Nebenbei:
Hier sieht man auch gleich den gravierenden Nachteil die ACL "INBOUND" zu nennen. Der Parameter "inbound" ist Teil des IOS Kommandos und dadurch keine besonders intelligente Wahl des ACL Namens.
Man sollte generell vermeiden Variablen so zu benennen das sie heissen wie Kommandos oder Kommando Bestandteile. Das ist immer gefährlich und schadet nebenbei der Übersichtlichkeit.
Da diese List ja offensichtlich eingehenden Multicast Traffic mit den Multicast Gruppen 239.255.x.y blocken soll wäre es intelligenter die "MCBlocking" o.ä. zu nennen.
access-list INBOUND extended deny ip 239.255.0.0 255.255.0.0 any
Würde alles was VON der Absender IP nach irgendwohin geht blocken. Stimmt also nicht zu dem was oben gefordert ist.
access-list INBOUND deny udp
Verbietet (deny) generell UDP Traffic obwohl oben explixit "erlauben" (permit) gefordert ist. Das man Grundlegendes wie Ja und Nein sprich Permit und Deny verwechselt ist sollte eigentlich nicht passieren...!
access-list INBOUND extended permit ip any any erlaubt wieder alles. Damit ist dann auch TCP inkludiert und macht dann die TCP Regel überflüssig.
Also mal der Reihe nach....:
Alles von irgendwoher (any) soll an die Zieladresse 239.255.0.0/16 verboten werden:
ip access-list INBOUND deny ip any 239.255.0.0 0.0.255.255
Danach soll generell alles was UDP und TCP ist erlaubt (permit) werden.
ip access-list INBOUND permit udp
ip access-list INBOUND permit tcp
So das dann die finale Regel logisch und einfach so lautet:
ip access-list INBOUND deny ip any 239.255.0.0 0.0.255.255
ip access-list INBOUND permit udp any any
ip access-list INBOUND permit tcp any any
Diese wird dann ans Interface gebunden:
interface gig1/0/1
ip access-group INBOUND inbound
Nebenbei:
Hier sieht man auch gleich den gravierenden Nachteil die ACL "INBOUND" zu nennen. Der Parameter "inbound" ist Teil des IOS Kommandos und dadurch keine besonders intelligente Wahl des ACL Namens.
Man sollte generell vermeiden Variablen so zu benennen das sie heissen wie Kommandos oder Kommando Bestandteile. Das ist immer gefährlich und schadet nebenbei der Übersichtlichkeit.
Da diese List ja offensichtlich eingehenden Multicast Traffic mit den Multicast Gruppen 239.255.x.y blocken soll wäre es intelligenter die "MCBlocking" o.ä. zu nennen.
1
Hallo ihr beiden,
vielen dank für eure Hilfe.
Und danke aqui für die Erklärung. Jetzt habe ich es auch Verstanden.
Kannst du mir auch hier helfen? Cisco aus einem anderern Netzwerk erreichbar machen
Gruß
Max
vielen dank für eure Hilfe.
Und danke aqui für die Erklärung. Jetzt habe ich es auch Verstanden.
Kannst du mir auch hier helfen? Cisco aus einem anderern Netzwerk erreichbar machen
Gruß
Max
Jetzt habe ich es auch Verstanden.
👍