Lab 12 | Implementing a Firewall
Lab 12 | Implementing a Firewall
After considerable trouble, I was able to get my lab setup capable of connecting to the pfsense gui, I was aided by classmates as well as the tutor reconfiguring the routers for us.
After considerable trouble, I was able to get my lab setup capable of connecting to the pfsense gui, I was aided by classmates as well as the tutor reconfiguring the routers for us.
From this, I learnt that I need to check the adapter settings within both the router and vmware to ensure that I have my connections plugged into the right ports, I originally overlooked this by making an assumption that the ports in vmware were in the same order as the ports in the router itself.
Following the execution of the mtr tool we reviewed some of the available status statistics that pfsense offers us, this included:
- showing CPU load by processes
- traffic graph
- interface statistics, blocked and allowed packet
The logs are only stored in memory in the firewall but can be configured to also store to a file.
Lab Questions
Ex 3 | 15
Re-run the Nmap scan - is it able to gather any more information without the block?
Shown below are the details I got from scanning without the block, we can see the metasploitable as well as following details that were provided. This shows that if the website port is open to the wide area network then it can be scanned for information that reveals more than the layman may think is possible.
Ex 4 | 4
Switch to the pfSense WebConfigurator on WIN10-WS. Has Securicata logged any activity?
Shown below we can see the activity that has been logged whilst we try to connect to 172.16.0.254 from 192.168.2.192, this also logs the ports we attempted to use, the protocol of our request and also a description pertaining to more detailed information if possible, in this instance the error code was unknown but we can further tell that the request was made using ICMPv4.
Ex 4 | 12
Switch to the pfSense WebConfigurator on WIN10-WS (it should start responding again shortly after stopping the attack). Has Securicata logged any activity? What is listed under Diagnostics > States Summary?
Shown below is states page after I reloaded the webpage following the DoS attack, in the scroll bar on the right-hand side of the page we can see that there is a significant amount of entries into the states table, this was done during the action of flooding the firewalls states until the state's limit was reached, this stopped further traffic from passing through the firewall whilst the attack was still in operation. This allows us to take down the firewall with relative ease, some sort of precaution likely needs to be implemented in order to prevent this type of attack, I am aware that third-party providers offer DDoS attack prevention services although I am not sure what a lone network could do about such an attack, I can imagine there may be software that exists that is capable of recognizing the patterns these types of attacks produce and then stopping it in its tracks before it takes down the attack target, rendering it incapable of functioning whilst the attack is in effect.
Re-run the Nmap scan - is it able to gather any more information without the block?
Shown below are the details I got from scanning without the block, we can see the metasploitable as well as following details that were provided. This shows that if the website port is open to the wide area network then it can be scanned for information that reveals more than the layman may think is possible.
Ex 4 | 4
Switch to the pfSense WebConfigurator on WIN10-WS. Has Securicata logged any activity?
Shown below we can see the activity that has been logged whilst we try to connect to 172.16.0.254 from 192.168.2.192, this also logs the ports we attempted to use, the protocol of our request and also a description pertaining to more detailed information if possible, in this instance the error code was unknown but we can further tell that the request was made using ICMPv4.
Ex 4 | 12
Switch to the pfSense WebConfigurator on WIN10-WS (it should start responding again shortly after stopping the attack). Has Securicata logged any activity? What is listed under Diagnostics > States Summary?
Shown below is states page after I reloaded the webpage following the DoS attack, in the scroll bar on the right-hand side of the page we can see that there is a significant amount of entries into the states table, this was done during the action of flooding the firewalls states until the state's limit was reached, this stopped further traffic from passing through the firewall whilst the attack was still in operation. This allows us to take down the firewall with relative ease, some sort of precaution likely needs to be implemented in order to prevent this type of attack, I am aware that third-party providers offer DDoS attack prevention services although I am not sure what a lone network could do about such an attack, I can imagine there may be software that exists that is capable of recognizing the patterns these types of attacks produce and then stopping it in its tracks before it takes down the attack target, rendering it incapable of functioning whilst the attack is in effect.
Critical Thinking & Analysis
This lab has increased my knowledge pertaining to firewalls and certain targetted attacks can impact them, during the lab we learnt about the 'block and reject' types of firewall request denial. It is apparent to me that block would be ideal, this appears to give off no indication that the probing packet has found the right IP address whereas reject would signal to the probing user that the packet had been rejected, from here they can decide to execute other malicious software upon the ip address. This lab also highlighted exploitable holes in the firewall system if the user can find an open port that allows them to send packets to the firewall, this was shown in the form of a DoS attack and also an attack that flooded the state's limit of the firewall, the DoS attack aims to overwhelm the firewall in a more 'brute force' sense with consistent packets with the goal of rendering the firewall incapable of handling regular requests due to being overcome by the consistent packet stream distributed by the DoS attack.
The state limit attack, however, exploited the state limit existing within the firewall, once the limit was reached then it was impossible to execute any new functions with the firewall due to the attack taking up all the states. This was more effective than the DoS attack due to it not requiring significant computing power to overwhelm the firewall.
Comments
Post a Comment