Security Zones and Security Policies on Security Devices
Understanding Layer 2 Security Zones
A Layer 2 security zone is a zone that hosts Layer 2 interfaces. A security zone can be either a Layer 2 or Layer 3 zone; it can host either all Layer 2 interfaces or all Layer 3 interfaces, but it cannot contain a mix of Layer 2 and Layer 3 interfaces.
The security zone type—Layer 2 or Layer 3—is implicitly set from the first interface configured for the security zone. Subsequent interfaces configured for the same security zone must be the same type as the first interface.
You cannot configure a device with both Layer 2 and Layer 3 security zones.
You can configure the following properties for Layer 2 security zones:
Interfaces—List of interfaces in the zone.
Policies—Active security policies that enforce rules for the transit traffic, in terms of what traffic can pass through the firewall, and the actions that need to take place on the traffic as it passes through the firewall.
Screens—A Juniper Networks stateful firewall secures a network by inspecting, and then allowing or denying, all connection attempts that require passage from one security zone to another. For every security zone, and the MGT zone, you can enable a set of predefined screen options that detect and block various kinds of traffic that the device determines as potentially harmful.
Note:You can configure the same screen options for a Layer 2 security zone as for a Layer 3 security zone.
Address books—IP addresses and address sets that make up an address book to identify its members so that you can apply policies to them.
TCP-RST—When this feature is enabled, the system sends a TCP segment with the reset flag set when traffic arrives that does not match an existing session and does not have the synchronize flag set.
In addition, you can configure a Layer 2 zone for host-inbound traffic. This allows you to specify the kinds of traffic that can reach the device from systems that are directly connected to the interfaces in the zone. You must specify all expected host-inbound traffic because inbound traffic from devices directly connected to the device's interfaces is dropped by default.
See Also
Example: Configuring Layer 2 Security Zones
This example shows how to configure Layer 2 security zones.
Requirements
Before you begin, determine the properties you want to configure for the Layer 2 security zone. See Understanding Layer 2 Security Zones.
Overview
In this example, you configure security zone l2-zone1 to include a Layer 2 logical interface called ge-3/0/0.0 and security zone l2-zone2 to include a Layer 2 logical interface called ge-3/0/1.0. Then you configure l2-zone2 to allow all supported application services (such as SSH, Telnet, and SNMP) as host-inbound traffic.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security-zone l2-zone1 interfaces ge-3/0/0.0 set security-zone l2-zone2 interfaces ge-3/0/1.0 set security-zone l2–zone2 host-inbound-traffic system-services all
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure Layer 2 security zones:
Create a Layer 2 security zone and assign interfaces to it.
[edit security zones] user@host# set security-zone l2-zone1 interfaces ge-3/0/0.0 user@host# set security-zone l2-zone2 interfaces ge-3/0/1.0
Configure one of the Layer 2 security zones.
[edit security zones] user@host# set security-zone l2–zone2 host-inbound-traffic system-services all
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Verification
To verify the configuration is working properly,
enter the show security zones command.
Understanding Security Policies in Transparent Mode
In transparent mode, security policies can be configured only between Layer 2 zones. When packets are forwarded through the VLAN, the security policies are applied between security zones. A security policy for transparent mode is similar to a policy configured for Layer 3 zones, with the following exceptions:
NAT is not supported.
IPsec VPN is not supported.
Application ANY is not supported.
Layer 2 forwarding does not permit any interzone traffic unless there is a policy explicitly configured on the device. By default, Layer 2 forwarding performs the following actions:
Allows or denies traffic specified by the configured policy.
Allows Address Resolution Protocol (ARP) and Layer 2 non-IP multicast and broadcast traffic.
Continues to block all non-IP and non-ARP unicast traffic.
This default behavior can be changed for Ethernet switching packet flow by using either J-Web or the CLI configuration editor:
Configure the
block-non-ip-alloption to block all Layer 2 non-IP and non-ARP traffic, including multicast and broadcast traffic.Configure the
bypass-non-ip-unicastoption to allow all Layer 2 non-IP traffic to pass through the device.
You cannot configure both options at the same time.
Starting in Junos OS Release 12.3X48-D10 and Junos OS Release 17.3R1, you can create a separate security zone in mixed mode (the default mode) for Layer 2 and Layer 3 interfaces. However, there is no routing among IRB interfaces and between IRB interfaces and Layer 3 interfaces. Hence, you cannot configure security policies between Layer 2 and Layer 3 zones. You can only configure security policies between the Layer 2 zones or between Layer 3 zones.
See Also
Example: Configuring Security Policies in Transparent Mode
This example shows how to configure security policies in transparent mode between Layer 2 zones.
Requirements
Before you begin, determine the policy behavior you want to include in the Layer 2 security zone. See Understanding Security Policies in Transparent Mode.
Overview
In this example, you configure a security policy to allow HTTP traffic from the 192.0.2.0/24 subnetwork in the l2–zone1 security zone to the server at 192.0.2.1/24 in the l2–zone2 security zone.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security policies from-zone l2-zone1 to-zone l2-zone2 policy p1 match source-address 192.0.2.0/24 set security policies from-zone l2-zone1 to-zone l2-zone2 policy p1 match destination-address 192.0.2.1/24 set security policies from-zone l2-zone1 to-zone l2-zone2 policy p1 match application http set security policies from-zone l2-zone1 to-zone l2-zone2 policy p1 then permit
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure security policies in transparent mode:
Create policies and assign addresses to the interfaces for the zones.
[edit security policies] user@host# set from-zone l2-zone1 to-zone l2-zone2 policy p1 match source-address 192.0.2.0/24 user@host# set from-zone l2-zone1 to-zone l2-zone2 policy p1 match destination-address 192.0.2.1/24
Set policies for the application.
[edit security policies] user@host# set from-zone l2-zone1 to-zone l2-zone2 policy p1 match application http user@host# set from-zone l2-zone1 to-zone l2-zone2 policy p1 then permit
Results
From configuration mode, confirm your configuration
by entering the show security policies command. If the
output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@host> show security policies
from-zone l2-zone1 to-zone l2-zone2
{
policy p1 {
match {
source-address 192.0.2.0/24;
destination-address 192.0.2.1/24;
application junos-http;
}
then {
permit;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Understanding Firewall User Authentication in Transparent Mode
A firewall user is a network user who must provide a username and password for authentication when initiating a connection across the firewall. Firewall user authentication enables administrators to restrict and permit users accessing protected resources behind a firewall based on their source IP address and other credentials. Junos OS supports the following types of firewall user authentication for transparent mode on the SRX Series Firewall:
Pass-through authentication—A host or a user from one zone tries to access resources on another zone. You must use an FTP, Telnet, or HTTP client to access the IP address of the protected resource and be authenticated by the firewall. The device uses FTP, Telnet, or HTTP to collect username and password information, and subsequent traffic from the user or host is allowed or denied based on the result of this authentication.
Web authentication—Users try to connect, by using HTTP, to an IP address on the IRB interface that is enabled for Web authentication. You are prompted for the username and password that are verified by the device. Subsequent traffic from the user or host to the protected resource is allowed or denied based on the result of this authentication.