As a security best practice, we recommend that you segment your network into smaller physical or logical pieces, a practice known as network segmentation.
Internal network segmentation acts as an extra layer of defense to your perimeter security. For example, if an outside attacker breaches your network perimeter, segmentation helps to confine the breach because the attacker cannot traverse segments to connect to your entire network.
Segmentation can also help prevent unwanted connections to network resources from internal users. For example, to better secure internal servers that handle payment processing, you can create a virtual local area network (VLAN) for those servers. Next, you can configure a Firebox policy that allows connections to that VLAN from only the VLANs you specify. Users on other VLANs cannot connect to the payment processing servers.
Segmentation can also help improve network performance because it can reduce traffic congestion. On a flat network, which is network that is not segmented, hosts send traffic across a single broadcast domain. When you divide a flat network into subnets, each subnet represents a smaller broadcast domain. Because there are fewer hosts on each broadcast domain, less traffic occurs on each broadcast domain.
For example, to improve network performance for latency-sensitive applications, you can create a separate physical segment for those application servers. This segmentation helps to make sure congestion caused by lower-priority traffic, such as web browsing, does not affect application performance.
This topic describes these concepts:
- Benefits of Segmentation
- How Segmentation Works
- Basic Topologies
- Policies for Segmented Networks
- Authentication and Segmentation
Benefits of Segmentation
Network segmentation helps you to better secure your network in several ways:
- Protect data by allowing connections to network resources from only specific portions of your network
- Isolate security threats, such as perimeter breaches and malware, to smaller sections of your network
- Keep your guest and corporate networks separate
- Meet security requirements defined by industry regulations such as the Payment Card Industry Data Security Standard (PCI DSS)
- Protect devices on your internal network that have limited built-in security, such as Internet of Things (IoT) devices
Network segmentation can also help to improve network performance so that traffic congestion is less likely to affect critical business applications.
How Segmentation Works
When you segment a network, you divide it into smaller pieces known as segments. Segments can be physical or logical:
- Physical segment — A segment of your network defined by physical topology. For example, you might connect network servers to one switch and user computers to another switch.
- Logical segment — A segment of your network defined by software. For example, on a single switch, you might define multiple virtual local area networks (VLANs) that correspond to departments in your organization. Or, you might define a VLAN that spans more than one switch. For more information about VLANs, go to About Virtual Local Area Networks (VLANs).
On the Firebox, you can create policies that allow connections to network resources from specific segments. For example, you can add policies like these:
- A policy that allows traffic to a file server from only subnet 10.0.1.0/24
- A policy that allows traffic to VLAN2 from only VLAN1
- A policy that allows traffic from all Trusted interfaces (represented by the built-in alias Any-Trusted) to your internal email server
- A policy that allows traffic from only one Trusted interface to your internal email server
Hosts on one internal network cannot connect to hosts on a separate internal network unless you configure a Firebox policy that allows the connection. For example, if you configure multiple Trusted interfaces, hosts on one Trusted network cannot connect to hosts on a separate Trusted network unless you configure a Firebox policy that allows the connection. In Fireware, the term interface type refers to the security zone. There are three internal interface types (zones): trusted, optional, and custom. For more information about interface types, go to About Network Modes and Interfaces.
Basic Topologies
This diagram shows a flat (unsegmented) network. User computers and servers are on the same subnet, which is 10.0.1.0/24 in this example. This topology does not include VLANs.
On a flat network, the Firebox cannot see or control traffic that flows on the internal network.
If you divide a flat network into smaller segments, the Firebox can monitor and control traffic that flows between segments. For example, if you place user computers and servers on separate segments, you can add Firebox policies that control traffic that traverses segments, and the Firebox can monitor this traffic.
This diagram shows a network with basic segmentation. The network server and user computers are on different subnets. In this example, the subnets are 10.0.1.0/24 and 10.0.2.0/24.
On a segmented network, the Firebox can see and control internal network traffic that flows between segments. For example, you can add Firebox policies that control traffic between user computers on the eth1 LAN (10.0.1.0/24) and servers on the eth2 VLAN (10.0.2.0/24). The Firebox can also monitor this traffic.
Policies for Segmented Networks
If some traffic must traverse segments on your network, you can create Firebox policies that allow the traffic.
In the policy settings, we recommend that you specify the protocols in use on your network. With this level of granularity, the Firebox allows protocols that users require to complete their work but does not allow unrecognized or untrusted traffic.
In this example, you have a VLAN named Support VLAN for the IT support team at your company. This team must be able to connect to a specific network server with the SSH protocol. No one else in the company requires an SSH connection to this server. To allow this traffic, you can add a custom Firebox policy that specifies the SSH port and protocol. In the From list of the policy, specify only the Support VLAN alias. In the To list, specify the network server this team must connect to.
In this example, your network includes multiple subnets. You create a policy that allows only users on subnets 10.0.2.0/24 and 10.0.5.0/24 to make an RDP connection to one of your servers. Computers on other subnets on your network cannot make an RDP connection to this server.
When you first enable a mobile VPN on the Firebox, the Firebox adds a default policy that allows users to connect to all network resources. This occurs because the To list in the default policy includes only the alias Any. For example, the Mobile VPN with IKEv2 default policy allows connections from the IKEv2-Users group to the alias Any.
We recommend that you replace the default mobile VPN policy with policies that specify which users or groups can connect to which network resources.
For example, this policy allows DNS traffic from internal and remote users to a local DNS server (Internal_DNS_Server_1) and to multiple external DNS servers included in the alias External_DNS_Servers.
If you already have policies that allow specific user groups, those policies also apply to users who send traffic through a VPN if you include the user group in a mobile VPN user group.
For example, the SSH Traversal policy in the Policies That Allow Connections from VLANs section works for the Support group regardless of whether they are inside the network or on a VPN. This works if you add the Support user group in the Mobile VPN with IKEv2 configuration.
For more information about the default mobile VPN policy, go to:
Authentication and Segmentation
You can use authentication in addition to network or VLAN segmentation to allow users to connect to resources regardless of the user's physical location on the local network. This is important for users who must log in to computers from different locations in your office.
For example, an IT support technician must troubleshoot a problem on a manager's computer, which is on a VLAN named Managers VLAN. To complete a task on the manager's computer, the technician must temporarily make an SSH connection to a server on a different subnet. The Firebox policy for traffic to that server does not allow traffic from computers on the Managers VLAN. However, the Firebox policy does allow traffic from both the Support user group and the Support VLAN. Because the technician is a member of the Support user group, the technician can connect to that server from any computer on the network, including a computer on the Managers VLAN.
This diagram shows the network described in this example.
The eth1 interface can be a VLAN interface or a regular interface (Trusted, Optional, or Custom interface). In this example, for a regular interface, you must configure static routes that point to the switch to handle traffic to those VLANs.
This is the policy described in this example:
In policies, you can specify user groups defined on the local Firebox authentication server (Firebox-DB) or on external authentication servers. For more information about authentication server support, go to Authentication Server Types.
This diagram shows a network with multiple subnets. To control access to the network server, you can create policies that allow traffic to network resources from subnets, user groups, or both.
In this example policy, we allow only the Support user group and hosts on the 10.0.2.0/24 subnet to make an SSH connection to a server (Server1) on the 10.0.3.0/24 subnet.
802.1X is an IEEE standard for network access control (NAC). You can use 802.1X on network devices such as switches and Wi-Fi access points to allow only authenticated users to pass traffic. Switches and access points configured to use 802.1X can assign clients to a specific network or VLAN based on authentication information such as user groups.
If you use 802.1X for network access control, you can integrate it with RADIUS SSO (RSSO) on the Firebox. With RADIUS SSO, your users on the trusted or optional networks provide their user credentials one time (when they connect to the wireless access point or other RADIUS client) and they automatically authenticate to your Firebox. For more information about RSSO, go to About RADIUS Single Sign-On.
Authentication Only
As a best practice, we recommend that you implement network segmentation and authentication together. Access control based solely on authentication is less secure because different departments in your company are not segmented from each other.
If multiple physical segments or VLANs are not feasible on your network, it is important to at least implement authentication to control access to resources. Authentication requires users to verify their identity to connect to network resources.
Keep in mind that the Firebox does not handle intra-host traffic that occurs behind switches or routers. For example, if traffic between a user computer and an internal server does not go through the Firebox, the Firebox does not apply policies to that traffic. In this example, you cannot use Firebox policies to allow or deny connections from users and groups to network resources.