Lab 6. Fortigate introduction
Setup
Story
After gaining some experience with Cisco Firepower, our company decided to test a firewall product from a different vendor: Fortinet, called FortiGate. It will be used firstly to create simple configs (like the ones did on lab3): create the qemu image path, the node on eve-ng, and deploy the machine, configure the interfaces and policy rules between interfaces.
Lab infra
The FortiOS version of our FortiGate machine (FGT) is 7.2.3 (the latest KVM release as of Nov 2022). You can find qcow2 image located in your home directory, called virtioa.qcow2 (this is based on this qemu images naming conventions).
t0. ssh to the eve-ng machine (use user root and -X flag) - for Windows use PuTTY or MobaXterm:
user: root
password: student
user@host:~# ssh -l root -X 10.3.0.A (where A is your 4th byte in the assigned IPv4 address)
t1. create the directory of the FGT image, using the format fortinet-FGT-vX-buildABCD (where X is the max version, in our case 7 and ABCD is the fortios build, in our case 1262):
root@SRED:~# cdq root@SRED:/opt/unetlab/addons/qemu# mkdir fortinet-FGT-v7-build1262
t2. move the qcow2 image (found in your home dir) to this path
root@SRED:~# mv virtioa.qcow2 /opt/unetlab/addons/qemu/fortinet-FGT-v7-build1262
t3. solve the permissions:
root@SRED:~# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
t4. go to eve-ng WebUI from your browser (http://10.3.0.A) and create a new lab by closing the old one (left > expand > close lab), create a new one (add new lab + add name lab5) and open it.
Create a new node for the FGT:
Right click > Add new object Node > Search for 'Fortinet FortiGate' (if you cannot find it, you need to go back to steps t1,t2, and t3) > select the required image name (it is based on the folder name):
See the configuration (based on these hardware requirements):
- ram 2 GB
- 1 vCPUs (for more than 1 vCPU, the existing license will not be accepted, so stick to only 1)
- 4 ethernet interfaces
- console vnc
Q: why do we need 4 ethernet interfaces?
On FGT machines, interfaces are named portX, where X is a digit from 1+ (in our case port1→port4):
- the first interface, called port1 (you can name it outside - see below how), is the management one and also used for Internet access (remember outside interface - G0/0 on FTD). It has by default a static route to 0.0.0.0/0 via def gw of ESX vswitch:
FGT81 # get router info routing-table details
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [5/0] via 10.3.255.254, port1
C 10.3.0.0/16 is directly connected, port1
- the next interfaces are used as traffic ports. In this lab we are going to use only the first 2 for internal clients (inside1 and inside2) and the third one will be kept for the next ones (maybe for an attacker).
t5. As the traffic is forwarded to Internet via the mgmt interface (port1), we are going to need only 1 Network cloud node. Create a new network (Right click > Network) and select type Management(Cloud0). Attach a wire from this Cloud to FGT (select the first interface - port1). Using this, it will take an ip address from the ESX vswitch (via dhcp).
t6. Save forti node and create 2 new ones for Linux devices:
- 1 node with Linux image linux-ubuntu-18.04-client1_machine (keep default config - 1 eth intf also) with name client1. Connect it to interface port2 on FGT
- 1 node with Linux image linux-ubuntu-18.04-client2_machine (keep also default config - 1 eth intf also) with name client2. Connect it to interface port3 on FGT
To create links node - node, simply hover over the node until you see the plug logo and drag it to the correspondent node/network. Create the topology as seen below:
t7. Start all nodes (go to left > expand > More Actions > Start all nodes). Access firstly the FGT machine from vnc/rdp and wait for it to boot (this will take 1,2 minutes).
t8. enter default credentials: user: admin; password: null (which means press enter)
You will need to change the default password after the first login (use password: student).
Go to cli of forti:
# config sys int # edit port1 # set macaddr <MAC address> - use here the format: 50:00:00:byte_2_eveng_ip:byte3_eveng_ip:byte4_eveng_ip # end # exec router restart
t9. from cli, find the interface ip address:
FGT81 # show system interface ? # you will see here all ports configuration here, including port1, which needs to be in subnet 10.3.0.0/16. # And based on different MAC addresses assigned, your ip must be unique
t10. for port1, there are by default multiple administrative services are activated (like ping, http, snmp etc.)
Access from your browser the WEBUI of FGT: http://PORT1_IP (identified at t9). It should be available instantly.
t11. Do the WebUI setup:
- download the license from Moodle and upload it. After this, the machine will restart, then check again the ip from cli (it should be the same)
Login again:
- for the hostname, you can use the following format: FGTlast_byte_eve_ng_address (for example: for ip 10.3.0.10 is FGT10)
- select for dashbord Optimal (the newest dashboard available). The second option can be used by users that were used to the old version of WebUI (this can interchanged anytime from the menu).
From cli, check the network connection:
FGT81 # execute ping google.com PING google.com (142.250.74.206): 56 data bytes 64 bytes from 142.250.74.206: icmp_seq=0 ttl=116 time=29.5 ms 64 bytes from 142.250.74.206: icmp_seq=1 ttl=116 time=29.3 ms ^C
t12. Configure the rest of 2 interfaces (port2 and port3):
- for port2 use network 172.16.0.0/24 with .1 ip for forti. Name it inside1 (alias)
- for port3 use network 192.168.0.0/24 with .1 ip for forti. Name it inside2
For each interface, configure also DHCP servers with range .2 - .254, with default gw the same interface, DNS server the same and activate ping for admin access.
t13. Go to Linux clients via vnc/rdp, authenticate using credentials eve/eve and obtain the ip address for eth0:
user@host:~# sudo dhclient eth0
Check the ping to def gw.
t14. As expected, clients cannot access anything from Internet, due to default firewall policy: Implicit Deny (which is like 'deny any any' from ACLs). You can enable logging for this rule and try to ping google.com from client1. You will see on log & report > forward traffic, that this will drop anything (with Deny: policy violation).
We need to create for each interface, a rule for letting any traffic outside (from Policy & Objects > Firewall Policy):
- inside1 ↔ outside (any source and any destination, any service) with action ACCEPT
- inside2 ↔ outside (any source and any destination, any service) with action ACCEPT
Try again to access from browser from each client, an Internet resource.
Exercises
e1. [8p] Full setup
Go through all steps t1→ t14 from tutorial and make sure both clients have internet access.
e2. [1p] Filter ping
Filter for client1 the ping to any destination. The rest of traffic (dns, http, smtp) should not be affected.
e3. [1p] Filter web
We want for client2 to filter access to facebook.com. Configure a web filter object with static URL filter and create a new security rule for filtering traffic to that website.
Check other pages from facebook, like reg or login. Traffic should be blocked and a stock 'page blocked' should be served.
Case study web filtering
Discussion regarding website blocking (remember also e1 from lab5):
1. If you configure on Web Filter the URL www.facebook.com (exact match or regex), all traffic to www.facebook.com will be blocked, but traffic to facebook.com won't as no exact match is seen.
Example:
user@host:~/# curl -I www.facebook.com HTTP/1.1 403 Forbidden
The client will send get req:
GET / HTTP/1.1 Host: www.facebook.com [...]
which will match the one configured on web filter.
Let's try now to send a req to facebook.com:
eve@ubuntu:~/# curl -I facebook.com HTTP/1.1 301 Moved Permanently [...]
See that now we are receiving a 301 code with the https link (http-https redirection) - which means web filtering is no longer done.
This is the main reason why you should configure url for web filter with subdomain.subdomain.domain.tld, without www.
2. See that for http traffic we are receiving a 'Replacement Message' with a html page from the firewall.
But, when the traffic is via https explicitly sent by client, this page cannot be seen anymore:
eve@ubuntu:~/# curl -I https://facebook.com curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to facebook.com:443
The reason for this is that traffic is dropped on tls handshake, on Client Hello message (based on extension server_name):
See here diagram for filtering:
