Until now the basic statistics have been sufficient.
Now let's examine the application letter.
Let's open the file with the captured telnet session.
This is a protocol that's very easy to interpret.
It's easy for us humans to read what the client sent to the server and how the server responded.
We can see that two computers exchange communication the first three packets visible were responsible
for a proper establishment of the CCP session or a three way handshake.
Below you can see that the tone that was turned on however it's difficult to tell how the communication
proceeded.
We won't analyze a packet after packet
clicking on any of the telnet packets with the right mouse button open in the context menu with the
follow stream option.
Follow TCAP stream follow UDP stream follow as the cell Stream we will choose.
Follow TCAP string.
It allows us to see the whole of communication unpacked from the headers of the lower layer packets.
We now see the raw data.
We can see the data that the client contributed or how the server responded.
In our case we see the original conversation the user has logged in with telnet in the fourth row from
the top.
Everything is doubled.
This means that the program captured echo after the user pressed a keyboard button a character appeared
on the screen.
The server sent back the echo of the buttons the user pressed after typing the password and logging
in.
Please note that there is no echos of the password some information on the remote server was displayed
in the client logged out followed TCAP stream allows you to trace this kind of communication.
If we do use this feature earlier with the TTP server it would have pointed to a communication between
the browser and the Web site.
Now let's look at something more related to security.
We open another capture file it presents a situation you would not ever want to have in your network.
Just looking at the main window you can more or less get what's going on.
First you can see the TCAP session establishment.
Then there's an attempt to log in to the FCP server as an administrator with a random password by clicking
on the selected packet with the right mouse button.
We can choose follow a TCAP stream.
We see that someone tried to guess the administrators password.
We would like wireshark to highlight issues like this one at once to do this.
You should first prepare your own profile.
It can be called for example SEC like in security.
From now on will perform every action in the new profile
will now create coloring rules or filtering rules for specific packets.
The point of that is to enable you to choose a preconfigured profile management security etc. Whenever
you turn wireshark on we're now checking on the T-P protocol Let's see how the user tried to guess the
password.
Remember that any piece of data can be used as a filter.
If we applied the filter the request command equals equals user we would be shown only logging requests
to the FTB server.
If we only wanted to see the failed attempts we should select the password not accepted packet.
Click on it with the right mouse button and choose the options apply as filter or selected.
Let's now create a coloring rule.
We would like to color a situation in which the password was not accepted.
Right mouse key colorize with filter new coloring rule
we will call the new rule.
Bad FTB pass.
Now choose the background color.
I suggest you choose a really annoying one.
There are already a few coloring rules in Wireshark because the rules are applied in sequence.
It's more important that our rule is first.
From now on we'll be able to spot the packets we would never like to see in the file.
In this way we've created our own intrusion detection system.
Let's look at the attempt to guess the password to another service.
Will open another capture file.
The protocol used to communicate with the Microsoft as Cuil servers is the tedious tabular data stream
protocol
as you can see.
Wireshark correctly interprets the data of this protocol.
Not only did it show that such a protocol was used but it also properly interpreted its header wireshark
correctly interprets a large set of protocols.
Virtually all of them.
If it doesn't manage to do so it means that someone uses a really strange protocol or an unusual port
and that you'll have to manually decode the data usually all data are properly interpreted by wireshark
will filter data according to the TADS protocol to see if there are any troubling messages.
We see that someone has tried to use the server name SA to connect to the computer named s y d as 21
ESX I with a server with a visible IP address and listening on port 14:30 3
filtering the data sent by the server according to IP addresses would be faster but it would give the
same result we have the error message reported by the Cuil server which is understandable even for people
unfamiliar with databases.
It contains information that as Cuil server reports an error when someone tries to log in with the wrong
password the error message number is 1 8 4 5 6.
We can use the error number as a filter or as a coloring rule.
We can check how many times someone tried to log into the server.
We would like to know how frequently these attempts were in the table above.
We can see the total time since beginning of capture.
You can change this to the time elapsed since the last capture.
Now it's easier for us to analyze the data.
We can see that someone sitting at a computer with the IP address displayed source tried to log into
the bascule server more often than every thirty nine milliseconds.
Either this is a person who types really fast or uses a brute force program to acquire unauthorized
access to the server.