Now that we've reviewed our strategy for detecting
brute force attacks on an SSH server,
we will move into the demonstration environment and
show an application of the strategy.
As we noted in the previous section,
the detection of a brute force attack on an SSH server is more
complicated to detect as we don't have direct knowledge of the
commands that are being transmitted.
And because of this,
the potential attacks that are detected will need to be further
scrutinized to determine a true attack has occurred.
So now let's move back into the demonstration environment
and take a look at how we can potentially detect brute
force attacks on an SSH server.
We're still importing Scapy.
We're still beginning at the main function.
The first difference that we're going to see from
the previous demonstration was, instead of pulling in the FTP traffic,
we're pulling in SSH traffic into the same captured variable.
We are, in this case, using three different of these variables.
You see the lighter blue is the ones that were actually using
in this case, so PrintSummaryToConsole, TrackAttackSources,
and the SSHThreshold.
The SSHThreshold, in this case,
relates directly to the size of the exchange that goes
between the SSH client and the SSH server.
So you would change this if you saw that those exchanges were taking
different amounts of traffic for success versus failure,
in our case,
7500 seemed to be a good number based on what we saw from the session analysis.
We're going to use that same FullDuplexSessions function to pull all of
our sessions into a Full_Duplex_Session variable.
We're going to use the same TCPSessionFilter to weed out anything,
but TCP sessions,
and then we're going to use a new one named SSHSessionFilter which
is going to automatically screen out anything,
except SSH traffic.
Now, if we go up to that SSH one,
since we didn't look at that in the previous one,
all that we're doing in the SSHSessionFilter is we're looking for
traffic that has a source or destination port of 22.
Now once it's collected all of the different session rows
of this variable that relate to SSH, so once this loop has done its work,
it will return them into the SSHSessions variable.
Then next we have here,
this is sort of the meat for the SSH piece of the brute analysis,
and here is where we take all of those SSH full duplex sessions that we had
and we're pushing them into the SSHBruteAnalysis function,
and again,
we're sending in three different variables which
were the three that we reviewed, including these sessions.
Now the analysis for SSH as we noted in the previous section must be
based on something other than specific commands inside that traffic
because we don't have access to it,
and the way we did that was we looked for the specific
size of the exchange that went on.
So the session that went on between the client and the server,
we measured what that size total was and then we compared that against
the threshold that we entered into this function,
and then if it was under that specific threshold,
it would automatically add it to the failed list.
Now the trackattack piece is what's going to collect all of the
cumulative source and destination information, and if the
attacks are coming from a specific host,
it can be printed out and it will show you that the brute
force attack type was coming from these specific addresses
or this specific address,
and it would print that out for you so you could do further investigation on it.
Just like before, if you wanted to print the summary out,
it would give you the Success and the Failure Counts.
And if we actually have trackattacks enabled,
it would automatically print this key information out once the
function was complete with its analysis.
Now let's take a look at what this looks like if we actually run it.
So in this case within that capture file,
our script believes that of the sessions that it read,
65 of them were failures and none of them were successes.
And since we had the trace attacks variable enabled,
it shows you that of the 65 attacks,
all of them were coming from the 10.10.10.105
client into the 10.10.10.103 server.
So this information can be used for you to investigate who is the .105 address
and why he's trying to brute force into your SSH server,
or best case scenario,
why he's having continued unsuccessful logins coming into your SSH server.
And so now with that, let's move into our summary for this module.