1
00:00:02,170 --> 00:00:07,210
Let me introduce the next speaker, because we're right on the money with that talk.

2
00:00:08,050 --> 00:00:09,670
Let's see here, who's next?

3
00:00:09,670 --> 00:00:10,450
Scribbles!

4
00:00:10,450 --> 00:00:11,350
Where's Scribbles?

5
00:00:11,350 --> 00:00:12,510
Scribbles, you here?

6
00:00:13,910 --> 00:00:15,150
Scribbles here?

7
00:00:15,330 --> 00:00:16,430
Oh yeah, I'm here.

8
00:00:16,730 --> 00:00:17,630
Oh, okay, there you are.

9
00:00:17,630 --> 00:00:18,370
Sorry.

10
00:00:18,410 --> 00:00:21,110
Okay, Scribbles is our next speaker.

11
00:00:21,430 --> 00:00:25,450
He's going to be presenting Advanced Packet Wrangling with TCP Dump.

12
00:00:25,550 --> 00:00:28,430
This should be a very interesting talk, by the way.

13
00:00:30,250 --> 00:00:36,370
Scribbles, Stephen Kennedy, is a security engineer and a new Linux enthusiast in Denver, Colorado.

14
00:00:36,370 --> 00:00:43,270
He holds an MS, a master's degree in cybersecurity and information assurance, as well as over 20 industry certifications.

15
00:00:43,950 --> 00:00:45,450
Dude, do you ever sleep?

16
00:00:45,450 --> 00:00:46,710
I mean, 20 search?

17
00:00:46,710 --> 00:00:47,750
Seriously, where are you?

18
00:00:47,750 --> 00:00:48,750
That is impressive.

19
00:00:48,750 --> 00:00:51,050
Okay, I've got search on their heart again.

20
00:00:51,050 --> 00:00:54,750
I work for the university system, you know, they just keep paying me in search instead.

21
00:00:55,610 --> 00:00:56,930
Yeah, well, that's true.

22
00:00:56,930 --> 00:01:00,790
Yes, I know exactly what you mean.

23
00:01:00,790 --> 00:01:03,170
It's like, here's free money, go to another class.

24
00:01:03,170 --> 00:01:04,030
There you go.

25
00:01:04,050 --> 00:01:15,750
So, his first computer was a Commodore 64, and he's a survivor of the late 90s and early 2000s IRC.

26
00:01:15,870 --> 00:01:18,110
By the way, IRC is still alive and working.

27
00:01:18,110 --> 00:01:19,230
Thank you very much.

28
00:01:19,230 --> 00:01:21,290
So, without any further ado, here's Scribbles.

29
00:01:21,290 --> 00:01:22,150
Thank you.

30
00:01:22,870 --> 00:01:23,350
Wonderful.

31
00:01:23,350 --> 00:01:24,450
Thank you, X-Ray.

32
00:01:25,370 --> 00:01:26,850
Just a moment here.

33
00:01:27,950 --> 00:01:30,170
Oh, do you have access to the stage?

34
00:01:30,610 --> 00:01:31,690
I do.

35
00:01:31,690 --> 00:01:32,290
Yep.

36
00:01:32,290 --> 00:01:33,170
Okay.

37
00:01:34,270 --> 00:01:37,550
Just making sure that the stream is looking good too.

38
00:01:37,550 --> 00:01:38,670
Stream set up.

39
00:01:38,750 --> 00:01:40,470
Oh, they got it working.

40
00:01:41,490 --> 00:01:42,650
They did.

41
00:01:43,550 --> 00:01:44,230
Excellent.

42
00:01:44,230 --> 00:01:47,250
Well, our team has been in the background hacking like crazy.

43
00:01:47,250 --> 00:01:48,150
So, excellent.

44
00:01:50,190 --> 00:01:51,010
All right.

45
00:01:51,010 --> 00:01:51,990
Thanks, everyone.

46
00:01:53,710 --> 00:01:56,110
Let me make sure my slides are up over here as well.

47
00:01:56,390 --> 00:02:02,770
And definitely a big shout out to the Giglio team for figuring this out.

48
00:02:02,850 --> 00:02:08,390
It's been a bit of a fire event just to get these slides up, but everything figured out, which is amazing.

49
00:02:08,710 --> 00:02:12,770
So, like X-Ray said, my name is Stephen Kennedy.

50
00:02:13,910 --> 00:02:17,970
Previously, I spent time as a network security consultant and a network security engineer.

51
00:02:19,130 --> 00:02:22,150
And, of course, if you're not familiar with the 14ers...

52
00:02:23,250 --> 00:02:24,770
Let me see if I can move this slide.

53
00:02:24,770 --> 00:02:26,210
This is the new form.

54
00:02:27,650 --> 00:02:28,710
Oh, I can do it myself.

55
00:02:28,710 --> 00:02:29,350
Nice.

56
00:02:30,710 --> 00:02:31,850
Come back and take a look.

57
00:02:31,930 --> 00:02:36,910
Yeah, so if you're not familiar with the 14ers, so those are mountain peaks over 14,000 feet.

58
00:02:37,050 --> 00:02:40,810
Or if you're not using Freedom Units, that'd be 4,267 meters.

59
00:02:42,170 --> 00:02:44,190
Let's see how far away I can test this.

60
00:02:45,590 --> 00:02:46,790
Oh, that's beautiful.

61
00:02:47,830 --> 00:02:50,330
Okay, so tcpdump and libpcap.

62
00:02:51,270 --> 00:02:53,250
These projects are both open source.

63
00:02:53,250 --> 00:02:55,610
They're developed by the tcpdump group.

64
00:02:55,990 --> 00:02:59,970
tcpdump is certainly the best known command line interface packet analyzer.

65
00:03:00,290 --> 00:03:03,970
You can basically open a terminal and see all the traffic on any of your network interfaces.

66
00:03:03,970 --> 00:03:08,070
If you do it on a busy enterprise box, you'll barely get a chance to see any text at all.

67
00:03:08,070 --> 00:03:09,550
It'll just all just screen by.

68
00:03:10,650 --> 00:03:14,830
And, you know, you'll just have to hit control C a hundred times to get it to finally stop.

69
00:03:16,210 --> 00:03:20,450
So the important part about tcpdump is to build filters to slow some of that stuff down.

70
00:03:20,990 --> 00:03:25,470
So it was first released in 1988, and I believe it or not, it is still in active development.

71
00:03:25,470 --> 00:03:29,550
It's still an extremely useful tool, and it's absolutely keeping up with the times.

72
00:03:29,830 --> 00:03:34,390
So, you know, a big part of this talk is encouraging you to dive deep on this one.

73
00:03:35,110 --> 00:03:41,190
So libpcap is the library that tcpdump uses to interface with the kernel.

74
00:03:41,190 --> 00:03:47,510
In Windows, this is called WinPCAP, and the Windows version of tcpdump is called WinDump.

75
00:03:51,740 --> 00:03:53,440
And... let's see here, yep.

76
00:03:53,440 --> 00:04:01,600
So right around 1993 at USENIX, if you're not familiar with USENIX, it's a famous conference where a lot of technical papers are presented.

77
00:04:01,780 --> 00:04:13,220
But back in 1993, the folks that created tcpdump at Lawrence Berkeley Laboratories actually delivered a paper on what they called BSD packet filters.

78
00:04:13,420 --> 00:04:16,340
You might have seen the phrase BPF being thrown around.

79
00:04:16,340 --> 00:04:18,820
It's usually associated with tcpdump.

80
00:04:18,960 --> 00:04:31,740
At this point, BPF has exploded into a number of uses and ways to filter and access all these other bits of information that require really quick access because, you know, the CPU is really quick, there's a lot of process activity.

81
00:04:31,780 --> 00:04:34,700
It's no longer just about network activity.

82
00:04:34,700 --> 00:04:42,340
But if you start searching around, you'll see that most of the stuff online about it is going to be somehow relating to network filtering.

83
00:04:45,280 --> 00:04:47,140
All right, so next slide here.

84
00:04:48,700 --> 00:04:50,560
This is the why should I care slide.

85
00:04:50,880 --> 00:04:53,160
So this is a pretty important part, right?

86
00:04:53,160 --> 00:05:03,900
So whenever people hear that tcpdump is, you know, from 1988, there's a little bit of that, you know, I'm trying to be dragged back into Linux command line again, and I've never seen this stuff before, how long is this going to take to learn, stuff like that,

87
00:05:03,900 --> 00:05:04,460
right?

88
00:05:05,260 --> 00:05:08,440
This is an incredibly useful tool for your skill set.

89
00:05:08,600 --> 00:05:11,440
And I really want to prove that out to you.

90
00:05:11,520 --> 00:05:15,820
The PCAP or it didn't happen picture on the previous slide.

91
00:05:15,820 --> 00:05:18,080
So, you know, it's popular slogan for shirts and everything.

92
00:05:18,320 --> 00:05:20,540
It's not just a clever phrase, right?

93
00:05:20,580 --> 00:05:22,420
It's generally true.

94
00:05:22,420 --> 00:05:25,460
If it didn't go across the wire, it probably didn't happen.

95
00:05:26,580 --> 00:05:29,180
You know, perhaps there's scenarios where you're blocked from viewing it.

96
00:05:29,180 --> 00:05:30,160
And sure, right?

97
00:05:30,820 --> 00:05:32,520
Those are few and far between.

98
00:05:32,520 --> 00:05:39,440
So it's very important as a tool to be able to prove things that you need to prove to someone else or to prove that someone's claiming to you.

99
00:05:40,300 --> 00:05:41,580
So how would that work?

100
00:05:41,600 --> 00:05:51,460
So, you know, I think if you've ever worked in an IT environment, you've been on either side of this conversation and probably will be for the rest of your career.

101
00:05:51,460 --> 00:05:58,320
But that conversation where maybe you're a server owner and you just stood up or maybe you own a couple of servers, right?

102
00:05:58,320 --> 00:06:00,220
A couple of services running on it.

103
00:06:00,220 --> 00:06:04,060
And one of your co-workers just stood up a new server and it needs to connect to yours.

104
00:06:04,120 --> 00:06:09,800
And they come to you and say, hey, I need this, you know, can you give me this token or whatever so I can connect to your service?

105
00:06:09,800 --> 00:06:11,680
You go, yep, made an account for your token.

106
00:06:12,660 --> 00:06:15,340
Go do your thing and configure the stuff that you own.

107
00:06:15,980 --> 00:06:22,600
And then they come back and they go, well, hey, you know, I configured it and the only message that I got was connection failed.

108
00:06:22,960 --> 00:06:23,480
Right?

109
00:06:23,800 --> 00:06:26,300
So connection failed doesn't tell us very much.

110
00:06:26,480 --> 00:06:29,600
Is it a, you know, is the network actually down?

111
00:06:30,440 --> 00:06:32,580
Did we, did something actually fail?

112
00:06:32,580 --> 00:06:34,380
It doesn't, it doesn't tell us very much of anything.

113
00:06:34,380 --> 00:06:35,960
Did it even try to get on the network?

114
00:06:36,160 --> 00:06:38,620
Maybe it can't even access the network adapter itself.

115
00:06:39,940 --> 00:06:41,800
So error messages can be terrible.

116
00:06:41,800 --> 00:06:43,060
I think we all know that.

117
00:06:43,580 --> 00:06:46,140
You know, and developers can be very hit or miss on that sort of thing.

118
00:06:46,140 --> 00:06:49,580
And log messages in general are, you know, aren't always much greater.

119
00:06:49,580 --> 00:06:53,100
So this is that part where you can start to lean on the network to be like, well, wait a minute.

120
00:06:54,080 --> 00:06:59,020
So me as the server owner, if my co-worker comes to me and says, hey, I tried to connect to you and it just didn't work.

121
00:06:59,420 --> 00:07:04,460
One of the first things I'm probably going to do is, you know, we're obviously going to double check the information that he was given.

122
00:07:04,460 --> 00:07:07,460
Maybe the IP was wrong or something like that.

123
00:07:07,580 --> 00:07:10,660
But if you use a tool like TCPDOM, you can say, hey, well, what's your server IP?

124
00:07:11,500 --> 00:07:13,420
Go ahead and try to connect to me again.

125
00:07:13,420 --> 00:07:19,060
And if I don't see any traffic come to my interface, there's something else that's going on, right?

126
00:07:19,060 --> 00:07:21,160
We've already ruled out this entire service.

127
00:07:21,160 --> 00:07:28,060
And , you know, again, if you're in that IT space, you know that you just stopped an entire circus from happening, potentially five meetings, right?

128
00:07:28,920 --> 00:07:32,220
So it's very important that you be able to rule things out.

129
00:07:33,120 --> 00:07:34,760
Improving their claim, right?

130
00:07:34,760 --> 00:07:42,980
And so another great example is that, you know, in a past life, I was working for a vendor that sold security appliances.

131
00:07:43,760 --> 00:07:46,820
And a customer had one installed in Tokyo.

132
00:07:47,120 --> 00:07:51,260
And this appliance would make a tunnel back to a data center in the U.S.

133
00:07:51,440 --> 00:07:53,060
And the tunnel kept failing.

134
00:07:53,060 --> 00:08:00,780
And the response from the customer is, you know, as you'd expect, you know, they paid a lot of money for it, is your appliance is broken, you need to figure it out and fix it.

135
00:08:02,300 --> 00:08:08,200
And so we started looking at the appliance, and it took a bit to, you know, see what was going on.

136
00:08:08,200 --> 00:08:12,900
And every time the tunnel would open, we were looking at it from the point of view of the box that's in Tokyo.

137
00:08:13,040 --> 00:08:16,280
Every time we see that SYN go out, we'd immediately get a reset back.

138
00:08:16,800 --> 00:08:17,220
Right?

139
00:08:17,220 --> 00:08:28,040
And so if you think about it, you know, you don't have to know a ton about, you know, networking to realize that, you know, one millisecond or less isn't enough time for that SYN to go from Tokyo to Atlanta.

140
00:08:29,060 --> 00:08:29,340
Right?

141
00:08:29,340 --> 00:08:31,120
That's breaking the laws of physics.

142
00:08:32,100 --> 00:08:42,540
So if we're immediately getting a reset, right after we attempt that connection, we know that there's another network device nearby, potentially, maybe even in the same office, that's sending that reset.

143
00:08:42,540 --> 00:08:47,680
And so we were immediately able to call that out and get their network engineers on the line and be like, what is this?

144
00:08:47,900 --> 00:08:50,300
Look at the timestamps, like this doesn't make sense.

145
00:08:50,340 --> 00:08:54,760
And boom, you know, they found out that they hadn't actually properly implemented the ACLs.

146
00:08:54,760 --> 00:08:57,740
And the connection was open and the tunnel was able to work.

147
00:08:58,460 --> 00:08:58,620
Right?

148
00:08:58,620 --> 00:09:05,820
So the point of the story is, of course, being that, you know, this tool can look very esoteric, but it's important.

149
00:09:06,720 --> 00:09:09,920
And third, of course, threat actors aren't the only ones that live off the land.

150
00:09:09,920 --> 00:09:16,360
Whenever we hear that phrase, we always think about, you know, threat actors having to come in and, you know, they can't, you know, upload certain tools.

151
00:09:16,360 --> 00:09:17,360
So they have to live off the land.

152
00:09:17,360 --> 00:09:17,880
Right?

153
00:09:19,280 --> 00:09:20,880
That happens to us too.

154
00:09:21,300 --> 00:09:21,540
Right?

155
00:09:21,540 --> 00:09:35,200
So when you work in a highly regulated or highly secured environment, if you have customers that are, you know, in the energy industry, or potentially, you know, if you're working in a FedRAMP environment with government customers, you know this problem well.

156
00:09:35,200 --> 00:09:42,280
Whenever you run into a problem, someone's always going to bring up some really slick tool from GitHub that was just written four weeks ago, probably in Go.

157
00:09:43,600 --> 00:09:46,260
And you can't just go download and install that.

158
00:09:46,260 --> 00:09:47,860
It would break compliance regulations.

159
00:09:47,860 --> 00:09:49,240
You'd be tons of paperwork.

160
00:09:49,380 --> 00:09:56,700
And this is generally, you know, what we call, you know, if you try to circumvent those sorts of things, it's generally what we consider a career limiting move.

161
00:09:57,380 --> 00:09:57,740
Right?

162
00:09:58,380 --> 00:10:07,020
So those are the important pieces that, you know, I just really wanted to highlight and make sure that we got through here when we were talking about TCP dump.

163
00:10:07,280 --> 00:10:10,980
So this is a skill that also pays dividends.

164
00:10:10,980 --> 00:10:11,120
Right?

165
00:10:11,120 --> 00:10:15,280
The more you invest in this, the more you practice, the better you're going to get at it.

166
00:10:15,400 --> 00:10:20,600
Some of the technical details here, if you don't practice them, it's not going to stick.

167
00:10:20,600 --> 00:10:22,180
It's just like anything else in life.

168
00:10:22,180 --> 00:10:25,400
But it's not as hard as it can look initially.

169
00:10:25,620 --> 00:10:30,180
So please understand that this does require a basic understanding of the TCP IP protocol stack.

170
00:10:30,320 --> 00:10:34,720
If you're a networking newbie, this will help you get an idea of what's possible with this tool.

171
00:10:43,260 --> 00:10:50,800
So once we get through the syntax, we're going to do some more advanced filter techniques, but certainly don't be discouraged because things will get a little weird here.

172
00:10:50,800 --> 00:10:51,800
We'll stick with...

173
00:10:53,460 --> 00:10:59,380
So some basic syntax, you've probably seen a good bit of this, if you are familiar with TCP dump.

174
00:11:00,180 --> 00:11:04,980
So on the left here, we've got our flags, color-coded.

175
00:11:04,980 --> 00:11:06,860
So if we look at the command across the top, right?

176
00:11:06,860 --> 00:11:11,180
So we've got capital X, so that's going to show the output in both hexadecimal and ASCII.

177
00:11:11,460 --> 00:11:13,780
The N is don't resolve hosts and ports.

178
00:11:14,080 --> 00:11:17,940
Typically, we do that just because we just want to see port numbers and we want to see IP.

179
00:11:17,940 --> 00:11:22,320
I don't want resolution and DNS getting in the way because we know that that always gets messy.

180
00:11:23,860 --> 00:11:27,560
For I, also very important one, we want to specify the network interface we're monitoring.

181
00:11:28,680 --> 00:11:30,940
So in this example, we're going to be looking at eth0.

182
00:11:30,940 --> 00:11:39,100
And then for the dash C, we're going to specify the packet count, which this way you can say, hey, you might match a million packets with this filter, just show me five.

183
00:11:39,100 --> 00:11:40,340
That'd be great, right?

184
00:11:41,200 --> 00:11:43,700
So we look on the right side here, filters and operators.

185
00:11:45,260 --> 00:11:47,080
So pretty easy to read in English.

186
00:11:47,080 --> 00:11:52,880
So right after we get past that C5 on the top left, we're going to move into what I put in single quotes.

187
00:11:52,880 --> 00:12:00,200
The reason you typically want to do that is because the TCP DOM filters can start to use characters that might be interpreted by your shell.

188
00:12:00,680 --> 00:12:05,200
I'm talking about like an ampersand or parentheses or things you might have to escape otherwise.

189
00:12:05,300 --> 00:12:09,140
It gets messy, just use single quotes, and then you don't have to worry about it.

190
00:12:09,980 --> 00:12:12,940
So TCP and, you see we've got open parentheses.

191
00:12:13,440 --> 00:12:15,820
That's matched by a closed parenthesis on the other end of the line.

192
00:12:15,820 --> 00:12:21,080
Remember, this is just like in math class, order of operations, we're going to start with the parentheses first.

193
00:12:21,200 --> 00:12:26,700
And what we're saying here is source host, this IP address, or source host, this other IP address.

194
00:12:27,240 --> 00:12:34,380
So this filter is going to show us any packet that is TCP and source from either of those hosts.

195
00:12:34,640 --> 00:12:35,880
Easy enough, right?

196
00:12:36,020 --> 00:12:37,920
We can also see that there's other things you can do.

197
00:12:37,920 --> 00:12:39,380
You can do ports, port ranges.

198
00:12:39,620 --> 00:12:43,400
You can specify protocols, TCP, UDP, ISP multicast.

199
00:12:43,400 --> 00:12:45,600
I said NOT and OR at the bottom line.

200
00:12:45,600 --> 00:12:47,180
I wanted to hit that one first.

201
00:12:47,180 --> 00:12:48,520
Look right above it.

202
00:12:48,660 --> 00:12:51,740
Of course, the NOT and the negation is the estimation point.

203
00:12:52,240 --> 00:12:55,280
Just like in bash, the double ampersand is an AND.

204
00:12:55,420 --> 00:12:58,180
Just like in everything else, the double pipe is an OR.

205
00:12:58,480 --> 00:13:03,540
And we have some other characters that are available to us, less than, greater than, equals, and parentheses to help divide some things.

206
00:13:07,540 --> 00:13:09,120
Okay, so...

207
00:13:11,220 --> 00:13:13,080
filtering of the transporter network letters.

208
00:13:13,080 --> 00:13:18,760
So a really cool feature of TCPdump is that you do have some convenience flags.

209
00:13:18,760 --> 00:13:24,640
This is done by the development team, you know, just kind of thrown in there some really common things that you're going to need to do.

210
00:13:24,740 --> 00:13:26,760
There's no reason to bring math into this, right?

211
00:13:26,760 --> 00:13:30,760
Like, let's just do something easy where we can look at a table and figure this out.

212
00:13:30,760 --> 00:13:33,080
Again, this is pretty English readable.

213
00:13:33,120 --> 00:13:34,400
You'll see the flags on the left.

214
00:13:34,400 --> 00:13:37,940
If you're familiar with the TCP protocol, you'll recognize the flag names.

215
00:13:38,740 --> 00:13:43,100
What we have is, you know, TCP FIN, TCP SIN, RESET, PUSH, ACK.

216
00:13:43,100 --> 00:13:46,540
And then the message types, these are all ICMP messages down here.

217
00:13:46,540 --> 00:13:54,460
So the most common ones you're going to recognize are, of course, ICMP message type 8 and message type 0, which are ECHO and ECHO REPLY or PING and PING REPLY.

218
00:13:54,460 --> 00:13:56,180
That's the most common way of knowing it.

219
00:13:56,880 --> 00:14:01,740
So in the examples up here, let's look at one of these written out using some of these keywords.

220
00:14:01,740 --> 00:14:04,660
So we have TCP and then in square brackets, TCP flags.

221
00:14:05,120 --> 00:14:09,940
And parenthesis, TCP SIN or TCP FIN does not equal 0.

222
00:14:11,020 --> 00:14:13,280
So it's pretty obvious what the first part does, right?

223
00:14:13,320 --> 00:14:16,840
So we're filtering on the TCP flag section of the TCP header.

224
00:14:17,120 --> 00:14:27,160
And I want you to show me packets where either the TCP SIN flag, or remember that pipe is an OR, or the FIN packet is not 0.

225
00:14:27,520 --> 00:14:30,640
So remember, a packet is actually binary when it's on the wire.

226
00:14:30,640 --> 00:14:32,860
It's a 1 or a 0, it's on or off.

227
00:14:32,860 --> 00:14:37,160
So if it does not equal 0, then it must be a 1, which means it must be on.

228
00:14:37,300 --> 00:14:40,100
So show me packets where SIN or FIN are on.

229
00:14:40,640 --> 00:14:44,120
And same thing with the ICMP message down here.

230
00:14:44,120 --> 00:14:45,100
Pretty straightforward.

231
00:14:45,100 --> 00:14:50,660
ICMP type does not equal ICMP ECHO, and it does not equal ICMP ECHO REPLY.

232
00:14:50,660 --> 00:14:56,100
That would essentially show you every ICMP packet that is not related to PING.

233
00:14:57,160 --> 00:14:58,280
It's simple, right?

234
00:14:58,680 --> 00:15:00,280
Let's move on to the next slide here.

235
00:15:09,410 --> 00:15:14,330
All right, so the big question is we see those keywords, right?

236
00:15:14,330 --> 00:15:16,810
And they're very convenient, very nice, easy to remember.

237
00:15:18,090 --> 00:15:19,750
And things start getting weird.

238
00:15:19,750 --> 00:15:22,430
So how do those keywords work?

239
00:15:22,910 --> 00:15:24,050
Why are they convenient?

240
00:15:24,050 --> 00:15:26,050
And why would they go out of their way to do this for us?

241
00:15:26,270 --> 00:15:30,030
How do they go into a packet and pull out that section of the packet?

242
00:15:30,070 --> 00:15:36,630
So in this diagram here, the big part in the center, so that's actually the TCP header, right?

243
00:15:36,630 --> 00:15:40,290
So if you're familiar with TCP IP, you'll know that typically the IPv4 header is at the top.

244
00:15:40,290 --> 00:15:45,330
And then in order to get around, TCP needs its own... requires IPv4.

245
00:15:45,390 --> 00:15:51,190
And so below the IPv4 header, you'll have the TCP header, and then the payloads, all the data that's being moved around below that.

246
00:15:51,350 --> 00:15:54,530
This TCP, you'll notice in this header, doesn't talk about IP addresses.

247
00:15:54,610 --> 00:15:56,150
It just talks about ports.

248
00:15:56,250 --> 00:15:58,390
IP addresses are up in the IPv4 header.

249
00:16:00,170 --> 00:16:04,370
So when we talk about TCP SYN, TCP FIN, what's actually happening?

250
00:16:04,370 --> 00:16:06,610
And again, these are examples from previously.

251
00:16:07,630 --> 00:16:09,990
You look down at byte 13 down here.

252
00:16:09,990 --> 00:16:11,870
In green, you'll see TCP flags.

253
00:16:12,490 --> 00:16:14,770
It says C-E-U-A-P-R-S-F.

254
00:16:15,590 --> 00:16:19,310
So what that actually is, is those are all of the TCP flags.

255
00:16:19,450 --> 00:16:21,490
Look on the left-hand side over here.

256
00:16:21,790 --> 00:16:26,230
What we have is this table that's showing ERJAC, PUSH, RESET, SYN, FIN.

257
00:16:27,370 --> 00:16:32,570
So these are a lot of the flags that you hear on a regular basis, the SYN, SYNAC, ACK for the TCP three-way handshake.

258
00:16:33,170 --> 00:16:35,030
The order of those matters.

259
00:16:35,970 --> 00:16:39,910
And so when we're going in and we're looking at a header like this, it can be very confusing.

260
00:16:40,410 --> 00:16:43,390
So there's lots of numbers and lines and things like that.

261
00:16:43,450 --> 00:16:47,590
So at the very top left is byte offset zero.

262
00:16:47,590 --> 00:16:50,410
That's the beginning of the TCP header.

263
00:16:51,170 --> 00:16:59,330
So for the next eight open slots here, so we'll count them off, 1, 2, 3, 4, 5, 6, 7, 8, so where that one is right above the word source, that's a whole byte.

264
00:16:59,330 --> 00:17:00,790
And one byte is eight bits.

265
00:17:01,190 --> 00:17:03,630
And you'll see there's a line in the middle that's a little bit darker.

266
00:17:03,630 --> 00:17:05,650
So a half byte is called a nibble.

267
00:17:05,650 --> 00:17:07,230
So four bits is a nibble.

268
00:17:07,230 --> 00:17:08,550
Eight bits is a byte.

269
00:17:09,410 --> 00:17:11,210
So it's pretty easy to say.

270
00:17:11,210 --> 00:17:14,070
The source port field of the TCP header takes up two whole bytes.

271
00:17:14,510 --> 00:17:15,750
Easy enough.

272
00:17:16,110 --> 00:17:28,950
So if we look on the top left where this binary diagram is, what we'll see is actually the top column in blue is 128, 64, 32, 16, 8, 4, 2, 1.

273
00:17:28,950 --> 00:17:32,290
You'll see that 128 keeps getting cut in half as we go.

274
00:17:32,290 --> 00:17:34,310
And then there's ones and zeros along it.

275
00:17:34,370 --> 00:17:38,090
So think of each of these slots or each of the columns there.

276
00:17:38,150 --> 00:17:39,150
There's eight of them.

277
00:17:39,150 --> 00:17:41,390
They match up with the eight bits in a byte.

278
00:17:42,550 --> 00:17:50,370
So as we go across, starting at byte offset zero here, that's going to be 128, 64, 32, 16, 8, 4, 2, 1.

279
00:17:51,010 --> 00:17:56,390
So as they're coming across the wire, again, electronically, it's just a one or a zero or an on pulse or an off pulse.

280
00:17:56,850 --> 00:18:01,690
So in this diagram up here, so we see it's 1, 0, 1, 1, 0, 0, 0, 1.

281
00:18:01,690 --> 00:18:04,950
All you have to do is where there's a one, you just add that number.

282
00:18:04,950 --> 00:18:05,770
It's that simple.

283
00:18:06,030 --> 00:18:09,170
128 plus 32 plus 16 plus 1 equals 177.

284
00:18:09,550 --> 00:18:11,770
I mean, that's binary math, right?

285
00:18:11,770 --> 00:18:13,890
It's really just adding where there's a one.

286
00:18:13,970 --> 00:18:19,470
And just know that after that one at the very end here, along the top column, it just starts over again.

287
00:18:19,690 --> 00:18:23,410
At 1, so it goes 4, 2, 1, 128, 64, 32.

288
00:18:23,410 --> 00:18:28,390
And that's going to keep going along the whole top of all of these fields over and over and over again.

289
00:18:28,390 --> 00:18:32,390
And that's how your computer is interpreting these values, your network card, rather.

290
00:18:32,990 --> 00:18:36,450
So back to the point about the filter examples.

291
00:18:36,950 --> 00:18:42,390
So we already went over the verbal one or the keyword one, TCP SYN or TCP FIN does not equal zero.

292
00:18:42,710 --> 00:18:45,690
But the line below it is actually equivalent.

293
00:18:46,170 --> 00:18:49,370
So TCP 13 and 2 or 1 does not equal zero.

294
00:18:49,990 --> 00:18:59,970
So you might have put two and two together now and realized that that TCP 13, the reason that's equivalent to TCP flags, well, TCP flags where it's green right here is actually byte 13 of the TCP header.

295
00:18:59,970 --> 00:19:02,230
We're saying start it that byte.

296
00:19:02,710 --> 00:19:03,910
What about this AND part?

297
00:19:03,910 --> 00:19:05,430
So AND 2 or 1?

298
00:19:05,650 --> 00:19:06,910
Go back up to the binary chart.

299
00:19:06,910 --> 00:19:09,810
That's the two bits on the far right of the 13th byte here.

300
00:19:09,810 --> 00:19:12,330
There's the S and the F, the SYN and the FIN.

301
00:19:12,730 --> 00:19:19,190
So if there's a 1 and a 1 here, then we could match.

302
00:19:21,550 --> 00:19:29,010
So starting from byte 13, if this field of TCP flags is 0000, 0010, it's going to show up with our TCP dump filter.

303
00:19:30,390 --> 00:19:32,250
And that's about as hard as this gets.

304
00:19:32,350 --> 00:19:34,250
It gets a little weirder, but that's about as hard as it gets.

305
00:19:34,250 --> 00:19:37,270
So if you're following me there, you're doing a great job.

306
00:19:39,870 --> 00:19:41,110
The next slide.

307
00:19:47,230 --> 00:19:49,410
We can get a lot more precise than that.

308
00:19:50,630 --> 00:19:56,890
And so if you feel it in your chest the first time you see a filter like this, you're not alone.

309
00:19:56,890 --> 00:19:58,310
I've certainly been there.

310
00:19:59,290 --> 00:20:04,650
This is whenever those keywords don't match what you need to look for in TCP dumper on the wire.

311
00:20:05,050 --> 00:20:06,230
So we start seeing things.

312
00:20:06,230 --> 00:20:08,390
Some of this might make sense based on what we've been talking to.

313
00:20:08,390 --> 00:20:09,610
We've got IP, sure.

314
00:20:09,610 --> 00:20:11,630
I see the brackets where they have the byte numbers.

315
00:20:11,630 --> 00:20:12,410
I can look at those, right?

316
00:20:12,410 --> 00:20:13,350
TCP 12.

317
00:20:13,910 --> 00:20:15,270
Not equal zero.

318
00:20:15,930 --> 00:20:17,390
What does any of this mean?

319
00:20:19,450 --> 00:20:21,250
And where do we even begin?

320
00:20:21,250 --> 00:20:23,070
So we're going to break this down into three parts.

321
00:20:23,070 --> 00:20:25,750
The TCP port 80 and pretty straightforward.

322
00:20:26,810 --> 00:20:28,130
But we're going to break this down into three filters.

323
00:20:28,130 --> 00:20:29,350
We've got the blue one here.

324
00:20:29,970 --> 00:20:30,590
What is that?

325
00:20:30,590 --> 00:20:31,210
Coral?

326
00:20:31,290 --> 00:20:32,490
We'll go with coral.

327
00:20:32,490 --> 00:20:35,850
And then this yellow-ish color here.

328
00:20:35,990 --> 00:20:39,610
We're going to break this into three different filter pieces and go through them.

329
00:20:43,790 --> 00:20:44,710
All right.

330
00:20:44,750 --> 00:20:47,650
So this is the IPv4 header, RC791.

331
00:20:49,970 --> 00:20:54,730
The filter we're looking at is the first part of the original one on the previous slide here.

332
00:20:54,930 --> 00:21:00,590
So we're looking at IP 2 and 2 as the first portion of what we want to figure out.

333
00:21:00,730 --> 00:21:03,410
Because the goal here is just to figure out what it is that this filter does.

334
00:21:04,590 --> 00:21:05,210
So, okay.

335
00:21:05,210 --> 00:21:06,110
So IP 2 and 2.

336
00:21:06,110 --> 00:21:07,810
So we hadn't seen the colon 2 before.

337
00:21:07,870 --> 00:21:10,390
But we know that that 2 probably means the second byte.

338
00:21:10,470 --> 00:21:12,710
So the top left, we see the offset and length.

339
00:21:13,110 --> 00:21:17,530
So whenever you do the 2 and 2, it's just like a range, just like you would do in Python or another language like that.

340
00:21:17,530 --> 00:21:24,990
So it's saying from byte 2, so where the blue arrow here on the diagram begins, I want the next two bytes.

341
00:21:25,250 --> 00:21:27,030
So from byte 2, 1, 2.

342
00:21:27,030 --> 00:21:28,190
And there's the end of the line.

343
00:21:28,230 --> 00:21:32,130
So we're basically done with the IP 2 and 2 portion.

344
00:21:32,130 --> 00:21:35,930
If you look at the header, we know that it's asking for the total length field.

345
00:21:35,930 --> 00:21:43,870
So we're basically saying whatever value is in the total length field is going to be swapped out in the filter as we go.

346
00:21:43,870 --> 00:21:49,170
And at the bottom here, one of the cool things about this diagram is it has a couple of definitions for what the fields do, because some of the fields are a little different.

347
00:21:49,510 --> 00:21:55,590
So total length is the total length of the IP diagram, or IP fragmented, and it's measured in bytes.

348
00:21:55,590 --> 00:21:57,750
That's already in bytes, and that's what we probably want.

349
00:21:57,750 --> 00:21:59,290
So we're just going to go with that.

350
00:21:59,730 --> 00:22:00,450
Easy.

351
00:22:02,130 --> 00:22:02,870
All right.

352
00:22:02,930 --> 00:22:10,390
But then the next one is this IP 0 and 0xfslsn2.

353
00:22:10,390 --> 00:22:11,670
All right.

354
00:22:11,670 --> 00:22:14,650
So that looks pretty strange.

355
00:22:14,650 --> 00:22:16,710
Let's move on to the next one and take a look.

356
00:22:21,020 --> 00:22:23,560
So we're going to validate our length field here.

357
00:22:23,960 --> 00:22:27,440
So this is the first time that we're taking a look at the TCP dump output.

358
00:22:28,400 --> 00:22:30,020
I hope everyone can see this.

359
00:22:30,020 --> 00:22:33,320
I'm going to slide down here so I can get a first look as well.

360
00:22:33,820 --> 00:22:42,500
So you can see that I'm using, at the very top line, I'm using the filter that we were looking at, TCP 13 and 2 or 1 does not equal 0.

361
00:22:42,500 --> 00:22:43,200
Great.

362
00:22:43,200 --> 00:22:47,900
So on the third line of this whole screen here is a timestamp, that 1345.

363
00:22:48,160 --> 00:22:53,020
Each one of these timestamps is a packet that matched that filter that TCP dump is outputting and showing us.

364
00:22:53,940 --> 00:23:01,280
As we read across, we see IP 192.168.1.140 is reaching out to this 174 address in port 80.

365
00:23:01,400 --> 00:23:05,380
I'm going to make a leap and say that's probably HTTP traffic.

366
00:23:05,380 --> 00:23:06,920
I think that's safe to say, right?

367
00:23:07,680 --> 00:23:11,900
As a little bit further than that, it says flags, bracket, S bracket.

368
00:23:12,340 --> 00:23:18,300
So in TCP dump output, that S actually represents that SYN flag being on, the TCP SYN.

369
00:23:18,800 --> 00:23:25,760
And if we look directly below that S into the next packet where it says S dot, that S dot, the dot is an ACK.

370
00:23:26,300 --> 00:23:28,080
So what we're seeing here is part of the three-way handshake.

371
00:23:28,080 --> 00:23:29,980
So we see S and S dot.

372
00:23:29,980 --> 00:23:33,580
So the host that received the SYN reply back with his SYN ACK.

373
00:23:34,640 --> 00:23:41,140
What's in the red box is actually the part of the packet that we were just filtering for the IP 2 and 2.

374
00:23:41,340 --> 00:23:43,600
So why is it all the way over here in these weird characters?

375
00:23:44,240 --> 00:23:54,460
So if you've never seen HEX before, hopefully you have, but if you haven't, HEX is typically represented when it's written beginning with 0x in order to separate it from other types of values like decimal.

376
00:23:55,420 --> 00:23:57,720
HEX is a base 16 counting system.

377
00:23:57,880 --> 00:24:01,220
So we're doing 0 through 9 and A through F are the valid characters.

378
00:24:01,220 --> 00:24:02,560
So F is 15.

379
00:24:02,580 --> 00:24:06,400
The reason why F is not 16 in the base 16 counting system is because we count from 0.

380
00:24:07,900 --> 00:24:09,100
So 003C.

381
00:24:09,900 --> 00:24:13,080
So each character up there is actually one nibble.

382
00:24:13,140 --> 00:24:20,720
So if we start at the top left and see that 4500 to the left of the red box, we can actually look at our header diagram and see, okay, version.

383
00:24:20,760 --> 00:24:21,880
That's that 4.

384
00:24:22,220 --> 00:24:23,680
IHL, that's a 5.

385
00:24:24,340 --> 00:24:25,660
Type of service, 0.

386
00:24:25,660 --> 00:24:26,660
Next nibble, 0.

387
00:24:26,660 --> 00:24:28,200
Now we're into the red box.

388
00:24:28,700 --> 00:24:31,060
003C, so first nibble, 0.

389
00:24:31,060 --> 00:24:32,180
Second nibble, 0.

390
00:24:32,280 --> 00:24:34,100
Then there's a 3, then there's C.

391
00:24:34,580 --> 00:24:36,360
Well, 3C doesn't make any sense to us.

392
00:24:36,360 --> 00:24:38,160
We thought this was supposed to be in bytes.

393
00:24:38,560 --> 00:24:39,100
Well, it is.

394
00:24:39,100 --> 00:24:40,900
It's just in hexadecimal right now.

395
00:24:40,980 --> 00:24:43,260
So we have to convert that to decimal.

396
00:24:43,340 --> 00:24:47,780
At the very top, just above the screenshot, you can see HEX003C equals 60.

397
00:24:48,020 --> 00:24:50,940
You convert that value to decimal, that's 60 bytes.

398
00:24:52,140 --> 00:24:53,580
All right.

399
00:25:00,320 --> 00:25:01,960
This next slide here.

400
00:25:03,880 --> 00:25:12,140
So back to the second part of the coral filter, IP0 and 0xf, less than, less than 2.

401
00:25:12,180 --> 00:25:14,540
So what's actually going on here?

402
00:25:14,540 --> 00:25:16,200
I'm going to exit the stage here for a moment.

403
00:25:18,960 --> 00:25:21,320
So we're going to start at the very top left.

404
00:25:21,980 --> 00:25:26,700
And what we can see is that IP0, simple enough.

405
00:25:26,700 --> 00:25:27,480
We're going to look at the IP header.

406
00:25:27,480 --> 00:25:29,100
We're going to start at byte offset 0.

407
00:25:29,120 --> 00:25:30,120
Show me that first byte.

408
00:25:30,120 --> 00:25:30,460
Great.

409
00:25:30,460 --> 00:25:32,080
There's the first two nibbles, right?

410
00:25:32,080 --> 00:25:33,120
Two nibbles and a byte.

411
00:25:34,340 --> 00:25:38,200
And so that part's done, but we haven't finished dealing with the rest of the parentheses yet.

412
00:25:38,200 --> 00:25:45,960
So that ampersand 0xf, the ampersand is telling you that we're going to bit mask.

413
00:25:46,920 --> 00:25:53,340
And so what we're going to do is we're going to mask these eight bits in this single byte.

414
00:25:54,220 --> 00:25:59,040
And what that means is that we need to take that hexadecimal F, we need to convert it to decimal.

415
00:25:59,540 --> 00:26:02,220
F in decimal is 15, like we were just talking about.

416
00:26:02,360 --> 00:26:04,900
And in binary, it's 1111.

417
00:26:05,560 --> 00:26:07,020
Why is it 1111?

418
00:26:07,400 --> 00:26:20,600
Well, again, if we imagine the 128, 64, 32, 16, 8, 4, 2, 1 across each bit in this byte, what you're going to see is it actually breaks out to 0, 0, 0, 0, 1, 1, 1 because 8, 4, 2, 1 totals 15.

419
00:26:21,580 --> 00:26:25,720
And so that's why we opted to give it the hex F value.

420
00:26:25,720 --> 00:26:40,020
So with this mask applied, we have now told tcpdump, hey, I know that you only let me tell you which whole byte to start on, but I really needed a half byte, and that doesn't help me very much.

421
00:26:40,020 --> 00:26:48,160
So I want you to start at 0 and now use this mask to carve out this nibble for me.

422
00:26:48,460 --> 00:26:50,260
And you can do this a lot of different ways.

423
00:26:50,260 --> 00:26:52,620
There's a lot of cool tricks you can do, but this is the concept.

424
00:26:53,460 --> 00:27:02,260
So the IHL field in tcpdump, I'm sorry, in the IP header is actually the header length.

425
00:27:02,960 --> 00:27:06,500
And so this typically almost always is a 5.

426
00:27:06,700 --> 00:27:10,740
And so the reason for that is that IP options are generally no longer used.

427
00:27:10,740 --> 00:27:13,320
The IP options is the last field in an IP header.

428
00:27:14,480 --> 00:27:18,240
So there's just one of these things in life that you just have to accept.

429
00:27:18,240 --> 00:27:21,860
It's a weird rule where the story takes longer than it does remember the rule.

430
00:27:21,860 --> 00:27:28,340
You just need to remember that when that field has a value in it, you multiply it by 4, and that tells you the number of bytes that the header is.

431
00:27:28,340 --> 00:27:31,280
It's almost always 20 bytes, because again, IP options just aren't used.

432
00:27:31,600 --> 00:27:35,020
So I went ahead and put that 5 over here, right?

433
00:27:35,020 --> 00:27:37,200
And below it, we have the binary chart.

434
00:27:37,440 --> 00:27:41,160
And so we finished the parentheses, and we're still left with that less than, less than 2.

435
00:27:41,200 --> 00:27:42,200
So what does that mean?

436
00:27:43,360 --> 00:27:47,980
So the less than 2 actually means we're going to bit shift the value in parentheses by 2.

437
00:27:48,600 --> 00:27:52,300
If you haven't heard of bit shifting, it sounds really complicated and cool.

438
00:27:52,300 --> 00:27:53,860
It's extremely simple.

439
00:27:53,920 --> 00:28:00,640
So we're going to take that value, and we know that we need to multiply by 4 to get the bytes, right?

440
00:28:01,000 --> 00:28:06,540
But the interesting part is that bit shifting left by 2 is the same thing as multiplying by 4.

441
00:28:08,180 --> 00:28:11,720
I say that again, bit shifting left by 2 is the same as multiplying by 4.

442
00:28:11,720 --> 00:28:14,980
And the reason that is, is we come over here and look.

443
00:28:17,630 --> 00:28:21,830
We have 0, 1, 0, 1 in this left binary table here, right?

444
00:28:21,830 --> 00:28:23,150
So 8, 4, 2, 1.

445
00:28:23,270 --> 00:28:32,450
All I did was literally slid the value in the left table 2 bits over, and any new spaces that are created, you just throw a 0 in there.

446
00:28:32,590 --> 00:28:35,090
We can't create new ones, right?

447
00:28:35,090 --> 00:28:37,890
So then it just becomes 1, 0, 1, 0, 0.

448
00:28:38,730 --> 00:28:44,490
So we essentially multiplied by 4 because we went from 4 and 1 makes 5 to 16 and 4 makes 20.

449
00:28:44,890 --> 00:28:59,110
It's an interesting bit of binary math, and also, you know, if you've never delved into how CPUs at a very low level do complex math, this is the very beginning of how that stuff works.

450
00:28:59,150 --> 00:29:06,270
The advanced stuff has been above my head for a long time, but this is a very general idea of how that binary math works.

451
00:29:07,810 --> 00:29:09,590
So that's it, right?

452
00:29:09,590 --> 00:29:11,410
So one of the most intimidating pieces.

453
00:29:13,750 --> 00:29:15,650
So on to the third filter.

454
00:29:17,810 --> 00:29:19,670
This looks very much the same.

455
00:29:19,670 --> 00:29:21,090
You already know what to do here.

456
00:29:21,150 --> 00:29:24,630
So we're starting with the TCP header.

457
00:29:24,750 --> 00:29:29,350
We started the 12th byte, and we can see the header up here at the very top right.

458
00:29:29,350 --> 00:29:32,190
So the 12th byte, we look on the left-hand column.

459
00:29:32,250 --> 00:29:34,470
There's those byte offset values in red.

460
00:29:34,470 --> 00:29:35,790
You can actually just go straight down to 12.

461
00:29:35,790 --> 00:29:36,810
You don't even have to count.

462
00:29:36,810 --> 00:29:40,990
That's nice and easy, right on a simple edge line there.

463
00:29:40,990 --> 00:29:43,250
So we're looking at the offset value.

464
00:29:43,450 --> 00:29:57,270
So if you don't know what the TCP offset value is, that value tells you in bytes how far from offset zero of the TCP header does the TCP payload begin, right?

465
00:29:57,290 --> 00:30:08,090
So the reason why that's important and less important than the IP header length value is that, like I said, IP options aren't really used anymore, so it's almost always 20 bytes.

466
00:30:08,350 --> 00:30:10,890
TCP options are absolutely used all the time.

467
00:30:11,290 --> 00:30:14,630
So we do need to calculate this value, and it does matter, right?

468
00:30:14,630 --> 00:30:17,490
So we're looking at TCP 12, and we know which part that is.

469
00:30:17,490 --> 00:30:18,230
Great.

470
00:30:18,810 --> 00:30:28,570
But again, we're on the problem where the offset value in the header diagram, the diagram shows us that offset is not a whole byte, like source port was, where it was nice and easy.

471
00:30:28,570 --> 00:30:32,370
So we need to bit mask again just to grab that first nibble.

472
00:30:34,090 --> 00:30:37,070
So the bit mask is 0xF0.

473
00:30:37,070 --> 00:30:42,810
Remember, the previous mask was 0xF in order to get the far right four bits.

474
00:30:42,810 --> 00:30:47,910
Now we want the far left four bits, which is the higher order bits, so 128, 64, 32, 16.

475
00:30:48,070 --> 00:30:49,510
We're going to do the same thing.

476
00:30:49,510 --> 00:30:51,270
We convert that to binary.

477
00:30:52,050 --> 00:30:54,990
And in binary, let me check my notes.

478
00:30:54,990 --> 00:30:56,650
Yeah, that comes out to 240.

479
00:30:57,090 --> 00:31:01,210
And so that 240, we build that out.

480
00:31:06,900 --> 00:31:09,100
So we get the 1, 1, 1, 1, 0, 0, 0, 0.

481
00:31:09,100 --> 00:31:10,360
Sorry, I was looking at my notes there.

482
00:31:10,560 --> 00:31:12,420
And that gets us our mask.

483
00:31:12,420 --> 00:31:14,500
So that 240 is the whole half nibble there.

484
00:31:14,500 --> 00:31:15,740
We drop down.

485
00:31:15,780 --> 00:31:20,440
And I went ahead and selected 80 from one of the packets that we match on a future slide, so we have data to work with.

486
00:31:20,780 --> 00:31:25,400
And that's what's actually in the offset value for a real TCP packet.

487
00:31:25,760 --> 00:31:27,560
So we use that 240 to get the mask.

488
00:31:27,800 --> 00:31:32,720
And then once we actually look in that field using that mask, we realize that there's an 80 in there.

489
00:31:32,720 --> 00:31:35,640
So an 80 is made up of 64 plus 16.

490
00:31:36,340 --> 00:31:37,140
Great.

491
00:31:37,540 --> 00:31:38,240
Got that.

492
00:31:38,240 --> 00:31:40,440
But we still need to bitshift 2 to the right.

493
00:31:40,800 --> 00:31:51,800
Well, if bitshifting left by 2 is multiplying by 4, I certainly didn't do well in math in school, but I'm pretty confident that bitshifting right by 2 is probably going to do the opposite, and it's going to divide by 4.

494
00:31:52,160 --> 00:31:55,540
And so if we look, and that's exactly what we just did.

495
00:31:55,540 --> 00:31:58,920
We just rolled those 1s two places to the right.

496
00:31:59,300 --> 00:32:00,480
It's that simple.

497
00:32:00,480 --> 00:32:05,260
Now, if you find yourself rolling off, there's a whole other problem that begins there, right?

498
00:32:05,260 --> 00:32:09,820
But that's unlikely to happen in these much more simple binary math situations.

499
00:32:11,840 --> 00:32:12,820
That's it.

500
00:32:12,820 --> 00:32:16,480
So now we've got 20 as the result of this filter.

501
00:32:19,480 --> 00:32:20,520
Wow.

502
00:32:21,320 --> 00:32:25,700
So let's go back to our original, extremely intimidating, complicated filter.

503
00:32:25,700 --> 00:32:32,280
And the point of that filter was to view only IPv4 HTTP packets that contain a payload.

504
00:32:32,580 --> 00:32:33,460
And that's a tough one, right?

505
00:32:33,460 --> 00:32:43,960
Because if I were to come up to you and say, hey, you know, I want you to show me HTTP packets, the first thing everyone's going to do is a DSP dump and an IE0 port 80.

506
00:32:44,520 --> 00:32:46,680
Well, that doesn't satisfy the other part.

507
00:32:46,680 --> 00:32:48,080
It needs to contain a payload, right?

508
00:32:48,080 --> 00:32:49,600
Plus anything could be on port 80.

509
00:32:49,640 --> 00:32:50,720
It doesn't have to be HTTP.

510
00:32:50,720 --> 00:32:51,760
It just probably is.

511
00:32:52,240 --> 00:32:57,380
Okay, so if we look at this again, think back to, you know, last time you did math, order of operations.

512
00:32:58,500 --> 00:32:59,720
We've got a color code here.

513
00:32:59,720 --> 00:33:06,260
So what we actually did was we looked for a TCP port 80 and we need the IPv4 total length, which we got.

514
00:33:06,260 --> 00:33:07,080
That was 60.

515
00:33:07,340 --> 00:33:09,480
The TCP header length, we got that.

516
00:33:09,480 --> 00:33:10,500
That was 20.

517
00:33:10,580 --> 00:33:11,920
Those are in the first parentheses.

518
00:33:11,920 --> 00:33:13,340
We have to break that down.

519
00:33:13,920 --> 00:33:21,580
And then whatever that resulting value is, which is, of course, 40, we need to subtract the TCP data offset from that.

520
00:33:22,320 --> 00:33:23,800
That gets us down to 20.

521
00:33:23,900 --> 00:33:25,460
It does not equal zero.

522
00:33:25,580 --> 00:33:28,260
I would generally agree that 20 does not equal zero.

523
00:33:28,680 --> 00:33:32,440
That brings our filter all the way down to TCP port 80 and true.

524
00:33:33,060 --> 00:33:39,520
So true is just a more of a Boolean kind of keyword type here, right?

525
00:33:39,520 --> 00:33:42,720
So it's not an actual TCP dump keyword that you can use.

526
00:33:42,720 --> 00:33:46,240
We're using it to display that TCP dump is looking at every packet.

527
00:33:46,240 --> 00:34:02,400
And unbelievably, you know, it's just the speed of, you know, traffic here, is performing all this math on every single packet that goes by and satisfying these values, doing this calculation, and seeing if it can satisfy your filter, TCP port 80, and this all has to work out to true.

528
00:34:02,680 --> 00:34:05,020
False, don't show it to me, right?

529
00:34:05,960 --> 00:34:06,760
Fantastic.

530
00:34:08,840 --> 00:34:09,840
All right.

531
00:34:10,060 --> 00:34:11,080
So success.

532
00:34:12,620 --> 00:34:16,600
So at the very top, again, you can see that I'm using TCP dump.

533
00:34:16,720 --> 00:34:18,540
And just go back to one of our first slides.

534
00:34:18,540 --> 00:34:21,780
I use XNR, dash R is to read a PCAP.

535
00:34:22,300 --> 00:34:27,100
So I'm reading HTTP.PCAP, which is one I pulled from a public traffic repository.

536
00:34:27,100 --> 00:34:27,960
There's a lot of those out there.

537
00:34:27,960 --> 00:34:31,340
I highly recommend using them as a playground to test these.

538
00:34:32,020 --> 00:34:35,820
And it did the filter we've been looking at on the cross, and we've got something.

539
00:34:36,640 --> 00:34:47,120
So if you're familiar with HTTP, what you can actually see in the ASCII here on the middle right-hand column here, you can actually see the get plus images, logo.png, HTTP slash one dot area.

540
00:34:47,120 --> 00:34:48,760
That's definitely an HTTP payload.

541
00:34:49,020 --> 00:34:51,400
And so we're successful.

542
00:35:01,900 --> 00:35:02,880
Let's see.

543
00:35:02,880 --> 00:35:04,940
Do we have any questions for our speaker?

544
00:35:09,050 --> 00:35:12,350
We got... it looks like we're actually missing a slide here.

545
00:35:14,990 --> 00:35:17,810
Let me just give you a couple of resources here real quick.

546
00:35:17,810 --> 00:35:22,670
So tcpdump.org is actually a fantastic resource.

547
00:35:23,810 --> 00:35:29,450
You know, for folks that have been around that long, I just can't believe how good of a job they've done with documentation.

548
00:35:30,230 --> 00:35:32,950
It's not necessarily always the case.

549
00:35:33,250 --> 00:35:37,550
tcpdump101.com, it will help you build filters like this with a GUI.

550
00:35:37,550 --> 00:35:40,590
Save yourself some time, help to play around with it, figure it out.

551
00:35:40,690 --> 00:35:44,810
The man pages for tcpdump and PCAP-filter, fantastic.

552
00:35:44,810 --> 00:35:49,850
The long filter we looked at today came from the tcpdump man pages.

553
00:35:50,170 --> 00:35:52,430
There's even an explanation at the bottom, right?

554
00:35:52,430 --> 00:35:54,990
One of the best man pages I've seen out there.

555
00:35:55,470 --> 00:36:00,630
If you're familiar with the awesome projects, awesome-pcap-tools, take a look at that page.

556
00:36:00,630 --> 00:36:04,730
I'm not just pushing it out there because I'm one of the maintainers of it.

557
00:36:04,730 --> 00:36:06,310
It's actually a great list.

558
00:36:06,750 --> 00:36:10,390
Take a look and please help, you know, if you have any tools that we're missing on there.

559
00:36:10,790 --> 00:36:16,930
If you felt intimidated by any of this and you're, you know, what the hell is he talking about, IV4, TCP, SYN, Synax?

560
00:36:17,010 --> 00:36:18,490
You need to brush up on your networking.

561
00:36:18,730 --> 00:36:21,310
Take a look at Professor Messer on YouTube.

562
00:36:21,490 --> 00:36:23,450
It's a fantastic network plus video series.

563
00:36:23,450 --> 00:36:25,330
You don't have to take the CERT if you don't care.

564
00:36:25,870 --> 00:36:28,110
But just the content in the series is worth your time.

565
00:36:28,110 --> 00:36:29,770
I think it's only like eight hours long.

566
00:36:32,090 --> 00:36:33,570
It's free training, right?

567
00:36:33,990 --> 00:36:34,490
That's right.

568
00:36:34,490 --> 00:36:35,170
It's free training.

569
00:36:35,170 --> 00:36:35,850
Absolutely.

570
00:36:37,030 --> 00:36:40,010
And final few pieces, some tips and tricks.

571
00:36:40,010 --> 00:36:43,770
A lot of people prefer Wireshark for their own reasons.

572
00:36:44,770 --> 00:36:53,650
It is possible to use SSH to pipe a TCP dump session back to your local host and have it display in Wireshark.

573
00:36:54,030 --> 00:36:56,030
Just Google that.

574
00:36:56,030 --> 00:36:58,830
There's a long SSH command that you can do it with.

575
00:36:58,830 --> 00:37:10,370
Another common thing that will come up in doing this at work is you're going to find out that, you know, there's going to be situations where, you know, this only happens when my database server sends this one weird packet at 2 a.m.

576
00:37:10,370 --> 00:37:11,770
ever since they did this update.

577
00:37:12,050 --> 00:37:13,310
You're not going to want to be there at 2 a.m.

578
00:37:13,310 --> 00:37:14,830
because it happens at 4 a.m.

579
00:37:15,910 --> 00:37:25,910
If you need to start a long-standing TCP dump with a complex filter, you can actually start it with an ampersand at the end, which, of course, in the Unix world is going to background that session for you.

580
00:37:25,990 --> 00:37:29,730
If you get disconnected, even if it's backgrounded, that's still going to kill the TCP dump.

581
00:37:29,730 --> 00:37:35,950
You can use a command called disown to separate the command from you and then disconnect.

582
00:37:35,950 --> 00:37:37,370
It'll keep running in the background.

583
00:37:37,370 --> 00:37:48,830
Whenever you come back in the morning and you need to kill that session and grab your PCAP, you can send a PCAP with the kill command to that PID and get the PCAP back.

584
00:37:49,330 --> 00:37:52,650
That's well over time here.

585
00:37:53,010 --> 00:37:54,730
Certainly appreciate everyone sticking around.

586
00:37:54,730 --> 00:37:56,690
If you have any questions, feel free to grab me.

587
00:37:56,690 --> 00:37:59,430
My Twitter handle is at404Scribbles.

588
00:37:59,670 --> 00:38:04,890
If you have any questions, any ideas or anything that you think I missed, certainly feel free to reach out.

589
00:38:04,890 --> 00:38:06,190
I'd love to chat and share ideas.

590
00:38:06,190 --> 00:38:06,790
Thank you.