IDP NetScreen-Security Manager Migration Guide

Transcription

1 Intrusion Detection and Prevention IDP NetScreen-Security Manager Migration Guide Release 4.0r3 Juniper Networks, Inc North Mathilda Avenue Sunnyvale, CA USA Part Number: , Rev. C

2 Copyright Notice Copyright 2007 Juniper Networks, Inc. All rights reserved. Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. FCC Statement The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. The equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense. The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with NetScreen s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures: Reorient or relocate the receiving antenna. Increase the separation between the equipment and receiver. Consult the dealer or an experienced radio/tv technician for help. Connect the equipment to an outlet on a circuit different from that to which the receiver is connected. Caution: Changes or modifications to this product could void the user's warranty and authority to operate this device. Disclaimer THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR JUNIPER NETWORKS REPRESENTATIVE FOR A COPY. Writer: Mark Schlagenhauf Editor: Lisa Eldridge 2

3 Table of Contents About This Guide 7 Document Audience...7 Document Conventions...8 IDP Documentation...8 Release Notes...9 Online Help...9 Web Access...9 Providing Feedback...10 Juniper Networks Technical Support...10 Chapter 1 Migration Overview 11 IDP Upgrade Paths...12 About the Migration...12 What Is Migrated...12 What Is Not Migrated...14 Planning and Sizing...16 Chapter 2 Migrating Data and Sensors 19 Migrating Data...19 Migration Requirements...19 Opening Firewall Ports Between NSM and Sensors...20 Out-of-Band Upgrade...20 Migration Procedures...21 Migrating Management Server Data to NSM on a Different Machine...21 Migrating Management Server Data to NSM on the Same Machine...27 Migrating a Management Server Data from a Combo Box (IDP 100)...32 Migrating Sensors...38 Chapter 3 Migrating Logs 39 About Log Migration...39 Stages of Log Migration...40 Migrating the Logs...40 Chapter 4 Upgrading Sensors 43 Sensor Upgrades...43 Sensor Upgrade Paths...43 Chapter 5 Features Overview 45 Administrator Accounts...45 Account Migration...46 Account Differences...46 Table of Contents 3

4 IDP-NetScreen Security Manager Migration Guide RADIUS Support...46 Sensors...46 Sensor Settings...48 Policies and Policy Templates...48 Policies...48 Differences in How Policies Are Handled...49 Similarities in How Policies Are Handled...49 Working with Policies in NSM...50 Policy Templates...51 Severities...51 Objects...52 Network (Address) Objects...52 Service Objects...53 Attack Objects...53 Platforms...53 Hierarchies...53 Other Differences...53 IDP Detector Engine...54 Device Monitor...54 Logs...54 Audit Logs...56 Log Actions...56 Reports...56 Viewing Reports...56 Dashboard...57 Profiler...57 Security Explorer...58 Scheduler...60 Management Server...61 General User Interface...61 Search...61 Job Manager...62 Domains...62 Device Templates...62 Index Table of Contents

5 List of Figures Figure 1: NSM New Device Dialog...47 Figure 2: Sensor Settings in NSM...48 Figure 3: Basic Security Policy...50 Figure 4: Additional IDP Rulebases...50 Figure 5: NetScreen-Security Manager Left Navigation Panel...52 Figure 6: Profiler: Application View...57 Figure 7: Security Explorer: Top Attacks View...59 Figure 8: Security Explorer: Peer IPs View...60 Figure 9: Device Template...62 List of Figures 5

6 IDP-NetScreen-Security Manager Migration Guide 6 List of Figures

7 About This Guide This guide describes procedures for migrating the management of existing IDP Sensors from the IDP Management Server to NetScreen-Security Manager (NSM). This guide contains the following chapters: Chapter 1, Migration Overview, on page 11 Chapter 2, Migrating Data and Sensors, on page 19 Chapter 3, Migrating Logs, on page 39 Chapter 4, Upgrading Sensors, on page 43 Chapter 5, Features Overview, on page 45 NOTE: This guide uses the term Sensor for any IDP 10, 50, 100, 200, 500, 600, 1000, or 1100 appliance. Document Audience This guide is written for IDP Administrators who are migrating to NSM and NSM Administrators that need to migrate an existing IDP installation to NSM. Document Audience 7

8 IDP-NetScreen-Security Manager Migration Guide Document Conventions Table 1 defines the notice icons used in this guide. Table 1: Notice Icons Icon Meaning Description NOTE: Informational only Indicates important but not critical features or instructions. Caution Alerts you to the risk of data loss or hardware damage. Warning Alerts you to the risk of personal injury. IDP Documentation The IDP document set includes the following documents: IDP NetScreen-Security Manager Migration Guide This document. Intrusion Detection and Prevention Concepts & Examples Guide Explains basic concepts of the IDP system and provides examples of how to use the system. Installer s Guide: IDP 50, 200, 600, 1100 Describes the hardware components of the IDP 50, 200, 600, and 1100 Sensors. Provides instructions for rack-mounting, cabling, basic configuration, and management-server and user-interface installation. NetScreen Safety Guide Contains safety warnings and instructions for installing and using network devices. Hardware Guide (650) Contains important safety and compliance information about the IDP 10 (650) Sensor. Hardware Guide (1650) Contains important safety and compliance information about the IDP 100 and 500 (1650) Sensors. Hardware Guide (1750) Contains important safety and compliance information about the IDP 10, 100, 500, and 1000 (1750) Sensors. QuickStart Guide, IDP 3.2 Contains quickstart instructions for the IDP 10, 100, 500, and 1000 systems. QuickStart Guide, IDP 3.2, High Availability Contains quickstart instructions for setting up the IDP 10, 100, 500, and 1000 systems in high availability (HA) mode. NetScreen-Security Manager, which is now used to manage IDP Sensors, comes with its own document set. 8 Document Conventions

9 About This Guide Release Notes Release notes for IDP are available on the Juniper Networks website at The release notes contain the latest information about features, changes, and known and resolved problems. If you find that information in the release notes is different from information in the documentation set, follow the release notes. Online Help Web Access The IDP Appliance Configuration Manager (ACM) contains online help that provides explanations for Sensor-configuration options. All Juniper Networks product documentation is available on our website. To obtain technical documentation for any Juniper Networks product, visit For IDP documentation: For NetScreen-Security Manager documentation: IDP Documentation 9

10 IDP-NetScreen-Security Manager Migration Guide Providing Feedback We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation to better meet your needs. Please contact us at the following address: Please include the following information with your comments: Document name Document part number (located under the Juniper Networks address on the title page) Page number(s) Hardware platform and/or software-release version Juniper Networks Technical Support For technical support, open a support case using the Case Manager link at or call JTAC (within the United States) or (outside the United States). 10 Juniper Networks Technical Support

11 Chapter 1 Migration Overview This chapter covers the migration of IDP Management Server data and logs to a NetScreen-Security Manager (NSM) device server. As part of the process, all Sensors controlled by the IDP Management Server are upgraded to IDP Sensor software version 4.0r3. The migration process includes the following stages: 1. Getting the NSM software and license. Contact Juniper Customer Care at (US and Canada) Select Option 2 for Customer Care (International) Select Option 2 for Customer Care 2. Installing or upgrading to NSM Refer to the NetScreen-Security Manager Installer Guide. 3. Migrating the IDP Management Server and some of the Sensors. CAUTION: Once you have migrated the IDP Management Server data to NSM, you should not use IDP Manager to push new policies to Sensors. Changing the remaining Sensors with IDP Manager after data migration risks introducing errors into the final NSM database. See Migrating Data on page Migrating the rest of the Sensors, if necessary See Migrating Sensors on page Migrating IDP logs See Migrating Logs on page Upgrading unmanaged Sensors to IDP 4.0r3 so that they can be added to NSM See Upgrading Sensors on page

12 IDP-NetScreen-Security Manager Migration Guide IDP Upgrade Paths In order for the upgrade process to succeed, the IDP Management Server and all Sensors must be running the same IDP version. Juniper Networks supports the upgrade paths to IDP 4.0r3 shown in Table 2. CAUTION: If a migration is being performed from 3.2r2, it is recommended to migrate to 4.0r3. Although NSM r2 comes bundled with 4.0r2, it is recommended to change the version to 4.0r3 before continuing with the migration. Instructions for changing the version can be found in the migration procedures. Table 2: Upgrade Paths Existing Version Upgrade Path 3.2r2 Directly to 4.0r3 3.2r4 Directly to 4.0r3 Other versions Upgrade IDP sensors and Management Server to 3.2r2 using supported upgrade paths, then upgrade to 4.0r3. About the Migration Sensor migration is one way only. Once a Sensor s data has been migrated, it cannot be rolled back to IDP Manager. Sensors can be migrated one at a time or in batches. You can migrate some Sensors, then migrate others. Up to five (5) Sensors can be migrated at a time. What Is Migrated The following objects and information are migrated into the target domain in NSM: Sensors Each Sensor is migrated into a device object and an address object. Security policies However, NSM does not support policy versioning, so only the most recent policy version is migrated. If you wish to keep multiple versions of a policy in NSM, use the Save As function to create copies. Logs However, you cannot migrate logs from a Linux machine to a Solaris machine, or vice versa. To keep your logs, you must migrate to the same platform. NSM does not have an export-to-database log action. Use formatted output and script actions instead. 12 IDP Upgrade Paths

13 Packet captures that have been downloaded to the IDP Management Server prior to Sensor upgrade. User-defined services Predefined services are not migrated because they already exist in NetScreen-Security Manager. User-defined attack objects The following attack object components are not migrated: Display name field. The attack object name is used instead. User-defined and user-created attributes. Predefined attack objects are not migrated because they already exist in NSM. If you modify a predefined object, you must change the object s name as well. Attack objects with the same name as a predefined attack object are not migrated. Violation (permitted) objects User-defined reports Custom reports created in IDP admin accounts are migrated to the corresponding admin account in NSM, not to the NSM super account. Profiler configuration Profiler data is not migrated. Log Viewer and Reports user settings Customized Log Viewer and Reports settings configured for IDP admin accounts are migrated to the corresponding admin account in NSM, not to the NSM super account. Global logging settings However, if more than one IDP Management Server is migrated to the same NSM domain, later migrated global settings overwrite earlier migrated global settings. Alarm, SNMP, Syslog, and Global Logging Management Server screen settings Accounts NOTE: Before migration, make sure all IDP Administrators have login names of 62 characters or less. Rename any login names that are longer than 62 characters. Also, Juniper Networks recommends that all passwords have a length of 9-64 characters, which is the NSM standard. Passwords of different lengths will still migrate correctly, however. About the Migration 13

14 IDP-NetScreen-Security Manager Migration Guide All IDP accounts are migrated. IDP superuser admin account migrates to a NetScreen-Security Manager IDP Administrator account. IDP read-write administrator migrates to a NetScreen-Security Manager IDP Administrator account. IDP read-only administrator migrates to a NetScreen-Security Manager Read-Only IDP Administrator account. Account passwords migrate with the accounts. Log Investigator settings User-defined Log Viewer views Custom log views created in IDP admin accounts are migrated to the corresponding admin account in NSM, not to the NSM super account. High-Availability (HA) cluster information NetScreen-Security Manager clusters may only contain two devices. Before migrating, you must divide all larger clusters into clusters of two. If the migration detects an IDP cluster with more than two Sensors, it will fail. Host/Source Watch Lists Watch lists created in IDP admin accounts are migrated to the corresponding admin account in NSM, not to the NSM super account. IVE One-Time Password (OTP), if configured. If the IVE OTP was not configured, you may get a warning message saying that the password is not found. You can ignore this message. What Is Not Migrated The following objects and information are not migrated: Packet captures that have not been downloaded to the IDP Management Server prior to Sensor upgrade User changes to the contents of predefined services when predefined service names remain the same. If you wish to keep a modified predefined service, rename it. Policy version data Policy versioning is not supported in NSM Sensor settings Sensor settings are configured on the device, not in a policy, in NSM. 14 About the Migration

15 Anti-spoof settings Anti-spoof is supported in NSM via Device Manager > Security Devices > Edit Device. However, the settings in IDP Manager are not migrated to NSM. User-configured anti-spoof settings must be manually reestablished. Default values for anti-spoof settings are automatically recreated in NSM. Profiling data Profiling data becomes obsolete very quickly, so prior data is not migrated. Rerun the Profiler after migration is complete. The Duration and Refresh Interval fields in the Host Watch List and Source Watch List User settings other than Log Viewer and Reports Log Purging, Disk Space Alerts, and Database Export Management Server settings Log Investigator filter settings Log links to policies When you view a log, you can hyperlink to the policy that generated the log. However, migrated logs lose this hyperlink. Logs generated after the migration will still hyperlink to their respective policies. Changes made to predefined log views Scripts for Log Actions Script files are not migrated automatically. Manually copy your scripts to the /usr/netscreen/devsvr/var/scripts/ directory on the NSM device server. If a rule cannot find a referenced script, it produces a validation error. Sensor and Management Server versions Predefined objects and reports These already exist in NetScreen-Security Manager If you have made changes to a predefined attack object that you want to keep, rename the object. IDP Manager used a three-tier hierarchy of attack objects, whereas NetScreen-Security Manager uses a two-tier hierarchy. (Example: In IDP, a particular attack might be in the Critical: Server Attacks group, whereas in NSM it s in the Critical:HTTP group. See Attack Objects on page 53. Management Server utilities About the Migration 15

16 IDP-NetScreen-Security Manager Migration Guide Planning and Sizing This section describes the minimum system requirements for the NetScreen-Security Manager (NSM) server software. Refer to the NetScreen-Security Manager Installer Guide for complete NSM sizing information, including sizing for running the IDP Profiler. Table 3 describes the minimum requirements that must be met for the GUI Server and Device Server on the same machine. Table 3: Minimum System Requirements Management System on Same Server Component Operating system CPU RAM Swap space Storage Network connection Other Minimum Requirements Solaris 8, Solaris 9 operating system Red Hat Enterprise Linux ES 3.0 with Update 5 or 4.0 with Update 1 Red Hat Enterprise Linux AS 3.0 with Update 5 or 4.0 with Update 1 Sun Microsystems UltraSPARC IIi 500 MHz (or higher) OR Linux 1GHz (x86) processor (or higher) 1 GB (or higher); 2GB+ recommended (depending on the number of managed devices and configuration size) 4GB for both GUI server and device server IDE hard disk drive with the following: RPM: 10K minimum; 15K recommended Disk space: 18 GB minimum; 40 GB recommended 100 MBps NIC Ethernet adapter Server must be dedicated to running NetScreen-Security Manager. Table 4 describes the minimum requirements that must be met for the GUI server and device server on separate servers. Table 4: Minimum System Requirements Management System on Separate Servers Component Operating system CPU RAM Swap space Storage Network connection Minimum Requirements Solaris 8, Solaris 9 operating system Red Hat Enterprise Linux ES 3.0 with Update 5 or 4.0 with Update 1 Red Hat Enterprise Linux AS 3.0 with Update 5 or 4.0 with Update 1 NOTE: Both servers must be running the same operating-system version. Sun Microsystems UltraSPARC IIi 500 MHz (or higher) OR Linux 1GHz (x86) processor (or higher) 512 MB (or higher); 1GB (recommended) 2GB for GUI server, 2GB for device server IDE hard disk drive with the following: RPM: 10K minimum; 15K recommended Disk space: 18 GB minimum; 40 GB recommended 100MBps NIC Ethernet adapter 16 Planning and Sizing

17 Component Device connection I/O Other Minimum Requirements bps (minimum) Split backplane (recommended for device server) Each server must be dedicated to running NetScreen-Security Manager. Planning and Sizing 17

18 IDP-NetScreen-Security Manager Migration Guide 18 Planning and Sizing

19 Chapter 2 Migrating Data and Sensors This chapter describes how to migrate Management Server data from IDP to NetScreen-Security Manager (NSM), and how to migrate the management of individual Sensors to NSM. Migrating Data The IDP-NSM data migration process consists of two parts: Copying IDP Management Server data to NSM Upgrading the Sensors to IDP 4.0r3 You do not have to migrate all of your Sensors when you perform the initial Management Server migration. You can migrate the rest of your Sensors at a later time using a different command. However, you should not modify your remaining Sensors in any way after performing the data migration. In particular, you should not push policies to the remaining Sensors after data migration. Data migration migrates data for all Sensors, not just the ones being upgraded in the current batch. Therefore, Sensors that have not been migrated and are not being managed by NSM may show up in certain places in the NSM GUI. Always be aware of which Sensors have and have not been upgraded. Do not, for example, try to use NSM to assign a policy to a Sensor that has not been updated to 4.0. You can migrate up to five Sensors at a time. If a migration is interrupted, try re-running it. If that fails, contact JTAC. Migration Requirements Table 5: Data-Migration Requirements To migrate your data, you need the information shown in Table 5. IDP Requirements IP address of your IDP Management Server machine Admin (root) user ID for the IDP Management Server machine NSM Requirements Running NetScreen-Security Manager Device Server of sufficient capacity. Refer to the NetScreen-Security Manager Installer Guide for sizing information. Domain to receive the migrated Sensors NOTE: This domain can be empty or can already contain devices. Migrating Data 19

20 IDP-NetScreen Security Manager Migration Guide IDP Requirements Password for the admin (root) user ID for the IDP Management Server machine Sensors must have current date set. An incorrect date may prevent Sensor upgrade. MD5 SSH key fingerprint of the IDP Management Server NSM Requirements Login access to the NSM GUI and access to the target domain Opening Firewall Ports Between NSM and Sensors The NetScreen-Security Manager Device Server uses port 7803 to communicate with managed devices. If you have a firewall between NSM and your Sensor, the firewall must allow this traffic. When adding a Sensor to NSM, you can use one of two methods, depending on whether the Sensor is reachable or not. For the Sensor to be reachable, it must have SSH turned on and traffic to port 22 must be allowed by any firewalls. If you do not want to turn on SSH, or if you do not want to allow traffic on port 22 through your firewall, you must use the device unreachable method for adding Sensors. Out-of-Band Upgrade The IDP-NSM migration program also upgrades IDP Sensors to IDP 4.0r3. To do this, the NSM server must download the IDP 4.0r3 installation script to each Sensor. When it upgrades a Sensor, NSM pushes the IDP software installation file over your network to the Sensor. If you are concerned about bandwidth to your Sensors, you can upgrade your Sensors manually. The migration scripts check each Sensor to determine what software it runs. If the IDP software is up to date, the migration script skips the IDP download and proceeds with the rest of the migration process. To use the out-of-band upgrade method with one of the procedures listed under Migration Procedures, do the following: 1. Follow the steps in the procedure to migrate the IDP Management Server data to NSM, but do not migrate the Sensor. 2. Upgrade the Sensors to 4.0r3 using the out-of-band method described in Upgrading Sensors on page Complete the rest of the migration steps See the rest of this chapter for migration instructions. See Upgrading Sensors on page 43 for out-of-band Sensor upgrade instructions. 20 Opening Firewall Ports Between NSM and Sensors

21 CAUTION: Once you have upgraded a Sensor to IDP 4.0r3, you can no longer manage it with the IDP Management Server. Make sure you are ready to migrate to NSM before upgrading any Sensors to IDP 4.0r3. Do not attempt an out-of-band upgrade on a combo box until you have migrated the IDP Management Server on that box. Migration Procedures This section describes the following procedures: Migrating Management Server Data to NSM on a Different Machine Migrating Management Server Data to NSM on the Same Machine on page 27 Migrating a Management Server Data from a Combo Box (IDP 100) on page 32 Migrating Management Server Data to NSM on a Different Machine CAUTION: Once you have migrated the IDP Management Server data, you should not push new policies to any remaining Sensors. Changing the remaining Sensors after data migration risks introducing errors into the final NSM database. This procedure describes how to migrate IDP Management Server data from a standalone management server to a NetScreen-Security Manager server that is running on a different machine. This is the simplest migration procedure. It does not cover migrating from a combo box. For combo box migrations, see Migrating a Management Server Data from a Combo Box (IDP 100) on page 32. If you want to migrate in place, with NSM running on the same machine that used to run the IDP Management Server, see Migrating Management Server Data to NSM on the Same Machine on page 27. To migrate your IDP Management Server to NSM: 1. In IDP Manager, update your IDP attack objects and push final policies. 2. Download any Sensor packet captures you want to keep. Use the downloadpackets utility found on the IDP Management Server in the /usr/idp/mgt-svr/utils directory. Syntax: downloadpackets yyyymmdd This command downloads packets for one day. To download packets for multiple days, put the command in a script. 3. If you have made changes to any predefined attack objects or service objects, rename them. Migration Procedures 21

22 IDP-NetScreen Security Manager Migration Guide The migration script does not migrate predefined objects, because they already exist in NSM. Therefore, if you want to migrate a predefined object that you have modified, you must name it something other than its original name. 4. In the IDP UI, select File > Save All to save any changes to custom objects. 5. If you already have an NSM installation, back up your NetScreen-Security Manager data. CAUTION: The migration process is one way and has no recovery mode. If something goes wrong, the only way to recover your NSM database is to restore the database backups. Back up your NSM databases before migrating. The migration does not modify the IDP database, so you do not have to back up your IDP data before performing the migration. Refer to the information about maintaining NSM in the NetScreen-Security Manager Installer Guide for instructions on backing up your data and logs. a. Stop the HA server, the Device Server, and then the GUI Server. b. Use the ls -al command to discover the actual paths of the GUI Server and Device Server data directories: Syntax: ls -al /usr/netscreen/guisvr/var Output: lrwxrwxrwx 1 root root 21 Feb 25 16:04 /usr/netscreen/guisvr var -> /var/netscreen/guisvr The output above indicates that the actual location of the GUI Server data is the /var/netscreen/guisvr directory. Verify where your data is stored and which directories should be backed up on your own system. Enter ls -al /usr/netscreen/devsvr/var to determine the location of your data on the Device Server. c. Run the appropriate backup command on your Solaris or Linux platform to backup the GUI Server data. For example, you can do so by running the following command: tar -cvf /netscreen_backup/db-data.tar /var/netscreen/guisvr gzip db-data.tar NOTE: Using tar may not be appropriate for very large sets of log data on the Device Server. d. Run the appropriate backup command on your Solaris or Linux platform to back up the Device Server data. We recommend Secure Copy (scp) for backing up the Device Server data. 22 Migration Procedures

23 For example, you can use scp by running the following command: scp -r local directory e. Relocate backup copies of both the GUI Server configuration data and the Device Server log data to an external location or disk. f. Restart the GUI Server, the Device Server, then the HA server. g. In IDP, confirm that all of the Sensors displayed are valid devices. If some Sensors have been physically removed, remove them from the IDP Management Server. 6. Upgrade to NSM management server version , or install the software if you do not have an existing installation. Refer to the NetScreen-Security Manager Installer Guide for instructions on installing or upgrading your NSM server. 7. Download the IDP 4.0r3 Sensor software and replace the existing sensor file in NSM. a. Download the IDP 4.0r3 Sensor software from the Juniper Networks support site (sensor_4_0r3.sh). b. Rename the file to agent_4_0_r3.sh. mv sensor_4_0r3.sh agent_4_0r3.sh c. gzip the file to produce agent_4_0r3.sh.gz. gzip agent_4_0r3.sh d. Remove the earlier sensor file from /usr/netscreen/devsvr/var/firmware on the NSM Device Server. rm /usr/netscreen/devsvr/var/firmware/agent_idp_4.0_linux_x86_rpm_opt.sh.gz e. Copy the new file agent_4_0r3.sh.gz to /usr/netscreen/devsvr/var/firmware. cp agent_4_0r3.sh.gz /usr/netscreen/devsvr/var/firmware/. 8. If the IDP Management Server is still running, stop the process by running the following command on the IDP Management Server machine: /usr/idp/mgt-svr/bin/mgtsvr.sh stop 9. Modify the IDP Management Server so that it may be accessed by NSM. a. SSH to your IDP Management Server. b. Open the file /etc/ssh/sshd_config for edit. c. Change the value of PermitRootLogin from no to yes. Migration Procedures 23

24 IDP-NetScreen Security Manager Migration Guide d. Remove the # character from the beginning of the line #Subsystem sftp /usr/libexec/openssh/sftp-server so that it reads Subsystem sftp /usr/libexec/openssh/sftp-server e. Save the file. f. Restart SSH. /etc/rc.d/init.d/sshd restart 10. Change the permissions of the /var directory to rwxrwxrwx using the following procedure: a. Stop all NSM processes. sh /usr/netscreen/guisvr/bin/guisvr.sh stop sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 777 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status The migration script needs to write to this directory. You ll be able to change the permissions back after the migration. 11. Start the NSM UI. 12. Update your NSM attack objects. Select Tools > View / Update NSM Attack Database, then follow the wizard. 13. Use the pull-down menu in the upper left to select the domain into which you want to migrate the IDP Management Server data. 24 Migration Procedures

25 14. Select Tools > IDP Migration > Migrate an IDP Manager. An information screen appears, reminding you to back up your NSM database before migrating an IDP server. 15. If the data has been backed up, click Next. An information screen appears, reminding you to have the IDP Management Server s IP address and login information ready. 16. If you have all the data ready, click Next. 17. Enter the following data in the appropriate fields: IDP Management Server IP address IDP Management Server admin (root) user ID IDP Management Server admin (root) password NetScreen-Security Manager domain that will receive the migrated data 18. Click Next. 19. Verify the SSH key fingerprint of the IDP Management Server. 20. Click Next. An information screen appears, showing you the version of the IDP Management Server and the number of Sensors it manages. 21. Click Next. 22. Select the checkboxes of the five (or less) IDP Sensors you want to migrate at this time. For each selected Sensor, populate any empty access information fields (IP address, password, and SSH version). NOTE: Migrating five Sensors should take about 20 minutes. Migrating one Sensor still takes about 10 minutes because of the time it takes to download the new software to the Sensor. You can migrate some Sensors now and the rest later. To migrate Sensors later, see Migrating Sensors on page Click Next. A confirmation screen appears. 24. Verify the displayed information, then click Next. Migration Procedures 25

26 IDP-NetScreen Security Manager Migration Guide Migration begins. The migration software checks each Sensor to see if it has been upgraded to 4.0r3. If not, it downloads the IDP 4.0r3 software and upgrades each Sensor. This process can take some time, perhaps 20 minutes or more for five Sensors. The process then copies data for each selected Sensor to the NSM database. When the migration process is complete, a confirmation screen appears, indicating which Sensors were migrated successfully, which Sensors had problems, and which Sensors were not selected for migration. Make a note of any error messages. Any Sensor that is not successfully migrated will be rolled back to its prior state. You can then migrate that Sensor again using the procedure Migrating Sensors on page Click Finish. 26. Change the permissions of the /var directory to rwxr-xr-x using the following procedure: a. Stop all NSM processes. sh /usr/netscreen/guisvr/bin/guisvr.sh stop sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 755 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status 27. If there are still some Sensors being managed by the IDP Management Server, restart the IDP Management Server by using the following command: /usr/idp/mgt-svr/bin/mgtsvr.sh start Migrated Sensors will still appear in the IDP Management Server UI, even though they can no longer be managed by IDP. This is because the migration process merely copies the IDP Management Server data; it does not modify it. 26 Migration Procedures

27 28. When you have finished migrating all your Sensors, change the value of PermitRootLogin in the file /etc/ssh/sshd_config back to no. 29. Right-click the sensor and select Import device. You need to import all migrated sensors. 30. After completing the migration process you must perform the policy update from within NSM. Migrating Management Server Data to NSM on the Same Machine This procedure describes how to migrate IDP Management Server data to NetScreen-Security Manager running on the same machine. CAUTION: You can install the NSM management server on the same machine as the IDP Management Server. However, if the server is a Red Hat server, you cannot run the IDP Management Server once you have upgraded the operating system to support NSM. Be sure you have finished using the IDP Management Server before upgrading the Red Hat operating system, as the IDP Management Server is unsupported on the versions of Red Hat necessary to run NSM. This restriction does not apply to the Solaris platform. WARNING: Installing Red Hat ES or AS 3.0 or 4.0 with the default settings will erase your IDP Management Server hard drive. Instead, Disk Druid to set each partition s file system options to Leave Unchanged. Also, set Format? to DO NOT FORMAT. Use the GRUB Boot Loader. All other settings can be used as default. For more information, ask JTAC for the Tech Note called Upgrading Linux Red Hat 8/9 for NetScreen-Security Manager To migrate your IDP Management Server to NSM on the same machine: 1. In IDP Manager, update your IDP attack objects and push final policies. 2. Download any Sensor packet captures you want to keep. Use the downloadpackets utility on the IDP Management Server in the /usr/idp/mgt-svr/utils directory. Syntax: downloadpackets yyyymmdd This command downloads packets for one day. To download packets for multiple days, put the command in a script. 3. If you have made changes to any predefined objects, rename them. The migration script does not migrate predefined objects, because they already exists in NSM. Therefore, if you want to migrate a predefined object that you have modified, you must name it something other than its original name. Migration Procedures 27

28 IDP-NetScreen Security Manager Migration Guide 4. In the IDP UI, select File > Save All to save any changes to custom objects. 5. Shut down the IDP Management Server. /usr/idp/mgt-svr/bin/mgtsvr.sh stop 6. If your IDP Management Server is running on Solaris, skip to step If you are installing NSM on the same Red Hat server as the IDP Management Server, perform the following steps to install Red Hat ES or AS 3.0 or 4.0: NOTE: These instructions do not apply to versions running on Solaris servers. a. If the IDP Management Server is still running, stop the process with the following command: /usr/idp/mgt-svr/bin/mgtsvr.sh stop b. Insert the Red Hat installation CD. c. Restart the system. d. Type the following at the boot prompt: linux text e. Enter the following when prompted: Check the CD Image: Select Skip (only if you know that the CD image is working fine) Language Selection: English Keyboard Selection: us Mouse Selection: Default (Generic Wheel Mouse (PS/2) or the respective mouse on your system Disk partitioning setup: Disk Druid Partitioning Information - Edit each individual partition. Note that the last mounted partition appears in a new window. Mount the partition as the same, then select the "File system Option" as "Leave Unchanged" Format? DO NOT FORMAT Select OK to exit partitioning screen Swap needs to be formatted: YES Boot Loader Configuration: GRUB Boot Loader All the other options are default or you can use environment-specific settings. 28 Migration Procedures

29 f. Follow the wizard and provide all other necessary information to complete the installation. g. Install the necessary system update (Update 1 for AS/ES 4.0, update 5 for AS/ES 3.0). 8. Modify the IDP Management Server so that it may be accessed by NSM. a. SSH to your IDP Management Server. b. Open the file /etc/ssh/sshd_config for edit. c. Change the value of PermitRootLogin from no to yes. d. Remove the # character from the beginning of the line #Subsystem sftp /usr/libexec/openssh/sftp-server so that it reads Subsystem sftp /usr/libexec/openssh/sftp-server e. Save the file. f. Restart SSH. /etc/rc.d/init.d/sshd restart 9. Install NSM Refer to the NetScreen-Security Manager Installer Guide. 10. Change the permissions of the /var directory to rwxrwxrwx using the following procedure: a. Stop all NSM processes. sh /usr/netscreen/guisvr/bin/guisvr.sh stop sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 777 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start Migration Procedures 29

30 IDP-NetScreen Security Manager Migration Guide sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status The migration script needs to write to this directory. You ll be able to change the permissions back after the migration. 11. Start the NSM UI. 12. Update your NSM attack objects. Select Tools > View / Update NSM Attack Database, then follow the wizard. 13. Download the IDP 4.0r3 Sensor software and replace the existing sensor file in NSM. a. Download the IDP 4.0r3 Sensor software from the Juniper Networks support site (sensor_4_0r3.sh). b. Rename the file to agent_4_0_r3.sh. mv sensor_4_0r3.sh agent_4_0r3.sh c. gzip the file to produce agent_4_0r3.sh.gz. gzip agent_4_0r3.sh d. Remove the earlier sensor file from /usr/netscreen/devsvr/var/firmware on the NSM Device Server. rm /usr/netscreen/devsvr/var/firmware/agent_idp_4.0_linux_x86_rpm_opt.sh.gz e. Copy the new file agent_4_0r3.sh.gz to /usr/netscreen/devsvr/var/firmware. cp agent_4_0r3.sh.gz /usr/netscreen/devsvr/var/firmware/. 14. Use the pull-down menu in the upper left to select the domain into which you want to migrate the IDP Management Server data. 15. Select Tools > IDP Migration > Migrate an IDP Manager. An information screen appears, reminding you to back up your NSM database before migrating an IDP server. 16. If the data has been backed up, click Next. An information screen appears, reminding you to have the IDP Management Server s IP address and login information ready. 17. If you have all the data ready, click Next. 18. Enter the following data in the appropriate fields: 30 Migration Procedures

31 IDP Management Server IP address IDP Management Server admin (root) user ID IDP Management Server admin (root) password NetScreen-Security Manager domain that will receive the migrated data 19. Click Next. 20. Verify the SSH key fingerprint of the IDP Management Server. 21. Click Next. An information screen appears, telling you the version of the IDP Management Server and the number of Sensors it manages. 22. Click Next. 23. Select the checkboxes of the five (or less) IDP Sensors you want to migrate at this time. For each selected Sensor, populate any empty access information fields (IP address, password, and SSH version). NOTE: Migrating five Sensors should take about 20 minutes. Migrating one Sensor still takes about 10 minutes because of the time it takes to download the new software to the Sensor, unless you have upgraded the Sensor manually to IDP 4.0r3. You can migrate some Sensors now and the rest later. However, you cannot run IDP Manager again, so you cannot monitor the remaining Sensors. To migrate Sensors later, see Migrating Sensors on page Click Next. A confirmation screen appears. 25. Verify the displayed information, then click Next. Migration begins. The migration software checks each Sensor to see if it has been upgraded to 4.0r3. If not, it downloads the IDP 4.0r3 software and upgrades each Sensor. This process can take some time, perhaps 20 minutes or more for five Sensors. When the process is complete, a confirmation screen appears, indicating which Sensors were migrated successfully, which Sensors had problems, and which Sensors were not selected for migration. Make a note of any error messages. 26. Click Finish. 27. Change the permissions of the /var directory to rwxr-xr-x using the following procedure: a. Stop all NSM processes. Migration Procedures 31

32 IDP-NetScreen Security Manager Migration Guide sh /usr/netscreen/guisvr/bin/guisvr.sh stop sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 755 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status 28. Change the value of PermitRootLogin in the file /etc/ssh/sshd_config back to no. 29. Right-click the sensor and select Import device. You need to import all migrated sensors. 30. After completing the migration process you must perform the policy update from within NSM. Migrating a Management Server Data from a Combo Box (IDP 100) CAUTION: Once you have migrated the IDP Management Server data, you should not push new policies to any remaining Sensors. Changing the remaining Sensors after data migration risks introducing errors into the final NSM database. This procedure describes how to migrate IDP Management Server data from a combo box to NetScreen-Security Manager. Migrating from a combo box (an IDP 100 running the IDP Management Server on the Sensor) is supported, but NSM must be installed on another machine. You cannot install NSM on the IDP 100. To migrate your IDP Management Server combo box to NSM: 1. In IDP Manager, update your IDP attack objects and push final policies. 2. Download any Sensor packet captures you want to keep. Use the downloadpackets utility found on the IDP Management Server in the /usr/idp/mgt-svr/utils directory. Syntax: downloadpackets yyyymmdd 32 Migration Procedures

33 This command downloads packets for one day. To download packets for multiple days, put the command in a script. 3. If you have made changes to any predefined objects, rename them. The migration script does not migrate predefined objects, because they already exist in NSM. Therefore, if you want to migrate a predefined object that you have modified, you must name it something other than its original name. 4. In the IDP UI, select File > Save All to save any changes to custom objects. 5. If you already have an NSM installation, back up your NetScreen-Security Manager data. CAUTION: The migration process is one way and has no recovery mode. If something goes wrong, the only way to recover your NSM database is to restore the database backups. Please back up your databases before migrating. The migration does not modify the IDP database, so your normal IDP backups are sufficient. For instructions on backing up your data and logs, refer to the information on maintaining NSM in the NetScreen-Security Manager Installer Guide. a. Stop the HA server, the Device Server, and then the GUI Server. b. Use the ls -al command to discover the actual paths of the GUI Server and Device Server data directories. Syntax: ls -al /usr/netscreen/guisvr/var System output: lrwxrwxrwx 1 root root 21 Feb 25 16:04 /usr/netscreen/guisvr var -> /var/netscreen/guisvr The output above indicates that the actual location of the GUI Server data is in: /var/netscreen/guisvr Verify where your data is stored and which directories should be backed up on your own system. Follow the same procedure to determine the location of your data on the Device Server. c. Run the appropriate backup command on your Solaris or Linux platform to backup the GUI Server data. For example, you can do so by running the following command: tar -cvf /netscreen_backup/db-data.tar /var/netscreen/guisvr gzip db-data.tar NOTE: Using tar may not be appropriate for log data in the Device Server that may be very large. Migration Procedures 33

34 IDP-NetScreen Security Manager Migration Guide d. Run the appropriate backup command on your Solaris or Linux platform to back up the Device Server data. It is recommended that you use Secure Copy to back up the Device Server data. For example, you can use scp by running the following command: scp -r local directory e. Relocate backup copies of both the GUI Server configuration data and Device Server log data to an external location or disk. f. Restart the GUI Server, the Device Server, then the HA server. g. In IDP, confirm that all of the Sensors displayed are valid devices. If some Sensors have been physically removed, remove them from the IDP Management Server. 6. Upgrade to NSM management server version , or install the software if you do not have an existing installation. Refer to the NetScreen-Security Manager Installer Guide for instructions on installing or upgrading your NSM server. 7. If the IDP Management Server process is still running, stop the process. /usr/idp/mgt-svr/bin/mgtsvr.sh stop 8. Modify the combo box so that it may be accessed by NSM. a. SSH to your IDP 100, or attach to the Console port. b. Open the file /etc/ssh/sshd_config for edit. c. Change the value of PermitRootLogin from no to yes. d. Remove the # character from the beginning of the line #Subsystem sftp /usr/libexec/openssh/sftp-server so that it reads Subsystem sftp /usr/libexec/openssh/sftp-server e. Save the file. f. Restart SSH. /etc/rc.d/init.d/sshd restart 9. Change the permissions of the /var directory to rwxrwxrwx using the following procedure: a. Stop all NSM processes. sh /usr/netscreen/guisvr/bin/guisvr.sh stop 34 Migration Procedures

35 sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 777 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status The migration script needs to write to this directory. You ll be able to change the permissions back after the migration. 10. Start the NSM UI. 11. Update your NSM attack objects. Select Tools > View / Update NSM Attack Database, then follow the wizard. 12. Download the IDP 4.0r3 Sensor software and replace the existing sensor file in NSM. a. Download the IDP 4.0r3 Sensor software from the Juniper Networks support site (sensor_4_0r3.sh). b. Rename the file to agent_4_0_r3.sh. mv sensor_4_0r3.sh agent_4_0r3.sh c. gzip the file to produce agent_4_0r3.sh.gz. gzip agent_4_0r3.sh d. Remove the earlier sensor file from /usr/netscreen/devsvr/var/firmware on the NSM Device Server. rm /usr/netscreen/devsvr/var/firmware/agent_idp_4.0_linux_x86_rpm_opt.sh.gz e. Copy the new file agent_4_0r3.sh.gz to /usr/netscreen/devsvr/var/firmware. cp agent_4_0r3.sh.gz /usr/netscreen/devsvr/var/firmware/. Migration Procedures 35

36 IDP-NetScreen Security Manager Migration Guide 13. Use the pull-down menu in the upper left to select the domain into which you want to migrate the IDP Management Server data. 14. Select Tools > IDP Migration > Migrate an IDP Manager. An information screen appears, reminding you to back up your NSM database before migrating an IDP server. 15. If the data has been backed up, click Next. An information screen appears, reminding you to have the IDP Management Server s IP address and login information ready. 16. If you have all the data ready, click Next. 17. Enter the following data in the appropriate fields: IDP Management Server IP address IDP Management Server admin (root) user ID IDP Management Server admin (root) password NetScreen-Security Manager domain that will receive the migrated data 18. Click Next. 19. Verify the SSH key fingerprint of the IDP Management Server. 20. Click Next. An information screen appears, displaying the version of the IDP Management Server and the number of Sensors it manages. 21. Click Next. 22. Select the checkboxes of the five (or less) IDP Sensors you want to migrate at this time. For each selected Sensor, populate any empty access information fields (IP address, password, and SSH version). NOTE: Migrating five Sensors should take about 20 minutes. Migrating one Sensor still takes about 10 minutes because of the time it takes to download the new software to the Sensor, unless you upgraded the Sensor manually to 4.0r3. You can migrate some Sensors now and the rest later. To migrate Sensors later, see Migrating Sensors on page Click Next. A confirmation screen appears. 24. Verify the displayed information, then click Next. 36 Migration Procedures

37 Migration begins. The migration software checks each Sensor to see if it has been upgraded to 4.0r3. If not, it downloads the IDP 4.0r3 software and upgrades each Sensor. This process can take some time, perhaps 20 minutes or more for five Sensors. The process then copies data for each selected Sensor to the NSM database. When the process is complete, a final screen appears, indicating which Sensors were migrated successfully, which Sensors had problems, and which Sensors were not selected for migration. Make a note of any error messages. 25. Click Finish. 26. Change the permissions of the /var directory to rwxr-xr-x using the following procedure: a. Stop all NSM processes. sh /usr/netscreen/guisvr/bin/guisvr.sh stop sh /usr/netscreen/devsvr/bin/devsvr.sh stop b. Verify that all processes are stopped. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status c. Change the permissions of the /var directory. chmod 755 /var d. Verify that the permissions have been changed. e. Restart the processes. sh /usr/netscreen/guisvr/bin/guisvr.sh start sh /usr/netscreen/devsvr/bin/devsvr.sh start f. Verify that all processes have restarted. sh /usr/netscreen/guisvr/bin/guisvr.sh status sh /usr/netscreen/devsvr/bin/devsvr.sh status 27. If there are still some Sensors being managed by the IDP Management Server, restart the IDP Management Server process. /usr/idp/mgt-svr/bin/mgtsvr.sh start Migrated Sensors still appear in the IDP Management Server UI, even though they can no longer be managed by IDP. This is because the migration process merely copies the IDP Management Server data; it does not modify it. 28. Right-click the sensor and select Import device. You need to import all migrated sensors. 29. After completing the migration process you must perform the policy update from within NSM. Migration Procedures 37

38 IDP-NetScreen Security Manager Migration Guide Migrating Sensors You can migrate some Sensors with the Management Server migration. If you did not migrate all your Sensors with the Management Server migration, use this procedure to migrate additional Sensors. To migrate additional Sensors: 1. In NSM, select Tools > IDP Migration > Migrate IDP Sensor(s). A dialog appears displaying the Sensors that have not yet been migrated. 2. Select the checkboxes of the IDP Sensors you want to migrate at this time. For each selected Sensor, populate any empty access information fields (IP address, password, and SSH version). 3. Click OK. A job-information screen appears. You can leave it showing to watch the migration progress. 4. Right-click the sensor and select Import device. You need to import all migrated sensors. 5. After completing the migration process you must perform the policy update from within NSM. 38 Migration Procedures

39 Chapter 3 Migrating Logs This chapter explains how to migrate the IDP Management Server logs to NetScreen-Security Manager (NSM). You must migrate the IDP Management Server data and all Sensors before migrating any logs. About Log Migration Things to know before migrating your logs: You cannot migrate IDP log data from a Linux machine to a Solaris machine, or vice versa. You can migrate IDP data between the two platforms, however. Before you migrate the logs, migrate all the Sensors on the IDP Management server. See the Migrating Data and Sensors on page 19 for instructions on how to accomplish this task. If you want to keep packets captured by the Sensor (pcaps), you must download them to the IDP Management Server before migrating the Sensor to IDP 4.0r3. Once the Sensor has been upgraded, the packet captures are lost. Any packet captures that have been downloaded to the IDP Management Server are migrated to NSM with their respective log entries during log migration. The IDP Management Server machine must be running and available, but the IDP Management Server software should not be running. Log migration is one way. It cannot be undone. The only way to recover the prior NSM log condition is to restore backups. Log migration cannot migrate logs for the current day, because NSM is using that part of the log database. Either you can wait one day after migrating the last Sensor before migrating the logs, or you can migrate them all on the same day, but you must rerun the log migration script the next day to integrate the last day s logs. IDP log IDs are lost in the migration. Each log entry will receive a new log ID when it is migrated to NSM. Log merging combines the log data so that all logs are in the correct chronological order. Once IDP logs are merged with NSM logs, they are treated as NSM logs. About Log Migration 39

40 IDP-NetScreen-Security Manager Migration Guide Log migration takes place one log day at a time. If the migration process is interrupted, it will pick up again at the beginning of the last day that was being processed. In other words, if the migration is interrupted, you can restart it and not worry about duplicate logs. The migration script does not migrate individual logs that are corrupt and unreadable by the script. Logs for Sensors that have been deleted from IDP Management Server are not migrated. Migrating Sensors does not delete them from IDP Management Server. The log migration script does not validate that the logs being migrated actually belong to the associated IDP Management Server. Be sure you migrate the correct log files for the given IDP Management Server. After finishing the migration, the log migration script restarts the NSM Device Server automatically. Stages of Log Migration The log migration process has two stages. In the first stage, you must make the IDP logs locally available to the NSM Device Server, either by copying the logs over or by mounting the IDP drive to the NSM machine. In the second stage, the integration script interleaves the IDP log entries with the NSM logs. Migrating the Logs To migrate the logs for one IDP Management Server to NSM, do the following steps: 1. Make sure the NSM attack database is up to date. In NSM, select Tools > View / Update NSM Attack Database. 2. Back up NSM logs. Refer to the information about archiving and restoring logs and configuration data in the NetScreen-Security Manager Installer Guide for more information. 3. Make the IDP logs locally available to the NSM Device Server. You can do this by copying the logs to the NSM Device Server, or by mounting the IDP management server drive to the NSM Device Server machine. 4. Open a command prompt window on the NSM Device Server. 5. Make sure the environment variable $NSROOT is set to /usr/netscreen. If is not, set it. (If you installed NSM in a different directory, set $NSROOT to that directory instead.) 6. Change directory to $NSROOT/DevSvr/utils. 7. Run the script. 40 Stages of Log Migration

41 sh importidplogs.sh <IDP Mgt Svr IP> <Local path to copied log files> Runtime logs of this utility are written to $NSROOT/DevSvr/var/errorLog/idplogmigration.* After each day is processed, the original NSM logs for that day are deleted, and the merged logs are moved to $NSROOT/DevSvr/var/logs/<Day Id>. If you have waited a day after migrating the last Sensor to migrate the logs, you will only have to perform this procedure once. However, if you did not wait a day, you will have to rerun the integration script at a later time to migrate the last day of logs, since script cannot integrate the current day s logs. Re-running the script will not re-migrate migrated logs. Migrating the Logs 41

42 IDP-NetScreen-Security Manager Migration Guide 42 Migrating the Logs

43 Chapter 4 Upgrading Sensors This chapter shows you how to upgrade an unmanaged Sensor to IDP 4.0r3 so that it can be managed by NetScreen-Security Manager (NSM). It contains the following sections: Sensor Upgrades Sensor Upgrade Paths Juniper Networks supports the upgrade paths shown here. on page 43 Juniper Networks supports the upgrade paths shown in Table 6. Sensor Upgrades NSM can only manage IDP Sensors running IDP 4.0 or later. After you have migrated your management system to NSM, you purchase a new Sensor that has an earlier version of IDP. Before you can add that device to NSM, you must first upgrade the Sensor software to IDP 4.0r3. Sensor Upgrade Paths Juniper Networks supports the upgrade paths shown here. Table 6: Upgrade Paths Existing Version Upgrade Path 3.2r2 Migrate/upgrade directly to 4.0r3 4.0r1, 4.0r2 Upgrade directly to 4.0r3 Other versions Upgrade to 3.2r2, then migrate to 4.0r3. For upgrades to other versions of IDP, see the Juniper Networks Support website: To replace your existing IDP installation, contact Juniper Networks customer support via the website. Sensor Upgrades 43

44 IDP-NetScreen-Security Manager Migration Guide For technical support, open a support case using the Case Manager link at or call JTAC (within the United States) or (outside the United States). You can perform the upgrade from a local system console (recommended) or use an SSH connection. To upgrade the Sensor software, perform the following steps: 1. Download the IDP 4.0r3 Sensor software from Juniper Networks. 2. Make sure the Sensor has the current date. An incorrect date may cause the upgrade to fail. To set the date, select Reconfigure Date/Time from the ACM home page, then follow the prompts. (Access ACM by navigating your browser to 3. Verify that you have SSH enabled for the management port. To enable SSH, select Modify SSH Access from the ACM home page, then follow the prompts. (You access ACM by navigating your browser to 4. Download the Sensor software from 5. Unplug the HA port cable, if one is attached. 6. Log into the IDP Sensor as root via the Console port. 7. Change the directory to /tmp. 8. From the Sensor, FTP the file to the /tmp directory. NOTE: The Sensor does not run an FTP server, so you must FTP from the Sensor. 9. Make the UI install script executable using the following command: chmod 755 sensor_4_0r3.sh 10. Run the Sensor update script using the following command: sh sensor_4_0r3.sh 11. When the script is finished, reboot the device using the following command: reboot;reboot When you have finished upgrading all the Sensors in the cluster, reconnect the HA cable. At this point, you are ready to add the Sensor to NSM using the procedures in the NetScreen-Security Manager Administrator s Guide. 44 Sensor Upgrade Paths

45 Chapter 5 Features Overview This section describes the following IDP-related functions in NetScreen-Security Manager (NSM): Administrator Accounts on page 45 Sensors on page 46 Sensor Settings on page 48 Policies and Policy Templates on page 48 Severities on page 51 Objects on page 52 Device Monitor on page 54 Logs on page 54 Reports on page 56 Dashboard on page 57 Profiler on page 57 Security Explorer on page 58 Scheduler on page 60 Management Server on page 61 General User Interface on page 61 Administrator Accounts NetScreen-Security Manager has a new account type: IDP Administrator. This account type is designed for administrators who only administer IDP functions. Users logged in as an IDP Administrator see a simplified, IDP-centric NSM interface. Administrator Accounts 45

46 IDP-NetScreen-Security Manager Migration Guide Account Migration All IDP Management Server accounts, including the admin account, migrate to NSM as IDP Administrator -class accounts. Users with read-only access in IDP Management Server have read-only access in NSM. All IDP Management Server accounts migrate to a single domain in NSM. If a particular login ID already exists in that domain, the migration appends _1 to the ID. For example, an account with a login ID of fred will be migrated to NSM as fred_1 if a fred account already exists in that NSM domain. All IDP Management Server accounts must contain 62 characters or less. If any IDP accounts have longer login IDs, rename them before migration. Passwords remain the same. Account Differences In IDP Manager, only one administrator could be active at any given time. In NSM, multiple administrators can modify the system at the same time. However, only one administrator can modify a given object or policy at any one time. NSM locks an object when an administrator opens it and locks a policy when an administrator begins to modify it. You can see who has a particular object locked by viewing logged in admins. Select Tools > Logged in Administrators to see who is logged in, what domain their account was created in, their status, their current IP address, and what object they currently have locked, if any. RADIUS Support NSM supports RADIUS-based user authentication and authorization. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 3: Configuring Role-Based Administration for more information. Sensors In NSM, IDP Sensors are handled the same as other security devices. They are viewed the same way, modified the same way, and updated the same way. To view IDP Sensors and other devices, select Device Manager > Security Devices from the left navigation panel in the NSM GUI. There are three ways to add a Sensor to NSM. To begin any of the three processes, select Device Manager > Security Devices from the left navigation pane, then click the + button. The three processes are as follows: Add a Sensor with a known, reachable IP address. This is the easiest, most straightforward method. NSM logs into the Sensor with the provided information, then downloads the Sensor s configuration to the NSM database. 46 Sensors

47 Add a Sensor with an unreachable IP address. This method creates a set of commands that you run on the Sensor. The Sensor then contacts NSM to initialize communications. Model a Sensor, then add it later. This method creates a virtual Sensor in NSM. You can assign a security policy to the virtual Sensor, configure its Sensor settings and configuration, then apply all those settings to the real Sensor once you install it. Figure 1: NSM New Device Dialog Other things to know about IDP Sensors in NSM: NSM can manage up to 100 IDP Sensors (20 of the Sensors can be running Profiler) along with up to 2000 firewall/vpn devices. NSM clusters can only have two Sensors in them. If you have clusters of more than two Sensors, you must divide your cluster into clusters of two before migration. NSM is able to handle Sensors running different versions of IDP software. Only applies to Sensors running IDP 4.0r1 or higher. In NSM, holding the cursor over a device icon in Device Manager pops up a dialog with information about the device. However, this dialog does not contain the device s IP address. NSM supports device templates. You can set device settings, such as IDP Sensor Settings, in a device template, then push that template to multiple devices. You can push multiple templates to the same device. You can launch a Sensor s ACM from NSM. Right-click the Sensor in Device Manager and select Launch ACM. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 4: Adding Devices for more information on adding devices. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 4: Configuring Devices for more information on configuring devices. Sensors 47

48 IDP-NetScreen-Security Manager Migration Guide Sensor Settings In the IDP Management Server, Sensor settings were handled in policies. In NSM, they are handled in the device dialog. They can be configured individually for Sensors, or they can be configured for multiple Sensors using the Security > IDP SM Settings area of a device template. Sensor settings are not migrated from IDP. To view and set Sensor settings in NSM, do the following: 1. Select Device Manager > Security Devices from the left navigation pane. 2. Double-click on the Sensor you want to edit. 3. Select Sensor Settings from the left navigation pane. The four Sensor Settings tabs are displayed: Figure 2: Sensor Settings in NSM Refer to the Configuring Security section of the NetScreen-Security Manager Administrator s Guide, Chapter 4: Configuring Devices for more information on IDP sensor settings. Policies and Policy Templates Policies Policies are migrated from IDP to NSM during the IDP Management Server data migration process. If a policy name already exists in the NSM domain that receives the migration data, the migration will append _1 to the policy name. For example, a policy named fred will be migrated to NSM as fred_1 if a fred policy already exists in that NSM domain. 48 Sensor Settings

49 NSM, unlike IDP, manages multiple types of devices: firewalls, VPN devices, and IDP devices. However, because some devices contain multiple sets of functions, policies are not segregated. You can push any policy to any device, even if the policy sets values that don t exist on the target device. For example: the ISG family of devices can support both firewall and IDP functions. However, standalone IDP Sensors do not support firewall functions. Nevertheless, you can create a policy that contains both firewall and IDP rulebases, and you can push that policy to both kinds of devices. The standalone IDP Sensor will simply ignore the firewall settings. Policy versioning is not supported in NSM. Instead, use the Save As function to create backup copies of policies. To access security policies in NSM, select Security Policies from the left navigation pane. Differences in How Policies Are Handled This section describes the differences between IDP and NSM policies. The IDP Main rulebase is now called IDP. In Expanded mode, the IDP, Exempt, and Backdoor rulebases include From Zone and To Zone columns, even though these columns have no meaning for standalone IDP. The columns are there to support ISG devices. Packet capture is now restricted to 256 packets before and 256 packets after an event. For policies that have been migrated, the value indicating how many packets are captured before the event has been incremented by one. (If the value was set to 1 in IDP, it is set to 2 in NSM.) In fact, the same number of packets are captured. IDP and NSM just use different methods of counting packets. In IDP, a setting of 0 still captured one packet out of necessity, so the value appears as 1 in NSM. Sensor settings are now handled in the device, not in a the policy. Information previously found in a policy s Sensor Settings tab can be found in NSM under Device Manager > Security Devices. Select and edit a device. In the device dialog, select Sensor Settings. Similarities in How Policies Are Handled The Exception and Backdoor rulebases already exist in NSM. They work the same as they do in IDP. The SYN Protector, Traffic Anomalies, and Network Honeypot rulebases are new in NSM. They work the same as they did in IDP Manager, although they may have minor label changes. For example, in the Network Honeypot rulebase, the Attack IP column is now Source Address, and the IP column is now Destination IP. Policies and Policy Templates 49

50 IDP-NetScreen-Security Manager Migration Guide Working with Policies in NSM To view a policy in NSM: 1. Select Security Policies from the left navigation pane. 2. Double-click a listed policy to bring up the Security Policy window. Figure 3: Basic Security Policy 3. To add additional rules to a rulebase, click the + button in the upper left corner of the window. 4. To add rulebases to a security policy, click the + button in the upper right corner of the window. Figure 4: Additional IDP Rulebases 5. Additional rulebases appear as additional tabs in the Security Policy window, just like in IDP. 50 Policies and Policy Templates

51 Policy Templates IDP policy templates are not migrated from IDP to NSM. Instead, NSM has its own list of templates. These templates are similar to the ones available in IDP, but there are some improvements: By default, NSM templates contain only the firewall and IDP rulebases. The firewall rulebase is there to support ISG devices. Firewall rulebase settings are ignored by standalone IDP devices. Because the other rulebases are normally not needed, they are not included in the templates. Templates have been modified and improved based on customer feedback. Redundancy has been removed, and the templates themselves are now easier to read. The list of available templates has changed slightly. The list is as follows: all_with_logging dmz_services dns_server file_server getting_started web_server all_without_logging (new) idp_default (new) Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 9: Configuring Security Policies for more information Severities IDP and NetScreen-Security Manager both have five levels of severity, but use different labels. The NSM levels are based on Syslog standards. IDP values are mapped to NSM values during the migration. The following table maps IDP severity levels to NSM severity levels. Severities 51

52 IDP-NetScreen-Security Manager Migration Guide Table 7: Severity Level Mappings IDP Critical High Medium Low Info NetScreen-Security Manager Critical Major Minor Warning Info Objects Like IDP, NSM makes use of objects in the GUI. All NSM objects can be found under Object Manager in the left navigation panel. Figure 5: NetScreen-Security Manager Left Navigation Panel Network (Address) Objects IDP Manager host objects and network objects are both called address objects in NSM. IDP Sensors are handled as security devices, not as address objects, in NSM. If you wish to treat an IDP Sensor as a source or target network object in NSM, you must create an address object for it. However, migrated security devices have an accompanying address object created automatically. 52 Objects

53 Service Objects Attack Objects Called service objects in NSM as well. There are two kinds of service objects: Predefined and Custom. Attack objects are functionally similar to the ones in IDP Manager, but with some differences. NSM supports multiple types of IDP-capable devices, and it can support multiple versions of IDP software at the same time. Platforms NSM supports different kinds of IDP platforms. A platform is a version of IDP software running on a type of hardware. (Example: IDP 4.0r3 running on a standalone IDP Sensor is one platform, and ScreenOS IDP1 running on an ISG 2000 is another.) Sometimes, a given attack object is the same on multiple platforms, but other times it has to be somewhat different. As such, an NSM attack object may have more than one entry in the Platform tab. This is different from IDP Manager, where the Management Server supported only one platform. Hierarchies IDP Manager used a three-tiered object hierarchy, whereas NSM uses a two-tiered hierarchy. For example, the attack object Apache Slapper (bugtraq) Worm Probe was in the Critical > HTTP > Apache Server Attacks category in IDP. It s in the Critical > HTTP category in NSM. During migration, all third tier categories are mapped to second tier categories in NSM. As a result, some migrated policies may cover slightly different sets of objects. For example, perhaps you have a policy that covered all HTTP Critical attacks, but with the Cisco Embedded Web Server attacks subcategory deselected. When this policy is migrated to NSM, which has no Cisco Embedded Web Server attacks subcategory, that subcategory would no longer be deselected, as it doesn t exist. The policy would now search for those attack objects. The greater ramification is in the Exempt rulebase. If you had created a rule that exempted Critical Cisco Embedded Web Server attacks, the migration would convert this exception to the next larger category: Critical HTTP attacks. CAUTION: Double-check all your attack object categories in all your policies before pushing new policies to the Sensors from NSM. Make sure the category mapping did not change your coverage. Other Differences If a migrated service object had validation errors, the object itself will not be tagged with the warning icon in the main navigation tree. Only the fields within the object will have the warning icons. In NSM, hovering the cursor over an attack object does not show the object s pattern. Objects 53

54 IDP-NetScreen-Security Manager Migration Guide In NSM, you cannot modify pre-defined attack objects. However, you can save a predefined attack object as a custom attack object (with a different name) and modify that. IDP Detector Engine In prior releases of IDP, attack objects (objects that covered new virus, trojan, and worm signatures) were downloaded and updated on a regular basis. However, protocol anomaly objects (objects that described valid parameters for various protocols) and methods of detection were only updated with new versions of the IDP software. IDP 4.0r3 includes the Detector Engine. Now, when you download attack objects, you also download protocol anomaly objects and methods of detection. You can load the latest protocol anomaly settings whenever you want. To load new protocol anomaly objects, select Devices > IDP Detector Engine > Load IDP Detector Engine, then follow the wizard. Refer to NetScreen-Security Manager Administrator s Guide, Chapter 8: Configuring Objects for more information Device Monitor Host and Source Watch Lists are configured by selecting Tools > Preferences in the Preferences dialog. Select Watch List, then select either Source Watch List or Destination Watch List. The choice list is populated from the address object list in Object Manager. Logs The NSM Log Viewer provides more information about IDP events than IDP Manager. However, some of the fields have different labels. To view logs, select Log Viewer > IDP/DI Logs from the left navigation pane. 54 Device Monitor

55 Table 8: Log Field Mappings IDP Manager NSM UI Notes Log ID Log ID Not migrated. Value generated by NSM. Flag User Flag Device Address Device Different values used. VIN Different values used. Variable Data Var Data Alarm Alert Category Custom or Predefined Different values used in NSM. Attack Subcategory Different values used in NSM. Severity Severity NSM has different labels than IDP. Packet Data Has Packet Data Policy ID Policy Policy Version Not used in NSM Inbound if Src Intf Outbound if Dest Intf Rulebase Rule Number Rule # Misc Details Bytes Bytes Total Packets Packets Total Elapsed Elapsed Secs script, syslog, , SNMP script, syslog, , SNMP, CSV, XML Repeat Count Log suppression count script: Scripts are not migrated syslog: Format is different Similar SNMP: MIB is different. CSV: NSM feature XML: NSM feature Other differences: NSM does not support the View Unused Attacks function. NSM does not support log collapsing. Use Sensor Settings to configure log suppression instead. Backdoor, Traffic Anomalies, Network Honeypot, SYN Protector logs appear in the Traffic log viewer, not the IDP/DI log viewer. Logs 55

56 IDP-NetScreen-Security Manager Migration Guide You can launch Security Explorer from a log view. Right-click and select Launch Security Explorer. NSM has a simpler process for creating exceptions from logs than IDP Manager. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 13: Logging for more information on logs. Audit Logs Log Actions NSM provides audit logs, which IDP did not. These logs are part of Common Criteria compliance. NSM supports the following log action options: script supports the same functionality as IDP, but old scripts must be moved to the NSM system manually. syslog NSM uses a different syslog format than IDP. NSM uses an format that is similar to the one IDP uses. SNMP NSM uses different MIBs than IDP. The NSM MIBs can be found in /usr/netscreen/devsvr/utils/. The two MIB filenames are jnx-nsm-traps.mib and jnx-smi.mib. CSV New in NSM. Outputs the log data to a CSV file. XML New in NSM. Outputs the log data to an XML file. NSM does not support exporting to a Postgres database. Use CSV or XML export instead, then read results into a database with a script. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 9: Configuring Security Policies for more information on setting log actions for policy logs. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 13: Logging for more information setting log actions for domain and audit logs. Reports Custom reports in IDP are migrated to NSM during the Management Server migration phase. However, these reports will only be visible to users logged in with the same login ID as the one used to create the reports in IDP initially. Viewing Reports To view existing reports, select Report Manager > DI/IDP Reports. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 14: Reporting for more information. 56 Reports

57 Dashboard NSM now has a Dashboard. The NSM Dashboard displays a near-real time view of the source watch list, destination watch list, and the top 10 attacks within the previous hour. It also displays device status. Clicking on a Watch List takes you to the appropriate Log Viewer page. Previously, it had taken you to Log Investigator. To view the Dashboard, select Security Monitor > Dashboard. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 12: Analyzing Your Network for more information. Profiler Figure 6: Profiler: Application View NSM now features the same Profiler functionality as the IDP Management Server. Profiler settings are migrated from IDP, but Profiler data is not. Rerun Profiler after your migration by selecting Devices > IDP Profiler > Start Profiler, then following the wizard. To view Profiler data, select Security Monitor > Profiler. Profiler changes between IDP and NSM: NSM automatically downloads profiler data from the Sensors. You no longer have to download Profiler data manually. Dashboard 57

58 IDP-NetScreen-Security Manager Migration Guide You cannot manually purge selected Profiler entries. The Sensor handles purging automatically. You can, however, purge the entire Profiler database in NSM. NSM supports up to 20 Sensors running Profiler. Profiler now supports Operating System fingerprinting. You can filter output by right-clicking on a column header. Violation objects: In IDP, you could create violation objects for the Profiler. NSM has the following differences: Instead of violation objects, NSM has permitted objects. These have the same function; they just have different names. Create permitted objects for every permitted combination of Source, Destination, and Service. Everything else that shows up is a violation. In IDP, violation objects were handled in Object Manager. In NSM, permitted objects are handled in the Profiler itself, in the Violation Viewer tab. Permitted objects make use of predefined and user-created service objects and user-created address objects. You can use pre-created address objects or add to the address object pool using the permitted objects editor. Creating a permitted object does not automatically apply it to the Profiler view. To apply an object, check its checkbox in the Violation Viewer list, then click the Apply button at the bottom of the list. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 12: Analyzing Your Network for more information. Security Explorer Security Explorer is a new feature in NSM. It takes Profiler and attack data and displays it in a dynamic, interactive graphical layout that lets you navigate through network events. To view Security Explorer, select Security Monitor > Security Explorer. Refer to the NetScreen-Security Manager Administrator s Guide, Chapter 12: Analyzing Your Network for more information. 58 Security Explorer

59 Figure 7: Security Explorer: Top Attacks View Security Explorer 59

60 IDP-NetScreen-Security Manager Migration Guide Figure 8: Security Explorer: Peer IPs View Scheduler NSM provides automated report generation and automated attack-object downloads. The IDP Scheduler tool is no longer supported. The NSM GUI server scheduler tool (guisvrcli.sh) has all the same functionality, and more. Reports stored in My Reports cannot be scheduled. If you want to schedule a report you have created, right-click the report, select Save As, and save the report into Shared Reports. 60 Scheduler

61 For more information on automatic report generation, see the NetScreen-Security Manager Administrator s Guide, Chapter 14: Reporting. For more information on Scheduled Security Updates, see the NetScreen-Security Manager Administrator s Guide, Chapter 7: Managing Devices. Management Server IDP had one management server that managed both the IDP Sensors and the IDP user interface. NetScreen-Security Manager splits this functionality into two servers, the Device Server (DevSvr) and the GUI Server (GuiSvr). You can either run both of these servers on the same machine or run them on different machines to improve performance. In addition, NSM servers have High Availability support via backup servers. If one device or GUI server fails, NSM can switch over to the other device or GUI server automatically. Refer to the NetScreen-Security Manager Installers Guide for more information on planning your NSM installation. General User Interface This section covers user interface differences that aren t part of a specific feature. Search In any tabular display of information in NSM, you can search on any column. 1. Click any cell in the column you want to search. 2. Press Ctrl-F. 3. Select a mode from the following list: C Finds cells in the column that contain the string anywhere in the cell. S Finds cells in the column that start with the string. R Finds cells based on the entered regular expression. I Finds cells that contain the entered IP address. 4. Type a string. The highlight jumps down to matching cells. 5. Use the down and up arrows on your keyboard to cycle through the matching rows. Shortcut: Rather than pressing Ctrl-F, then C in a cell, you can just highlight the cell and start typing. Management Server 61

62 IDP-NetScreen-Security Manager Migration Guide Job Manager NSM supports the background processing of many functions, including device update. Progress for an individual process is displayed in a Job Information dialog. You can leave this dialog open while the job processes, or you can close it. The Job Manager displays all jobs, sorted by job type. Select Job Manager from the left pane to see this screen. Double-clicking a job entry brings up that job s Job Information dialog. The background processing, along with the Job Manager, allows you to run and monitor many operations at the same time. Domains Device Templates NSM provides the concept of Domains. You can segregate devices and user functions into discreet areas, called domains. You can create domains based on physical location (the New York office and the Chicago office), by function (firewall administration and IDP Sensor administration), or by another system. NSM provides device templates. A device template contains all the device settings for every type of device supported by NSM. You can populate these fields in the template, then push the template to multiple devices, including Sensors. Devices ignore any fields that do not apply. IDP Sensor Settings can be found in the Security > IDP SM Settings portion of the device template. The policy and Profiler setting can be found in the IDP Device Settings portion of the device template. Figure 9: Device Template 62 General User Interface