Lab 3. Dedicated firewall security (FTD)


This lab we are going to configure the Cisco Firepower Thread Defense (FTD) that can be accessible from web or cli. FTD is an unified software image and includes Cisco ASA features and Firepower services.


Cisco 7200 is now changed with the FTD and UbuntuVM and KaliVM are now put in the same network and zone (a private one). InternetVM remains in the same network and zone (public one). The topology is as follows:


The firewall has a 90 days trial available license, with 4 vCPUs configured, 8196 MB RAM and 4 network adapters (1 for a paravirtualized interface using host-only adapter in VBox network and the rest using Generic Driver adapter - internal configured in GNS3). See here on Table 1 the requirements for deploying VM.

It has four GigabitEthenet interfaces (1 is used for management and the rest of 3 for traffic) and due to the internals of virtual machine, the last 2 are added in the zones from above:

  1. GigabitEthernet2 is connected to InternetVM - zone outside_area
  2. GigabitEthernet3 is connected to internal area switch - zone inside_area

Also, GigabitEthernet0 corresponds to the management interface which is not attached to any other interface in GNS3 (it is attached to vm area of virtualBox, the gateway being your host machine).

For not creating confusions, in the following lines we are going to use the exact names for the traffic interfaces, as follows:

  • GigabitEthernet3 (from GNS3) is GigabitEthernet0/1 in FTD (with logical name inside). We will use for it GigabitEthernet0/1 OR inside
  • GigabitEthernet2 (from GNS3) is GigabitEthernet0/0 in FTD (with logical name outside). We will use for it GigabitEthernet0/0 OR outside

Moreover, all operations are exemplified for WebUI (FDM for Firepower machine). If you would like to use CLI, you can start by looking at this documentation, but when using such devices for the first time, is highly recommended to use in the beginning the GUI of it.

Outside interface is in network:

Inside interface is in network:

After configuring FTD, there is need to deploy configuration (commit it) in order to take effect (be aware that deployments on virtual devices may take up to 3 minutes, so try to do this as rare as possible). A nice feature offered by Cisco is that a configuration difference is given for entities to have a better look over the newer version before committing. You can also download the current configuration in JSON format (is automatically deleted from FTD after deploying new changes) to have a snapshot just for analysis (it cannot be uploaded to machine).

One of the components that require a license on FTD is the deployment. Without it, you cannot do any new configuration and the machine becomes mostly non usable (rely only on already found configuration on it).

FTD also has configured a default policy rule that lets any traffic from inside to outside (and no started traffic from outside to inside).

After booting up the firewall in GNS3, wait for approximately 10 minutes for accessing the firepower management center (FMC or the webUI manager of the FTD). To access it, simply go to a browser and introduce the management ip address with https protocol.

The credentials for FTD:

user: admin

password: Admin123


This machine has 2 interfaces:

  1. enp0s3: use to connect to internal area (with packets filterted by FTD). Assigned address
  2. enp0s8: use to connect the machine to the Internet (using NAT cloud)

It has ip routing activated and an iptables nat rule with MASQUERADE added.

In /etc/network/interfaces, the interface enp0s3 is configured permanently with address + netmask and a route to internal area:

student@internet:~# cat /etc/network/interfaces
auto enp0s3
iface enp0s3 inet static
    up route add -net netmask gw

Is it best not to do any modifications here. But, if you need to restart the networking service after modifications are made in this file, use:

student@internet:~# sudo /etc/init.d/networking restart
[ ok ] Restarting networking (via systemctl): networking.service

A default route to the internet via next hop (default gateway) is also added, alongside a route via firewall to internal subnet.

Also, if there is any other default route (different than the one from above), delete it.

FTD has added in the configuration the default route (route to via hip next hop

For InternetVM there is a configuration issue on the machine (the interface enp0s3 gets the ip address - corresponds to fw). As a workaround for now, do the following:

student@internet:~# sudo ifdown enp0s3; sudo ifup enp0s3
student@internet:~# sudo ip a del dev enp0s3

After this, verify the ip address again on enp0s3:

student@internet:~# ip a s dev enp0s3
   inet [...] scope global enp0s3

This device also has installed a basic apache2 server (with index file in /var/www/html) which is inactive by default. For the next exercises you can use it if you want. Enable it using:

student@internet:~# sudo service apache2 start
student@internet:~# sudo service apache2 status
Active: active (running)

Test it with curl from endpoints (ubuntu or kali VMs).


UbuntuVM and KaliVM are both connected to the same switch and IP addresses added via DHCP. The inside interface from FTD has a static ip configured: with a DHCP server configured for it. The address pool is You can find the server on Device > System Settings > DHCP server and add/edit the current one if you like. A default route is injected also to endpoints via (their gateway). The machines should receive after booting the IP addresses on enp0s3 (Ubuntu) and eht0 (Kali).

After boot, start manually DHCP process on both clients (receive the IP, default route and also use only locally configured DNS servers - and

student@ubuntu:~# sudo dhclient enp0s3
student@ubuntu:~# ifconfig enp0s3
enp0s3: [...]
    inet netmask [...]

Verify the default route using:

student@ubuntu:~# ip r s
default via dev enp0s3 # static route dev enp0s3 [...] # directly connected network

Before starting the exercises, ping (or any other website) from FTD and internal machines to be sure internet is reachable from them. For Cisco VM, you can send icmp-echo requests using the CLI from GUI (the button near the deploy one). Note that the syntax is limited to commands like ping,traceroute or show.


On Cisco FTD we enumerate the following basic features:

  • network objects for creating an alias for IPs (example: instead of having to keep in mind your server IPs, you can apply such labels). It can represent one (type Host) or more IP addresses (type Network). There can also be created groups containing one or more network objects. You can find them on Objects > Networks
  • port objects also for creating labels for different ports. There are multiple already predefined by Cisco on Objects > Ports
  • add one or more interfaces to zones for managing and classifying traffic flows for different policies and configurations. Found on Objects > Security Zones
  • policy rules, which are processed in their order. This means that is very important to have the specific one at the beginning and leave the more generic ones at the end. When creating a policy, there are three actions available for configuration:
    1. Trust: traffic is allowed and no more inspection is done on it
    2. Block: drop packets
    3. Allow: further inspection can be configured here using intrusion policies
  • for network analysis, there is a monitoring section in Dashboard to see, for example, traffic that matched policies. There is also possible to forward syslogs to external servers
  • geolocation for identifying users based on the IP location

As an introduction to this firewall, we will test basic applications of it:

  • filter ICMP and other applications from some clients
  • filter DNS port for some clients
  • filter URLs based on a pre-configured list

1. Filter ICMP application

Let only UbuntuVM ping IPs, deny ping for any other ip of internal network and allow any other applications (like web-browsing or VoIP):

  1. first policy rule is for allowing traffic from zone inside_area AND ip (or the IP you have on UbuntuVM- it can differ, so do not add this one if is not the same) to zone outside_area AND application ICMP (for ipv4)
  2. second one is for denying (BLOCK) traffic from zone inside_area to zone outside_area AND application ICMP
  3. the last one is for allowing any other type of traffic from zone inside_area to zone outside_area (can be called allow-any-from-inside-to-outside)

Add all three to security policies and deploy configuration.

For testing, do the following:

  • from Ubuntu machine, ping It should work
  • from Kali machine, ping also It should not work
  • from both of them, curl (with -L to follow the link in case of 301 HTTP code) or (web server from InternetVM) OR nslookup for a domain. All operations should work on both devices

A nice feature offered by Cisco is packet-tracer command (is NOT the simulator you know) for tracking packets in data path. It is a very important tool for understanding better the logic behind the routing and filtering of firewall. We will use it below for sending ping from Ubuntu (dropped) and from Kali (allowd). See more about icmp code field which are used with this command here. This can be used only from your CLI on the VirtualBox machine, as follows:

# we want to test the second security rule added above
# send icmp-echo-request (code type 8) and wait for icmp-echo-reply (code  type 0)
> packet-tracer input inside icmp 8 0 fqdn detailed
Mapping FQDN to IP address (name solving)

Phase: 1
Subtype: Resolve Egress Interface
Result: ALLOW

Phase: 2
Subtype: log
Result: DROP

input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule[...]

By looking at the results we can see that the first phase consists in finding the next hop for forwarding the ICMP packet (already configured in the machine). Connection to it is allowed. For the next phase, the ICMP packet needs to be sent, but is denied by the security rule (seen also as acl-rule).

Next, send icmp echo requests from Kali:

> packet-tracer input inside icmp 8 0 fqdn detailed
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

Here, there are multiple phases for packets to be forwarded, but the ending is what interests us - action is allow.

2. Filter ports

In Objects > Ports there are multiple ports predefined by Cisco that we are going to use on here. UbuntuVM will be let to access everything from the Internet, but Kali is going to have a small list of pre-defined IPs that is going to use (3 IPs are already added in /etc/hosts) and DNS application is not allowed for it.

Delete the first 2 rules added above and keep only allow-any-from-inside-to-outside.

Your task is:

  • add a rule for dropping DNS for Kali host only (verify the ip for that machine). DNS packets should not exceed the value of 512 bytes, but just to be sure add both DNS over UDP and DNS over TCP applications for destination. In case of IPv6 and DNSSEC responses the TCP protocol is used instead of UDP.
  • add a rule (or keep the old one allow-any-from-inside-to-outside) to allow anything from inside_area zone to outside_area

Deploy and test:

  • curl from Kali should not work. Try this also on Ubuntu and ping or nslookup They should work
  • now try on Kali to ping (or other application like curl, wget), and (entries found in /etc/hosts with IPs from Politehnica subnet All should work.

3. URL filtering

Before doing any configuration, delete the first rules from above with the exception of allow-any-from-inside-to-outside.

Let's say that we want our clients to not use their desktops/laptops for accessing social media websites like or and shopping websites like and To do this, there is firstly need to enable URL filtering from Device > Smart Licenses > View Configuration > URL License and click Enable (it may take a few seconds).

Next, configure policy rules: add from zone inside_area to zone outside_are, from URLs tab > add new ones on the left side URLS and create new URL. Define the 4 required ones from above (you can play with other ones if you want) - URL object and then add them to rule. Deploy configuration and try from both endpoints to access the link using curl. Try also to access other to see they are not blocked.

student@ubuntu:~# curl
<!DOCTYPE html>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Access Denied</title>
<style type="text/css">body {margin:0;font-family:verdana,sans-serif;} h1 {margin:0;padding:12px 25px;background-color:#343434;color:#ddd} p {margin:12px 25px;} strong {color:#E0042D;}</style>
<h1>Access Denied</h1>
<strong>You are attempting to access a forbidden site.</strong><br/><br/>
Consult your system administrator for details.
student@ubuntu:~# curl
<!doctype html>
    <title>Example Domain</title>

You can see also by looking only at the HTTP header:

student@ubuntu:~# curl -s -I
HTTP/1.1 403 Forbidden
Connection: close
student@ubuntu:~# curl -s -I
HTTP/1.1 200 OK

On this feature, there exists also default categories for websites already provided by Cisco (a website can be identified as belonging to such a category). For example, for category Dating is found or for Social Networking The reputation for each of them is set from Trusted (allow) to Untrusted (block). You can use this website for reputation lookup.

4. Other features of Cisco FTD

You can see that on security policies (access rules) there are other tabs which not treated on this lab, like the following:

  1. Users: identify users based on their identities. This login is needed before any other security policies are analyzed. It is useful for adding another layer of security for protection against users that may not have the permission to be in a network area. This is similar to User-Id from Palo Alto. This can be done in two modes:
    • passive-authentication: identities are found in Active Directories (AD). The user is prompted for his credentials
    • active-authentication: the firewall has a CA certificate that needs to be installed on clients' machines for doing SSL decryption and not seeing the untrusted error in browser. A captive portal is needed here.
  2. Intrusion Policy: a subscription license which is already included with the 90 days smart license is the Threat one. It performs intrusion detection + prevention and file control. By enabling it, intrusion policies can be applied to access rules.
  3. File policy: detect malicious software using Advanced Malware Protection (AMP) for Firepower or perform file control. This also needs a smart license to be enabled.

To capture any logs, simply enable logging for security ruler (at the end or at the end and beginning) and see them in Monitor. A syslog can also be configured and used to forward to syslog servers logs regarding dropped packets (for example) with a level of severity (INFO, ALERT etc.). There are very useful in case of monitoring infrastructures and how are clients behaving.

At the end, shutdown the firepower machine from CLI:

> shutdown
This command will shutdown the system. Continue?
Please enter 'YES' or 'NO': YES

After this, stop the device from GNS3 (this will allow it to shutdown correctly and when booting up again it will not do DB checks).

sred/laborator_3._dedicated_firewall_security.txt ยท Last modified: 2019/10/31 10:01 by horia.stoenescu
CC Attribution-Share Alike 3.0 Unported Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0