Your systems are up in smoke, or at least it seems like that nothing is working.
The CPU is 100% and you don't know why.
You can't get anything done.
Well, what's happened is you've been DoSed.
It's a denial of service attack.
In a previous video, I talked about the CIA triad in particular.
One of those aspects was this business of availability, a DoS attack.
Denial of service is an attack on the availability of the system.
Let's drill into that in a little bit more detail and find out what could be.
Well, it turns out not all DDoS attacks are the same.
Most people tend to think about one particular type, which I will talk about toward the end.
But in fact, there are different classes of denial of service attacks.
So the first one I'm going to talk about is sort of I'll refer to it as a ninja attack.
It's a surgical strike.
It's a magic bullet, whatever analogy you'd like to use, but it's a very targeted strike.
And in this case, what we do is we have a particular system
here that's operational and the bad guy comes along and sends a specially crafted message.
So he's taken advantage of some rule that he's going to violate in the protocol,
or he's using a buffer overflow, which is he's allocating
he's sending more information than was expected in the particular buffer where it was going to be received in some way.
This packet has been specially configured and specially manufactured
so that when it is sent to the target system, the target system goes up in smoke.
It's one strike and the system is down.
That's a type of denial of service that not a lot of people think about.
They generally think about overwhelming with more volume and we'll talk about that.
That's the next type I'll refer to, which is what I'll call the death by a thousand cuts type of attack in these attacks.
And there's a number of different types that can happen here.
But for instance, if here is our system, it's operational.
I'll give you an example of an attack that dates back to about 1996, which was one of the early versions of this kind of attack.
And it's called a SYN-ACK or a SYN flood.
What happens is a bad guy wants to take over this system.
So what he's going to do is start by sending a packet, what's called a SYN in TCP terminology.
This is starting what is a three way handshake to begin a session.
He sends the SYN message and what's supposed to happen
in a normal case is he puts in his address
so that the server responds with what's known as a SYN-ACK as an acknowledgment.
But in fact, what he does, instead of having it come back to him, he sends the SYN acknowledgment to someplace else.
He fakes out an address and says, Don't send it to me, send it to someplace else.
So he's lying about who he is.
Now, in the meantime, what happens is this system starts a timer and it allocates some resources for this new session
that it's starting and it waits now on an acknowledgment to come back from this place.
Well, this place down here is unsuspecting.
It doesn't know anything about this.
It just got a random SYN-ACK message that it's going to discard so it will never respond.
In the meantime, this system is holding resources.
The bad guy sends another SYN and another SYN.
And another SYN doesn't have to send a ton of these, but enough of these where it's a death by a thousand cuts.
No single one of these took the system down,
but collectively each one of them is reserving resources on this system until finally it's out.
Again, this was called a SYN flood attack.
And we have fixes for this now.
People have have adjusted.
But the original TCP protocol did not take into account that someone might try to do something like this.
There are other versions of this type of attack, things that do reflection, things that do amplification.
You can look up if you're interested in something called a Smurf attack, which was a similar era.
Again, we have ways to defend against these things now, but there are lessons to be learned as we look forward.
So these are two different types of DoS attacks.
How about the third major, a type of attack that a lot of people are pretty familiar with?
And with this one, what we have is we start with this is basically a death by a thousand cuts
times in where end is the number of users who are involved in the attack.
And in this case, it's going to be unsuspecting users.
So we start off with one regular user who comes along and they would access the system and everything's fine.
In the meantime, a bad guy over here, though, is starting to take over systems.
He has sent out some malware or he's hacked into a bunch of systems
and he's building what is now effectively an army of unsuspecting users that he's going to later use in his attack.
We call this a botnet or they were called zombies at one point.
But these are basically systems that are sitting here that the user has no awareness
that they have latent code that could be exploited.
Then when the bad guy wants to start his attack, he sends a message out to all of the systems
in his bot army and then they all start bombarding the system.
With traffic until it is way too much for anyone to deal with.
This is what's called a distributed denial of service attack, a DDoS attack.
It's distributed in that unlike these, the attack was in one coming from one place.
In this case, this guy is just sending the command to start the attack.
But the attack is really emanating from a lot of different places.
So that's why we call it a DDoS attack.
And there are botnet armies that sit out there right now today that can be used by a bad guy.
All he has to do is wake them up and send them on their task for a particular target.
That's the scope of the problem and there are many other types, but that gives you a general sense.
What can you do about it?
Well, it turns out there's a number of things.
So let's look at some defenses here.
First of all, the number one defense for any sort of denial of service attack,
and I'm going to say this facetiously, is infinite capacity.
Unfortunately, nobody can afford that.
So if you had infinitely capable systems, then you could throw as much
as you wanted to have them and they would be able to withstand the attack.
But that's too expensive.
What's the next best thing?
Redundancy.
If you have only one system, then one system is a single point of failure.
If you have multiple systems, for instance, in most cases we use what's referred to a rule of three
where you want to have at least three of everything.
So if one goes down, you're not at 50% capacity.
You're still have what is a usable system.
So redundancy is another important part to have here adds to expense, but it's necessary.
Pacing that is, looking at the traffic as it's coming in and limiting how much we will accept over a specific interval of time
or traffic going out, which also comes to the point of filtering.
Now, in some cases we want to filter traffic coming in from certain locations, from certain IP addresses.
We want to be able to turn these filters on when we know we're under attack.
And we and it's very difficult to do that in a DDoS attack because the attack seems to be coming from everywhere.
We should also, as responsible citizens, be looking at doing egress filtering
or filtering the data that's going out of our systems.
For instance, if the ISP for this guy was looking and seeing that he was sending lots of SYNs
that were referring to an address, that's not him, they could have blocked that at the source.
So the right kind of filtering and the egress helps everyone if we do that kind of thing.
Other things you could do would be hardened systems.
That means remove unnecessary services, remove IDs that are not needed, remove capabilities that are not going to be used.
Every one of those is something that a bad guy could ultimately exploit later.
So we don't want to have anything that's not absolutely necessary on the system.
We also want to change default passwords and user IDs, if at all possible.
Patching is another.
Making sure that all the systems have the latest software on them.
It's software fixes that took care of a lot of these earlier DoS attack scenarios.
So there they will the vendors will continue to find ways to fix their products.
And we need to keep our capabilities up to that level of where those fixes are.
Monitoring, being able to look over the whole system and understand when this is happening and when it's not.
Understand is our system really under a load because we're being ultra successful right now?
Maybe we just put some new product on sale and everybody's there.
Or is it because a bad guy has decided to try to take the system down?
We need to build it and understand the difference between the two.
So monitoring and the technologies I've talked about in other videos,
the SIEM Security Information Event Management,
XDR, extended detection and response give us that kind of monitoring capability.
And then finally, it's incident response or also called SOAR security orchestration, automation and response.
It's the ability to, once we realize we have a problem, what are we going to do?
We need dynamic playbooks that guide what our responses should be so that we can respond quickly.
The organizations that don't have that in place are the ones that suffer the most from denial of service attacks.
Don't be one of those victims.