So again, as we talked about
what's important with Wireshark,
is understanding
the fundamentals of networking.
And where some of us
may be training to become
high level professionals or experts
or some of us may already be in that area,
understanding how to configure a device
is a little bit different than
actually troubleshooting
the data going to and from the device.
So, what's key to learning about
networking is not only how to configure,
how to design, but also how to troubleshoot.
So that's a lot of the design, run,
build elements of networking.
So, you're going to design it.
You're going to make sure that you
say, if I want resiliency
either I want them to be secure,
do I want redundancy,
do I want density?
What do I want, actually want
to produce and then
it has to be built or engineered.
So then we're going to go
through the process of
building all these components.
We're going to deploy them,
and we're going to test them.
Possibly lab them prior to
you know, make sure
that our theories and designs are accurate
and then we're going to deploy them.
And then there is run,
So that's the actual operations of
of position where
you'll likely be using Wireshark the most, right?
So, if you're in a network situation
where, you know, you get hired
or you're a consultant and
and you step into the role of handling operations,
you'll likely going to be
using troubleshooting tools
pretty much on a daily basis.
Now, Wireshark will likely not be your only tool.
You'll probably be using things as simplistic as
ping and trace route and basic logs all the way
to enterprise monitoring tools
that we discussed earlier
which some of the ones that are more specific
to data capture and analysis is
ones from Riverbed and
from NetScout, as an example.
So, just to highlight what
we've already discussed
as far as source to destination,
that concept still applies when you're talking
about other network hardware.
What we're really going to talk
about in this module is
specifically the security devices because
they really change your data a lot
and it makes it more difficult
to look at the data with Wireshark.
Either whether it's blocking it,
or it's changing it through net
or you can't actually use the,
or to use Wireshark to capture the data
because it's being blocked completely.
No matter that is,
that's going to be some of the things
that you encounter when using
Wireshark in this fashion.
So, some of the things that
Wireshark can do as of 1.8,
a lot of radical changes that we will talk about.
Some really good things like some simple
things, like you can annotate files all the way to -
you can actually build and use a
a firewall ACL rule within Wireshark.
It'll help you build that depending on what
data it is that you're trying to look at
as you can see from this screen shot.
So there's a lot of things that
you need to understand about using Wireshark
in this fashion because as
we have mentioned earlier
these firewall devices are going to
block by default. It's very restrictive,
it's likely to block the traffic.
unless you specifically ask the firewall to allow it.
It's going to have a, implicit
deny on pretty much anything.
There's fix up protocols that allow you
to do things in it's ACL's and there's all
kinds of tools within the firewall
but with Wireshark specifically,
there are some tools sets within it, as well.
So, what is an ACL?
An ACL is an access control list.
It's basically used to say,
I am going to either allow data to pass
or I'm going to deny it from passing.
There's many things that create ACL's.
Now, we're learning about Cisco at INE
at the highest layer, and obviously,
that's something that you would take
into account immediately.
You'd say, well, I can't get the data through
I'm going to check the Cisco router,
I'm going to look at the firewall.
It's likely an an ACL issue,
but there's a couple of different things.
Now, if we go back to our concept
from earlier that you're not looking at
when you're using Wireshark
to troubleshoot problems, you're not looking at
in a, in a, in a tube or at.
You're not looking at specifically at one point.
You are looking at everything holistically.
You're saying from the source to the destination,
what are all the things involved.
So, we talked about the tip of the arrow
you know, we say, oh the client.
Alright, so what's,
what could be wrong with the client?
The client could be performing horribly.
It could have, it could have malware on it.
There's so many things that can impact
the client - memory, disc space.
So when we talk about, you know,
traffic problems, we just got to remember that
it's not necessarily just
specifically, let say the router ACL.
We might have other things that
are blocking, so for example,
it may not be a Cisco router
or it may be a checkpoint firewall.
It may be, you know, a SideWinder firewall,
Palo Alto. It could be any particular thing
but they're also going to be using ACL's.
With Windows server,
you can use netsh to configure firewall rules.
There's the GUI.
You can configure firewall rules.
Those are technically ACL's that would
block traffic on a Window's client.
It could be blocking with the
Window's firewalls so you may be
trying to run a capture and can't figure out
why data is not traversing -
it could be as simple as looking at the client.
With Linux or Unix, IP tables, the same thing -
firewall, ACL's blocking the traffic
and many others.
So just remember,
when you're using Wireshark that
and you were dealing something
such as the firewall,
a firewall may not just be the device
that you're used to, like a Cisco PIX/ASA.
It may be something different.
It may be a checkpoint firewall.
It may be one of many
different flavors of firewalls.
It could be a router with a
simple set of ACL's.
It could be a client with a, a client firewall.
It could be a Linux or a Unix
system with a client firewall.
So just remember these concepts of
when you're troubleshooting with Wireshark
if you can't get the traffic
and you don't understand why,
there's many things from
source to destination
that could be blocking that traffic.
So, troubleshooting a network or
or, or trying to capture data to analyze it,
in this sense where you have a firewall
that may be the source of the problem
and or blocking your view of it,
it's very, very simple to understand.
If you're trying to capture and analyze
traffic from the router,
let's say, from the laptop computer
with Wireshark installed,
and you're not seeing
the traffic from the server,
the simplest answer could be - well,
in this instance there's likely
a firewall in between.
Maybe that's, that could be the
problem or it's blocking it.
Maybe I don't have Wireshark
on the right side of the firewall.
Maybe I need them on both sides.
Maybe I need to allow
the traffic through the firewall.
We need to remember,
if you're using Wireshark in a lab,
we could pretty much do
whatever it is that we want to do.
We can install things in a way where
you know, if we wanted to test
any theory if it's in a lab environment,
we can, you know, change the firewall rules.
We can, we can do pretty much
anything we want.
What's important to remember in production,
and likely, you're going to be using Wireshark
the most, there's 2 important concepts
to remember - one, you're using a protocol
and packet capture device
on a production network,
and therefore, you may not be allowed to.
One of the reasons is because Wireshark
is also used for security analysis.
So with the protocols we talked to already
with, let's say, this TCP/IP protocol
sweep version 4 allow the protocols involved
in within that sweep such as, let's say,
telnet, SNMP, and others.
They will send information in clear text,
non-encrypted so if you're not
doing extra encryption,
if you're sending this data in clear text
Wireshark can capture it.
So you may be called to troubleshoot
a problem with Wireshark configured on a
network and start capturing data that
in reality may expose a lot of
the things that are meant to be kept secret
on the network itself.
So just remember that when you're using
Wireshark, it is, it is also used primarily
as a security tool and you need to have
permission to use it specifically
on a production network.
Also as we're talking about before, the firewall
you may see data that's encrypted
and you may not be able to see it
and you could use Wireshark to,
to add the keys to decrypt it.
So that's one of the interesting
things about Wireshark.
It could be used in a security sense
that it could be -
you can reconstruct voice calls,
you can use it to capture data
that can be decrypted.
You can capture unencrypted data
that can be used to log in to devices.
You may see read and write strings,
private and public strings
from SNMP that you can capture
and now manipulate the device with.
So, just remember,
with Wireshark, that's there's a lot more that
you can do with it than just troubleshooting.
So simple firewall concepts
obviously, a firewall will block traffic.
This is tricky when you're trying
to troubleshoot with Wireshark
because if you're trying to see
for example, why a source cannot
communicate with the destination
and let's say, you don't have access
to the firewall and they're asking you
to solve that problem with Wireshark.
Ok, well, how are we actually going to do that?
Well, as we reflect back to the simple lab
where we had the source to the destination,
we had, let's say, a firewall in between
if you see that you're not able to traverse that
let's say, with RDP
but you able to ping through it,
it may give you the false impression that
the firewall is not the source of the issue. But
it may be blocking specific traffic that is required
for an application to function.
And why would that be an issue because
let's say, we're troubleshooting a
a new problem where they said
"You know just recently
something on the DMZ stopped working,
we don't understand."
You know, as being network professionals,
we, our brains would start working -
say, when was the last change on the firewall?
What, what could have possibly, you know,
made this happen, as in a new deployment.
We know that with
the complexity of what it is that we do,
we try to be masterful and perfect everytime, but
we could fat finger something and
we can knock something off the network.
But in regards to that if it's blocking the traffic
and you do not have information back
from the firewall that anything changed,
or there's any specific
problems that they can see,
a simple solution would be
to set up Wireshark
on both sides of the firewall
and take a look at the source
to destination traffic in 2 captures.
If you see that you're sending data 2
and you're not receiving on the other side
then it could be implied that the
firewall is actually blocking the traffic.
We will learn in future modules
how do you time that, right?
So, you would want to
actually look at timestamps
from one capture to the other.
to see exactly when things are
going from one side to the other.
You can look at the handshakes.
There's lots of ways to figure that out.
But a very simple capture would be
the time it capture on both ends.
Take a look -
is the source getting to the destination?
Yes or no? And if not,
then likely it's blocking that traffic.
Firewall also translates traffic.
It will do that through
Network Address Translation.
It also does it with Port Address Translation.
And when it does that
it will send the data,
the source will send the data.
It will hit the NAT device,
maybe a router, maybe a firewall.
And that device will then send the data
as it appears from a different IP address, and
it can do that from a pool.
And the reason it does that is it generally hides
the privately addressed network
from the outside world.
It would translate a larger set of addresses
to a smaller subset of public addresses.
But regardless, it's something that you need
to understand because when you're capturing
the data with Wireshark
if you did not know it was NATting
and, and you weren't capturing specifically
and looking for specifically that data,
it may confuse you. Here's an example.
Let's say, you're capturing
a source to destination problem where
you know that the source address is,
you know, 192.168.1.10
and the destination is 10.1.1.20.
You're not going to necessarily as
you're troubleshooting the segments through
see that all the way through.
You're going to see different things happening.
As we talked about earlier in the modules,
these devices change the data from hop to hop,
and if you're not, if you do not understand
what's happening from hop to hop,
you may not what you're looking at or looking for.
And again, as we talked about earlier,
ports and IP addresses, firewalls will generally
block or, or translate the data by IP
and or block the port.
So just a simple example of a network firewall,
just want to make you aware that
again, we're very, we try to learn things very
in advanced forms and get to expert levels and
what ends up happening sometimes is it gets
your brain thinking at the highest level.
And sometimes it happens to me and I have
to actually stop myself and think
simplistically in a way where -
"Hold on a second,
did I really look at the client close enough"?
Simple things, you know.
And sometimes, you wind up spending,
at least it happened to people I know,
as well as myself,
very, very smart people -
they start looking very deeply into things
and it's something they missed
because it's something very simple.
So as a reminder, a network firewall could be
something as simple as the client itself.
It can have a role configured
and it may be throwing your whole capture off
for not allowing to do
some specific troubleshooting.
So just a reminder to be a aware
that those things do exist
and it's very important
to be mindful of them.
Alright, some other hardware - hubs.
So, hubs are something we've almost
completely eradicated from our networks
with the inception of switching
and data traveling a gigabit
and now at 10 gigabit speeds.
Hubs are just dinosaurs,
they're things of the past.
But, it's interesting because still to this day,
I find hubs available.
Now, not only they're available,
but I find them available to people
who try to expand their networks using them.
And why, and most times it's not from the
the people who actually run the network.
So if you're, if you're locking down your networks
and you're only allowing the ports open,
if you're using port security as an example,
and you're blocking everything that's not open,
then these are less likely to be used. But
if you're not using port security or using a device
that doesn't have that feature
you may be in for a surprise.
You may go into a, let say,
conference room where they needed
to host 30 people and they didn't have
as an example, wireless connection.
They may all jack in from a hub
that they actually, you know, purchased from
let's say, Best Buy and they connect
and configure.
So these things do exist, they're out there,
you need to be mindful of them.
Hubs are actually dangerous
because you can create a gigantic
loop on your network and
I've see hubs completely blowup,
take down an enterprise network.
So that's another reason why you should
lock down your unused ports.
But, just be aware that they do exist.
But as the Wireshark expert,
the network analyst,
the person who's doing protocol analysis
a hub is a quick way for you to
quickly span out a section of a network.
So if you understand networks
and you do not create a loop,
and you know how to masterfully use the hub,
you can quickly look between 2
2, a source and a destination
and figure things out by hubbing out
so they are useful in that matter.
They create a larger domain
and they will allow you to
look at traffic traversing from a group of host.
But remember, it may confuse things,
it may be dangerous, so just make sure
that if you do use it, you're careful.
Again, load balancers, as we already discussed,
the use of virtual IP.
There may be one or many devices
behind it as standby's and
this is for network resiliency.
You want to be very careful, or should say,
you should be very mindful of their existence
because if you're troubleshooting problem
from host to a gateway, you may not realize
that the gateway is multiple gateways.
So, just remember that it's a virtual IP or VIP,
commonly called the VIP that may be
in the path from source to destination.
And also inspection units, such as IPS,
IDS, moreso IPS today -
with the IPS modules that you could put in
too many ASA firewall. There's a lot of devices
that also inspect the traffic, a lot like sniffer.
They look for heuristics.
They, they monitor the traffic for anomalies.
So these, these do the same function of sniffing
Nessus as an open source is one,
like Wireshark is an open source tool.
Just beware that they are in a path
so when you troubleshoot with Wireshark,
there may be another thing in the hop.
And all these devices,
what's important about them with Wireshark is
when you capture the data, again,
the mantra over these next 3 days is
you have to look at this as very holistically,
high-level, wide.
Remember that you're looking at the
forest through the trees.
You're trying to capture the whole entire
essence of what's going on on the segment,
the enterprise network, the area in which you are
using Wireshark to troubleshoot the problem.
The very important - that you look at it
in a way where you're aware of these devices.
Hopefully, when you go in to do this,
it's either the network that you work on
so you'll have, let's say, a blueprint or some
Visio documentation for it.
If it's a customer or client,
maybe they do, hopefully they do.
Maybe they do some network discoveries
to find these devices or
talk to the network manager.
Likely they know, if it's not documented
if it's not documented, what's in the path -
then maybe draw out a quick document,
the segment or segments in which
you're going to be troubleshooting.
Where you will playing, placing Wireshark
and where these other devices, hubs, switches,
routers, firewalls, load balancers,
NAT devices, proxy servers, all these
things, what will be in the path
and how it will change the interpreted data.
And then specifically,
the protocol analysis that you're going to do
when you're capturing how these,
these devices actually impact your data.
If it's NAtting, it's going to change the address.
If it's routing,
it's going to change the MAC address.
If it's load balancing, it may be a VIP.
So, just remember,
that these devices are very specific
to protocol and traffic analysis,
when you're doing either,
to make sure that you're aware of them
Tip is to again look for documentation and or
make a landscape document, document
of what area you'll be troubleshooting,
so you're aware, do some network discovery
and, and then use Wireshark to start
capturing data and, and troubleshooting.