Differences
This shows you the differences between two versions of the page.
|
sred:lab3 [2020/11/06 16:53] horia.stoenescu [Setup] |
sred:lab3 [2022/10/28 14:21] (current) horia.stoenescu [Setup] |
||
|---|---|---|---|
| Line 6: | Line 6: | ||
| After a period of time, our company managed to have some income and decided to invest it in security equipment, a license for a Cisco Firepower Threat Defense (known as FTD). In the first day, as expected, there is need to setup the virtual machine and create a simple topology with the server connected in **Outside** zone and client area in **Inside** one. | After a period of time, our company managed to have some income and decided to invest it in security equipment, a license for a Cisco Firepower Threat Defense (known as FTD). In the first day, as expected, there is need to setup the virtual machine and create a simple topology with the server connected in **Outside** zone and client area in **Inside** one. | ||
| - | === Lab infra === | + | <note tip> |
| - | This new security equipment called **ftd** is a Cisco Firepower version 6.6.1-91. You can find it on your local machine in $HOME directory. Your task is to add to qemu directory , use a specific naming format for Firepower and image and solve the permission problems (this is based of this [[https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-firepower-6-x-images-set/|tutorial]]): | + | [[https://curs.upb.ro/2022/pluginfile.php/364637/mod_resource/content/2/lab3_ftd.pdf|Here]] you can find the presentation for lab3. There is made the transition from CBAC/ZBF to a firewall solution (consisting in basic scenarios like permitting traffic from inside to outside, filtering urls, and applications). |
| + | </note> | ||
| + | |||
| + | === Local host prerequisites === | ||
| + | If you have a Windows/MacOS machine, you need to install on it [[https://www.realvnc.com/en/connect/download/viewer/windows/|vnc viewer]] to access the Linux/Firewall machines and [[https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html|putty]] for Cisco routers/switches. | ||
| + | You can also check this client side pack from Eve-ng for [[https://www.eve-ng.net/index.php/download/#DL-WIN|Windows]] and [[https://www.eve-ng.net/index.php/download/#DL-OSX|MacOS]]. | ||
| + | |||
| + | For Linux OS, you can use Remmina or Remote Desktop Viewer (both should be already installed). Check this link also: [[https://remmina.org/how-to-install-remmina/|Remmina install]]. | ||
| + | |||
| + | === Lab infra - deploy full topology === | ||
| + | This new security equipment called **ftd** is a Cisco Firepower Thread Defense version 6.6.1-91. You can find it on your local machine in **$HOME/images/ftd** directory. Your task is to add to qemu directory , use a specific naming format for Firepower and image, solve the permission problems (this is based of this [[https://www.eve-ng.net/index.php/documentation/howtos/howto-add-cisco-firepower-6-x-images-set/|tutorial]]), deploy and configure the machine: | ||
| <note important> | <note important> | ||
| Line 13: | Line 23: | ||
| </note> | </note> | ||
| - | 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 win use putty or mobaxterm: |
| + | |||
| + | user: root | ||
| + | |||
| + | password: student | ||
| <code> | <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 ipv4 address) | ||
| Line 22: | Line 37: | ||
| root@SRED:~# cdq | root@SRED:~# cdq | ||
| # note: cdq is an alias for 'cd /opt/unetlab/addons/qemu' | # note: cdq is an alias for 'cd /opt/unetlab/addons/qemu' | ||
| - | root@SRED:~# mkdir firepower6-FTD-6.6.1-91 | + | root@SRED:/opt/unetlab/addons/qemu# mkdir firepower6-FTD-6.6.1-91 |
| </code> | </code> | ||
| Format: //firepowerMAX_VERSION-FTD-MAX_VERSION.MIN_VERSION.BUILD-REVISION// (in our case MAX_VERSION=6, MIN_VERSION=6, BUILD=1, REVISION=91) | Format: //firepowerMAX_VERSION-FTD-MAX_VERSION.MIN_VERSION.BUILD-REVISION// (in our case MAX_VERSION=6, MIN_VERSION=6, BUILD=1, REVISION=91) | ||
| - | t2. move the qcow2 image (found in your home dir) to this path | + | t2. move the qcow2 image (found in $HOME/images/ftd) to this path |
| <code> | <code> | ||
| - | root@SRED:~# mv hda.qcow2 /opt/unetlab/addons/qemu/firepower6-FTD-6.6.1-91 | + | root@SRED:~# mv ~/images/ftd/hda.qcow2 /opt/unetlab/addons/qemu/firepower6-FTD-6.6.1-91 |
| </code> | </code> | ||
| Line 59: | Line 74: | ||
| Select the first option, then wait for the kernel to boot. Close the machine after booting completed (you can send a simple SIGINT signal to the process). | Select the first option, then wait for the kernel to boot. Close the machine after booting completed (you can send a simple SIGINT signal to the process). | ||
| - | t5. 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) and open it. | + | t5. 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) - make sure all nodes are turned off, create a new one (add new lab > give a suggestive name) and open it. |
| Create a new node for the FTD: | Create a new node for the FTD: | ||
| - | Right click > Add new object Node > Search for Firepower version 6 (if you cannot find it, go back to steps 1,2 and 3) > select the required image name (it is based on the folder name): | + | Right click > Add new object Node > Search for Firepower version 6 (if you cannot find it, go back to steps 1,2, and 3) > select the required image name (it is based on the folder name): |
| - | {{:sred:ftd_config.png?500|}} | + | {{:sred:ftd_node_2021.png?500|}} |
| See the configuration: | See the configuration: | ||
| - | - ram 8GB (at least 8 are required) | + | - add a new mac address (for dhcp request with a new mac address) for first eth interface. you can use the format: **00:50:00:byte_2_eveng_ip:byte3_eveng_ip:byte4_eveng_ip** (example: for 10.3.0.76, use 00:50:00:03:00:76).In the image from above, the configured mac address is 00:50:00:03:00:02, which corresponds to eve-ng machine with ip 10.3.0.2. |
| + | |||
| + | - ram 8GB (at least 8 are required for FTD) | ||
| - cpu 8 | - cpu 8 | ||
| - | - Ethernet interfaces 4. | + | - Ethernet interfaces 4. |
| + | |||
| + | <note warning> | ||
| + | Do not forget to add the mac address with the format from above! Else, you may get the same ip address as the other colleagues which will create conflicts. | ||
| + | </note> | ||
| **Q**: Why do we need 4 netw interfaces on FTD? | **Q**: Why do we need 4 netw interfaces on FTD? | ||
| Line 81: | Line 102: | ||
| {{:sred:ftd_interfaces2.png?800|}} | {{:sred:ftd_interfaces2.png?800|}} | ||
| - | The first interface is used for managing the FTD remotely or locally if we are in lab network from upb. Is it strictly used for accessing the webui of equipment (most of the times) and no other traffic like forwarding packets from clients to other networks or creating ipsec tunnels with cloud instances or clients connected via vpn client (I will give you here some examples). This part will be used by the next interfaces, which are known as **traffic** ones. | + | The first interface is used for managing the FTD remotely or locally (if we are in lab network from UPB). Is it strictly used for accessing the WebUI of the equipment (most of the times) and no other traffic like forwarding packets from clients to other networks, creating ipsec tunnels with cloud instances or clients connected via vpn client (I will give you here some examples on the next lab). These scenarios can be performed on the next interfaces, which are known as **traffic** ones. |
| The next one is a console one which is not available in eve-ng (device can be managed anyway like a console attached to it using vnc or rdp). | The next one is a console one which is not available in eve-ng (device can be managed anyway like a console attached to it using vnc or rdp). | ||
| Line 87: | Line 108: | ||
| The following 3 ones are Gigabit interfaces which represent: | The following 3 ones are Gigabit interfaces which represent: | ||
| - | - outside area: used by default by firewall for internet access (you will this at easy setup for ntp and license activation). This needs to remain only for outside area. The next ones can be changed as we want internally. | + | - outside area: used by default by firewall for Internet access (you will see this at easy setup for ntp and license activation). This needs to remain only for outside area. The next ones can be changed how do we want internally. |
| - | - inside area: used by internal clients to connect to firewall. There exists by default a NAT rule to translate internal ips dynamically to external one and an access policy rule for allowing any traffic from inside to outside. | + | - inside area: used by internal clients to connect to firewall. There exists by default a NAT rule to translate internal ips dynamically to external one and an access policy rule for allowing any traffic from inside to outside. |
| - the third one can be used for other networks (like DMZ or visitors - see lab 2). Currently, we are keeping it disabled for the third lab. | - the third one can be used for other networks (like DMZ or visitors - see lab 2). Currently, we are keeping it disabled for the third lab. | ||
| - | As a conclusion here, FTD forwards and filters traffic generated from inside to outside area based on security policies. An important note here is that returning traffic is also allowed, as it comes from internal zone (see there is no need for an access policy in mirror). Note that this means we cannot by default to access from the Router Linux VM the client machine. | + | As a conclusion here, FTD forwards and filters traffic generated from inside to outside area based on security policies. An important note here is that returning traffic is also allowed, as the request comes from internal zone (see there is no need for an access policy in mirror - remember the example with the RACLs). This means also that we do not have access from Router Linux VM to the client machine when incoming packets are coming from outside zone. |
| <note> | <note> | ||
| Line 99: | Line 120: | ||
| </note> | </note> | ||
| - | t6. we will need to access the machine remotely. The first solution that comes to mind is to add in the same subnet as the eve-ng machine (with Internet access). To do this, simply create a new network (Right click > Network) and select type management/Cloud0. Then attack a wire from this Cloud to FTD (select the first interface - mgmt for FTD). Using this, it will take an ip address from the ESX vswitch. | + | t6. we will need to access the machine remotely. The first solution that comes to mind is to add in the same subnet as the eve-ng machine (with Internet access). To do this, simply create a new network (Right click > Network) and select type management/Cloud0. Then attach a wire from this Cloud to FTD (select the first interface - mgmt for FTD). Using this, it will take an ip address from the ESX vswitch (via dhcp). |
| <note> | <note> | ||
| - | Eve-ng uses internally bridges for links between the devices or between devices and other esx interfaces. For example, when you create a network link between FTD and a Linux device (or 2 nodes), there is generated a bridge **vnetX_Y** (X for device id and Y for interface id) which contains interfaces created for each node (vunl format) - example: | + | Eve-ng uses internally bridges for links between the nodes/devices or between devices and other esx interfaces. For example, when you create a network link between FTD and a Linux device (or 2 nodes), there is generated a bridge **vnetX_Y** (X for device id and Y for interface id) which contains interfaces created for each node (vunl format) - example: |
| <code> | <code> | ||
| root@SRED:~# brctl show | root@SRED:~# brctl show | ||
| Line 117: | Line 138: | ||
| </code> | </code> | ||
| - | Above see that there is a bridge between eth0 and 2 cloud interfaces (used by 2 devices for internet access). Any device connected to that cloud node will get its ip using dhcp (more information about this will be added on setup lab [[https://ocw.cs.pub.ro/courses/sred/setup_lab_remote|page]]). | + | Above see that there is a bridge between eth0 and 2 cloud interfaces (used by 2 nodes/devices for internet access). Any device connected to that cloud node will get its ip using dhcp (more information about this will be added on setup lab [[https://ocw.cs.pub.ro/courses/sred/setup_lab_remote|page]]). |
| </note> | </note> | ||
| - | t7. save node config and create another 2 nodes and new 2 networks: | + | t7. save node config and create another 2 nodes and new 1 network: |
| - | - 1 node with Linux image linux-ubuntu-18.04-server_machine (keep the rest of default config) and 1 node with Linux image linux-ubuntu-18.04-client1_machine (keep also the rest of default config) | + | - 1 node with Linux image linux-ubuntu-18.04-server_machine (add 2 eth interfaces and keep the rest of default config). Add also a mac address for first eth interface with format **00:50:00:byte_2_eveng_ip:byte3_eveng_ip+1:byte4_eveng_ip** (example: for 10.3.0.76 use 00:50:00:03:01:76). |
| - | - 2 networks, both with type Management/Cloud0 (attached to eth0). Each device connected to it will get its own ip from range 10.3.0.0/16 using dhcp. | + | - 1 node with Linux image linux-ubuntu-18.04-client1_machine (keep also the rest of default config - 1 eth interface also) |
| + | |||
| + | - 1 networks, with type Management/Cloud0 (attached to eth0). Linux machine connected to it will get its own ip from range 10.3.0.0/16 using dhcp. | ||
| + | |||
| + | <note warning> | ||
| + | Same case here for mac address! | ||
| + | </note> | ||
| To create links node - node and node-network, 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 (client - FTD using G0/1 and linux_router - FTD using G0/0): | To create links node - node and node-network, 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 (client - FTD using G0/1 and linux_router - FTD using G0/0): | ||
| Line 147: | Line 174: | ||
| {{:sred:ftd_new_passwd.png?800}} | {{:sred:ftd_new_passwd.png?800}} | ||
| - | t12. configure the mgmt network interface using dhcp protocol and check in the end the ip address: | + | t12. configure the mgmt network interface with ipv4 only, using dhcp protocol and check in the end the ip address assigned (this will be your management ip): |
| {{:sred:ftd_netw1.png?800}} | {{:sred:ftd_netw1.png?800}} | ||
| Line 166: | Line 193: | ||
| </note> | </note> | ||
| - | t13. Go through the easy setup part and activate 90-days trial. You may see some errors on step 1 as we did not completed Linux Router VM configuration. | + | t13. Go through the easy setup part, choose dhcp for outside area (the ip will be configured later) and activate 90-days trial. You may see some errors on step 1 as we did not completed Linux Router VM configuration. |
| t14. Leave the FDM and go to Linux Router VM. See that on interface eth0, there is assigned an ip address from range 10.3.0.0/16. If not execute the command: | t14. Leave the FDM and go to Linux Router VM. See that on interface eth0, there is assigned an ip address from range 10.3.0.0/16. If not execute the command: | ||
| Line 181: | Line 208: | ||
| <code> | <code> | ||
| eve@ubuntu:~# echo 1 > /proc/sys/net/ipv4/ip_forward # enable routing (disabled by def) | eve@ubuntu:~# echo 1 > /proc/sys/net/ipv4/ip_forward # enable routing (disabled by def) | ||
| - | eve@ubuntu:~# iptables -t nat -A POSTROUTING -d 0.0.0.0/0 -o eth0 -j MASQUERADE | + | eve@ubuntu:~# sudo iptables -t nat -A POSTROUTING -d 0.0.0.0/0 -o eth0 -j MASQUERADE |
| - | eve@ubuntu:~# iptables -t nat -L | + | eve@ubuntu:~# sudo iptables -t nat -L |
| [...] | [...] | ||
| MASQUERADE all -- anywhere anywhere | MASQUERADE all -- anywhere anywhere | ||
| </code> | </code> | ||
| - | t15. Come back to FDM and go to Device: firepower (4th up side) > Interfaces > View All interfaces > Edit GigabitEthernet0/0 and add the ip address 172.31.0.1 with subnet 255.255.255.0 (optional a description). | + | t15. Come back to FDM and go to Device: firepower (4th tab) > Interfaces > View All interfaces > Edit GigabitEthernet0/0 and add the ip address 172.31.0.1 with subnet 255.255.255.0 (optional a description). |
| The internal routing table is empty, so we need to a default static route one. Go to Device: firepower > Routing > View configuration > add (+ sign) and add: | The internal routing table is empty, so we need to a default static route one. Go to Device: firepower > Routing > View configuration > add (+ sign) and add: | ||
| Line 215: | Line 242: | ||
| </code> | </code> | ||
| - | See that also a default route was injected, but no dns server (by default dhcp server has configuration with dns servers empty): | + | See that also a default route was injected, but no DNS server (by default dhcp server has configuration with dns servers empty): |
| <code> | <code> | ||
| eve@ubuntu:~# ip r s | eve@ubuntu:~# ip r s | ||
| Line 224: | Line 251: | ||
| options edns0 | options edns0 | ||
| # add 8.8.8.8 dns ip | # add 8.8.8.8 dns ip | ||
| - | eve@ubuntu:~# echo "8.8.8.8" >> /etc/resolv.conf | + | eve@ubuntu:~# echo "nameserver 8.8.8.8" >> /etc/resolv.conf |
| </code> | </code> | ||
| t18. In the end, try to ping from client google.com or access from Mozilla browser youtube.com. | t18. In the end, try to ping from client google.com or access from Mozilla browser youtube.com. | ||
| - | |||
| - | <note warning> | ||
| - | After you finish working with FTD equipment, please go to cli mode and type: | ||
| - | <code> | ||
| - | > shutdown | ||
| - | This command will shutdown the system. Continue? | ||
| - | Please enter 'YES' or 'NO': YES | ||
| - | </code> | ||
| - | 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!). | ||
| - | </note> | ||
| ==== Exercises ==== | ==== Exercises ==== | ||
| Line 245: | Line 262: | ||
| === e2. [1p] Don't ping === | === e2. [1p] Don't ping === | ||
| - | Block all icmp traffic from inside zone to outside zone (application ICMP - default one). Deploy and test ping to google.com. | + | Block all icmp traffic from inside zone to outside zone (application ICMP - default one). This is also known as **AVC** (application) inspection. Deploy and test ping to google.com. |
| === e3. [1p] No more social media === | === e3. [1p] No more social media === | ||
| Block all URL traffic to facebook.com from inside zone (URL tab > + > create new URL > add name and URL facebook.com). Deploy and test facebook access from Mozilla. Check that twitter/other website works. | Block all URL traffic to facebook.com from inside zone (URL tab > + > create new URL > add name and URL facebook.com). Deploy and test facebook access from Mozilla. Check that twitter/other website works. | ||
| + | <note warning> | ||
| + | After you finish working with FTD equipment, please go to cli mode and type: | ||
| + | <code> | ||
| + | > shutdown | ||
| + | This command will shutdown the system. Continue? | ||
| + | Please enter 'YES' or 'NO': YES | ||
| + | </code> | ||
| + | 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!). | ||
| + | </note> | ||
