Types of Web Server Attacks and Countermeasures

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

7 hours 6 minutes
Video Transcription
Hey, everyone, welcome back to the course. So in this video, we're gonna talk about some different types of Web server attacks as well as some of the countermeasures we could do against them.
So we've got many different types of attacks we've got. Did Austin denial of service attacks. We've got DNS hijacking DNS Amplification directory. Traverse ALS men in the middle and we'll talk about each one of these a little bit. We've got phishing attacks, Miss configurations, defacement attacks, web cache poisoning, ssh, attacks
and password cracking attacks.
So let's talk about denial of service in the DDOS attacks. So this is basically where the attacker is going to send a large volume of request to that single, uh, server.
And so the whole goal here is to eat up bandwidth to overwhelm the server with requests. So it affects the availability of that server or applications to the user that actually needs them. So it eats up the memory. It's up the network bandwidth and essentially the whole goals to take off. Take that server offline so it can't actually be used.
We have DNA server hijacking. So this is where the attacker compromises the DNS. server and actually changes the settings.
So, for example, if I'm trying to go to my favorite Thai restaurant website, theater actors actually compromising DNS. So when I type in, let's just say Thai restaurant dot com. It redirects me to a website that looks similar to the real one,
and but that websites actually on the Attackers server. So it's a malicious site
and I entered my log in credentials for the site and the attacker has my log in so a better example There is probably, ah, bank right bank website. I go, I think I'm logging into my bank website. In fact, I'm actually logging into the Attackers website now they know my user name and password for the bank. They go in, they log in, they clean on my account, and I don't even know anything until
the next day when my mortgage
payment doesn't go through
DNs amplification attack. So this is basically where the Attackers taking advantage of DNs recursive methods. So essentially they're redirecting.
Think they're spoofing I p addresses, and then they're redirecting to amplify that attack
directory traverse alot attack. And so for the ch exam, you're gonna want to just be familiar with all of these And having taken the thieve version 11, which is a new one coming out in January of 2020. Uh, just taking that beta test, I can tell you that you do want to just be familiar with
the different types of attacks here. I can't tell you specifically which ones but just know you wanna be familiar with these a little bit going into that example,
director traversed attacks. So essentially, just using this attack to access directories that the Attackers shouldn't be able to access on that web server
man in the middle of attacks. So again, just injecting themselves in between that session of the client and the Web server s early in the course. We talked about an example of throwing a football to our friend. So I throw the football to my friend and you jump in between and and catch the football. We're talking about American football here
on you catch the football. You're that man in the middle, essentially, your
capturing that data packet. And then you're throwing it to to my friend and completing. You know the transaction. There are the three way handshake
on DSO you're basically taking over that session. So you're jumping in between the session and looking at the data that's flowing through it.
We've got phishing attacks.
This is where the attacker might be using the fake websites. So they redirect, for example, to that fake Web website. That fake banking website
on the goal there is stealing the credentials, right? So now they can log into your banking account and they could steal of all of your money,
miss configurations of the Web server. So we might be using default credentials. And so the Attackers able to gain access, also air messages. So as you're sending queries to the site, it's giving them very verbose air messages, telling them information about that back end database
and also miss configure security certificates. So we're not. The attack was able to exploit that,
and we're they're able to downgrade our site to an insecure site as well as running things like unnecessary services on that Web server
and lastly, enabling remote admin functions or not disabling them if we don't actually need them
Web cache poisoning attacks. So this is basically where the Attackers gonna flush the Web server cash and then send their own information into the cash. So they're gonna send their own request malicious requests into the cash.
Ssh! Brute force attacking where the Attackers gonna brute force? Ssh! To try to get the log in credentials.
And then they basically they've got an encrypted tunnel, so to speak that they can transmit malware. And it's not detected by your ideas system
password cracking for the web server. So basically, transmission of default passwords allows us to try to crack those passwords SMTP servers, uh,
using trying to crack essays, tunnels
as well as if If we're using, like, FTP servers and not secure FTP for transmitting that data
and they do this sort of variety of methods, it could be guessing it or mawr likely dictionary or brute force attacks. Eso brute force attacking and using dictionary attacks.
So what are some of the things we can do against Web server attacks? Well, weaken do things like patching. We can also make sure that we're focused on Onley using the protocols that we need. We can check the user accounts, make sure only accounts that need to be running a running as well as making sure we limit access to the files and directories, So let's talk about each one of those a little bit.
So with our patching and updates, we wanna identify any vulnerabilities that we may have based off the operating system and applications and use on that Web server. Before we deploy these patches to production, we wanna make sure we actually test things, see if we're breaking stuff. If so, let's identify what the issue is. Maybe there's a
a specific step we missed in the process of updating with that patch,
and we have to go to the manufacturer site and download it and then update that one area not related to Web servers but one area not related that you might see that in is I. C s networks where we way might try to, for example, patch R H m I, and
we forget one step in the process. So then we have to go to the manufacturer website and download
that patch and then reinstall the patch. We just did. And so we wanna make sure that we test these things first before we put him into production,
and we could do this through Patch management, right? We can have good patch management in place. Also making sure we have backups just in case something's wrong with that backup and part of that being making sure we have a proper BCP and DRP the business continuity plan as well as the disaster recovery plan. So what happens if something goes wrong? Can we continue business and how do we do so
and then? Disaster recovery plan?
What happens if there's an actual, like natural, natural disaster? How do we recover from that and making sure you update those security certificate? So making sure we keep the latest version of the certificate on our Web server
protocols. So basically, let's block unnecessary ports or airports that we're not gonna be using block ICMP traffic. So blocking those ping that ping traffic
blocking any unnecessary protocol. So if we don't need it, let's not have it open on our Web server. That's just all additional areas where the attacker can get in updating the system software and using I p. SEC policies. Eso using that with insecure protocols like FTP until net
our accounts again. Just making sure that if there's accounts created that our default credential accounts, we disable those because we don't need those accounts to log in, make sure that any accounts that are live are using the concept of least privilege. So that way they only get access to the information that they need, removing any access to the database.
So if an account on the Web server doesn't actually need database access, we remove that access,
removing stored procedures as well as well as unused application extensions and ensuring that we've got strong password policies for the accounts that are live on our Web servers.
And then for a final file on directories, we want to eliminate any unnecessary dot jar files, as well as removing sensitive configuration information and disabling the the basically the serving or the ability of the attacker to see the directory listings, as well as eliminating any non Web files from that Web server.
So just a quick, quick question here for you default log in credentials in use or an example of which of the following is that a defacement attack? Miss confirm Miss configuration or poisoning.
All right, this one is pretty easy, right? This one is miss configuration.
So in this video, we just talked about some of the different types of Web server attacks. We also talked about some of the counter measures we could do to help protect against those attacks.
Up Next