Differences
This shows you the differences between two versions of the page.
|
sred:laborator_3._dedicated_firewall_security [2020/11/13 16:35] horia.stoenescu [Setup] |
sred:laborator_3._dedicated_firewall_security [2022/11/04 14:40] (current) horia.stoenescu Moved syslog exercise to lab5 and changed grading |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ========== Lab 4. Dedicated firewall security (part 2) - FTD ========== | ========== Lab 4. Dedicated firewall security (part 2) - FTD ========== | ||
| - | ==== Setup ==== | + | ==== Setup ==== |
| === Story === | === Story === | ||
| - | 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: | + | 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** | - traffic filtering based on **URL categories** | ||
| Line 12: | Line 12: | ||
| - **IDS/IPS** for network traffic investigation of possible attacks | - **IDS/IPS** for network traffic investigation of possible attacks | ||
| - | - **SSL decryption** for in-depth analysis | + | - **SSL decryption** for traffic in-depth analysis |
| - logging to **syslog** server to generate alerts | - logging to **syslog** server to generate alerts | ||
| Line 18: | Line 18: | ||
| Other features include: | 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 (**HA**) used to provide redundancy or load balancing - will be studied in detail and implemented on Fortigate machines [[https://ocw.cs.pub.ro/courses/sred/lab5|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) |
| - | - 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) | + | - **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 [[https://ocw.cs.pub.ro/courses/sred/lab9|here]] |
| === Topology === | === Topology === | ||
| 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). | 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). | ||
| - | {{:sred:lab4_topology.png?800|}} | + | {{:sred:lab4_topology.png?750| }} |
| ==== Exercises ==== | ==== Exercises ==== | ||
| Line 33: | Line 33: | ||
| </note> | </note> | ||
| - | === e1. [1p] New guy in network === | + | === e1. [2p] New guy in network === |
| 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. | 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. | ||
| Line 44: | Line 44: | ||
| - connect it to to G0/2 found on FTD and start both nodes | - 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 and create a new dhcp server to apply to it | + | - 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 and also the corresponding nat and access policy rules | + | - 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. | Test if client2 has Internet access. | ||
| Line 65: | Line 65: | ||
| - test access to other websites like google.com, digi24.ro etc. | - test access to other websites like google.com, digi24.ro etc. | ||
| - | === e3. [1p] File policy === | + | === e3. [2p] File policy === |
| 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. | 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: | There are 2 options for this feature: | ||
| - | 1. **Block malware all**: 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). | + | 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). | 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). | ||
| Line 100: | Line 100: | ||
| Regarding rules, some of them can be removed on different versions of FTD. For example, in Snort currently there are multiple nmap rules deleted, like this [[https://www.snort.org/rule_docs/1-469|one]]. You can try to search for them on Intrusion policy with no results. | Regarding rules, some of them can be removed on different versions of FTD. For example, in Snort currently there are multiple nmap rules deleted, like this [[https://www.snort.org/rule_docs/1-469|one]]. You can try to search for them on Intrusion policy with no results. | ||
| </note> | </note> | ||
| + | |||
| + | 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. | Firstly, we will use a reverse tcp attack from attacker machine. | ||
| Line 112: | Line 114: | ||
| </code> | </code> | ||
| - | Create a new access policy rule: from inside and inside2 to inside2, action Allow, and inside with Intrusion policy enabled and maximum detection. Deploy and go to Kali machine (client2). | + | 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. |
| <note warning> | <note warning> | ||
| - | Do not use it on Inside-outside rule as some valid traffic I've seen it identified (like nslookup responses from 8.8.8.8 are blocked). I will investigate this false positives and come with a response. | + | Do not use it on Inside-outside rule as some valid traffic I've seen it identified (like nslookup responses from 8.8.8.8 are blocked). I will investigate this false positives and come with a response in future. |
| </note> | </note> | ||
| Line 154: | Line 156: | ||
| === e5. [1p] Staying in the middle === | === e5. [1p] Staying in the middle === | ||
| + | <note important> | ||
| + | Before moving to this exercise, make sure you disable Intrusion policy from the rule created earlier. Reason: deployment takes a lotes with maximum policy in place. | ||
| + | </note> | ||
| + | |||
| We can inspect also encrypted traffic using FTD in two ways: | We can inspect also encrypted traffic using FTD in two ways: | ||
| Line 162: | Line 168: | ||
| 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. | 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. | + | <note> |
| + | If you have RDP enabled for client1 Linux machine, just copy and paste the cert to a new file on home dir ca_ftd.pem. | ||
| + | |||
| + | If not, use this [[https://privnote.com/|site]] to add the CA cert as it is in pem format, then open it from client1 and save it to home dir as ca_ftd.pem. | ||
| + | </note> | ||
| + | |||
| + | 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). | ||
| <note important> | <note important> | ||
| Line 184: | Line 196: | ||
| 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). | 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). | ||
| - | </note> | ||
| - | |||
| - | === e7. [2p] Send some logs === | ||
| - | |||
| - | {{:sred:lab4_syslog.png?800|}} | ||
| - | |||
| - | 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: | ||
| - | <code> | ||
| - | 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 | ||
| - | </code> | ||
| - | |||
| - | After this, go to another terminal on Router VM and test the syslog server: | ||
| - | <code> | ||
| - | logger -n 10.3.0.84 -P 1025 "testing my new syslog server" | ||
| - | </code> | ||
| - | |||
| - | And from another terminal, check the logs.txt file: | ||
| - | <code> | ||
| - | tail -f /var/log/syslog-ng/logs.txt | ||
| - | Nov 10 10:00:00 ubuntu eve: testing my new syslog server | ||
| - | </code> | ||
| - | |||
| - | Do the same thing from FTD expert mode and check with tail logs.txt: | ||
| - | <code> | ||
| - | > expert | ||
| - | admin@ciscoasa:~$ logger -n 10.3.0.84 -P 1025 "testing syslog from ftd" | ||
| - | </code> | ||
| - | |||
| - | 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: | ||
| - | |||
| - | - in: inside and inside2 | ||
| - | - out: outside | ||
| - | - application: ICMP | ||
| - | - action: ALLOW | ||
| - | - logging: at the end of connection and send connection events to syslog server (configured at step 1). Note that all these events are informational and can also be seen locally on FTD : Monitoring > Events | ||
| - | |||
| - | <note> | ||
| - | For more info about syslog-ng, see [[https://www.techrepublic.com/article/how-to-use-syslog-ng-to-collect-logs-from-remote-linux-machines/|here]]. | ||
| </note> | </note> | ||
