Forcepoint NGFW
Administrator
Lab Guide
Forcepoint Technical Enablement Program
Rev. CB0335
Public
forcepoint.com
© 2021 Forcepoint. Forcepoint and the FORCEPOINT logo are trademarks of Forcepoint.
All other trademarks used in this document are the property of their respective owners.
This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or
reduced to any electronic medium or machine-readable form without prior consent in writing
from Forcepoint. Every effort has been made to ensure the accuracy of this manual. However,
Forcepoint makes no warranties with respect to this documentation and disclaims any implied
warranties of merchantability and fitness for a particular purpose.
Forcepoint shall not be liable for any error or for incidental or consequential damages in
connection with the furnishing, performance, or use of this manual or the examples herein. The
information in this documentation is subject to change without notice.
2 << <Course title>
Public
© 2021 Forcepoint
Contents
1. Lab 1: Post-installation Administration Tasks
1.1
Create an on-demand backup . . . . . . . . . .
1.2
Create a task and schedule ongoing backups .
1.3
View pending changes . . . . . . . . . . . . . .
1.4
Enable an administrator password policy . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
. 9
. 10
. 13
. 15
2. Lab 2: SMC User Administration
2.1
Create a User Role . . . . . . . .
2.2
Create an ACL . . . . . . . . . .
2.3
Create an SMC administrator . .
2.4
Testing the new SMC user . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
19
20
23
.
.
.
.
25
25
26
27
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Lab 3: Understanding and Using Logs
3.1
Use the log viewer to locate events of interest
3.2
Manually create specific filters . . . . . . . . .
3.3
Using statistics . . . . . . . . . . . . . . . . .
3.4
Drilling In . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Lab 4: NGFW Policy and Template
31
4.1
Create a new policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2
Change the template of a policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Lab 5: Designing a Security Policy
5.1
Add a Continue Rule for Logging . . . . . . . . . .
5.2
Add a continue rule for SSH timeout . . . . . . . .
5.3
Add a rule to allow SSH access to firewall . . . . .
5.4
Add a rule allowing traffic to the internet . . . . . .
5.4.1 Create an Expression . . . . . . . . . . .
5.4.2 Adding the outbound access rule . . . . .
5.5
Add rule sections . . . . . . . . . . . . . . . . . . .
5.6
Add a rule to monitor traffic from foreign countries
5.7
Add a dynamic source NAT rule . . . . . . . . . . .
5.8
Upload the policy and enable validation tools . . .
5.9
Testing the new security policy . . . . . . . . . . .
5.9.1 Testing connectivity to the internet . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
35
36
37
38
39
39
40
42
43
45
45
6. Lab 6: Configuring SSH Proxy
6.1
Create a rule Permitting SSH from the Engine
6.2
Create a known host entry . . . . . . . . . . .
6.3
Create an SSH Known Host List . . . . . . .
6.4
Enable SSH Proxies on the Engine . . . . . .
6.5
Create a custom SSM proxy element . . . . .
6.6
Add a policy rule using the SSM SSH proxy .
6.7
Testing the SSM SSH Proxy . . . . . . . . . .
6.8
Deleting a Rule . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
49
50
51
52
54
55
56
7. Lab 7: Using Deep Inspection
7.1
Add a security policy rule enabling Deep Inspection . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
Create a new Inspection Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3
Select the Inspection Policy in the Firewall Policy . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
59
60
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7.4
7.5
7.6
Upload and test the inspection policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Create an Exception rule for false positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Blocking An Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8. Lab 8: Automated alerting and notifications
8.1
Configure the management server for alerting
8.2
Configure an Alert Chain . . . . . . . . . . . .
8.3
Create A custom alert . . . . . . . . . . . . .
8.4
Configure an Alert Policy . . . . . . . . . . . .
8.5
Add custom alerting in a Security Policy . . .
8.6
Testing Automated Alerting . . . . . . . . . .
.
.
.
.
.
.
69
69
71
72
73
75
76
9. Lab 9: Preparing for User Authentication
9.1
Create an LDAP Server element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2
Add a new LDAP domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3
Create a new user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
77
78
80
10. Lab 10: Browser-based Authentication
10.1 Configure the firewall for user authentication . . . . . . .
10.2 Create a rule requiring authentication for internet access
10.3 Create an HTML response to users . . . . . . . . . . . .
10.4 Testing Browser-Based Authentication . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
86
88
11. Lab 11: Configuring the SSL VPN
11.1 Create a web service . . . . . . .
11.2 Create an SSL VPN policy . . . .
11.3 Create the SSL VPN Portal . . .
11.4 Testing the SSL VPN Portal . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
90
91
93
12. Lab 12: Creating a Site-to-Site IPSec VPN
12.1 Create the External VPN Gateway . . . . . . .
12.2 Configure the VPN topology . . . . . . . . . . .
12.3 Create a custom VPN Profile . . . . . . . . . .
12.4 Add VPN rules to Security Policy . . . . . . . .
12.5 Testing access to and from the Partner network
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
95
97
98
101
102
13. Lab 13: Advanced Log Usage
13.1 Enable diagnostic logs . . . .
13.2 View rule counters . . . . . .
13.3 Exporting logs . . . . . . . .
13.4 Using rule tags . . . . . . . .
13.5 Using Audit Logs . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
103
105
106
108
109
14. Lab 14: Tools for the SMC and Policy Management
14.1 Compare the current policy with a snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.2 Using the policy search tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.3 Enabling network details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
111
112
113
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15. Lab 15: Monitoring, Overviews and Reporting
114
15.1 Create and customize a new overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
15.2 Schedule and generate a built-in report and export it to PDF . . . . . . . . . . . . . . . . . . . . 114
15.3 Create a simple custom report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
16. Lab 16: If Things Go Wrong - Troubleshooting
16.1 Collecting sgInfo files from the Management Server using the management client
16.2 Collecting sgInfo files from the FW engines using the management client . . . .
16.3 Collecting an sginfo at the command line for the engine . . . . . . . . . . . . . .
16.4 Collecting an sginfo at the command line for the management server . . . . . . .
16.5 Running tcpdump from the SMC and command line . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
120
121
122
125
125
17. Lab 17: Single Firewall Installation
17.1 Define a new single firewall . . . . . . . . . . . . . .
17.2 Define physical interfaces . . . . . . . . . . . . . . .
17.2.1 Define interface 0 . . . . . . . . . . . . . .
17.2.2 Define Interface 1 . . . . . . . . . . . . . .
17.3 Configure IP addresses on physical interfaces . . . .
17.3.1 Add IP address for Interface 0 . . . . . . .
17.3.2 Add IP Address for Interface 1 . . . . . . .
17.4 Configure Interface Options . . . . . . . . . . . . . .
17.5 Create a default route . . . . . . . . . . . . . . . . .
17.6 Establishing Trust with the SMC . . . . . . . . . . . .
17.6.1 Saving the initial configuration . . . . . . .
17.6.2 Configuring the Engine for SMC Contact . .
17.7 Bind a License to the Engine . . . . . . . . . . . . .
17.8 Define a Policy for Partner FW . . . . . . . . . . . .
17.8.1 Create the Partner Policy . . . . . . . . . .
17.8.2 Add VPN rules to the partner firewall policy
17.9 Re-install the Student HQ Policy . . . . . . . . . . .
17.10 Testing access to and from the Partner network . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
128
128
129
129
130
130
131
131
132
133
134
134
136
141
141
141
142
143
144
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Introduction
This guide is designed to help administrators understand the management and maintenance of a Forcepoint
NGFW environment. The exercises below will help you understand some of the most common tasks that
administrators are required to perform on a daily basis.
In these labs, there are many ways of accomplishing the same task. While working through the labs, you
are encouraged to find a way of performing tasks that is comfortable for you. While the instructions are step
by step, they only illustrate one way of performing a task. Should you have any questions about other ways
of performing a task, please ask your instructor.
The lab environment that you will be using is designed so that it provides as close to a “real-world” experience as possible. The virtual environment that you will use simulates a simple networking environment to
illustrate some of the Forcepoint NGFW core concepts.
Accessing the lab
Your instructor will provide you with the information needed to access the lab environment through Go4Labs.
This will be a URL and/or connection information for use with an RDP client. It is generally recommended
to use the Web-based access because it provides the instructor with additional tools for assisting you.
However, if network stability is an issue, then the RDP client may provide a more resilient means of access.
Your initial connection will be to a Windows virtual machine, which is referred to as the “Landing Machine”
in this lab environment. You will not perform the lab exercises directly on this machine, but it offers tools for
connecting with all of the components in the lab environment itself.
On the desktop of the Landing Machine you will find an icon for GNS3. Double-click to open the
application and access the connections to the various components of the Lab environment.
6
Connecting to the HQ SMC
Most of your work will be done while connected to the HQ Workstation. There are two flavors of
management clients, Java- and Web-based. Launch the Security Management Center client by doubleclicking one of the green Forcepoint logo icons on the desktop of the landing machin.
Figure 2 : Connecting to the SMC
You may find it preferable to display the remote viewer window in full-screen.
Figure 3 : Fullscreen
Accessing the SMC Management Client
Most of the tasks in the lab exercises will be completed within the SMC Management Client. This client is
installed on the desktop of the HQ Workstation.
7
To access the Management Client, double-click on the desktop icon and wait for the application to load.
When the application loads, an IP address for the Management Server should be pre-defined. Click the
pre-defined Management Server.
Figure 4: Selecting the Management Server
Log in as the user student using Forcepoint1 as the password.
Unless directed otherwise by this lab guide or by your instructor, use Forcepoint1 as the password
everywhere one is requested.
Figure 5: Logging in to the SMC
8
1
Lab 1: Post-installation Administration Tasks
Goals of this lab
In a new deployment of the SMC software, after the software is installed and the licenses are applied,
there are a few tasks that should always be performed before you begin installing and configuring firewalls.
By performing these tasks, you can rest assured that there will always be a backup of the environment
should something happen to the SMC. Additionally, you will learn how to view the changes that you made
to policies, object or engine before deployment to the NGFW Engines. Lastly, you will learn how to enforce
a password policy so that administrator passwords must conform to the standard you specify.
1.1
Create an on-demand backup
1. To create an on-demand backup, click Menu > System Tools > Backup.
Figure 6: Creating an on-demand backup
9
System Tools may not appear on the menu until you have first selected an engine.
2. Click on the Management Server and click Add.
3. In the Backup Comment field, type “Post installation backup”.
Figure 7: Backup details
4. Click OK. The backup will execute. When it finishes, you may close this tab.
1.2
Create a task and schedule ongoing backups
To create ongoing backups, will need to create a Management Backup task and then schedule it. Perform
the following steps:
1. Click on the Configuration icon.
10
Figure 8: Configuration icon in toolbar
2. On the left side, expand Administration.
3. Expand Tasks and click on Definitions.
4. In the right pane, right-click > New > Backup Task.
Figure 9: Creating a backup task
5. In the Name field, enter “Weekly SMC backup”.
6. Click on Management Server and click Add.
7. In the Backup Comment field, enter “Weekly backup”.
8. Click OK.
11
Figure 10: Backup task properties
9. The task is now created. Now that the backup task is created, you must now schedule it to run on a
weekly basis.
10. Right-click on the Weekly SMC backup task > Schedule.
Figure 11: Scheduling a backup task
11. In the Task Schedule Properties, select Weekly from the Repeat dropdown menu.
12. For Repeat On, deselect all days except Monday.
12
13. Optionally, you can select a start time and how the Final Action is handled.
Figure 12: Schedule task properties
14. Click OK. The task is now scheduled.
1.3
View pending changes
You can view the configuration changes that you and other administrators have made before the new
configurations and policies are transferred to the NGFW Engines. You will now make a change to HQ FW
configuration and this change will be displayed in the Pending Changes pane in the Home view.
1. Click on Home icon, right-click on the HQ FW > Edit Single Firewall HQ FW. The firewall editor
opens.
2. In the General properties (the default view), next to the DNS IP Addresses, click the Add button >
IP Address.
3. In the box that appears, enter 192.168.123.1
13
Figure 13: Adding an additional DNS server
4. In the upper-right of the engine editor, click the Save button. Then close the engine editor tab.
Now that an update has been made to the configuration of the engine, let’s view this change.
5. From the Home view, click on the HQ FW, you will notice that the Pending Changes panel shows
that a change was made. Click the View Changes button. The configuration comparison tool opens.
Figure 14: Viewing pending changes
6. In view that appears, click on the Targets (Modified) icon. This will show a comparison of the engine
configuration before and after the change. You may close the configuration comparison tab.
14
Figure 15: Engine configuration comparison
7. From the Home view, under the Pending Changes panel, click the Commit Changes button.
Figure 16: Committing changes
8. Click OK in the Refresh Policy Dialog box.
1.4
Enable an administrator password policy
To ensure that SMC users are forced to adhere to certain security requirements, you will now configure
logon options, password age and expiration requirements, and password complexity.
1. Click the Menu > System Tools > Global System Properties.
2. Click on the Password Policy tab.
3. Select the following options:
15
• Enforce Password Settings...
• Only One Logon Session for Each User
• Lock the Management Client Window After the User Session is Idle for: set to 2 Hours
Figure 17: Selecting logon requirements
4. Now, you will configure options for password age and expiration. Under the Password Age and
Expiration section, select the following options:
• Require Password Change After First Logon (should already be selected)
• Password Expires After
• Notify User When Password Expires in
• Limit Reuse of Previous Passwords (Number of Previous Passwords)
Figure 18: Password age and expiration
16
5. Lastly, you will configure password complexity options. Accept the default settings. Feel free to
customize.
Figure 19: Selecting password requirements and options
6. Click OK
The password policy is now configured.
The administrator password policy in this lab has been designed to meet the training needs. In a
real deployment, the password policy should be more secure.
17
2
Lab 2: SMC User Administration
Goals of this lab
In the SMC, it is always a good idea to ensure that there are as few administrators as possible who have
superuser privileges. When the SMC is installed, there is always one superuser created. Other administrators in the system should have somewhat restricted privileges. The benefits to this include accountability
and the assurance that not all administrators have the ability to completely control the SMC. To do this,
you will use Role-based Access Control to create administrator roles, restrict what objects an administrator
has access to through the use of access control lists, and provide administrators a way to customize their
preferences.
2.1
Create a User Role
Before you can create a user, there must be a role associated with a user that specifies what they have the
rights to do. There are built-in roles, but here you will create a custom role.
1. On the menu bar, click the Configuration icon.
2. Expand Administration > Access Rights and click on Administrator Roles.
3. Right-click in the pane on the right and select New Administrator Role.
4. Enter the name for the role as HQ Custom Role.
5. Select the following options:
• View Element Contents
• Refresh Policies
• Browse Logs and Alerts from Granted Elements
• View System Alerts
18
Figure 20: Custom role properties
6. Click OK to save the new role.
2.2
Create an ACL
Now you will create a custom Access Control List to restrict the new user to only certain elements. For this,
you will use some of the built-in ACLs to build your new ACL.
1. On the left side, click on Access Control Lists.
2. Right-click in the pane on the right and select New Access Control List.
3. In the Name field, enter HQ Custom ACL.
4. Click on Access Control Lists.
5. From the list of ACLs, add the following by clicking the Add button:
19
• ALL Simple Elements
• Use the “arrow” icon, go up a level click on NGFW Engines and add the HQ FW to the list.
• Go up a level again, and navigate to Policies > Firewall Policies > Firewall Template >
Management Template and add the HQ Policy to the list.
6. Click OK to save the new ACL.
Figure 21: Access Control List Properties
The role and the ACL have now been defined. The role specified what actions someone in the role can
perform, and the ACL controls to which elements those actions can be performed. You will now combine
these by associating them with a new SMC administrator.
2.3
Create an SMC administrator
To create a new administrator with restricted rights, perform the following steps:
1. On the left, click on Administrators.
2. Right-click in the pane on the right and select New Administrator.
3. In the Name field, enter Bob.
4. Leave Local as value in the Type field.
20
5. In the Password field, enter Pass123456, making sure to confirm it in the field below.
The Generate Password button will generate a sufficiently complex password for normal use.
6. Leave the Always Active radial button selected.
Figure 22: Administrator Properties
7. Click on the Permissions tab and click Add Role.
8. Under the Role column, click on Operator. A drop-down list appears.
9. Select the role you created in the last section, HQ Custom Role. If the role does not appear in the
list, click Select to open the selection dialog box.
10. Under the Granted Elements column, right-click and select Edit Granted Elements.
21
Figure 23: Edit granted elements
11. In the box that appears, click on ALL Simple Elements on the right and click the Remove button.
12. In the left pane, click the Access Control Lists > HQ Custom ACL and click the Add button.
Figure 24: Custom ACL selection
13. Click OK. The Administrator properties have now been selected and you can click OK again to close
the Administrator Properties.
There are other tabs on the Administrator Properties that are worth exploring. On the Color
Filters tab, you could change the colors of how entries appear in the log view.
22
2.4
Testing the new SMC user
You have now created a user with restricted permissions. You will now test your new user’s abilities with
restricted permissions.
1. Close the SMC console, and reopen it. This time logging in as Bob.
2. As per the password policy that you created in the first lab, you are prompted to change your password. Use Pass12345678 as the new password.
Figure 25: First logon password change
3. Once you are logged in, attempt the following tasks:
• Note that you when you log in, the main status view looks the same.
• Right-click on HQ FW and notice that you can view its properties, but it cannot be edited.
Figure 26: Restricted viewing permissions
• Right-click on the HQ FW > Current Policy > Refresh Policy. Can you do that?
23
Figure 27: Attempting to refresh a policy
• On the menu bar, click the Configuration icon.
• On the left side, expand Network Elements > Hosts.
• Right-click on a host. Can you view its properties?
• Click the New icon in the upper right. Can you add a new host?
Figure 28: Adding a new host
Close the console and log back in as root. If you are required to change the password, use
Forcepoint2. Remember to use this password for the remainder of the labs.
By now, it is clear that with Role-based Access Control, it is possible to tightly control what administrators
can do, thereby limiting the amount of power any one administrator can have. You are encouraged to take a
moment and learn the extent of the relationship between the role and the ACL. If you have questions, your
instructor will be glad to answer.
24
3
Lab 3: Understanding and Using Logs
Goals of this lab
In the SMC, there are few things more powerful than the logs. Understanding the logs and how they can be
used is crucial for situational awareness, reporting, troubleshooting and support among other things. This
lab will familiarize you with how to locate events, filter for events in two ways, and use statistics to provide
a visual representation of log data.
3.1
Use the log viewer to locate events of interest
To begin using the logs, you must first locate something of interest. As a simple example, you will look for
DNS traffic. Then, you will attempt to find all DNS traffic that is not destined for 192.168.122.53
1. On the menu at the top, right-click the Logs icon on the menu bar and select Open in New Tab. The
log view opens in a new tab.
2. Scroll through the logs, looking at the Service column. Locate a log entry with DNS as the service.
3. Drag and drop that into the query panel on the right by clicking on the service value DNS (UDP).
Figure 29: Filtering for DNS traffic
4. Click Apply. Note that only entries with DNS as the service appear.
5. You will now see there are many entries with 192.168.122.53 as the destination. Click on
192.168.122.53 in the destination column and drag it to the query panel.
6. Click the small box to the left of the filter you just added. This will negate traffic destined for
192.168.122.53.
7. Click Apply.
25
Figure 30: Negating a destination address
All DNS events that are not destined for 192.168.122.53 are now displayed.
3.2
Manually create specific filters
You have just learned the basic idea behind dragging and dropping items from the logs to create filters. This
is very useful for quickly locating information. However, there is a more targeted way of locating information.
Now you will create a specific filter out UDP traffic.
1. First, remove the two last filters by right-clicking on the filter and selecting Remove.
2. Right-click on the column header for IP Protocol > Filter: IP Protocol.
Figure 31: Manual creation of a protocol filter
3. In the box that appears, type UDP in the box that reads Type to Search.
4. Double-click UDP and then Apply. The UDP filter appears in the query panel.
5. Click in the small box to the left of the filter to negate it.
6. The IP Protocol filter appears in the query panel. To run the query, click Apply.
26
Figure 32: Query panel with sample filters
Now only protocols that are not UDP will appear in the log view. This same procedure can be repeated on
any of the column headers to create manual filters.
3.3
Using statistics
Statistics are a way of taking the information you see in the log view and creating a graphical representation
of it. In this way, you can see the larger picture of what might be happening on the network. In order to use
statistics effectively, you will first need to generate some traffic through the firewall. There are two scripts
on the desktop of your workstation that will start and stop traffic.
1. On the desktop of your HQ Workstation, double-click the shortcut for the browser, StartTraffic some
traffig. Allow this to some time. You should begin to see traffic in the log view.
Figure 33: Starting some traffic generation
If you want to see the logs generated by the engine in live mode as they arrive on the log server,
click on the current button.
Figure 34: Current mode button
27
2. After letting it run, with the log view open, click the Statistics button > Select.
Figure 35: Statistics selection
3. In the box that appears, scroll down and locate Top Services. If it is not seen in the list, click Select
and browse to locate it.
You can also start the first few letters of the item for which you are searching to make finding items
easier, as in the figure below.
Figure 36: Selecting Top Services
4. Click Select. The Top Services are displayed. You should see something similar to the figure below.
28
Figure 37: Top Services
3.4
Drilling In
In the last exercise you were able to create a graphical representation of the logs, enabling you to see the
larger picture of the top services in you network. It is possible to toggle between raw logs and statistics,
providing you a simple path to find items of particular interest in your network. In this exercise, you will drill
deeper into the statistics view.
1. From the Top Services view, select one of the items on the bar graph.
2. Right-click on it and select Show Records. The individual records are now displayed.
Figure 38: Showing records from the statistics view
3. To leave the Statistics view and return to the unfiltered logs, click the Back Arrow in the top left of
the window.
29
4. Repeat steps 1 through 4 above, selecting Top Network Applications instead. This will display the
top network applications.
Figure 39: Statistics for Top Network Applications
Although this exercise was quite simple, follow these same steps to view many, many kinds of statistical
information related to network activity. You may close the logs view after this exercise.
Parei aqui na aula 01 - 08/08/2023
30
4
Lab 4: NGFW Policy and Template
Goals of this lab
Creating a security policy is simple to do, but doing it correctly from the very beginning will significantly
reduce the burden on administrators in the future. Through the use of templates, you can create a policy
hierarchy that will ease the administration of your firewall policies, especially for large deployment. This lab
will familiarize you with the concept of policy templates. You will learn how to change policy templates and
view the inherited rules from the template as they are inserted into your policy.
4.1
Create a new policy
To begin, you will create a policy based on the predefined Firewall Template. It contains predefined access
rules necessary for the firewall to communicate with the SMC and some external components.
1. Right-click on the Configuration icon on the menu bar and select Open in New Tab.
2. On the left side, expand NGFW > Policies and click Firewall Policies.
3. Right-click on the Firewall Template and select New > Firewall Policy.
Figure 40: Creating a new firewall policy
4. In the Name field, enter Student HQ Policy.
5. Click OK. The policy editorwill open.
A new policy has been created and is ready for editing. Note the green insert point.
It is possible to view rules that are inherited from templates. In the Policy Editor, click the Inherited
Rules button. Rules that are inherited from the Firewall Template and any custom template are now
displayed. Inherited rules cannot be edited from the Firewall policy. To hide the inherited rules,
simply click the Inherited Rules button again.
31
Figure 41: Viewing the inherited rules
4.2
Change the template of a policy
You will change the template of your Student HQ Policy to use the customized template for this training
environment.
1. Click the Preview button in the policy editor toolbar. The policy will change from edit mode to preview
mode, which is mandatory for changing the template of your policy.
2. Click the Configuration view tab you opened in Section 4.1, step 1, right-click the Student HQ Policy
and select Properties.
3. Expand the Policies tree and select ManagementTemplate.
Figure 42: Change the template of a policy
4. Click OK.
5. In the Configuration View, expand the Policies tree to see the new policy hierarchy.
6. Click the tab where the Student HQ Policy is open.
The rules inherited from the ManagementTemplate are displayed in light gray.
7. Click the Inherited Rules button in the toolbar to hide the inherited rules.
32
5
Lab 5: Designing a Security Policy
Goals of this lab
After you decide on a policy hierarchy, you can populate the policy elements with rules for handling the
traffic. This lab will familiarize you with creating access control and NAT rules for your firewall policy.
Through the use of continue rules, aliases, expressions and rule sections, you will create a clean, readable,
and secure policy that can be maintained easily for ongoing administration.
5.1
Add a Continue Rule for Logging
A common mistake in logging is forgetting to turn on logging for something important. In this exercise, you
will add a Continue rule that will ensure that logging is always enabled for all rules. There are many way to
deal with the volume of logs that this could produce in a busy network, such as log data pruning and turning
off logging on a rule-by-rule basis.
1. In the tab where the Student HQ Policy is open, click the Edit button.
2. Double-click on the green line that reads HQ-Rules - add rules here. A blank rule is inserted.
3. Configure this rule with the following properties:
• Source: right-click > Set to ANY.
• Destination: right-click > Set to ANY.
• Service: right-click > Set to ANY.
• Action: right-click > Continue.
• Logging: right-click > Edit Logging. Configure the following properties:
–
–
–
–
Select the Override Settings inherited from Continue Rule(s) checkbox.
Set the Log Level to Stored .
Set the Connection Closing to Log Accounting Information.
Set the Log Network Applications to Enforced.
The completed Logging properties should look like the figure below.
33
Figure 43: Logging options
The fully configured continue rule should look like the figure below.
If the columns are not at the proper width, right-click on any column header and select Fit All
.
Figure 44: Logging continue rule
34
5.2
Add a continue rule for SSH timeout
In the previous exercise, you added a Continue rule for logging. Here you will add another Continue rule
that sets a timeout for idle SSH connections.
1. On the previous rule, right-click in the ID and select Add Rule After.
Figure 45: Adding a rule after the first
2. Configure this rule with the following properties:
• Source: Right-click > Set to ANY.
• Destination: Right-click > Set to ANY.
• Service: Click in the Service column and type 22. Select SSH from the list.
Figure 46: Finding services faster
• Action: Right-click > Continue.
• Logging: Leave logging blank. The previous rule has you covered.
3. Right-click on the Action and select Edit Options. The action options open.
4. Click the Advanced tab.
35
5. In the Idle Timeout field, enter 120.
Figure 47: Setting the SSH Idle Timeout
The completed rule should look like the figure below.
Figure 48: Completed continue rule for SSH timeout
5.3
Add a rule to allow SSH access to firewall
You will now create a rule that allows access directly to the firewall on SSH. The purpose of this rule is so
that the administrator can access the engine at the command line in the event there was a need to do so,
such as troubleshooting. Unless this rule is present, the engine will deny incoming SSH connections. It is
highly recommended that the source of the SSH connection be as restricted as possible. In this exercise,
the source will be the HQ-Workstation machine and the management server machine.
1. On the previous rule, right-click in the ID and select Add Rule After.
36
2. Click in the Source column.
3. On the left, click Network Elements > Hosts and drag the win-wrkstn into the Source column.
win-wrkstn is the element that identifies the HQ Workstation machine in SMC.
Figure 49: Network element tree
Then go up one level, click Network Elements > Servers, and drag the Management Server into
the Source column.
4. Click in the Destination column. On the left, click Network Elements > NGFW Engines. If necessary, go up one level in the resources pane to find Network Elements.
5. Drag HQ FW into the Destination column.
6. Drag SSH from the rule above into the Service column.
7. Right-click in the Action column and select Allow.
In order for SSH access to the firewall to work, it must be enabled. This can be done in the Home
view by right-clicking on the firewall named HQ Firewall, then click Commands > Enable SSH
from the menu.
The completed rule should look like the figure below.
Figure 50: Allowing management SSH access to engine
5.4
Add a rule allowing traffic to the internet
You will now add an access rule that permits traffic to the internet. When and where possible, it is recommended that you avoid the use of ANY. To avoid this, you will create an Expression that will help you more
37
specifically define what the “internet” is.
5.4.1
Create an Expression
1. In the tree view on the left, navigate to Network Elements > Expressions.
2. Right-click > New Expression. The Expression editor opens.
3. In the Name field, enter Not HQ Training Networks.
4. Click the negate operator (~).
5. Click the left parenthesis icon.
6. Click the Add Element button (it looks like a big “plus” sign), the element selection window appears.
7. Browse to Network Elements > Networks > network-172.31.200.0/24, then click Select.
8. Click the union operator, U. This will allow you to “union” your internal network with your DMZ
network.
9. Click the Add Element button again, browse to Network Elements > Networks, select the
network-192.168.0.0/24 network, then click the Select button.
10. Finally, click the right parenthesis button.
11. Click OK. The Expression editor will close.
Your completed expression should look like the figure below.
Figure 51: Completed expression
38
5.4.2
Adding the outbound access rule
With your completed expression, you are now ready to add a rule that has a more specific definition for the
“internet” other than “Any”
1. Right-click in the ID column of the last rule (the SSH engine access rule) and select Add Rule After.
2. Configure this rule with the following properties:
• Source: On the left, browse to Networks and drag the network-172.31.200.0/24 and
network-192.168.0.0/24 networks into the Source column.
• Destination: On the left, browse to Expressions and drag your not HQ Training Networks
expression into the Destination column.
• Service: Right-click > Set to ANY.
• Action: Allow
Your completed rule should look like the figure below.
Figure 52: Completed outbound access rule
5.5
Add rule sections
At this point, it is always a good idea to start making the policy readable by others. No doubt, there will be
other administrators or auditors who have to look at the security policy and understand what it’s doing and
how to interpret the function of rules. To aid in that, you will now add rule sections to organize it. As you will
see, rule sections are best added from the bottom up.
1. Right-click in the ID column of the last rule and select Add Rule Section Before.
2. Note that the rule you just added appears to have disappeared. Click the “plus” sign to the left of the
rule to expend the rule section.
3. In the blank, light blue area, double-click and type Outbound Access Rules. Click on the Check
icon.
4. Optional: Right-click on the rule section > Colors > Color to your liking.
5. Right-click in the ID column of the first rule and select Add Rule Section Before.
39
6. Double-click on the new rule section and name it Logging and Timeouts.
Your completed rule should look like the figure below.
Figure 53: Completed rule sections
5.6
Add a rule to monitor traffic from foreign countries
Now you will add a rule to alert you in the event that traffic from suspect countries is destined for you
network. You’ll note that you are setting to action to allow. This is because creating an access rule to drop
traffic from suspect countries is a false sense of security, as tools the TOR browser can anonymize the
source. In any case, it is still a good idea to be alerted to traffic sourced from suspect countries.
1. Right-click in the ID column of the last rule in the Logging and Timeouts section and select Add
Rule After.
2. Configure this rule with the following properties:
• Source: On the left, browse to Network Elements > Countries.
• Browse through the list of countries and drag Russia into the Source column of the new rule.
• Destination: Right-click > Set to ANY.
• Service: Right-click > Set to ANY.
• Action: Continue.
• Logging: Double-click in the logging column, the Logging Options appear.
3. Configure the logging as in the figure below and click OK.
40
Figure 54: Logging options for country monitoring
As with the other rules, it is a good idea to add a rule section for this new rule, to which you can add other
inbound rules in the future.
1. Right-click in the ID column of the country monitoring rule you just created > Add Rule Section
Before.
2. The new rule section appears. Double-click in the blank rule section. In the box that appears, type
Inbound Rules.
3. You may optionally change the color of the rule section by right-clicking > Colors.
Your completed rule should look like the figure below.
41
Figure 55: Country monitoring rule
5.7
Add a dynamic source NAT rule
Before your internal network can reach the internet, you have to NAT that traffic. Generally speaking, for
every NAT rule, there is a corresponding access rule, which you have just created. The access rules now
permit your internal traffic to the internet, now you will create the dynamic source NAT rule.
1. Click on the IPv4 NAT tab.
2. Double-click on the green HQ NAT - add rule here insert point. A blank rule is added.
3. Configure the NAT rule with the following properties:
• Source: On the left, browse to Network Elements > Networks and drag
network-172.31.200.0/24 into the Source column.
• Destination: On the left, browse to Network Elements > Expressions and drag your not HQ
Training Networks into the Destination column.
• Service: Right-click > Set to ANY.
• Right-click in the NAT column > Edit NAT.
• On the Source Translation tab, choose the Translation Type as Dynamic.
• Click the Address button. Type 192.168.122.100 in the field provided.
• Make sure that the Automatic Proxy ARP checkbox is selected.
42
Figure 56: Dynamic Source NAT Properties
4. Click the Save icon (not the one with the “up” arrow)
Your completed Dynamic Source NAT rule should look like the figure below.
Figure 57: Completed dynamic source NAT
5.8
Upload the policy and enable validation tools
You have finally arrived at the point where you will upload the completed policy and test. You will also
enable some of the rule validation tools to ensure that the policy contains no errors.
1. In the policy editor, in the upper right-hand corner, click the “gear” icon and select Validate.
2. In addition to the already selected items, check Analyze Rules, click OK.
There will likely be some issues. These arise from the template that was created for the training
environment. They will not prevent policy upload.
43
Figure 58: Enabling rule analysis
3. Click the Save and Install icon (the save button with the “up” arrow), the policy upload dialog appears.
4. From the list of engines on the left, select HQ-FW and click Add.
44
Figure 59: Upload the security policy
5. Click OK. The policy upload begins. When you see the message “Policy snapshot completed.
Operation finished on HQ FW.” you can click the Close button.
5.9
Testing the new security policy
Now that the security policy is uploaded, you will test basic access to the internet.
5.9.1
Testing connectivity to the internet
Here you will test basic connectivity to the internet using the logs view and filtering for the address of your
workstation.
1. On the menu bar, click on the Logs icon.
2. Right-click on the Query Panel then from the menu, choose New > Filter: IP Address. The Filter
Properties opens.
45
Figure 60: IP address filter menu
3. In the IP Address field, enter the IP of your workstation, 172.31.200.60, click Add.
4. Click Apply.
Figure 61: IP address filter properties
5. The new filter appears in the query panel. Click Apply.
6. From the Logging Toolbar, click the Current Events button (the “play button”) .
7. From your workstation, open a browser and attempt to access http://pitcher.training.com.
8. You should now see the connections from your workstation to the web server.
You could additionally create a filter to exclude NetBIOS traffic in the log view to better visualize the
web traffic.
9. Scroll to the right and look at the Nat Src and Nat Dst columns and note that your workstation was
NATed properly to the web server.
46
Figure 62: NAT source and NAT destination
47
6
Lab 6: Configuring SSH Proxy
Goals of this lab
One very useful feature of the firewall is the ability to proxy connections for TCP, UDP, HTTP, HTTPS and
SSH. In this section, you will configure the firewall to proxy outbound SSH connections, which could serve
as an avenue for data exfiltration. In the exercise below, you will add rules that prevent writing data to a
secure FTP site.
6.1
Create a rule Permitting SSH from the Engine
In order for the engine to proxy SSH connections, it must know the key information for hosts communicating
via SSH. You will add a rule that permits the engine to communicate outbound on SSH.
1. Click the tab where the Student HQ Policy is open for editing.
2. In the IPv4 Access tab, expand the sections. Find the rule permitting the HQ-Workstation and the
Management Server machine to access the engine on SSH. Right-click in the rule ID column and
select Add Rule After.
3. Configure the new rule as follows:
• Source: Drag the HQ FW from the rule above into the Source column of the new rule
• Destination: Right-click and set to ANY.
• Service: Click into the Service column and type 22. In the list the appears, select SSH.
• Action: Right-click in the Action column and select Allow.
4. Click the Save and Install button. The policy uploads dialog appears.
5. Click OK. The policy upload begins. When you see the message “Policy snapshot completed.
Operation finished on HQ FW.” you can click the Close button.
Your completed rule allowing the engine outbound on SSH should appear as in the figure below.
Figure 63: Completed outbound SSH rule
48
6.2
Create a known host entry
In this exercise, you will create one trusted server (a known host), so that the engine will permit (and proxy)
communication with this server only; communication to other non-trusted servers will be discarded.
1. Click the tab where the Configuration View is open.
.
If the Configuration View is closed, right-click the Configuration icon on the menu bar and select
Open in New Tab
2. Browse to NGFW > Other Elements > Sidewinder Elements > SSH Known Hosts > SSH Known
Hosts.
Figure 64: Browsing to the SSH known hosts
3. Right-click SSH Known Hosts and then select New SSH Known Host.
4. In the Name field, enter Remote SSH Server.
5. In the IPv4 Address field, enter 87.35.16.200.
6. In the Key Type drop-down box, select ssh-rsa.
7. Press the Retrieve button to send a public key request, the Select Firewall dialog box will open.
The Retrieve function works because the SSH rule you configured above permits the engine to
communicate outbound on SSH to retrieve the key.
8. Select the HQ FW and click the Select button. The public key is downloaded from the SSH server.
Your completed SSH known host should appear as in the figure below (the key and fingerprint will be
different).
49
Figure 65: Completed SSH known host
9. Click OK.
A warning will appear alerting you that the address is used by another host. This does not represent
an IP address conflict. You may click Yes.
6.3
Create an SSH Known Host List
In order to restrict communication to only a list of known and trusted hosts, you will now configure a known
hosts list. In this exercise, you will only add one host to the list. In reality, this could contain a list of all the
SSH servers that are to be allowed. Any host not appearing in the list would have its connection discarded.
To configure the known hosts list, perform the steps below.
1. In the Configuration View, browse to NGFW > Other Elements > Sidewinder Elements > SSH
Known Hosts > SSH Known Hosts Lists.
2. Right-click > New SSH Known Hosts List.
3. In the Name field, enter Training Known Hosts.
4. Click the Add button to add a new SSH known host.
50
5. In the window that appears, select Remote SSH Server that you created above, and click Select.
Remote SSH Server now appears in the SSH Known Hosts list. Your SSH Known Hosts List should
appear as in the figure below.
6. Click OK.
Figure 66: Completed SSH known hosts list
6.4
Enable SSH Proxies on the Engine
1. In the Configuration view, browse to NGFW > NGFW Engines and right-click the HQ FW > Edit
Single Firewall HQ FW. The engine editor will open.
2. On the left, expand Add-Ons and navigate to Sidewinder Proxies.
3. Check the Enable check box.
4. Leave the Sidewinder Logging Profile set to Sidewinder default.
5. In the SSH Proxy pane, click the Add button to add the SSH Known Host list you created above.
6. In the window that appears, select the Training Known Hosts list and click Select.
7. Click the Save icon and close the tab where the engine is open for editing.
Your completed engine configuration should appear as in the figure below.
51
Figure 67: Enabling the Sidewinder proxies
6.5
Create a custom SSM proxy element
In order to customize the SSH Proxy for your needs, you will copy the existing SSM SSH proxy element
and adjust its settings appropriately. To make a custom SSM SSH proxy element, follow the steps below.
1. In the Configuration View, browse to NGFW > Other Elements > Services > With Proxy.
2. Right-click on the SSM SSH Proxy element > New > Duplicate. The service properties will open.
3. In the Name field, enter SSM SSH Custom.
4. Click on the Protocol Parameters tab.
5. Ensure that Allow Remote Command Execution and Allow Remote Shell Execution are checked.
6. Expand the SFTP Commands section. In the Allowed SFTP Commands drop-down menu, choose
Selected From List.
7. Ensure that only Read directories on the server and Read files on the server are selected.
52
Figure 68: Selecting allowed SFTP commands
8. Under the Client Authentication section, enter, “WARNING: This connection is being monitored and
is restricted” in the Client Connection Message field.
9. Under the Client Advanced Settings section, press the Select button next to the SSH Cryptographic Profile and choose Training Profile.
The Training Profile is a collection of SSH settings designed to work with the SSH client you will
use later for testing. Under normal circumstances, the default High Compatibility Profile can be
used.
10. Under the Server Advanced Settings, click Edit next to Accepted Server Key Types. In the window
that appears, click on ssh-rsa and click the Up button below.
11. Click OK. The Accepted Server Key Types window will close.
12. Under the Server Advanced Settings, choose Use Strict Known Host List in the Server Host Key
Validation drop-down menu.
13. Press the Select button next to the SSH Cryptographic Profile and choose Training Profile.
53
Figure 69: Enforcing the use of known SSH hosts
14. Click OK.
6.6
Add a policy rule using the SSM SSH proxy
Now you will add a rule to your policy that will activate the proxy for outbound SSH attempts from the internal
network. To create the SSM SSH rule, follow the steps below.
1. Click the tab where the Student HQ Policy is open for editing.
If your security policy is not already open for editing, click the Configuration button, browse to
NGFW > Policies > Firewall Policies and right-click Student HQ Policy > Edit Policy Student
HQ Policy.
2. Right-click in the ID column of the last rule (under Outbound Access Rules) and select Add Rule
Before.
3. Configure the new rule as follows:
54
• Source: Drag and drop the network-172.31.200.0/24 and network-192.168.0.0/24 from the
rule below into the Source column.
• Destination: Drag and drop the not HQ Training Networks from the rule below into the Destination column.
• Service: Click into the Service column, type 22 and select the SSM SSH Custom.
• Action: In the Action column, right-click and select Allow.
Figure 70: Completed SSM SSH proxy rule
• Click the Save and Install button. The policy uploads dialog appears.
• Click OK. The policy upload begins. Close the upload window when the operation is finished.
6.7
Testing the SSM SSH Proxy
Now you will test the SSM SSH Proxy in two ways: using an SSH terminal and an SFTP Client. You will test
to ensure that the client message is displayed and that the capabilities on the SFTP server are restricted.
1. From the HQ Workstation, double-click the Bitvise SSH Client shortcut on the desktop.
2. The information necessary to log into this server is pre-populated. You will open a connection to
87.35.16.200 by clicking the Login button. The Host Key Verification pop-up appears. Click Accept
for This Session.
3. A User Authentication Banner appears. Note that this is the message that you configured above.
Click the “X” in the upper right corner to close this message.
Figure 71: Session monitoring and restriction message
4. The password should be stored in the profile, so you should not be prompted for one. If you are
prompted, enter Pass1234 and click OK.
5. Two windows appear. One is the command line for the remote server, and the other is the SFTP
client. In the Bitvise SFTP window, locate a file called bash_history in the right-hand pane.
55
6. Right-click on the file and select Erase, then click Yes to the comfirmation prompt. What happens?
You should see an error from Bitvise as in the figure below.
Figure 72: Bitvise error message
7. Open the log view and you should see an entry as in the figure below.
Figure 73: Blocked SFTP action
6.8
Deleting a Rule
From time to time, it will be necessary, for a variety of reasons, to delete a rule. In this exercise, you will
delete the SSH proxy rule that you created above.
1. Click the tab where the Student HQ Policy is open for editing.
2. Locate the SSM SSH rule. In the ID column, right-click and select Delete Rule. The rule is now
deleted.
3. Click the Save and Install button and click OK.
4. The policy upload begins. You can close the window when the operation finishes.
5. You may now close all the Bitvise windows.
56
7
Lab 7: Using Deep Inspection
Goals of this lab
A Next Generation Firewall without deep inspection is just a firewall. In this lab you will become familiar
with the deep inspection capabilities of the Forcepoint NGFW. You will focus on using deep inspection in a
targeted and judicious way to prevent administrator fatigue. In addition to this, you will learn how to quickly
and easily tune Inspection policies to suit your environment. In the course of administering the environment,
it may become necessary to quickly enhance your security policy to a higher level of protection. The last
exercise will teach you how to quickly change your security from a medium level of inspection to a high level
of inspection to deal with an ever changing threat landscape.
7.1
Add a security policy rule enabling Deep Inspection
The first step in using deep inspection is to enable it in the access rules. In this exercise, you will enable
deep inspection for traffic destined for the DMZ.
1. Click the tab where the Student HQ Policy is open for editing.
If the Student HQ Policy is not open for editing, you can edit your Firewall Policy directly from the
Home view. Click the Home button in the menu bar, right-click on the HQ Firewall > Current
Policy > Edit.
2. Below the rule for monitoring country traffic, add a new rule. Right-click in the ID column and select
Add Rule After.
3. Configure the rule with the following properties:
• Source: On the left, browse to Network Elements > Expressions and drag not HQ Training
Networks into the Source column.
• Destination: On the left browse to Network Elements > Hosts and drag DMZ-WWW-NAT into
the destination column.
This is a preconfigured object.
• Service: Right-click > Set to ANY.
• Action: Right-click and select Allow as the action.
4. Right-click again in the Action field and select Edit Options. The options dialog appears
5. In the Deep Inspection drop-down menu, select On. Click OK.
57
Figure 74: Enabling deep inspection for the DMZ
Your completed rule to enable deep inspection for traffic into the DMZ should look like the figure below.
There is a destination NAT rule in the Management Template policy template that translates the
DMZ Server public IP to the private one.
58
Figure 75: Completed deep inspection rule for HTTP
7.2
Create a new Inspection Policy
Now that you have created the access rule that sends matching connections for deep inspection, you will
now associate an inspection policy with your firewall policy.
1. Click the tab where the Configuration view is open.
If the Configuration view is closed, right-click the Configuration icon on the menu bar and select
Open in New Tab.
2. Browse to NGFW > Policies > Inspection Policies.
3. Right-click Inspection Policies and select New Inspection Policy. The Inspection Policy Properties opens.
Figure 76: Creating a new inspection policy
4. In the Name field, enter HQ Inspection Policy.
59
5. Browse to > Policies > No Inspection policy > Medium-Security Inspection Policy and select it
as the template for your inspection policy
Figure 77: HQ Inspection Policy
6. Click OK. The inspection policy opens for editing in a new tab.
7. As you will, for now, accept the defaults, leave the tab with your inspection policy open.
Your new inspection policy should look like the figure below.
Figure 78: Completed HQ Inspection Policy
7.3
Select the Inspection Policy in the Firewall Policy
1. Click the tab where the Student HQ Policy is open for editing.
60
2. Click the Inspection tab.
3. Click the Select button for the Inspection Policy. The Select Element dialog box will open.
4. Click the gear icon (the tools menu) and select Expand All.
Figure 79: Expand the policy tree
5. Browse to Policies > No Inspection policy > Medium-Security Inspection Policy > HQ Inspection Policy.
6. Click on your new HQ Inspection Policy and click Select.
Figure 80: Select HQ Inspection Policy
61
7. Click Save.
7.4
Upload and test the inspection policy
In the last exercise, you created an Inspection Policy based on the Medium Security template. There was
no additional customization, and so you can now upload the policy. This policy upload will contain all of the
access and inspection rules together. All matching connections destined for the NAT IP of the DMZ server
will be inspected.
1. Click the tab where the Student HQ Policy is open for editing.
2. Click the Save and Install button. The policy upload dialog appears.
3. Click OK. The policy upload begins. Close the window when the operation finishes.
4. On the desktop of your workstation, double-click the Start Traffic shortcut.
5. Allow this to run for a few minutes .
6. Close any open Log view tabs. Right-click on the Logs button on the menu open and select Open in
New Tab.
7. In the Query Panel, use the drop-down menu and select Inspection, click Apply.
8. Click the Current Mode button in the log view to see the logs in live mode.
Figure 81: Current mode button
9. After the traffic has run for a while, you should begin to see traffic similar to the figure below:
Figure 82: Events identified by deep inspection
62
If you do not see any log records, go to the Last Log record icon ( >| ) to display the latest stored
records.
Figure 83: Last log record button
At any time, you can stop and start again the traffic generator by double-clicking the Stop Traffic shortcut
on the desktop of your workstation and then double-clicking the Start Traffic shortcut. Logs should appear
within one minute.
7.5
Create an Exception rule for false positives
Let’s assume that some of the identified events are false positives or events that you determine to be benign
in nature. To tune the policy for your environment, you will now create an inspection rule that will turn off
logging for these events. There is more than one way to do this. You could modify the inspection policy
itself, but, this method makes it slightly easier to identify those things that you have flagged as a false
positive.
1. Click on the tab where your Inspection Policy is open for editing and click on the Exceptions tab.
2. Double-click on the colored Insert Point. An empty rule is created.
3. On the tab where the logs are running, locate an event with the Situation being HTTP_CSH-LockyB-Control-Traffic.
Figure 84: Example inspection event
4. Click and hold the HTTP_CSH-Locky-B-Control-Traffic, drag it to the tab that has your inspection
policy open for editing, and let it go in the Situation column.
Alternatively, you can right-click on the offending event > Create Rule > Do Not Log Connection. This would automatically generate a rule that you could then add to the Exceptions of your
inspection policy.
63
Figure 85: Generating a rule from a log entry
5. Right-click in the Source and Destination columns > Set to ANY, you may leave the Severity,Logical Interface and Protocol columns set to ANY.
6. Leave the Action set to Permit.
7. Right-click in the Logging column, and select Edit Logging.
8. Check the box next to Override Settings Inherited from Continue Rules.
9. In the drop-down box for Log Level, leave it set to None, click OK.
64
Figure 86: Logging for a false positive rule
10. Click the Save button.
11. Click the Home view tab.
If the Home view is not open, right-click on the Home button in the menu bar and select Open in
New Tab.
12. Right-click HQ FW then Current Policy > Refresh as in the figure below.
65
Figure 87: Refreshing the Engine Security Policy
Alternatively, in the Home view, you can click the HQ FW and click the Commit Changes button in
the Pending Changes pane.
13. In the Refresh Policy Properties dialog box, click OK. After the policy installation is completed, the
event will no longer appear in the logs.
7.6
Blocking An Attack
In the last exercise, you created a rule that prevented a false positive from being logged. You will now use
a similar set of steps to prevent an attack that was permitted.
1. In your inspection policy that is still open for editing, verify that you have the Exceptions Tab selected,
create a new empty rule by right-clicking in the ID column > Add Rule After.
2. Leave the Situation column blank for the moment and set the other fields to ANY.
3. In the Action column, right-click and select Terminate.
4. Right-click in the Logging column, and select Edit Logging.
5. Check the box next to Override Settings Inherited from Continue Rules.
6. Set the log level to Alert, click OK.
66
Figure 88: Setting the Log Level to Alert
7. Return to the tab where the Inspection Logs are still running.
8. Locate an instance of the Generic_CS-Donbot-Spambot.
If you do not see any log, go to the last log record icon to display the last stored records.
Figure 89: Last log record button
9. Click and hold the event, drag it the tab where your inspection policy is open for editing, and let it go
in the situation column of the rule you just created.
Your completed rule should look like the figure below.
Figure 90: Completed bot termination rule
10. Save your inspection policy and refresh the firewall policy as in the last exercise.
11. From your HQ Workstation, double-click the StopTraffic shortcut, followed by the StartTraffic shortcut.
12. In the Logs view tab, click the Current Mode button to see the logs in real time.
67
Future occurrences of the Generic_CS-Donbot-Spambot will now be terminated and an alert will be generated. Verify this by examining the logs. Alerts generated by the Generic_CS-Donbot-Spambot situations
are also visible in the Home view. They will appear in the Alert pane in the Potential Compromise category.
68
8
Lab 8: Automated alerting and notifications
Goals of this lab
As an administrator, it is very important to know when particularly interesting things occur in the firewall
environment. This could be related to the functioning of the management environment or when deep inspection detects malware. To accomplish this, you will learn how to use automated alerting and notifications
to bring an event of interest to your attention through different methods. You will learn how engine logging
and the SMC work together so that you are always informed.
8.1
Configure the management server for alerting
In this exercise you will configure the management server for automated alerting.
1. Click the tab where the Home view is open.
2. At the bottom left, expand Others.
3. Right-click on the Management Server > Properties.
Figure 91: Management server properties
4. Click on the Notifications tab.
5. In the SMTP Server field, click the Select button, the Select Element dialog opens.
6. Click on the "gear" icon > New > SMTP Server, the SMTP Server Properties dialog box opens.
7. In the Name field, enter mail.training.com.
8. Click the Resolve button. The IP address of the mail server appears.
If the IP address that appears is different the figure below, this is normal for the lab environment.
69
9. In the Default Sender Name field, enter trainingadmin.
10. In the Default Sender E-Mail field, enter trainingadmin@training.com.
Figure 92: SMTP server properties
11. Click OK. The SMTP Server Properties dialog will close.
12. Click Select in the remaining window to select your new mail server.
13. In the Sender Name (where the Management Server properties are still open), enter trainingadmin.
14. In the Sender Address field, enter trainingadmin@training.com Your configured Notifications should
appear as in the figure below.
70
Figure 93: Notification management configuration
15. Click OK.
16. Click YES to close the warning dialog box.
8.2
Configure an Alert Chain
In this exercise, you will create an Alert Chain to specify the sequence of events to follow in the event that
alert is raised.
1. Click the tab where the Configuration View is open.
2. On the left, browse to Administration > Alert Configurations > Alert Chains.
3. On the right, right-click and select New Alert Chain, the Alert Chain Properties dialog box opens.
71
Figure 94: Creating a new Alert Chain
4. In the Name field, enter HQ Chain and click OK.
5. The HQ Chain properties opens. Right-click on Final Action and select Add Rule.
6. Configure the rule as follows:
• Channel: Click in the Channel field and select SMTP.
• Destination: Double-click the Destination field and enter alertadmin@training.com.
• Threshold to Block: Set to 10 alerts in 10 min.
7. Add another rule by right-clicking in the ID column > Add Rule After.
8. Configure the rule as follows:
• Channel: USER NOTIFICATION
• Destination: root
To find the root user, use the resources panel on the left and
and drag the root user into the Destination cell.
• Threshold to Block: Cannot be edited with User Notification
Your configured Alert Chain should be configured as in the figure below:
Figure 95: Completed alert chain
9. Click the Save icon. You may close the Policy Chain tab.
8.3
Create A custom alert
Alerting can occur based on a number of conditions, such as events related to the functioning of the SMC
and policy rules that have the log level set to Alert. In order to properly test the alerting capabilities of the
SMC, you will need to create a custom alert and use this in an inspection rule that you created in Lab 5.
72
1. Click the tab where the Configuration view is open and browse to Administration > Alert Configurations > Alerts.
2. In the upper right-hand corner, click the New icon > Custom Alert, the Custom Alert Properties
dialog box opens.
3. In the Name field, enter HQ Alert.
4. In the Situation Type, select Attacks.
Figure 96: Custom alert properties
5. Optionally, you may enter a message in the Message field.
6. Click OK.
8.4
Configure an Alert Policy
Now that the chain of events has been created, by first sending an email, and then user notification through
the management interface, you must configure the policy that will start the chain of events from the last
exercise.
1. In the tree view on the left, click on Alert Policies.
2. Right-click in the white space on the left and select New Alert Policy.
3. In the box that appears, in the Name field, enter HQ Alert Policy.
73
Figure 97: HQ Alert Policy creation
4. Click OK.
5. The HQ Alert policy is now open for editing. Right-click on the rule that says Return > Add Rule.
6. Configure the rule as follows:
• Sender: ANY
• Alert and Situation: click in the Alert and Situation column. In the Resource Pane on the left,
click on Alerts, the drag and drop the HQ Alert into the Alerts and Situation column.
• Chain: Click in the Chain field and select HQ Chain.
Your fully configured Alert Policy should look like the figure below.
Figure 98: Completed alert policy
7. Click the Save and Install icon to save the policy and upload it to the Shared Domain.
8. In the window that appears, click on Shared Domain and click Add.
74
Figure 99: Uploading the HQ Alert Policy
9. Click OK. You may close the Alert Policy tab.
8.5
Add custom alerting in a Security Policy
When a rule matches that has the logging level set to Alert, the Alert Chain and Alert Policy can be processed so that administrators receive alerts via channels such as SMTP. To make this happen, your custom
alert, created above, must be added to a policy rule. In this exercise, you will add your custom alert to an
Inspection Policy Exception rule. When this rule matches, the Alert Policy and Alert Chain are processed
to generate an email that is sent to the administrator.
1. Click the tab where the HQ Inspection Policy is open for editing.
If HQ Inspection Policy is not already open for editing, click the Configuration button in the menu
bar and browse to NGFW > Policies > Inspection Policy, right-click HQ Inspection Policy >
Edit Inspection Policy HQ Inspection Policy. The policy opens for editing.
2. Switch to the Exceptions Tab.
3. Locate the rule where HTTP_CSH-Locky-B-Control-Traffic is being permitted and change the action
to Terminate.
4. In the logging column, right-click and select Edit Logging. The logging options appear.
5. Change the logging level to Alert.
6. In the Alert field, select the HQ Alert that you created in section 8.3.
7. Click OK.
8. Save the HQ Inspection Policy.
75
9. Install the Student HQ Policy again on the HQ FW.
You are now configured to receive alerts should that rule match. The fully configured inspection rule should
look like the following.
Figure 100: Completed policy alert rule
76
9
Lab 9: Preparing for User Authentication
Goals of This Lab
User authentication is a critical feature needed for ensuring that access to particular resources is controlled,
depending on the network user. User authentication can be used to control access to resources on the
network or provide access to the network for remote users. Regardless of how it is to be used, there are
steps that must be taken to configure the SMC for user authentication. This can be accomplished in many
ways such as using the internal LDAP database, or, more commonly, integrating external user storage such
as LDAP Server or Active Directory. In this lab, you will use an external LDAP database, where you will add
users and prepare the SMC for user authentication.
9.1
Create an LDAP Server element
Before user authentication can work, you have to integrate a directory service (typically Active Directory
or an LDAP server) with the SMC. In the simplest case, you can also use the internal LDAP database in
the SMC, but that is not particularly scalable in large environments. In fact, most organizations will already
have a user storage mechanism. In this exercise, you will add an external LDAP server and integrate it with
the SMC.
1. Click the tab where the Configuration view is open and browse to User Authentication > Servers.
If the view is closed, open a new tab and click User Authentication.
2. On the right, click on Servers. In the white space, right-click New > LDAP Server.
3. In the name field of the LDAP Server Properties that opens, enter 172.31.200.215.
4. .The IP address of the directory server appears.
5. Configure the LDAP Server properties as follows:
• Base DN: dc=training,dc=com
• Bind User ID: cn=Manager,dc=training,dc=com
• Bind Password: Forcepoint1
6. Click the Check Connectivity button to verify communication.
If you cannot see the check connectivity button or click the OK button, you can swap between the
full size and custom size of the LDAP Server Properties window.
77
Figure 102: LDAP Server attributes
7. Click on the Authentication Tab. Click the Add button.
8. In the dialog box that appears, click on LDAP Authentication and click Select.
9. Click OK to close the server properties.
If you receive the duplicate IP warning message, click Yes to close it.
9.2
Add a new LDAP domain
Now that you have added the LDAP server, you must now add the domain for which the LDAP server is
storing users and the default authentication associated to the domain.
1. On the left side tree view, click on Users.
2. In the white space to the right, right-click and select New > External LDAP Domain.
78
3. In the Name field, enter training.com.
4. Under the Servers column, click on the directory.training.com and click the Add button. The server
should now appear under the Bound Servers column.
5. Make sure that the Default LDAP Domain is checked.
Figure 103: Adding a new LDAP domain
6. Click on the Default Authentication tab and click the Select button.
7. In the dialog box that appears, click on LDAP Authentication and click Select. LDAP authentication
will be used as the authentication method for the external training domain.
8. Click OK to close the Properties window.
Figure 104: LDAP Domain default authentication
79
9. On the new domain you just added, expand it to ensure the integration was successful. You should
see one user, Student.
9.3
Create a new user
You have now integrated the LDAP server and its associated domain with the SMC. Now you must add a
user. Adding users to an LDAP domain from the SMC is not possible.
1. On the desktop of your workstation, open the GNS3 machine click the icon for Windows2012R2.
Figure 105: LDAP
2. Doubl-click to open the terminal session
Figure 106: LDAP server
3. A window appears, in which you will login on the server.
Figure 107: Connecting to the training LDAP server
80
4. At the top of the tree view, right-click dc=training, dc=com [172.31.200.215] > New > User. The
user attributes open.
5. The user properties should be configured as in the figure below.
• First name: Bob
• Second name: Robertson
• Username: brobertson
• Home Directory: /home/remote
Figure 108: New LDAP user properties
6. Click OK to add the user.
7. It is time now to create a password for the new user, on the user you just created, right-click and select
Set Password in the menu that appears.
8. In the New Password field, enter Pass1234 and confirm it.
9. Click OK to close the window.
10. You may now return to the management client and close the LdapAdmin window.
11. Expand the training domain, right-click and Refresh View. You should now see your new user.
81
Figure 109: Addition of a new user to an LDAP domain
LDAP Authentication method allows direct authentication with an LDAP server instead of configuring
additional RADIUS or TACACS services to provide authentication.
82
10
Lab 10: Browser-based Authentication
Goals of this lab
In the previous lab, you configured the environment so that user authentication can be used for several
things such as browser-based access control and remote access, via IPSec or SSL VPNs. In this lab,
you will configure browser-based authentication that will force a network user to authenticate to the firewall
before they can access the internet. Further, you will use a combination of access rules and deep inspection
to seamlessly redirect users to their intended destination after successfully authenticating to the firewall. In
this lab, users behind the firewall will be forced to authenticate before accessing the internet on HTTP.
10.1
Configure the firewall for user authentication
Now that a user store mechanism and its associated domain has been added, you can now use the user
information stored there for authentication purposes. As is the case with this exercise, this can be for
browser-based authentication or for SSL VPN and IPSec. You will now configure the firewall for browserbased authentication.
1. Click the tab where the Home view is open. If the Home view is closed, right-click on the Home
button from the menu bar and select Open in New Tab.
2. Right-click on the HQ FW and select Edit Single Firewall HQ FW. The firewall properties open.
3. On the left, expand Add-Ons and select User Authentication.
4. Check the box next to HTTP and ensure the port number is 80.
5. In the Listen On Interfaces area, click Selected and check the box for Interface 1 (172.31.200.1).
6. Next to User Authentication Page, select Default User Authentication Pages.
7. Check the box next to Enable Session Handling.
83
Figure 110: Configuring HQ FW for user authentication
8. Click the Save button and close the firewall editor.
10.2
Create a rule requiring authentication for internet access
Now that the firewall is configured to listen on the internal interface for authentication requests, you must
now add two rules to the firewall policy that will force users to authenticate before proceeding to the internet
using HTTP.
When a user successfully authenticates, they are not automatically redirected to their original destination. Although possible, there are more steps required to enable that action.
1. Click the tab where the Student HQ Policy is open for editing. If the Student HQ Policy is closed,
from the Home view, right-click on the HQ FW > Current Policy > Edit.
2. Right-click in the ID column of the last rule and select Add Rule Before.
3. Repeat the same procedure for the rule you just added, so that you now have two blank rules.
4. Configure the first rule with the following (the rule closer to the top):
84
• Source: Click inside the source of the last rule and drag the network-172.31.200.0/24 object
into the Source column.
• Destination: not HQ Training Networks (this can be dragged from the destination of the last
rule)
• Service: Click in the service cell, type 80, and select HTTP from the list.
• Action: Allow.
• Authentication: Right-click > Edit Authentication. The Authentication Parameters opens.
5. In the Users tab, on the left side, click Users > training.com > training, click on brobertson and
click the Add button.
Figure 111: Rule Authentication Parameters
6. Click the Authentication Methods tab, then click on LDAP Authentication, click Add so that it is
added to the list of Accepted Authentication Methods.
Figure 112: User password authentication
7. Click OK to close the Authentication Parameters window.
85
8. The Source, Destination, and Service should be the same for the second rule you added.
9. In the second rule you added, closer to the bottom, set the Action to Discard.
10. Right-click in the Action column of the same rule, and select Edit Options.
10.3
Create an HTML response to users
Now you will configure the response that users will receive from the firewall when they attempt access to
the internet.
1. Click the Response tab.
2. Check the box for Override Settings Inherited from Continue Rules.
3. Next to the User response field, click Select.
4. In the window that opens, click the “gear” icon > New > User Response. The User Response
Properties window opens.
5. In the Name field, enter HQ Internet Access Response.
6. Click on Connection Discarded by Access Rule.
7. In the Type of Response field, select URL Redirection.
8. For the URL, type http://172.31.200.1, the firewall’s internal interface.
9. Check both boxes for Enable Manual Redirection to Original URL After Authentication and Enable Automatic Redirection to Original URL After Authentication.
86
Figure 113: User Response Properties
10. Click OK.
11. Your new response should be highlighted, and click Select.
12. Click OK to close the Rule Action Options.
13. Save and Install the firewall policy.
Your new user authentication rules should look like the figure below.
Figure 114: User authentication rules
87
10.4
Testing Browser-Based Authentication
To test your authentication rules, open a web browser on your workstation, and attempt to access http://training.com. What
is the result? Note: Use Ctrl+F5 to force the reload of the http://training.com Web page if the
NGFW authentication page is not displayed.
1. Supply the credentials for brobertson with the password Pass1234.
2. After successfully authenticating, you will receive a page that tells you when you session will expire.
Notice the button to Re-Authenticate at the bottom of the session details page. If this tab is kept
open, it can be used to refresh the authentication before it expires and prevent work from being
interrupted.
3. Open a new tab and attempt to access http://training.com again. What is the result?
88
11
Lab 11: Configuring the SSL VPN
Goals of This Lab
With the Forcepoint NGFW, there are two ways to offer remote access to users outside of your network:
using the SSL VPN or the IPSec VPN. Both have their advantages. This lab will focus on the configuration
of an SSL VPN. The advantages of an SSL VPN are mainly its broad support of different operating systems.
Generally, all that is necessary is a web browser, though Forcepoint does offer dedicated SSL VPN clients
for Mac OS X, Android, and Windows. You will configure the SSL VPN to be used through a web browser
by creating a portal to which you will publish web services that allow access to specific internal resources.
11.1
Create a web service
In order to reach internal resources through the SSL VPN, you first have to make a resource available in
the portal. To do that, you will create a web service that allows access to the DMZ web server.
1. Click the tab where the Configuration view is open and browse to SD-WAN. If the view is closed,
open a new tab. Under the Configuration section, click SD-WAN.
2. On the left, expand SSL VPN Portal and click on SSL VPN Portal Services.
3. Right-click in the white space on the right, and select New SSL VPN Portal Service. The Portal
Service Properties opens.
4. In the Name field, type HQDMZWWW.
5. In the External URL Prefix field, type /intranet-www.
6. In the Internal URL field, enter http://192.168.2.150/.
89
Figure 115: SSL VPN Web Service Properties 1
7. Switch to the Look & Feel tab, ensure that the Visible in Portal box is checked.
8. In the Title field, enter DMZ Web Services. Click OK to close the window.
11.2
Create an SSL VPN policy
You have now created a service that can be made available in the portal. You now need to configure a
policy for publishing one or more services.
1. On the left, click on SSL VPN Portal Policies.
2. In the white space on the right, right-click and select New SSL VPN Portal Policy.
3. In the Name field, enter HQ Portal Policy, click OK. The policy opens for editing.
4. On the Discard All rule, right-click and select Add Rule.
5. On the left, click on SSL VPN Portal Services. Drag the HQDMZWWW service into the SSL VPN
Portal Service column.
6. Click into the Authentication column. On the left, click Users > training.com > training and drag
brobertson into the Authentication column. Click Save.
90
Figure 116: SSL VPN Portal Policy
7. You may now close the tab.
11.3
Create the SSL VPN Portal
You have now created two components that together do not constitute an SSL VPN portal. You must now
combine these in the form of a portal that will be associated with an engine.
1. On the Configuration view tab where you were working with the SSL VPN components, click on SSL
VPN Portals.
2. In the white space on the right, right-click and select New SSL VPN Portal.
3. In the Name field, enter HQSSLVPNPortal.
No spaces are allowed in this name.
4. In the SSL VPN Portal Policy field, click Select. In the window that opens, click on HQ Portal Policy
and click Select. The window closes.
5. In the Hostnames field, add ssl-vpn.training.com.
6. In an operational environment, you would want to upload the server certificates here. However, since
this is a testing/training scenario, you will check Use Self-Signed Certificate.
91
Figure 117: SSL VPN Portal Properties General tab
7. Click on the Look & Feel tab. In the Title field, enter HQ Internal WWW. Leave the Look & Feel set
to Forcepoint.
8. Click the Target Engine tab. Click the Add button. A new row is added.
9. In the Target Engine column, double-click and select HQ FW. Click Select. The selection window
closes.
Figure 118: Target Engine Selection
10. Click OK to complete the portal configuration.
11. Refresh the policy on the HQ FW.
92
11.4
Testing the SSL VPN Portal
Now that you have created the portal, it’s time to test it. To do that, you will open a console to the Partner
Internal Server and perform your test.
1. Open a console to the Parter Internal Server. If you are using the Forcepoint Go4Labs lab environment, use the connections in the mRemoteNG application on the Landing Machine and open a
console to the Parter Server
2. The login for the server is user Student and the password is Forcepoint1
3. Open a web browser. There is a shortcut to Firefox on the launch bar at the top
4. Enter https://ssl-vpn.training.com in the url field
5. Click the Advanced button and click Add Exception to accept the browser warning message related
to certificate authenticity. This arises from the fact that you selected the Use Self-Signed Certificate
option. Then click Confirm Security Exception.
6. Login with user brobertson with the password Pass1234.
Figure 119: Successful access to the SSL VPN portal
7. Click the DMZ Web Services icon and you should be able to access the website on the DMZ server.
93
Figure 120: Access to DMZ website
If the page remains blank, click the URL bar and press enter to reload the page.
94
12
Lab 12: Creating a Site-to-Site IPSec VPN
Goals of This Lab
Life as a firewall administrator will almost certainly involve the creation of a site-to-site VPN between your
network and that of a business partner or a remote location. When creating IPSec VPNs, the most simple
scenario is one in which a site-to-site VPN is being created between two Forcepoint NGFWs that you are
managing. However, this will not always be the case. In fact, it is more probable that the VPN will be
between a Forcepoint NGFW and some other vendor. This lab will focus on the later scenario where the
remote side of the VPN is a different vendor.
12.1
Create the External VPN Gateway
Before you can begin creating the VPN, you must first define the External VPN Gateway. By definition,
this is a firewall from another vendor or another Forcepoint NGFW that you are not managing. The external
security gateway represents the firewall on the other end of the connection.
1. Click the tab where the Configuration view is open and browse to SD-WAN. If the view is closed,
open a new tab. Under the Configuration section, click SD-WAN.
2. Right-click Policy-Based VPNs and select New Policy-Based VPN. The Policy-Based VPN Properties opens.
3. Name the element Partner-HQ. Leave the Default VPN Profile set to Suite-B-GCM-128. Click OK.
Figure 121: Policy-Based VPN Properties
4. The VPN editor opens. On the left side, click Central Gateways. Then right-click and select New
External VPN Gateway.
95
5. In the Name field, enter Partner. Leave the Gateway Profile set to Default (all capabilities).
Figure 122: Partner External VPN Gateway Properties
6. Click on the Endpoints tab, right-click and select New External Endpoint.
7. In the Name field, enter Parter EP.
8. In the IP Address field, enter 130.207.200.79, accepting the defaults in the other fields.
The remaining settings would likely have to used in cases where the remote endpoint was behind a
device performing NAT.
Figure 123: External Endpoint Properties
96
9. Click OK. The Endpoint properties closes.
10. Click the checkbox next to the endpoint you just defined to enable it.
11. Click on the Sites tab.
12. Under the Network Elements selection, browse to Networks. Locate the network-10.100.100.0/24
element and click Add Your completed site definition should look as in the figure below:
Figure 124: Completed Partner Site definition
13. Click OK, the Site Properties closes. Click OK on the Partner gateway properties.
The definition of the external security gateway is now complete. You can now create the topology.
12.2
Configure the VPN topology
In this exercise, you will create the VPN topology. Since this is a site-to-site VPN involving only two gateway,
this is a fairly simple procedure.
1. In the list of gateways on the left, drag the HQ FW - Primary under the Central Gateways column
and drag the Partner gateway under the Satellite Gateways column.
Figure 125: Site-To-Site VPN Topology
97
The VPN topology is now created. It’s time to move on to selecting the security settings used for IPSec.
12.3
Create a custom VPN Profile
A VPN Profile is used to define the settings for Phase 1 and Phase 2 of an IPSec VPN. This exercise
assumes that you have been in touch with the administrator of the partner site, who has provided you the
settings for the Partner firewall. Those will be part of the VPN Profile.
1. Click on the Tunnels tab. On the left side, click the New icon, and select VPN Profile. The Profile
Properties opens.
2. In the name field, enter Partner-HQ-Profile.
3. Click on the IKE SA tab, select the following for the IKE Phase 1 settings:
• Versions: IKEv2
• Cipher Algorithms: AES-256
• Message Digest Algorithm: SHA-2 256
• Diffie-Hellman Groups: 5 (1536 bits)
• Authentication Method: Pre-shared Key
• SA Lifetime in Minutes: 180
98
Figure 126: IKE SA Properties
4. Click on the IPsec SA tab and select the following settings:
• IPsec Type: ESP
• Cipher Algorithms: 3DES
• Message Digest Algorithms: MD5
• Compression Algorithms: None
• IPsec Tunnel Lifetime: 60 min
• Security Association Granularity: SA per Net
99
Figure 127: IPsec SA Properties
5. Click OK
The hard part is done. Now you must use the new VPN Profile so that the two firewalls can properly
negotiate communications.
1. Under the Gateway <-> Gateway section, click under the VPN Profile column and select the PartnerHQ-Profile. if the Partner-HQ-Profile is not in the list, click Select.
2. Double-click under the Key column. Set the pre-shared key as hqpartnervpn. Click OK .
3. Click the Save button.
In reality, the pre-shared key should be as complex as practically possible. Optionally, there is a
Generate button that will produce a sufficiently complex pre-shared key that would need to communicate to the administrator of the partner site.
The completed configuration should look as in the figure below.
100
Figure 128: Completed tunnels configuration
12.4
Add VPN rules to Security Policy
The last remaining step is to configure the policy to enforce the VPN for matching packets. For this, you
will create two rules, one permitting traffic from HQ to your partner and the other permitting traffic from your
partner to the HQ.
1. Click the tab where the Student HQ Policy is open for editing. If the Student HQ Policy is closed,
from the Home view, right-click on the HQ FW > Current Policy > Edit.
2. Right-click on first rule in the Inbound Traffic rule section and select Add Rule Before. Repeat this
step so that you have two empty rules.
3. In the first empty rule, configure the following:
• Source: network-172.31.200.0/24
• Destination: network-10.100.100.0/24
• Service: Click in the Service column. On the left, browse to Services > ICMP and drag
Ping into the Service column. In the same column, type 80, and select HTTP from the list that
appears.
• Action: Right-click and select Allow. Right-click again and select Edit Options. The Action
Options window opens.
Under the VPN Action section, select Enforce VPN. Under the VPN section, click the Select
button and select the Partner-HQ VPN that appears in the window. Click Select, the window
closes. Then, press OK. The Action Options window closes.
4. Repeat the last step for the next rule, except you will swap the source and destination.
5. Click the Save and Install icon to upload the policy.
Your completed VPN rules should look as the figure below.
Figure 129: Completed Site-to-Site VPN rules
101
12.5
Testing access to and from the Partner network
Now you must test your VPN.
1. On your workstation, open a command prompt Start > Run and type cmd.exe.
2. Issue the command: ping 10.100.100.50. This is the IP of the partner server behind the Partner
firewall.
3. In the Home view, browse to the SD-WAN section. Does the status of the Partner-HQ VPN change
(color)?
Another way to view information about the status of the VPN is to verify that IPSec SAs are properly
negotiated.
1. Click the plus (+) sign at the top to open a new tab.
2. Click the VPN SAs button, the element selection window opens.
Figure 130: VPN SA monitoring
3. Navigate to Firewalls > HQ FW, click select and the currently negotiated SAs appear. You may close
this tab when the lab is completed.
102
13
Lab 13: Advanced Log Usage
Goals of this lab
In Lab 3, you learned the basic usage of logs for locating events of interest, mainly by filtering. However,
there is a great deal more that make the logs indispensable. Should there ever be an issue with which you
require support, diagnostic logs can provide nearly debug level information that can help locate the cause
and nature of a problem. When you are adding rules, attempting to locate a rule that could be problematic,
or locating which administrator performed a particular action, there are several other tools available in the
SMC that this lab will demonstrate. Security policy rules and logs are inextricably linked, and this lab will
highlight the usefulness of that relationship.
13.1
Enable diagnostic logs
Occasionally, the need will arise to see deeper detail related to a specific component of the firewall. Common examples would be VPN, clustering, deep inspection, and authentication. Each of the processes in the
firewall is referred to as a “facility”. Each of these has their own diagnostic logs. These are human readable
and go to the log server and can be viewed in the log view.
After they are enabled, be sure to disable them as they have the potential to generate high log
volume.
To enable diagnostic logs, perform the following steps:
1. Click the tab where the Home view is open. If one isn’t open already, click the Home icon on the
menu bar.
2. Right-click on the HQ FW > Options > Diagnostics. The diagnostics selection opens.
3. Check Authentication and VPN. There is no need to upload the policy. These changes take effect
immediately.
103
Figure 131: Diagnostic log selection
4. Click OK.
5. To test this, select the HQ FW in the home view. In the Drill-Down pane on the right, select Monitoring > VPN SAs.
6. Click the tab where the Logs view is open. If one isn’t open already, right-click the Logs icon > Open
in New Tab.
7. In the Query Panel, use the drop-down menu > Select. The facility selection opens.
8. From the list, click VPN and click Select. If VPN does not appear in the list, click Select to open the
selection dialog box.
104
Figure 132: Selecting VPN log context
9. Click Apply.
10. Click the Current Mode button in the menu bar to see the logs in real time.
11. In the tab where the VPN SA monitoring view is open, right-click and delete the IKEv2 SA. Click Yes
to confirm.
12. On your workstation, in the cmd terminal, issue the command: ping 10.100.100.50 again.
13. In the tab where the VPN logs are open, observe the effect of enabling IPSec diagnostics. Look at
the Information Message column, scrolling to far right side, for details about the VPN negotiation.
14. After some period of time, repeat the steps above to turn off diagnostic logging. You may also close
the VPN SA monitoring view.
13.2
View rule counters
One of the best ways to determine the effectiveness of a firewall policy and tune it is through the use of rule
hit counters. Every time a rule is matched, the counter increases. Using rule counters, you can determine
if rules that match more frequently should be higher in the rule base to reduce work on the firewall. Also,
for purposes of troubleshooting, you can find out if packets are matching a particular. Below, you will see
how to use them.
As you proceed from here, you need to make sure some of the more mundane tasks, such as opening a
policy for editing, are starting to become more second nature. Therefore, some of the detail above will be
omitted. If you have questions, please ask your instructor.
1. Click the tab where the Student HQ Policy is open for editing.
2. Scroll to far right side of the policy, and you see the Hits column.
3. Click the “gear” icon in the upper right, and select Rule Counters. The Rule Counter Analysis
window opens.
105
4. Select the period for 1 Week.
5. If the Target Engine section is not auto-populated with the HQ FW, click the Add button, select the
HQ FW from the list and click Select.
6. Click OK. The Hits column is now populated with data from the last week.
Figure 133: Rule Counter Analysis
13.3
Exporting logs
From time to time, you may wish to export logs for auditing, management, or support. Exporting logs can
take several forms, both manual and automated. Here, you will see how to take log entries and export them
to PDF.
1. Click the tab where the Logs view is open. You may select Security Engine logs in the Quey panel
and click Apply to see all log events generated by your engine.
2. Click on a log entry, hold down the Shift Key and click another log entry far below the first. The
selected logs will turn a slightly gray color.
3. Right-click somewhere on the logs, and select Export > Export Log Events.
106
Figure 134: Exporting log entries
4. There are a number of options for which format you might like to use, such as CSV, a zip archive, or
popular SIEM formats such as ArcSight, Q1, and McAfee ESM. For these purposes of this exercise,
choose Export CSV.
5. For the Destination File, select Local Workstation.
6. Click the Browse button and select Documents.
7. Enter the file name as Logs-Export.csv and click Select.
Figure 135: Exporting logs to CSV
8. Click OK and the logs export completes.
107
Logs can also be printed to PDF for a more readable experience.
1. With the same logs selected, right-click and select Print.
2. Select Print to File and click Browse.
3. Enter the file name as Logs-PDF, double-click the Documents folder.
4. Click Select and Click OK. The logs are exported to a PDF file.
5. Open the files you just exported.
13.4
Using rule tags
Rule tags are one of the most useful features in the SMC. They relate logs to rules, and rules to logs. They
can be used to see which log entries were generated by which rules, and which rule generated a particular
log entry. Let’s see how they can be used.
1. With the log view still open, scroll to the right and locate the Rule Tag column.
2. Right-click on the Rule Tag of a connection that has been allowed, and select View Rule.
Figure 136: Viewing a policy rule from a rule tag
3. The view then switches and highlights the specific rule that created that log entry from the correct
policy. This is possible because the rule tag is unique to every rule in every policy.
Now, let’s look at this in reverse.
1. In the view where your security policy opened, choose the rule where deep inspection is enabled.
Right-click on the ID column value and select Show Related Logs. What happens?
108
Figure 137: Viewing logs related to a rule
2. Close the log view that just opened.
13.5
Using Audit Logs
For keeping track of what actions were performed by whom and when, there is no better resource than the
Audit Logs. Any change that is made to any aspect of the system is recorded in the Audit logs as well as
who made the change. They are very useful for reverse engineering mistakes, problematic policy additions,
and for auditors. Let’s see how to use them.
1. Click the tab where the Logs view is open. Make sure that there is no filter defined in the Query
pane. Clear filters if necessary.
2. Just below the word Query on the right side, click the drop-down box, and select Audit.
3. Click Apply. The view changes to show the Audit Logs.
4. Click the Statistics button and select Create From Item.
5. A large list of items appears. Type the word admin, the list narrows. Select Audit records by
admin/origin, operation, result, SMC and click Select.
109
Figure 138: Audit log statistics
A graph is shown depicting who made what change to what object and the result. Remember that you can
drill into any part of the resultant graph to see the individual records.
110
14
Lab 14: Tools for the SMC and Policy Management
Goals of this lab
In the previous lab, you learned the extent to which logs can be used for different purposes. This lab will
focus on some of the SMC tools that relate to finding information about policies or information in policies.
As you continue to build the skills necessary to troubleshoot and solve various issues that could arise in the
course of administration, this lab will familiarize you with tools that are more specific to policies. If issues
related to policies arise, after the successful completion of this lab, you will be equipped with the knowledge
required to locate information in a policy or troubleshoot problems.
14.1
Compare the current policy with a snapshot
Every time a policy is uploaded, a snapshot is created. These can be used later for comparison purpose for,
among other things, reverse engineering a potential mistake in a policy or finding which addition or deletion
to a policy resulted in a problem.
1. Click the tab where the Configuration view is open. If the view is closed, open a new tab and click
NGFW.
2. Browse to NGFW > Other Elements > Policy Snapshots > Firewall Policy Snapshots.
3. In the list on the right, choose a snapshot of one of your earlier uploads.
4. Right-click on the selected policy snapshot, select Compare > Compare Snapshot to Engine’s
Current Policy.
5. In the lower pane, you will see a list of objects that have been added, modified, deleted, the engines
that were effected, and any changes with respect to rules. You can click on a rule intry in the list to
see the details of the changes.
111
Figure 139: Policy comparison - list view
There is also another way to see what has changed in the policy. Below the two compared policies, there
is a separator with a small “up arrow” and “down arrow”. Press the “down arrow” so that the view of the
policies is expanded. Note that the differences in the policies are more visually represented. Which view is
more informative is simply a matter of preference.
14.2
Using the policy search tool
This tool can be very helpful in complex policies. In cases where there are hundreds or even thousands
of rules, scrolling through all of them with a fine-toothed comb can be time-consuming and difficult. The
policy search tool can be of great benefit in this regard. Let’s look at a simple example meant to highlight
its function.
1. Click the tab where the Student HQ Policy is open for editing.
2. Click the “gear” icon in the upper right and click Search Rules. At the bottom of the policy, a Search
Rules input box appears.
3. In the Source cell, enter 87.35.16.200 and in the Destination cell, enter 212.20.0.150. The rule that
would match such a packet with that header information is highlighted.
112
Figure 140: Using the rule search feature
14.3
Enabling network details
One particularly annoying aspect of working with firewalls, especially in cases where IP Addresses are
obfuscated by object names, is easily figuring out their actual values without having to look at the properties
of the object. To deal with this, there is a very simple solution.
1. With your policy still open, click on the “gear” icon and select Network Details. The network details
are now displayed.
Some objects may not populate with network details, particularly if they are dynamic object such as domain
object.
Figure 141: Enabling Network Details
113
15
Lab 15: Monitoring, Overviews and Reporting
Goals of This Lab
In addition to administrators, there are many more audiences to which the information collected by the SMC
would be of great value. These include, but are not limited to, operations, security, management, auditors,
and Forcepoint support. This lab will familiarize you with the situational awareness provided by overviews
and the creation of reports that can used for a variety of audiences.
15.1
Create and customize a new overview
You can think of overviews as a moving picture of your network. As logging data arrives, that information
is fed into overviews to provide a near real-time picture of activity on the network. In this exercise, you will
create a new overview and customize it.
1. On the menu bar at the top, click on Overviews.
2. Select New Overview. The Overview Properties window opens.
3. From the list, select the Default Overview that you will use as a starting point. Click OK.
4. With the overview open, click the “x” in the upper right corner of the System Summary Panel.
5. Click the New icon, and select Firewall Summary (Counters).
If Firewall Summary is not in the list, click Select and select the Firewall Summary (Counters)
from the available sections.
6. Click the “x” in the corner of Records by Data Type.
7. Drag the right side of Firewall Summary (Counters) to the left edge of Load By Sender.
8. Click the “x” in the corner of Top Destinations-1 Hour to remove it.
9. Drag the right side of Top Sources-1 Hour to the left side of Traffic Summary-1 Hour.
10. Lastly, experiment with different ways of visualizing the data in the Top Sources-1 Hour by clicking
on the section header and changing the graph type and the summary type (Top Rate, Progress, or
other) under the Section Properties on the right.
11. When you are done experimenting, click the Save button, and choose a name for your new overview.
There are an infinite number of ways that you can configure overviews. Choose what suits your needs best.
15.2
Schedule and generate a built-in report and export it to PDF
Much as you did in an earlier lab, you will now use the task system again to schedule report generation.
Reports can be viewed in the SMC or they can be exported to a format, such as PDF. You will now create
a report and schedule its generation.
114
1. Click the tab where the Configuration view is open and browse to Monitoring. If the view is closed,
open a new tab and click on Monitoring.
2. On the left side, browse to Reports > Design.
3. In the white space on the right, right-click and select New Report Design.
Figure 142: Report design selection
4. In the list, select Firewall Daily Summary from All Firewalls and click OK.
5. The report design opens. Click the Save button and give the report a new name, HQ Firewalls
Summary and click OK. You may now close the HQ Firewalls Summary tab.
6. In the Design tab, right-click on your new report, and select Start.
115
Figure 143: Report Operation Properties
7. Click on the Task tab.
8. Under the Repeat section, click the Every Day radio button.
9. Check Store Report and PDF Export.
10. For the email address, enter admin@training.com.
116
Figure 144: Completed report scheduling
11. Click OK. The report will now run, and for every day going forward at the selected time.
12. After the report completes, it will appear in under the History section.
Figure 145: List of generated reports
13. Double-click the new report and view it.
14. In the upper right corner, click the Print button. The Print Report to... dialog box opens.
15. Make sure that the Format is set to PDF.
16. Click OK.
The way that the report appears in the SMC differs greatly from how it will look when exported to
PDF or other format.
117
15.3
Create a simple custom report
Now you will create a simple report that is customized to your needs.
1. In the tab showing your firewall report, click the back arrow in the main menu bar to go back to the
Reports section in the Configuration view.
2. On the left side, browse to Reports > Design and right-click New Report Design.
3. Select Empty Report and click OK. The report editor opens.
4. On the Report Properties panel on the right, enter a name for the report, HQ Custom Report.
5. On the left side, right-click on the existing report section, and select Remove Section.
6. Next to the Save icon, click the New icon and go to Select near the bottom of the list.
7. In the list that appears, start typing the first few characters of the word Admin and select Admin
Operation Trends. Then click Select.
8. Repeat the process from steps 6 and 7 above, this time selectiing Top Information Messages.
Figure 146: Selecting new report section
9. Repeat the same procedure and select Top Admins and Operations
10. Add one more section, this time selecting Top Admin Clients. Your completed custom report should
appear as below.
118
Figure 147: Completed custom report
11. Click the Save button. In the box that appears, click OK. You may now close the HQ Custom Report
tab.
12. In the Design tab, right-click on the HQ Custom Report, and select Start. The Report Operation
Properties dialog box opens.
13. Click OK.
14. Double-click the HQ Custom Report report to view it. You may close the tab after viewing the report.
119
16
Lab 16: If Things Go Wrong - Troubleshooting
Goals of this lab
If there is anything certain about firewall administration, it is that problems will arise. Knowing how to find
information about the problem, resolve it, or reach out for help are critical for reducing the time it takes to
resolve the problem. This lab will focus on more advanced ways of troubleshooting the environment so that
you can resolve the problem. There are, of course, problems that may not be so easily solved. So that the
problem can be solved quickly, there are a variety of tools at your disposal, both in the engine and the SMC,
that will collect the information necessary to bring your issue to a speedy and successful resolution.
16.1
Collecting sgInfo files from the Management Server using the management client
Should the time come that you need to involve support on some issue, one of the most important tools at
your disposal to speed the resolution time of a problem is an sgInfo. In this exercise, you will collect an
sgInfo from the management server and the HQ Firewall.
1. Click the tab where the Home view is open. Open it from the main menu bar if necessary.
2. At the bottom left of the view that appears, expand Others.
Figure 148: Collecting the management server’s sgInfo archive
120
3. Right-click on the Management Server > Tools > Collect sginfo.
4. In the window that appears, leave Include FILESTORAGE_DIR Contents unchecked.
5. In the Destination Path add Documents to the end of the path. Click OK.
Figure 149: Management sgInfo properties
6. The sgInfo for the Management Server runs and returns the following message.
Figure 150: Completed sgInfo task
16.2
Collecting sgInfo files from the FW engines using the management
client
Now you will collect an sgInfo for the engine through the management client. By default, the configuration
of the NGFW Engine is stored in an encrypted format. You should first disable the encryption of the
configuration data in the engine advanced settings, before collecting the sgInfo.
1. From the Home view, expand NGFW Engines on the left.
2. Right-click on the HQ FW and select Edit Single Firewall HQ FW. The engine editor opens.
3. In the engine editor, on the left side menu, click Advanced Settings and unselect the checkbox
Encrypt Configuration Data.
121
4. Click on the Save and Refresh icon in the menu bar and refresh the policy on the engine.
5. Close the HQ FW tab.
6. From the Home tab, right-click on the HQ FW > Commands > Collect sginfo. The sgInfo task
window appears.
7. The Target should contain the HQ FW engine.
8. Check the box to Include core files.
9. In the Destination Path, leave the Management Server radio button selected.
Figure 151: Engine sgInfo collection task properties
10. Click OK, a warning will appear and the sginfo collection runs.
11. Close the view when the sgInfo task is completed.
In a production enviromnent, the encryption of the configuration data on the engine should be
enabled again after the sgInfo is collected.
16.3
Collecting an sginfo at the command line for the engine
In the case that the Management Server cannot contact the engine, you will have to collect the sgInfo from
the engine at the command line. It is for this reason that you added an SSH access rule to the engine in
your policy. In addition, you will need to enable the SSH daemon on the engine.
122
1. From the Home view, right-click on HQ FW > Commands > Enable SSH to enable SSH on the
engine. Click Yes in the confirmation dialog box.
Figure 152: Enabling SSH on the engine
2. From the HQ Workstation, double-click the Bitvise SSH Client shortcut on the desktop.
3. Enter 172.31.200.1 in the Host box and click on the Login button. The Host Key Verification pop-up
appears. Click Accept for This Session.
4. The password may be saved in Bitvise, but if you are prompted for one, enter Pass1234 and click
OK.
5. Two windows appear. One is the Bitvise Xterm window which provides command line access to the
remote server, and the other one is the Bitvise SFTP Client. Begin work in the Xterm window and
leave the SFTP client in the background.
6. At the command line, run the command sginfo -d -f. This will force the firewall to generate the
sginfo even if some of the data is encrypted, such as the policy. In this lab, you already performed
the necessary steps to decrypted the configuration data on the engine. The “-d” option will ensure
that the sginfo contains core dumps.
7. The sginfo will run and be saved to the engine. In order to retrieve it, you will have to use a secure
copying tool such as pscp in Windows or scp in Unix/Linux systems. The sftp client of Bitvise can
also be used.
123
8. Bring the Bitvise SFTP client into the foreground. The left pane contains the ‘“Local files”, the file
system of the HQ Workstation. The right pane contains the “Remote files”, the file system on the
HQ FW.
9. In the Remote files pane, click the UP icon three times to reach the root directory “/”.
Figure 153: Navigating the remote filesystem
10. In the Remote files pane, double-click on spool, then sginfos. You should see your SGInfo files as
a time-stamped file ending in .tar.gz.
Figure 154: SGInfo file in /spool/sginfos
11. In the Local Files pane, click the UP icon to move from C: \Users \Student \Desktop to C: \Users
\Student.
12. In the Local Files pane, double-click on Documents.
13. You can now drag the SGInfo file from the Remote files pane into the Local files pane. The file will
be copied into the Documents folder on your HQ Workstation.
Figure 155: SGinfo transferred to HQ workstation
124
16.4
Collecting an sginfo at the command line for the management server
To collect the sginfo for the management server at the command line, you need to log on the HQ SMC
machine.
1. Close the opened Bitvise SSH Client windows and launch the application again. Enter 172.31.200.101
in the Host box and click on the Login button. The Host Key Verification pop-up appears. Click Accept for This Session.
2. The password may be saved in Bitvise, but if you are prompted for one, enter Forcepoint1! and click
OK.
3. Close the SFTP Bitvise Client window.
4. From the Bitvise terminal, type cd /usr/local/forcepoint/smc/bin to browse to the installation directory for the SMC.
5. Type ./sgInfo.sh to run the sgInfo command. The equivalent command on Windows is sgInfo.bat.
In the command above, note that the “I” in sgInfo is uppercase.
6. When the script completes, it will display a message indicated where the sginfo was stored. It can be
retrieved to your workstation using the method from the previous exercise if you wish. Then you may
close the Bitvise SSH Client windows.
16.5
Running tcpdump from the SMC and command line
At times, there is no more definitive way to locate a problem than by collecting a capture of network traffic.
Support will often ask for this, particularly if the problem is proving difficult to find. There are two ways to
collect this - through the Management Client and at the command line. You will consider both scenarios.
1. From the Home view, right-click on the HQ FW > Tools > Capture Traffic.
2. In the window that appears, click on Interface 2 and click Select.
125
Figure 156: Collecting traffic captures from the SMC
3. In the window that appears, in the Maximum Duration field, change the number to 60.
4. Accept the defaults in the remaining fields.
5. Click Start Capture the traffic capture begins. It can be stopped at any time by clicking the Stop
button.
6. Results from the traffic capture will be reported on-screen. This will include the location of the saved
packet capture.
Figure 157: Results include the file location
7. Close the Taffic Capture view when the capture is completed
Collecting a traffic capture at the command line is a great deal more flexible because so many more options
can be used.
1. From the HQ Workstation, double-click the Bitvise SSH Client shortcut on the desktop.
126
2. Enter 172.31.200.1 in the Host box and click on the Login button. The Host Key Verification pop-up
appears. Click Accept for This Session.
3. If prompted for a password, enter Pass1234 and click OK.
4. From the Bitvise terminal, run the command: tcpdump -n -i eth2 -s0 -w hqfw-eth2.pcap
5. Allow that to run several seconds, and press Control-C to stop it.
6. You may close the Bitvise SSH Client windows after this exercise is completed.
The previous command collects the entire packet with the “-s” option. The “-n” option prevents the resolution
of DNS, and “-i” specifies the interface.
127
17
Lab 17: Single Firewall Installation
Goals of this lab
In the lab that follows, you will replace the third-party partner firewall by a Forcepoint NGFW managed by
the HQ SMC. The new firewall will be a single firewall. It will be communicating with the SMC through the
HQ firewall, meaning that the partner firewall will have to use the NAT IP of the management server.
You will first configure the partner firewall in the SMC. You will then configure the engine itself using the
terminal-based installation wizard and use the one-time password for establishing trust with the SMC. You
will create a policy for the partner firewall and define rules to allow the same VPN connectivity between
the HQ FW internal network and the partner firewall internal network as you had before with the third-party
firewall.
17.1
Define a new single firewall
The first step in deploying a new firewall is to first define it in the SMC. In this exercise, you will define a new
single firewall with two (2) interfaces: one will be an external interface connected to the router connecting
to the HQ firewall, and the second interface will be connected to the partner internal network.
1. From the Home view, click the gear icon next to NGFW Engines and browse to New > Firewall >
Single Firewall. The Single Firewall (Edit) tab opens.
Figure 158: Creating a new Single Firewall
2. Under the General section, in the Name field, enter Partner FW.
3. In the Log Server field, ensure that Log Server 172.31.200.101 is selected.
128
Figure 159: Partner FW general properties
17.2
Define physical interfaces
The first step in configuring a Forcepoint NGFW is to define the physical interfaces. After the physical
interfaces are defined, you will add IP addresses to them in the next exercise.
17.2.1
Define interface 0
1. On the left side, click on Interfaces.
2. In the menu bar above the Zone column, click the New icon and select Layer 3 Interface. The Layer
3 Physical Interface properties opens.
3. Verify that the Interface ID is set to 0.
4. Click the Zone drop-down menu, and select External.
5. Click the LLDP Mode drop-down menu and select Receive Only.
6. In the comment field, enter Partner External.
129
Figure 160: Interface 0 Properties
7. Click OK. The Layer 3 Physical Interface Properties dialog closes.
17.2.2
Define Interface 1
1. Click thew New icon and select Layer 3 Physical Interface. The Layer 3 Physical Interface Properties
opens.
2. Verify that the Interface ID is set to 1.
3. Click the Zone drop-down menu and select Internal.
4. Click the LLDP Mode drop-down menu and select Receive Only.
5. In the Comment field, enter Partner Internal.
6. Click OK. The Layer 3 Physical Interface Properties dialog closes.
17.3
Configure IP addresses on physical interfaces
The physical interfaces are now defined. At this point, you will assign IP addresses to the interfaces. The
partner Internal Interface (Interface 1) will get an IP Address in the partner private network.
130
17.3.1
Add IP address for Interface 0
1. Right-click on Interface 0 and browse to New > IPv4 Address. The IP Address Properties dialog for
Interface 0 opens.
2. In the drop-down menu, make sure that the IP Address type is set to Static.
3. In the IPv4 Address field, enter 130.207.200.79.
4. Click in the Netmask field. The subnet mask, network address, and the broadcast addresses are
populated automatically.
Figure 161: IP address for interface 0
5. Click OK. The IP Address Properties for Interface #0 closes
17.3.2
Add IP Address for Interface 1
1. Right-click on Interface 1 and browse to New > IPv4 Address. The IP Address Properties for
Interface #1 opens.
2. In the drop-down menu, make sure that the IP Address type is set to Static.
3. In the IPv4 Address field, enter 10.100.100.1.
4. Click in the Netmask field. The subnet mask, network address, and the broadcast addresses are
populated automatically.
5. Click OK. The IP Address Properties for Interface #1 closes.
131
Your configured Interfaces should appear as in the figure below:
Figure 162: Completed interface IP address configuration
17.4
Configure Interface Options
In the NGFW, there are options that must be selected for the interfaces you created in the last exercise.
Most importantly, this exercise will guide you through selecting the management interface.
1. In the tab where the Partner Firewall is open for editing, expand Interfaces on the left side and click
Interface Options.
2. In the Control Interface section, in the Primary field, verify that the Interface 0 (130.207.200.79) is
selected.
3. In the IPv4 Identity for Authentication Requests field, verify that the Interface 0 (130.207.200.79)
is selected.
The Identity for Authentication Requests is the IP that is present to external authentication servers.
The IP is used as an identifier only, as such packets are still routed according to the routing table.
4. In the IPv4 Source for Authentication Requests, choose the interface the firewall uses for send
authentication requests by leaving it set to According to Routing.
5. Set Default IP for Outgoing Traffic to Interface 0 (130.207.200.79).
Your configured Interface Options should appear as in the figure below.
132
Figure 163: Completed interface option configuration
17.5
Create a default route
Now you will create a default route to direct any traffic not destined to your internal networks to the route of
last resort, the Internet.
1. On the left side, click on Routing.
2. In the Routing Tools pane at the bottom, in the Default Route tab, enter 130.207.200.1 which is the
IP address of the default gateway.
Figure 164: Adding a default route for partner FW
3. Click Add.
4. Click the Expand all icon (just above the Name column). The routing definition should look as in the
figure below .
133
Figure 165: Completed partner FW routing view
5. In the upper right-hand corner of the Engine editor, click the Save button to store the changes you
have just made. You may now close the Partner FW tab.
17.6
Establishing Trust with the SMC
Now that the firewall has been defined in the SMC, you can save the initial configuration of the firewall.
The information contained in this configuration will be used to establish a trust relationship between the
SMC and the engine (firewall). In this exercise, you will save the initial configuration and use a console to
configure the engine for initial contact with the SMC.
The Management Template policy template contains rules that permit management connections
through the HQ FW to the SMC so that the partner firewall can be managed.
• A rule that permits the Management Server to communicate to the Partner FW.
• A rule that permits the Partner FW to send management and log related information to the Management and Log Servers.
17.6.1
Saving the initial configuration
1. From the Home view, in the tree view on the left, browse to Firewall > Partner FW.
2. Right-click on Partner FW and browse to Configuration > Save Initial Configuration.
134
Figure 166: Saving the initial configuration
3. On the window that appears, click View Details.
4. Leave this window open or write down the One Time Password. Alternatively you can take a picture
of the One Time Password. This will be needed for the engine configuration.
Figure 167: Viewing initial configuration details
135
17.6.2
Configuring the Engine for SMC Contact
So far you have gotten the information from the SMC to establish a trust relationship with the SMC: the
one-time password. This is used on the engine as a way of identifying itself to the SMC. In this exercise,
you will open a console to the Partner FW. In the lab environment, the Partner Firewall is a Forcepoint
NGFW controlled by another SMC and you will first restore the firewall to factory settings. The firewall will
then be configured to contact your SMC.
Reinitialize the Partner FW to factory settings
1. Return to the Lab "Landing Machine" and use mRemoteNG to open a console to the Partner Firewall.
2. In the window that appears, press Enter to activate the console. Log on with the following credentials:
• Username: root
• Password: Forcepoint1
3. Type sg-clear-all to display the restore options for the firewall.
Figure 168: Display the restore options
4. Type YES. The firewall will reboot and the restore options will be displayed after few seconds.
5. Make sure that option 1 is selected. Press Enter.
Figure 169: Reset the engine to factory settings
136
6. Type YES.
7. Press Enter to reboot the engine.
Configuring the engine for SMC contact with the Configuration Wizard
1. In the Partner FW console, one minute after the reboot of the engine, you will be prompted to activate
the console. Press Enter to activate the console.
2. Stop the browser-based configuration by entering Y. The console configuration wizard starts.
Figure 170: First engine login
3. When prompted to select the Role, press Enter. You are now prompted to select the role.
4. Select Firewall/VPN by pressing Enter.
Figure 171: Selecting engine role
5. On the Welcome screen, use the Tab key, tab over to Next, and press Enter.
6. In the Configure OS Settings, enter the following values:
Use the Enter key to select a setting to change, use the Space bar to check a box, and the Tab or
arrow keys to move from field to field.
• Keyboard layout: US English
• Local timezone: EST5EDT
TIP: Press E and the selection will jump to time zones starting with E.
• Hostname: Partner-FW
137
• Root password: Forcepoint1
7. Using the Space bar, select Enable SSH daemon.
Figure 172: Completed HQ firewall OS settings
8. Using the Tab key, move to Next and press Enter.
9. In the Configure Network Interfaces screen, leave eth0 set as the Mgmt (Management) interface.
Tab down to Next.
Figure 173: Completed network interfaces settings
10. Using the Tab or Arrow keys, move down to Enter node IP address manually, and press the Space
bar to select it. Enter the following values:
• IP address: 130.207.200.79
• Netmask/Prefix Length: 24
• Gateway to management: 130.207.200.1
11. Using the Tab or Arrow Keys, move down to Contact and press the Space Bar to select it.
12. Arrow down to the Management Server field, and enter the following values:
138
• IP address: 212.20.0.101
• One-time password: Enter the one time password generated in Step 4 from the Saving the
Initial Configuration section above
13. Arrow or Tab down to 256-bit security and press the Space bar to deselect it.
14. Arrow or Tab down to Finish.
Your completed Engine initial configuration should appear as in the figure below:
Figure 174: Completed HQ firewall initial configuration
15. When presented with the Fingerprint Verification, select Yes and press Enter to accept the Management Server certificate fingerprint.
Figure 175: Management Server certificate fingerprint
16. After this, you should receive a message that contact with the Management Server was successful,
and after 5 seconds, the login prompt will be presented.
139
Figure 176: Management server contact successful
If contact fails, and you receive a message in relation to the one-time password being incorrect, it is
not necessary to restart the installation wizard. Log in as root with Forcepoint1 as the password
and run sg-contact-mgmt followed by the one-time password. It is also possible to create a new
one-time password by right-clicking on the Engine > Configuration > Save Initial Configuration.
You will then receive a new one-time password. Run the following sg-contact-mgmt <YOUR ONE
TIME PASSWORD> in the Partner FW console.
17. In the Management Client, you may now close the window where your one-time password was available for viewing.
18. To verify that the Management Server Contact was successful, click the Home button and note that the
color of the Engine has changed from white to orange, letting you know that contact was successful.
Figure 177: Successful management contact SMC view
The status of the engine will not be green until a policy is successfully uploaded in a later lab.
140
17.7
Bind a License to the Engine
In order for a policy to be installed, you must bind a license to the engine. In this exercise, you will bind one
of the NGFW licenses to the Single Firewall you just created.
1. From the Management Client, click the tab where the Configuration view is open. If the view is
closed, open a new tab and click on Administration.
2. In the tree view on the left, browse to Administration > Licenses > NGFW Engines.
3. In the pane on the right, right-click the first unassigned NGFW Node (dynamic license) and select
Bind. The Select License Binding dialog opens.
4. Click on Partner FW node 1.
Figure 178: Binding a license to the partner FW
5. Click Select. The Select License Binding dialog closes. A message appears letting you know that
a policy installation is required to activate the license.
17.8
Define a Policy for Partner FW
Now that the Partner FW has been defined, you will create a firewall policy for the partner firewall to permit
again the VPN connectivity between the HQ FW internal network and the Partner FW internal network.
17.8.1
Create the Partner Policy
1. In the tab where the Configuration view is open, browse to NGFW > Policies > Firewall Policies.
2. Right-click on Firewall Template and select New > Firewall Policy. The Firewall Policy Properties
opens.
3. In the Name field, enter Partner Policy.
141
Figure 179: Partner policy properties
4. Click OK. The Firewall Policy Properties dialog closes. The partner firewall policy opens for editing.
17.8.2
Add VPN rules to the partner firewall policy
You will now add VPN rules in your partner policy by copying the rules already defined in the Student HQ
Policy and pasting them in the partner policy. In the Partner-HQ VPN, the partner external gateway will be
replaced by the partner firewall gateway to allow the VPN connectivity between the two sites.
1. In the Configuration view tab, browse to NGFW > Policies > Firewall Policies. Right-click Student
HQ Policy under the ManagementTemplate Policy Template and select Preview Firewall Policy
Student HQ Policy.
2. Expand the sections and locate the VPN rules, select both of them and right-click Rule > Copy Rule.
3. In the tab where the Partner Policy is open, right click the green insert point Local Firewall Policy
Rules - add rules here and select Paste.
Figure 180: Partner policy opened in policy editor
4. Right-click Edit Logging in the Logging cell and set the log level to Stored for both VPN rules.
5. Right-click Enforce VPN: Partner-HQ in the Action column and select Edit Policy Based VPN
Partner-HQ.
142
Figure 181: Editing Partner-HQ VPN from the partner policy editor
6. In the VPN editor, in the Site-to-Site VPN Tab, right-click the Partner External Gateway and select
Remove.
7. In the Gateways resource pane, select drag and drop the Partner FW - Primary Gateway in the
Satellite Gateways tree.
Figure 182: Partner-HQ VPN configuration completed
8. Click the Tunnels Tab to view the VPN tunnels.
9. Click the Save button.
10. Switch back to the Partner Policy tab.
11. Click the Save and Install button. The policy upload dialog appears.
12. From the list of engines on the left, select Partner FW and click Add.
13. Click OK. The policy upload begins.
17.9
Re-install the Student HQ Policy
Following the changes made in the Partner-HQ VPN configuration, the Student HQ policy needs to be
installed again on the HQ firewall.
1. Switch back to the Student HQ Policy tab.
2. Click the Save and Install button. The policy upload dialog appears.
143
3. Click OK. The policy upload begins. When the policies are successfullly installed, you can perform
the VPN test.
17.10
Testing access to and from the Partner network
In this last section, you will test your Partner-HQ VPN again.
1. On your HQ workstation, open a command prompt Start > Run and type cmd.exe.
2. Issue the command: ping 10.100.100.50. This is the IP of the partner server behind the Partner
firewall.
3. From the Home view, browse to SD-WAN > Policy-Based VPN and check that the status of the
Partner-HQ VPN is green again.
Figure 183: Partner-HQ VPN status in home view
Summary
In this lab you have taken the first steps in deploying your firewall. You first configured the engine in the
SMC, which gave you a one-time password for use in establishing trust between the SMC and engine.
You then configured the engine itself using the terminal-based installation wizard and used the one-time
password to contact the Management Server. Finally you created a policy for the Partner FW and added
rules to allow VPN connectivity between the HQ FW internal network and the Partner FW internal network.
144