Show page

Differences

This shows you the differences between two versions of the page.

--- sred:lab5 [2020/11/27 12:37]
horia.stoenescu [Setup]
+++ sred:lab5 [2022/11/18 15:15] (current)
horia.stoenescu Updated fgt node
@@ Line 1: / Line 1: @@
-======= Lab 5. Fortigate introduction =======
+======= Lab 6. Fortigate introduction =======
 ===== Setup =====
 === Story ===
-After gaining some experience with Cisco FTD, our company decided to 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, create the node and deploy the machine, configure the interfaces and policy rules between interfaces.
+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 6.4.2. You can find qcow2 image located in your $HOME directory, called virtioa.qcow2 (this is based on [[https://www.eve-ng.net/index.php/documentation/qemu-image-namings/|this]] qemu images naming conventions).
+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 [[https://www.eve-ng.net/index.php/documentation/qemu-image-namings/|this]] qemu images naming conventions).
-t0. ssh to the eve-ng machine (use user root and -X flag) - for win use putty or mobaxterm:
+t0. ssh to the eve-ng machine (use user root and -X flag) - for Windows use PuTTY or MobaXterm:
 user: root
@@ Line 16: / Line 16: @@
 <code>
-user@host:~# ssh -l root -X 10.3.0.A (where A is your 4th byte in ipv4 address)
+user@host:~# ssh -l root -X 10.3.0.A (where A is your 4th byte in the assigned IPv4 address)
 </code>
-t1. create the directory of the FGT image, using the format **fortinet-FGT-vX-buildABCD** (where X is the max version, in our case 6 and ABCD is the fortios build, in our case 1723):
+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):
 <code>
 root@SRED:~# cdq
-root@SRED:/opt/unetlab/addons/qemu# mkdir fortinet-FGT-v6-build1723
+root@SRED:/opt/unetlab/addons/qemu# mkdir fortinet-FGT-v7-build1262
 </code>
 t2. move the qcow2 image (found in your home dir) to this path
 <code>
-root@SRED:~# mv virtioa.qcow2 /opt/unetlab/addons/qemu/fortinet-FGT-v6-build1723
+root@SRED:~# mv virtioa.qcow2 /opt/unetlab/addons/qemu/fortinet-FGT-v7-build1262
 </code>
@@ Line 35: / Line 35: @@
 </code>
-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.
+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, go back to steps t1,t2 and t3) > select the required image name (it is based on the folder name):
+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):
+{{:sred:fgt_setup_2022.png?450|}}
 See the configuration (based on [[https://help.fortinet.com/fmgr/vm-install/60/Content/Document/200_Licenses/400_Minimum%20HW%20Required.htm|these]] hardware requirements):
-- ram 4 GB
+- ram 2 GB
-- 2 vCPUs
+- 1 vCPUs (for more than 1 vCPU, the existing license will not be accepted, so stick to only 1)
 - 4 ethernet interfaces
-Q: why do we need 4 ethernet interfaces?
+- console vnc
-On FGT machines, interfaces are named portX, where X is a digit from 1+ (in our case port1->4):
+**Q**: why do we need 4 ethernet interfaces?
-- 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 on FTD). It has by default a static route to 0.0.0.0/0 via def gw of ESX vswitch:
+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:
 <code>
 FGT81 # get router info routing-table details
@@ Line 70: / Line 72: @@
 </code>
-- 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).
+- 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).
 <note important>
-Regarding the MAC address issue found on FTD labs: if you deploy multiple FTGs in the same network with management interfaces connected there (plus the ip configured via dhcp), the interfaces will have different MAC addresses, so no conflicts will be seen (the same mgmt ip taken by all firewall instances).
+Regarding the license, we will use the same for all forti instances (you can find it on Moodle course [[https://curs.upb.ro/2022/mod/folder/view.php?id=87287|page]]). We want to have for this lab network access, so the license will be invalidated after less than 5 minutes. Don't worry, our required features are still available and starting with the next lab, the default route will be blackholed.
+</note>
+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:
+{{:sred:lab5_topology.png?500|}}
+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**).
+<note important>
+Regarding the MAC addresses: you MUST change the default one to a custom one for port1 as each machine must have an unique private ip:
+Go to cli of forti:
+<code>
+# 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
+</code>
 </note>
+t9. from cli, find the interface ip address:
+<code>
+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
+</code>
+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:
+<code>
+FGT81 # execute ping google.com
+PING google.com (142.250.74.206): 56 data bytes
+bytes from 142.250.74.206: icmp_seq=0 ttl=116 time=29.5 ms
+bytes from 142.250.74.206: icmp_seq=1 ttl=116 time=29.3 ms
+^C
+</code>
+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.
+<note important>
+After doing any config, you are not required to deploy/commit anything. Only configure and check.
+</note>
+t13. Go to Linux clients via vnc/rdp, authenticate using credentials eve/eve and obtain the ip address for eth0:
+<code>
+user@host:~# sudo dhclient eth0
+</code>
+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 [[https://ocw.cs.pub.ro/courses/sred/labextraftd#e1_2p_traffic_analysis|e1]] from lab5):
+. 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:
+<code>
+user@host:~/# curl -I www.facebook.com
+HTTP/1.1 403 Forbidden
+</code>
+The client will send get req:
+<code>
+GET / HTTP/1.1
+Host: www.facebook.com
+[...]
+</code>
+which will match the one configured on web filter.
+Let's try now to send a req to facebook.com:
+<code>
+eve@ubuntu:~/# curl -I facebook.com
+HTTP/1.1 301 Moved Permanently
+[...]
+</code>
+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.
+. 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:
+<code>
+eve@ubuntu:~/# curl -I https://facebook.com
+curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to facebook.com:443
+</code>
+The reason for this is that traffic is dropped on tls handshake, on Client Hello message (based on extension server_name):
+{{:sred:https_facebook_drop.png?500|}}
+See here diagram for filtering:
+{{:sred:web_filter_filtering.png?500|}}