Professional Documents
Culture Documents
5.b
Student Guide
1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Course Number: EDU-JUN-CJFV
Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Configuring Juniper Networks Firewall/IPSec VPN Products Student Guide, Revision 5.b Copyright 2007, Juniper Networks, Inc. All rights reserved. Printed in USA. Revision History: Revision 5.bApril 2007 The information in this document is current as of the date listed above. The information in this document has been carefully verified and is believed to be accurate for software Release 5.4. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice. YEAR 2000 NOTICE Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The JUNOS software has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. SOFTWARE LICENSE The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
Contents
Chapter 1: Chapter 2: Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 ScreenOS Concepts, Terminology, and Platforms . . . . . . . . . . . . . . . . . . . . . . 2-1
Security Device Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 ScreenOS Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10 Juniper Networks Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Chapter 3:
Chapter 4:
Chapter 5:
Chapter 6:
Chapter 7:
Contents iii
Chapter 8:
Chapter 9:
iv Contents
Course Overview
Configuring Juniper Networks Firewall/IPSec VPN Products (CJFV) is the first course in the ScreenOS curriculum. It is a three-day, instructor-led course that focuses on configuration of the Juniper Networks firewall/VPN products in a variety of situations, including basic administrative access, routing, firewall policies and policy options, attack prevention features, address translation, and VPN implementations. The course combines both lecture and labs, with significant time allocated for hands-on experience. Students completing this course should be confident in their ability to configure Juniper Networks firewall/VPN products in a wide range of installations.
Objectives
After successfully completing this course, you should be able to: Explain the Juniper Networks security architecture. Configure administrative access and options. Backup and restore configuration and ScreenOS files. Configure a Juniper Networks device in transparent, route, and NAT modes. Discuss the applications of multiple virtual routers. Configure the Juniper Networks firewall to permit and deny traffic based on user defined policies. Configure advanced policy options. Identify and configure network designs for various types of network address translation. Configure policy-based and routebased VPN tunnels.
Intended Audience
This course is intended for network engineers, support personnel, reseller support, and others responsible for implementing Juniper Networks products.
Course Level
This is an introductory-level course.
Prerequisites
This course assumes that students have basic networking knowledge and experience in the following areas: The Internet Networking concepts Terms including TCP/IP, bridging, switching, and routing.
Course Overview v
Course Agenda
Day 1
Chapter 1: Chapter 2: Chapter 3: Chapter 4: Course Introduction ScreenOS Concepts, Terminology, and Platforms Initial Connectivity Device Management
Day 2
Chapter 5: Chapter 6: Chapter 7: Chapter 8: Layer 3 Operations Basic Policy Configuration Policy Options Address Translation
Day 3
Chapter 9: Transparent Mode (Optional) Chapter 10: VPN Concepts Chapter 11: Policy-Based VPNs Chapter 12: Route-Based VPNs Appendix A: Additional Features
vi Course Agenda
Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table. Style Franklin Gothic Courier New Description Normal text. Console text: Century Gothic Screen captures Noncommand-related syntax commit complete Exiting configuration mode Select File > Open, and then click Configuration.conf in the Filename text box. Usage Example Most of what you read in the Lab Guide and Student Guide.
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats: Go to http://www.juniper.net/techpubs/ Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Additional Information ix
x Additional Information
Introductions
This slide serves to break the ice by having you introduce yourself and state your reasons for attending the class.
Course Contents
This slide lists the topics we discuss in this course.
Prerequisites
This slide lists the prerequisites for this course.
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and feedback. Depending on the class you are taking, please complete the survey at the end of the class, or be sure to look for an e-mail about two weeks from class completion that directs you to complete an online survey form (be sure to provide us with your current e-mail address). Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for taking the time to help us improve our educational offerings.
Security Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks security technologies.
WX Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks WX Framework technologies.
DX Curriculum
This slide displays the primary Education Services offerings that support Juniper Networks DX Application Acceleration Platform technologies.
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them now so that your instructor can best address your needs during class.
Firewall
Fundamental firewall intelligence consists of the ability to make filtering decisions based on IP packet header information. When individual packets are received by a firewall, they are compared with a set of rules. Each rule consists of a source and destination IP address, Layer 4 protocol, source and destination ports, and most importantly, an action (permit or deny). When a packet matches a rule, the action is performed.
Virtual Systems
Multiple firewall devices emulated in one physical hardware device is a virtual system. Only the high-end Juniper Networks firewalls support virtual systems.
Interface Designations
The slide shows a list of platforms and interface naming. You can see that on the different platforms interfaces have different names.
Virtual Interfaces
The slide shows a list of the syntax of virtual interfaces on the ScreenOS devices.
Attack Prevention
Attack prevention describes the Juniper Networks security options available in ScreenOS software. Many of these options are SCREEN options that you can enable at the security zone level. SCREEN options apply to traffic reaching the Juniper Networks security device through any interface bound to a zone for which you enabled such options. SCREEN options offer protection against IP address and port scans, denial-of-service (DoS) attacks, and other kinds of malicious activity. You can apply other network security options, such as Web filtering, antivirus checking, and intrusion detection and prevention (IDP) at the policy level. These options only apply to traffic under the jurisdiction of the policies in which they are enabled.
4.
5.
6.
8.
9.
Therefore, the firewall forwards the packet out interface E8 (as determined by the destination lookup) and adds the information to the session table. Traffic in both directions for this particular session will be allowed to pass without any subsequent policy evaluation. Not shown is the network address translation that takes place on the packet.
(Note that the 5-GT and Hardware Security Client (HSC) devices do not use ASICs; instead, these devices use high-performance CPUs to provide the required performance and throughput.) Continued on next page.
NS Configuration Line
Designed for the fixed telecommuter and the small remote office environment, the Juniper Networks NS-Hardware Security Client (NS-HSC) solution is the most cost-effective integrated security solution for the fixed telecommuter and small remote office. Combining a complete set of best-in-class unified threat management (UTM) security features including intrusion prevention system (IPS), antivirus (includes antispyware, antiadware, antiphishing), antispam, and Web filtering allows the NS-5GT device to defend the network against worms, spyware, trojans, malware and other emerging attacks. It can easily be deployed and managed in large deployments using Rapid Deployment capabilities within Juniper Networks Security Manager to eliminate expensive staging steps.
Appliance Deployment
This slide illustrates typical deployments of Juniper Networks firewall/VPN appliances. The SSG 520 device near the top of the slide is providing firewall protection between internal zones as well as from the Internet. It is also providing VPN tunnel access via the Internet for remote offices (via the SSG 20 and SSG 5 devices) and a remote mobile user (via the NS-Remote).
System Deployment
On this slide, a Juniper Networks firewall/VPN systemthe NS-5400 deviceis providing firewall controls for a service provider providing VPN connectivity for two different customers. The virtual system capabilities of the NS-5400 device allow the two customer networks to be completely isolated from each other, even though they are physically connected to the same device. Each VSYS has its own set of policies, and the service provider has the option of creating VSYS-specific administrators, thereby allowing customers to maintain their own internal security implementations.
Review Questions
1. 2. 3. 4.
System Components
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
System Components
In a Juniper Networks device, the ScreenOS image and the saved configuration file are stored in flash memory. Upon startup, after the power-on self-test (POST) completes, the ScreenOS image loads into RAM and begins executing. The ScreenOS software loads the saved configuration file into RAM and executes the statements in sequential order. As a result, various processes are started, buffers, caches and tables are created, and parameters are assigned to system resources. Once the initialization of the device is complete, any additional configuration changes you make (either from the CLI, the WebUI, or TFTP) are applied to the running configuration in RAM. Once defined, those changes take effect immediately. You can use Security Manager to centrally manage many Juniper Networks devices. This course demonstrates how you can use Security Manager to do just that. A Juniper Networks device can also interact with one or more external servers that provide auxiliary services. These auxiliary services can include, but are not limited to, authentication, domain name lookup, logging, simple network management, and proxies.
CLI Characteristics
You can manage a Juniper Networks device from the console port by making a serial connection (COM port) from a workstation or PC. The console ports on Juniper Networks devices vary as to the cable requirements. The NS-5GT and NS-500 devices use a DB9 female to DB9 male straight-through serial cable. The SSG 5, NS-25, NS-50, NS-200, and NS-5000 products use an RJ45 serial cable. On the PC, activate a terminal emulation program with the following settings: 9600 bps 8 bit, no parity 1 stop bit No flow control
CLIFunctionality
After establishing a connection to the console port, the device prompts you to log in. The default login on all Juniper Networks devices is a username of netscreen and a password of netscreen.
Keyboard Shortcuts
The Juniper Networks CLI supports most common keyboard shortcuts for command editing as well as command recall and command completion. In addition, command abbreviation is available with most commands capable of being abbreviated to three or four characters. The Question Mark key (?) is available for help with command syntax, both at the prompt and within partially completed commands. Note the unset command. You can use this command to remove individual settings from RAM. If you use the command unset all, you do not modify RAM; instead, you erase the saved configuration file from flash memory. Use this option when repurposing a device to erase all saved configuration, then reset the box to boot up with a default (unconfigured) device.
WebUI Characteristics
The ScreenOS software on Juniper Networks devices also supports a Web-based graphical user interface (GUI). Opening a browser window on the PC and navigating to an IP address on the Juniper Networks device activates the WebUI. All Juniper Networks devices ship with a default IP address of 192.168.1.1, which is accessible from the product-specific interface for the device. As long as this IP address is reachable, you can browse to the Juniper Networks device and configure it. However, if you change the IP address of the interface through which you are connected, you will lose the Web session. Therefore, we recommend that you perform the initial IP configuration from the CLI, then use the browser afterward. We discuss this IP configuration later in this section. If you browse to a Juniper Networks NS-5GT device that has no configuration saved in flash memory, an Initial Configuration Wizard will display instead of the login screen. This Wizard takes you through a series of screens that defines the operational mode, assigns the root administrator name and password, defines the address and subnet mask for selected interfaces, and enables auxiliary services such as DNS.
Main ScreenWebUI
The WebUI presentation always opens to the Home screen. The page is organized with a navigation panel on the left and information or configuration panels on the right. In the left panel, the Toggle Menu button enables you to switch between Dynamic Hypertext Markup Language (DHTML) and Java format when navigating between functions. The Home screen presents a variety of key system information. Much of the status information is similar to the output of a get system command at the CLI. In addition, the WebUI also includes administrator logins, system resource utilization, recent log events, and alarms. You can monitor system events and system resources conveniently from the Home screen and, as a result, you can refresh the screen to show the most current status. The Home screen defaults to manual refresh, although you can schedule the refresh in advance for common intervals, ranging from ten seconds to several minutes. Navigation in the WebUI is simple. Clicking a category title or the plus sign (+) associated with the category title expands the category and reveals the sub topics. Once a sub topic is selected, the right panel updates and displays the current settings or available configuration options.
Establishing Connectivity
The slide highlights the topic we discuss next.
Zone Types
Three main types of zones exist on a Juniper Networks firewall. You use security zones for creating security policies. The Juniper Networks device includes predefined security zones, but you can create your own security zones with naming conventions that map more closely to your network infrastructure. You use Layer 2 (V1) security zones when the Juniper Networks device operates in transparent mode; you use Layer 3 zones when the Juniper Networks device operates in NAT/route mode. (We discuss both these modes in detail later in this course.) Function zones are zones that serve a single, specific purpose within the firewall. They are not used in security policies. Function zones include the following: Null: This zone is the default zone for an interface that is not bound to any other zone. An interface is not configurable while it is bound to the Null zone. Self: This zone hosts the logical and internal interface for remote management connections (Telnet, HTTP, SSH). MGT: This zone hosts the out-of-band management interface on firewall systems (NS-500 device, NS-5000 devices).
The Tunnel zone is used for backward-compatible tunnel support when upgrading from ScreenOS software versions earlier than Release 3.1.
Management Services
Depending on the zone assignment of an interface, different management services are enabled. These defaults protect the Juniper Networks device from unauthorized access. The two-step process to enable SSH on an interface is the following: set interface e1 manage ssh set ssh enable When you enable SSH, you must enable the SSH server.
Management ServicesWebUI
You can override these defaults selectively on each interface by checking the appropriate boxes in the WebUI. The Manageable check box next to the interface IP address overrides any selected service options; if Manageable is not checked, no management services will be available from the interface.
manage-ip Address
By default, the management IP address on an interface is the same as the interface IP address. However, you might want to configure a separate IP address for management purposes. This address adds an additional element of security to your system; management services will only be available via the manage-ip address, not the interface address. As the manage-ip address is never published nor used as a source address (for example, in a routing update), it is invisible to any snooping on your network and therefore, more secure. Note, however, that the physical interface IP address will still respond if pinged. Another instance where the manage-ip address is useful is in a redundant configuration. The interface address will be identical for both redundant devices, but the manage-ip address can be unique for each, allowing individual accessibility. The only requirement for a separate management address is that the address be selected from the same block of subnet addresses as the interface IP address.
Default Route
Adding a default route to the Juniper Networks device is important. This route allows for unknown destination addresses to be forwarded to an upstream router. You should add the default route to the virtual router that you are using, most commonly trust-vr.
Default RouteWebUI
Adding a default route in the WebUI is a two-step process. You can add the default route to the routing table by first selecting the correct virtual router, trust-vr, then clicking New. Second, fill out the static route entry. Remember that 0.0.0.0/0 is the network that you want to forward to the default gateway.
Device Administrators
Now that we know how to access the Juniper Networks device (IP address) and which services are available (management services), the next step is configuring who can access the system. The Juniper Networks device ships with a root administrator configured with the default username and password of netscreen. You should always change this parameter in a production environment. (Note: Do not change this in the classroom lab!) The root administrator can create other administrators. These additional administrators can have read/write or read-only access to the system. The root administrator has a few additional privileges over a read/write administrator, including the following: Creating additional administrators; Activating and deactivating asset recovery features; and Replacing configurations from remote devices to flash memory.
A read-only administrator can only view CLI and WebUI information and is limited to get and ping commands. You can create a maximum of 20 administrators on a Juniper Networks device. However, only ten administrators can be logged in simultaneously.
TimeoutConsole
By default, console and Telnet sessions time out after 10 minutes of inactivity. You can modify this parameter or disable it by setting the timeout value to zero. We suggest that you never set the timeout value to zero. To verify the current console timeout, use the get console command: ns208-> get console Console timeout: 120(minute), Page size: 22/22, debug: buffer privilege 250, config has not been changed! ID State Duration Task Type Host 0 Logout 0 2816 Local 2 Login 6190 4928 Local ns208->
TimeoutWebUI
The WebUI timeout, like the console timeout, defaults to 10 minutes. When changing the WebUI timeout, specify a number of minutes (between 1 and 999) of idle time before the browser closes. If you do not want the WebUI to time out, uncheck the Enable Web Management Idle Timeout check box. For class, we recommend that the timeout be set to 60 minutes to keep the WebUI from expiring during lecture time. Other options on this screen include a link to online help. This link defaults to the Juniper Networks Web site; however, if you do not have Internet access, you can change this link to point to a local site where the documentation is stored. You can use the remaining options to further control administrative access to your Juniper Networks device. You can use Security Manager to also adjust the WebUI timeout: SecMgr: Edit Device > Device Admin > Web Management
Permitted IP Addresses
To provide yet another level of security, you can configure the Juniper Networks device to accept management requests only from a select range of device addresses.
Management Operation
All the individual management components shown in the slide work together to provide tight security regarding who can access what services on which interfaces on the Juniper Networks device.
Verifying Connectivity
The slide highlights the topic we discuss next.
Verifying Connectivity
Using the CLI get commands shown on the slide can assist in verifying connectivity.
Verifying AdministratorsCLI
The CLI separates administrator information from SSH information. On the slide you can determine if SSH is enabled and whether PKA keys are created for each administrator.
Verifying AdministratorsWebUI
After you create your administrators, they are added to the list shown on the WebUI. Note that the top half of the screen refers to an external database of administrators. Instead of defining administrators locally, you can use a RADIUS server to define administrators. This method allows you to overcome the limit of 20 administrators. The settings here allow you to determine what access an externally authenticated administrator has to the system. To complete RADIUS configuration, you must set up connectivity to the RADIUS server. You set up this connectivity under the Configuration > Auth > AuthServers menu, or with the command: set auth-server name radius options
Review Questions
1. 2.
Management
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
DNS Configuration
DNS configuration consists of the ability to set three DNS servers as well as setting a refresh schedule to update the resolved address table.
NTP Configuration
Network time servers allow devices on the network to keep their time synchronized with a master time server. Juniper Networks devices are Network Time Protocol (NTP) clients that can synchronize their time to an NTP server. The maximum time adjustment value represents the acceptable time difference between the security device system clock and the time received from an NTP server. The device only adjusts its clock with the NTP server time if the time difference between its clock and the NTP server time is within the maximum time adjustment value that you set. You can also use the WebUI command Sync Clock With Client to update the ScreenOS device.
SNMP Parameters
The Simple Network Management Protocol (SNMP) agent for the Juniper Networks device provides you with a way to view statistical data about the network and the devices on it, and to receive notification of system events of interest. The Juniper Networks device supports SNMPv1 and SNMPv2c. It also supports all relevant MIB II groups. The following is a list of SNMP parameters: Contact: Name of contact; Location: Name of location; Port: Listen or trap port number; Community name: Name of the SNMP community; Community version: Version of the SNMP community; Community host: IP address; and Community host trap: IP address.
SNMP Configuration
The device uses the SNMP configuration to send and receive network management information. Configuration consists of setting ports and adding a community.
Syslog Configuration
Syslog is a facility that enables the logging of system events to a single file for later review. A Juniper Networks device can generate syslog messages for system events at predefined severity levels and optionally, for traffic that policies permit across a firewall. It sends these messages using UDP or TCP (port 514) to up to four designated syslog hosts. The severity level of an event determines whether the event is communicated in a syslog message. By default, syslog is disabled even if servers are configured, so be sure you issue the enable command or click the check box to turn on the service. The source interface parameter determines which interface IP address the device uses for the source of logging messages. You might need to set this parameter if you connect to your syslog server through a VPN; the source interface will be an interface in your trusted zone.
After you enter the information, the LMS displays the license keys for your system. You can then cut and paste the keys to your device.
File Management
The Juniper Networks device relies on two files for proper operation: the ScreenOS image binary, and a configuration file. By default, these files are loaded into RAM from flash memory at system startup. Because flash storage space is limited, additional file storage options are available. All devices have a TFTP-client feature in the ScreenOS software that allows the transfer of files to and from an external TFTP server. Mid-range and high-end systems have some form of additional local storage, either PCMCIA or compact flash, depending on the device. The WebUI also allows use of the local management stations hard drive for file storage.
Configuration Rollback
Configuration rollback is a feature in ScreenOS software. It allows for a second backup configuration file to be stored in flash memory. At system restart, the system checks a retry counter. If the counter is set to zero, the system tries to load the primary configuration file. If the loading fails, the system increments the counter. If the counter is set to any value other than zero, the system attempts to load the last known good (LKG) configuration file. As soon as any configuration is successfully loaded, the counter is reset to zero.
Rollback Commands
If at any time you want the system to boot from the LKG file, you can use the exec config rollback command to reset the system using the LKG file. Caution: If sufficient flash memory does not exist to support both configuration files, the system does not create the LKG file. The system instead displays an error message.
Upgrade ExampleCLI
When performing an upgrade via the CLI, the file transfer process displays an exclamation point (!) for every segment successfully transferred. The system then performs a checksum against the file to ensure successful transfer. Once the file is validated, it is written to flash memory. To load the file from flash memory into RAM, reset the system.
Upgrade ExampleWebUI
Upgrading from the WebUI involves selecting a file, then leaving the system alone to transfer the file, validate it, then reset. To verify that the upgrade is successful, reconnect to the Juniper Networks device and check the software version.
Recovery
The slide highlights the topic we discuss next.
Disaster Recovery
Although not a common occurrence, sometimes events happen that require drastic actions to recover from an electronic mishap. Some examples of these events include the following: A corrupted flash image that prevents a device from booting correctly; Loss of the root-level password; and A device so badly misconfigured that it is simpler to erase the configuration and start over.
Fortunately, Juniper Networks devices have features that allow you to handle these mishaps in an efficient manner. You can overwrite a corrupted ScreenOS image in flash memory with an image from a TFTP server by using a special boot mode. This procedure involves interrupting the normal boot sequence and initiating a file transfer from a local TFTP server. You can overcome the loss of the root password, but the results of the process are very destructive; the configuration in flash memory is completely erased so as to prevent theft of the configuration through this process. Therefore, we highly recommend storing backups of your configuration on external devices. When a device configuration is so messed up that the unit fails to operate, sometimes the only logical action is to clear the configuration and start anew. Again, having a backup copy of a valid device configuration on a server can make the recovery almost painless.
Once you enter the information, the data transfer from the TFTP server begins. See the following page for more information about this process.
Review Questions
1. 2.
The difference between Network Address Translation (NAT) and route interface modes; Configuring interfaces for NAT or route mode; and Verifying operation.
Static Routes
You manually configure a static route. The route includes the destination network, the interface used to reach that network, and the address of the next-hop router in the path to the destination. Note that even if the destination network is several hops away, the next-hop router is always on the same subnet as the firewall. The next-hop router, in turn, will have the same type of forwarding information, handing the packet to the next router in line until the destination network is reached.
Default Routes
Literally millions of networks and subnets are connected via the Internet. Configuring a detailed static route to each of them is an impossible task. Instead, define a special static route called a default route, a route to network 0.0.0.0/0. This route acts as a none-of-the-above entry in the forwarding tableif the destination network is not in the forwarding table, send the packet to this specific next hop. The next-hop router might have more detailed informationor it might have its own default route pointing to yet another router. The ScreenOS software searches a routing table from the most specific to the least specific route. The default gateway is the least specific route.
Virtual RoutersOne VR
Thus far, we have looked at the Juniper Networks firewall as a single router. All networksboth private and publicare included in the local routing table. This setup might suit a smaller environment using static routing, but in larger networks using dynamic routing protocols, this setup requires complex routing configurations to hide the private addresses from outside and unsecured networks.
The overlapping address capability is particularly useful in remote office or corporate merger situations where private addressing might be used on both sides of the firewall.
Dynamic routing
The Juniper Networks device supports several dynamic routing protocols, such as RIP, OSPF, and BGP. RIP is one of the basic dynamic routing protocols supported. The OSPF is an interior gateway protocol (IGP) used for routing within a single autonomous system (AS). The BGP is a routing protocol used for communication between ASs on the Internet.
Configuring Layer 3
The slide highlights the topic we discuss next.
Case Study
We use the case study shown on the slide to demonstrate how you can configure Layer 3 networks on a Juniper Networks device.
Verifying Layer 3
The slide highlights the topic we discuss next.
Routing Interdependencies
When relying on static routes for your configuration, remember that IP sessions are bidirectional. Even if a packet makes it all the way from the source and session initiator to the destination, if the routers cannot send the reply back to the source, communication will fail.
Debug Utility
The debug utility is a powerful troubleshooting tool that allows you to track the flow of a packet or events in a Juniper Networks device. The debug capability is supported for many functions; a partial list is shown on the slide. (Obtain a complete list using the debug ? command.) By default, the device sends the output to the debug buffer. One of the most helpful debug commands is debug flow basic. This command provides output that tracks the sequence of events that occurs as the Juniper Networks device processes a packet.
Debug Buffer
The debug buffer is memory that is set aside for collecting output from the debug and snoop utilities. You can examine the size of the debug buffer, and if necessary, make changes to the buffer size. To work with the buffer, first clear the debug buffer with the command clear dbuf. Then perform a test operation, such as ping. Finally, analyze the contents of the debug buffer using the get dbuf stream command.
The device performs a policy lookup. The device checks for an existing ARP cache entry. The device creates the session and forwards the packet.
Debug Procedure
The effective use of debug follows a specific process: 1. 2. 3. Get the output of ffilter to check for existing debug filters. Set some flow filters on the debug data stream. Enable the debug utility for the desired option. You can enable multiple options but doing so might produce output that is difficult to analyze. In most circumstances it is better to use one option at a time. Clear the debug buffer. The debug buffer displays the oldest information first. Clearing the debug buffer avoids having to search through old output. Issue the ping command (or whatever command is being used to generate traffic). The debug buffer captures the result. Disable debug to terminate output going to the debug buffer. Use get dbuf stream to analyze the output from the debug utility. Check to see if the problem is resolved. Turn off the flow filters if the problem is resolved. If the problem is not resolved, go back to Step 2 and repeat the process until the problem is resolved.
4.
5. 6. 7. 8.
5.
Note that debug output varies from system to system and software version to software version. The key messages appear regardless of version.
No Route to Destination
debug flow basic often provides clear indication of where packet processing failures occur. In the example shown on the slide, the packet is dropped because no route was found in the route table lookup in the trust-vr. If you do not set a default gateway, this error also appears if you try to access the Internet.
Denied by Policy
In the example shown on the slide, the packet is dropped because it was denied by policy. Note that the output indicates that the device searched both a specific policy and a global policy. This output indicates that the packet did not match any particular policy and so was dropped by default. If a policy explicitly denies traffic, the output then shows that either the specific policy or the global policy was responsible for dropping the traffic.
Loopback Interface
The slide highlights the topic we discuss next.
Loopback Interface
A loopback interface is a logical interface that is up as long as one physical interface is up on the device. Use loopback interfaces whenever an always-on IP address is preferred: for management purposes, for VPN termination (VPNs can stay up even if physical interfaces fail if dynamic routing is available), or for dynamic routing purposes.
Interface-Based NAT
The slide highlights the topic we discuss next.
Interface-Based NAT
Interface-based NAT is the simplest form of translation to configure on the Juniper Networks firewall, but it has limited functionality. If your configuration uses one virtual router, consider the following parameters: The ingress interface must belong to the Trust or DMZ zones, and you must configure it for NAT mode (this is the default). The egress interface must belong to the Untrust or DMZ zone.
Interface-based NAT does not work between any pairs of zones other than traffic passing from the Trust zone to Untrust zone. If, for example, the ingress interface is in the Trust zone and is set for NAT mode, and the egress interface is in the Public zone, interface-based NAT will not occur. If your configuration uses two virtual routers, consider the following parameters: The ingress interface must belong to a security zone, and you must configure it for NAT mode. The egress interface must belong to another security zone in the untrust-vr.
Therefore, interface-based NAT works between user-defined zones, but only if the egress zone is assigned to the untrust-vr. If your configuration does not match these parameters, you can use one of the policy-based translation options, which we discuss in a later chapter.
Route Mode
You can configure all interfaces to operate in route mode. The device never translates traffic between route mode interfaces. Full routing is required for all networks. The following three reasons explain why you would place all interfaces in route mode: The firewall is an internal firewall; all addresses are private and do not require translation. All addresses are valid Internet addresses and do not require translation. The network is running applications that are difficult to translate, such as NetBIOS or H.323.
NAT Mode
When an interface is configured in NAT mode, translation takes place only if traffic crosses the right combination of zones and VRs as discussed earlier. When translation occurs, the private source address and port number are replaced in the packet with the outbound public interface address and a dynamically assigned port number. The destination host sends responses to this public address. The Juniper Networks device receives the response and uses the port number to determine which private address/port pair to translate.
Using Translation
In the second example on the slide, both flows are identified as part of the same session, but the source and session originator address is different in each direction. This difference indicates that translation is taking place for this session.
Review Questions
1. 2. 3. 4.
Functionality
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Policy Components
Once you complete your zone and interface configuration, you can begin creating your security policies. As stated earlier, you associate policies with a pair of zones and a traffic direction. This policy set consists of one or more individual policy statements (sometimes called rules or simply policies). Each statement includes a source address, destination address, service (which defines Layer 47 information), and action. We cover additional options for each policy statement in the next chapter.
Policy Configuration
The slide highlights the topic we discuss next.
You can include multiple protocols in a single service definition. For example, the FTP service definition includes both FTP control (port 21) and FTP data (port 20).
Configuration Options
In large networks with complex security requirements, you might encounter this situation: you have ten network managers on five different subnets who must access three different data collection systems. You can create separate policy entries for each combination of network manager and data collection systemor you can use policy options to group the network manager and server entries, creating a single policy statement that includes all addresses. Using groups not only makes administration easier, it also more efficiently allocates system resources. If not using groups, the configuration we described allocates memory for 30 policies (10 administrators x 3 servers = 30 policy entries). Grouped policy statements require fewer system resources.
Address Groups
The address group option allows you to group existing address book entries into a single entry that you can then add to a policy. The following constraints apply to address groups: Address groups can only contain addresses that belong to the same zone. Address names cannot be the same as group names. For example, if you use the name Paris for an individual address entry, you cannot also use it for a group name. If you reference an address group in an access policy, you cannot remove the group. You can edit the group, however. You cannot add the following predefined addresses to groups: Any, All Virtual IPs, and Dial-Up VPN.
Multicell Policies
The multicell policies option allows you to have multiple address book entries, service book entries, or both selected in an individual policy statement. Each entry appears as a separate listing within the policy display.
Common Problems
The slide highlights the topic we discuss next.
Common Problems
The most common problem with policy configuration is incorrect ordering, so completing Step 4 in policy creation (reordering policy entries) is essential. If you do not perform this step at the time of policy creation, you can perform it at a later time using the procedures we just described. Two other common configuration problems relate to the use of names in policy creation. We discuss these problems on the following slides.
Group Membership
Using address and service groups can also introduce confusion when troubleshooting policies. The group names Security Managers and Allowed Services are only helpful if you know what addresses and services they contain. Troubleshooting might involve checking the actual group memberships to ensure that the correct hosts and services are included. Multicell policies avoid the latter problem by displaying individual entries in the window. You still have the names problem, however, as the entries display address book names.
Disabling a Policy
A useful option when troubleshooting policies is the ability to manually disable a policy entry. The policy is still defined in memory, but it is no longer included in the policy evaluation. This feature is useful when troubleshooting ordering problems. If disabling a policy entry has no effect on traffic passing through the firewall, the policy entry is not effective when enabled and must either be moved or redefined.
Global Policy
The slide highlights the topic we discuss next.
Global Zone
You can use the global zone to create default policies. If you have traffic that you always want to permitwhether it is from specific sources, to specific destinations, or to specific servicesyou can create a global policy to allow it The policy checking process first checks for a policy match in the zones determined by the routing lookup. If no match is found, the global zone is checked. If the ScreenOS software finds no match in the global zone, it takes the default action. The normal setting for the default is to deny traffic. You can set the system to default to permitting traffic, but we do not recommend this setting.
Global Policy
We mentioned earlier that a global policy is searched if the ScreenOS software finds no specific zone-to-zone policy definition. The following information further explains the global zone: The get policy global command shows all the set global policies. The default setting is to deny all traffic, as shown on the slide. Next, we defined a global policy. The policy still denies all traffic; the only change is that we made a log entry for the action. (This is a convenient way to log all denys of traffic without having to make an entry in each policy.) When we view the global policy now, we see a policy ID 6 showing the details, including the logging. The debug output shows a ping packet routed from eth1 to eth7. A policy search from zone 1000 to zone 1002 (private to public) finds no policy. ScreenOS software searches the global policy next and drops the packet because of policy ID 6. The packet is logged.
Verifying Policies
The slide highlights the topic we discuss next.
Verifying Policies
We now verify policies using the CLI get commands. Also, we review the debug flow basic learned in the last chapter. The CLI get session command allows you to view the active sessions in the ScreenOS device.
2.
2.
3. 4. 5. 6.
No Policy Configured
Any time network traffic flows from one security zone to another, a policy is required. If no policy is present from zone to zone, look for a global policy, which serves as a default policy for the system.
Intrazone Block
If two (or more) interfaces are in the same zone, no policy is required for packets to travel between these interfaces. However, you can force policy checking to occur. This scenario is illustrated in the following sequence: Intrazone block was enabled for the zone Private. Thus, a policy must be present in packets that go between interfaces in this zone (eth1 and eth2). A packet comes in on eth1. The packet is routed to eth2. Because intrazone block is enabled, ScreenOS software performs a policy search. First, a policy from zone 1000 to zone 1000 (private to private) occurs. Next, a search for a global policy is performed. Because no match exists in the global policy, the packet is dropped due to intrazone block.
The solution to this problem is to configure an exception policy for the zone in question, or to disable intrazone blocking if all traffic should be allowed.
Review Questions
1. 2. 3.
Overview
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Schedule: Allows policy to be automatically enabled or disabled based on a configured schedule. Traffic Shaping: Allows you to reserve bandwidth on a per-policy basis.
Logging
The slide highlights the topic we discuss next.
Traffic Logs
The traffic log shows the time a connection is closed. This log also shows pertinent packet information for each session. You can troubleshoot translation by using traffic logs that check for successful session translation. You can also use traffic logs to verify a policy in general. For example, ask if this policy is logging any sessions. If not, the policy is not matching any traffic. Note that the ScreenOS software only adds log entries after the session closes or times out. To see active sessions, use the get session command on the CLI. Also note that a Juniper Networks device only stores 4096 log entries. For long-term logging, it is better to use syslog.
Counting
The slide highlights the topic we discuss next.
Traffic Counters
Traffic counters display a graphical view of traffic that matches the policy. The X-axis of the graph represents time, and the Y-axis represents the number of bytes. You can modify the X-axis to display in seconds, minutes, hours, days, or months. You can also add alarms to counters by setting traffic thresholds in bytes per second and kilobytes per minute. Traffic exceeding these thresholds causes an alarm to be entered into the system log. Use the CLI to access raw counter data.
Scheduling
The slide highlights the topic we discuss next.
Policy Scheduling
You can use schedules to automatically enable and disable individual policy statements based on the time of day. Schedules are separate objects you apply to policies, and they can be either recurring or one-time events. Because schedules rely on clock settings, we recommend that you use the Network Time Protocol (NTP) to provide an accurate clock feed.
Creating a ScheduleCLI
CLI schedule configuration is straightforward. When you create a recurring schedule, make sure you enter the same name for each day of the week.
Creating a ScheduleWebUI
In the WebUI, a recurring schedule has two periods per day when the policy can be active. If you only want a single period per day, simply leave the second period blank. The schedule name you enter here is displayed in the list of schedules when you configure the policy.
Verifying Scheduling
If a policy is configured with a schedule, the policy line has a gray background in the policy list. If the policy is grayed out, this policy is outside the schedule window. If the policy is not grayed out, the policy is within the schedule window.
User Authentication
The slide highlights the topic we discuss next.
User Authentication
You can configure user authentication on the Juniper Networks device in conjunction with a policy. Even though traffic matches a policy, it does not pass through the firewall until the user is authenticated. Policy authentication is another layer of protection in the network. For example, one of your employees leaves for the day but forgets to log off the system. This computer and all it can access are now available to anyone walking by. However, if no active firewall sessions are present, the evil user must still enter a username and password before the traffic can pass through the firewall. Note the statement active firewall sessions. A users authentication is good for as long as a session remains active on the Juniper Networks device plus 10 minutes. You can change this setting with the following command: set auth-server local timeout minutes
Firewall Authentication
Think of firewall authentication as inline authentication. A user must generate either a Web session, a Telnet session, or an FTP session that matches the authentication policy. The user is then prompted for the username and password. Once authenticated, any traffic the policy permits is allowed through. If the user forgets to authenticate, no traffic is permitted, even traffic that matches the policy. For example, your authentication policy permits ping. An unauthenticated user tries to ping, and even though the addresses and service match, authentication has not occurred; therefore, the firewall drops the traffic. The user then opens a Web browser session through the firewall, authenticates, and tries to ping again. This time the ping is permitted.
WebAuth Authentication
WebAuth is another authentication option that requires your users to actively browse to a specific IP address before their traffic is passed. This IP address is an address on the Juniper Networks device specifically used for authentication purposes. As with firewall authentication, once the user is authenticated using WebAuth, any traffic matching the policy is permitted.
Verifying Authentication
A policy that includes authentication displays a user icon in the WebUI policy list or an X in the A column on the CLI. You can see who is currently logged in with the get user all command, and you can view login statistics with the get auth table command.
Review Questions
1. 2. 3. 4.
Scenarios
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Interface-Based NATReview
As we discussed earlier, interface-based NAT is available on all platforms, but only in limited configurations. In more complex networks needing NAT, policy-based options are available.
Placing the interfaces in route mode and configuring policy-based NAT by using a policy provides you with greater control. When using a policy, you can enable and disable port translation, and the ScreenOS device assigns the translated addresses from a pool of addresses. There are two basic families of policy-based address translationunidirectional and bidirectional. As the names imply, the ScreenOS device applies unidirectional translation only to sessions initiating in the direction of the defined policy. The device applies bidirectional translation to traffic both originating from and sent to a specified private/public address set.
NAT-src
The slide highlights the topic we discuss next.
Dynamic IP Address
Before we move on, we should discuss dynamic IP (DIP) addresses. A DIP address set allows you to configure a range or pool of IP addresses from which the Juniper Networks device can dynamically take addresses to use when performing NAT. You configure DIP address pools on an interface. The range of addresses in a DIP pool must be in the same subnet as an IP address associated with that interfaceeither the interface address, a secondary address on the interface, or an extended address on the interface. The DIP pool cannot conflict with any other addresses, so it should not contain the interface IP address, router IP address, or any other address mapping (for example, MIP or VIP addresses). Consider the following additional DIP address restrictions: Only applied to traffic exiting the interface where the DIP address is configured; Can consist of a single IP address or range of IP addresses; Address range cannot exceed 254 addresses; and System supports 252 DIP address sets across all interfaceseach DIP address set has a unique identifier that must be in the range of 4255.
NAT-src Options
We look at NAT-src first. NAT-src has the following four different configuration options: NAT-src: This functions like interface-based NAT without the zone limitations. The source address is translated to the address of the outbound interface. Port translation ensures that each session is uniquely identified. DIP address pool with port translation: A DIP address is a pool of addresses that can be used for source translation. Address selection is dynamic and done on a round-robin basis. Port translation allows for a large group of private addresses to use a smaller group of public addresses for translation. DIP address pool without port translation: Functions as DIP address pool, but without port translation. If port translation is not used, you should ensure that sufficient public addresses are available. IP address shifting: A one-to-one mapping of a range of private addresses to a range of public addresses. No port translation is performed.
NAT-src Examples
In the first example on the slide, we perform simple NAT-src, translating the source address to the interface address. The port number uniquely identifies the returning flow for translation back to the private address. In the second example, we use a DIP address pool with port translation. The example shows that multiple internal addresses can share a single external address through port translation. In reality, addresses are assigned on a round-robin basis, so the likelihood of these two sources having the same post-translation IP address is based on the size of the DIP address pool. The third example shows a DIP address without port translation. Note that the IP address of the post-translation packet is different, but the port number is the same. Again, remember that this option requires that you have sufficient IP addresses for your outbound connection requirements. The fourth example illustrates IP address shift. DIP address shift is a one-to-one relationship between a group of private and a group of public addresses. You must have the same number of addresses on each side of the translation. The ScreenOS device performs no port translation. Continued on next page.
Choose the source of the DIP address. If you select In the same subnet as the extended IP, configure the extended address and mask for the interface.
Verifying NAT-srcWebUI
You can verify that translation was added to the policy by looking at the action icon in the WebUI. A blue checkmark indicates that translation was added using the advanced policy options. To view translation in action from the WebUI, add logging to your policy. Terminated sessions that match the policy statement are added to the log; the log displays both the pretranslation and post-translation addresses. In the example on the slide, the policy is using a DIP address with port translation enabled. We can determine this configuration because the translated address is different for each session, even though the private source address is the same. Furthermore, the ports are translated. If DIP shifting were used, the private source would always use the same public source address.
NAT-dst
The slide highlights the topic we discuss next.
NAT-dst
You can configure Destination NAT (NAT-dst) in one of four variants: One-to-one mapping maps a single public IP address (as defined in an address book entry) to a single private IP address. Many-to-one mapping translates a group of public addresses (as defined in an address book entry) to a single private IP address. Many-to-many mapping translates a group of public addresses (as defined in an address book entry) to a contiguous range of private IP addresses, using the address-shifting mechanism we discussed earlier in association with DIP addresses. Port mapping allows you to add port translation to NAT-dst configurations.
NAT-dst Examples
The slide illustrates the different types of NAT-dst. Note the port translation that occurs in the last example. This translation is not dynamic port selection; you, the administrator, specify the post-translation port.
NAT-dst Requirements
For NAT-dst to work, the public address must be mapped to the correct internal or private zone. This requirement comes directly out of our packet-handling process; we perform a routing lookup to determine the source and destination zone before we apply a policy. Because translation is policy based, we must have the pretranslation address in the correct zone so that the correct policy can be applied. You can accomplish this correct mapping through either configuring the public address as a secondary address on one of the internal interfaces or by configuring a static route to the public address range with the outbound interface being one of the internal interfaces. Additionally, you must configure the addresses to be translated as address book entries in the internal zone. It is not possible to use any as the pretranslation destination when using NAT-dst.
Verifying NAT-dstCLI
Using the CLI, you can verify that translation was added to the policy. You can also view any currently established sessions and the associated translation with the get session command.
Verifying NAT-dstWebUI
You can verify that translation was added to the policy by looking at the action icon in the WebUI. A blue checkmark indicates that translation was added using the advanced policy options. Unfortunately, the logging feature only captures source translation, so no destination translation is visible using the WebUI.
VIP Addresses
The slide highlights the topic we discuss next.
VIP Addresses
A customer has several internal servers that must accessed from the Internet. The problem is that the customer has purchased one or maybe two IP addresses from its ISP. MIP addresses are not possible because there would need to be a MIP address for every server. A virtual IP (VIP) address maps traffic received at one IP address to another IP address based on the destination port number in the TCP or UDP header. Using the examples on the slide, if an IP packet is received with a destination address of 1.1.8.100 and a destination port of 80, the address is translated to 10.1.30.5. Likewise, a packet received with the same destination IP address, 1.1.8.100, but with a destination port of 21, is translated to 10.1.20.5.
MIP Addresses
The slide highlights the topic we discuss next.
MIP Address
You use a MIP address to define a static one-to-one mapping of a specific private address to a specific public address. The following translation occurs as appropriate: Source translation occurs when traffic is sent from the private host to the public network. Destination translation occurs when traffic arrives from the public network destined for the public address.
No port translation occurs when using a MIP address. Unlike other translation options, the public MIP address can be any legal IP address; it does not have to be associated with the interface on which it is configured. The only requirement is that upstream routers needs a route for the MIP address that directs traffic to the interface where the MIP address is configured.
Description
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Transparent Mode
In this chapter we cover the Layer 2 mode of operation for the Juniper Networks devices: transparent mode. This mode essentially allows you to immediately deploy Juniper Networks firewall and VPN functionality without making changes to the existing network topology. In this mode, the Juniper Networks device behaves as a Layer 2 forwarding device, similar to a bridge or switch.
VLAN1 Interface
The VLAN1 interface is a virtual interface that you can use for management and for terminating VPNs when operating in transparent mode. You can configure this interface with an IP address so that devices connected to an interface in any transparent zone can manage the Juniper Networks device, if permitted. You must configure the VLAN1 interface with an IP address in the same subnet as the other devices connected to the V1 zones. The interface exists in the VLAN zone and can only be accessed using the interfaces in the transparent zones.
Management Operations
In the administration chapter, we discussed the relationships between all the available management settingsmanage-IP, manager-IP, interface settings, and authentication.
Transparent Mode
When operating in transparent mode, the ScreenOS device ignores the management settings of physical interfaces. Instead, you configure management services on a per-zone basis. When configured, all interfaces bound to the zone share the same management access.
Configuration
The slide highlights the topic we discuss next.
When you enable the ARP method, the trace route option is enabled by default. You can also enable the ARP method without the trace route option. However, without trace-route, the Juniper Networks device can only discover the destination MAC address for a unicast packet if the destination IP address is in the same subnet as the ingress IP address. Actually, the trace route returns the IP and MAC addresses of all the routers in the subnet. The Juniper Networks device then matches the destination MAC address from the initial packet with the source MAC address on the arp-r packets to determine which router to target, and consequently, which interface to use to reach that target. Note that of the two methodsflood and ARP/trace routeARP/trace route is more secure because the Juniper Networks device floods ARP queries and trace-route packetsnot the initial packetout all interfaces.
Verifying Operations
The slide highlights the topic we discuss next.
Static Mapping
Although most often the MAC table is automatically updated using the flood or ARP/ trace-route options, you can add a static entry as well using the CLI command: set mac mac_address outgoing_interface
Points to Consider
One of the most common configuration problems is forgetting to add a policy for the new zones added.
Summary
The advantages of transparent mode operation; Transparent mode zones, interfaces, and Layer 3 mode zones; and Using the VLAN1 interface to manage the Juniper Networks device in transparent mode.
Review Questions
1. 2. 3. 4.
Data Encryption
Encryption provides data confidentiality. Encryption is the method of taking user datareferred to as plaintextand converting it into unreadable or secret data called ciphertext. Ciphertext is created by feeding data into an encryption algorithm along with an encryption key (a string of bits that seeds the encryption process). To reverse the process and decrypt the ciphertext, you must know both the encryption algorithm and encryption key. Encrypted data can be decrypted in one of the two following ways: Symmetric key encryption uses the same key for both encryption and decryption. Asymmetric key encryption uses a private key for encryption, and a mathematically related public key for decryption.
The cipher strength depends on the key size; the larger the key, more secure the cipher output. The trade-off is in processing time; larger keys take more computational cycles to encrypt and decrypt.
Digital Integrity
Now that we have the data encrypted as it traverses the Internet, we must ensure that the data is not modified along the way. Even though a novice hacker might not be able to crack the encryption algorithm and key, the hacker could still create havoc by modifying bits being carried in the encrypted payload. If this modification of bits happens, the decrypted output will not match the original data. Who knows what the consequences might be! Hashing solves this problem by creating a fingerprint of the data, similar to a cyclic redundancy check (CRC). Before data is sent out, it is run through a hashing engine that produces a fixed-length hash output. The hash is then placed in a field in the packet along with the data and then sent over the network. The destination takes the same data and runs it through the same hashing algorithm, calculating its own hash. The destination then compares the hash that it calculated against the hash that is carried in the packet. If they are the same, that is verification that the data was not modified in transit. If the hashes do not match, the packet is dropped.
2.
To see how it is possible to create a one-way function, think of the example on the slide, which shows a modulus operation. Given the value of 3, it is not possible to work out what the original value was because an infinite range of possible answers exists. However, this example would not be suitable as a real-world hash function because it does not satisfy the collision-resistant requirementa malicious person could change the plaintext by any multiple of the modulus number and know that the hashed value would still be the same. The most secure hash function that is widely used at present is the SHA-1. SHA-1 is a preferred over MD5, although MD5 is still widely supported. These functions produce a fixed-length output, which is useful when working with IP packets because the overhead of transmitting the hash value is predictable.
Hash Process
The following steps outline the hash process: 1. 2. 3. 4. 5. The sender runs the data through the hash process. The sender appends the hash value to the data and sends both to the receiver. The receiver separates the data and the hash value. The receiver hashes the data. The receiver then compares the calculated hash value to the received hash value. If the hash values match, the data has not been altered.
Source Authentication
Encryption protects the packet contents from being viewed on the public network. Hashing verifies that the data was not altered. But what about validating the source of the data? Source authentication is performed using the Hashed Method Authentication code (HMAC). The sender appends a secret preshared key to the data, then performs the hash function. For the hashes to successfully match, the receiver must append the same key value to the data before performing the hash function. The key itself is never transmitted along with the data.
The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The Diffie-Hellman algorithm is a method whereby two parties can agree upon a secret key that is known only to them. The strength of the technique is that it allows the participants to create the secret value over an unsecured medium without exchanging the secret value itself. It is also impossible to reverse-generate the secret if it is somehow intercepted.
Diffie-Hellman Groups
Diffie and Hellman proposed five groups of prime numbers and generator values to be used in their key exchange algorithm. The group is used to generate unique keys using a combination of exponential and modulus calculations. Juniper Networks ScreenOS devices support Diffie-Hellman (DH) Groups 1, 2, and 5. The larger the prime number, the stronger the keyand the more computationally intensive the calculation. Both tunnel peers must be configured to use the same DH group; otherwise, the key generation process will fail. Continued on next page.
IP Security
This slide highlights the topic we discuss next.
IP Security
IP Security (IPSec) is a set of standards that defines how the encryption, validation, and authentication methods we just discussed are actually implemented in networks. The two protocols defined in the standard are the Encapsulating Security Protocol (ESP) and the Authentication Header (AH) protocol. ESP provides for the confidentiality, integrity, and authentication of data. Through ESP, encryption, hashing, and authentication can all be performed. Instead of having to worry about implementing each of these algorithms separately, you simply implement ESP to oversee these services. AH does not perform any encryption. It only verifies the integrity and authentication of the data.
IPSec Modes
You can implement IPSec in the following two modes: Tunnel mode: This mode is the most commonly implemented method. Tunnel mode is implemented between an IPSec gateways or IPSec gateway and a remote client providing secure access to the networks behind gateway. In this method, the end systems need not be aware of the IPSec protocol suite. All encryption and decryption takes place on the IPSec gateways on behalf of the hosts behind the gateway. Transport mode: This mode is implemented between IPSec end systems. The end systems should be aware of IPSec protocol suite. They do all the encryption and decryption of data.
ESP Auth is the integrity check value (ICV) (that is, the hash value) for this packet.
Authentication Header
The Authentication Header (AH) protocol provides only data integrity, authentication, and antireplay services. AH is identified by IP protocol number 51. It uses MD5 or SHA-1 to provide data integrity services.
The AH trailer contains the ICV (that is, the hash value) for this packet.
Once these attributes are negotiated between the IPSec peers, IKE is used to secure future attribute exchanges used to protect data. IKE exchanges are authenticated using one of the following methods: Preshared keys; Digital signatures; and Public key encryption.
IKE is preferred over manual keys in IPSec implementations because of the ease of management and scalability.
Security Associations
A security association (SA) is a set of policies and key(s) used to protect information. SAs are established upon the successful completion of IKE negotiations. An SA is uniquely identified by SPI value, tunnel destination address, and the security protocol (ESP or AH) being used. The lifetime of an SA can be based either on time or on the volume of traffic that is protected by the proposal.
SA Database
SAs are stored in a security association database. Each entry includes the name of the particular VPN, the remote gateway IP address, the SPIs for each direction, the agreed-upon security protocol, encryption and authentication algorithms, and keys.
Proxy ID
The proxy ID is used to exchange policy rules between two VPN peers. By default, policy checking is enabled on all ScreenOS devices. Thus, the policy that is sent via the proxy ID will be compared to the locally configured policy. It is critical that address book entries match. For example, if ScreenOS device A uses source address 10.1.10.0/24 and destination address 10.1.210.0/24 in the policy statement, ScreenOS device B must use the same address definitions when creating the policy. If ScreenOS device B uses 10.1.210.3/32 instead of the subnet, the policy statements will not match, and the VPN will not be established. Proxy ID mismatches are the most common reasons for VPN establishment failures, so be sure to double-check the proxy ID when doing your configurations.
The first two messages validate the peer configuration (by checking the cookie against the locally configured peer IP address), and negotiate the above parameters. Both tunnel peers must have at least one matching proposal configured for the Phase 1 exchange to be successful. The next two messages exchange Diffie-Hellman public key values and nonces necessary to compute the shared key. The last two messages send simple identification information using the negotiated key; these messages validate that the key was calculated properly. Continued on next page.
For Message 3 and Message 4, the Diffie-Hellman public values are exchanged to create a common session key. Nonces, which are essentially random numbers, are also exchanged at this time to be used as seeds for keys generated later. After both sides have exchanged their Diffie-Hellman public values, a key is created on each side to encrypt the rest of the IKE Phase 1 messages. The session key is a result of the exchanged public keys being sent to each partner. Messages 5 and 6 contain the preshared key, Diffie-Hellman session key, cookies, and nonces are exchanged to verify identity and validate the new session key.
Upon successful completion of quick mode, user data will be encrypted between the configured IPSec peers. Both tunnel peers must have at least one matching proposal configured for the Phase 2 exchange to be successful. The result of Phase 2 is to create an IPSec VPN for user data to be securely transmitted through the network. Continued on next page.
Message 3 is used to acknowledge information sent from quick mode Message 2 so that the Phase 2 tunnel can be established.
Review Questions:
1. 2. 3. 4.
Configuration
This slide lists the topics we cover in this chapter. We discuss the highlighted topic first.
Policy Checking
The policy configuration is also used during the tunnel establishment process. Juniper Networks derives the proxy ID value exchanged during IKE Phase 2 from the policy configuration. These values are compared, and if they do not match, the tunnel is not established.
Verifying Operations
The slide highlights the topic we discuss next.
Troubleshooting Tools
The best tool for troubleshooting VPN setup issues is the system event log. The ScreenOS device captures a summary of IKE communications in this log, and it is easily interpretable. We will look at the event log, plus the commands listed on the slide, in more detail on the next few pages. Remember that VPN problems might not be VPN-specific problems, but because we discussed routing and policy issues in other chapters, we will focus on VPN setup specifically.
Troubleshooting Tools
You can use the system log output to troubleshoot VPN establishment problems. You can access these logs using the WebUI or the CLI; the remaining slides show CLI output.
Review Questions:
1. 2. 3.
Tunnel Interfaces
A tunnel interface is a virtual interface; it has no physical existence. However, it is still an IP interface and needs the same basic configuration as any other interface: zone assignment, interface number (tunnel.x), and IP addressing.
Configuring VPNs
The slide highlights the topic we discuss next.
Verifying Operations
The slide highlights the topic we discuss next.
Troubleshooting Tools
The best tool for troubleshooting VPN setup issues is the system event log. The ScreenOS device captures a summary of IKE communications in this log, and the log is easily interpretable. We will look at the event log, plus the commands listed on the slide, in more detail on the next few pages. Remember that VPN problems might not be VPN-specific problems, but because we discussed routing and policy issues in other chapters, we will focus on VPN setup specifically.
Troubleshooting Tools
Because setting up a tunnel involves two devices, each device receives its own output in the event log. The initiator is the device attempting to bring up the tunnel (that is, the device that sent the first message); the responder is the remote gateway defined at the initiator. For most problems, it is the responder device that reports the actual cause of the problem in the log. In the example on the slide, the responder did not recognize the incoming request as originating with a valid gateway peer. This issue could be caused by one of the following three misconfigurations at the responder: Peer gateway address misconfigured; Peer ID misconfigured; or Outgoing interface is incorrect.
Review Questions:
1. 2. 3.
Hardware
The slide shows the topic we cover in this appendix.