Let's have another look at the diagnostic possibilities of Wireshark.
The point is to detect a situation when someone tries to send a large amount of data well try out the
data visualization capabilities of Wireshark to evaluate the contents of the file.
Let's try to visualize them first.
We look at the IO graphs from the statistics menu the image shown below is a graphical representation
of units called packet Tich.
The unit is not really intuitive.
We can change it into bytes Tich.
Now we see at what speed data is transmitted at a given point in time we see how the speed with which
anyone sent or received data changed over time.
It's presented as a summary
looking at the statistics.
We can notice that one of the computers who tried to establish a connection was identified by the address
ten point zero point five two point one six four
this information can be included in the graph.
It turns out that we can visualize a variety of information on the graph
after we've created a red graph representing a new rule.
We can change the graph style to impulses.
We can make the graphs overlapped based on the filters previously created in Wireshark.
If we look at the example again you should notice that the client downloaded data from two different
servers and in one case the bandwidth was small but in the other much bigger.
In this example we're focusing on data visualization in Wireshark.
Let's see another problem namely the case before what happens if wireshark is not able to properly interpret
the data examining the above capture file you'd conclude that this is a net BIOS over TCAP IP session
looking closely at the data presented by Wireshark.
It turns out that the program does not interpret the data as SMB.
It shows raw data.
This is an example of a situation in which someone uses a protocol that utilizes the TCAP transport
that wireshark is not familiar with or someone has changed the destination port and wireshark decodes
the wrong data.
What should we do in this case.
First we'll try to decode it.
If you suspect what could really have happened.
Select any packet with the right mouse button and choose decode as
from the list you can choose the protocol that you suspect was used.
Let's try to decode data as T.P..
After playing the decoder the situation looks better right away.
We have a correct interpretation.
We can now track the selected packet by using the follow TCAP stream from the right mouse button click
menu
it turned out that it was actually a TCAP session.
We can see who connected to which server and what folders they browse through if in the main wireshark
window under the subheading data.
There's not information about the protocol.
Try decoding it as a different protocol this operation almost always succeeds.
Shortly we'll look at another capture file.
It'll be the record of a process which we mentioned in one of the earlier lectures we talked about how
you can make a switch act like a hub.
We said that this can be done by sending a large number of IP addresses associated with a random mac
address.
This is the situation you see on the screen.
Please note how quickly the packets were sent and how many hosts were apparently involved in the communication.
Here we see only the x y and packets of the TZP protocol.
There are no data in these packets so it's not an unusual thing.
Please note that the windows size field value is set at 512.
No operating system uses such a small TCAP initial window size the packet gives no reason to set the
window size smaller than the default one because we haven't received any data yet.
A situation where there is only Syn packets and the window size 5:12 seems readily suspicious.
So really this is a signature of Mac off a program used for switch flooding.
If you make recoloring rule for the window size value 512.
This is the first part you should have in your filter.
At this point we can get some false positives from time to time.
Computers can inform you about such window sizes.
We're halfway to solution.
We should now move the coloring rule to the top
so far.
The rule works as it should.
We'll add just one more detail to it.
That should be a sin packet.
This is the final rule which we would like to add to our existing coloring rules.
Thus we have worked out the signature of backoff.
If we manage to do this with one program used for automated attacks on operating systems and computer
networks will probably manage with others as well.
Let's try it out on another demonstration file will open the file named Nessus the file name suggests
what we'll be looking for.
Here we mostly want to get to know another wireshark functionality press control plus help to open the
Find window.
We can now search for something by display filters that is all rules that could be entered into the
program by hexadecimal values are displayed in the lowest window of the program or by strings typing
any string of characters these criteria will be used to search the packet's list.
The details pain or the bytes pain.
Let's see what happens if you type the expression Nessus.
We found the program which as we mentioned in the previous lectures tries to be neither discrete nor
stealthy Messis is a program that detects certain errors and vulnerabilities in the configuration of
network services.
The program probes remote services
in packets simply Nessus we find program names.
We could create another color and rule or another filter that will show whether someone in the company
uses Ness's.