26. CloudFront Signed URL – 01
Hi everyone, and welcome back to the Knowledge Portal video series. So recently I have been traveling, and I am currently in a different city, so I had to actually set up my entire lab, including my microphones, etc. And there are again some issues with the lightning, so I hope you can bear with that. Anyway, by continuing with our Cloud Front lectures today, you’ll learn how to make cloud print work with sign URLs. Now we already looked into the basics of signed URLs when we were studying the F-3 subsection, and today we’ll look into a very similar concept, but this time configuring it with CloudFront.
So generally, let’s take a very simple use case where you are a solutions architect for one organization, and that organisation is very similar to that of iTunes. So what that means is that the user first purchases a song, and once the payment is successfully completed, the application will allow the user to download that song. So again, I hope you understand the basic concept of a signed URL. So, after the user purchases the song, the application will generate a signed URL with an expiration timer and provide that signed URL to the user to download. So again, the back-end infrastructure is that all the songs should be in s three.
And now that the organisation is using CloudFront, we need to integrate signed URLs with CloudFront distribution. So before we go ahead and understand how we can implement this particular type of architecture, let me actually show you how this works. So I have a Cloud Front distribution over here, and let me just copy this particular domain name as this is a Jingle Bells MP3. So this is the MP3 file. This file is once again saved in the s3.
The slug in the slug in the slug. So let me try to open this particular file. And if it says missing key pairID query parameter or cookie value, it means that the user will be unable to download this specific MP3 file unless he has an associated signed URL for it. so similar with index HTML. Let me actually show you. So you see, even if I open the index HTML file, it is saying “missing key pair” for the idea query parameter. So what we need to do is get the signed URL to open this particular file. Let me just copy this and try to open it now that I’ve created a signed URL. Okay, it is not working. Let me try to generate it again. This time it’s proper, I guess. Let me copy this particular signed URL, and let’s try opening it. And now you see that it is opening perfectly. So if you look into the basic format of the URL, Again, we discussed that in the initial chapters while doing Chapter 3. First comes the URL of the page, which is index HTML, then various query parameters that are basically related to the expiration header, which basically means how much time this URL should be valid: should it be valid for 24 hours, should it be valid for three days, et cetera. And along with that, it also contains the key pair ID. So if you look here, this is the key pairID along with the signature of the particular URL. So if I want to access the Jingles Bells MP3, let me just show you how. This file is actually present in the “S” bucket. Okay, so this is the JingleBezzle MP3.
Now, I need to access this via CloudFront, and when I try it directly, it is not working. That means any content within this particular bucket will only be accessible as part of a signed URL. So let me do one thing. Let me generate a new signed URL. We’ll talk about the various parameters in the upcoming lecture, but for the timing, I just wanted to show you how things work. So I type “jingle levels MP3” in place of the Uri partover, and it should return a signed URL. I’ll copy the signed URL. And one more thing I just wanted to show is that we are also passing the parameter “less than.” So this will directly connect to the expiration timer. So on one side, let me just copy it again. Okay, let me copy this again, and this time you can see the MP stream in English is actually opening, and it will open or be valid only until the time that we specified during the generation of a signed URL. So this is the fundamentals of how we can configure cloud front or the fundamentals of a signed URL with cloud front. In the next lecture, we’ll understand how we can configure our cloud distribution to work with signed URLs. So I hope this has been informative for you, and I’d like to thank you for viewing.
27. CloudFront Signed URL – 02
Everyone, and welcome back to the Knowledge Full video series. Now, in the previous lecture, we looked at how CloudFront works in terms of signed URLs. And in today’s lecture, we’ll go ahead and understand how we can configure our CloudFront distribution to work with signed URLs. So again, looking into the use case, I have a three-bucket list, and there are three files within this three-bucket list, and there is an MP3 file called Jingle Belts MP3. So now the use case over here is that your organization wants people to download this particular MP3 file only after they have purchased the song.
So once the user has purchased the song, the application should be able to generate a signed URL that it will give to the user, who will then use that URL to download the song. A very simple use case So how can we configure this particular scenario? Now again, the very first thing is that you need to have an S-3 bucket, and definitely you need to have some contents like songs within the S-3 bucket. Now the next thing that you want to do is establish a bucket policy. Now, we already discussed that only CloudFront should be able to get the objects within this particular bucket. And this is very important; otherwise, users will try to directly access the Spotify bucket to download the songs. So there is the configured originaccess identity. That means only CloudFront distribution will be permitted to get the objects within this three-bucket three bucket.
So until this part, I hope we are clear. So now let’s go to the cloud front. Now you already have the cloud front configured. So what I’ll do is just show you how to do that because I have already done it in my CloudFront distribution, and any changes that you make actually take a lot of time to get deployed. So currently, you see the status as “deployed and it actually took around 10 to 15 minutes to get deployed. So, while I don’t want to do it again, I’ll show you what changes I made. Very simple. You only have to modify two settings.
So you select the particular distribution and go to the distribution settings. Now, once you have gone to the distribution setting, select the behavior, and there will be one configured behaviour over here. Select this behavior, click on Edit, and if you go a bit down, there is an option called “Use sign URL or sign cookies,” which is also called “Restrict Viewer Access.” All you have to do is go from no to yes, and then select yourself in that trusted signup. So, now that you’ve done this, Cloud Fund will only allow access to the content of those three buckets through signed URLs. After that, simply click Yes, edit, and CloudFront distribution will change the status back to “in progress,” and it will be deployed in a few minutes. When it is deployed, the next time you try to open any content within the three buckets, such as indexor HTML, you will receive an error stating that a keyword ID, query parameter, or cookie value is missing. So if you get this error, you are all set. That means the signed URL is properly configured. Now, once you have done this, you need to log into the root account. Remember, you must log into the root account, which is my root account over here, and then go to my security credentials, where you will see CloudFront keypads. So just select the cloud-front key pairs, and you need to create a new key pair.
Now the reason why you need to create a new key pair is because if you want to generate your own signed URL, then you need a private key associated with it. So I already have a keypair, which is configured over here. Let me delete the older ones. Okay, so you need to create a new key pair, and then it will prompt you to download. So just download the private key file. So I’ll download the private key file, which will be something like PK or PEM. So this is a very important file, and you will use this particular private key to create a signed URL. If you want to see the format of a signed URL, go to the AWS crowdsourcing CLI and press CTRL + S to sign, and it will give you the basic option that you need to create a signed URL via the AWS CLI, so the basic command is AWS cloud front followed by sign URL. As a result, in the URL, you must include the exact URL, followed by the key pair ID, the private key, and the data less than value. So let me show you how this works. So we created a signed URL in the previous chapter. Let me actually show you the exact command that I use to create a signed URL. So we have an AWS cloud front, followed by a sign.
So this is followed by the URL. The URL is now simply the URL that the user wishes to open or download. So if a user wants to download a song, the link to that song should be in the URL section. Next is the key pair ID. Now this key pair ID is the ID of the key that we just generated. So if you see over here, which is the access key ID, So in our case, the key pair ID will be the one that we just generated, which is this particular one. So this is the key pair ID that you need to provide. Now this is the key pair ID followed by the private key. Now remember, we just downloaded a private key file. So you need to reference that private key file. Without the private key, you will not be able to create a signed URL. Very important. And the last section over here is the date parameter. Now in the date parameter, you need to provide the expiration time, just like in this URL. The sign URL that will be generated will only be generated for a particular, specific time. As a result, you can include that in the date less than header.
So if you look at the expiration date and time for the URL, So this is the basic option for creating a Cloud Front sign URL. Now, one important thing to remember as the AWS CLI is very new as far as Cloud Front is concerned: So you need to run this particular command, which says “AWS configure set preview CloudFront true,” which will actually enable Cloud Front-related CLI commands. As a result, you must execute this command in AWS. Okay? Once you run this particular command, just run the CLI command that we have typed. Now, a very important thing to remember is that they have not given any examples over here; you see, there is no example, and many of the time it will be a mistake where you reference a private key file directly to the path. But you need to mention the file. So without this, it will not work, and this is not there in the example. It is very important to remember this now.
So again, I hope you remember. And now if I just press Enter, the AWS CLI will give me the cloud friend-signed URL. I copy this URL, I paste it in the browser, and I’m up and running with the MB three file. So this is the basic information about the signed URL. Again, one important thing to remember is to make sure that you have the latest AWS version of the CLI. So if you have an older version, like 1.9, it will not work. You need to have the latest version, which is AWS CLI version one point. The Cloudfront CLI is only compatible with AWS CLI version 1. So, this is a very important thing to remember. In terms of the CloudFront distribution, this is the fundamental information on how to generate an assigned URL. I hope this has been useful for you. Again, I really encourage you to practise once, because without practice, you will not truly understand the true concept. So this is it for this lecture. I hope this has been informative, and I’ll see you in the next lecture.
28. Real World example on DOS Implementation
Hey everyone, and welcome to the KP Labs course. Now in today’s lecture we are going to speak about a very interesting topic, which I am sure most of you will really like, which is called the “denial of service.” So, I’m sure many of you have heard about denial of service attacks and how many major websites are being brought down as a result of them. So let’s understand the basics, or what denial-of-service attacks are all about, and then we’ll go ahead with our interesting practical’s as well. So in a normal website operation, there is generally something called “normal traffic.” So if this is a website, a website can handle a specific amount of traffic.
So it can be ten requests per second or it can be 100 requests per second, depending upon the server capacity. So in the normal scenario, you see that the server is all happy. So it is in green where there is normal traffic. At times, there may be a high volume of traffic, causing the server resources to become extremely busy and the application or website to become extremely slow. However, the website is still operational. As a result, the cases you’re about to use will appear very genuine. However, an attacker may attempt to generate excessive traffic with the sole purpose of bringing the server down. So if you’ll see over here in the third-party case, you have a denial of service where a single attacker is generating a lot of requests in such a way that the server is completely down.
Now, there is one more attack called “distributed denial of service,” where there are multiple parties doing a denial of service attack on the same resource. One distinction between a DoS and a DDoS is that a DoS may involve only one user attacking the server. DDoS attacks, on the other hand, involve hundreds of users from all over the world attacking the same endpoint at the same time, which is why they are referred to as “distributed denial of service” attacks. So DoS and DDoS are basically part and parcel of the servers and the network life. Now, the reason why these attacks are so successful is because they are very easy to launch them. And along with that, when you go and inquire about DDoS protection, if you are a system administrator, you will be presented with a big bill that you might have to pay if you really need DDoS protection. However, many cloud providers, such as AWS, are providing good services, such as AWS Shield, that can help you protect against distributed service attacks to some extent.
So nowadays, the DDoS attacks are very big. So if you talk about 2016 itself, which is like two years ago, you had a DDoS of 800 gbps. You can imagine 800 GB of traffic per second. It can actually bring the biggest of the websites down. So, let me demonstrate in real-world labs what the Dos attack would look like. So on the left side, I have my Windows machine. And if you look at the CPU utilization, it is at 3%. So I have a Core i7 processor that is only 3% utilized. Now, after I performed a Denial of Service attack, you can see that the CPU instantly went to 100%. So, within a few seconds, DoS attacks increased from 3% to 100%. So let’s not waste time. And let me show you what it would actually look like. So first, I have a Windows 10 machine over here. And if you look at the CPU utilization, it’s not much, quite empty, ranging from 8% to 78%. On the right, I now have a Kali Linux machine. And this is where the DoS attacks will be directed.
So, let’s start. So just notice the CPU utilisation is quite low at 3% right now. Now, within Kali Linux, there is a great tool called Loik. So Loik is one of the tools that can perform Denial of Service attacks. So, the first thing you must enter is either a URL or the IP address of the endpoint that you wish to attack. So in my case, I’ll put the IP address of the endpoint. So, 109, 216-8923. So this is the IP address of my Windows machine. Depending on the firewall and the application, you may be able to employ a variety of attack vectors. So for my case, I will be using a UDP-based attack vector. And let’s start. So you can put the first thing you have to do—just lock on to the target—and just press “I am charging my laser.” As you can see, the number of requests sent by this platform is astoundingly fast. And note that this virtual machine only has around 2 GB of RAM. Examine the requests that are being made within two GB of RAM. Now, if I go to the Windows server, you can see the CPU utilisation is actually going to a very high spike rate. So around 89% And after a minute or two, the CPU utilisation will spike to 100% full. And this is the power of a denial-of-service attack. You see, the CPU already reached 89% anyway.
So, if I just press “Stop flooding,” I’m sure I’ll be able to count the requests in unit tens, 100,000, 10,000 lakh, ten lakh. So, from a 2 GB RAM virtual machine, approximately 13 lakh requests were sent in less than a minute. So imagine what would happen if you launched this attack vector from a 16GB RAM server. The volume of requests that will be received will be enormous, and it has the potential to bring down many networks and websites. Anyways. So coming back to our PowerPoint presentation, I hope you understood what the denial-of-service attack was all about. So the practical thing that we did right now was to deny service because there was a single entity. You also have distributed denial of service, where there are multiple users who might run the log tool, which we just ran now to a common endpoint. That is the distinction between a Dawson attack and a DDoS attack. DDoS attacks are also fairly common. It has actually brought Twitter down and restored much of the functionality on Facebook, PayPal, and other sites.
29. AWS Shield
Hey everyone, and welcome back. In today’s video, we will be discussing AWS Shield. Now AWS Shield basically helps you protect your workloads against distributed denial-of-service attacks. AWS Shield tyres are now available in two sizes. One is the shield standard. And second is the shield advance. Now one of the very common scenarios nowadays is a distributed denial-of-service attack, which actually brings the website down.
And this is the reason why a lot of customers have been asking for a solution that can protect against large-scale DDoS attacks, and AWS Shield is one of the solutions that can help against this scenario. Now speaking about the two variants of Shield, which were Shield Standard and Shield Advanced, let’s understand the difference between them. Now, when it comes to the AWS Shield standard, it basically provides a basic level of protection against common attacks related to the transport and network layers of the oversight stack. When it comes to a higher level of security, AWS Shield Advance is the best option. Now, a Shield Advance basically protects against various sophisticated distributed denial-of-service of Service attack.
And one good thing about Shield is that it provides near-real-time visibility into the attack that is occurring or that might be occurring within the organization. Now, along with that, AWS Shield Advance gives customers 24-by-7 access to the AWS DDoS Response Team, which is also referred to as the DRT during the ongoing attack. So let’s assume that your organisation is already facing a massive DDoS attack. So what you can do is contact the AWS DRT team, which will help you with the measures that can be taken to protect against those attacks. Now the next important part to remember is the AWS Shield-related cost and credit factor. Now AWS Shield Advance will cost you a base price of $3,000 per organization, and it basically requires you to have business or enterprise support. Now one of the interesting parts about AWS Shield is that during the attack, let’s assume that you have Shield Advance enabled and have received a huge amount of attack, due to which your infrastructure cost will also increase.
So AWS will basically return that money in the form of credits. Now, remember, it does not offer you credit for all the AWS resources. There are certain AWS resources, like Route 53 ELP CloudFront, for which the credits will be returned to you if you have seen a search due to a DDoS attack. This is a screenshot of ShieldAdvance as it actually appears. If you are interested, you can pay $3,000 and see in real time what Shield Advance would really give you. But I’m sure that we will be content with a few screenshots to just see what exactly it might look like. So these are a few screenshots related to the Shield Advance. Now, before we conclude the lecture, I just wanted to show you the shield on the console. So within the Waffen-Schutz page of AWS, you can go to the AWS Shield, and basically on the start page, it will give you a comparison between AWS Shield Standard and AWS Shield Advance. So, if you looked, these are all the comparisons. This is the type of cost protection that reimburses. AWS will reimburse the costs related to the Route53 cloud front end as well as ELB. And along with that, you can activate ShieldAdvance, where the base price is $3,000 per month. And you have additional data fee charges as well.
30. Mitigating DDOS Attacks
Hi everyone, and welcome back to the Knowledge for Video Series! We learned the fundamentals of DDoS and what a single machine can do for DDoS-based attacks in previous lectures. So generally, what happens is that hackers use the full botnet of servers to attack the websites, and a lot of websites go down because of distributed denial-of-service attacks. So what we’ll do today is learn about various techniques for mitigating DDoS attacks on our infrastructure. So there are four major points to understand as far as mitigating DDoS is concerned. The first is to be ready to scale as traffic surges, so you should be ready to scale up if the traffic increases. So we’ll understand all of these points in detail. So the second point is minimising the attack surface area. This basically means that you should not expose your entire infrastructure structure to the internet because DDoS attacks are most likely to occur in the exposed area, which is usually the public subnet. So this is what the second point says. The third point says to know what is normal and what is abnormal. This is specifically applicable to enterprise websites; they should have a proper metric to understand that this much traffic is normal and this traffic is abnormal. This is a critical point.
And the fourth point is to create a plan for attacks. So this basically means: what will you do when there is an ongoing DDoS attack? So you should have a proper plan for that as well. So let’s understand each point in detail. So the first point again is to be ready to scale. So basically, our infrastructure, or your infrastructure in AWS, should be designed to scale up as well as scale down whenever required. So this will not only help you during your peak business hours, but it will also help you protect yourself under a DDoS attack. So, to scale infrastructure up and scale infrastructure down, you can use various AWS services, specifically ELB and auto scaling. Now, for example, whenever a CPU load is greater than 70% on the application server, it automatically adds one more application server to meet the needs. So generally, in a DDoS attack, there is resource consumption. Assume your application server, your current application server, is using 70% of the CPU. Then the auto-scaling group should automatically add one more application server to meet the needs. So this will help you not only during your peak hours, or, as I would say, suddenly when the traffic comes, but also when there is a DDoS attack going on. It is very important to always have your infrastructure ready for scaling. This is the first point.
The second point is to minimise the attack surface area. So again, this is possible if you have a properly decoupled infrastructure. So as with PCI, DSS also says that one server should be used for one service; there cannot be multiple services on a single server. So, for example, an application server and database server should not be in the same EC2 instance. Now, let’s assume that you have a single EC2 instance running both the application server and the database server. So if you have such a scenario and if there is a DDoS attack that is happening on that particular EC2 instance, not only your application server will go down, but along with that, even your database will go down. Now, if, for example, you have a separate EC2 instance for application and database, and if you have a sudden DDoS attack, then just the application server will go down. In the worst case, your database server will still be up and running. So, it is very important to always have a decoupled infrastructure, and in order to have a decoupled infrastructure, there are various services like SQS and elastic beam stop that will help here.
Third, understand what is normal and what is abnormal. So there should be a key matrix that defines that this is normal behavior. So again, an example is that of a website that is receiving huge traffic in the middle of the night at 3:30 a.m. Assume you have an e-commerce website and you suddenly see a large increase in traffic at 3:00 a.m.; this is actually unusual. You can see that this is unusual because an e-commerce website for a specific country does not receive a lot of traffic at night. So, similar to this, you should have a key matrix that can help you as a security engineer determine whether this amount of traffic at this time, for example, is normal or abnormal. So again, various services can help you, like Cloud Watch and SNS, which are important services that can help in this case. Now, the fourth and most important point is to create a plan for attack. So let’s assume that there is an ongoing attack on your intrastructure. Now, how you will deal with this situation or what action you will take in this scenario is critical.
So you should have a plan to mitigate DDoS attacks or to mitigate ongoing DDoS attacks. So, for example, let’s assume that there is a dual-source attack going on and you are unaware of what exactly is happening. Checking whether the source IP address of the request from which the traffic was sourced is a very simple way to determine whether it is a DDU attack or not. The second important point is to check from which country the increased traffic is coming from.So, if you have an e-commerce website based in India and suddenly you are finding a huge amount of traffic coming from another country, that definitely means that that traffic is basically suspicious. The third step is to determine the nature of the attack. So if the attack is a thin flood or if the attack is at the application level, So once you understand the nature of the attack, you can know what measures you can take. So, if it is a sin-flood-based attack, then maybe you can work around it with, say, network AC or the security group. But if it is an application-level attack, then maybe you might need a web application firewall, et cetera.
So in order to understand how you can prevent an attack, you should know the nature of the attack. And the fourth point is that it can be blocked at the network ACL or security group level. For example, if the majority of the traffic is coming from a specific IP address, you can block that IP address directly at the network ACL level. And the last point to remember, which AWS also recommends here, is that it is recommended to have AWS support, at least for business purposes. So whenever you are having a DDUs attack, you can immediately contact AWS support, and they, along with your security engineers, can help you work around the ongoing attack. So, four very important points. Now there are various services that will help you protect against DDoS attacks, like Amazon CloudFront. It is one of the major services that can help you protect against DDoS attacks. The second is route 53. Then you have various services like auto-scaling, web application firewalls, ELB, VPC, security groups, and network ACS. So generally, as far as exams are concerned, specifically in a security specialty exam, whenever you see a DDoS attack, they might ask you what the prevention measures are to protect against those DDoS attacks. And again, the number one prevention mechanism, I would say, is having an AWS cloud front.
These are two very important services. Amazon has released a very nice webinar, or should I say video, on mitigating DDoS attacks. I’ll attach the link along with this module. I will really recommend you watch that video once because it goes into too much detail, too much technical detail, on how CloudFront or Route 53 can actually help you protect against DDoS attacks. So it goes into the Sin Flood and how cloud fronts can mitigate the Sin Flood-based attacks and those things. So, it’s really recommended that you watch this video. So that’s the fundamentals of mitigating DDoS attacks. So I hope this has been useful for you. And this is again a very important question. As far as the exams are concerned, I would really recommend that you watch and understand them. So this is it about this lecture. I hope this has been informative, and I’d like to thank you for viewing.
