[00:02.170 --> 00:07.210]  Let me introduce the next speaker, because we're right on the money with that talk.
[00:08.050 --> 00:12.510]  Let's see here, who's next? Scribbles! Where's Scribbles? Scribbles, you here?
[00:13.910 --> 00:15.150]  Scribbles here?
[00:15.330 --> 00:16.430]  Oh yeah, I'm here.
[00:16.730 --> 00:18.370]  Oh, okay, there you are. Sorry.
[00:18.410 --> 00:25.450]  Okay, Scribbles is our next speaker. He's going to be presenting Advanced Packet Wrangling with TCP Dump.
[00:25.550 --> 00:28.430]  This should be a very interesting talk, by the way.
[00:30.250 --> 00:36.370]  Scribbles, Stephen Kennedy, is a security engineer and a new Linux enthusiast in Denver, Colorado.
[00:36.370 --> 00:43.270]  He holds an MS, a master's degree in cybersecurity and information assurance, as well as over 20 industry certifications.
[00:43.950 --> 00:48.750]  Dude, do you ever sleep? I mean, 20 search? Seriously, where are you? That is impressive.
[00:48.750 --> 00:51.050]  Okay, I've got search on their heart again.
[00:51.050 --> 00:54.750]  I work for the university system, you know, they just keep paying me in search instead.
[00:55.610 --> 00:56.930]  Yeah, well, that's true.
[00:56.930 --> 01:04.030]  Yes, I know exactly what you mean. It's like, here's free money, go to another class. There you go.
[01:04.050 --> 01:15.750]  So, his first computer was a Commodore 64, and he's a survivor of the late 90s and early 2000s IRC.
[01:15.870 --> 01:19.230]  By the way, IRC is still alive and working. Thank you very much.
[01:19.230 --> 01:22.150]  So, without any further ado, here's Scribbles. Thank you.
[01:22.870 --> 01:26.850]  Wonderful. Thank you, X-Ray. Just a moment here.
[01:27.950 --> 01:30.170]  Oh, do you have access to the stage?
[01:30.610 --> 01:32.290]  I do. Yep.
[01:32.290 --> 01:33.170]  Okay.
[01:34.270 --> 01:38.670]  Just making sure that the stream is looking good too. Stream set up.
[01:38.750 --> 01:40.470]  Oh, they got it working.
[01:41.490 --> 01:42.650]  They did.
[01:43.550 --> 01:48.150]  Excellent. Well, our team has been in the background hacking like crazy. So, excellent.
[01:50.190 --> 01:51.990]  All right. Thanks, everyone.
[01:53.710 --> 01:56.110]  Let me make sure my slides are up over here as well.
[01:56.390 --> 02:02.770]  And definitely a big shout out to the Giglio team for figuring this out.
[02:02.850 --> 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.
[02:08.710 --> 02:12.770]  So, like X-Ray said, my name is Stephen Kennedy.
[02:13.910 --> 02:17.970]  Previously, I spent time as a network security consultant and a network security engineer.
[02:19.130 --> 02:22.150]  And, of course, if you're not familiar with the 14ers...
[02:23.250 --> 02:26.210]  Let me see if I can move this slide. This is the new form.
[02:27.650 --> 02:29.350]  Oh, I can do it myself. Nice.
[02:30.710 --> 02:31.850]  Come back and take a look.
[02:31.930 --> 02:36.910]  Yeah, so if you're not familiar with the 14ers, so those are mountain peaks over 14,000 feet.
[02:37.050 --> 02:40.810]  Or if you're not using Freedom Units, that'd be 4,267 meters.
[02:42.170 --> 02:44.190]  Let's see how far away I can test this.
[02:45.590 --> 02:46.790]  Oh, that's beautiful.
[02:47.830 --> 02:50.330]  Okay, so tcpdump and libpcap.
[02:51.270 --> 02:55.610]  These projects are both open source. They're developed by the tcpdump group.
[02:55.990 --> 02:59.970]  tcpdump is certainly the best known command line interface packet analyzer.
[03:00.290 --> 03:03.970]  You can basically open a terminal and see all the traffic on any of your network interfaces.
[03:03.970 --> 03:08.070]  If you do it on a busy enterprise box, you'll barely get a chance to see any text at all.
[03:08.070 --> 03:09.550]  It'll just all just screen by.
[03:10.650 --> 03:14.830]  And, you know, you'll just have to hit control C a hundred times to get it to finally stop.
[03:16.210 --> 03:20.450]  So the important part about tcpdump is to build filters to slow some of that stuff down.
[03:20.990 --> 03:25.470]  So it was first released in 1988, and I believe it or not, it is still in active development.
[03:25.470 --> 03:29.550]  It's still an extremely useful tool, and it's absolutely keeping up with the times.
[03:29.830 --> 03:34.390]  So, you know, a big part of this talk is encouraging you to dive deep on this one.
[03:35.110 --> 03:41.190]  So libpcap is the library that tcpdump uses to interface with the kernel.
[03:41.190 --> 03:47.510]  In Windows, this is called WinPCAP, and the Windows version of tcpdump is called WinDump.
[03:51.740 --> 03:53.440]  And... let's see here, yep.
[03:53.440 --> 03:57.040]  So right around 1993 at USENIX, if you're not familiar with USENIX,
[03:57.040 --> 04:01.600]  it's a famous conference where a lot of technical papers are presented.
[04:01.780 --> 04:06.860]  But back in 1993, the folks that created tcpdump at Lawrence Berkeley Laboratories
[04:06.860 --> 04:13.220]  actually delivered a paper on what they called BSD packet filters.
[04:13.420 --> 04:16.340]  You might have seen the phrase BPF being thrown around.
[04:16.340 --> 04:18.820]  It's usually associated with tcpdump.
[04:18.960 --> 04:24.280]  At this point, BPF has exploded into a number of uses and ways to filter
[04:24.280 --> 04:28.240]  and access all these other bits of information that require really quick access
[04:28.240 --> 04:31.740]  because, you know, the CPU is really quick, there's a lot of process activity.
[04:31.780 --> 04:34.700]  It's no longer just about network activity.
[04:34.700 --> 04:38.680]  But if you start searching around, you'll see that most of the stuff online
[04:38.680 --> 04:42.340]  about it is going to be somehow relating to network filtering.
[04:45.280 --> 04:47.140]  All right, so next slide here.
[04:48.700 --> 04:50.560]  This is the why should I care slide.
[04:50.880 --> 04:53.160]  So this is a pretty important part, right?
[04:53.160 --> 04:56.060]  So whenever people hear that tcpdump is, you know, from 1988,
[04:56.060 --> 04:59.220]  there's a little bit of that, you know, I'm trying to be dragged
[04:59.220 --> 05:02.280]  back into Linux command line again, and I've never seen this stuff before,
[05:02.280 --> 05:04.460]  how long is this going to take to learn, stuff like that, right?
[05:05.260 --> 05:08.440]  This is an incredibly useful tool for your skill set.
[05:08.600 --> 05:11.440]  And I really want to prove that out to you.
[05:11.520 --> 05:15.820]  The PCAP or it didn't happen picture on the previous slide.
[05:15.820 --> 05:18.080]  So, you know, it's popular slogan for shirts and everything.
[05:18.320 --> 05:20.540]  It's not just a clever phrase, right?
[05:20.580 --> 05:23.940]  It's generally true. If it didn't go across the wire,
[05:23.940 --> 05:25.460]  it probably didn't happen.
[05:26.580 --> 05:29.180]  You know, perhaps there's scenarios where you're blocked from viewing it.
[05:29.180 --> 05:30.160]  And sure, right?
[05:30.820 --> 05:32.520]  Those are few and far between.
[05:32.520 --> 05:36.000]  So it's very important as a tool to be able to prove things
[05:36.000 --> 05:39.440]  that you need to prove to someone else or to prove that someone's claiming to you.
[05:40.300 --> 05:41.580]  So how would that work?
[05:41.600 --> 05:46.560]  So, you know, I think if you've ever worked in an IT environment,
[05:46.560 --> 05:50.300]  you've been on either side of this conversation and probably will be
[05:50.300 --> 05:51.460]  for the rest of your career.
[05:51.460 --> 05:54.040]  But that conversation where maybe you're a server owner
[05:55.240 --> 05:58.320]  and you just stood up or maybe you own a couple of servers, right?
[05:58.320 --> 06:00.220]  A couple of services running on it.
[06:00.220 --> 06:02.060]  And one of your co-workers just stood up a new server
[06:02.440 --> 06:04.060]  and it needs to connect to yours.
[06:04.120 --> 06:06.240]  And they come to you and say, hey, I need this, you know,
[06:06.720 --> 06:09.800]  can you give me this token or whatever so I can connect to your service?
[06:09.800 --> 06:11.680]  You go, yep, made an account for your token.
[06:12.660 --> 06:15.340]  Go do your thing and configure the stuff that you own.
[06:15.980 --> 06:18.800]  And then they come back and they go, well, hey, you know,
[06:19.360 --> 06:22.600]  I configured it and the only message that I got was connection failed.
[06:22.960 --> 06:23.480]  Right?
[06:23.800 --> 06:26.300]  So connection failed doesn't tell us very much.
[06:26.480 --> 06:29.600]  Is it a, you know, is the network actually down?
[06:30.440 --> 06:32.580]  Did we, did something actually fail?
[06:32.580 --> 06:34.380]  It doesn't, it doesn't tell us very much of anything.
[06:34.380 --> 06:35.960]  Did it even try to get on the network?
[06:36.160 --> 06:38.620]  Maybe it can't even access the network adapter itself.
[06:39.940 --> 06:41.800]  So error messages can be terrible.
[06:41.800 --> 06:43.060]  I think we all know that.
[06:43.580 --> 06:46.140]  You know, and developers can be very hit or miss on that sort of thing.
[06:46.140 --> 06:49.580]  And log messages in general are, you know, aren't always much greater.
[06:49.580 --> 06:51.940]  So this is that part where you can start to lean on the network
[06:51.940 --> 06:53.100]  to be like, well, wait a minute.
[06:54.080 --> 06:56.640]  So me as the server owner, if my co-worker comes to me and says,
[06:56.640 --> 06:59.020]  hey, I tried to connect to you and it just didn't work.
[06:59.420 --> 07:02.620]  One of the first things I'm probably going to do is, you know,
[07:02.620 --> 07:04.460]  we're obviously going to double check the information that he was given.
[07:04.460 --> 07:07.460]  Maybe the IP was wrong or something like that.
[07:07.580 --> 07:10.660]  But if you use a tool like TCPDOM, you can say, hey, well, what's your server IP?
[07:11.500 --> 07:13.420]  Go ahead and try to connect to me again.
[07:13.420 --> 07:16.800]  And if I don't see any traffic come to my interface,
[07:16.800 --> 07:19.060]  there's something else that's going on, right?
[07:19.060 --> 07:21.160]  We've already ruled out this entire service.
[07:21.160 --> 07:23.740]  And, you know, again, if you're in that IT space,
[07:23.740 --> 07:26.660]  you know that you just stopped an entire circus from happening,
[07:26.660 --> 07:28.060]  potentially five meetings, right?
[07:28.920 --> 07:32.220]  So it's very important that you be able to rule things out.
[07:33.120 --> 07:34.760]  Improving their claim, right?
[07:34.760 --> 07:39.680]  And so another great example is that, you know, in a past life,
[07:39.680 --> 07:42.980]  I was working for a vendor that sold security appliances.
[07:43.760 --> 07:46.820]  And a customer had one installed in Tokyo.
[07:47.120 --> 07:51.260]  And this appliance would make a tunnel back to a data center in the U.S.
[07:51.440 --> 07:53.060]  And the tunnel kept failing.
[07:53.060 --> 07:55.980]  And the response from the customer is, you know, as you'd expect,
[07:55.980 --> 07:57.600]  you know, they paid a lot of money for it,
[07:57.600 --> 08:00.780]  is your appliance is broken, you need to figure it out and fix it.
[08:02.300 --> 08:05.080]  And so we started looking at the appliance,
[08:05.080 --> 08:08.200]  and it took a bit to, you know, see what was going on.
[08:08.200 --> 08:10.320]  And every time the tunnel would open,
[08:10.320 --> 08:12.900]  we were looking at it from the point of view of the box that's in Tokyo.
[08:13.040 --> 08:16.280]  Every time we see that SYN go out, we'd immediately get a reset back.
[08:16.800 --> 08:18.780]  Right? And so if you think about it, you know,
[08:18.780 --> 08:22.620]  you don't have to know a ton about, you know, networking to realize that,
[08:23.020 --> 08:26.100]  you know, one millisecond or less isn't enough time for that SYN
[08:26.100 --> 08:31.120]  to go from Tokyo to Atlanta. Right? That's breaking the laws of physics.
[08:32.100 --> 08:34.580]  So if we're immediately getting a reset,
[08:34.580 --> 08:36.000]  right after we attempt that connection,
[08:36.000 --> 08:39.260]  we know that there's another network device nearby, potentially,
[08:39.260 --> 08:42.540]  maybe even in the same office, that's sending that reset.
[08:42.540 --> 08:44.400]  And so we were immediately able to call that out
[08:44.400 --> 08:47.680]  and get their network engineers on the line and be like, what is this?
[08:47.900 --> 08:50.300]  Look at the timestamps, like this doesn't make sense.
[08:50.340 --> 08:51.600]  And boom, you know,
[08:51.600 --> 08:54.760]  they found out that they hadn't actually properly implemented the ACLs.
[08:54.760 --> 08:57.740]  And the connection was open and the tunnel was able to work.
[08:58.460 --> 09:01.980]  Right? So the point of the story is, of course, being that, you know,
[09:02.720 --> 09:05.820]  this tool can look very esoteric, but it's important.
[09:06.720 --> 09:09.920]  And third, of course, threat actors aren't the only ones that live off the land.
[09:09.920 --> 09:12.620]  Whenever we hear that phrase, we always think about, you know,
[09:12.620 --> 09:14.220]  threat actors having to come in and, you know,
[09:14.220 --> 09:16.360]  they can't, you know, upload certain tools.
[09:16.360 --> 09:17.880]  So they have to live off the land. Right?
[09:19.280 --> 09:21.540]  That happens to us too. Right?
[09:21.540 --> 09:24.380]  So when you work in a highly regulated or highly secured environment,
[09:24.760 --> 09:28.720]  if you have customers that are, you know, in the energy industry,
[09:28.720 --> 09:30.080]  or potentially, you know,
[09:30.080 --> 09:34.080]  if you're working in a FedRAMP environment with government customers,
[09:34.080 --> 09:35.200]  you know this problem well.
[09:35.200 --> 09:36.440]  Whenever you run into a problem,
[09:36.440 --> 09:38.900]  someone's always going to bring up some really slick tool from GitHub
[09:38.900 --> 09:42.280]  that was just written four weeks ago, probably in Go.
[09:43.600 --> 09:46.260]  And you can't just go download and install that.
[09:46.260 --> 09:47.860]  It would break compliance regulations.
[09:47.860 --> 09:49.240]  You'd be tons of paperwork.
[09:49.380 --> 09:52.740]  And this is generally, you know, what we call, you know,
[09:52.740 --> 09:54.240]  if you try to circumvent those sorts of things,
[09:54.240 --> 09:57.740]  it's generally what we consider a career limiting move. Right?
[09:58.380 --> 10:00.240]  So those are the important pieces that, you know,
[10:00.240 --> 10:05.560]  I just really wanted to highlight and make sure that we got through here
[10:05.560 --> 10:07.020]  when we were talking about TCP dump.
[10:07.280 --> 10:11.120]  So this is a skill that also pays dividends. Right?
[10:11.120 --> 10:13.660]  The more you invest in this, the more you practice,
[10:13.660 --> 10:15.280]  the better you're going to get at it.
[10:15.400 --> 10:19.280]  Some of the technical details here, if you don't practice them,
[10:19.280 --> 10:22.180]  it's not going to stick. It's just like anything else in life.
[10:22.180 --> 10:25.400]  But it's not as hard as it can look initially.
[10:25.620 --> 10:28.100]  So please understand that this does require a basic understanding
[10:28.100 --> 10:30.180]  of the TCP IP protocol stack.
[10:30.320 --> 10:32.780]  If you're a networking newbie, this will help you get an idea
[10:32.780 --> 10:34.720]  of what's possible with this tool.
[10:43.260 --> 10:44.980]  So once we get through the syntax,
[10:44.980 --> 10:46.960]  we're going to do some more advanced filter techniques,
[10:46.960 --> 10:50.800]  but certainly don't be discouraged because things will get a little weird here.
[10:50.800 --> 10:51.800]  We'll stick with...
[10:53.460 --> 10:56.780]  So some basic syntax, you've probably seen a good bit of this,
[10:57.180 --> 10:59.380]  if you are familiar with TCP dump.
[11:00.180 --> 11:04.980]  So on the left here, we've got our flags, color-coded.
[11:04.980 --> 11:06.860]  So if we look at the command across the top, right?
[11:06.860 --> 11:09.040]  So we've got capital X, so that's going to show the output
[11:09.040 --> 11:11.180]  in both hexadecimal and ASCII.
[11:11.460 --> 11:13.780]  The N is don't resolve hosts and ports.
[11:14.080 --> 11:16.920]  Typically, we do that just because we just want to see port numbers
[11:16.920 --> 11:17.940]  and we want to see IP.
[11:17.940 --> 11:20.680]  I don't want resolution and DNS getting in the way
[11:20.680 --> 11:22.320]  because we know that that always gets messy.
[11:23.860 --> 11:25.300]  For I, also very important one,
[11:25.300 --> 11:27.560]  we want to specify the network interface we're monitoring.
[11:28.680 --> 11:30.940]  So in this example, we're going to be looking at eth0.
[11:30.940 --> 11:33.280]  And then for the dash C, we're going to specify the packet count,
[11:33.280 --> 11:37.520]  which this way you can say, hey, you might match a million packets
[11:37.520 --> 11:39.100]  with this filter, just show me five.
[11:39.100 --> 11:40.340]  That'd be great, right?
[11:41.200 --> 11:43.700]  So we look on the right side here, filters and operators.
[11:45.260 --> 11:47.080]  So pretty easy to read in English.
[11:47.080 --> 11:50.100]  So right after we get past that C5 on the top left,
[11:50.100 --> 11:52.880]  we're going to move into what I put in single quotes.
[11:52.880 --> 11:56.460]  The reason you typically want to do that is because the TCP DOM filters
[11:56.460 --> 12:00.200]  can start to use characters that might be interpreted by your shell.
[12:00.680 --> 12:02.920]  I'm talking about like an ampersand or parentheses
[12:02.920 --> 12:05.200]  or things you might have to escape otherwise.
[12:05.300 --> 12:07.780]  It gets messy, just use single quotes,
[12:07.780 --> 12:09.140]  and then you don't have to worry about it.
[12:09.980 --> 12:12.940]  So TCP and, you see we've got open parentheses.
[12:13.440 --> 12:15.820]  That's matched by a closed parenthesis on the other end of the line.
[12:15.820 --> 12:18.260]  Remember, this is just like in math class,
[12:18.260 --> 12:21.080]  order of operations, we're going to start with the parentheses first.
[12:21.200 --> 12:23.860]  And what we're saying here is source host, this IP address,
[12:24.420 --> 12:26.700]  or source host, this other IP address.
[12:27.240 --> 12:30.340]  So this filter is going to show us any packet that is TCP
[12:31.220 --> 12:34.380]  and source from either of those hosts.
[12:34.640 --> 12:35.880]  Easy enough, right?
[12:36.020 --> 12:37.920]  We can also see that there's other things you can do.
[12:37.920 --> 12:39.380]  You can do ports, port ranges.
[12:39.620 --> 12:43.400]  You can specify protocols, TCP, UDP, ISP multicast.
[12:43.400 --> 12:45.600]  I said NOT and OR at the bottom line.
[12:45.600 --> 12:47.180]  I wanted to hit that one first.
[12:47.180 --> 12:48.520]  Look right above it.
[12:48.660 --> 12:51.740]  Of course, the NOT and the negation is the estimation point.
[12:52.240 --> 12:55.280]  Just like in bash, the double ampersand is an AND.
[12:55.420 --> 12:58.180]  Just like in everything else, the double pipe is an OR.
[12:58.480 --> 13:00.340]  And we have some other characters that are available to us,
[13:00.340 --> 13:03.540]  less than, greater than, equals, and parentheses to help divide some things.
[13:07.540 --> 13:09.120]  Okay, so...
[13:11.220 --> 13:13.080]  filtering of the transporter network letters.
[13:13.080 --> 13:18.760]  So a really cool feature of TCPdump is that you do have some convenience flags.
[13:18.760 --> 13:21.400]  This is done by the development team, you know, just kind of thrown in there
[13:21.400 --> 13:24.640]  some really common things that you're going to need to do.
[13:24.740 --> 13:26.760]  There's no reason to bring math into this, right?
[13:26.760 --> 13:30.760]  Like, let's just do something easy where we can look at a table and figure this out.
[13:30.760 --> 13:33.080]  Again, this is pretty English readable.
[13:33.120 --> 13:34.400]  You'll see the flags on the left.
[13:34.400 --> 13:37.940]  If you're familiar with the TCP protocol, you'll recognize the flag names.
[13:38.740 --> 13:43.100]  What we have is, you know, TCP FIN, TCP SIN, RESET, PUSH, ACK.
[13:43.100 --> 13:46.540]  And then the message types, these are all ICMP messages down here.
[13:46.540 --> 13:49.240]  So the most common ones you're going to recognize are, of course,
[13:49.240 --> 13:51.980]  ICMP message type 8 and message type 0,
[13:51.980 --> 13:54.460]  which are ECHO and ECHO REPLY or PING and PING REPLY.
[13:54.460 --> 13:56.180]  That's the most common way of knowing it.
[13:56.880 --> 13:59.240]  So in the examples up here,
[13:59.240 --> 14:01.740]  let's look at one of these written out using some of these keywords.
[14:01.740 --> 14:04.660]  So we have TCP and then in square brackets, TCP flags.
[14:05.120 --> 14:09.940]  And parenthesis, TCP SIN or TCP FIN does not equal 0.
[14:11.020 --> 14:13.280]  So it's pretty obvious what the first part does, right?
[14:13.320 --> 14:16.840]  So we're filtering on the TCP flag section of the TCP header.
[14:17.120 --> 14:22.100]  And I want you to show me packets where either the TCP SIN flag,
[14:22.100 --> 14:24.180]  or remember that pipe is an OR,
[14:24.180 --> 14:27.160]  or the FIN packet is not 0.
[14:27.520 --> 14:30.640]  So remember, a packet is actually binary when it's on the wire.
[14:30.640 --> 14:32.860]  It's a 1 or a 0, it's on or off.
[14:32.860 --> 14:35.600]  So if it does not equal 0, then it must be a 1,
[14:35.600 --> 14:37.160]  which means it must be on.
[14:37.300 --> 14:40.100]  So show me packets where SIN or FIN are on.
[14:40.640 --> 14:44.120]  And same thing with the ICMP message down here.
[14:44.120 --> 14:45.100]  Pretty straightforward.
[14:45.100 --> 14:48.440]  ICMP type does not equal ICMP ECHO,
[14:48.440 --> 14:50.660]  and it does not equal ICMP ECHO REPLY.
[14:50.660 --> 14:56.100]  That would essentially show you every ICMP packet that is not related to PING.
[14:57.160 --> 14:58.280]  It's simple, right?
[14:58.680 --> 15:00.280]  Let's move on to the next slide here.
[15:09.410 --> 15:14.330]  All right, so the big question is we see those keywords, right?
[15:14.330 --> 15:16.810]  And they're very convenient, very nice, easy to remember.
[15:18.090 --> 15:19.750]  And things start getting weird.
[15:19.750 --> 15:22.430]  So how do those keywords work?
[15:22.910 --> 15:24.050]  Why are they convenient?
[15:24.050 --> 15:26.050]  And why would they go out of their way to do this for us?
[15:26.270 --> 15:30.030]  How do they go into a packet and pull out that section of the packet?
[15:30.070 --> 15:33.650]  So in this diagram here, the big part in the center,
[15:33.650 --> 15:36.630]  so that's actually the TCP header, right?
[15:36.630 --> 15:37.790]  So if you're familiar with TCP IP,
[15:37.790 --> 15:40.290]  you'll know that typically the IPv4 header is at the top.
[15:40.290 --> 15:45.330]  And then in order to get around, TCP needs its own... requires IPv4.
[15:45.390 --> 15:47.990]  And so below the IPv4 header, you'll have the TCP header,
[15:47.990 --> 15:51.190]  and then the payloads, all the data that's being moved around below that.
[15:51.350 --> 15:54.530]  This TCP, you'll notice in this header, doesn't talk about IP addresses.
[15:54.610 --> 15:56.150]  It just talks about ports.
[15:56.250 --> 15:58.390]  IP addresses are up in the IPv4 header.
[16:00.170 --> 16:04.370]  So when we talk about TCP SYN, TCP FIN, what's actually happening?
[16:04.370 --> 16:06.610]  And again, these are examples from previously.
[16:07.630 --> 16:09.990]  You look down at byte 13 down here.
[16:09.990 --> 16:11.870]  In green, you'll see TCP flags.
[16:12.490 --> 16:14.770]  It says C-E-U-A-P-R-S-F.
[16:15.590 --> 16:19.310]  So what that actually is, is those are all of the TCP flags.
[16:19.450 --> 16:21.490]  Look on the left-hand side over here.
[16:21.790 --> 16:26.230]  What we have is this table that's showing ERJAC, PUSH, RESET, SYN, FIN.
[16:27.370 --> 16:29.970]  So these are a lot of the flags that you hear on a regular basis,
[16:29.970 --> 16:32.570]  the SYN, SYNAC, ACK for the TCP three-way handshake.
[16:33.170 --> 16:35.030]  The order of those matters.
[16:35.970 --> 16:38.470]  And so when we're going in and we're looking at a header like this,
[16:38.470 --> 16:39.910]  it can be very confusing.
[16:40.410 --> 16:43.390]  So there's lots of numbers and lines and things like that.
[16:43.450 --> 16:47.590]  So at the very top left is byte offset zero.
[16:47.590 --> 16:50.410]  That's the beginning of the TCP header.
[16:51.170 --> 16:53.530]  So for the next eight open slots here,
[16:53.530 --> 16:55.610]  so we'll count them off, 1, 2, 3, 4, 5, 6, 7, 8,
[16:55.610 --> 16:57.670]  so where that one is right above the word source,
[16:58.070 --> 16:59.330]  that's a whole byte.
[16:59.330 --> 17:00.790]  And one byte is eight bits.
[17:01.190 --> 17:03.630]  And you'll see there's a line in the middle that's a little bit darker.
[17:03.630 --> 17:05.650]  So a half byte is called a nibble.
[17:05.650 --> 17:07.230]  So four bits is a nibble.
[17:07.230 --> 17:08.550]  Eight bits is a byte.
[17:09.410 --> 17:11.210]  So it's pretty easy to say.
[17:11.210 --> 17:14.070]  The source port field of the TCP header takes up two whole bytes.
[17:14.510 --> 17:15.750]  Easy enough.
[17:16.110 --> 17:21.770]  So if we look on the top left where this binary diagram is,
[17:21.770 --> 17:28.950]  what we'll see is actually the top column in blue is 128, 64, 32, 16, 8, 4, 2, 1.
[17:28.950 --> 17:32.290]  You'll see that 128 keeps getting cut in half as we go.
[17:32.290 --> 17:34.310]  And then there's ones and zeros along it.
[17:34.370 --> 17:38.090]  So think of each of these slots or each of the columns there.
[17:38.150 --> 17:39.150]  There's eight of them.
[17:39.150 --> 17:41.390]  They match up with the eight bits in a byte.
[17:42.550 --> 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.
[17:51.010 --> 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.
[17:56.850 --> 18:01.690]  So in this diagram up here, so we see it's 1, 0, 1, 1, 0, 0, 0, 1.
[18:01.690 --> 18:05.770]  All you have to do is where there's a one, you just add that number. It's that simple.
[18:06.030 --> 18:09.170]  128 plus 32 plus 16 plus 1 equals 177.
[18:09.550 --> 18:11.770]  I mean, that's binary math, right?
[18:11.770 --> 18:13.890]  It's really just adding where there's a one.
[18:13.970 --> 18:19.470]  And just know that after that one at the very end here, along the top column, it just starts over again.
[18:19.690 --> 18:23.410]  At 1, so it goes 4, 2, 1, 128, 64, 32.
[18:23.410 --> 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.
[18:28.390 --> 18:32.390]  And that's how your computer is interpreting these values, your network card, rather.
[18:32.990 --> 18:36.450]  So back to the point about the filter examples.
[18:36.950 --> 18:42.390]  So we already went over the verbal one or the keyword one, TCP SYN or TCP FIN does not equal zero.
[18:42.710 --> 18:45.690]  But the line below it is actually equivalent.
[18:46.170 --> 18:49.370]  So TCP 13 and 2 or 1 does not equal zero.
[18:49.990 --> 18:55.390]  So you might have put two and two together now and realized that that TCP 13, the reason that's equivalent to TCP flags,
[18:55.390 --> 18:59.970]  well, TCP flags where it's green right here is actually byte 13 of the TCP header.
[18:59.970 --> 19:02.230]  We're saying start it that byte.
[19:02.710 --> 19:05.430]  What about this AND part? So AND 2 or 1?
[19:05.650 --> 19:09.810]  Go back up to the binary chart. That's the two bits on the far right of the 13th byte here.
[19:09.810 --> 19:12.330]  There's the S and the F, the SYN and the FIN.
[19:12.730 --> 19:19.190]  So if there's a 1 and a 1 here, then we could match.
[19:21.550 --> 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.
[19:30.390 --> 19:34.250]  And that's about as hard as this gets. It gets a little weirder, but that's about as hard as it gets.
[19:34.250 --> 19:37.270]  So if you're following me there, you're doing a great job.
[19:39.870 --> 19:41.110]  The next slide.
[19:47.230 --> 19:49.410]  We can get a lot more precise than that.
[19:50.630 --> 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.
[19:56.890 --> 19:58.310]  I've certainly been there.
[19:59.290 --> 20:04.650]  This is whenever those keywords don't match what you need to look for in TCP dumper on the wire.
[20:05.050 --> 20:08.390]  So we start seeing things. Some of this might make sense based on what we've been talking to.
[20:08.390 --> 20:11.630]  We've got IP, sure. I see the brackets where they have the byte numbers.
[20:11.630 --> 20:15.270]  I can look at those, right? TCP 12. Not equal zero.
[20:15.930 --> 20:17.390]  What does any of this mean?
[20:19.450 --> 20:21.250]  And where do we even begin?
[20:21.250 --> 20:23.070]  So we're going to break this down into three parts.
[20:23.070 --> 20:25.750]  The TCP port 80 and pretty straightforward.
[20:26.810 --> 20:29.350]  But we're going to break this down into three filters. We've got the blue one here.
[20:29.970 --> 20:32.490]  What is that? Coral? We'll go with coral.
[20:32.490 --> 20:35.850]  And then this yellow-ish color here.
[20:35.990 --> 20:39.610]  We're going to break this into three different filter pieces and go through them.
[20:43.790 --> 20:47.650]  All right. So this is the IPv4 header, RC791.
[20:49.970 --> 20:54.730]  The filter we're looking at is the first part of the original one on the previous slide here.
[20:54.930 --> 21:00.590]  So we're looking at IP 2 and 2 as the first portion of what we want to figure out.
[21:00.730 --> 21:03.410]  Because the goal here is just to figure out what it is that this filter does.
[21:04.590 --> 21:07.810]  So, okay. So IP 2 and 2. So we hadn't seen the colon 2 before.
[21:07.870 --> 21:10.390]  But we know that that 2 probably means the second byte.
[21:10.470 --> 21:12.710]  So the top left, we see the offset and length.
[21:13.110 --> 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.
[21:17.530 --> 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.
[21:25.250 --> 21:28.190]  So from byte 2, 1, 2. And there's the end of the line.
[21:28.230 --> 21:32.130]  So we're basically done with the IP 2 and 2 portion.
[21:32.130 --> 21:35.930]  If you look at the header, we know that it's asking for the total length field.
[21:35.930 --> 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.
[21:43.870 --> 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.
[21:49.510 --> 21:55.590]  So total length is the total length of the IP diagram, or IP fragmented, and it's measured in bytes.
[21:55.590 --> 22:00.450]  That's already in bytes, and that's what we probably want. So we're just going to go with that. Easy.
[22:02.130 --> 22:10.390]  All right. But then the next one is this IP 0 and 0xfslsn2.
[22:10.390 --> 22:16.710]  All right. So that looks pretty strange. Let's move on to the next one and take a look.
[22:21.020 --> 22:23.560]  So we're going to validate our length field here.
[22:23.960 --> 22:27.440]  So this is the first time that we're taking a look at the TCP dump output.
[22:28.400 --> 22:33.320]  I hope everyone can see this. I'm going to slide down here so I can get a first look as well.
[22:33.820 --> 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.
[22:42.500 --> 22:47.900]  Great. So on the third line of this whole screen here is a timestamp, that 1345.
[22:48.160 --> 22:53.020]  Each one of these timestamps is a packet that matched that filter that TCP dump is outputting and showing us.
[22:53.940 --> 23:01.280]  As we read across, we see IP 192.168.1.140 is reaching out to this 174 address in port 80.
[23:01.400 --> 23:06.920]  I'm going to make a leap and say that's probably HTTP traffic. I think that's safe to say, right?
[23:07.680 --> 23:11.900]  As a little bit further than that, it says flags, bracket, S bracket.
[23:12.340 --> 23:18.300]  So in TCP dump output, that S actually represents that SYN flag being on, the TCP SYN.
[23:18.800 --> 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.
[23:26.300 --> 23:29.980]  So what we're seeing here is part of the three-way handshake. So we see S and S dot.
[23:29.980 --> 23:33.580]  So the host that received the SYN reply back with his SYN ACK.
[23:34.640 --> 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.
[23:41.340 --> 23:43.600]  So why is it all the way over here in these weird characters?
[23:44.240 --> 23:48.940]  So if you've never seen HEX before, hopefully you have, but if you haven't,
[23:48.940 --> 23:54.460]  HEX is typically represented when it's written beginning with 0x in order to separate it from other types of values like decimal.
[23:55.420 --> 24:01.220]  HEX is a base 16 counting system. So we're doing 0 through 9 and A through F are the valid characters.
[24:01.220 --> 24:06.400]  So F is 15. The reason why F is not 16 in the base 16 counting system is because we count from 0.
[24:07.900 --> 24:13.080]  So 003C. So each character up there is actually one nibble.
[24:13.140 --> 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.
[24:20.760 --> 24:31.060]  That's that 4. IHL, that's a 5. Type of service, 0. Next nibble, 0. Now we're into the red box. 003C, so first nibble, 0.
[24:31.060 --> 24:38.160]  Second nibble, 0. Then there's a 3, then there's C. Well, 3C doesn't make any sense to us. We thought this was supposed to be in bytes.
[24:38.560 --> 24:43.260]  Well, it is. It's just in hexadecimal right now. So we have to convert that to decimal.
[24:43.340 --> 24:50.940]  At the very top, just above the screenshot, you can see HEX003C equals 60. You convert that value to decimal, that's 60 bytes.
[24:52.140 --> 25:01.960]  All right. This next slide here.
[25:03.880 --> 25:12.140]  So back to the second part of the coral filter, IP0 and 0xf, less than, less than 2.
[25:12.180 --> 25:16.200]  So what's actually going on here? I'm going to exit the stage here for a moment.
[25:18.960 --> 25:26.700]  So we're going to start at the very top left. And what we can see is that IP0, simple enough.
[25:26.700 --> 25:30.460]  We're going to look at the IP header. We're going to start at byte offset 0. Show me that first byte. Great.
[25:30.460 --> 25:33.120]  There's the first two nibbles, right? Two nibbles and a byte.
[25:34.340 --> 25:38.200]  And so that part's done, but we haven't finished dealing with the rest of the parentheses yet.
[25:38.200 --> 25:45.960]  So that ampersand 0xf, the ampersand is telling you that we're going to bit mask.
[25:46.920 --> 25:53.340]  And so what we're going to do is we're going to mask these eight bits in this single byte.
[25:54.220 --> 25:59.040]  And what that means is that we need to take that hexadecimal F, we need to convert it to decimal.
[25:59.540 --> 26:04.900]  F in decimal is 15, like we were just talking about. And in binary, it's 1111.
[26:05.560 --> 26:13.840]  Why is it 1111? Well, again, if we imagine the 128, 64, 32, 16, 8, 4, 2, 1 across each bit in this byte,
[26:13.840 --> 26:20.600]  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.
[26:21.580 --> 26:25.720]  And so that's why we opted to give it the hex F value.
[26:25.720 --> 26:36.360]  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,
[26:36.360 --> 26:40.020]  but I really needed a half byte, and that doesn't help me very much.
[26:40.020 --> 26:48.160]  So I want you to start at 0 and now use this mask to carve out this nibble for me.
[26:48.460 --> 26:52.620]  And you can do this a lot of different ways. There's a lot of cool tricks you can do, but this is the concept.
[26:53.460 --> 27:02.260]  So the IHL field in tcpdump, I'm sorry, in the IP header is actually the header length.
[27:02.960 --> 27:06.500]  And so this typically almost always is a 5.
[27:06.700 --> 27:10.740]  And so the reason for that is that IP options are generally no longer used.
[27:10.740 --> 27:13.320]  The IP options is the last field in an IP header.
[27:14.480 --> 27:18.240]  So there's just one of these things in life that you just have to accept.
[27:18.240 --> 27:21.860]  It's a weird rule where the story takes longer than it does remember the rule.
[27:21.860 --> 27:25.200]  You just need to remember that when that field has a value in it, you multiply it by 4,
[27:25.200 --> 27:28.340]  and that tells you the number of bytes that the header is.
[27:28.340 --> 27:31.280]  It's almost always 20 bytes, because again, IP options just aren't used.
[27:31.600 --> 27:35.020]  So I went ahead and put that 5 over here, right?
[27:35.020 --> 27:37.200]  And below it, we have the binary chart.
[27:37.440 --> 27:41.160]  And so we finished the parentheses, and we're still left with that less than, less than 2.
[27:41.200 --> 27:42.200]  So what does that mean?
[27:43.360 --> 27:47.980]  So the less than 2 actually means we're going to bit shift the value in parentheses by 2.
[27:48.600 --> 27:52.300]  If you haven't heard of bit shifting, it sounds really complicated and cool.
[27:52.300 --> 27:53.860]  It's extremely simple.
[27:53.920 --> 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?
[28:01.000 --> 28:06.540]  But the interesting part is that bit shifting left by 2 is the same thing as multiplying by 4.
[28:08.180 --> 28:11.720]  I say that again, bit shifting left by 2 is the same as multiplying by 4.
[28:11.720 --> 28:14.980]  And the reason that is, is we come over here and look.
[28:17.630 --> 28:21.830]  We have 0, 1, 0, 1 in this left binary table here, right?
[28:21.830 --> 28:23.150]  So 8, 4, 2, 1.
[28:23.270 --> 28:29.390]  All I did was literally slid the value in the left table 2 bits over,
[28:29.390 --> 28:32.450]  and any new spaces that are created, you just throw a 0 in there.
[28:32.590 --> 28:35.090]  We can't create new ones, right?
[28:35.090 --> 28:37.890]  So then it just becomes 1, 0, 1, 0, 0.
[28:38.730 --> 28:44.490]  So we essentially multiplied by 4 because we went from 4 and 1 makes 5 to 16 and 4 makes 20.
[28:44.890 --> 28:47.630]  It's an interesting bit of binary math, and also, you know,
[28:47.630 --> 28:56.730]  if you've never delved into how CPUs at a very low level do complex math,
[28:56.730 --> 28:59.110]  this is the very beginning of how that stuff works.
[28:59.150 --> 29:02.130]  The advanced stuff has been above my head for a long time,
[29:02.130 --> 29:06.270]  but this is a very general idea of how that binary math works.
[29:07.810 --> 29:09.590]  So that's it, right?
[29:09.590 --> 29:11.410]  So one of the most intimidating pieces.
[29:13.750 --> 29:15.650]  So on to the third filter.
[29:17.810 --> 29:19.670]  This looks very much the same.
[29:19.670 --> 29:21.090]  You already know what to do here.
[29:21.150 --> 29:24.630]  So we're starting with the TCP header.
[29:24.750 --> 29:29.350]  We started the 12th byte, and we can see the header up here at the very top right.
[29:29.350 --> 29:32.190]  So the 12th byte, we look on the left-hand column.
[29:32.250 --> 29:34.470]  There's those byte offset values in red.
[29:34.470 --> 29:35.790]  You can actually just go straight down to 12.
[29:35.790 --> 29:36.810]  You don't even have to count.
[29:36.810 --> 29:40.990]  That's nice and easy, right on a simple edge line there.
[29:40.990 --> 29:43.250]  So we're looking at the offset value.
[29:43.450 --> 29:45.910]  So if you don't know what the TCP offset value is,
[29:45.910 --> 29:53.450]  that value tells you in bytes how far from offset zero of the TCP header
[29:53.450 --> 29:57.270]  does the TCP payload begin, right?
[29:57.290 --> 30:03.730]  So the reason why that's important and less important than the IP header length value
[30:03.730 --> 30:06.150]  is that, like I said, IP options aren't really used anymore,
[30:06.150 --> 30:08.090]  so it's almost always 20 bytes.
[30:08.350 --> 30:10.890]  TCP options are absolutely used all the time.
[30:11.290 --> 30:14.630]  So we do need to calculate this value, and it does matter, right?
[30:14.630 --> 30:17.490]  So we're looking at TCP 12, and we know which part that is.
[30:17.490 --> 30:18.230]  Great.
[30:18.810 --> 30:22.690]  But again, we're on the problem where the offset value in the header diagram,
[30:22.690 --> 30:26.010]  the diagram shows us that offset is not a whole byte,
[30:26.010 --> 30:28.570]  like source port was, where it was nice and easy.
[30:28.570 --> 30:32.370]  So we need to bit mask again just to grab that first nibble.
[30:34.090 --> 30:37.070]  So the bit mask is 0xF0.
[30:37.070 --> 30:42.810]  Remember, the previous mask was 0xF in order to get the far right four bits.
[30:42.810 --> 30:45.850]  Now we want the far left four bits, which is the higher order bits,
[30:45.850 --> 30:47.910]  so 128, 64, 32, 16.
[30:48.070 --> 30:49.510]  We're going to do the same thing.
[30:49.510 --> 30:51.270]  We convert that to binary.
[30:52.050 --> 30:54.990]  And in binary, let me check my notes.
[30:54.990 --> 30:56.650]  Yeah, that comes out to 240.
[30:57.090 --> 31:01.210]  And so that 240, we build that out.
[31:06.900 --> 31:09.100]  So we get the 1, 1, 1, 1, 0, 0, 0, 0.
[31:09.100 --> 31:10.360]  Sorry, I was looking at my notes there.
[31:10.560 --> 31:12.420]  And that gets us our mask.
[31:12.420 --> 31:14.500]  So that 240 is the whole half nibble there.
[31:14.500 --> 31:15.740]  We drop down.
[31:15.780 --> 31:19.220]  And I went ahead and selected 80 from one of the packets that we match on a future slide,
[31:19.220 --> 31:20.440]  so we have data to work with.
[31:20.780 --> 31:25.400]  And that's what's actually in the offset value for a real TCP packet.
[31:25.760 --> 31:27.560]  So we use that 240 to get the mask.
[31:27.800 --> 31:30.680]  And then once we actually look in that field using that mask,
[31:30.680 --> 31:32.720]  we realize that there's an 80 in there.
[31:32.720 --> 31:35.640]  So an 80 is made up of 64 plus 16.
[31:36.340 --> 31:37.140]  Great.
[31:37.540 --> 31:38.240]  Got that.
[31:38.240 --> 31:40.440]  But we still need to bitshift 2 to the right.
[31:40.800 --> 31:47.220]  Well, if bitshifting left by 2 is multiplying by 4, I certainly didn't do well in math in school,
[31:47.220 --> 31:50.240]  but I'm pretty confident that bitshifting right by 2 is probably going to do the opposite,
[31:50.240 --> 31:51.800]  and it's going to divide by 4.
[31:52.160 --> 31:55.540]  And so if we look, and that's exactly what we just did.
[31:55.540 --> 31:58.920]  We just rolled those 1s two places to the right.
[31:59.300 --> 32:00.480]  It's that simple.
[32:00.480 --> 32:05.260]  Now, if you find yourself rolling off, there's a whole other problem that begins there, right?
[32:05.260 --> 32:09.820]  But that's unlikely to happen in these much more simple binary math situations.
[32:11.840 --> 32:12.820]  That's it.
[32:12.820 --> 32:16.480]  So now we've got 20 as the result of this filter.
[32:19.480 --> 32:20.520]  Wow.
[32:21.320 --> 32:25.700]  So let's go back to our original, extremely intimidating, complicated filter.
[32:25.700 --> 32:32.280]  And the point of that filter was to view only IPv4 HTTP packets that contain a payload.
[32:32.580 --> 32:33.460]  And that's a tough one, right?
[32:33.460 --> 32:39.040]  Because if I were to come up to you and say, hey, you know, I want you to show me HTTP packets,
[32:39.040 --> 32:43.960]  the first thing everyone's going to do is a DSP dump and an IE0 port 80.
[32:44.520 --> 32:46.680]  Well, that doesn't satisfy the other part.
[32:46.680 --> 32:48.080]  It needs to contain a payload, right?
[32:48.080 --> 32:49.600]  Plus anything could be on port 80.
[32:49.640 --> 32:51.760]  It doesn't have to be HTTP. It just probably is.
[32:52.240 --> 32:57.380]  Okay, so if we look at this again, think back to, you know, last time you did math, order of operations.
[32:58.500 --> 32:59.720]  We've got a color code here.
[32:59.720 --> 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.
[33:06.260 --> 33:07.080]  That was 60.
[33:07.340 --> 33:09.480]  The TCP header length, we got that.
[33:09.480 --> 33:10.500]  That was 20.
[33:10.580 --> 33:11.920]  Those are in the first parentheses.
[33:11.920 --> 33:13.340]  We have to break that down.
[33:13.920 --> 33:18.200]  And then whatever that resulting value is, which is, of course, 40,
[33:18.200 --> 33:21.580]  we need to subtract the TCP data offset from that.
[33:22.320 --> 33:23.800]  That gets us down to 20.
[33:23.900 --> 33:25.460]  It does not equal zero.
[33:25.580 --> 33:28.260]  I would generally agree that 20 does not equal zero.
[33:28.680 --> 33:32.440]  That brings our filter all the way down to TCP port 80 and true.
[33:33.060 --> 33:39.520]  So true is just a more of a Boolean kind of keyword type here, right?
[33:39.520 --> 33:42.720]  So it's not an actual TCP dump keyword that you can use.
[33:42.720 --> 33:46.240]  We're using it to display that TCP dump is looking at every packet.
[33:46.240 --> 33:50.700]  And unbelievably, you know, it's just the speed of, you know, traffic here,
[33:50.700 --> 33:55.660]  is performing all this math on every single packet that goes by and satisfying these values,
[33:55.660 --> 34:00.420]  doing this calculation, and seeing if it can satisfy your filter, TCP port 80,
[34:00.420 --> 34:02.400]  and this all has to work out to true.
[34:02.680 --> 34:05.020]  False, don't show it to me, right?
[34:05.960 --> 34:06.760]  Fantastic.
[34:08.840 --> 34:09.840]  All right.
[34:10.060 --> 34:11.080]  So success.
[34:12.620 --> 34:16.600]  So at the very top, again, you can see that I'm using TCP dump.
[34:16.720 --> 34:18.540]  And just go back to one of our first slides.
[34:18.540 --> 34:21.780]  I use XNR, dash R is to read a PCAP.
[34:22.300 --> 34:27.100]  So I'm reading HTTP.PCAP, which is one I pulled from a public traffic repository.
[34:27.100 --> 34:27.960]  There's a lot of those out there.
[34:27.960 --> 34:31.340]  I highly recommend using them as a playground to test these.
[34:32.020 --> 34:35.820]  And it did the filter we've been looking at on the cross, and we've got something.
[34:36.640 --> 34:38.420]  So if you're familiar with HTTP,
[34:38.420 --> 34:42.780]  what you can actually see in the ASCII here on the middle right-hand column here,
[34:42.780 --> 34:47.120]  you can actually see the get plus images, logo.png, HTTP slash one dot area.
[34:47.120 --> 34:48.760]  That's definitely an HTTP payload.
[34:49.020 --> 34:51.400]  And so we're successful.
[35:01.900 --> 35:02.880]  Let's see.
[35:02.880 --> 35:04.940]  Do we have any questions for our speaker?
[35:09.050 --> 35:12.350]  We got... it looks like we're actually missing a slide here.
[35:14.990 --> 35:17.810]  Let me just give you a couple of resources here real quick.
[35:17.810 --> 35:22.670]  So tcpdump.org is actually a fantastic resource.
[35:23.810 --> 35:25.790]  You know, for folks that have been around that long,
[35:25.790 --> 35:29.450]  I just can't believe how good of a job they've done with documentation.
[35:30.230 --> 35:32.950]  It's not necessarily always the case.
[35:33.250 --> 35:37.550]  tcpdump101.com, it will help you build filters like this with a GUI.
[35:37.550 --> 35:40.590]  Save yourself some time, help to play around with it, figure it out.
[35:40.690 --> 35:44.810]  The man pages for tcpdump and PCAP-filter, fantastic.
[35:44.810 --> 35:49.850]  The long filter we looked at today came from the tcpdump man pages.
[35:50.170 --> 35:52.430]  There's even an explanation at the bottom, right?
[35:52.430 --> 35:54.990]  One of the best man pages I've seen out there.
[35:55.470 --> 35:59.410]  If you're familiar with the awesome projects, awesome-pcap-tools,
[35:59.410 --> 36:00.630]  take a look at that page.
[36:00.630 --> 36:04.730]  I'm not just pushing it out there because I'm one of the maintainers of it.
[36:04.730 --> 36:06.310]  It's actually a great list.
[36:06.750 --> 36:10.390]  Take a look and please help, you know, if you have any tools that we're missing on there.
[36:10.790 --> 36:13.270]  If you felt intimidated by any of this and you're, you know,
[36:13.270 --> 36:16.930]  what the hell is he talking about, IV4, TCP, SYN, Synax?
[36:17.010 --> 36:18.490]  You need to brush up on your networking.
[36:18.730 --> 36:21.310]  Take a look at Professor Messer on YouTube.
[36:21.490 --> 36:23.450]  It's a fantastic network plus video series.
[36:23.450 --> 36:25.330]  You don't have to take the CERT if you don't care.
[36:25.870 --> 36:28.110]  But just the content in the series is worth your time.
[36:28.110 --> 36:29.770]  I think it's only like eight hours long.
[36:32.090 --> 36:33.570]  It's free training, right?
[36:33.990 --> 36:35.850]  That's right. It's free training. Absolutely.
[36:37.030 --> 36:40.010]  And final few pieces, some tips and tricks.
[36:40.010 --> 36:43.770]  A lot of people prefer Wireshark for their own reasons.
[36:44.770 --> 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.
[36:54.030 --> 36:56.030]  Just Google that.
[36:56.030 --> 36:58.830]  There's a long SSH command that you can do it with.
[36:58.830 --> 37:04.110]  Another common thing that will come up in doing this at work is you're going to find out that, you know,
[37:04.110 --> 37:06.470]  there's going to be situations where, you know,
[37:06.470 --> 37:10.370]  this only happens when my database server sends this one weird packet at 2 a.m.
[37:10.370 --> 37:11.770]  ever since they did this update.
[37:12.050 --> 37:14.830]  You're not going to want to be there at 2 a.m. because it happens at 4 a.m.
[37:15.910 --> 37:19.270]  If you need to start a long-standing TCP dump with a complex filter,
[37:19.690 --> 37:22.030]  you can actually start it with an ampersand at the end,
[37:22.030 --> 37:25.910]  which, of course, in the Unix world is going to background that session for you.
[37:25.990 --> 37:29.730]  If you get disconnected, even if it's backgrounded, that's still going to kill the TCP dump.
[37:29.730 --> 37:35.950]  You can use a command called disown to separate the command from you and then disconnect.
[37:35.950 --> 37:37.370]  It'll keep running in the background.
[37:37.370 --> 37:42.350]  Whenever you come back in the morning and you need to kill that session and grab your PCAP,
[37:42.350 --> 37:48.830]  you can send a PCAP with the kill command to that PID and get the PCAP back.
[37:49.330 --> 37:52.650]  That's well over time here.
[37:53.010 --> 37:54.730]  Certainly appreciate everyone sticking around.
[37:54.730 --> 37:56.690]  If you have any questions, feel free to grab me.
[37:56.690 --> 37:59.430]  My Twitter handle is at404Scribbles.
[37:59.670 --> 38:03.710]  If you have any questions, any ideas or anything that you think I missed,
[38:03.710 --> 38:04.890]  certainly feel free to reach out.
[38:04.890 --> 38:06.190]  I'd love to chat and share ideas.
[38:06.190 --> 38:06.790]  Thank you.