Ok, for our next module, we will be getting into flow graphs.
And if you were part of our Q&A session
momentarily, we did a practical, practical application of using a flow graph.
But we will redo one again now and go into more detail about the flow graph.
What the flow graph does is it allows you to look at all conversations in a view
where specifically, if you needed to see communication
from an IP address to an IP address
it will show you packet by packet exactly
what's taking place at every step of the communication.
And if you refined to a TCP flow, it will actually show you
specifically where in the handshake the, each packet is
and that gives you a great picture.
So, let's use an example. Let's say you are going to a website
and that website was performing poorly.
You did not understand why and you're starting to look through your packets,
your data, and you're, and you're, you're starting to come to a loss.
So, one of the things you do is you pull a flow graph on this data.
And you're able to extract the entire conversation
from source to destination
and each packet, what happened in time sequence.
So, what that will show you as an example is if you go through your, your TCP handshake,
and you see a flood of reset packets or you see it consistently
send out duplicate acknowledgements or re-transmitting data.
It's likely that there is some kind of issue taking place
from source to destination.
And what's nice about the flow graph is it gives you that in a picture form.
So that instead of sifting through the data even, even if you use the TCP stream graph,
without siftiing through all that data,
you can very quickly ascertain what could be the problem or what point
this was creating a problem or problematic behavior
or perfomance issue. So, what does it mean?
It doesn't necessarily mean you know where the problem is coming from?
You just know that it's from the source to the destination.
So that's one of the important things to understand about the flow graph.
Just because you see from the source to the destination
doesn't mean you see all t he components in between.
And anything there could be also causing an issue.
A synchronous routing can be a common one where it's impeding the traffic flow.
There could be buffering problems on the target device.
There could be a, a path of reasons why you may be getting this data back but
what this graph will do, the flow graph
will allow you to really see the conversation for what it is -
what it is as you caught it and will start giving you clues as to what could be causing
the issue downstream or at each endpoint.
So why we use the flow graph?
We use it to analyze the capture of filtered data
to extract the flow from a source to destination and view the entire conversation.
We do this so that we can see what may be broken in the conversation
or causing this residual affect of duplicate or I should say re-transmitted data,
duplicate acts, anything out of the ordinary.
Dropped connections can also be found as well as other issues
such as latency or bandwidth issues.
So as we were looking at in our Q&A section, you can pull a flow graph
very easily from Wireshark by going to the statistics menu.
And when you go to the statistics menu, you can select flow graph.
And you're going to have a couple of options here.
You can choose all packets, or you can choose
the displayed packets that you already filtered out
as an example. You may choose to only want to see
specifically what you already filtered or you can choose all.
And you can look at general flow which is all of them
or you can specifically look at TCP flow.
And you can choose the note address type.
For this example, we're going to look at the TCP flow.
And then the TCP flow, as we mentioned
you have source and destination IP's.
So you can very quickly and easily see what is speaking to what.
You'll see a lot of things here that don't really or necessarily amount to anything.
There are other IP's on your network but when we're looking specifically
for these communications, they may not be relevant to this capture or this graph.
And interestingly, as we mentioned before you can go for, down the graph
in time sequence format to look at between each packet what was taking place.
So from 192.168.1.13 to a target IP
we can see specifically 3 SYN's and then a reset.
So it's very important to understand as you're going through these captures
that you're very familiar with the TCP handshake
which we'll get to in a moment in another slide.
But this is what we're looking for and this is what's going to help us to see
issues on, on a network.
So as we saw here, it's a little bit bigger for your view
you can choose all packets or ones that you're just displaying at this time.
Or where we targeted a TCP from.
So essentially this, the flow graph itself is used to analyze traffic flow in general.
You can do TCP flow extraction which we just showed you.
This will allow you to see specifically the TCP handshake.
The TCP handshake is used to establish a connection.
This is how TCP operates. We covered this in one of the first 2 modules of the course.
Basically, a SYN, a SYN/ACK, an ACK is your basic handshake.
But there's other bits that you will see.
You will see a FIN or a reset.
Basically, normally if you want to just finish
or close out the connection, that would be normal.
But if you saw a flood of resets, that may not be normal.
That probably be a cause of an issue.
And as we mentioned before, when you use the flow graph
you will be able to see those in succession
based on the conversation that you're analyzing.
So that's how we try to put it all together here.
You're granulizing what you see based on source to destination.
You filter it down to the TCP flow if that's what you're looking for.
And then you look in time sequence to see
exactly each leg of the communication, what is taking place.
Is there a normal handshake, is there duplicate ACK's taking place?
Is it a constant re-transmission, it is a flood of resets?
And this may be something that's attributable to a network issue.
A host issue, the host can have a problem with I/O.
read/writes the disc, anything, it could be anything causing that
communication to stagnate or contend or have some kind of latency
which will allow it to continue because it's TCP and it will try to continuously resend
so that it can get the data there. However, you will be able to see that
it causes latency or performance issue when you do that and you will be able to use
the flow graph to isolate and find those issues.
So reviewing the questions in the forum, I got
2 excellent questions which I will review now.
The first question is people are hearing that Wireshark is more stable
on Linux or more reliable than the Windows version.
So, this is what I've found. I've found that I've used both
and to me both have been incredibly stable.
There's differences obviously in the core architecture
because one is installed on Linux and that way inter-operates with it
and the other one is installed on Windows.
I have found that in using both of these, they are both stable for me.
However, I keep my machines completely free
of anything else that I'm using, when I'm using them for analysis.
So I would assume that if you're using a typical Windows machine
and it's got a lot of bloatware on it and it's got a lot of stuff that you're using
other applications, it may clutter up the machine.
It's also an open source program, it's the GUI's made by the GIMP.
It could potentially be more stable on Linux
I find Linux system just to be more stable overall
because they are built on the bedrock of Unix but Windows has come a long way.
Since maybe the days of, when some of us
may have started using it when it was Windows 2.0, 3.0 or 3x,
Windows 4 groups where it's extremely unreliable all the way up in
through some NT versions. But I feel that both are very reliable.
The key take away here is that you keep your machines free and clear of other stuff,
especially if you're going to be using them for protocol network
and any other type of analysis work.
And we have another question here. This is a great question.
Is it possible to merge traffic flows in case of NAT?
So let's dissect that into 2 separate questions.
Yes, the last topic we'll cover is merging.
We will learn how to merge files into different systems.
Sometimes when you merge them, it'll just append it at the bottom,
there's certain things that you'll have to do to alter the merge.
But yes, there's a lot of reasons why you would want to merge them to analyze them.
And then the second half of the question is
because of traffic flows in case of NAT, or network address translation.
There's 2 different networks separated by a firewall
and there's net configured and
trying to figure out some basic information on the flow.
And you want to get that out of your capture.
So, typically what you would want to do is you'd want to do 2 captures.
You'd want to do one before and one after so that you have 2 captures.
And one of the things that you're going to have to do is figure out
from the NAT table what the translation is because
you can merge it all together and it's still not going to tell you -
it's not going to be able to, to translate anything for you
so if you're not sure what the IP addressing is or what it's translated to
you're going to have to figure that out from the NAT table
or, or x-late table what ever you're using.