Network Monitoring Tools! (CompTIA Linux+ Objective 1.5.3)

Hey, everybody. Shawn Powers here. It is 5:15

in the evening. I just finished work.

I have another appointment at 6:00, but it's been too long. So we're doing

this video, and we're going to do it right

now. Linux Plus, the next section.

Before we get started, though, I want to

take a minute to thank DJ Eric Santos, who is the newest top-tier Patreon

supporter of this channel, and of me, and

all the things I do, and I just cannot thank you enough. It--it just humbles

me that people are willing to spend

their actual money to support what I'm

doing here. So thank you. And top tier--it--

I had to actually look to see what all the benefits were because you are my

second top-tier supporter, and I didn't

even remember what all the benefits were.

So thank you, and I will get your welcome basket boxed up and sent out to

you. And, without further ado, let's get on to this Linux Plus objective 1.5.3.

Now, in this video, we're looking at network monitoring tools.

We're going to look at TCPdump and Wireshark

or TShark. And then these tools--we

looked at some of these tools before--netstat and ping. We're going to look

at traceroute and MTR, which is My Traceroute, a newer tool. But I do have

to mention, when we're talking about TCPdump and Wireshark, people tend to get

very, very opinionated--a lot like my dogs,

apparently, who are barking about something. You'll probably hear them

through this whole video. I can't seem to

get them to quiet down. But this video is

not like a--a training video on Wireshark.

There are entire courses devoted to

Wireshark and TCPdump. I'm just going to

show you what they do, how to do a couple of

very simple things with them so that we

can understand it as a tool to meet the requirements of the Linux Plus

objectives, but also just so you get a feel for what's possible. This is not

going to be a complete and thorough

course on TCPdump, Wireshark, TShark, that sort of a thing. This is just to

give you a feel for what you can do with some network monitoring tools.

Before we get into those particular tools, I want

to talk about some of the things that

we've already looked at and share some

similar properties. So, ping. You've seen

me use ping all the time and basically,

we just do, like, ping google.com. I mean, this is doing a lot of things.

It's doing a DNS lookup for the IP address, and then

it's sending out an ICMP packet to the

IP address that it finds. Now, that ICMP

packet goes there and then it responds

with another ICMP packet--an ACK reply. We're not going to go into the

nitty-gritty of networking. But basically,

this sends out an ICMP--which is not TCP, it is not UDP. It's ICMP, which is a

different type of traffic specifically for making connections work.

And just as a really brief rant: there are a lot

of security experts who believe that blocking ICMP at the firewall is really

wise, or not responding to ICMP traffic is a way to stay more secure.

Now, maybe there are some security reasons to

do that. I don't think that the security benefits it might provide are

worth breaking how the Internet is designed to work. ICMP is a type of

traffic that regulates how the Internet

works. It makes things work better.

So I'm personally not a fan of blocking ICMP

traffic like pings, but I don't want to get into an argument about it.

But just know--if something doesn't reply to

a ping, it's probably somebody who decided that blocking ICMP traffic is a

way to secure their place--their, you

know, their systems. And so you might have

to do something else, which we'll talk

about in a second. Anyway, this sends out

that ICMP traffic and then it responds

and tells you how long it took to

respond. And you can see this--it's very valuable information,

especially when you're doing network

troubleshooting. Now, one of the things

that ping does, and ICMP allows you to do, is do a timeout. Like, if it only

goes a certain number of hops--like, if it

takes more than this many hops, like going from this router to that router to

this router to that router--it will fail.

And you can use that knowledge of, like, how--like, fail after one, then fail

after two, then fail after three--to get information about every step

along the way. Specifically, that is what

traceroute is doing. So, let me clear the screen.

If we were to say traceroute google.com--

well, it gave us a whole bunch of stuff really quickly. Basically, what

it does is it sends out a series of ping

commands or ICMP packets, with specific

time-to-live--maybe, I don't think time-to-live is the proper

terminology, but maybe it is time-to-live--but only goes one hop.

And then, if it's not at its destination, it gets that information.

So basically, it pings every step along the

way and gives us information. Like, for

example, the first hop is my home pfSense router: 192.168.1.1.

Okay. So that's pretty cool.

Then the next hop is here. The next hop

is here. The next hop is here. And it will

continue to do that until you get to the

destination, which apparently was this IP address here for google.com.

Now, there are some times where you're not going to

get responses and you'll get things like

this, and that is where that particular

node or that hop along the way decided not to return ICMP traffic. It still

allows it to go through, but it doesn't reply. You can see it allows it to go

through because we got a response from

the next hop along the way. So if you see these, like, asterisk, asterisk,

asterisk--that just means that it didn't receive an ICMP reply at that hop.

Hopefully, that makes sense. But it has still forwarded those packets

on to the next destination because, again, we got the response from there.

So that is how traceroute finds the path.

It traces the path from one place to another and gives you information

along the way--how long it took to get to that particular hop from

where you are. So it's really useful information, but it's kind of old. Right?

It's an old-school way of doing things, and there is a new kid on the

block that gives us even more information in kind of a really nice way

as well. And if you remember the video we

did on top, and then I talked about htop

being a newer program that is probably the one you should use because

it's newer and better and faster and

more user-friendly and does more things--

this is the same sort of thing. MTR stands for My Traceroute, and it's

probably not installed by default on your distribution. So you'd have to, like,

install it with yum or with apt or

whatever your package management system

is. It's probably in your repositories, though.

And then you can use that in the place of--or in addition to--ping and

traceroute to get that same sort of information.

And the same binary works either GUI or on

the command line. So let me show you both

really quick. So we'll clear the screen, and now if we use mtr and we just--

without any flags--just give it a domain, google.com,

it will pop up a GUI window. If you're on

a desktop that has, you know, an X Windows--

or I'm sure Wayland as well--but with an

X server installed, it's going to pop up

a GUI window, and you'll see it keeps

updating in real time. Now, this is the traceroute information. Let me--yes--

scroll down here. Okay. These are the same

sort of things that we got when we used traceroute, but it allows us to see

things update. It just keeps sending packets, and then we get, like, the

standard deviation of how long it took.

These are in milliseconds. So, like, the last ping was 11

milliseconds here, 21 milliseconds, 7 milliseconds, 16 milliseconds.

And you can see along the way, like, if there's a

spot along the path where there's a

rough connection--oh, like, see there, we

just had some loss. There's some packet loss at that section along the

path from us to Google. And so this is a really great way to see if it's you or

if it's them. You know, like the site, is it down for everyone or just me? This is

a great way that you can test to see if there's a spot along the path that is

having issues. Like, apparently, this spectrum.com site is really having some

issues because we have packet loss at

that section of the journey, so to speak.

It doesn't necessarily mean that there's

a problem because they could just not be

replying because of load concerns. Like, if it's heavily loaded, it might just

drop packets instead of responding.

But if you have an issue and it's not working well, something like this

might show you a problem along the way. And this will work internally too.

Like, if you have a bunch of routers inside,

you can traceroute or MTR between them as long as it, you know, changes

subnets and that sort of thing. So, anyway,

this is MTR, but this is the GUI version,

and we can change things. We can pause it.

We can restart from scratch. Maybe unpause it. There we go. We can do all

sorts of things, change how quickly it

updates, but it also works on the command line if you do mtr -t.

We'll do it again. This is apparently what we're doing today--google.com.

And this will do the exact same thing, but in a text interface. So, like, if

you're SSH'd into a server, you're going to get this without the -t because

if it doesn't sense an X server, it's going to give you the text version.

But if you want to have it in your terminal

instead of a GUI pop-up, you can use -t to get the same information on a

terminal. And then, the keys up here, it

shows us there's, like, help and display and restart. We can do restart. I just

pressed r to restart, and it will do all that. Q should quit. Yeah.

And q quits. Okay. Now, do you remember when I talked about

some places stopping ICMP traffic?

Well, with MTR, you can do a really cool thing

where we can do mtr --udp google.com, and what this does--oh, I

didn't do -t, so it popped up another

window here. But what this is doing now is instead of using ICMP traffic, it is

sending out a UDP data packet, and we are getting information based

on UDP instead of ICMP. And we can do the same thing:

mtr --tcp google.com, and this is not using

ICMP traffic. Again, this is using TCP traffic. Yeah. Let's go over here.

I keep forgetting it's going to pop up a GUI window, but that's okay.

GUI windows are cool. And the same thing.

Rather than ICMP, right now it is using

TCP to check every hop along the way.

Alright. So, there's some really cool things

that you can do with it. But, basically, it is like a more advanced version of

traceroute. And now, one more non-controversial tool that I want to

show you--let's clear the screen--is

netstat. And I've shown you netstat before, and I even told you the flag

that I use 99.5% of the time. Do you

remember it? Netstat -tuna. Right? Netstat -tuna,

and this is going to show us the port information on our local computer.

So, netstat -tuna, just press that, and it'll show us all of the ports that

are open or in use on our local computer.

Okay? And that's important. I mean, this is

just testing our local computer, querying our local interfaces. Now, usually,

what I do--let me stretch this a little bit because that wrapped in an

awkward place. There we go. Yeah.

You can see the top ones. So this is going

to show us, like, if a daemon is listening, like, for example, on this computer,

apparently, there's an SSH server running

because it's listening on port 22 on 0.0.0.0, which means all interfaces, on

TCP version 4. It's listening on port 22, and it says it's listening right

there. So that's what we can do there.

But I thought for this video, specifically,

why don't we explain what each of those letters in tuna is for? So, let me

clear the screen. First of all, netstat

has to be spelled correctly. -t means

I want to know about TCP ports on the system. So the t is for TCP.

The u is for--can you guess? The u is for

UDP. -n. That means I want to know

about localhost. I want to know about

0.0.0.0. I want to know about, you know, if it's only listening on one of the IP

addresses, like 192.168.1.1. I want to know all of the network addresses

on the system. Tell me about all of them. And then, a is similar but slightly

different. a says, I want you to tell me about all interfaces. So n means all IP

addresses, like the localhost and every

IP address that might be assigned to the

system--including that special one, 0.0.0.0, which means all. a means every

interface. So eth0, eth1, eth2--which I know eth0 isn't really used anymore--

but, like, I always forget the, like, here, let's,

enp8s0. Basically, the a means I want you to tell

me about all of the interfaces on the system as well. And then, usually, like I

showed you before, usually I don't use that whole long thing. Usually, I will

grep the results. So, I'll do something like netstat -tuna, and then I will grep

for the word LISTEN, all in caps.

I guess, type the word grep. Grep for LISTEN, and it will show us just

the ports that are currently listening.

Meaning, like, a daemon that is listening

on the system. Like, if we had Apache installed, it would show, like, port 80

was here, and it would be in the LISTEN

state. So that's something I use netstat

for, and that covers everything except

the TCP dump, TShark, and Wireshark.

So let me quickly explain what they do.

And, basically, they cause people to get really opinionated.

What TCP dump and Wireshark are, both, are

packet capture tools. So they capture

packets from an interface, like a network interface on your computer.

Now, the important thing to note about any of

these tools, tcpdump or TShark (which is the text version of Wireshark),

Wireshark is a GUI program, is they can only capture packets that they see.

And what I mean by that is if you are on a network where

your computer is plugged into a switch, it's only going to be able to see

traffic that that switch port sees. So if

two computers on two separate ports are

talking to each other, your switch port is never going to see that traffic.

That's what switches do. Switches only

connect the traffic to where it needs to

go. A hub, on the other hand--a hub just

spews it everywhere, and whoever it's for can listen, but that's why they're

less efficient because a hub makes things very, very messy.

Everybody just screams all your information, and

then whoever needs it listens. But a

switch will connect two parties together,

and only those two are going to see each other. So that's why if you want to

capture packets for an entire network or

for something else, your switch might have, like, a mirror port, where, like,

your uplink port, you could mirror it on

another port, plug your computer into

there, and then listen, and it would hear all the traffic on this port

as well. So there are ways that you can get

stuff, but, also, you might have to SSH into a remote server and capture the

packets you want to see, bring them back

locally to examine them in Wireshark.

So when you capture packets, just realize the computer can only capture what it sees.

And with modern switching

technology, it doesn't see all the traffic in a network. That's just not how

networks work, except wireless networks.

Wireless networks are just hubs. For the

most part, you're going to have to use

sudo or root access to capture packets

just because you need access to the

interface, and usually only root has that.

There are ways to set it up using group

permissions and stuff, but, generally,

you're going to need root permissions to do a packet capture on an interface.

And so, the first two we're going to look at

are the older one, which is TCP dump.

It's been around forever. So I'm going to do

sudo tcpdump. Now, we can specify what

interface we want to listen on, but it'll

choose your default interface if you

don't specify it. So that's, you know, what

I'm going to do. Otherwise, we could do -I and tell it what specific

interface, but, again, I forget the names of the interfaces, like enpso75 blah,

blah, blah. Anyway, TCPdump will use your default network interface, and if

you just press enter, it will show all of the information that it sees on

the network. Again, just everything that

our local computer sees right here, but it's going to show a whole bunch of

traffic as it goes through the default

interface on my system. So I'm going to

hit Ctrl + C because that's just a lot of information, and it's not usually how

it's used. Usually, you'll capture something into a .pcap file, and that is

just a format that Wireshark can use to

look at it later on. And so, like I said, a lot of times, you'll SSH into a remote

server, do a packet capture, and then

bring that back. And that's why TCPdump is still often used. So we can say,

"I'm going to do that right now." I'll capture

some information using TCPdump.

So, let's say, sudo TCPdump, and I'm still going to use a default interface,

but we're going to say we're going to filter. So that's the

other thing that it can do. It can just get some traffic, rather than all of the

traffic everywhere. I'm going to get just traffic that's going to

my router, for example, like just traffic going to the router or from the

router. So I'll say TCPdump and then host 192.168.1.1, and then instead of just

spewing it on the screen, I want it to write the -w to, let's call it

dump.pcap. Alright? And that's going to save it into a .pcap file that we can

look at with Wireshark later. So when you

press enter, it's going to be listening.

It's dumping stuff in there. It's just going to keep going and keep going.

There are ways to set up, so it will only

capture for a certain amount of time.

It will only capture a certain number of

packets. You can explore the help page

for all those limitations. There are also lots of other filters you can use.

You can say, instead of just host, you can say host DST for just the

destination of 192.168.1.1, or just the source SRC of that, and it

will only capture packets whose source

is from there. And you can filter and run all

kinds of filters. You can even AND filters together. But when we're done,

I'm just going to do Ctrl + C. Okay.

And then ls -l * .pcap. And sure enough, there is our file.

It looks like we captured 47 kilobytes of

information. We'll look at that in just a

second, because looking at it, the best way to do that is with Wireshark.

It just really is. Okay? The other way we could

capture it, though, is with Wireshark

itself. The GUI tool can capture, but also TShark, which is the text version of

Wireshark, can capture without needing a

GUI interface. And they do very similar things as far as capturing packets.

Now T, and this is where people might get

controversial and be like, "No. No. No. It's so

much better. This is better. That's better. This is better. That's better."

They're both great. All three of them are great. There are slightly different

filters that you might be able to apply

with TShark, like, based on the internals of a packet. Like, if you're trying to

troubleshoot SIP information, you might be able to craft a filter in one that

works better than the other as far as like getting just SIP information from a

certain type of client or something.

Anyway, to do the same sort of thing with TShark, we do something like

sudo TShark, and then let's do a filter.

So in this case, to do a filter with TShark, it's -f and then the filter. And I am

going to do a filter of just ICMP traffic. Okay? And we'll just press enter.

And then what this should do is wait to look for ICMP traffic on the network.

It looks like it actually did find some. I'm not saving this to a file. I am just

letting this print on the screen. It looks like it is going to save a temp file for us in the temp folder,

but we're not going to look at that.

But we can write it to a file. But I

wanted to show you. Now, this is the same sort of thing we could do using

TCPdump, but we could do ping google.com. And now, when we ping, it's

going to capture or it's going to display all of those packets because it

matched the filter of ICMP traffic.

Does that make sense? So that's what actually

happened. It captured that. Again, I'm not capturing it to a file, but you

could do the same thing with TShark.

And then Wireshark is the GUI tool. So let's

open up Wireshark just to finish this

video off. And now remember, all of these

tools can do capture. So we could just start capturing packets. And in fact,

it'll just do that. It'll just start capturing packets, and we can look at them,

click stop, and then we can examine all of the packets that we have just

captured. And it just captured everything.

But it's cool because in

Wireshark, you can explore them at your

leisure without having to watch them scroll by. So look at this TCP

packet, for example. It will show all of the details of a packet. So if you're

having an issue, you can capture a packet

and you can capture some packets and

then search through to see, "Okay, here's where it's, you know, talking to this

server." So what's actually going on in

this conversation? And you can look at

the entire packet of information and see

what's going on, including the actual

data in the packet. So you can examine all sorts of stuff. Now if you're

thinking, "Whoa. If I can capture packets, that means I can see passwords."

Well, you can see login and passwords for protocols that are not encrypted.

So, like, traditional FTP or Telnet without

any encryption, yeah, you can see the actual text that's going through.

But for things like SSH, you can capture the

packets, but they're all encrypted. So all

you're going to see is the encrypted stuff. You're not actually going to see,

you're not going to find people's

passwords in there. Anyway, you can hear my dogs are excited again, but

what we could also do is open that file. Like, where's that file? Oh, you see I

have all sorts of stuff in there. I'm downloading some television shows.

But dump.pcap. This is the one that we had.

So I'm opening this. I'm going to continue without saving our captured

packets. But this is the information that

we captured using TCPdump. Remember, we

captured TCPdump, and our filter was

only stuff that was to or from the router 192.168.1.1.

And you'll see all of these packets that it captured are either has

a source or a destination of 192.168.1.1. 1.51 is the computer that we're on.

That's my big tuna machine. And it looks like

the bulk, if not all, of the we had one

that wasn't. Okay. Here was an ARP request.

This was ARP, but everything else

looks to be DNS. And so, almost everything else, oh, here's a broadcast,

an ARP broadcast. Looks like my Ubiquiti

something was looking for somebody who

knows who has the IP address of 1 or 192.168.1.1,

this Ubiquiti device is asking for that

because it knows that's the router that it needs to use to get out to the

Internet. But it does, the way that networking

works, it has to get the MAC address of

the computer with that IP address so it

knows how to talk to it. That's kind of

deep into the weeds with networking, but

that's really what we're looking at with Wireshark here is the nitty-gritty

packets that we can capture on our

system. So, yeah, like I said, this was not

an in-depth look at Wireshark, Tshark, TCPdump. Just know that it's for

capturing packets to examine individual packets for stuff. And usually, the

examination itself happens with the Wireshark utility, the GUI version.

TShark is, you can look at stuff using TShark.

It's not nearly as nice in my opinion. Usually, you just want to capture

a .pcap file and then bring that to a computer with a GUI interface and then

look at the captured packets with Wireshark so you can determine when

something is going wrong. But the important things to remember are it can

only capture the traffic that it sees.

So if you are trying to capture all the traffic from another computer, you

probably want to SSH to that computer to

do the capture, and then you can bring

that .pcap file back. Anyway, I hope that

was clear. Networking is so much fun.

And, again, there's so many courses, that we

could have started with just the topics

that we covered in this one. But this is

just how to use those tools and a little bit to make your life a little bit

easier and to pass that Linux Plus exam.

Anyway, learn everything. We have a

lot to learn in this video. Do what you

love. And most importantly, be kind. I will

see you in the next video and feel free

to join us on the Discord. There's a link down in the description.

There are a lot of people there who are super

smart, and we love to talk nerdy stuff.

So hope to see you there, and I will see you in

the next video. And it looks like I finished with about 12 minutes to spare,

so I might have a cup of coffee before

my next meeting. I mean, I guess I could edit. I'll start editing.