How to protect against Denial of Service DoS & DDoS attacks using Fortigate Firewall

in this video we will talk about denial of service attacks and how to use a 40 gate firewall to protect against them let's start with a quick introduction what is denial of service the knowledge service attacks are based on overwhelming server resources by sending too much request to a service that is exposed and the purpose of bringing the service down or making it extremely slow almost unusable we're going to look an example that an attacker would identify services in your environment these services could range from web servers dns servers domain controllers anything that is exposed and you probably have your firewall policy along this axis for that purpose and therefore the hacker would send a lot of requests maybe 500 requests at a time and try to overwhelm the server resources now to increase the attack surface a hacker would not just rely on just 500 connection at a time you can actually utilize things like multi-threading which is sending a lot more requests from different channels from the same computer or you can also add additional computers and try to make it a distributed denial of service because it's based on multiple computer at once and this increases the load on the server even more now denial of service attacks can cause a lot of issues for example you can get a resource exhaustion is the first symptom for example you will see cpu spikes or ram spikes or constant load on your server it will also cause things like slow load speed or the web pages are not opening at all or the service is not functioning and finally it can cause the server to completely crash or just the service demon to crash now additionally if you are deploying services in the cloud this can be very tricky because most of the cloud providers have different cpu packages for virtual machines but a lot of them would have some sort of a cbu throttling based on how much cpu you have been consuming you are only allowed specific times of cpu spikes throughout the day and with the denial service attack causing the resource exhaustion this can cause your cpu credits to run out quickly and then you're going to be throttled for the rest of your session until your credits get refilled also some people might opt in for unlimited cpu plans which are mirror mean that if the resource exhaustion is causing the cpu spikes to stay for longer you're gonna be incurring a lot of additional charges which is very terrible to make sure you are protecting yourself from the narrow service attacks which we're gonna explore in this video also it's good to know that denial of service attacks are absolutely illegal you should not be testing this on any website if you want to test it on your own service you also have to be careful because if you are testing on the cloud you have to read the cloud service provider terms of service make sure they are accepting this kind of behavior this kind of testing otherwise you should avoid doing it and for the purpose of this video we're going to emulate this denial of service attack to see how the firewall would react in the default configuration and then we're gonna see how we can use the fortigate built-in denial of service protection to protect against this kind of attack so our design will be the firewall we would have an attack surface or attack source and when we talk about attack source you have to assume the worst that mean you can't just assume that attacks come only from the internet side if you are in a big environment you are possibly have attacks that can come from inside or through your partner vbns or anywhere you are connected so not just the when we can apply this security profile on everywhere if we want to now for our attack destination we will emulate this using a web server so in this case our web server is listening on http https our default web boards and we already allowed the firewall policy to accept this traffic because this is the purpose of the web server and once we start emulating this denial of service attack to our web server we will then add the additional layer of security adjust before the traffic hits the web server by adding a denial of service policy now we are looking into the firewall interfaces i have here my dmz to emulate the web server this is given a public ib address to emulate a service that is available on the internet so i give it ib address 100.100.100.1 this is a slash 24 network and i'm gonna try to attack the service this time from my pc network this is in a different interface and over in the dmz network we are looking into this computer which is running vmware workstation we are hosting a wordpress blog to emulate a website this is just a very light website there is not much content in here but as you see the website is going to be working very smoothly because it's already empty right now there's no much load now let's switch our view to the hypervisor and this is the virtual machine that is running the wordpress and we're going to use a utility called h-top to monitor our cpu and ram usage as you see right now this virtual machine is running only one cpu core and about 666 makes of ram which is pretty low to begin with but we also got some swap which is using the desk for additional ram now i'm going to login into my attacking source which is going to be another ubuntu server that i'm running in my pc network and i'm going to log into the server and i want to initiate an attack to the server right now without any protection and i'm going to use a python script called golden eye this is a denial of service testing script and it's very powerful this script is very simple to use all we need to do is to open it with python and then define which target we're gonna attack in this case i wanna target my blog which is running in the ip address 100.100.100.100. so i'm gonna define this ip address in here in my target and after that we just need to define two parameters one parameter is the workers or the nodes that's gonna initiate that attack this is the multi threading we talked about earlier but i want to define the workers to be 600 this is very generous number but we're gonna try to boost it as much as we could and then for how many requests are gonna send from these workers is gonna be with the s flag and then i'm gonna also bought 600 once we initiate this this will initiate the attack as you see the server immediately jumped the cpu to a hundred percent the ram is also being consumed and we are starting to utilize more from the swap if you look closely on what is causing the bottleneck or what is causing the load it's mainly the php compiler here because this is the one doing the php work for the wordpress and therefore it's causing the cpu spike because of the attack now let's move on to the 40 gate let's see what the 40 gate thing is happening now as we look into the log and report we're gonna check for forward traffic and we're gonna change our filter to the destination we're gonna put our target that we are trying to attack which is 100 that 100 100 100 i'm going to remove this old filter as you see in here my ubuntu server 2 which is the attacking source is showing all these requests with very small period of time most of them are also showing sent data but no received as you see most of them are timing out the servers already cannot respond to most of them now if we expand any of these log entries you will notice that the firewall doesn't feel anything is wrong because it sees that there is a firewall policy that we intentionally added called internal dmz access number 11 and it's rated in the security level of notice so there's no alert whatsoever right now is happening but if we look into the server we know for sure the server is suffering actually if we move to the server right now try to refresh you'll see the server that has only four small bus is taken forever to load just the home page because of the excess load that is happening on a server with the denial of service attack finally loaded but this is obviously not acceptable now finally the login page opened which took about more than 15 seconds to load which is absolutely unbelievable number for such an empty page now if we also take a look at the home screen of the device you see in here in the fortigate side our cpu and ram are not much affected by this kind of attacks but we can see the spike in the sessions going up really quickly from almost in the 200 300 range up to the 2000 ranges and this is the impact of the denial of service from the firewall perspective so even though the logs show it as notice in the session table you can see the inflation of the number of session also if we look into the firewall policy you can see in here the policy that allows the access to our dmz and allows the http https because it's expected for these services but if you look closely into the stats for this policy you'll see in here that this pulse in such a small period of time had had almost 725 000 packets it was really high number for an internal server like this you can see in here the impact on the incision and the impact on the pulsey that's but you see nothing in the firewall logs that indicate the problem so now let's stop the attack momentarily and let's see how we can use the 40 gate firewall to start at least monitoring or feeling that something wrong is going on then we can start see how we can take action against this kind of attacks i'm going to switch back to the 40 gate and first let's start by enabling the denial of service protection this is something disabled by default we have to go into system feature visibility and we have to make sure that the denial of service policy is enabled once we do this the gui will refresh and we'll add another entry to our pausing object you see in here we have a new entry ibv4 denial of service policy and finally ibv6 denial of service policy let's go into ibv4 now inside the ibv4dos policy we're going to start creating our first denial of service protection layer once you are inside you have to choose which interface that you expect the attack on so this kind of policy is interface dependent if you want to apply this to multiple interfaces you have to duplicate the policy and choose the interface every time of which you know the attack will be coming and this time we're going to build one for our vc network this is where our attack surface is and for our source address we're just going to put all addresses we know the address in this network is this pc network or we can just choose all for this purpose for the destination address we can also use all or we can just define our dmz network which is 100 100 100.00 24. for the service you can also define it to the web services if you know only these services are open or you can just choose all also to cover more services like bing if bing is enabled i'm going to choose all for this purpose down here you're going to start see the layer 3 anomaly in layer 4 anomalies so you can tune based on your needs first off you can enable logging because that's what we are missing right now we are missing the knowledge that something is going on we can enable logging for layer 3 level and layer 411. all these metrics are disabled by default so you can choose between a block mode or monitor mode right now we are still testing this out so let's choose monitor first see what is happening and then decide to take action after i'm going to choose everything to monitor now there are many anomalies in here it's written in short text but you can actually hit into the 40 gate handbook and you can see in here a more detailed version on what every anomaly means for example the same flawed is if a sim packet is sent in a rate of 2000 bucket per second to one destination ip address that means there is some sort of attack happening also board scans udb flaws udb scans there are so many criterias and the numbers in here that you have by default is kind of more generous or more relaxed as you see 5 000 packets per second to define this as an enough service maybe too much i'm going to tune this number a little bit to maybe 2000 to make it more realistic and i want to remove anything that is 5000 i'm going to make it more lower and i'm going to leave anything else as is by default values then i'm going to save this policy right now i have my pc interface monitored for any anomaly behavior or any weird behavior of too much requests coming to this interface going into my dmz network 100 100 100.00 24. now i want to do the attack one more time i want to switch to my edge top my h top right now is more relaxed because there is no attack happening and i want to switch to my golden eye script again and this time i'm running it with 650 workers and 650 connection at once and i'm going to hit enter right now the server is being under the same load as we seen before we check with the additional workers and socket go back to our firewall and see what the firewall is seeing as far as session you'll see here decision inflation is starting to happen we start to move from almost 300 session back to 2000 plus session now we're gonna look into the login report again for our traffic as you see the same request is keep coming very short period of time timing out most of them but again if we look into the security level it's still notice so in here you will not see any difference but i want you to go into anomaly and under anomaly you will start seeing these denial of service anomalies being detected now severity level in here is much more different than logan report or raw traffic because here it's looking at it from the perspective it's sending too much even though the firewall policy allows it so as you see in here the same source session the same ib in the destination and it's seeing four different infractions already as seen here this is rated as critical and it sees that this ib address which is i'm running my golden eye script from in the bc network trying to hit this server on board 80 http and it's being detected at this point is not being drop it just being monitored as you see the firewall is finally able to identify there's anomaly of course it's going to come handy in here to have a good reputable login service like 4d analyzer or a syslog server like solarwinds or prtg like we explore in the other videos so that you can have some sort of email alerts for this kind of attacks and then you can react to it but also we're gonna create automation in place to do this for us if we look into the server the server is still suffering but the will know something is going on now the script is stopped and the server is back to normal now i want to switch back to my firewall and i want to go and change my action on this denial of service policy so that's no longer being detected i want to drop and i want it gone i want to go into my policy ibv4 dos and then i'm going to change all the anomalies action to block save our updated policy and now our protection is finally effective now we are looking into our server we have our session numbers in here from the fortigate site and we have our attacking source we're going to run the script to attack the server with a 650 connection each on 650 workers and we're going to see the behavior on the side of the 40 gate the numbers are increasing for the session same for the cpu is absolutely going 100 percent at this moment but as you see once the general service is able to detect this the load goes back to smaller numbers let's go back to our anomalies we've seen here we start seeing these anomalies being detected and we are doing clear session the decisions are being removed from the session table right away and the attack is not able to crash the server in this case as you see in if the script is still running the cpu would still spike back and forth until the denial of service policy is able to catch the pattern and block it now this obviously is not good enough so i want to show you how you can quarantine these ip addresses so that they don't keep trying to attack you and keep spiking the cpu back and forth so first i want to go inside config firewall denial of service policy and here we can see some cli only commands so as you see in the structure in here we have our first policy for our internal to our pc network for all addresses trying to hit our dmz on all boards we have all the layer 3 and layer 4 anomalies listed in the cli format and we're going to try to target the ones that we are affected with because these anomalies have a quarantine option so let's go back to our firewall login report and verify under the anomaly page most of the attack names are categorized under tcb source position and tcp destination session so we're going to edit the specific anomaly entries for those items and we're going to add a quarantine option to it would ib get banned for a specific period and you don't keep trying so i want to edit one this is the entry itself if i do a show one more time to verify it's the same now we're just going to go under config and normally this is like the sub menu so config anomaly and then we're just going to do an edit and search for that tcp source now once we are inside the entry let's do a show to see what is inside it just has the log and the threshold so now we're gonna do a set and then we can do a question mark as you see there is an option for quarantine i want to do a quarantine attacker this will make sure that the ib get banned now our second option that we can do in here is to log this quarantine entry of course we need logging for all these attack logs we're going to do a quarantine log enabled and the last option we want to do is set quarantine expiry this defines how long we want to ban the ip addresses from trying to attack the server again you can use in here a symbol format of number and then h or m or d so i want to do one edge for one hour and this should be sufficient enough now we're gonna do a next this will not push us to the main menu this will just bring us back to the anomaly sub menu and now we're going to edit the second entry we were seeing in tech names which is tcp destination and we can just tab until we find it then inside i can do an up arrow to bring back the commands i entered before and just repeat the same three that i enter for tcp source and add it to tcp destination now i have the quarantine for this anomaly for one hour for the attacker now we should be all set for this one so now we can do a next and we have both our important anomalies quarantine for one hour once we do an end and once we come out of the now all the settings are saved i just want to do a show and verify everything looks good and now with the recent modification let's just try to initiate our attack again and see if we can get better result this time now we are seeing the same pattern our cpu is jumping all over the place our ram the server is suffering but in a few seconds i don't have service plugged attack this time we are seeing longer consistency no more cpu spike from that specific ib address looks like our quarantine efforts have improved the service a lot now back to our anomaly logs we can see in here the same clear session entries from before now if we switch back to our forward traffic logs suddenly out of the know where our ubuntu server the attacker is being denied which indicate this is something caused by the quarantine is not very visible in this specific menu that this is based on a quarantine but if you notice this policy number 11 is actually the allow policy there is no deny on this one we can additionally double verify using the user and devices menu we actually see the quarantine is shown one if we open this one we can actually see now that our ubuntu server has been banned there is 58 minutes left from the one hour this is based on the denial of service that's how you use the 48 firewall to protect and detect against denial of service attacks thank you for watching

Channel: ElastiCourse

Views: 2,386

Keywords: fortigate, fortinet, firewall, network security, denial of server, dos detection, ddos attach, dos block, server overload

Id: yGpVa6b0Vks

Length: 23min 42sec (1422 seconds)

Published: Mon Nov 30 2020