Newsgroup: it.comp.reti.cisco
Titolo: Problema filtering su cisco 4500

Ho un Cisco WS-C4507R-E con IOS 12.2(53)SG1 e doppia supervisor SUP-6E
Ho la necessitï¿œ di impostare delle ACL su una determinata VLAN. In
particolare ho una situazione in cui una VLAN ï¿œ esposta in un luogo che non
ï¿œ sotto il mio controllo, su uno switch untrust, e devo fare in modo che non
si possano attaccare macchine diverse da quelle giï¿œ presenti o che se ciï¿œ
avvenisse comunque le nuove macchine sullo switch untrust non possano
comunicare con le macchine connesse allo switch trusted. E' indifferente
operare un controllo su IP o su MAC.
Fondamentalmente lo schema ï¿œ quello di figura seguente:
+---------------+
|  4507R-E      |
| Switch trust  |
|               |  trunk 10+11    +----------------+
| g6/1+g7/1=Po1 +-----------------+ Switch untrust |
|               |                 | v10  v10  v11  |
|               |                 +--+----+----+---+
| g6/2   vlan10 +---- SRV            |    |    |
| g7/2   vlan11 +---- SRV           SRV  SRV  SRV
|               |
Un estratto della configurazione del 4507R-E relativamente alle porte
interessate ï¿œ il seguente:
vlan 10
 name VlanTrusted
!
vlan 11
 name VlanUntrusted
!
interface Vlan10
 description VlanTrusted
 ip address 10.10.10.254 255.255.255.0
!
interface Vlan11
 description VlanUntrusted
 ip address 10.10.11.254 255.255.255.0
!
interface Port-channel1
 description Link verso cliente
 switchport
 switchport trunk allowed vlan 10-11
 switchport mode trunk
!
interface GigabitEthernet6/1
 description Link cliente P1
 switchport mode trunk
 switchport trunk allowed vlan 10-11
 channel-group 1 mode active
!
interface GigabitEthernet7/1
 description Link cliente P2
 switchport mode trunk
 switchport trunk allowed vlan 10-11
 channel-group 1 mode active
!
interface GigabitEthernet6/2
 description SRV su v10
 switchport access vlan 10
 switchport mode access
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface GigabitEthernet7/2
 description SRV su v11
 switchport access vlan 11
 switchport mode access
 spanning-tree portfast
 spanning-tree bpduguard enable
!
La vlan da "proteggere" ï¿œ la 10. La vlan 11 invece non deve essere
considerata in alcun modo dalle ACL che devo impostare sulla 10.
Ora. Se la macchina fosse un 6500 potrei creare una ACL che filtri in base
all'IP ed al vlan id ed applicarla alle porte del trunk e il problema
sarebbe risolto. Sul 4500 questo non ï¿œ supportato questo tipo di acl.
Anche se la vlan 10 mi arrivasse non taggata su una singola porta al posto
che in un trunk il problema sarebbe semplicemente risolvibile con una acl
applicata sulle porte della consegna.
In questo caso invece mi trovo con un problema perchï¿œ una ACL applicata
sulla porta del trunk filtra anche tutte le altre vlan taggate trasportate
(in questo caso la 11), ma io non ho controllo su tutti i dati che
transitano sul trunk e quindi non posso adottare questo tipo di filtering.
Una soluzione a cui avevo pensato era quelle di attestare il trunk su una
coppia di switch diversi e portare la vlan 10 al core separatamente dalle
altre in modo da applicare le ACL sulla porta, ma attualmente non ho e non
potrï¿œ avere a breve una coppia di switch extra da poter dedicare allo scopo.
Guardando la doc ho pensato che una possibile soluzione sia applicare un
filtro alla vlan.
L'obbiettivo sarebbe quello di dire allo switch di fare forward dei soli
pacchetti che hanno un determinato mac address, bloccando di fatto la
consegna di pacchetti di macchine sconosciute. Il 4500 supporta le
vlan-access-map che mi pare facciano proprio questo.
Ho quindi preparato una mac access list con tutti i mac address delle
macchine autorizzate a trasmettere sulla vlan ed ho creato una access-map
applicata alla vlan 10. Di seguito l'estratto della configurazione.
mac access-list extended vlan10-mac-filter
 permit host 0000.1111.2200 any
 permit host 0000.1111.2201 any
 permit host 0000.1111.2202 any
 permit host 0000.1111.2203 any
 deny any any
vlan access-map vlan10-map 100
 action drop
 match mac address vlan10-mac-filter
!
vlan filter vlan10-map vlan-list 10
Purtroppo non funziona come mi attendevo. Dove sbaglio? Ho misinterpretato
la funzione delle access-map e vlan filter? Ho dimenticato qualcosa?
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 la funzione delle access-map e vlan filter? Ho dimenticato qualcosa?
O non ho capito io quel che vuoi fare te, o la configurazione ï¿œ errata.
Tu stai dicendo che tutti i mac presenti in vlan10-mac-filter devono
essere bloccati dalla acl vlan10-map che ha come azione di default un 
bel drop. Non dovevi fare l'opposto, ovvero bloccare tutto tranne quei
precisi mac?
Prova con:
mac access-list extended vlan10-mac-filter
   permit host 0000.1111.2200 any
   permit host 0000.1111.2201 any
   permit host 0000.1111.2202 any
   permit host 0000.1111.2203 any
vlan access-map vlan10-map 100
   action forward
   match mac address vlan10-mac-filter
vlan access-map vlan10-map 110
   action drop
vlan filter vlan10-map vlan-list 10
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 vlan filter vlan10-map vlan-list 10
Questo ï¿œ quel che avevo provato in prima istanza, sia con la mac access-list
che con una ip access-list. In questo caso blocca tutto, anche i mac che
dovrebbero passare; provo a pingare tra loro due macchine sulla rete,
entrambe listate nell'access list ma nulla da fare. Peraltro non trovo
nemmeno cosa abilitare nel debug per vedere quel che accade a questo livello.
Altre idee?


 nemmeno cosa abilitare nel debug per vedere quel che accade a questo livello.
Occhio, perchï¿œ nella mia config non c'ï¿œ il deny nella access list.
Riesci a postare la configurazione esatta che hai attualmente in
esecuzione ora?


 esecuzione ora?
Come detto ï¿œ esattamente quella che hai postato tu. C'ï¿œ anche tra i mac
autorizzati anche quello dello switch dato che la rete deve essere
raggiungibile dall'esterno.
Ovviamente scambiando drop con forward tutto va.
mac access-list extended vlan10-mac-filter
 permit host 0000.0000.cf91 any
 permit host 0000.0000.cf92 any
...
 permit host 0000.0000.001c any
 permit host 0000.0000.142a any
 permit host 0000.1111.187a any
!
vlan access-map vlan10-map 100
 action forward
 match mac address vlan10-mac-filter
vlan access-map vlan10-map 110
 action drop
!
vlan filter vlan10-map vlan-list 10


 vlan filter vlan10-map vlan-list 10
E' questa la config che non funziona?


 E' questa la config che non funziona?
Sï¿œ. Copiato paro paro (tranne i mac)


 vlan filter vlan10-map vlan-list 10
il traffico IP sulla vlan 10 viene matchato dallo statement 110,
action drop.
Per risolvere il problema da te posto, ovvero come limitare il
traffico di eventuali host non autorizzati proveniente da uno switch
non strettamente sotto controllo potresti intraprendere varie strade:
-port security sullo switch untrust, max  1 mac address, mac address
fissati sulle porte, errdisable recovery.
-autenticazione 802.1x sullo switch untrust, necessita di server
radius/tacacs+.
-arp acl e arp inspection con filter statico sul 4507  (personalmente
non lo consiglio... ) o sullo switch untrust.
Quest'ultima non e' una vera soluzione ma piuttosto un escamotage.
L'autenticazione 802.1x ti mette al riparo dai mac address impostati
"a mano", gli altri metodi no.
HTH
Marco
--
http://rizzitech.blogspot.com/

 "a mano", gli altri metodi no.
802.1x sarebbe comunque inutilizzabile in questo caso perch� su quella rete
ci sono device per lo storage (controller, switch FC, ecc.ecc.) non PC o server.
Se non trovo una soluzione adeguata con il 4507 o ripiego su una coppia di
switch extra da dedicare a questo scopo o � la volta buona che finalmente ci
metto un 6500 (ormai che nel datacenter i 10Gbe sono comuni il 4507 pu�
diventare un collo di bottiglia non indifferente, e tra acquistare delle
nuove schede 10Gbe per il 4500 e un paio di switch per questo scopo o
comprare un intero 6500 non � poi cos� differente).


 traffico NON IP.
Touchè, e pensare che ho letto il documento, mi è proprio 
sfuggito il *non*

 sfuggito il *non*
ibidem.


 ibidem.
OK, sono un idiota. Sono riuscito a far funzionare la cosa a livello di
indirizzi IP autorizzati usando le ip access list.
La configurazione è la seguente.
ip access-list extended vlan10-ip-acl
 permit ip host 10.10.10.50 any
 permit ip host 10.10.10.51 any
[...]
 permit ip host 10.10.10.74 any
 permit ip host 10.10.10.75 any
 deny   ip 10.10.10.0 0.0.0.255 any
 permit ip any any
vlan access-map vlan10-map 100
 action forward
 match ip address vlan10-ip-acl
vlan access-map vlan10-map 110
 action drop
!
I motivi per cui non mi funzionava la configurazione quando l'ho provato
erano due:
1) perché sono un cretino e mi ero scordato che le ACL sugli switch usano le
wildcard, non le netmask!!!
2) perché su questo switch quando si edita una ip ACL, le modifiche non
hanno effetto finché non si esce dalla configurazione dell'access list.
Questo è un comportamento differente da altri apparati/versioni di IOS e me
ne sono accorto per caso. Per evitare di dare disservizi prolungati facevo
le prove senza mai dare l'exit, e poi riscontrando che non andava rimettevo
a posto prima di uscire dalla conf, senza quindi mai rendere effettive le
modifiche.
Spero se non altro che sia utile a qualcun altro :-)


 modifiche.
Questa mi è nuova.
Il comportamento cambia in base agli apparati anche a parità di IOS?
Io ho dei 3750 e dei 2960 che, se non erro, applicano le modifiche solo
dopo essere usciti dalla configurazione. (non ne son sicurissimo ma mi
pare così)


no... le cfg sono immediate
ciao

 !
Flavio, perdona l'ardire,
 ma visto che la vlan 10 viene ruotata a L3 su quel 4507, non avrebbe
piu' senso applicare l'acl sull'interface vlan 10 invece di fare una
vlan map?
Marco
--
http://rizzitech.blogspot.com/

 vlan map?
No, nel senso che c'� *anche* una acl sul L3 per la protezione da altre
reti, ma io devo proteggere la VLAN anche a livello 2. Il "braccio" di vlan
che va sullo switch untrusted non � ruotato, ed � proprio da l� che voglio
difendermi; se fosse stato ruotato come giustamente dici tu una classica acl
risolveva tutto, cos� come se fosse stata una rete che entrava su una porta
in access avrei potuto applicare una ACL alla porta.
Ma cos� sul 4500 l'unica soluzione che ho trovato � la vlan map con la
complessit� del caso.
(fai rif. al primo post per uno schema dettagliato).


 traffico NON IP.
Ciao,
mi intrometto perch� anch'io sto avendo un problema simile a quello di Flavio.
Ho seguito la discussione e letto la documentazione che hai linkato a riguardo 
ma ho trovato per� che tutti quanti in rete continuano ad usare le access-map 
applicate alle vlan per filtrare i mac address.
La prima domanda che mi sorge �: ma le vlan alle quali non assegni nessun 
indirizzo IP non lavorano semplicemente layer2 ? Si, sono layer3 capable ma 
senza IP non lavorano layer3.
Perch� in questo caso una delle note da te linkate viene a cadere (ossia: "Named 
MAC extended ACLs cannot be applied to Layer 3 interfaces")
Poi � la stessa doc che dice di usare la access-map per filtrare il traffico a 
livello di vlan e mi sembra una contraddizione in termini dire di usare le 
access-map per filtrare i mac a livello di vlan.... non capisco.
Inoltre c'� la parte relativa al comando mac address-table static in cui ti dice 
espressamente che viene usato per filtrare il traffico unicast da un dato mac 
address: 
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/53SG/configuration/secure.html#wp1066708
per� anche questo non funziona (ho un Supervisor 6E su un 4510).
Possibile che non sia possibile filtrare un semplice mac address su un apparato 
da Nmila euro ?!?! Cosa che per altro tutti in rete sbandierano come fattibile 
sempre con il sistema delle access-map:
http://www.4ward.it/Blogs/Systems-and-Web/Marzo-2009.aspx
http://cauew.blogspot.com/2008/08/vacl-vlan-maps-mac-acl.html
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la verit� � 
che non avere nulla da perdere significa essere pronti a rischiare tutto ci� che 
si possiede.

 Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)
ciao Flavio,
non ho modo di provare su un 4500 con sup e ios recente,
ma su un semplice 3750 puoi applicare ip access-list anche su porte in
trunk, ad es:
Switch#sh run int f 1/0/23 | b int
interface FastEthernet1/0/23
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 234,432
 switchport mode trunk
 ip access-group TEST in
end
Switch#sh ip access-list
Extended IP access list TEST
    10 permit ip host 10.0.0.3 host 10.0.0.2
    20 permit ip host 192.168.0.4 host 192.168.0.3
la classe 
10.0.0.0/24
 viene trasportata sulla vlan 234, la classe
192.168.0.0/24
 invece e' sulla vlan 432
In questo caso lo switch lavora solo a L2, non ha interfaces vlan, ma
e' L3 capable, come giustamente dice Rizio, quindi e' in grado di
esaminare anche i layer superiori.
...questa cosa non mi era venuta in mente in prima battuta, credo
funzioni allo stesso modo anche su 4500, se puoi provalo e facci
sapere
Marco Rizzi
-=-=-=-
http://rizzitech.blogspot.com


Questo secondo esempio credo sia corretto.
Spero di aver risposto alle tue domande, nei limiti delle mie
conoscenze e prove che posso effettuare.


 sapere
Dubito di riuscire a fare prove a breve perch� nelle prossime 2 settimane
non ho un buco libero nemmeno nel WE. Forse per� dopo la met� di novembre
riesco a trovare un po' di tempo per divertirmi ed approfondire l'argomento.


 sapere
Purtroppo ero partito per fare la stessa cosa sul 4510 ma lì non funziona. Non 
ottengo nessun risultato.
Ciao


 Marco Rizzi
Assolutamente si, grazie mille per la chiacchierata
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere... ma la veritŕ č 
che non avere nulla da perdere significa essere pronti a rischiare tutto ciň che 
si possiede.