This is an old revision of the document!
After deploying and configuring successfully the FTD, and also creating a basic topology with just 1 internal client, we decided to create another internal zone (called internal2 - for branch for example) that will host another Ubuntu client. Moreover, we studied in depth some features of FTD and decided to apply them in our secured network:
- traffic filtering based on URL categories
- file policy to detect malware
- SSL decryption for in-depth analysis
- logging to syslog server to generate alerts
Other features include:
- remote access VPN (used to create a gateway for remote users connection to internal network - like we use GP for eve-ng access) - will be studied in detail and implemented on Fortigate machines
- High availability or HA (used to provide redundancy or load balancing) - will be studied also in detail and implemented on Fortigate machines. Use cases of HA active-passive: failover in case of crashes, OS updates of active instance and connection needs to remain up (we may have a website that needs to have 24/7 availability and a patch update is required)
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).
user: admin
password: Admin123
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.
student@internet:~# sudo ifdown enp0s3; sudo ifup enp0s3 student@internet:~# sudo ip a del 172.31.0.1/24 dev enp0s3
After this, verify the ip address again on enp0s3:
student@internet:~# ip a s dev enp0s3 [...] inet 172.31.0.2/24 [...] 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 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.
Remember that we deployed the firewall with 4 interfaces: 1 for mgmt and the rest of 3 for traffic (only 2 of them inside and outside where used and configured). Then, there is 1 left we need to configure for inside traffic data.
You need to:
- firstly shutdown the machine (only from cli!)
- enable the 3rd interface in routed mode, name inside2 and create a new dhcp server to apply to it
- create a new security zone named inside2 and also the corresponding nat and access policy rules
Test if client2 has Internet access.
In the previous lab, we decided to block facebook site for internal users, but this was based on static url entries defined by us. As we want to block a set of websites based on their type, we can use url categories.
Your task is to create an access policy rule for the internal zones to block the url category where facebook is also located. You need to enable the url license and find the corresponding category for facebook (hint: Talos).
For testing, do the following:
- test access from client to twitter, snapchat, tiktok etc. It should fail.
- test access to other websites like google.com, digi24.ro etc.
# 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.
We can block a client from downloading malware file from websites, emails, ftp server etc. by using file policy in an access policy. There is need firstly to enable the following licenses: threat and malware, then create an access policy with action Allow (the only action where file policy can be used), from zones inside and inside2 to outside zone. This will protect internal users from downloading any known malware by Talos.
After deploy, download from Palo Alto website samples of Wildfire (their sandbox and considered the best on the market) malware files.
Then, go to fdm > monitoring > dashboard malware and see how transactions for msexe files are identified.
We can inspect also encrypted traffic using FTD in two ways:
- decrypt re-sign (behaves like a mitm)
- decrypt known key (if you are the owner of the website - add it also to ftd and decrypt every packets s2c or c2s)
To be easier for configuration, we will use only the first option. From Polices > SSL decryption > enable decrypt re-sign and download the CA certificate, then upload it to client1.
Create a policy for traffic coming from inside to outside zone and for other fields keep any. After commit, try to access any website and see the browser error: unknown_issuer. This is because it does not know about that issuer/CA the ftd is currently using. To solve this, add the uploaded CA in it's trust store.
In the beginning of 2020, TLS version 1.0 and 1.1 became obsolete and many websites (850.000 were still using this old versions as said by netcraft) were affected by this decision. Currently, many of them have switched to newer versions like 1.2 and 1.3 and also browser implemented endpoint filtering and blocking websites if TLS version is less or equal to 1.1.
As, for now, we don't collect from internal clients data like browser version, we will suppose they did not update it for some time (which is the case for us also).
There exists a nice suite of testing websites called badssl where you can find different web pages with security problems: expired or revoked certificate, bad CN or tls version etc. All of those can be used for testing different scenarios, without having to create, for example, virtual hosts on apache2 servers with different problems.
From client1, go to badssl website and try all three tls websites: tls-v-1-0, tls-v-1-2 and tls-v-1-3. You should have access to all of them. Check also other websites like: expired, wrong-host etc. and see how blocking is already done by the browser.
To enforce this new requirement, we need to create another ssl decryption rule: will block all servers that are using tls1.0, tls1.1 and also ssl3.0 (which is for a long period of time eol). Check again tls testing websites from above and see how connection is dropped for the first 2.
Of course, using the method do not decrypt, we can except some websites based on url, users, certificate or tls version from decryption (we may not want to to decrypt health or banking data for our users).
As logging is limited on our FTD device, we can use an external device for log collection. This can be a syslog server, that we will configure firstly on our linux router VM.
To configure it, do the following:
sudo apt-get update sudo apt-get install syslog-ng sudo mv /etc/syslog-ng/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf.bkup # same the default one sudo vim /etc/syslog-ng/syslog-ng.conf # add here: @version: 3.5 @include "scl.conf" @include "`scl-root`/system/tty10.conf" options { time-reap(30); mark-freq(10); keep-hostname(yes); }; source s_local { system(); internal(); }; source s_network { syslog(transport(udp) port(1025)); }; destination d_local { file("/var/log/syslog-ng/messages_${HOST}"); }; destination d_logs { file( "/var/log/syslog-ng/logs.txt" owner("root") group("root") perm(0777) ); }; log { source(s_local); source(s_network); destination(d_logs); }; # create the log dir and restart the server sudo mkdir /var/log/syslog-ng sudo touch /var/log/syslog-ng/logs.txt sudo service syslog-ng restart # check the service if it is LISTENING on port 1025 sudo netstat -atupn | grep 1025
After this, go to another terminal on Router VM and test the syslog server:
logger -n 10.3.0.84 -P 1025 "testing my new syslog server"
And from another terminal, check the logs.txt file:
tail -f /var/log/syslog-ng/logs.txt Nov 10 10:00:00 ubuntu eve: testing my new syslog server
Do the same thing from FTD expert mode and check with tail logs.txt:
> expert admin@ciscoasa:~$ logger -n 10.3.0.84 -P 1025 "testing syslog from ftd"
Next, go to FDM and configure syslog for client. There are 3 important parts here:
1. create the syslog server object
2. enable logging for remote device and select severity level as informational
3. create a new access policy rule with:
> shutdown This command will shutdown the system. Continue? Please enter 'YES' or 'NO': YES
This will ensure everything is handled right when shutting down the device (if you just stop it from webui, you will need to redo all the steps from above!).