Configure a virtual IP interface representing the router’s attachment to the bridge group with the interface

bvi number command.

Listing 6-2 shows the IRB configuration of the firewall router. After these configuration commands, the router performs two distinct logical functions: It bridges between two interfaces and routes between BVI1, FastEthernet0/0.100, and the serial interface (see Figure 6-2).

LISTING 6-2 IRB and IP Configuration of the Firewall Router

bridge irb ! interface FastEthernet0/0.1 bridge-group 1 ! interface FastEthernet0/0.5 bridge-group 1 ! interface FastEthernet0/0.100 ip address 192.168.0.1 ip nat inside NOTE

For the remainder of the router configuration, including Network Address Translation (NAT) configuration, see Chapter 4.

Firewalls LISTING 6-2 IRB and IP Configuration of the Firewall Router continued ! interface BVI1 ip address 10.0.0.1 255.255.255.0 ip nat inside !

bridge 1 protocol ieee bridge 1 route ip

The packets traversing the router thus take one of the following paths:

■ If the packet arrives through one of the bridged interfaces and the destination MAC address is not the router’s own

MAC address, it’s bridged according to the entries in the bridge forwarding database (displayed with the show

bridge number command).

10.0.0.0/24 Firewall Router FastEthernet 0/0.100 192.168.0.0/24 Serial 0/0.100 VLAN 517 BVI 1 FastEthernet 0/0.5 FastEthernet 0/0.1 192.168.201.4/30 VLAN 516 FIGURE 6-2 Logical structure of the firewall router

Firewalls ■ If the packet arrives through one of the bridge interfaces with the router’s MAC address as the destination MAC

address, it’s routed as if it were received through the BVI interface. The physical interface through which the packet has been received is mostly ignored in the routing process.

NOTE

BVI interface configuration is considered when routing these packets. For example, if you configure ip access-group in on the physical interface and the BVI interface, only the one on the BVI interface is applied.

■ If the packet arrives through any other interface and is routed to the BVI interface, the outbound configuration of the

BVI interface is applied (for example, the IP access list is checked, NAT translation is performed, and so on), and then the packet is bridged into the bridge group (which might involve flooding the packet if the ARP cache entry is still valid, but the destination MAC address is not available in the bridge forwarding database).

The transparent firewallfeature of Cisco IOS can now be applied to the bridged interfaces by assigning them to security zones. For example, you can create two new zones (clients and servers) and assign VLAN 516 to the clients zone and VLAN 517 to the servers zone (Listing 6-3). The BVI1 interface is obviously assigned to the inside zone.

LISTING 6-3 Zone Assignments of the Inside Physical and Logical Interfaces

zone security Inside zone security Clients zone security Servers !

class-map type inspect match-any Exchange match protocol msrpc

match protocol imap match protocol imaps match protocol pop3 match protocol pop3s match protocol smtp match protocol ldap match protocol ldaps !

Firewalls LISTING 6-3 Zone Assignments of the Inside Physical and Logical Interfaces continued match protocol netbios-ns

match protocol netbios-ssn match protocol netbios-dgm !

class-map type inspect match-any SQLServer match protocol ms-sql

!

policy-map type inspect ServerTraffic class type inspect SQLServer

inspect

class type inspect Netbios inspect

class type inspect Exchange inspect

class class-default drop

!

zone-pair security ClientsToServers source Clients destination Servers service-policy type inspect ServerTraffic

!

interface FastEthernet0/0.1 zone-member security Clients !

interface FastEthernet0/0.5 zone-member security Servers !

interface BVI1

Firewalls When defining the interzone policies, you have to define rules for traffic crossing from the clients zone to the servers zone (in our example, we allowed NetBIOS, SQL Server, and Outlook traffic from clients to the server) and vice versa (in our example, no sessions are allowed to be established from the servers toward the clients), but not between clients (or servers) and outside (or perimeter). This is a bit startling at first glance, but not if you consider the switching path a packet takes in the router:

■ When a packet is bridged between the Fast Ethernet interfaces, it’s considered to be crossing between the clients and

servers zones.

■ When a packet arrives through the bridged interfaces and is routed to another subnet, it’s considered to be arriving

through the BVI1 interface (thus from the inside zone).

It looks like a router would be split in two separate firewalls, one operating on the bridged level, and another one on the routed level (see Figure 6-3).

Using the transparent firewall feature in our sample firewall, you can filter the communication between the clients and the servers residing in separate VLANs, but you cannot use the clients and servers zones to limit traffic that these two groups of hosts are allowed to send to or receive from the perimeter or outside zones. If these hosts send the traffic to another

FastEthernet 0/0.100 Perimeter 192.168.0.0/24 Outside 192.168.201.4/30 Serial 0/0.100 Clients VLAN 516 BVI 1 Inside 10.0.0.0/24 Servers VLAN 517 FIGURE 6-3 Resulting firewall structure

Firewalls routed zone, it appears as if the traffic is coming from the inside zone, so the only way to differentiate between clients and servers when routing IP traffic is to define traffic classes used in the inside zone based on their IP addresses. In our example, we would have to extend the configuration from Chapter 4 by defining new traffic classes covering traffic toward the server or originating from the server and inserting them at the beginning of corresponding policy maps:

■ Class map AllServerTraffic covers all routed traffic to and from the server. This class is used as a catchall class that

drops all sessions that are not explicitly allowed.

■ Class map MailFromInside covers SMTP traffic from inside server to perimeter server.

■ There is no need for new classes covering traffic from outside or perimeter zones into the inside zone; no sessions

are allowed from outside to inside anyway and the existing configuration of PerimeterToInside policy map (Listing 4-4) already filters traffic based on the server’s IP address.

■ The new classes are inserted at the beginning of the existing InsideToPerimeter policy map. (See Listing 4-4for the complete configuration.) The InsideToOutside policy map is also modified to prevent session establishment from the server to the outside zone.

The modified firewall policy is included in Listing 6-4. As you can see, mixing IP hosts with different security require- ments in the same security zone (which is obviously against the rules we established in Chapter 2, “Typical Zone-Based Firewall Designs,” but is necessary because our design requirements and implementation details of the transparent fire- wall) degrades the concept of security zones to the complexity of building firewalls with IP access lists (most obvious in the InsideToPerimeter policy map).

Firewalls LISTING 6-4 Modified Firewall Policy for the Inside-to-Perimeter Zone Pair

class-map type inspect match-all MailFromInside match protocol smtp

match access-group name ServerAccess

class-map type inspect match-all AllServerTraffic match access-group name ServerAccess

!

ip access-list extended ServerAccess permit ip any host 10.0.0.10

permit ip host 10.0.0.10 any !

policy-map type inspect InsideToOutside class type inspect AllServerTraffic

drop

class type inspect WebTraffic ! defined in Chapter 4 inspect

class type inspect FileTransfer inspect

!

policy-map type inspect InsideToPerimeter class type inspect MailFromInside

inspect

class type inspect AllServerTraffic drop

class type inspect PublicTraffic ! defined in Chapter 4 inspect

class type inspect PublicManagement inspect

Firewalls

_{Protecting Internal Servers: Alternate Design}

The previous discussion of the transparent firewall behavior might have led you to believe that it has only marginal usability for our case study. This is the completely wrong impression; it’s counterintuitive only when used in a combined routed/bridged environment. As an alternative, cleaner design, you could deploy the second physical firewall between the servers and the clients, operating it in bridged-only mode. To illustrate the dilemmas arising in a mixed bridged/routed environment, we will also add the administrators zone (VLAN 515) that has privileged access to the servers

(Figure 6-4).

In the modified design, we still have three VLANs (servers, administrators, and clients) in the same IP subnet, so IRB is still needed to connect them. Ideally, both the inside and outside firewall would connect to all relevant VLANs (inside firewall to all three of them, outside firewall to clients and servers). However, with the introduction of the inter-VLAN bridge in the inside firewall, IRB can no longer be used on the outside firewall, because the attachment of two inter- VLAN bridges to the same VLANs would create a bridging loop, and at least one subinterface on the inside or outside firewall would be disabled, resulting in suboptimal traffic flow (Figure 6-5).

NOTE

Adding a second firewall in the inside network also slightly increases the security of the solution (defense-in-depth princi- ple); if an intruder gains access to the outside fire- wall or breaks through its defenses, the internal firewall still protects the servers.

FIGURE 6-4