NS Workshop Lab Guide

Forcepoint NGFW
Partner Workshop
Student Lab Guide
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, we encourage you 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.
List of Virtual Machines / Containers

• HQ SMC (smc.training.com): This is a Linux container that runs the SMC
• Internal IP: 172.31.200.101 (smc.training.com)
• Username: student
• Password: Forcepoint1
• HQ Firewall: This is the firewall that separates the HQ network from the simulated
internet. The Windows workstation that you will use is located behind this firewall.
• External IP: 212.20.0.254 (ssl-vpn.training.com)
• Internal IP: 172.31.200.1. Serves as the default route for machines on the HQ
network.
• Username: root
• Password: Forcepoint1
• HQ Workstation: This is a Windows 10 VM from which you will connect to the SMC (HQ
SMC)
• IP address: 172.31.200.60 (wrk1.training.com)
• Username: student
• Partner Firewall: This is the firewall to which you will create a VPN. It is a Linux firewall,
fully configured, and running StrongSWAN
• External IP: 130.207.200.79 (partnerfw.training.com)
• Internal IP: 10.100.100.1
• Partner Internal Server: This is a Linux workstation from which you will perform various
tests.
• IP address: 10.100.100.50
2
• Pcapreplay: This container combines packets for bi-directional stateful replay. This
machine should not be reconfigured
• Receiver internal IP address: 192.168.0.150
• Receiver NAT IP address: 212.20.0.150
• External IP address: 87.35.16.200 as well as dynamic, constantly changes
source of client PCAPs
• Router: this is a container that performs simple static routing
• External IP addresses: 212.20.0.1, 87.35.16.1 and 130.207.200.1
• DNS authoritative server: DNS server that hosts training.com zone. Other requests are
relayed to recursive server
• IP address: 172.31.200.102 (ns.training.com)
• DNS recursive server: accepts any DNS query and attempts to resolve it using root DNS
servers
• IP address: 172.31.200.106
• Webmail server: accepts SMTP emails to any destination and provides webmail UI
• IP address: 172.31.200.103 (mail.training.com)
• OpenLDAP server: provides LDAP directory for training.com zone
• IP address: 172.31.200.104 (ldap.training.com)
• DMZ WWW server: a simple internal web server used in SSL VPN lab
• IP address: 172.31.200.105 (dmzwebserver.training.com)
• Remote workstation: container using Firefox web browser used in SSL VPN lab
• IP address: 87.35.16.202
• Remote web server
• IP address: 87.35.16.201 (webserver.training.com)
3
Classroom Network Diagram
Figure 1: Classroom Network Diagram
1 Lab1: Post-installation Administration Tasks

Goals of This Lab
After getting the SMC software installed, the licenses applied, and you are ready to begin installing
firewalls, etc., there are a few tasks that should always be performed before getting started. 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 enable
change control so that when changes are made to policies, objects, or engines there will be a
4
mechanism for approving those changes before deployment. Lastly, you will learn how to enforce
a password policy so that administrator passwords must conform to the standard you specify.
To access SMC, connect to the Landing Machine using Microsoft Remote Desktop client and use
HQ Workstation link. From there open http://smc.training.com:8080/ using Chrome. Username for
SMC is student, password is Forcepoint1
1.1 Create an on-demand backup
1. To create an on-demand backup, click Menu → System Tools → Backup
Figure 2: Creating an On-Demand Backup
2. Click on the Management Server and click Add

3. In the Backup Comment field, type “Post installation backup“
4. Click OK
5
Figure 3: Backup Details
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

2. On the left side, expand Administration
3. Expand Tasks and click on Definitions
4. In the right pane, right-click → New → Backup Task
6
Figure 4: 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
Figure 5: 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.
1. Right-click on the Weekly SMC backup task → Schedule
7
Figure 6: Scheduling a Backup Task
2. In the Task Schedule Properties, select Weekly from the Repeat dropdown menu
3. For Repeat On, deselect all days except Monday
4. Optionally, you can select a start time and how the Final Action is handled
Figure 7: Schedule Task Properties
5. Click OK. The task is now scheduled
1.3 Enable change control
Change control is a feature that, when enabled, requires that all changes must be approved by a
superuser. To enable change control, perform the following steps:
1. Click the Menu → System Tools → Global Properties
8
Figure 8: Selecting Global Properties
2. Click on the Change Management tab

3. Check the boxes for Require Approval for Changes and Allow Administrators to
Approve Their Own Changes in NGFW Engine Configuration
9
4. Click OK
Change management is now enabled.
NOTE: When Change Management is enabled, future policy installations will require approval
before uploading.
1.4 Testing Change Control
Now you test Change Control by making a change to the currently installed policy on the HQ
FW. After making the change, you will be able to view and approve the changes. To test
Change Control, perform the following steps:
1. From the Home view, right-click on the HQ FW →Edit Single Firewall HQ FW. The firewall
editor opens
2. In the General properties (the default view), under the DNS IP Addresses, click the Add
button → IP Address
3. In the box that appears, enter 8.8.8.8
10
Figure 10: Adding Addtional DNS Server
4. In the upper-right of the engine editor, click the Save button. Close the engine editor
Now that a change has been made to the configuration of the engine, it is time to view and
approve the change.
1. From the Home view, 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 11: Viewing Pending Changes
2. 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
11
Figure 12: Engine Configuration Comparison
3. From the Home view, under the Pending Changes panel, single-click to the right of the
administrator icon. This action indicates that the change has been approved
4. Click the Commit Changes button. The policy upload begins
Figure 13: Approving and Committing Changes
NOTE: Now that change control has been enabled and successfully tested, please disable
change control for purpose of the remaining labs. Disabling change control in this environment
will ensure that every change you make will not require approval. In a “real world“ environment,
change control would be left enabled.
1.5 Enable an Administrator password policy
12
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 Properties

2. Click on the Password Policy tab
3. Select the following options:
• Only One Logon Session for Each User

• Lock Out After Failed Logon Attempts, accepting the defaults
• Lock the Management Client Window After the User Session is Idle for • Close the
Management Client
Now, you will configure options for password age and expiration
1. 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)
13
Figure 15: Password Age and Expiration
Lastly, you will configure password complexity options
1. Accept the default settings. Feel free to customize
Figure 16: Selecting Password Requirements and Options
2. Click OK
The password policy is now configured.
NOTE: For the purposes of future labs, disable the password policy so that your management
client does not disconnect after the amount of time specified in the policy you just configured.
This is only for convenience in this lab environment. In a “real world“ environment, you would
want to leave that enabled.
14
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 as possible administrators
that 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, we will use Role-based Access Control to
create administrator roles, restrict what objects have rights 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:
• Edit Element properties

• View Element Contents
• Create Elements
• Refresh Policies
• Browse Logs and Alerts from Granted Elements
• View System Alerts
15
Figure 17: Custom Role Properties
6. Click OK to save the new Role
2.2 Create and 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.
16
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:
• ALL Simple Elements

• Use the “arrow“ icon, go up a level click on NGFW Engines and add the HQ Firewall to the
list
• Go up a level again, click on Policies → Firewall Policies and add the HQ policy to the list.
Figure 18: 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. In the Password field, enter Pass123456, making sure to confirm it in the field below.
NOTE:The Generate Password button will generate sufficiently complex password for normal
use.
5. Leave the Always Active radial button selected
17
Figure 19: Administrator Properties
6. Click on the Permissions tab and click Add Role

7. Under the Role column, click on Operator. A drop down list appears
8. Select the role you created in the last section, HQ Custom Role
9. Under the Granted Elements column, right-click and select Edit Granted Elements
18
10. In the box that appears, click on ALL Simple Elements on the right and click the Remove
button
11. In the left pane, click on HQ Custom ACL and click the Add button
Figure 21: Custom ACL Selection
12. Click OK. The Administrator properties have now been selected and you can click OK again
to close the Administrator Properties
NOTE: There are other tab 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 browser.
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
19
Figure 22: 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 any attempts to
edit and save will result in error message
Figure 23: Attempt to save restricted element
• Right-click on the HQ FW → Current Policy → Refresh Policy. Can you do that?
Figure 24: Attempting to Refresh a Policy
• On the menu bar, click the Configuration icon

• On the left side, expand Network Elements → Hosts
20
• 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 25: Adding a new Host
4. Close the console and log back it as student
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.
We encourage you 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.
21
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 browser to locate events of interest
To begin using the logs, we 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.5.5.241
1. On the menu at the top, click the Logs icon. The log browser opens
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
Figure 26: 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.5.5.241 as the destination. Click on
192.5.5.241 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.5.5.241
7. Click Apply
22
Figure 27: Negating a Destination Address
All DNS events that are not destined for 192.5.5.241 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 last filter by right-clicking on the filter and selecting Remove
2. Right-click on the column header for IP Protocol → Filter: IP Protocol
Figure 28: Manual Creation of a Protocol Filter
3. In the box that appears, type UDP in the box that reads Type to Search
4. Click Apply. The UDP filter appears in the query panel
23
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
Figure 29: Query Panel with Sample Filters
Now only protocols that are not UDP will appear in the log browser. 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 browser and creating a graphical
representation of it. In this way, you can see the larger picture of what may be happening on the
network. In order to use statistics effectively, we 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 Landing Machine, double-click the shortcut labeled, StartTraffic.
Allow this to run for a few moments. You should begin to see traffic in the log browser.
2. After letting it run, with the log browser open, click the Statistics button → Select
24
Figure 31: Statistics Selection
3. In the box that appears, scroll down and locate Top Services. NOTE: 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 32: Selecting Top Serves
4. Click Select. The Top Services are displayed. You should see something similar to the figure
below
25
Figure 33: List of 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 34: Showing Records from 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
4. Repeat steps 1 through 4 above, selecting Top Network Applications instead. This will
display the top network applications.
26
Figure 35: 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.
27
4 Lab 4: Designing a Security Policy
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. This lab will familiarize you with
creating a policy that can be maintained easily for ongoing administration. Through the use of
templates, continue rules, aliases, expressions and rule sections, you will create a clean,
readable, and secure policy.
4.1 Create a new policy
To begin, you will create a policy based on a customized template for this training environment.
It contains some rules that are necessary for the labs to function properly.
1. Right-click on the Configuration icon on the menu bar and select Open in New Tab
2. On the left side, expand Policies and click on Firewall Policies
3. Right-click on the Management Template and select New → Firewall Policy
Figure 36: Creating a New Firewall Policy
4. In the Name field, enter Student HQ Policy. The policy editor opens
A new policy has been created and is ready for editing. Note the green insert point.
4.2 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. Double-click on the green line that reads HQ-Rules - add rules here. A blank rule is inserted
2. Configure this rule with the following properties:
28
• 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. Select the settings in the figure below
Figure 37: Logging Options
The fully configured Continue rule should look like the figure below. NOTE: If the columns are
not at the proper width, right-click on any column header and select Fit All.
Figure 38: Logging Continue Rule
29
4.3 Add a Continue Rule for SSH timeout
In the previous exercise, you added a Continue rule for logging. Here you will a 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
• 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
• Action: right-click → Continue

• Logging: leave logging blank. The previous rule has you covered
30
3. Right-click on the Action and select Edit Options. The logging options open
4. In the Idle Timeout field, enter 120
Figure 41: Setting the SSH Idle Timeout
The completed rule should look like the figure below
Figure 42: Completed Continue Rule for SSH Timeout
4.4 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
31
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 management server.
1. On the previous rule, right-click in the ID and select Add Rule After
2. Click in the Source column
3. On the left, click Network Elements →Servers and drag the Management Server into the
Source column
Figure 43: Network Element Tree
4. Click in the Destination column. On the left, go up one level, click on NGFW Engines
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
NOTE: In order for SSH access to the firewall to work, it must be enabled. This can be done by
right- clicking on the firewall → Commands → Enable SSH
The completed rule should look like the figure below
Figure 44: Allowing Management SSH Access to Engine
32
4.5 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,
we recommend avoiding the use of Any. To avoid this, you will create an Expression that will
help you more specifically define what the “internet“ is.
4.5.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, click Select
8. Click the union operator, U. This will allow you “union“ your internal network with your DMZ
network
9. Click the Add Element button again, browse to Network Elements → Networks and select
the network-192.168.0.0/24 network, click the Select button
10. Finally, click the right parenthesis button
11. Click OK. The Expression editor closes
Your completed expression should look like the figure below
Figure 45: Completed Expression
33
4.5.2 Adding the Outbound Access Rule
With your complete 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
• 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
4.6 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
4. Optional: Right-click on the rule section → Colors → Color to your liking
34
Figure 47: Completed Outbound Rule Section
5. Right-click in the ID column of the first rule and select Add Rule Section Before
6. Double-click on the new rule section and name it Logging and Timeouts
Figure 48: Completed Rule Sections
4.7 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 we 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.
35
1. Right-click in the ID column of the last rule in the Logging and Timeouts section and select
Add Rule After
• Source: On the left, browse to Network Elements → Countries

• Browse through the list of countries and drag those countries into the Source column of
the new rule
• Destination: Right-click → Set to ANY
• Action: Allow
• Logging: Double-click in the logging column, the Logging Options appear
3. Configure the logging as in the figure below
Figure 49: Logging Options for Country Monitoring
36
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
Figure 50: Country Monitoring Rule
4.8 Add a dynamic source NAT rule
Before your internal network can reach the internet, we 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-
171.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
• Right-click in the NAT column → Edit NAT
37
• On the Source Translation tab, choose the Translation Type as Dynamic
• Click the Address button. Type 212.20.0.60 in the field provided
• Make sure that the Automatic Proxy ARP checkbox is selected
Figure 51: 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 52: Completed Dynamic Source NAT
4.9 Add a rule to proxy outbound SSH
One very useful feature of the firewall is the ability to proxy connections for TCP, UDP, HTTP,
and SSH. In this section, you will configure the firewall to proxy 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.
38
4.9.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
communi- cating via SSH. You will add a rule that permits the engine to communicate outbound
on SSH.
1. Below the rule permitting the management server to access the engine on SSH, right-click in
the rule ID column and select Add Rule After
2. 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 Service column and select Allow
3. Click the Save and Install button. The policy uploads to the engine
Your completed rule allowing the engine outbound on SSH should appear as in the figure below
Figure 53: Completed Engine Outbound SSH Rule
4.9.2 Create a Known Host Entry
In this exercise, you will create one trusted server, i.e. 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 Configuration icon

2. Browse to NGFW → Other Elements → Sidewinder Elements → SSH Known Hosts →
SSH Known Hosts
39
Figure 54: 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.201
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 opens
NOTE: 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
9. Click OK.
NOTE: 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.
Your completed SSH known host should appear as in the figure below
40
Figure 55: Completed SSH Known Host
4.9.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 exercize, 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 their connection discarded. To configure the known hosts list, perform the steps
below.
1. Click the Configuration icon

2. Browse to NGFW → Other Elements → Sidewinder Elements → SSH Known Hosts →
SSH Known Hosts Lists
3. Right-click → New SSH Known Hosts List
4. In the Name field, enter Training Known Hosts
5. Click the Add button to add a new SSH known host
6. In the window that appears, select Remote SSH Server that you created above, and click
Select. Remote SSH Sever now appears in the SSH Known Hosts list
7. Click OK. Your SSH Known Hosts List should appear as in the figure below
41
Figure 56: Completed SSH Known Hosts List
4.9.4 Enable SSH Proxies on the Engine
1. From the Home view, right-click on the HQ FW →Edit Single Firewall HQ FW. The engine
editor opens
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
42
Figure 57: Enabling the Sidewinder Proxies
4.9.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. Right-click the Configuration icon and select Open in New Tab

2. Browse to NGFW → Other Elements → Services → With Proxy
3. Right-click on the SSM SSH element → New → Duplicate. The service properties open
4. In the Name field, enter SSM SSH Custom
5. Click on the Protocol Parameters tab
6. Ensure that Allow Remote Command Execution and Allow Remote Shell Execution are
checked
7. Expand the SFTP section. In the Allowed SFTP Commands drop-down menu, choose
Selected From List
8. Ensure that only Read directories on the server and Read files on the server is selected
43
Figure 58: Selecting Allowed SFTP Commands
9. Under the Client Authentication section, enter, “WARNING: This connection is being
monitored and is restricted“ in the Client Connection Message field
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
Figure 59: Reordering Accepted Server Key Types
44
11. Click OK. The Accepted Server Key Types window closes
12. Under the Sever Advanced Settings, choose Use Strict Known Host List in the Server
Host Key Validation drop down menu
Figure 60: Enforcing the Use of Known SSH Hosts
13. Click OK
4.9.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. In the tab where you policy is open for editing, right-click in the ID column of the last rule and
select Add Rule Before
2. Configure the new rule as follows:
• 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
45
Figure 61: Completed SSM SSH Proxy Rule
Click the Save and Install button. The policy is uploaded to the engine
4.10 Upload the policy and enable validation tools
You have finally arrived at the point where you will upload the policy and test. You will also
enable some of the rule validation tools to ensure that the policy contains no errors.
1. In the upper right-hand corner, click the “gear“ icon and select Validate
2. In addition to the already selected items, check Analyze Rules.
NOTE: There will likely be some issues. These arise from the template that was created for the
training environment. They will not prevent policy upload.
Figure 62: Enabling Rule Analysis
46
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
5. The policy upload begins
Figure 63: Upload the Security Policy
6. Once the policy has successfully uploaded, you my close the policy upload tab
You have now uploaded your security policy, and it is ready to test.
4.11 Testing the new Security Policy
Now that the security policy is uploaded, you will test basic access to the internet. After
checking that access to the internet works properly, you will test the SSH proxy rule.
4.11.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, right-click → New → Filter: IP Address. The Filter
Properties opens
47
Figure 64: IP Address Filter Menu
3. In the IP Address field, enter the IP of you workstation, 172.31.200.60, click Add
4. Click Apply
Figure 65: 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, attempt to access http://webserver.training.com
8. You should now see the connections from your workstation to the web server.
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
48
Figure 66: NAT Source and NAT Destination
4.11.2 Testing the SSM SSH Proxy
Now you will test the SSM SSH Proxy in two ways: using and 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.201 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 67: Session Monitoring and Restriction Message
4. When the password prompt appears, enter Forcepoint1 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 SFTP window, locate a file called bash_history in the right-hand pane
6. Right-click on the file and select Erase. What happens? Open the log browser and you
should see an entry as in the figure below
Figure 68: Blocked SFTP Action
49
4.12 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. If your security policy is not already open for editing, from the Home view, right-click on the
HQ FW → Current Policy → Edit
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 to upload the policy.
50
5 Lab 5: 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.
5.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. If your policy is not open for editing, Click the Configuration button and browse to NGFW →
Firewall Policies
2. Right-click on your policy → Edit Firewall Policy Student HQ Policy
3. Below the rule for monitoring country traffic, add a new rule. Right-click in the ID column and
select Add Rule After
4. 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. NOTE: This is a preconfigured object
NOTE: Under normal circumstances, the service should be as specific as possible.
ANY is used in this example because of the nature of how traffic generation is done in
these labs.
• Action: Right-click and select Allow as the action
• Right-click again in the Action field and select Edit Options. The options dialog
appears
• In the Deep Inspection drop down menu, select On. Click OK
51
Figure 69: Enabling Deep Inspection for DMZ
Your completed rule to enable deep inspection for traffic into the DMZ should look like the figure
below
Figure 70: Completed Deep Inspection rule for HTTP
52
5.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 Access rules.
1. From your security policy, click on the Inspection tab

2. In the Inspection Policy field, click Select. The Select Element dialog opens
3. Right-click on the Medium Security Inspection Template and select New Inspection
Policy. The Inspection Policy Properties opens
Figure 71: Creating a New Inspection Policy
4. In the Name field, enter HQ Inspection Policy and click OK
53
Figure 72: HQ Inspection Policy
5. In the background, the new Inspection Policy opens, and the Select Element dialog remains
6. Click on your new HQ Inspection Policy and click Select
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 73: Completed HQ Inspection Policy
54
5.3 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 HTTP
connections destined for the NAT IP of the DMZ server will be inspected.
1. On the tab where your Security policy is open for editing, click the Save and Install button.
The policy upload begins.
NOTE: If your security policy is not open for editing, click the Home button, right-click on the HQ
Firewall → Current Policy → Refresh
2. If you have not started background traffic previously, on the desktop of your workstation,
double-click the Start Traffic shortcut
3. Allow this to run for ten minutes
4. Close any open Log browser tabs. Right-click on the Logs button on the menu open and
select Open in New Tab
5. In the Query Panel, use the drop-down menu and select Inspection, click Apply
6. After the traffic has run for a while, you should begin to see traffic similar to the figure below
Figure 74: Events Identified by Deep Inspection
5.4 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, in this method below, it makes it slightly easier
to identify those things that you have flagged as a false positive.
1. On the tab where your Inspection Policy is still open for editing, click on the Exceptions tab
2. Double-click on the green 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-
Locky-B-Control-Traffic
Figure 75: Example Inspection Event
55
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
NOTE: 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
Figure 76: 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
56
Figure 77: Logging for a False Positive Rule
10. Click the Save button the refresh the security policy as in the figure below. The event will no
longer appear in the logs
Figure 78: Refreshing the Engine Security Policy
57
5.5 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, 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
Figure 79: Setting the Log Level to Alert
7. Return to the tab where the Inspection Logs are still running
8. Locate an instance of the DNS_Client-Name-Bad-Label-Type
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
10. Save your inspection policy and refresh the firewall policy as in the last exercise
Future occurrences of the Generic_CS-Donbot-Spambot will now be terminated and an alert
will be generated. Your completed rule should look like the figure below. Verify this by
examining the logs.
Figure 80: Completed Bot Termination Rule
58
6 Lab 6: Automated Alerting and Notifications
Goals of This Lab
As an administrator, it is very important to know when particularly interesting thing 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 and event of interest to you attention via different
methods. You will learn how engine logging and the SMC work together so that you are always
informed.
6.1 Configure the Management Server for Alerting
In this exercise you will configure the Management Server for automated alerting.
1. Open a new tab and click the Home button from the Menu Bar
2. At the bottom left, expand Others
3. Right-click on the Management Server → Properties
Figure 81: 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 TrainingMail
8. In the IP Address field, enter 172.31.200.103
9. In the Default Sender Name field, enter trainingadmin
10. In the Default Sender E-Mail field, enter trainingadmin@smc.training.com
59
Figure 82: SMTP Server Properties
11. Click OK
NOTE: A warning may appear stating that there is a duplicate IP Address. This is just informing
you that there are other object names with the same IP address. In this case, we are using the
Management server to perform several functions.
12. Click Yes to close the warning message. Click Select in the remaining window
13. In the Sender Name field, enter trainingadmin
14. In the Sender Address field, enter trainingadmin@smc.training.com
Your configured Notifications should appear as in the figure below
60
Figure 83: Notification Management Configuration
6.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. On the Menu Bar, right-click the Configuration icon and select Open in New Tab
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
61
Figure 84: 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@smc.training.com
• Threshold to Block: Set to 10 alerts in 10min
7. Add another rule by right-clicking in the ID column → Add Rule After

• Channel: USER NOTIFICATION

• Destination: student
NOTE: The destination could also be set to any, which means that all administrators
would be notified.
• Threshold to Block: Cannot be edited with User Notification
9. Click the Save icon
Your configured Alert Chain should be configured as in the figure below:
Figure 85: Completed Alert Chain
6.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
62
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.
1. From the Menu Bar, click the Configuration icon and browse to Administration → Alert
Configurations → Alerts
2. In the upper right-hand corner, click the New icon → Custom Alert, the Custom Alert
Properties opens
3. In the Name field, enter HQ Alert
Figure 86: Custom Alert Properties
4. Optionally, you may enter a message in the Message field

5. Click OK
6.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
63
Figure 87: 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
• Sender: ANY
• Alert and Situation: click in the Alert and Situation column. On the left tree view, 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
6. Click the Save and Install icon to save the policy and upload it to the Shared Domain
7. In the window that appears, click on Shared Domain and click Add
64
Figure 88: Uploading the HQ Alert Policy
Your fully configured Alert Policy should look like the figure below
Figure 89: Completed Alert Policy
6.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.
65
1. If your security policy is not open for editing, click the Home button on the menu bar, right-
click on the HQ FW, and select Current Policy → Edit
2. Click on the Inspection Tab
3. Right click in on your HQ Inspection Policy → Edit Inspection Policy HQ Inspection
Policy. The policy opens for editing
4. Switch to the Exceptions Tab
5. Locate the rule where HTTP_CSH-Locky-B-Control-Traffic is being permitted and change
the action to Terminate
6. In the logging column, right-click and select Edit Logging. The Logging options appear
7. Change the logging level to Alert
8. In the Alert field, select the HQ Alert that you created in section 6.3
9. Click OK and save and install the policy
You are now configured to receive alerts should that rule match. The fully configured inspection
rule should look like the following
Figure 90: Completed Policy Alert Rule
6.6 Testing Automated Alerting
Now that the Alert Chain, Alert Policy, and rule are configured for automated alerting, it is time
to test it. When the Exception rule that you created above matches, the HQ Alert will be raised
and processed according to the Alert Policy. In the Alert Policy, you specified the delivery
method as SMTP. When the Exception Rule matches, an email is sent to a predefined user,
alertadmin@smc.training.com. In this exercise, you will generate an attack and check your
email to ensure that it is delivered.
1. If not already open in another tab, open the log browser by pressing the Logs button from the
Menu Bar
2. In the Query Panel, use the drop-down box and select Inspection and click Apply
3. Click the Current Logs button (the “play“ button). You should start to see events related to
HTTP_CSH-Locky-B-Control-Traffic
4. From your HQ Workstation, open Chrome and go to http://mail.training.com and log in with
username alertadmin@smc.training.com and the password Forcepoint1
66
Figure 91: Logging into Alert Admin Webmail
5. You should see alerts that were emailed by trainingadmin@smc.training.com
67
7 Lab 7: 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 or Active
Directory. In this lab, you will use an external LDAP database, wherein you will add users and
prepare the SMC for User Authentication.
7.1 Create an LDAP Server element
Before user authentication can work, you have to integrate a user storage server (typically
Active Direc- tor or LDAP) 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. Open a new tab and select User Authentication

2. On the right, click on Servers. In the white space, right-click New → LDAP Server
3. In the LDAP Server Properties that opens, configure the following on the General
Properties tab:
• Name: smc.training.com
• IP Address: 172.31.200.104
• Base DN: dc=training,dc=com
• Bind User ID: cn=Manager,dc=training,dc=com
• Bind Password: Forcepoint1
NOTE: You will not see some field of the form, if LDAP Server Properties windows does
not fit into your desktop because of insufficient resolution. To increase resolution,
use View → Zoom → Zoom Out feature of Remote Viewer application that is used to
access the HQ Workstation or a keyboard shortcut Ctrl+-
4. Click the Check Connectivity button to verify communication

5. Click on the Attributes tab and select the Updated radial button
68
Figure 92: LDAP Server Attributes
6. Click on the Authentication tab. Click the Add button

7. In the box that appears, click on User Password and click Select. Click OK to close the
server properties.
7.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.
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
3. In the Name field, enter training.com
4. Under the Servers column, click on the smc.training.com and click the Add button. The
69
server should now appear under the Bound Servers column
5. Make sure that the Default LDAP Domain is checked
Figure 93: Adding a New LDAP Domain
6. Click OK to close the Properties window

7. On the new domain you just added, expand it to ensure the integration was successful
7.3 Create a new user
You have now integrated the LDAP server and its associated domain with the SMC. Now we
must add a user. To do that, you will use a tool to administer your LDAP domain. Adding users
to an LDAP domain from the SMC is not possible.
1. On the desktop of your workstation, double-click the icon for LdapAdmin
70
Figure 94: LDAP Administration Tool
2. In the far upper-left corner of the window that opens, click the Connect button
3. A window appears, in which you will double-click TrainingLDAP
Figure 95: Connecting to the Training LDAP server
4. At the top of the tree view, right-click → New → User. The user attributes open
5. The user properties should be configured as in the figure below
Figure 96: New LDAP User Properties
71
6. Click OK to add the user
7. On the user you just created, right-click → Edit Entry
8. In the space on the left, click the drop-down menu and, from the list, click sguser
9. Click the Save icon
Figure 97: Adding sguser Attribute
10. You may now return to the management client

11. Expand the training domain, right-click and Refresh View. You should now see your new
user
Figure 98: Addition of New User to LDAP Domain
NOTE: When using LDAP servers, you must either use RADIUS for authentication or update the
schema on the LDAP server with Forcepoint specific attributes. This is so that the users can
authenticate against LDAP. This is not necessary with Active Directory, but there are optional
schema updates for Active Directory as well. Now you must set a password for the new user.
Part of the reason for adding the sguser attribute (which comes from the schema update) is so
that the Forcepoint specific User Password authentication mechanism can be used. Notice that
you did not set a password for the user you just created in LDAP.
72
1. Right-click on the user brobertson and select Properties
2. Make sure the Always Active box is checked
3. Click on the Authentication tab
4. Under Authentication Methods, click the Add button and select User Password. Click
Select. The Authentication Methods window closes
5. In the Password field, enter Pass1234 and confirm it
6. Click OK to close the window
Your fully configured user should appear as below
Figure 99: User Authentication Properties
73
8 Lab 8: 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 than 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.
8.1 Configure the firewall for user authentication
Now that a user store mechanism and its associated domain has been added, you can now
user the user information stored there for authentication purposes. This can be for, as in the
case of this exercise, browser-based authentication or for SSL VPN and IPSec. You will now
configure the firewall for browser-based authentication.
1. Click the Home button from the menu bar

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, 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
Figure 100: Configuring HQ FW for User Authentication
74
8. Click the Save button and close the firewall properties
8.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. NOTE: 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. 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):
• 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 (that 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 Properties
opens
5. Ensure that Require Authentication is checked

6. Click on the Users tab. On the left side, click Users →training.com →training, click on
brobertson and click the Add button.
Figure 101: Rule Authentication Parameters
75
7. Click the Authentication Methods tab, then click on User Password, click Add so that it is
added to the list of Accepted Authentication Methods
Figure 102: Accepted Authentication Methods
8. Click OK to close the Authentication Parameters window

9. The Source, Destination, and Service should be the same for the second rule you added
10. In the second rule you added, closer to the bottom, set the Action to Discard
11. Right-click in the Action column of the same rule, and select Edit Options
Now you will configure the response that users will receive from the firewall when they attempt
access to the internet.
1. Check the box for Override Settings Inherited from Continue Rules
2. Next to the User response field, click Select
3. In the window that opens, click the “gear“ icon → New → User Response. The User
Response Properties window opens
4. In the Name field, enter HQ Internet Access Response
5. Click on Connection Discarded by Access Rule
6. In the Type of Response field, select URL Redirection
7. For the URL, type http://172.31.200.1, the firewall’s internal interface
8. Check both boxes for Enable Manual Redirection to Original URL After Authentication
and Enable Automatic Redirection to Original URL After Authentication
76
Figure 103: User Response Properties
9. Your new response should be highlighted, and click Select

10. Click OK to close the Rule Action Options
11. Save and Install the firewall policy
Your new user authentication rules should look like the figure below
Figure 104: User Authentication Rules
77
8.3 Testing Browser-Based Authentication
To test your authentication rules, open a web browser on your workstation, and attempt to
access http://webserver.training.com. What is the result?
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
3. Open a new tab and attempt to access http://webserver.training.com again. What is the
result?
78
9 Lab 9: 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.
9.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. Open a new tab. Under the Configuration section, click VPN

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://172.31.200.105/
Figure 105: SSL VPN Web Service Properties
79
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
9.2 Create an SSL VPN policy
You have now created a service that can be made available in the portal. You have have 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
Figure 106: SSL VPN Portal Policy
7. You may now close the tab
9.3 Create the SSL VPN Portal
You have now created two components that, together, do not an SSL VPN portal make. You
must now combine these in the form of a portal that will be associated with an engine.
1. On the 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. NOTE: 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, enter 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
80
Figure 107: 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
81
Figure 108: Target Engine Selection
10. Click OK to complete the portal configuration

11. Refresh the policy on the HQ FW
9.4 Testing the SSL VPN Portal
Now that you have created the portal, it’s time to test it. To do that, open VNC console to
Partner Workstation and perform your test.
Figure 109: VNC console link to Partner Workstation
1. From the Landing Machine, use Partner Workstation shortcut to open VNC console
2. Web browser window should be automatically launched. If it is not open, navigate to JWM
menu on bottom left corner and open Applications → Mozilla Firefox
3. Enter https://ssl-vpn.training.com in the url field
4. Accept the browser warning message related to certificate authenticity. This arises from the
fact that you selected the Use Self-Signed Certificate option
5. Login with user brobertson with the password Pass1234
6. Click the DMZ Web Services icon and you should be able to access the website on the DMZ
server
82
Figure 110: Successful Access to the SSL VPN Portal
83
10 Lab 10: 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 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.
10.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. Open a new tab, under Configuration, click VPN

2. Right-click and select New Policy-Based VPN. The Policy-Based VPN Properties opens.
Leave the Default VPN Profile set to VPN-A Suite. Click OK
Figure 111: Policy Based VPN Properties
3. The VPN editor opens. On the left side, click Gateways. Then right-click and select New
External VPN Gateway
4. In the Name field, enter Partner. Leave the Gateway Profile set to Default (all capabilities)
84
Figure 112: Partner External SGW Properties
5. Click on the Endpoints tab, right-click and select New External Endpoint
6. In the Name field, enter Parter EP
7. In the IP Address field, enter 130.207.200.79, accepting the defaults in the other fields.
NOTE: The remaining settings would likely have to used in cases where the remote endpoint
was behind a device performing NAT.
Figure 113: External Endpoint Properties
8. Click OK. The Endpoint properties closes. NOTE: make sure to click the checkbox next to the
endpoint you just defined to enable it.
9. Click on the Sites tab. Double-click the New Site icon on the right
10. In the Name field, enter Partner Site
11. Under the Network Elements selection, browse to Networks. Locate the network-
85
10.100.100.0/24 element and click Add
12. Click OK, the Site Properties closes. Click OK on the Partner gateway properties
Your completed site definition should look as in the figure below:
Figure 114: Completed Partner Site Definition
The definition of the external security gateway is now complete. You can now create the
topology.
10.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
86
Figure 115: Site-To-Site VPN Topology
The VPN topology is now created. It’s time to move on to selecting the security settings used for
IPSec.
10.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 Partner administrator and he or she 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
• IKEv1 Negotiation Mode: Main (this is somewhat irrelevant)
87
Figure 116: 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
88
Figure 117: 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
Partner-HQ-Profile
2. Double-click under the Key column. Set the pre-shared key as hqpartnervpn.
3. Click the Save button
NOTE: In reality, the pre-shared key should be as complex as practically possible. Optionally,
there is a Generate button that will produce a sufficiently ugly pre-shared key that would need
to communicate to the Partner administrator.
The completed configuration should look as in the figure below
89
Figure 118: Completed Tunnels Configuration
10.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.
1. Click the Home button from the menu bar. Right-click on the HQ FW → Current Policy →
Edit. The security policy opens for editing
2. Right-click on 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 Use VPN. The Action Options window opens. Under the
Action section, select Enforce. 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 119: Completed Site-to-Site VPN Rules
90
10.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. From the Home view, does the status of the 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 “+“ sign at the top to open a new tab

2. Click the VPN SAs button, the element selection window opens
Figure 120: VPN SA Monitoring
3. Navigate to Firewalls → HQ FW, click select and the currently negotiated SAs appear
91
11 Lab 11: 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.
11.1 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, we want 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. Open your security policy 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
4. Select the period for 1 Week
5. For the Target Engine, click the Add button
6. Select the HQ FW from the list and click Select. Click OK. The Hits column is now populated
with data from the last week
92
Figure 121: Rule Counter Analysis
11.2 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. Open the log browser. You should see many log entries
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 “grayed-out“ logs, and select Export → Export Log Events
lfigexportlogsExporting 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
93
Figure 122: Exporting Logs to CSV
8. Click OK and the logs export completes
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 PDF
11.3 Using Rule Tags
Rule tags are one of the most useful features in the SMC (Management). 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 browser 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
94
Figure 123: 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. Open your security policy. Choose the rule where deep inspection is enabled. Right-click and
select Show Related Logs. What happens?
Figure 124: Viewing Logs Related to a Rule
11.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 recored in
95
the Audit Logs, and 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. Open the log browser

2. Just below the work 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
Figure 125: Audit Log Statistics
A nice 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.
96
12 Lab 12: 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.
12.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. Open a new tab and click Administration

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 default view, 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
Figure 126: Policy Comparison - List View
97
There is also another way to see what has changed
1. Between the two compared policies, there is a small “down arrow“. Press this so that the view
of the policies is expanded
2. Note that the differences in the policies are more visually represented. Which view is more
informative is simply a matter of preference
12.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. Open your security policy, in either edit or preview mode

2. Click the “gear“ icon 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
Figure 127: Using the Rule Search Feature
12.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. Viola! The
network details are now displayed.
Some objects may not populate with network details, particularly if they are dynamic object such
as domain object.
98
Figure 128: Enabling Network Details
99
13 Lab 13: 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.
13.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)
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 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.
13.2 Schedule and 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.
1. Open a new tab and click on Monitoring

2. On the left side, click on Design
3. In the white space on the right, right-click and select New Report Design
100
Figure 129: 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 this tab.
6. In the Design tab, right-click on your new report, and select Start
Figure 130: Report Operation Properties
101
7. Click on the Task tab
8. Under the Repeat section, click the Every Day radial button
9. Check Store Report and PDF Export
10. For the email address, enter admin@training.com
Figure 131: 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 132: List of Generated Reports
102
13. Double-click the new report and view it. In the upper right corner, you can click the Print
button and save it as a PDF. NOTE: The way that the report appears in the SMC differs greatly
from how it will look when exported to PDF or other format.
13.3 Create a simple custom report
Now you will create a simple report that is customized to your needs.
1. While still on the Design tab, click the New → Report Design. The report editor opens
2. On the Report Properties panel on the right, enter a name for the report, HQ Custom
Report
3. On the left side, right-click on the existing report section, and select Remove Section
4. Next to the Save icon, click the New icon and select Admin Operation Trends
5. Repeat this procedure, but after clicking the New icon, go to Select near the bottom of the list
Figure 133: Selecting New Report Section
6. In the list that appears, start typing the first few characters of the word information, and
select Top Information Messages
7. Repeat the same procedure and select Top Admins and Operations
8. Add one more section, this time selecting Top Admin Clients
9. Click the Save button. In the box that appears, click OK
10. As an optional step, go back to the Design section on the left tree view and run your new
report
Your completed custom report should appear as below
103
Figure 134: Completed Custom Report
104
14 Lab 14: 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.
14.1 Collecting SGInfo files from engines and management
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 Home button on the menu bar. At the bottom left of the view that appears, expand
Others
Figure 135: Collecting the Management sgInfo
2. Right-click on the Management Server → Tools → Collect sginfo

3. In the window that appears, leave Include FILESTORAGE_DIR Contents unchecked
4. In the Destination Path add Documents to the end of the path. Click OK
105
Figure 136: Management sgInfo Properties
5. The sgInfo for the Management Server runs and returns the following message
Figure 137: Completed sgInfo Task
Now you will collect an sgInfo for the engine through the management client.
1. From the Home screen, expand NGFW Engines on the left

2. Right-click on the HQ FW → Commands → Collect sginfo. The sgInfo task window
appears
3. The Target should contain the HQ FW engine
4. Check the box for Include core files
5. In the Destination Path leave the Management Server radial button selected
106
Figure 138: Engine sgInfo Collection Properties
6. Click OK, the sginfo collection runs
14.2 Collecting an sginfo at the command line
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. To collect an sginfo at the command line, perform
the following steps.
1. Open HQ Firewall console from the Landing Machine
Figure 139: HQ Firewall console shortcut
2. Type root as login

3. Type Forcepoint1 as password
4. 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. This can be decrypted by
editing the Advanced Properties of the engine and deselecting Encrypt Configuration Data
and refreshing the policy. The “-d“ option will ensure that the sginfo contains core dumps
5. 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.
107
14.3 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,
we will consider both scenarios
1. From the Home screen, right-click on the HQ FW → Tools → Capture Traffic

2. In the window that appears, click on Interface 2 and click Select
Figure 140: 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
Collecting a traffic capture at the command line is a great deal more flexible because so many
more options can be used.
1. Open a prompt to the HQ Firewall from the Landing Machine

2. Log in with user root and password Forcepoint1
3. At the command line, run the following command: tcpdump -n -i eth2 -s0 -w hqfw-eth2.pcap
4. Allow that to run several seconds, and press Control-C to stop it.
The previous command collects the entire packet with the “-s“ option. The “-n“ option prevents
the resolution of DNS, and “-i“ specifies the interface.
108

NS Workshop Lab Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NS Workshop Lab Guide

Uploaded by

Copyright:

Available Formats

Forcepoint NGFW

List of Virtual Machines / Containers

Figure 1: Classroom Network Diagram

1 Lab1: Post-installation Administration Tasks

1.1 Create an on-demand backup

1. To create an on-demand backup, click Menu → System Tools → Backup

Figure 2: Creating an On-Demand Backup

2. Click on the Management Server and click Add

1.2 Create a task and schedule ongoing backups

1. Click on the Configuration icon

5. In the Name field, enter “Weekly SMC backup“

Figure 5: Backup Task Properties

9. The task is now created

1. Right-click on the Weekly SMC backup task → Schedule

Figure 7: Schedule Task Properties

5. Click OK. The task is now scheduled

1.3 Enable change control

1. Click the Menu → System Tools → Global Properties

2. Click on the Change Management tab

1.4 Testing Change Control

Figure 11: Viewing Pending Changes

Figure 13: Approving and Committing Changes

1.5 Enable an Administrator password policy

1. Click the Menu → System Tools → Global Properties

• Only One Logon Session for Each User

• Require Password Change After First Logon (should already be selected)

Lastly, you will configure password complexity options

1. Accept the default settings. Feel free to customize

Figure 16: Selecting Password Requirements and Options

2.1 Create a User Role

1. On the menu bar, click the Configuration icon.

• Edit Element properties

6. Click OK to save the new Role

2.2 Create and ACL

• ALL Simple Elements

Figure 18: Access Control List Properties

2.3 Create an SMC Administrator

1. On the left, click on Administrators

6. Click on the Permissions tab and click Add Role

Figure 21: Custom ACL Selection

2.4 Testing the new SMC user

3. Once you are logged in, attempt the following tasks:

Figure 23: Attempt to save restricted element

• Right-click on the HQ FW → Current Policy → Refresh Policy. Can you do that?

Figure 24: Attempting to Refresh a Policy

• On the menu bar, click the Configuration icon

Figure 25: Adding a new Host

4. Close the console and log back it as student

3.1 Use the log browser to locate events of interest

Figure 26: Filtering for DNS Traffic

3.2 Manually create specific filters

Figure 28: Manual Creation of a Protocol Filter

Figure 29: Query Panel with Sample Filters

3.3 Using Statistics

Figure 32: Selecting Top Serves

Figure 34: Showing Records from Statistics View

4.1 Create a new policy

Figure 36: Creating a New Firewall Policy

4.2 Add a Continue Rule for Logging

Figure 37: Logging Options

Figure 38: Logging Continue Rule

2. Configure this rule with the following properties:

• Source: right-click → Set to ANY