Workshop Logistics

Accessing an AWS environment

For AWS Immersion Days and other events, we will provide you the following via email on the day of the event:

• AWS sign in link
• IAM User w/ console access
• Password for the IAM User

Accessing the FortiGate CNF Console

FortiGate CNF and other SaaS solutions are tied to your FortiCloud account. If you do not already have one, please navigate here and complete the registration process.

If you already have an account and don’t want to use that for this lab, it is recommended to create your own FortiCloud account.

Once logged in, you will see your FortiCloud dashboard.

You will log into the FortiGate CNF console later during the hands on section.

Navigating the AWS Console

When you first login you will see the Console Home page.

Use the Search Box at the top to search for services such as EC2, VPC, CloudFormation, etc.

When the results pop up, right click the name of the service and open the desired console in a new tab. This makes navigation easier.

This concludes this section.

AWS Networking Concepts

Before diving into the reference architecture for this workshop, let’s review core AWS networking concepts.

AWS Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

Availability Zones (AZ) are multiple, isolated locations within each Region that have independent power, cooling, physical security, etc. A VPC spans all of the AZs in the Region.

Region, is a collection of multiple AZs in a geographic location. The collection of AZs in the same region are all interconnected via redundant, ultra-low-latency networks.

All subnets within a VPC are able to reach each other with the default or intrinsic router within the VPC. All resources in a subnet use the intrinsic router (1st host IP in each subnet) as the default gateway. Each subnet must be associated with a VPC route table, which specifies the allowed routes for outbound traffic leaving the subnet.

An Internet Gateway (IGW) is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It therefore imposes no availability risks or bandwidth constraints on your network traffic.

AWS NAT Gateway (NAT GW) is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services cannot initiate a connection with those instances.

AWS Transit Gateway (TGW) is a highly scalable cloud router that connects your VPCs in the same region to each other, to on-premise networks, and even to the internet through one hub. With the use of multiple route tables for a single TGW, you can design hub and spoke routing for traffic inspection and enforcement of security policy across multiple VPCs.

AWS (Gateway Load Balancer (GWLB) is a transparent network gateway that distributes traffic (in a 3/5 tuple flow aware manner) to a fleet of virtual appliances for inspection. This is a regional load balancer that uses GWLB endpoints (GWLBe) to securely intercept data plane traffic within consumer VPCs in the same region.

In this workshop we will use all these components to test FortiGate CNF in an enterprise design.

For a deep dive on AWS networking concepts in your own lab, outside of this event, you can follow the AWS Network Immersion Day workshop in your own AWS account at your leisure.

This concludes this section.

AWS Common Architecture Patterns

While there are many ways to organize your infrastructure there are two main ways to design your networking when using GWLB, centralized and distributed. From the perspective of networking, routing, and GWLBe placement. We will discuss this further below.

FortiGate CNF is a SaaS offering that on the backend uses FortiGates, AWS GWLB, and GWLB endpoints to intercept customer traffic and inspect this transparently. As part of the deployment process for FortiGate CNF instances, the customer environment will need to implement VPC routing and Ingress Routing at the IGW to intercept the traffic to be inspected.

The FortiGate CNF security stack which includes the AWS GWLB and other components will be deployed in Fortinet managed AWS accounts. The details of the diagram are simply an example of the main components used in FortiGate CNF. This is more to understand what happens when customer traffic is received at our GWLB.

Decentralized designs do not require any routing between the protected VPC and another VPC through TGW. These designs allow simple service insertion with minimal routing changes to the VPC route tables. The yellow numbers show the initial packet flow for a session and how it is routed (using ingress and VPC routes) to the GWLBe endpoint which then sends traffic to the FortiGate CNF stack. The blue numbers show the returned traffic after inspection by the FortiGate CNF stack.

Centralized designs require the use of TGW to provide a simple hub and spoke architecture to inspect traffic. These can simplify east-west, egress, and ingress traffic inspection needs while removing the need for IGWs and NAT Gateways to be deployed in each protected VPC for egress inspection. You can still mix a decentralized architecture to inspect ingress and even egress traffic while leveraging the centralized design for all east-west inspection.

The yellow numbers show the initial packet flow for a session and how it is routed (using ingress, VPC routes, and TGW routes) to the GWLBe which then sends traffic to the FortiGate CNF stack. The blue numbers (east-west) and purple numbers (egress) show the returned traffic after inspection by the FortiGate CNF stack.

For more examples of distributed and centralized models, please reference the examples in the FortiGate CNF Admin Guide.

This concludes this section.

FortiGate CNF Terminology

This concludes this section.

Task 1

Task 1: Subscribe to FortiGate CNF in AWS Marketplace & Onboard an AWS account

• 1. Log into your AWS account and navigate to the AWS Marketplace listing for FortiGate CNF (click for MP listing). In the upper right corner, click View purchase options. On the next page, click Subscribe.

• 2. In the available offers list, select the Public offer.

• 3. The page should update and show the GA pricing. Click Subscribe.

• 4. A green banner will be at the top of the screen. Click Set up your account and this will open a new tab in the AWS Marketplace console.

• 5. Select Login or create vendor account and this will open a pop up window to login to FortiCloud.

• 6. Once completed, you will see that the FortiCloud account is now linked with the AWS account. Click Launch template to open a new tab in the CloudFormation console. On the CloudFormation console, tick the Capabilities box and then click Create stack. Once the template has been successfully created, move on to the next step.

• 7. Login to FortiGate CNF Console. Once logged in, click on your account tile and you will see the CNF dashboard.

• 8. This concludes this section.

Task 2

Task 2: Deploying CNF Instances and GWLBe endpoints

• 1. In the FortiGate CNF console, navigate to CNF instances and click New > CNF.

• 2. Provide a name for the CNF instance, select us-east-2 for the region for deployment, select Internal S3 for the log type, and select the S3 bucket created by CloudFormation for the logging destination. Then click Save. This will drop you back to the list of CNF instances while this is deployed in the background.

• us-east-1 (N. Virginia)
• us-east-2 (Ohio)
• us-west-1 (N. California)
• us-west-2 (Oregon)
• ca-central-1 (Central)
• sa-east-1 (Sao Paulo)
• eu-central-1 (Frankfurt)
• eu-central-2 (Zurich)
• eu-west-1 (Ireland)
• eu-west-2 (London)
• il-central-1 (Tel Aviv)
• ap-east-1 (Hong Kong)
• ap-northeast-1 (Tokyo)
• ap-southeast-1 (Singapore)

• 3. The CNF Instance should show up as active after roughly 10 minutes, now is a great time for a break :). Then you can select and edit it to deploy endpoints and assign a policy set.

• 4. On the Configure Endpoints section of the wizard, click the New button. Then you can select the account, VPC, then toggle the Select from all subnets to off (this filters the subnets to only show ones that are properly tagged), and the subnet to deploy the VPC endpoint to. Repeat this step for all subnets in the table below, then click the Next button. Once all have been created, click Next.

• 5. On the Configure Policy Set section of the wizard, the default ‘allow_all’ policy is used to allow all traffic from a Layer 4 perspective and click Exit. You should then see the list of CNF instances again.

• 6. To validate all GWLBe endpoints have been deployed and are active (takes ~5 mins), select and edit the CNF instance and click Next to view the GWLBe endpoints on the Configure Endpoints section of the wizard. Then click Exit to leave the CNF configuration wizard.

• 7. Log into your AWS Account and navigate to the VPC Console > Endpoints. Each of the GWLBe endpoints you deployed in the FortiGate CNF Console should be visible in your account. Notice the tag name and value pairs assigned to the endpoints.

• 8. To validate that the relevant VPC routes have been automatically created to route traffic to the GWLBe endpoints, in the AWS VPC console, navigate to Virtual Private Cloud > Route Tables, select each of the route tables listed below and confirm these routes exist in the route tab of the route table details pane.

• 9. To confirm that app1 in the Application VPC is reachable, in the AWS CloudFormation console, toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for URLforApp1. Click on the value for that output to check that App1 is reachable now. You should see a simple webpage with some metadata about the backend web server instance that is reachable via the public Network Load Balancer (NLB).

• 10. This concludes this section.

Task 3

Task 3: Create a policy set and apply it to a FortiGate CNF Instance

• 1. At this point, we are using the default allow_all policy set which allows all communication to be allowed without any restriction from a Layer 4 and Layer 7 perspective.

• 2. To customize the actual L4 rules and L7 security profile groups applied, in the FortiGate CNF Console navigate to Configuration > Policy Sets to create your own policy set. Simply click Create New, select Policy Set, and give your policy set a name.

• 3. Before adding in L4 rules within the policy set, create a few simple address objects. Navigate to Configuration > Addresses, click New, and Address. Then create each of the address objects below.

• 4. Next, create an Address Group to include all the RFC 1918 class objects. On the same page, click New, and Address Group. Then create each the address object below.

• 5. In FortiGate CNF you can create different types of address objects to be more flexible and granular in your rules within your policy set. Create an FQDN based address object by clicking New, and Address. Select FQDN for Type, then create the address object below.

• 6. Geography based address objects are available in FortiGate CNF. This allows controlling traffic based on public IPs assigned to countries around the globe. These objects can be used as a source or destination object within policies used in a policy set. Create a geo based address object by clicking New, and Address. Select Geography for Type, then create the address objects below.

• 7. Dynamic metadata based address objects are available in FortiGate CNF. This allows controlling of traffic based on things such as VPC ID, Auto Scale Group, EKS Cluster or Pod, and even Tag Name + Value pairs for a given AWS account and region. Create a dynamic based address object by clicking New, and Address. Select Dynamic for Type, then create the address objects below.

Note: For each object, you will use the same values for these settings:

Here is the list of dynamic objects to create:

• 8. Now you will create a policy set to enforce L4 rules using the address objects you just created in the previous steps. Navigate to Configuration > Policy Sets and click New, Policy Set. Give it a name and click Ok. You will be returned to the list of policy sets. Select your policy set and click Edit.

• 9. Now you can create the policies listed below to control all directions of traffic within the example environment. Click New and create the policies listed below:

• 10. In order to use this policy set, it must be applied to the deployed FortiGate CNF Instance. Navigate to CNF instances and select and edit the CNF Instance then click the Configure Policy Set bread crumb. In the Apply Policy Set, select your policy set then click Save then Exit.

• 11. This concludes this section.

Task 4

Task 4: Validate Resolution of Dynamic Address Objects

• 1. At this point, we are using a few dynamic address objects in our policy set. To confirm what they have resolved to, navigate to CNF Instances page and right click the instance and select View Policy Set Revision.

• 2. On the pop up window, select the Addresses tab and double click each of the dynamic address objects to confirm they resolve the IP addresses listed below.

• 3. In the EC2 Console, Navigate to Auto Scaling > Auto Scale Groups then select and edit the existing group.

• 4. Next, edit the group details and set the Desired, Minimum, and Maximum capacity to 1. A new EC2 instance will be launched within a minute or two.

• 5. In the CNF console navigate to Policy & Objects > Addresses and create a new dynamic address object based on the Auto Scale Group name, reference the values below:

• 6. For the address object to be resolved, it must be used in a policy set that is applied to a deployed CNF Instance. In the CNF console navigate to Policy & Objects > Policy Sets, then edit the existing policy set, and add the new address object to the IPinfo-Egress rule as an additional source.

• 7. Navigate to CNF Instances page and right click the entry and select Sync Policy Set, then within a few seconds click Refresh.

• 8. On the CNF Instances page and right click the instance and select View Policy Set Revision again, then select the Addresses tab and double click the new dynamic address object to see the resolved private IP.

• 9. The CNF Instance will continue to check what running resources match the configured filter in the dynamic address objects and update the list of resolved IP(s). To see this in action, in the EC2 Console, Navigate to Auto Scaling > Auto Scale Groups then select and edit the existing group and set the Desired, Minimum, and Maximum capacity to 3.

• 10. Within 60 seconds the existing address object will be updated. Navigate to CNF Instances page and right click the instance and select View Policy Set Revision again, then select the Addresses tab and double click the new dynamic address object to see the latest resolved private IPs.

• 11. This concludes this section.

Distributed Ingress

For this traffic flow we will focus on the Application VPC. Distributed ingress is commonly used when there is a need to inspect traffic for a VPC that is directly accessible with an attached IGW and resources with a public Elastic IP (EIP) or behind a public load balancer (ie ALB, NLB, etc). The benefit of this design is that traffic does not need to traverse additional AWS networking components for inspection so each VPC is isolated from others. The caveat to consider is that each VPC would need a directly attached IGW and resources such as load balancers, NAT GWs, etc that have additional cost.

Step 1: An inbound connection starts with an external user initiating a connection to a public resource such as a public NLB. The public NLB has a DNS record that resolves to a public IP for one of the NLB’s Elastic Network Interface (ENI) in either public subnet. The first packet (ie TCP SYN) will then be seen at the IGW attached to the VPC where the public NLB is deployed. Since there is a Ingress route table assigned to the IGW, traffic destined to either public subnet will be sent to the GWLBe endpoint in the same AZ.

Step 2: The traffic is received at the GWLBe endpoint which then routes the traffic to the associated GWLB ENI in the same AZ in the managed Fortinet AWS account/VPC. This is done behind the scene using AWS Private Link.

Step 3: The traffic is received at the GWLB ENI and is then encapsulated in a GENEVE tunnel and routed to one of the instances in the FortiGate CNF auto scale group for traffic inspection. Post inspection, if the traffic is allowed, the instance will hairpin the traffic back to the same GWLB ENI over GENEVE. Then the GWLB ENI will hairpin the traffic back to the same GWLBe endpoint.

Step 4: The GWLBe endpoint will then route the inspected traffic to the intrinsic router. The intrinsic router will route traffic directly to the NLB’s ENI as specified in the VPC route table assigned to the subnet.

Step 5: The NLB will send traffic to a healthy target, in either AZ since cross zone load balancing is enabled.

Step 6: The web server will receive the traffic and respond. The return traffic will flow these steps in reverse.

• 1. To test out this flow navigate to the AWS CloudFormation console and toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for URLforApp1. Click on the value for that output to check that App1 is no longer reachable now. Click on the value for the output EncryptedURLforApp1 and you will see the self-signed certificate warning. Once you accept the warning, you will see the test web page.

Distributed Egress

For this traffic flow we will focus on the Application VPC. Distributed egress is commonly used when there is a need to inspect traffic for a VPC that has an attached IGW and resources with a public Elastic IP (EIP) or that are behind a NAT GW. The benefit of this design is that traffic does not need to traverse additional AWS networking components for inspection so each VPC is isolated from others. The caveat to consider is that each VPC would need a directly attached IGW and resources such as NAT GWs that have additional cost.

Step 1: An outbound connection starts with a private EC2 instance initiating a connection to a public resource. The first packet (ie TCP SYN) will be routed to the intrinsic router which will route traffic to the NAT GW in the same AZ, as configured in the assigned VPC route table. The EC2 instance has a default route, received via DHCP, that points to the first host IP in the subnet which is the intrinsic router.

Step 2: The traffic is received at the NAT GW ENI which then routes the traffic to the associated GWLBe endpoint in the same AZ, as configured in the assigned VPC route table.

Step 3: The traffic is received at the GWLBe endpoint which then routes the traffic to the associated GWLB ENI in the same AZ in the managed Fortinet AWS account/VPC. This is done behind the scene using AWS Private Link.

Step 4: The traffic is received at the GWLB ENI and is then encapsulated in a GENEVE tunnel and routed to one of the instances in the FortiGate CNF auto scale group for traffic inspection. Post inspection, if the traffic is allowed, the instance will hairpin the traffic back to the same GWLB ENI over GENEVE. Then the GWLB ENI will hairpin the traffic back to the same GWLBe endpoint.

Step 5: The GWLBe endpoint will then route the inspected traffic to the intrinsic router. The intrinsic router will route traffic directly to the IGW as specified in the VPC route table assigned to the subnet.

Step 6: The destination will receive the traffic and respond. The return traffic will be intercepted at the IGW and routed to the GWLBe endpoint. Then the return traffic follow these steps in reverse.

• 1. To test out this flow navigate to the AWS EC2 console and go to Instances > Instances. Then select either AppInstance and click Connect > EC2 serial console. Copy the instance ID as this will be the username and click connect.

• 2. Login to the instance with the instance ID as the username and FORTInet123! as the password. Then run the commands below to test traffic:

ping 8.8.8.8

curl http://ipinfo.io

curl https://ipinfo.io

Centralized Egress

For this traffic flow we will focus on the Shared Services, Workload, and Inspection VPCs. Centralized egress is commonly used when there is a strong desire to control egress traffic through a common set of NAT GWs in an egress or what we call an Inspection VPC. The benefit of this design is that you only need NAT GWs in the Inspection VPC (one per AZ) vs every VPC (one per AZ), which have an hourly cost. The caveat of this design is traffic will traverse additional AWS networking components for inspection (ie TGW, etc) that will have additional cost.

Step 1: An outbound connection starts with a private EC2 instance initiating a connection to a public resource. The first packet (ie TCP SYN) will be routed to the intrinsic router which will route traffic to the TGW attachment in the same AZ, as configured in the assigned VPC route table. The EC2 instance has a default route, received via DHCP, that points to the first host IP in the subnet which is the intrinsic router.

Step 2: The traffic is received at the TGW ENI which then routes the traffic to the Inspection VPC TGW attachment, as configured in the associated Spoke VPC TGW route table.

Step 3: The traffic is received at the TGW ENI in the Inspection VPC which then routes the traffic to the GWLBe endpoint in the same AZ, as configured in the associated VPC route table.

Step 4: The traffic is received at the GWLBe endpoint which then routes the traffic to the associated GWLB ENI in the same AZ in the managed Fortinet AWS account/VPC. This is done behind the scene using AWS Private Link.

Step 5: The traffic is received at the GWLB ENI and is then encapsulated in a GENEVE tunnel and routed to one of the instances in the FortiGate CNF auto scale group for traffic inspection. Post inspection, if the traffic is allowed, the instance will hairpin the traffic back to the same GWLB ENI over GENEVE. Then the GWLB ENI will hairpin the traffic back to the same GWLBe endpoint.

Step 6: The GWLBe endpoint will then route the inspected traffic to the intrinsic router. The intrinsic router will route traffic directly to the NAT GW in the same AZ as specified in the VPC route table assigned to the subnet.

Step 7: The traffic is received at the NAT GW ENI which then routes the traffic to the intrinsic router. The intrinsic router will route traffic directly to the IGW as specified in the VPC route table assigned to the subnet.

Note: The NAT GW will source NAT the traffic to the private IP assigned to its ENI.

Step 8: The destination will receive the traffic and respond. The return traffic will follow these steps in reverse.

• 1. To test out this flow navigate to the AWS EC2 console and go to Instances > Instances. Then select either WrkInstance and click Connect > EC2 serial console. Copy the instance ID as this will be the username and click connect.

• 2. Login to the instance with the instance ID as the username and FORTInet123! as the password. Then run the commands below to test traffic:

ping 8.8.8.8

curl http://ipinfo.io

curl https://ipinfo.io

Centralized East West

For this traffic flow we will focus on the Shared Services, Workload, and Inspection VPCs. Centralized East West is commonly used when there is need for multiple VPCs in the same region to access common private resources such as a shared services VPC, premise items, or workloads/services in other VPCs. The benefit of this design is that this a flexible but simple way to interconnect many resources in the same region. The caveat of this design is traffic will traverse additional AWS networking components for inspection (ie TGW, etc) that will have additional cost.

Step 1: An outbound connection starts with a private EC2 instance initiating a connection to a public resource. The first packet (ie TCP SYN) will be routed to the intrinsic router which will route traffic to the TGW attachment in the same AZ, as configured in the assigned VPC route table. The EC2 instance has a default route, received via DHCP, that points to the first host IP in the subnet which is the intrinsic router.

Step 2: The traffic is received at the TGW ENI which then routes the traffic to the Inspection VPC TGW attachment, as configured in the associated Spoke VPC TGW route table.

Step 3: The traffic is received at the TGW ENI in the Inspection VPC which then routes the traffic to the GWLBe endpoint in the same AZ, as configured in the associated VPC route table.

Step 4: The traffic is received at the GWLBe endpoint which then routes the traffic to the associated GWLB ENI in the same AZ in the managed Fortinet AWS account/VPC. This is done behind the scene using AWS Private Link.

Step 5: The traffic is received at the GWLB ENI and is then encapsulated in a GENEVE tunnel and routed to one of the instances in the FortiGate CNF auto scale group for traffic inspection. Post inspection, if the traffic is allowed, the instance will hairpin the traffic back to the same GWLB ENI over GENEVE. Then the GWLB ENI will hairpin the traffic back to the same GWLBe endpoint.

Step 6: The GWLBe endpoint will then route the inspected traffic to the intrinsic router. The intrinsic router will route traffic to the TGW attachment in the same AZ as specified in the VPC route table assigned to the subnet.

Step 7: The traffic is received at the TGW ENI which then routes the traffic to the Shared Services VPC TGW attachment, as configured in the associated Inspection VPC TGW route table.

Step 8: The traffic is received at the TGW ENI in the Shared Services VPC which then routes the traffic to the destination, as configured in the associated VPC route table.

• 1. To test out this flow navigate to the AWS EC2 console and go to Instances > Instances. Then select WrkInstance2 and click Connect > EC2 serial console. Copy the instance ID as this will be the username and click connect.

• 2. Login to the instance with the instance ID as the username and FORTInet123! as the password. Then run the commands below to test traffic:

ping 10.1.2.10

ssh ec2-user@10.1.2.10

curl -k https://10.1.2.10

Task 1

Task 1: Deploying CNF Instances and GWLBe endpoints

• 1. In the AWS CloudFormation console, make sure you are in the us-west-1 (N. California) region, then toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for FortiAnalyzerLoginURL. Copy just the public IP as we will need this for the next step.

• 2. In the FortiGate CNF console, navigate to CNF instances and click New. Provide a name for the CNF instance, select us-west-1 (N. California) for the region, toggle FortiManager mode to on, select FortiAnalyzer for the log type and paste the public IP from the previous step. To save time, you can configure the GWLBe endpoints at the same time. In the Endpoints section, click the New button. Then you can select the account, VPC, then toggle the Select from all subnets to off (this filters the subnets to only show ones that are properly tagged), and the subnet to deploy the VPC endpoint to. Repeat this step for all subnets in the table below, then click the Next button. Once all have been created, click OK.

• 3. The CNF Instance should show up as active after roughly 10 minutes (Now is a great time for a break :) ). The endpoints will be deployed at this point.

• 4. To validate all GWLBe endpoints have been deployed and are active (takes ~5 mins), select and edit the CNF instance and click Next to view the GWLBe endpoints on the Configure Endpoints section of the wizard. Then click Exit to leave the CNF configuration wizard.

• 5. Log into your AWS Account and navigate to the VPC Console > Endpoints. Each of the GWLBe endpoints you deployed in the FortiGate CNF Console should be visible in your account. Notice the tag name and value pairs assigned to the endpoints.

• 6. To validate that the relevant VPC routes have been automatically created to route traffic to the GWLBe endpoints, in the AWS VPC console, navigate to Virtual Private Cloud > Route Tables, select each of the route tables listed below and confirm these routes exist in the route tab of the route table details pane.

• 7. To confirm that app1 in the Application VPC is reachable, in the AWS CloudFormation console, toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for URLforApp1. Click on the value for that output to check that App1 is reachable now. You should see a simple webpage with some metadata about the backend web server instance that is reachable via the public Network Load Balancer (NLB).

• 8. This concludes this section.

Task 2

Task 2: FortiManager Integration

• 1. In the AWS CloudFormation console, make sure you are in the us-west-1 (N. California) region, then toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for FortiManagerLoginURL. Login to the FortiManager with the username admin and the password FORTInet123!.

• 2. In the FortiManager GUI for the first login, you will be prompted to complete the setup wizard. Click Begin, Next, and Finish. Then on the home page, select Device Manager.

• 3. At the top left, click Add Device and select Discover Device.

• 4. In the FortiGate CNF console, navigate to CNF instances and select and edit the CNF instance, then toggle Display Primary FortiGate Information. Copy the Primary FGT information and click Exit.

• 4. In the FortiManager GUI, enter in the Primary FGT IP, toggle on Use Legacy Device Login, fill out the rest and click Next.

• 5. On the next page, click Next and the FortiManager will begin discovering and adding the CNF Instance.

• 6. Once this process is complete, click Import Now, then Import Policy Package and click Next. Select Automatically import all VDOMs and click Next and the FortiManager will import a policy package for each VDOM. Once complete, click Finish.

• 7. In the top left, click Device Manager then click Policy & Object. Then grab this bar and drag it to the right to see the full names of the policy packages.

• 8. Then right click the policy package ending in …root and click Delete. Do the same for the default policy package as well. Now you should be left with the policy package ending in …FG-Traffic.

• 9. Select policy #1, click Edit, then Edit again in the drop down menu.

• 10. In the edit firewall policy page, change the name to Inbound, set the Destination to be RFC1918-GRP, select default for Application Control, then all_default for IPS, toggle Log Allowed Traffic to All Sessions, finally type a note in the Change Note text box, then click OK to apply the changes.

• 11. Right click policy #1 again and click Clone Reverse to create a new policy. Then select policy #2, click Edit, then Edit again in the drop down menu.

• 12. In the edit firewall policy page, change the name to Outbound, select default for AntiVirus Profile, then monitor-all for Web Filter Profile, then deep-inspection for SSL/SSH Inspection, finally type a note in the Change Note text box, then click OK to apply the changes.

• 13. Right click the policy package and select Install Wizard. Then click Next, Next, Install. The FortiManager will begin pushing the modified policy package to the CNF Instance. Once complete, click Finish.

• 14. This concludes this section.

Task 3

Task 2: FortiAnalyzer Integration

• 1. In the AWS CloudFormation console, make sure you are in the us-west-1 (N. California) region, then toggle the view nested button to off > then select the stack name > and on the details pane select the outputs tab. You should see the output for FortiAnalyzerLoginURL. Login to the FortiAnalyzer with the username admin and the password FORTInet123!.

• 2. In the FortiAnalyzer GUI for the first login, you will be prompted to complete the setup wizard. Click Begin, Next, and Finish. Then on the home page, select Device Manager.

• 3. At the top right, click the Bell icon and select 2 Unauthorized device(s).. Then select both devices and click Authorize, on the next page click OK. Once complete, click Close.

• 4. Once logs have been received from all CNF instances, the widgets should all show green in a few minutes.

• 5. In the top left, click Device Manager then click FortiView and look at Top Threats. In ~15-20 minutes, logs should be generated by the EC2 instances in the Application VPC and the Nikto Scanner instance in the Management VPC. You can drill down on the widgets to get more information. Click on Eicar_TEST_File to see the source of the malware, then click the interface name to get to the formatted logs. Clicking on a log entry will bring up the log details.

• 6. Click on the following FortiView pages to see additional drill down widgets and click through the results to see more:
  • Traffic -> Top Sources
  • Traffic -> Top Destinations
  • Traffic -> Policy Hits
  • Applications & Websites -> Top Applications
  • Applications & Websites -> Top Website Domains
  • Applications & Websites -> Top Categories
  • System -> Resource Usage

• 7. In the top left, click FortiView then click Log View then select FortiGate -> Security -> Intrusion Prevention. Double click any log entry to view the log details.

• 8. This concludes this section.