Virtual Firewall: Multiple context mode
A virtual firewall is a software-based firewall solution that operates within a virtualized environment to provide network security and access control. Unlike traditional hardware-based firewalls that are implemented using dedicated physical appliances, virtual firewalls are deployed as software instances or virtual appliances running on virtualized servers, hypervisors, or cloud platforms.
Here are key features and characteristics of virtual firewalls:
1. **Software-Based**: Virtual firewalls are implemented as software instances or virtual appliances that run on standard server hardware or virtualization platforms. They leverage the computing resources and capabilities of the underlying hardware infrastructure to provide firewall functionality.
2. **Network Security**: Virtual firewalls perform firewall functions, such as packet filtering, stateful inspection, NAT (Network Address Translation), VPN (Virtual Private Network) termination, and intrusion prevention, to protect network traffic from unauthorized access, malicious threats, and attacks.
3. **Scalability**: Virtual firewalls can be easily scaled up or down to accommodate changing network requirements and traffic loads. Additional virtual firewall instances can be deployed or removed dynamically as needed, making them highly flexible and adaptable to evolving network environments.
4. **Centralized Management**: Virtual firewalls can be centrally managed and configured through a centralized management console or software interface. Administrators can define firewall rules, access policies, and security settings across multiple virtual firewall instances from a single management platform.
5. **Integration with Virtualization Platforms**: Virtual firewalls are designed to integrate seamlessly with virtualization platforms, such as VMware, Microsoft Hyper-V, KVM (Kernel-based Virtual Machine), and cloud platforms like AWS (Amazon Web Services), Azure, and Google Cloud Platform. They can leverage platform-specific features and APIs to optimize performance and resource utilization.
6. **Security Isolation**: Virtual firewalls provide security isolation and segmentation within virtualized environments by enforcing access control policies and traffic filtering between virtual machines (VMs), virtual networks, and different network segments. They help prevent lateral movement of threats and contain security breaches within isolated compartments.
7. **High Availability and Redundancy**: Virtual firewalls support high availability and redundancy features to ensure continuous availability and resilience against hardware failures or network disruptions. They can be deployed in active-active or active-passive configurations with failover mechanisms for uninterrupted service continuity.
Use cases of virtual firewalls include:
- Securing virtualized data centers and cloud environments
- Enforcing network security policies for virtualized applications and workloads
- Providing perimeter security and access control for virtualized networks
- Segmenting network traffic between different departments, business units, or customer environments within a multi-tenant environment
- Protecting virtual desktop infrastructure (VDI) deployments and remote access solutions
- Integrating security services, such as intrusion detection/prevention systems (IDS/IPS), antivirus, and web filtering, within virtualized environments
Overall, virtual firewalls offer a flexible, scalable, and cost-effective approach to network security in virtualized and cloud environments, enabling organizations to enhance their security posture while maximizing the benefits of virtualization and cloud computing technologies.
What is multiple mode, and why?
Taking single physical firewall and logically carving it into two or more firewalls. There won’t be any change in throughput by doing so. Needed, when we have one firewall but we have different admin groups say HR and Sales and we need to configure different policies for these groups.
Convert system to multiple mode
First, convert the system to multiple mode from single context mode which is a default. Here context means a virtual firewall. If we have lot of different groups, this simplifies the policies. We can have separate access-list for each group and access-list configured on one group will not have an impact on access-list configured on another group.
Create new contexts
Context means a virtual firewall
Test and verify
1. Convert to multiple mode
2. Here we will have SYSTEM Config which doesn’t know about access-list and ip address configured. It all knows about the box and the contexts that we have.
3. Copy the previous running-config and saved it to flash as “old_running.cfg”. This is an automatic process.
4. All previous routes and relative config from old_running.cfg is put in new context called admin. It means user will have full functionality once again. This will have all nameif commands, security-level, MPF. One thing we will loose here is dynamic routing protocol if any configured earlier since multiple mode does not support dynamic routing protocol. Instead of dynamic routes, we can use static routes. From here we can create additional contexts based on the license that we have.
Before changing to multiple mode, it good to follow below steps
write mem
copy startup-config backup.txt : this will copy to flash
Same will be there in old_running.cfg as well but just to be sure we copied it manually.
Issue :
#show mode
#show firewall
#mode multiple
After rebooting it will create a system config :
which will have a hostname of the physical box, information on contexts that exists.
This will also have information on allocations and resources.
CONFIG URL: for whatever context exists which can be stored on flash, tftp or ftp server or http or https. we need to tell system has information on where that file is. Normally these files are stored locally on flash.
Now ASA is rebooted :
Execute show run
it will have system config which will have the same information that has been configured during the single mode.
We have default class for resource allocation
Information on context admin which is the default. same interfaces are allocated under admin which are part of previous running-config. Also specifies where the config url for that context.
config-url disk0:/admin.cfg : this is start-up config for this context
Note: No information about access-list and ip address
One way to know about System Config is that it will have just hostname ASA1#
ASA1# changeto context admin
ASA1/admin # show run
This will have interface config , MPF , access-list , NT rules and everything else
ASA1/admin # changeto context system or changeto system
By default, we are in system space
ASA1# more flash:/admin.cfg
This will display text version of startup-config for that context
For every context, we will have one .cfg file.
We can manage multiple modes through ASDM as well.
Config -> Interfaces
Note: We don’t have the ability to terminate VPN tunnel on the firewall that is in multiple mode. Only we can do that in routed single mode. Dynamic routing protocol also not present here. Only we have an option for static routes.
To create new contexts: only possible from system space
ASA1# show context
here we will have default admin context. admin is just a name we can change it to any other name.
admin-context admin
There can be only 1 context that has the role of admin at a time. One of the contexts must be assigned that role.
Say we have 5 contexts and we have assigned admin role to context 4. If somebody ssh to context 4 or if somebody asdm to that context and authenticates, they will also have the ability to climb up to system context and manage the whole box ie any contexts. Context 1, 2 ,3 and 5 will only be able to manage local firewall.
To see system context in ASDM
view -> Device list
never delete admin context since it will have ip address configured. Doing so we will be losing the connectivity to firewall.
Let’s create another firewall, ie context 2
we want to use outside interface g3 for both contexts with different ip address configured for both. We can assign different mac address as well.
Config -> Context Management -> Security Contexts -> Add -> Ctx-2 -> Add -> g2 un-shared and g3 shared int
We can create a resource Class named Silver and associate it to this context. This way we want to confirm that we are not utilizing complete resource available for one context.
CLI equivalent :
mac address auto: assign different mac address for shared outside interface
class Silver
limit-resource asdm 2 and so on
context Ctx-2
member Silver
allocate-interface g2 ctx_inside
allocate-interface g3 ctx_outside
config-url disk0:/ctx2.cfg
Note: if this file ctx2.cfg doesn’t exist it will create new but somehow if that file already exists it will read it , it like reading startup-config and merger everything in into running-config of this virtual firewall.
So for safety purpose always delete a file of the same name if it already exists in flash.
Note we need to enable interfaces from the system context . Until we enable int on the system, we won’t be able to configure it on ctx-2.
int <>
no shut
Now we need to configure interfaces on this context ctx-2
ASA1# changeto context ctx-2
Configure the interfaces
ASA1/Ctx-2#
For asdm access
http server enable
http 0 0 inside: let everybody connect if they are coming on inside interface
ASA1/Ctx-2#changeto system
show run
Now we will see Class Silver. we also have context Ctx-2 which is a member of Silver
show context
If we want Ctx-2 to have role of admin context
ASA1(config)# admin-context Ctx-2
show context
See the output
*Ctx-2 : * means this context has admin role
Again we will make admin context as admin role so that we will not lose connectivity
SA1(config)# admin-context admin
*admin
We can also make Ctx-2 as admin role and delete admin context and create new context Ctx-1
ASA1(config)# admin-context Ctx-2
ASA1(config)# no admin-context admin
ASA1(config)# context Ctx-1
Allocate the interfaces
ASA1(config-ctx)# config-url disk0:/admin.cfg : Already this file is there. It will use an existing file.
ASA1(config)# admin-context Ctx-1
show context
Taking single physical firewall and logically carving it into two or more firewalls. There won’t be any change in throughput by doing so. Needed, when we have one firewall but we have different admin groups say HR and Sales and we need to configure different policies for these groups.
Convert system to multiple mode
First, convert the system to multiple mode from single context mode which is a default. Here context means a virtual firewall. If we have lot of different groups, this simplifies the policies. We can have separate access-list for each group and access-list configured on one group will not have an impact on access-list configured on another group.
Create new contexts
Context means a virtual firewall
Test and verify
1. Convert to multiple mode
2. Here we will have SYSTEM Config which doesn’t know about access-list and ip address configured. It all knows about the box and the contexts that we have.
3. Copy the previous running-config and saved it to flash as “old_running.cfg”. This is an automatic process.
4. All previous routes and relative config from old_running.cfg is put in new context called admin. It means user will have full functionality once again. This will have all nameif commands, security-level, MPF. One thing we will loose here is dynamic routing protocol if any configured earlier since multiple mode does not support dynamic routing protocol. Instead of dynamic routes, we can use static routes. From here we can create additional contexts based on the license that we have.
Before changing to multiple mode, it good to follow below steps
write mem
copy startup-config backup.txt : this will copy to flash
Same will be there in old_running.cfg as well but just to be sure we copied it manually.
Issue :
#show mode
#show firewall
#mode multiple
After rebooting it will create a system config :
which will have a hostname of the physical box, information on contexts that exists.
This will also have information on allocations and resources.
CONFIG URL: for whatever context exists which can be stored on flash, tftp or ftp server or http or https. we need to tell system has information on where that file is. Normally these files are stored locally on flash.
Now ASA is rebooted :
Execute show run
it will have system config which will have the same information that has been configured during the single mode.
We have default class for resource allocation
Information on context admin which is the default. same interfaces are allocated under admin which are part of previous running-config. Also specifies where the config url for that context.
config-url disk0:/admin.cfg : this is start-up config for this context
Note: No information about access-list and ip address
One way to know about System Config is that it will have just hostname ASA1#
ASA1# changeto context admin
ASA1/admin # show run
This will have interface config , MPF , access-list , NT rules and everything else
ASA1/admin # changeto context system or changeto system
By default, we are in system space
ASA1# more flash:/admin.cfg
This will display text version of startup-config for that context
For every context, we will have one .cfg file.
We can manage multiple modes through ASDM as well.
Config -> Interfaces
Note: We don’t have the ability to terminate VPN tunnel on the firewall that is in multiple mode. Only we can do that in routed single mode. Dynamic routing protocol also not present here. Only we have an option for static routes.
To create new contexts: only possible from system space
ASA1# show context
here we will have default admin context. admin is just a name we can change it to any other name.
admin-context admin
There can be only 1 context that has the role of admin at a time. One of the contexts must be assigned that role.
Say we have 5 contexts and we have assigned admin role to context 4. If somebody ssh to context 4 or if somebody asdm to that context and authenticates, they will also have the ability to climb up to system context and manage the whole box ie any contexts. Context 1, 2 ,3 and 5 will only be able to manage local firewall.
To see system context in ASDM
view -> Device list
never delete admin context since it will have ip address configured. Doing so we will be losing the connectivity to firewall.
Let’s create another firewall, ie context 2
we want to use outside interface g3 for both contexts with different ip address configured for both. We can assign different mac address as well.
Config -> Context Management -> Security Contexts -> Add -> Ctx-2 -> Add -> g2 un-shared and g3 shared int
We can create a resource Class named Silver and associate it to this context. This way we want to confirm that we are not utilizing complete resource available for one context.
CLI equivalent :
mac address auto: assign different mac address for shared outside interface
class Silver
limit-resource asdm 2 and so on
context Ctx-2
member Silver
allocate-interface g2 ctx_inside
allocate-interface g3 ctx_outside
config-url disk0:/ctx2.cfg
Note: if this file ctx2.cfg doesn’t exist it will create new but somehow if that file already exists it will read it , it like reading startup-config and merger everything in into running-config of this virtual firewall.
So for safety purpose always delete a file of the same name if it already exists in flash.
Note we need to enable interfaces from the system context . Until we enable int on the system, we won’t be able to configure it on ctx-2.
int <>
no shut
Now we need to configure interfaces on this context ctx-2
ASA1# changeto context ctx-2
Configure the interfaces
ASA1/Ctx-2#
For asdm access
http server enable
http 0 0 inside: let everybody connect if they are coming on inside interface
ASA1/Ctx-2#changeto system
show run
Now we will see Class Silver. we also have context Ctx-2 which is a member of Silver
show context
If we want Ctx-2 to have role of admin context
ASA1(config)# admin-context Ctx-2
show context
See the output
*Ctx-2 : * means this context has admin role
Again we will make admin context as admin role so that we will not lose connectivity
SA1(config)# admin-context admin
*admin
We can also make Ctx-2 as admin role and delete admin context and create new context Ctx-1
ASA1(config)# admin-context Ctx-2
ASA1(config)# no admin-context admin
ASA1(config)# context Ctx-1
Allocate the interfaces
ASA1(config-ctx)# config-url disk0:/admin.cfg : Already this file is there. It will use an existing file.
ASA1(config)# admin-context Ctx-1
show context
No comments:
Post a Comment