Now that we've reviewed our strategy for detecting
brute force attacks on an FTP server,
we will move into the demonstration environment and
show an application of this strategy.
Remember to keep in mind how these concepts could be used in your
job as a Globomantics network security engineer.
So now let's move into the demonstration environment where the
first thing that we did was import all of our associated Scapy
modules into this specific script with the from scapy.all import *
command at the very beginning, and then in our case,
our script actually starts at the very bottom here where it says run main,
so if__name and then it runs the main function,
and there is some reference to SSH in here and that's
because we use the same script,
but with different functions slightly in order to do our brute force
detection in our next demonstration environment.
So for the purposes of right now, we can ignore the SSH pieces.
So the first thing that we do in this script is we're going to pull in a
capture of a number of different brute force attempts on an FTP server
and we pull that into a capture variable.
Now there are a number of different variables that we have true and false here,
and we will review those as we go through the different code pieces real quick.
Next,
we're going to format the sessions from that capture that we
pulled in and we're going to do that by running them through
the full duplex sessions function.
So we need to run up to that function, which is at the top of this script,
and this is a function that I borrowed from a gentleman named Mark Baggett,
and we had done this a number of different ways,
but this seemed to be the most efficient for what we wanted to accomplish.
So what it does is it goes through each of the
different session entries from Scapy, these are Scapy sessions,
and it makes all of the unidirectional sessions full duplex sessions,
so it's going to be both the going to the server and back
from the server and that puts them into the same lines so you
can reference that whole session, including both directions.
And this information is then returned back into this
full duplex sessions variable.
Notice in this case, this full duplex sessions does not have underscores,
whereas the function has underscores.
We then take this variable and push it into a TCP session filter function and
that will return into this TCP sessions variable that we have.
What this function does is it takes all those full duplex sessions that we
pulled out from that initial function we looked at and it looks through all of
them and it only returns the ones that are TCP sessions.
So if there is any other sessions that it has in there,
it will automatically screen them out and if we look at that real quick,
that's this logic right here, and in this case,
all we're doing is we're looking to see if that specific entry,
or each specific entry says that it's TCP,
and if it says it's TCP,
it will automatically be entered into that TCP sessions variable and
returned back to that variable that we have at the end here.
So in this case, the function calls the TCP sessions,
and we also use the same name,
but this is a different variable that's local to the function variable.
This is a variable inside the main function.
So now this variable contains all of the full duplex TCP
sessions that exist from that captured file.
We then take those entries here and we push them into the FTP session filter,
and as you would imagine,
what this does is it takes all those TCP sessions and it screens out everything,
except for FTP sessions.
Look at that real quick.
And we see here, and I'm not going to go through all the specific logic,
it would take too long,
but the script is going to be included as part of your materials for this
course so you can take this code and use it at your will.
The thing we're mainly going to focus on here is this piece right here which
says is the destination and/or the source port information 21?
Okay, and those FTP sessions are returned back into this variable right here.
So now we have a full duplex list of all the FTP
sessions that existed within that capture.
So we've isolated down everything into one list of FTP
sessions that are held into full duplex.
In the next piece here is where we actually do the meat of this,
which is the brute force analysis of that FTP traffic.
And as you can see here,
there are a number of different variables that we push into this
function and the majority of those are optional,
and we'll go through real quick what they're used for in the function.
Okay, so here is the beginning.
This is the function we'll see that all of these other variables,
except for the FTP sessions variable are optional and they
automatically will default to false.
And what we're doing here is we're going to be looking for
those specific commands inside that traffic.
And what we're focusing on here is we see if I found user in there,
if we find password in there.
So basically what it's doing is it's it's going through in loop
for each one of the packets in the session and it's looking for
the user command and the pass command, and then on top of that,
it's also looking for that login successful message, and if
we clear this and move down a little bit,
we'll also see that it's looking for that 530 Login incorrect message.
If you look here,
we see it prints off to the screen and says Found LOGIN SUCCESS in session.
It'll tell you what the client is, it'll tell you what server it is,
it'll tell you what the user and password are,
and that will automatically be printed off to the screen,
but only if this variable is true,
and this is one of the variables that we had inserted in at the beginning.
So if you want to see stuff to the command line whenever you run this script,
you would turn that specific flag on.
And in this case,
that flag is the one that says plogins here and that associates
with print logins at console here and here.
So I just put that in the script just so if you want
to have more debug information, that's what it's there for.
Similar logic is followed.
If we have a failure that we detect, it'll,
if that's enabled and set to true, it'll show login failure,
it'll give you the client server, the username out to the CLI.
Now another one here is track the attacks and what
this does is if we have this flag on,
it's automatically going to create a dictionary of all of the failed attempts.
So it's going to give you a variable that you can parse
further of all of the different failed attempts,
and then from there,
you can further dissect that to say well there is a lot of different
failed attempts from this specific IP address.
So if that's enabled, it'll automatically return that as well.
And if we look at the bottom here,
we'll see a number of other things that associate to those
different variables that we talked about.
The first one is print a summary,
the track attacks variable that we just covered,
this is a printout of all those different attacks that would
automatically be pushed to your screen.
And the third one is save a file, and what the save a file does,
which is a completely different variable,
is it will automatically create a file in the root directory
of the script of the suspected attack.
So what that's going to be is it's going to be a pcap file of only
the session traffic for the suspected attack.
So if you wanted to further investigate that,
you would have a capture file that you can either pull onto Scapy and
do a further analysis of it or you can pull it into Wireshark or some
other capture utility and see the packet specifically and what we were
looking at within the utility.
Now let's take a look at what this looks like whenever we run it.
In this case, you can see that we have track attack sources on set to true,
we have print summary to true, but we have print logins to console as false,
so it's sort of a summarized view.
So within that specific capture file, we had 2 FTP login successes,
we had 870 failures, and between those 870 failures,
438 of them were going from 150 to 103, and in this case,
103 is the FTP server, and 432 of them were coming from .200.
So depending on however many sources there would be,
this would show up as part of the second part of the output.
Now if we wanted to see each one of these logins as it was being looped through,
we can set this variable to true, but whenever we do that,
it's going to show considerably more output.
And if we look through here we'll see Found a LOGIN FAILURE in the session.
The client was from .200 to 103.
The username that was tried was the username of kali and a password of newyork,
and there is another one, kali Ladybug, badboy,
raymond, cookies, fernanda, and all of those were tried coming into this.
Now obviously this shows a whole bunch of additional output,
so if you want to have that enabled or not,
completely depends on what you're trying to get out of this utility.
Now the save to file piece, and as of right now,
this is what's in this directory, run that same command,
going to save the sessions out,
and we would expect a whole bunch of different files in here of all
of the different sessions that were suspected.
So each one of these has its own name, so in this case,
this is traffic between .103, which is the FTP server and .200,
which was the attacker.
The ephemeral port was 39614,
which is what makes it unique, and it was a TCP capture.
So that's about it for this specific demonstration environment.
In our next section, we're going to move on from FTP,
which is simpler to look through,
and we're going to look at how we could detect a brute force attack with SSH.