Peter,

The access-map sequence has two match statements; one for layer-2 (mac
access-list) and another for layer-3 (ip access-list) addresses. Can you
explain why you believe that the 'AND' condition never be met in this
example? To me it seems like this SHOULD validate ARP for this statically
defined host in vlan 123:

access-list 123 permit ip host 192.168.123.1 any
mac access-list extended no_spoof
 permit host 001f.ca08.105c any 0x806 0x0
vlan access-map anti-spoof 10
 action forward
 match mac address no_spoof
 match ip address 123
vlan access-map anti-spoof 20
 action drop
vlan filter anti-spoof vlan-list 123

After thinking about this for a while, I'm beginning to think that the best
solution would be using a VACL to drop all ARP traffic in vlan 123 and
statically define our host mac-mapping, the only caveat being you'd need to
be presented with four pieces of info: mac, ip, port, and vlan.

vlan access-map anti-spoof 10
 action drop
 match mac address anto_spoof
ip source binding 001F.CA08.105C vlan 123 192.168.123.1 interface Fa0/15
vlan filter anti-spoof vlan-list 123


Buck

On Fri, Apr 16, 2010 at 1:08 AM, Kingsley Charles <
[email protected]> wrote:

> Hi Peter
>
> Solution 2 is fine but we need to add the mac-addresses.
>
> If we need a solution that is very scalable that doesn't need to us to add
> the mac-addresses, then I think using ip source guard is the best solution.
>
> But still, in non-DHCP environments, we need to add static bindinds :-(
>
>
> With regards
> Kings
>
> On Thu, Apr 15, 2010 at 11:17 PM, Peter Debye <[email protected]> wrote:
>
>> Hello,
>>
>> In the context of VLAN filtering (VACL) the mac access-list matches on
>> non-IP traffic only.
>> (IP ARP is considered as such, btw). Hence, imho, it is senseless to
>> put both mac and ip
>> address matches within the same vlan access-map entry: the AND (and it
>> is AND, Brandon
>> is right) between non-IP and IP will never get true.
>>
>> The drops which Kingsley is seeing in his example are not due to 10
>> entry but are owing
>> to the default no-match behaviour of vlan access-maps.
>>
>> Now, to address the task of blocking ARP spoofing using VACL I can suggest
>> two strategies:
>>        1) block _all_ IP ARP traffic in the vlan with:
>>                  mac access-list extended ARP
>>                     permit any any 0x806 0x0
>>                  vlan access-map BLOCK_ARP
>>                    action drop
>>                    match mac address ARP
>>          (This VACL doesn't affect IP traffic.)
>>          All hosts on the vlan must have ARP mapping configured
>> statically, like
>>                 arp -s A.B.C.D xx--xx-xx-xx-xx-xx
>> Not a very scalable solution but it may fit well the situation when
>> all traffic from hosts
>> must traverse a router.
>>
>>        2) permit ARP packets from a locally defined list of hosts only:
>>                    mac access-list ext ARP_MAC
>>                      permit host <mac1> any 0x806 0x0
>>                      permit host <mac2> any 0x806 0x0
>>                      ...
>>                    vlan access-map NO_SPOOF
>>                    action forward
>>                    match mac address ARP_MAC
>>
>> With that a rogue host will not be able to spoof the ARP mappings as its
>> ARP packets will be blocked on the vlan by the default rule.
>> Again, not a very scalable solution as you need to maintain a list of
>> mac's,
>> but for smaller lans it's okay.
>>
>> ==============================================
>>
>>
>> Date: Thu, 15 Apr 2010 10:22:37 -0500
>> From: bwalla <[email protected]>
>> Subject: Re: [OSL | CCIE_Security] Solutiion for ARP spoofing
>> To: Kingsley Charles <[email protected]>
>> Cc: "[email protected]"
>>        <[email protected]>
>> Message-ID:
>>        <[email protected]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Interesting. In the case that it's an OR match only, this solution
>> wouldn't actually work. The reason that I grouped the mac and IP match
>> statments in the same access-map sequence is because I assumed that it
>> would default to 'AND', OR being if you dropped them in different
>> sequences.
>>
>> Bummer.
>>
>> -Buck
>>
>> On Thu, Apr 15, 2010 at 2:30 AM, Kingsley Charles <
>> [email protected]> wrote:
>>
>> > Hi Brandon
>> >
>> > I just checked and it seems the vlan access-map is making "OR" logic
>> > between the matching criterias. With following config, either it
>> > matches mac acl "king" or IP acl "123".
>> >
>> > vlan access-map king 10
>> >  action drop
>> >  match mac address king
>> >  match ip address 123
>> >
>> > While the route-maps uses "AND" logic between the criteria.
>> >
>> >
>> > With regards
>> > Kings
>> >
>> > On Thu, Apr 15, 2010 at 12:27 PM, Brandon Carroll <
>> [email protected]>wrote:
>> >
>> >>  Kings,
>> >>
>> >> It's a logical and like a route-map.
>> >>
>> >> Regards,
>> >>
>> >> Brandon Carroll - CCIE #23837
>> >> Senior Technical Instructor - IPexpert
>> >> Mailto: <[email protected]>[email protected]
>> >> Telephone: +1.810.326.1444
>> >> Live Assistance, Please visit: <http://www.ipexpert.com/chat>
>> >> www.ipexpert.com/chat
>> >> eFax: +1.810.454.0130
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to