1
00:00:00,000 --> 00:00:18,120
Hey guys and welcome back. So within this skill we're going to continue down this path

2
00:00:18,120 --> 00:00:24,320
of networking based information and we will be using some tools and exploring some tools

3
00:00:24,320 --> 00:00:29,320
to test for basic connectivity in our network. We will also test how we can do something

4
00:00:29,320 --> 00:00:34,320
called port scanning. We'll get to see what this means and how to do this and we will

5
00:00:34,320 --> 00:00:41,640
also learn how we can track and monitor very particular network information. So we do have

6
00:00:41,640 --> 00:00:46,600
a lot of interesting stuff to get to within this skill. The very first thing which I want

7
00:00:46,600 --> 00:00:52,640
to talk to you about is the concept of testing connectivity. So let's roll up our sleeves

8
00:00:52,640 --> 00:00:58,560
and dig right in then shall we? So what I'll do here is clear my screen and the command

9
00:00:58,560 --> 00:01:03,600
the primary command should I say that I want to describe to you is the PIN command. Now

10
00:01:03,600 --> 00:01:10,240
the PIN command is one of the most well used tools in all of IT at least for systems administrators

11
00:01:10,240 --> 00:01:15,400
and network engineers. This is a tool that we can use to test that devices maybe say

12
00:01:15,400 --> 00:01:21,200
device one here and device two connected via let's say a switch. This tool allows us to

13
00:01:21,200 --> 00:01:26,840
be able to test that device one can talk to device two and vice versa. Now there are some

14
00:01:26,880 --> 00:01:32,320
limitations to the diagnostics that you get from a PIN command. The first one being is

15
00:01:32,320 --> 00:01:38,560
that PIN actually utilizes the protocol called ICMP. This is the Internet control message

16
00:01:38,560 --> 00:01:45,200
protocol. Now as it transpires some devices may just happen to block this particular protocol.

17
00:01:45,200 --> 00:01:49,920
So if you happen to use the PIN command to like I say try to test from device one to

18
00:01:49,920 --> 00:01:55,800
device two maybe device two actually could be reached over something like say HTTP if

19
00:01:55,840 --> 00:02:00,439
it happened to be serving up web requests but maybe for whatever reason on its firewall

20
00:02:00,439 --> 00:02:06,799
it happens to be blocking ICMP. So you may actually get a result that is inaccurate.

21
00:02:06,799 --> 00:02:14,039
IE the result may be that you cannot reach device two via the PIN command and you erroneously

22
00:02:14,039 --> 00:02:18,960
assume that therefore it cannot be reached at all. So really do not look at the PIN command

23
00:02:18,960 --> 00:02:24,000
as an absolute holistic solution that's going to tell you absolutely everything about connectivity.

24
00:02:24,439 --> 00:02:29,120
It's just one of the tools that we have in our tool belt and one of the first tools that we would

25
00:02:29,120 --> 00:02:35,039
use as a go to because it's very simple to use to test out this basic connectivity. Now when I

26
00:02:35,039 --> 00:02:39,960
happen to describe the PIN command there are a few things that I like to talk about first just

27
00:02:39,960 --> 00:02:45,000
because I do believe it's so important to be able to correctly use the tool. We do have to understand

28
00:02:45,000 --> 00:02:49,759
the output that the tool actually gives us. Now one of the things that we want to understand is

29
00:02:50,399 --> 00:02:55,840
the sequence number. So what actually is going to happen is that when we use ICMP we're going to

30
00:02:55,840 --> 00:03:02,399
send what are called echo requests. Now these are just little ICMP packets that we would send to

31
00:03:02,399 --> 00:03:07,840
our target device again so we have device number one here device number two. We could send let's

32
00:03:07,840 --> 00:03:16,000
maybe say five ICMP messages one two three four five. Now the first one we sent would have the

33
00:03:16,080 --> 00:03:21,039
sequence number one the next one would have the sequence number two the next three the next four

34
00:03:21,039 --> 00:03:26,719
the next five incrementing as we send them. So what might happen sometimes if there happens to be

35
00:03:26,719 --> 00:03:32,800
maybe some type of misconfiguration you may actually be able to get a reply from the first

36
00:03:32,800 --> 00:03:37,280
packet but maybe not the second and then you get a reply again from the third packet but not the

37
00:03:37,280 --> 00:03:43,120
fourth. All of these data points provide us information that can ultimately uncover what is

38
00:03:43,120 --> 00:03:47,840
potentially the problem with our network why we're not getting a consistent connection. So like

39
00:03:47,840 --> 00:03:53,360
I say the sequence number very very important to understand and the other concept that is really

40
00:03:53,360 --> 00:03:59,200
really vital to understand how to use the pin command is the TTL value. Now if you do not know

41
00:03:59,200 --> 00:04:06,000
what a TTL value is let me just refresh your memory or explain it from the get go. This is the time

42
00:04:06,080 --> 00:04:13,199
to live value. Now what this means is that a packet has a finite amount of what we would call

43
00:04:13,759 --> 00:04:18,639
hops that it can traverse throughout a network. So let me just describe to you what is going on

44
00:04:18,639 --> 00:04:25,120
here. So let's say we have device one, device two, device three and device four. So let's just

45
00:04:25,120 --> 00:04:32,240
connect these up to one two three four. So let's say device number one has the IP address of one

46
00:04:32,240 --> 00:04:38,400
dot one dot one dot one and device four has the IP address of four dot four dot four dot four. So

47
00:04:38,400 --> 00:04:44,720
device one we go on to its terminal we issue the pin command and we try to ping four dot four

48
00:04:44,720 --> 00:04:51,600
dot four dot four. Now hopefully we would get an echo reply to our echo request indicating to us

49
00:04:51,600 --> 00:04:57,840
that the device is reachable and we are sufficiently connecting to it. Now what if there was a

50
00:04:57,839 --> 00:05:04,479
misconfiguration. So we send this packet to device number two which is on the path towards device

51
00:05:04,479 --> 00:05:09,839
number four. This packet would be likely handled by something called a routing protocol. We don't

52
00:05:09,839 --> 00:05:14,639
actually have to understand the details of such a thing but just as a high level overview that is

53
00:05:14,639 --> 00:05:22,159
how routers can learn how to send what packets what direction. So R1 would send it to R2 and R2

54
00:05:22,159 --> 00:05:27,359
would know to send it out of this interface here if it was correctly configured. But like I say

55
00:05:27,439 --> 00:05:33,920
let's imagine there was a misconfiguration on device R2 and instead R2 sent it the wrong

56
00:05:33,920 --> 00:05:42,240
direction down to R3. Now R3 gets the packet sees its testing for R4 and R3 says hey I know how to

57
00:05:42,240 --> 00:05:49,199
get to R4 I want to go this direction so the packet gets bounced back to R2 but R2 misconfigures

58
00:05:49,199 --> 00:05:56,879
sends it back down and R3 sends it back up and down up and down on and on and on and on. What we

59
00:05:56,879 --> 00:06:02,879
ultimately have here is a routing loop. The packet is just bouncing back and forth and back and forth

60
00:06:02,879 --> 00:06:08,480
and all we're doing is we're not actually going anywhere we're not getting our packet to its target

61
00:06:08,480 --> 00:06:15,120
destination instead we're just bogging down this link with effectively useless traffic. So what would

62
00:06:15,120 --> 00:06:21,680
happen is we would want to have some type of way to terminate this behavior in the event of a loop

63
00:06:21,680 --> 00:06:27,519
IE. We could tolerate this for a little bit of time but we could not tolerate this forever and

64
00:06:27,519 --> 00:06:32,480
ever and ever. In fact we couldn't even tolerate it for a very short space of time we do not want

65
00:06:32,480 --> 00:06:39,280
to have unnecessary congestion on the wire. So think about this what if and I'll simplify this a

66
00:06:39,280 --> 00:06:47,280
little bit we gave it a TTL value of 10. What I'm saying is when I send this message from R1 going to

67
00:06:47,359 --> 00:06:54,639
R4 if we do not reach our destination within 10 stops the packet should just die a death and it

68
00:06:54,639 --> 00:07:01,679
should no longer be transmitted. So let's say we send it to R2, R2 receives it and what R2 will do

69
00:07:01,679 --> 00:07:07,439
it will decrement that number so it'll say okay I'm minus one off it the new TTL is nine but like

70
00:07:07,439 --> 00:07:14,879
I say R2 is misconfigured so R2 sends it the wrong way and it sends it to R3. R3 receives

71
00:07:14,879 --> 00:07:21,920
decrements it by one the value goes to eight that is the new TTL value and R3 tries to send it back

72
00:07:21,920 --> 00:07:28,719
northbound towards R2. R2 receives decrements goes to seven and again like I say this behavior just

73
00:07:28,719 --> 00:07:35,439
keeps going on and on but the difference is is at this time every time this happens every hop

74
00:07:35,439 --> 00:07:42,560
the TTL value is coming down now when that TTL value eventually reaches zero the packet is just

75
00:07:42,560 --> 00:07:49,360
going to die a death so instead of just having this link needlessly congested with this packet

76
00:07:49,360 --> 00:07:55,199
bouncing from wall to wall to wall to wall so to speak instead the network will be cleared up and

77
00:07:55,199 --> 00:08:02,319
we would just see from the output of our ping packets that our destination was unreachable.

78
00:08:02,319 --> 00:08:07,600
Now this is an output that you will see via the ping command if you can't reach your particular

79
00:08:07,680 --> 00:08:13,520
destination so this information here receiving this destination unreachable would communicate to us

80
00:08:13,520 --> 00:08:19,600
some type of networking error so the TTL doesn't actually fix the error for us we still have the

81
00:08:19,600 --> 00:08:25,600
problem of the misconfigured R2 within the network but the problem is is that the TTL is protecting

82
00:08:25,600 --> 00:08:30,400
us from unnecessarily congesting the network while we're trying to figure that problem out.

83
00:08:30,400 --> 00:08:35,279
Now when we happen to get this message of a destination unreachable it can tell us many

84
00:08:35,279 --> 00:08:41,120
different things it can say to us that maybe the local network has no routes to the remote

85
00:08:41,120 --> 00:08:47,120
destination or it can tell us that one of the devices we pass this to has no routes to the

86
00:08:47,120 --> 00:08:53,679
destination so maybe we have our laptop here and we connect to our router which connects to another

87
00:08:53,679 --> 00:08:58,079
router which connects to another router which connects to another router and let's say this is

88
00:08:58,080 --> 00:09:05,600
our destination right here if we happen to send our packets maybe this router is configured okay

89
00:09:05,600 --> 00:09:12,800
however once we get to this device here perhaps this is misconfigured and this no longer has a

90
00:09:12,800 --> 00:09:18,400
route to this destination it's at this point this router would ultimately send back to us this

91
00:09:18,400 --> 00:09:24,400
destination unreachable and we could take further measures trying to break down what exactly has

92
00:09:24,480 --> 00:09:29,919
happened so what I will do here as I will say ip adder and I can actually see my own ip address

93
00:09:29,919 --> 00:09:38,319
right here 192 168 0.65 if I just wanted to test that this ip address was up and running and that

94
00:09:38,319 --> 00:09:47,279
the interface was up and running I would say ping 192 168 0.65 now if I hit enter here this is just

95
00:09:47,279 --> 00:09:52,000
going to continually ping and ping and ping and ping and ping and ping what I'll have to do here is

96
00:09:52,000 --> 00:09:57,120
I'll have to stop this so I'll say control z now we can see here some of the information which I

97
00:09:57,120 --> 00:10:04,320
talked about right here we can see the destination we pinged we can see the size of the packet that's

98
00:10:04,320 --> 00:10:11,120
64 bytes we can see the icmp sequence number like I say this is the first one we sent the second one

99
00:10:11,120 --> 00:10:18,320
the third one we can also see the time it took for this ping and we can see this ttl value and we can

100
00:10:18,320 --> 00:10:26,160
see here the value is 64 64 being a very common ttl value depending on the application you're using

101
00:10:26,160 --> 00:10:34,240
some happen to use 128 some use 64 it really just does depend but straight away we can infer from this

102
00:10:34,240 --> 00:10:40,720
output here that we absolutely have connectivity with this ip address which is unsurprising we have

103
00:10:40,720 --> 00:10:47,280
our interface and the upstates the ip address is configured clearly so this is no surprise at all

104
00:10:47,279 --> 00:10:55,839
now if I happen to say ip root show I can see my default gateway of 192 1680.1 if I wanted to test

105
00:10:55,839 --> 00:11:01,360
that I could reach my default gateway well I could just use the same command I could say ping 192

106
00:11:01,360 --> 00:11:10,319
1680.1 and once again we can see the output of this command now what if I wanted to ping a

107
00:11:10,319 --> 00:11:15,839
remote network so I actually have connectivity to the internet what I will do is I will ping

108
00:11:15,840 --> 00:11:23,840
the ip address for google or google's dns server should I say so I'll ping 8.8.8.8 if I hit enter

109
00:11:23,840 --> 00:11:29,920
we can see the output coming back now as it transpires the ttl is a little bit larger that is

110
00:11:29,920 --> 00:11:34,879
because we're not actually pinging within a remote network the value may start off at a higher value

111
00:11:34,879 --> 00:11:41,759
which it has I'm assuming that the value happened to be 128 and it has been decremented every single

112
00:11:41,759 --> 00:11:47,840
time it's passing through a router so now we're seeing a value this time of 114 now if I tried to

113
00:11:47,840 --> 00:11:53,039
ping an address on my local network for example that doesn't actually exist we should see some

114
00:11:53,039 --> 00:11:58,639
information here to check this out so if I do 192 1680.0 this would mean that I'm pinging within my

115
00:11:58,639 --> 00:12:03,679
own network but I'll ping a host address which is not configured so there's no one on my network

116
00:12:03,679 --> 00:12:10,399
with this ip address of .24 if I hit enter now check this out we're getting destination host

117
00:12:10,399 --> 00:12:16,959
unreachable simply put there is no way to reach this host because this host does not exist now

118
00:12:16,959 --> 00:12:22,319
one thing they actually can do with the ping command is we can actually control the amount of

119
00:12:22,319 --> 00:12:28,959
pings we want to send as well as other things like the interval between each ping you'll notice

120
00:12:28,959 --> 00:12:34,319
that when I happen to send a ping say for example to my default gateway the actual interval as they

121
00:12:34,319 --> 00:12:39,679
come through is one second apiece I'll just stop this if I wanted to send them in quicker succession

122
00:12:39,759 --> 00:12:44,959
for example I could change this interval so if we go into the man page and say man ping we can see

123
00:12:44,959 --> 00:12:50,959
these different options we can do things like use an ipv6 only we can use an audible ping which

124
00:12:50,959 --> 00:12:57,039
will actually give you the sound of the ping we can specify the count this is how many echo requests

125
00:12:57,039 --> 00:13:02,479
we should send we can do dash d to print a particular timestamp we can control the interval as you

126
00:13:02,479 --> 00:13:07,199
can see here let me just scroll up one thing to note here that I always like to point out

127
00:13:07,200 --> 00:13:13,120
is that be careful when you're trying to have the interval very very short if you try to have

128
00:13:13,120 --> 00:13:19,759
an interval shorter than 0.2 seconds you must have super user privileges the reason for this is that

129
00:13:19,759 --> 00:13:25,920
you can actually overwhelm a system if you happen to be sending a whole bunch of pings maybe say

130
00:13:25,920 --> 00:13:32,240
50 milliseconds apart it just can become overwhelming we can also specify the source interface we want

131
00:13:32,240 --> 00:13:37,919
to be pinging from and we have a whole bunch of other options things like being able to change

132
00:13:37,919 --> 00:13:45,840
information relating to the quality of service now similarly we can also control the ttl value

133
00:13:45,840 --> 00:13:51,200
so as opposed to having that default value of maybe say 64 we can actually toggle that value

134
00:13:51,200 --> 00:13:57,519
and specify it ourselves so let's actually try some of these commands if I say ping and I say dash

135
00:13:57,519 --> 00:14:06,720
c 3 and I do 192 1680.1 and hit enter once this pings out we do 123 we can see here

136
00:14:06,720 --> 00:14:12,480
that the ping actually ends we do not have to interrupt it manually and we get this nice little

137
00:14:12,480 --> 00:14:18,720
summary of statistics at the end we transmitted three packets three were received we had a 0%

138
00:14:18,720 --> 00:14:25,120
packet loss that is very good we get the average time and we get the round trip time average now

139
00:14:25,120 --> 00:14:30,960
if I wanted to maybe send more packets I could say send 20 packets okay so I could

140
00:14:30,960 --> 00:14:36,320
hit enter but of course this would take 20 whole seconds to fully complete so let me just stop

141
00:14:36,320 --> 00:14:45,039
this here and I could say let's speed up the interval so I'll say dash I and I will send this at 0.2

142
00:14:45,039 --> 00:14:50,799
seconds so 200 milliseconds so when I hit enter now you'll notice the ping command are coming

143
00:14:50,799 --> 00:14:56,159
through much more rapidly because the interval has been shortened substantially now like I say if

144
00:14:56,159 --> 00:15:02,719
I try to lower this even lower than 0.2 say for example the 0.1 the ping command is not going

145
00:15:02,719 --> 00:15:09,199
to allow me to do this unless I specify super user privileges again because this can be abused and we

146
00:15:09,199 --> 00:15:14,959
can overwhelm systems so if I type in my password right now and hit enter this is going much much

147
00:15:14,960 --> 00:15:21,120
quicker but again requires super user privileges now we can actually just ping a targeted host say

148
00:15:21,120 --> 00:15:30,320
for example 192.1680.1 however what if we wanted to discover all of the devices within our local

149
00:15:30,320 --> 00:15:35,680
network that were actually responding to a ping so we could maybe see if those hosts were potentially

150
00:15:35,680 --> 00:15:41,280
alive well what we could do is we could ping all the hosts in the network at once now if you do

151
00:15:41,279 --> 00:15:46,480
recall from your lpik one studies we have the concept of a broadcast address now what the

152
00:15:46,480 --> 00:15:53,600
broadcast address does it means that if you ping the broadcast address every one on that network

153
00:15:53,600 --> 00:16:00,799
is going to respond to that ping so anyone who is alive and listening will ultimately reveal themselves

154
00:16:00,799 --> 00:16:07,439
and ping you back now we can actually do this using the ping command now if we just try to ping the

155
00:16:07,440 --> 00:16:11,760
broadcast address now you may recall that the broadcast address is the very last address

156
00:16:11,760 --> 00:16:18,800
within the network so if our network is 192.1680.something the broadcast address would be 255

157
00:16:18,800 --> 00:16:25,040
but if I tried to ping this just as it is and hit enter it says do you want to ping a broadcast

158
00:16:25,040 --> 00:16:30,640
then you have to use the dash b flag the reason being is that this is another one which can be

159
00:16:30,640 --> 00:16:37,040
abused simply put because all the hosts in the network will be prompted to ping you back to your

160
00:16:37,039 --> 00:16:43,439
original ping this can cause a lot of processing power on your local machine and what an attacker

161
00:16:43,439 --> 00:16:50,879
may do is they may spoof your source ip address and ping a really really massive network whereby

162
00:16:50,879 --> 00:16:57,039
thousands and thousands and thousands of devices will respond to that spoofed ping request and begin

163
00:16:57,039 --> 00:17:03,599
flooding that poor host with thousands of icmp replies which could effectively bog down their

164
00:17:03,600 --> 00:17:08,559
computer and potentially knock them offline so if we want to use this particular feature albeit

165
00:17:08,559 --> 00:17:13,839
it can be useful just be careful with it and know that if we want to use it with the ping command we

166
00:17:13,839 --> 00:17:22,400
would have to explicitly specify the dash b flag so we can say ping dash b 192.1680.255 if we hit

167
00:17:22,400 --> 00:17:28,559
enter now it tells us a warning that we're pinging a broadcast address notice that we're only seeming

168
00:17:28,559 --> 00:17:36,639
to be getting responses from 192.1680.1 that happens to be the only host alive on my network

169
00:17:36,639 --> 00:17:43,039
except from myself that is my default gateway but if there were other devices on this network that

170
00:17:43,039 --> 00:17:52,799
would be alive say for example 192.1680.5 for example you would also see the output here for 192.1680.5

171
00:17:52,799 --> 00:17:58,960
also responding so you can easily discover all the alive hosts within your network so very very

172
00:17:58,960 --> 00:18:04,720
useful if used carefully and with the correct purpose so we'll stop this right now so as we

173
00:18:04,720 --> 00:18:10,000
can see here the ping command is a very very useful command there is a lot of very important

174
00:18:10,000 --> 00:18:15,599
information that you can peel out from the responses you get from this command by looking at the

175
00:18:15,599 --> 00:18:21,599
sequence numbers and the time to lives and the messages such as the destination host being

176
00:18:21,599 --> 00:18:28,399
unreachable and we have different parameters that we can use to control and toggle the way in which

177
00:18:28,399 --> 00:18:32,559
the ping command is actually going to work we can change the interval we can change the count

178
00:18:32,559 --> 00:18:38,879
type we can ping broadcast addresses we can ping ipv6 based addresses and many many more so what I

179
00:18:38,879 --> 00:18:44,159
would do is encourage you as always to read the man page explore the command have some fun and

180
00:18:44,160 --> 00:18:49,759
lab it up okay doc so I hope it's been informative for you and I'd like to thank you for viewing