CCNP Switch - Securing with VLANs (VACL, PACL, Private VLANs, VLAN hopping)

 - VTP transparent mode is needed before you can create a private VLAN. 
 - All control protocol frames – CDP, VTP, DTP, STP etc are all sent on the Native (untagged) VLAN.   
 - If the Native VLAN is NOT in the list of allowed VLANs, then these frames may not be transmitted. (I say MAY not, because with different switches and different version of IOS, different protocols are included or excluded).  This can lead to the creation of loops due to the lack of Spanning Tree BPDUs being transmitted, and unexpected behaviour if you rely on dynamic trunking or the Vlan Trunking Protocol to disseminate VLAN information.

- DTP frames have no association with a vlan and hence are never tagged.
IEEE BPDUs have no association with a vlan and hence are never tagged.

-CDP & VTP both belong to vlan1, if native vlan is 1 they will be untagged, if the native vlan is anything other than 1 they will all be tagged with 1 

When a frame is forwarded on a port, it is sent either "Tagged" or "Untagged". I can see you clearly understand this by the wording of your question.

For some vendors, that's the end of the story.  For a given port, you have "Tagged" or "Untagged" VLANs, but for Cisco:

Tagged VLANs can be called:
 - Tagged VLANs
 - Voice VLANs
 - Auxiliary (or helping) VLANs (old terminology) - Voice VLAN is referred to as an auxiliary VLAN in the Catalyst 6000 family switch documentation.

Untagged VLANs can be called:
 - Untagged VLANs
 - Access VLANs
 - Native VLANs
https://learningnetwork.cisco.com/thread/40635

VACL and Private VLANs
Traditionally, traffic has been filtered only at router boundaries, where packets naturally are inspected before being forwarded.
Catalysts also can filter packets even if they stay within the same VLAN; VLAN access control lists, or VACLs, provide this capability.
Catalyst switches also have the capability to logically divide a single VLAN into multiple partitions.
Private VLANs make it possible to offer up a single VLAN to many disparate customers or organizations without any interaction between them.

VLAN Access Lists
R-ACL  (normal ACL)
 - Access lists (also known as router access lists,or RACLs) are merged or compiled into the TCAM.
 - Each RACL is applied to an interface according to the direction of traffic—inbound or outbound.
 - RACL can be applied to any routed interface (SVI or Layer 3 routed port).
 - Packets then can be filtered in hardware with no switching performance penalty.
 - Only packets that pass between VLANs can be filtered this way.
 - Access lists can manage or control traffic as it passes through a switch.

PACL - Port ACL
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/port_acls.html
 - PACL - filters traffic at the port (interface) level.
 - PACLs can be applied on a Layer 2 switch port, trunk port, or EtherChannel port.
 - PACLs act at the Layer 2 port level but can filter based on Layer 3/Layer 4 information.
 - PACL applied to trunk port will filter traffic on ALL VLANs present on the trunk port.
 - Port ACLs are applied only on the ingress traffic.
 - The PACL feature does not affect Layer 2 control packets received on the port (CDP, VTP, DTP, PAgP, UDLD, and STP, because the protocols are redirected to the RP before the ACL takes effect)
 - PACLs use the following modes:
  •Merge mode—In this mode, the PACL, VACL, and Cisco IOS ACLs are merged in the ingress direction. This is the default access group mode.
  •Prefer port mode—If a PACL is configured on a Layer 2 interface, the PACL takes effect and overwrites the effect of other ACLs (Cisco IOS ACL and VACL).
     If no PACL feature is configured on the Layer 2 interface, other features applicable to the interface are merged and are applied on the interface.

VACL - VLAN ACL (done by access-maps)
 - Packets that stay in the same VLAN do not cross a VLAN or interface boundary and do not necessarily have a direction in relation to an interface.
 - VACLs support filtering based on Ethertype and MAC addresses.
 - These packets also might be non-IP, non-IPX, or completely bridged; therefore, they never pass through the multilayer switching mechanism.
 - VLAN access lists (VACL) are filters that directly can affect how packets are handled within a VLAN.
 - VACL are merged into the TCAM, they can permit, deny, or redirect packets as they are matched.
 - VACLs also are configured in a route map fashion, with a series of matching conditions and actions to take.
 - ACLs are supported in hardware through IP standard ACLs and IP extended ACLs, with permit and deny actions.
 - VACLs follow route-map conventions, in which map sequences are checked in order.
   When  a  matching  permit  ACE is  encountered,  the  switch  takes  the  action.
   When  a  matching  deny     ACE is  encountered,  the  switch  checks  the  next  ACL  in  the   sequence  or  checks the next sequence.

 - VACLs have an implicit deny at the end of the map; a packet is denied if it does not match any ACL entry, and at least one ACL is configured for the packet type.

!   Implicit deny - will drop all frames/packets not permited by action forward
SW2(config-ext-nacl)#vlan access-map VACL_PERMIT-TELNET-ONLY
SW2(config-access-map)#action forward
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-ext-nacl)#vlan access-map VACL_PERMIT-TELNET-ONLY
SW2(config-access-map)#action drop
SW2(config-access-map)#exit 

same as
SW2(config-ext-nacl)#vlan access-map VACL_PERMIT-TELNET
SW2(config-access-map)#action forward
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#exit 

 - VACL without match clause, will have implicit forward action at the end of the list.

SW2(config-ext-nacl)#vlan access-map VACL_DENY-TELNET-PERMIT-ANY
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_DENY-TELNET-PERMIT-ANY
SW2(config-access-map)#exit 

same as
SW2(config-ext-nacl)#vlan access-map VACL_DENY-TELNET-PERMIT-ANY
SW2(config-access-map)#action drop
SW2(config-access-map)#match ip address ACL_TELNETR1_R2
SW2(config-access-map)#vlan access-map VACL_DENY-TELNET-PERMIT-ANY
SW2(config-access-map)#action forward
SW2(config-access-map)#exit

- If an empty or undefined ACL is specified in a VACL, any packets will match the ACL, and the associated action is taken.

VACL Configuration
VACLs are configured as a VLAN access map in much the same format as a route map.
Each statement can contain one or more matching conditions, followed by an action.

Switch(config)# vlan access-map <map-name> [<sequence-number>]

Configure a matching condition with one of the following access map

Switch(config-access-map)# match ip address {acl-number | acl-name}
Switch(config-access-map)# match ipx address {acl-number | acl-name}
Switch(config-access-map)# match mac address <acl-name>

Define the action

Switch(config-access-map)# action {drop | forward [capture] | redirect <type  mod/num>}
! A VACL can either drop a matching packet, forward it, or redirect it to another interface

You must apply the VACL to a VLAN using the following global configuration

Switch(config)# vlan filter <map-name> vlan-list <vlan-list>

 - VACL is applied globally to one or more VLANs listed and not to a VLAN interface (SVI).
 - VACL needs to function within the VLAN itself, where there is no inbound or outbound direction

Example:
Suppose that you need to filter traffic within VLAN 99 so that host 192.168.99.17 is not allowed to contact any other host on its local subnet.

Switch(config)# ip access-list extended local-17
Switch(config-acl)# permit ip host 192.168.99.17 192.168.99.0 0.0.0.255
Switch(config-acl)# exit
Switch(config)# vlan access-map block-17 10
Switch(config-access-map)# match ip address local-17
Switch(config-access-map)# action drop
Switch(config-access-map)# vlan access-map block-17 20
Switch(config-access-map)# action forward
Switch(config-access-map)# exit
Switch(config)# vlan filter block-17 vlan-list 99

Private VLANs
 - Normally, traffic is allowed to move unrestricted within a VLAN.
 - Packets sent from one host to another normally are heard only by the destination host because of the nature of Layer 2 switching.
 - If one host broadcasts a packet, all hosts on the VLAN must listen. You can use a VACL to filter packets between a source and destination in a VLAN if both connect to the local switch.
 - You must configure VTP to transparent mode before you can create a private VLAN. 
 - Private VLANs are configured in the context of a single switch and cannot have members on other switches. Private VLANs also carry TLVs that are not known to all types of Cisco switches.

Applications:
 - In a singleVLAN server farm, all servers should be capable of communicating with the router or gateway, but the servers should not have to listen to each other’s broadcast traffic.
 - Service provider network. The provider might want to use a single VLAN to connect to several customer networks. Each customer needs to be able to
contact the provider’s gateway on the VLAN. Clearly, the customer sites do not need to interact with each other.

Private VLANs (PVLAN) solve this problem on Catalyst switches.
 - Private VLANs are configured using special cases of regular VLANs.
 - VTP does not pass any information about the private VLAN configuration.
 - Private VLANs are only locally significant to a switch.
 - Each of the private VLANs must be configured locally on each switch that interconnects them.
 - A normal or primary VLAN can be logically associated with special unidirectional, or secondary, VLANs.
 - Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for example), but not with another secondary VLAN.
 - All secondary VLANs must be associated with one primary VLAN to set up the uni-directional relationship.

Private VLAN, also known as port isolation, is a technique in computer networking where a VLAN contains switch ports that are restricted such that they can only communicate with a given "uplink".
 - Each private VLAN typically contains many private ports, and a single uplink. The uplink will typically be a port connected to a router, firewall, server, provider network, or similar central resource.
 - PVLANS subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device – such as router.
http://en.wikipedia.org/wiki/Private_VLAN

A secondary VLAN is configured as one of the following types:
■ Isolated—Any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN.
    In addition, hosts associated with the same isolated VLAN cannot reach each other. They are, in effect, isolated from everything except the primary VLAN.
■ Community—Any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN. This provides the basis for server farms and workgroups within an organization, while giving isolation between organizations.

You must configure each physical switch port that uses a private VLAN with a VLAN association.
Define the port with one of the following modes:
■ Promiscuous—The switch port connects to a router, firewall, or other common gateway device.
   This port can communicate with anything else connected to the primary or any secondary VLAN.    In other words, the port is in promiscuous mode, in which the rules of private VLANs are ignored.
■ Host—The switch port connects to a regular host that resides on an isolated or community VLAN. The port communicates only with a promiscuous port or ports on the same community VLAN.

Private VLAN Functionality Within a Switch

Primary VLAN: Simply the original VLAN. This type of VLAN is used to forward frames downstream to all Secondary VLANs.
Secondary VLAN: Isolated or Community

Promiscuous port (P-Port)
Host Ports:  Isolated Port (I-Port)- communicates only with P-Ports OR  Community Port (C-Port) -communicates with P-Ports and ports on the same community VLAN.

Private VLAN Configuration
0) Set VTP mode to transparent (disable VTP).

vtp mode transparent

1) Define any secondary VLANs that are needed for isolation

Switch(config)# vlan <vlan-id>
Switch(config-vlan)# private-vlan {isolated | community}    <---secondary VLAN

2) Define the primary VLAN that will provide the underlying private VLAN connectivity.
Be sure to associate the primary VLAN with all its component secondary VLANs using the association keyword.
If the primary VLAN already has been configured, you can add or remove secondary VLAN associations individually.

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association {<secondary-vlan-list> | add <secondary-vlan-list> | remove <secondary-vlan-list>}

Associate Ports with Private VLANs
Define the function of the port that will participate on a private VLAN

Switch(config-if)# switchport mode private-vlan {host | promiscuous}
promiscuous - if the host connected to this port is a router, firewall, or common gateway for the VLAN
           This allows the host to reach all other promiscuous, isolated, or community ports associated with the primary VLAN
host - any isolated or community port.

4) For a nonpromiscuous port (private-vlan host) you must associate the switch port with the appropriate primary and secondary VLANs

Switch(config-if)# switchport private-vlan host-association <primary-vlan-id> <secondary-vlan-id>

For a promiscuous port (private-vlan promiscuous), you must map the port to primary and secondary VLANs.

Switch(config-if)# switchport private-vlan mapping <primary-vlan-id> <secondary-vlan-list> | {add <secondary-vlan-list>} | {remove <secondary-vlan-list>}

Example configuration ports with Private VLANs:

Private VLAN example configuration

Switch(config)# vlan 10
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 20
Switch(config-vlan)# private-vlan community
Switch(config)# vlan 30
Switch(config-vlan)# private-vlan isolated
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 10,20,30

Switch(config)# interface range fastethernet 1/1 - 1/2
Switchconfig# switchport private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 10
Switch(config)# interface range fastethernet 1/4 - 1/5
Switchconfig# switchport private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 20
Switch(config)# interface fastethernet 1/3
Switchconfig# switchport private-vlan host
Switch(config-if)# switchport private-vlan host-association 100 30
Switch(config)# interface fastethernet 2/1
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 10,20,30

Associate Secondary VLANs to a Primary VLAN SVI
On switched virtual interfaces, or VLAN interfaces configured with Layer 3 addresses, you must configure some additional private VLAN mapping.

Switch(config-if)# private-vlan mapping {<secondary-vlan-list> | add <secondary-vlan-list> | remove <secondary-vlan-list>}

Example:
 - SVI for the primary VLAN (VLAN 200) has an IP address and participates in routing traffic.
 - Secondary VLANs 40 (an isolated VLAN) and 50 (a community VLAN) are associated at Layer 2 with primary VLAN 200

Switch(config)# vlan 40
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 50
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 200
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 40,50
Switch(config-vlan)# exit
Switch(config)# interface vlan 200
Switch(config-if)# ip address 192.168.199.1 255.255.255.0

 - Primary VLAN 200 can forward traffic at Layer 3, but the secondary VLAN associations with it are good at only Layer 2.
 - To allow Layer 3 traffic switching coming from the secondary VLANs as well, you must add a private VLAN mapping to the primary VLAN (SVI) interface
 - The primary VLAN SVI function is extended to the secondary VLANs instead of requiring SVIs for each of them.

Switch(config)# interface vlan 200
Switch(config-if)# private-vlan mapping 40,50

Securing VLAN Trunks
 - Some attacks or exploits can be leveraged to gain access to a trunk or to the VLANs carried over a trunk.
 - Therefore, you should become familiar with how the attacks work and what steps you can take to prevent them in the first place.

Switch Spoofing
The switches dynamically can negotiate its use and its encapsulation mode by exchanging Dynamic Trunking Protocol (DTP) messages.
 - A well-behaved end user would not use DTP at all, so the port would come up in access mode with a single-access VLAN.
 - A malicious user, however, might exploit the use of DTP and attempt to negotiate a trunk with the switch port. This makes the PC appear to be another switch; in effect, the PC is spoofing a switch.

Switch# show interfaces fastethernet 1/0/46 switchport
Name: Fa1/0/46
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: trunk
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)

The solution to this situation is to configure every switch port to have an expected and controlled behavior.

Switch(config)# interface <type mod/num>
Switch(config-if)# switchport access vlan <vlan-id>
Switch(config-if)# switchport mode access

This way, an end user never will be able to send any type of spoofed traffic that will make the switch port begin trunking.

VLAN Hopping
An attacker positioned on one access VLAN can craft and send frames with spoofed 802.1Q tags so that the packet payloads ultimately appear on a totally different VLAN, all without the use of a router.
 - the key to this type of attack revolves around the use of untagged native VLANs.

The following conditions must exist in the network configuration:
■ The attacker is connected to an access switch port.
■ The same switch must have an 802.1Q trunk.
■ The trunk must have the attacker’s access VLAN as its native VLAN.

When the local switch Catalyst A receives a doubly tagged frame, it decides to forward it out the trunk interface.
Because the first (outermost) tag has the same VLAN ID as the trunk’s native VLAN, that tag is removed as the frame is sent on the trunk.
The switch believes that the native VLAN should be untagged, as it should. Now the second (innermost) tag is exposed on the trunk.

Prevent VLAN hopping
 - Set the native VLAN of a trunk to a bogus or unused VLAN ID.
 - Place unused ports in bogus VLAN
 - Prune the native VLAN off both ends of the trunk.
 - Disable DTP

Switch(config)# vlan 800
Switch(config-vlan)# name bogus_native
Switch(config-vlan)# exit
Switch(config)# interface gigabitethernet 1/1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport trunk native vlan 800
Switch(config-if)# switchport trunk allowed vlan remove 800
Switch(config-if)# switchport mode trunk

Although maintenance protocols such as CDP, PAgP, and DTP normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs.

One alternative is to force all 802.1Q trunks to add tags to frames for the native VLAN, too.
To force a switch to tag the native VLAN on all its 802.1Q trunks, you can use the following command:

Switch(config)# vlan dot1q tag native