Security Context on Firewall

Download

The virtual firewall methodology enables a physical firewall to be partitioned into multiple standalone firewalls. Each standalone firewall acts and behaves as an independent entity with its own configuration, interfaces, security policies, routing table, and administrators. In Cisco ASA, these virtual firewalls are known as security contexts.

Security Context Overview

The following are some example scenarios in which security contexts are useful in network deployments:

• You act as a service provider and you want to provide firewall services to customers. However, you do not want to purchase additional physical firewalls for each customer.
• You manage an educational institution and you want to segregate student networks from faculty networks for improved security using one physical security appliance.
• You administer a large enterprise with different departmental groups, and each department wants to implement its own security policies.
• You have overlapping networks in your organization and you want to provide firewall services to all of those networks without changing the addressing scheme.
• You currently manage many physical firewalls and you want to integrate security policies into one physical firewall.

Architectural Overview

In multiple security context mode, there are three types of configuration files rather than one. The Cisco security appliance can be divided into three types:

1. A System Execution Space
2. An Admin Context
3. One or More Customer Contexts

The System Execution Space is the startup configuration and is similar to a standard single-mode configuration except no network interfaces are defined other than a specialized failover interface. This system configuration is where the network administrator adds and manages the security contexts.

Here are the three important attributes configured for each context in the system execution space:

• Context name.
• Location of context's startup configuration. The configuration of each context is also known as a configlet.
• Interface allocation.

The Admin Context is not restricted and can be used as any other security context. When logged in as admin, all other security contexts can be seen and administered including the system configuration. The Admin context must reside on flash memory.

The Context Configurations are created for each separate security context. These configurations contain the security policies, interface configurations, etc., specific only to that context.

Contrasting Single and Multiple Mode Firewalls

Feature	Single Mode	Multiple Mode
Interface	All physical interfaces are available for use.	Only allocated interfaces are available in the contexts.
File management	Allows an administrator to copy system images and configurations.	Restricts a context administrator to manage the context configurations.
Firewall management	Allows a system administrator to fully manage the security appliance.	Allows a context administrator to manage the context.
Addressing scheme	Does not allow overlapping networks.	Allows overlapping networks between the contexts.
Routing protocols	Supports RIP and OSPF as the dynamic routing protocols.	Does not allow any dynamic routing protocols.
Licensing	There are no security contexts in single mode, hence no license is needed to turn on the security contexts.	Needs a license to activate more than two security contexts. The default license includes two customer security contexts and an admin context.
Resource allocation	The security appliance uses all the available resources.	The security appliance shares the system resources between the contexts.
Failover	Does not allow Active/Active failover.	Allows Active/Active failover for redundancy and load-balancing.
Quality of service	Supports QoS.	Does not support QoS.
Multicast	Supports multicast using PIM-SM.	Does not support multicast.
VPN	Supports remote access and site-to-site VPN tunnels.	Does not support VPNs.

Packet Flow in Multiple Mode

When the packets traverse through the security appliance in multiple mode, they are classified and forwarded to the right context. The packets are then processed based on the configured security policies on a context. The packet classification and the forwarding mechanism are discussed in the following subsections.

Packet Classification

In multiple mode, the security appliance must classify the packets to find out which context should operate on them. The packet classification is done at the ingress interface point that tags the packets using the source IP address, source port, destination IP address, destination port, and the interface or VLAN. The packet is processed based on the security policies configured in that context. Cisco ASA uses the following fields or packet identifiers to classify them properly:

• Source interface- If all the contexts in the Cisco ASA use unique interfaces, the packet classification becomes easier because the security appliance classifies these packets based on the source interface. As illustrated in Figure 9-2, when the packet is sourced from 192.168.10.10, the classifier assigns the packet to context CustA because the packet originated from G0/0, which is a part of the CustA security context.

Packet Classification Using Source Interface

• Destination IP address- The security appliance allows you to share one or more interfaces between the security contexts. In this deployment model, the shared interface uses the same network space with unique IP addresses on the end hosts. If the security appliance is configured to use a shared ingress interface, then it uses the destination IP address to further clarify which of the security contexts using the shared interface should receive the packets. In this case, the security contexts within the Cisco ASA cannot use overlapping IP addresses, and therefore all destination IP addresses must be unique.

Packet Forwarding Between Contexts

In multiple mode, the two contexts communicate with each other as if two standalone appliances were communicating with one another. The security contexts can talk to each other in two ways:

• Without a shared interface
• With a shared interface

Depending on what mode you use, the packet flow is different.

Configuration of Security Contexts

The configuration of a security context is broken down into seven steps:

1. Enable multiple security contexts globally.
2. Set up the system execution space.
3. Specify a configuration URL.
4. Allocate the interfaces.
5. Configure an admin context.
6. Configure a customer context.
7. Manage the security contexts (optional).

Step 1: Enabling Multiple Security Contexts Globally

The security context can be enabled by using the mode multiple command.

(Note: The security appliance saves the running configuration of the single-mode firewall as old_running.cfg in the Flash memory during the conversion process.)

Once the appliance comes online, you can use show mode to verify whether it is running in multiple mode.

Reverting to Single-Mode Firewall

To convert the device back to single mode, you have to copy the saved old_running.cfg as the startup configuration. After that, you need to switch the security appliance to single mode.

ASA1# copy disk0:/old_running.cfg startup-config

ASA1# mode single

Step 2: Setting Up the System Execution Space

As mentioned earlier, the system execution space is created as soon as multiple mode is enabled. To access the system execution space, you can do either of the following:

• Access the security appliance via the console or the auxiliary port.
• Log into the admin context using SSH or Telnet, and then switch to the system execution space.

If you are logged into the admin context, you need to use the changeto system command to get access to the system execution space.

Adding Customer Contexts in System Execution Space

ASA# configure terminal

ASA(config)# context CustA

Creating context 'CustA'... Done. (2)

ASA(config-ctx)# exit

ASA(config)# context CustB

Creating context 'CustB'... Done. (3)

ASA(config-ctx)# end

Step 3: Specifying a Configuration URL

The configuration URL specifies the location of the startup configuration for each context. The configured contexts (either admin or customer) are not active unless there is a configuration URL. The supported storage locations include the local disk and a network drive using the HTTP, HTTPS, FTP, or TFTP protocol. Once a configuration URL is specified, the Cisco ASA tries to retrieve the configuration from that location. If it does not find the configuration file, the Cisco security appliance creates a configuration file with the default settings.

An administrator can choose to specify different external servers as the configuration URL location for the security contexts.

Setting config-url for Security Contexts

ASA(config)# context admin

ASA(config-ctx)# config-url disk0:/admin.cfg

ASA(config-ctx)# context CustA

ASA(config-ctx)# config-url tftp://192.168.10.50/CustA.cfg

ASA(config-ctx)# context CustB

ASA(config-ctx)# config-url ftp://cisco:cisco123@192.168.20.50/CustB.cfg

Changing the Configuration URL

ASA# change context CustA

ASA/CustA# configure terminal

ASA/CustA(config)# clear configure all

ASA/CustA(config)# changeto system

ASA(config)# context CustA

ASA(config-ctx)# config-url ftp://cisco:cisco123@192.168.10.50/CustA.cfg

Step 4: Allocating the Interfaces

After defining the configuration URL, the next step is to allocate interfaces to each of the security contexts. You can assign either a physical interface or a subinterface to a security context. Do this by entering into the context subconfiguration mode and using the allocate-interface command.

The allocate-interface command can hide the physical interface name from the security context if a mapped name is used. This provides additional security by displaying only the mapped name to the context administrator.

Allocating Interfaces to Security Contexts

ASA(config)# context CustA

ASA(config-ctx)# allocate-interface GigabitEthernet0/0 A_inside invisible

ASA(config-ctx)# allocate-interface GigabitEthernet0/1 A_outside invisible

ASA(config-ctx)# exit

ASA(config)# context CustB

ASA(config-ctx)# allocate-interface GigabitEthernet0/2 B_inside invisible

ASA(config-ctx)# allocate-interface GigabitEthernet0/3 B_outside invisible

Step 5: Configuring an Admin Context

Cisco ASA creates an admin context automatically, if you convert it from single to multiple mode and you answer "yes" to "Convert the system configuration?" The admin context is treated as any other customer context in the security appliance. To log into the admin context, use the changeto context command, where an administrator logs into admin context called admin.

Setting Up an Admin Context

ASA(config)# context CustA

ASA(config-ctx)# config-url disk0:/CustA.cfg

ASA(config-ctx)# exit

ASA(config)# admin-context CustA

Not sure which context is set up as the admin context? Use one of the following three methods to find out:

• show running-config | include admin-context
• show admin-context
• show context, and look for the context name with an asterisk (*)

Step 6: Configuring a Customer Context

Any context that is not set up as the admin context is referred to as the customer context.

Step 7: Managing the Security Contexts (Optional)

Cisco ASA provides many ways to manage and optimize system resources. For example, if a context name is mistyped or if it needs to be deleted, you can remove it by typing no context followed by the name of that context.

In a situation where all contexts need to be removed, you can use the clear configure context command.

Example Configuration

Topology for Example Configuration

R1

int f0/0

ip add 192.168.1.100 255.255.255.0

no shut

ip route 0.0.0.0 0.0.0.0 255.255.255.0 192.168.1.1

R2

int f0/0

ip add 192.168.2.100 255.255.255.0

no shut

ip route 0.0.0.0 0.0.0.0 255.255.255.0 192.168.2.1

R3

int f0/0

ip add 192.168.3.100 255.255.255.0

no shut

ip route 0.0.0.0 0.0.0.0 255.255.255.0 192.168.3.1

ASA

sh mode

security context mode: single

config t

mode multiple

convert the system configuration? [confirm]

reload

config t

int g0

no sh

int g1

no sh

int g2

no sh

int g3

no sh

context c1

creating conetxt 'C1'... Done.

config-url disk0:c1.cfg

allocate-interface g0

allocate-interface g1

context c2

creating conetxt 'C2'... Done.

config-url disk0:c2.cfg

allocate-interface g0

allocate-interface g2

change to context c1

int g0

ip add 192.168.

1.1 255.255.255.0

nameif outside

int g1

ip add 192.168.2.1 255.255.255.0

nameif inside

exit

changeto system

mac-address auto(for shared interface in system area)

changeto context c2

conf t

int g0

nameif outside

ip add 192.168.1.1 255.255.255.0

int g2

nameif inside

ip add 192.168.3.1 255.255.255.0

R1

Ping 192.168.1.1

Success!!!!!!

R2

Ping 192.168.2.1

Success!!!!!!

R3

Ping 192.168.3.1

Success!!!!!!

ASA

Changeto context c1

Ping 192.168.1.100

Success!!!!!!

Ping 192.168.2.100

Success!!!!!!

Changeto context c2

Ping 192.168.1.100

Success!!!!!!

Ping 192.168.3.100

Success!!!!!!

----
@NetwaxLab