This is an old revision of the document!
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 192.168.56.0/24 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:
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).
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: 172.31.0.0/24
Inside interface is in network: 192.168.45.0/24
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).
FTD also has configured a default policy rule that lets any traffic from inside to outside (and no started traffic from outside to inside).
This machine has 2 interfaces:
It has ip routing activated and an iptables nat rule with MASQUERADE added.
student@internet:~# cat /etc/network/interfaces [...] auto enp0s3 iface enp0s3 inet static address 172.31.0.2 netmask 255.255.255.0 up route add -net 192.168.45.0 netmask 255.255.255.0 gw 172.31.0.1
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 192.168.159.2 (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 0.0.0.0/0) via hip next hop 172.31.0.2.
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 apache2.service [...] 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: 192.168.45.1/24 with a DHCP server configured for it. The address pool is 192.168.45.46-192.168.45.254. 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 192.168.45.1 (their gateway). The machines should receive after booting the IP addresses on enp0s3 (Ubuntu) and eht0 (Kali).
student@ubuntu:~# sudo dhclient enp0s3 student@ubuntu:~# ifconfig enp0s3 enp0s3: [...] inet 192.168.45.47 netmask 255.255.255.0 [...] [...]
Verify the default route using:
student@ubuntu:~# ip r s default via 192.168.45.1 dev enp0s3 # static route 192.168.45.0/24 dev enp0s3 [...] # directly connected network
Before starting the exercises, ping google.ro (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:
As an introduction to this firewall, we will test basic applications of it:
Let only UbuntuVM ping IPs, deny ping for any other ip of internal network and allow any other applications (like web-browsing or VoIP):
Add all three to security policies and deploy configuration.
For testing, do the following:
# 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 192.168.45.48 8 0 fqdn google.ro detailed Mapping FQDN google.ro to IP address 172.217.22.35 (name solving) Phase: 1 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW [...] Phase: 2 Type: ACCESS-LIST Subtype: log Result: DROP [...] Result: 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 192.168.45.47 8 0 fqdn google.ro detailed [...] Result: 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.
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.
Your task is:
Deploy and test:
Before doing any configuration, delete the first 2 rules from above and keep only 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 facebook.com or twitter.com and shopping websites like emag.ro and alibaba.com. 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 emag.ro <!DOCTYPE html> <html> <head> <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> </head> <body> <h1>Access Denied</h1> <p> <strong>You are attempting to access a forbidden site.</strong><br/><br/> Consult your system administrator for details. </p> </body> </html>
student@ubuntu:~# curl example.com <!doctype html> <html> <head> <title>Example Domain</title> [...]
You can see also by looking only at the HTTP header:
student@ubuntu:~# curl -s -I emag.ro HTTP/1.1 403 Forbidden Connection: close [...]
student@ubuntu:~# curl -s -I example.com HTTP/1.1 200 OK [...]
You can see that on security policies (access rules) there are other tabs which not treated on this lab, like the following:
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.
> 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).