Working with Ether Type

In transparent mode, you can have EtherType classification grouped in an object group and referenced in an access list.

• EtherType access list example:

FWSM(config)# access-list ETHER ethertype permit ipx FWSM(config)# access-list ETHER ethertype permit bpdu FWSM(config)# access-list ETHER ethertype permit mpls-unicast FWSM(config)# access-list nonIP ethertype deny 1256 * FWSM(config)# access-group ETHER in interface inside

* The EtherType access list denies EtherType 0x1256.

NOTE When allowing mpls-unicast through transparent Layer 2 firewalls on the policy feature card (PFC), the command that needs to be enabled is

PFC(config)# mpls ldp router-id interface force or

PFC(config)# tag-switching tdp router-id interface force

• The following is an example of applying inbound or outbound access lists:

The traffic flow control with access lists can be done in two ways on an interface: inbound control or outbound control. Inbound control provides control on the traffic entering the interface, and the outbound control provides control on the traffic leaving the interface to the next hop device.

You can use inbound and outbound directions to control the flow of traffic with access lists. This mainly depends on the security policy. If the security policy can be complied with one direction of access lists in all interfaces, the other direction (inbound or outbound) can have a permit ip any any statement.

In Example 8-1, the inbound access list is allowed with permit ip any any and the outbound access list has a specific network based on the security policy that is allowed to traverse the network.

Example 8-1 Shows Inbound Access List with permit ip any any

ContextA(config)# access-list IN extended permit ip any any ContextA(config)# access-group IN in interface inside ContextA(config)# access-group IN in interface outside

Example 8-2 shows the outbound access list in the inside and the outside interfaces to have configuration of the security policy (allowing only specific subnets).

Example 8-2 Outbound Access List in the Inside and Outside Interfaces

ContextA(config)# access-list OUT-Inside extended permit tcp 10.1.1.1 0.0.0.255 any ContextA(config)# access-group OUT-Inside in interface inside

ContextA(config)# access-list OUT-Outside extended permit tcp any host 201.1.1.1 eq www

ContextA(config)# access-group OUT_Outside in interface outside

The direction to have a specific allow statement depends on the security zone. In Example 8-2, the access list is applied to the inside security zone. This is the most secured domain among other interfaces. Incoming traffic is trusted and allows any traffic to pass through. The outbound traffic is made specific.

In the outside interface, the inbound access list must be specific and granular, and the outbound access list in the outside interface can permit traffic to flow out of the outside interface. The access list and the direction of applying the list depend on the security policy. For no reason should optimization of access list security policy rules be compromised.

0 0

Post a comment