Let me introduce the next speaker, because we're right on the money with that talk.
Let's see here, who's next? Scribbles! Where's Scribbles? Scribbles, you here?
Scribbles here?
Oh yeah, I'm here.
Oh, okay, there you are. Sorry.
Okay, Scribbles is our next speaker. He's going to be presenting Advanced Packet Wrangling with TCP Dump.
This should be a very interesting talk, by the way.
Scribbles, Stephen Kennedy, is a security engineer and a new Linux enthusiast in Denver, Colorado.
He holds an MS, a master's degree in cybersecurity and information assurance, as well as over 20 industry certifications.
Dude, do you ever sleep? I mean, 20 search? Seriously, where are you? That is impressive.
Okay, I've got search on their heart again.
I work for the university system, you know, they just keep paying me in search instead.
Yeah, well, that's true.
Yes, I know exactly what you mean. It's like, here's free money, go to another class. There you go.
So, his first computer was a Commodore 64, and he's a survivor of the late 90s and early 2000s IRC.
By the way, IRC is still alive and working. Thank you very much.
So, without any further ado, here's Scribbles. Thank you.
Wonderful. Thank you, X-Ray. Just a moment here.
Oh, do you have access to the stage?
I do. Yep.
Okay.
Just making sure that the stream is looking good too. Stream set up.
Oh, they got it working.
They did.
Excellent. Well, our team has been in the background hacking like crazy. So, excellent.
All right. Thanks, everyone.
Let me make sure my slides are up over here as well.
And definitely a big shout out to the Giglio team for figuring this out.
It's been a bit of a fire event just to get these slides up, but everything figured out, which is amazing.
So, like X-Ray said, my name is Stephen Kennedy.
Previously, I spent time as a network security consultant and a network security engineer.
And, of course, if you're not familiar with the 14ers...
Let me see if I can move this slide. This is the new form.
Oh, I can do it myself. Nice.
Come back and take a look.
Yeah, so if you're not familiar with the 14ers, so those are mountain peaks over 14,000 feet.
Or if you're not using Freedom Units, that'd be 4,267 meters.
Let's see how far away I can test this.
Oh, that's beautiful.
Okay, so tcpdump and libpcap.
These projects are both open source. They're developed by the tcpdump group.
tcpdump is certainly the best known command line interface packet analyzer.
You can basically open a terminal and see all the traffic on any of your network interfaces.
If you do it on a busy enterprise box, you'll barely get a chance to see any text at all.
It'll just all just screen by.
And, you know, you'll just have to hit control C a hundred times to get it to finally stop.
So the important part about tcpdump is to build filters to slow some of that stuff down.
So it was first released in 1988, and I believe it or not, it is still in active development.
It's still an extremely useful tool, and it's absolutely keeping up with the times.
So, you know, a big part of this talk is encouraging you to dive deep on this one.
So libpcap is the library that tcpdump uses to interface with the kernel.
In Windows, this is called WinPCAP, and the Windows version of tcpdump is called WinDump.
And... let's see here, yep.
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.
But back in 1993, the folks that created tcpdump at Lawrence Berkeley Laboratories
actually delivered a paper on what they called BSD packet filters.
You might have seen the phrase BPF being thrown around.
It's usually associated with tcpdump.
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.
It's no longer just about network activity.
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.
All right, so next slide here.
This is the why should I care slide.
So this is a pretty important part, right?
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, right?
This is an incredibly useful tool for your skill set.
And I really want to prove that out to you.
The PCAP or it didn't happen picture on the previous slide.
So, you know, it's popular slogan for shirts and everything.
It's not just a clever phrase, right?
It's generally true. If it didn't go across the wire,
it probably didn't happen.
You know, perhaps there's scenarios where you're blocked from viewing it.
And sure, right?
Those are few and far between.
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.
So how would that work?
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.
But that conversation where maybe you're a server owner
and you just stood up or maybe you own a couple of servers, right?
A couple of services running on it.
And one of your co-workers just stood up a new server
and it needs to connect to yours.
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?
You go, yep, made an account for your token.
Go do your thing and configure the stuff that you own.
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.
Right?
So connection failed doesn't tell us very much.
Is it a, you know, is the network actually down?
Did we, did something actually fail?
It doesn't, it doesn't tell us very much of anything.
Did it even try to get on the network?
Maybe it can't even access the network adapter itself.
So error messages can be terrible.
I think we all know that.
You know, and developers can be very hit or miss on that sort of thing.
And log messages in general are, you know, aren't always much greater.
So this is that part where you can start to lean on the network
to be like, well, wait a minute.
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.
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.
Maybe the IP was wrong or something like that.
But if you use a tool like TCPDOM, you can say, hey, well, what's your server IP?
Go ahead and try to connect to me again.
And if I don't see any traffic come to my interface,
there's something else that's going on, right?
We've already ruled out this entire service.
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?
So it's very important that you be able to rule things out.
Improving their claim, right?
And so another great example is that, you know, in a past life,
I was working for a vendor that sold security appliances.
And a customer had one installed in Tokyo.
And this appliance would make a tunnel back to a data center in the U.S.
And the tunnel kept failing.
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.
And so we started looking at the appliance,
and it took a bit to, you know, see what was going on.
And every time the tunnel would open,
we were looking at it from the point of view of the box that's in Tokyo.
Every time we see that SYN go out, we'd immediately get a reset back.
Right? 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. Right? That's breaking the laws of physics.
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.
And so we were immediately able to call that out
and get their network engineers on the line and be like, what is this?
Look at the timestamps, like this doesn't make sense.
And boom, you know,
they found out that they hadn't actually properly implemented the ACLs.
And the connection was open and the tunnel was able to work.
Right? So the point of the story is, of course, being that, you know,
this tool can look very esoteric, but it's important.
And third, of course, threat actors aren't the only ones that live off the land.
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.
So they have to live off the land. Right?
That happens to us too. Right?
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.
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.
And you can't just go download and install that.
It would break compliance regulations.
You'd be tons of paperwork.
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. Right?
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.
So this is a skill that also pays dividends. Right?
The more you invest in this, the more you practice,
the better you're going to get at it.
Some of the technical details here, if you don't practice them,
it's not going to stick. It's just like anything else in life.
But it's not as hard as it can look initially.
So please understand that this does require a basic understanding
of the TCP IP protocol stack.
If you're a networking newbie, this will help you get an idea
of what's possible with this tool.
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.
We'll stick with...
So some basic syntax, you've probably seen a good bit of this,
if you are familiar with TCP dump.
So on the left here, we've got our flags, color-coded.
So if we look at the command across the top, right?
So we've got capital X, so that's going to show the output
in both hexadecimal and ASCII.
The N is don't resolve hosts and ports.
Typically, we do that just because we just want to see port numbers
and we want to see IP.
I don't want resolution and DNS getting in the way
because we know that that always gets messy.
For I, also very important one,
we want to specify the network interface we're monitoring.
So in this example, we're going to be looking at eth0.
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.
That'd be great, right?
So we look on the right side here, filters and operators.
So pretty easy to read in English.
So right after we get past that C5 on the top left,
we're going to move into what I put in single quotes.
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.
I'm talking about like an ampersand or parentheses
or things you might have to escape otherwise.
It gets messy, just use single quotes,
and then you don't have to worry about it.
So TCP and, you see we've got open parentheses.
That's matched by a closed parenthesis on the other end of the line.
Remember, this is just like in math class,
order of operations, we're going to start with the parentheses first.
And what we're saying here is source host, this IP address,
or source host, this other IP address.
So this filter is going to show us any packet that is TCP
and source from either of those hosts.
Easy enough, right?
We can also see that there's other things you can do.
You can do ports, port ranges.
You can specify protocols, TCP, UDP, ISP multicast.
I said NOT and OR at the bottom line.
I wanted to hit that one first.
Look right above it.
Of course, the NOT and the negation is the estimation point.
Just like in bash, the double ampersand is an AND.
Just like in everything else, the double pipe is an OR.
And we have some other characters that are available to us,
less than, greater than, equals, and parentheses to help divide some things.
Okay, so...
filtering of the transporter network letters.
So a really cool feature of TCPdump is that you do have some convenience flags.
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.
There's no reason to bring math into this, right?
Like, let's just do something easy where we can look at a table and figure this out.
Again, this is pretty English readable.
You'll see the flags on the left.
If you're familiar with the TCP protocol, you'll recognize the flag names.
What we have is, you know, TCP FIN, TCP SIN, RESET, PUSH, ACK.
And then the message types, these are all ICMP messages down here.
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.
That's the most common way of knowing it.
So in the examples up here,
let's look at one of these written out using some of these keywords.
So we have TCP and then in square brackets, TCP flags.
And parenthesis, TCP SIN or TCP FIN does not equal 0.
So it's pretty obvious what the first part does, right?
So we're filtering on the TCP flag section of the TCP header.
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.
So remember, a packet is actually binary when it's on the wire.
It's a 1 or a 0, it's on or off.
So if it does not equal 0, then it must be a 1,
which means it must be on.
So show me packets where SIN or FIN are on.
And same thing with the ICMP message down here.
Pretty straightforward.
ICMP type does not equal ICMP ECHO,
and it does not equal ICMP ECHO REPLY.
That would essentially show you every ICMP packet that is not related to PING.
It's simple, right?
Let's move on to the next slide here.
All right, so the big question is we see those keywords, right?
And they're very convenient, very nice, easy to remember.
And things start getting weird.
So how do those keywords work?
Why are they convenient?
And why would they go out of their way to do this for us?
How do they go into a packet and pull out that section of the packet?
So in this diagram here, the big part in the center,
so that's actually the TCP header, right?
So if you're familiar with TCP IP,
you'll know that typically the IPv4 header is at the top.
And then in order to get around, TCP needs its own... requires IPv4.
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.
This TCP, you'll notice in this header, doesn't talk about IP addresses.
It just talks about ports.
IP addresses are up in the IPv4 header.
So when we talk about TCP SYN, TCP FIN, what's actually happening?
And again, these are examples from previously.
You look down at byte 13 down here.
In green, you'll see TCP flags.
It says C-E-U-A-P-R-S-F.
So what that actually is, is those are all of the TCP flags.
Look on the left-hand side over here.
What we have is this table that's showing ERJAC, PUSH, RESET, SYN, FIN.
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.
The order of those matters.
And so when we're going in and we're looking at a header like this,
it can be very confusing.
So there's lots of numbers and lines and things like that.
So at the very top left is byte offset zero.
That's the beginning of the TCP header.
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.
And one byte is eight bits.
And you'll see there's a line in the middle that's a little bit darker.
So a half byte is called a nibble.
So four bits is a nibble.
Eight bits is a byte.
So it's pretty easy to say.
The source port field of the TCP header takes up two whole bytes.
Easy enough.
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.
You'll see that 128 keeps getting cut in half as we go.
And then there's ones and zeros along it.
So think of each of these slots or each of the columns there.
There's eight of them.
They match up with the eight bits in a byte.
So as we go across, starting at byte offset zero here, that's going to be 128, 64, 32, 16, 8, 4, 2, 1.
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.
So in this diagram up here, so we see it's 1, 0, 1, 1, 0, 0, 0, 1.
All you have to do is where there's a one, you just add that number. It's that simple.
128 plus 32 plus 16 plus 1 equals 177.
I mean, that's binary math, right?
It's really just adding where there's a one.
And just know that after that one at the very end here, along the top column, it just starts over again.
At 1, so it goes 4, 2, 1, 128, 64, 32.
And that's going to keep going along the whole top of all of these fields over and over and over again.
And that's how your computer is interpreting these values, your network card, rather.
So back to the point about the filter examples.
So we already went over the verbal one or the keyword one, TCP SYN or TCP FIN does not equal zero.
But the line below it is actually equivalent.
So TCP 13 and 2 or 1 does not equal zero.
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.
We're saying start it that byte.
What about this AND part? So AND 2 or 1?
Go back up to the binary chart. That's the two bits on the far right of the 13th byte here.
There's the S and the F, the SYN and the FIN.
So if there's a 1 and a 1 here, then we could match.
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.
And that's about as hard as this gets. It gets a little weirder, but that's about as hard as it gets.
So if you're following me there, you're doing a great job.
The next slide.
We can get a lot more precise than that.
And so if you feel it in your chest the first time you see a filter like this, you're not alone.
I've certainly been there.
This is whenever those keywords don't match what you need to look for in TCP dumper on the wire.
So we start seeing things. Some of this might make sense based on what we've been talking to.
We've got IP, sure. I see the brackets where they have the byte numbers.
I can look at those, right? TCP 12. Not equal zero.
What does any of this mean?
And where do we even begin?
So we're going to break this down into three parts.
The TCP port 80 and pretty straightforward.
But we're going to break this down into three filters. We've got the blue one here.
What is that? Coral? We'll go with coral.
And then this yellow-ish color here.
We're going to break this into three different filter pieces and go through them.
All right. So this is the IPv4 header, RC791.
The filter we're looking at is the first part of the original one on the previous slide here.
So we're looking at IP 2 and 2 as the first portion of what we want to figure out.
Because the goal here is just to figure out what it is that this filter does.
So, okay. So IP 2 and 2. So we hadn't seen the colon 2 before.
But we know that that 2 probably means the second byte.
So the top left, we see the offset and length.
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.
So it's saying from byte 2, so where the blue arrow here on the diagram begins, I want the next two bytes.
So from byte 2, 1, 2. And there's the end of the line.
So we're basically done with the IP 2 and 2 portion.
If you look at the header, we know that it's asking for the total length field.
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.
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.
So total length is the total length of the IP diagram, or IP fragmented, and it's measured in bytes.
That's already in bytes, and that's what we probably want. So we're just going to go with that. Easy.
All right. But then the next one is this IP 0 and 0xfslsn2.
All right. So that looks pretty strange. Let's move on to the next one and take a look.
So we're going to validate our length field here.
So this is the first time that we're taking a look at the TCP dump output.
I hope everyone can see this. I'm going to slide down here so I can get a first look as well.
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.
Great. So on the third line of this whole screen here is a timestamp, that 1345.
Each one of these timestamps is a packet that matched that filter that TCP dump is outputting and showing us.
As we read across, we see IP 192.168.1.140 is reaching out to this 174 address in port 80.
I'm going to make a leap and say that's probably HTTP traffic. I think that's safe to say, right?
As a little bit further than that, it says flags, bracket, S bracket.
So in TCP dump output, that S actually represents that SYN flag being on, the TCP SYN.
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.
So what we're seeing here is part of the three-way handshake. So we see S and S dot.
So the host that received the SYN reply back with his SYN ACK.
What's in the red box is actually the part of the packet that we were just filtering for the IP 2 and 2.
So why is it all the way over here in these weird characters?
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.
HEX is a base 16 counting system. So we're doing 0 through 9 and A through F are the valid characters.
So F is 15. The reason why F is not 16 in the base 16 counting system is because we count from 0.
So 003C. So each character up there is actually one nibble.
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.
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.
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.
Well, it is. It's just in hexadecimal right now. So we have to convert that to decimal.
At the very top, just above the screenshot, you can see HEX003C equals 60. You convert that value to decimal, that's 60 bytes.
All right. This next slide here.
So back to the second part of the coral filter, IP0 and 0xf, less than, less than 2.
So what's actually going on here? I'm going to exit the stage here for a moment.
So we're going to start at the very top left. And what we can see is that IP0, simple enough.
We're going to look at the IP header. We're going to start at byte offset 0. Show me that first byte. Great.
There's the first two nibbles, right? Two nibbles and a byte.
And so that part's done, but we haven't finished dealing with the rest of the parentheses yet.
So that ampersand 0xf, the ampersand is telling you that we're going to bit mask.
And so what we're going to do is we're going to mask these eight bits in this single byte.
And what that means is that we need to take that hexadecimal F, we need to convert it to decimal.
F in decimal is 15, like we were just talking about. And in binary, it's 1111.
Why is it 1111? 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.
And so that's why we opted to give it the hex F value.
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.
So I want you to start at 0 and now use this mask to carve out this nibble for me.
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.
So the IHL field in tcpdump, I'm sorry, in the IP header is actually the header length.
And so this typically almost always is a 5.
And so the reason for that is that IP options are generally no longer used.
The IP options is the last field in an IP header.
So there's just one of these things in life that you just have to accept.
It's a weird rule where the story takes longer than it does remember the rule.
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.
It's almost always 20 bytes, because again, IP options just aren't used.
So I went ahead and put that 5 over here, right?
And below it, we have the binary chart.
And so we finished the parentheses, and we're still left with that less than, less than 2.
So what does that mean?
So the less than 2 actually means we're going to bit shift the value in parentheses by 2.
If you haven't heard of bit shifting, it sounds really complicated and cool.
It's extremely simple.
So we're going to take that value, and we know that we need to multiply by 4 to get the bytes, right?
But the interesting part is that bit shifting left by 2 is the same thing as multiplying by 4.
I say that again, bit shifting left by 2 is the same as multiplying by 4.
And the reason that is, is we come over here and look.
We have 0, 1, 0, 1 in this left binary table here, right?
So 8, 4, 2, 1.
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.
We can't create new ones, right?
So then it just becomes 1, 0, 1, 0, 0.
So we essentially multiplied by 4 because we went from 4 and 1 makes 5 to 16 and 4 makes 20.
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.
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.
So that's it, right?
So one of the most intimidating pieces.
So on to the third filter.
This looks very much the same.
You already know what to do here.
So we're starting with the TCP header.
We started the 12th byte, and we can see the header up here at the very top right.
So the 12th byte, we look on the left-hand column.
There's those byte offset values in red.
You can actually just go straight down to 12.
You don't even have to count.
That's nice and easy, right on a simple edge line there.
So we're looking at the offset value.
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?
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.
TCP options are absolutely used all the time.
So we do need to calculate this value, and it does matter, right?
So we're looking at TCP 12, and we know which part that is.
Great.
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.
So we need to bit mask again just to grab that first nibble.
So the bit mask is 0xF0.
Remember, the previous mask was 0xF in order to get the far right four bits.
Now we want the far left four bits, which is the higher order bits,
so 128, 64, 32, 16.
We're going to do the same thing.
We convert that to binary.
And in binary, let me check my notes.
Yeah, that comes out to 240.
And so that 240, we build that out.
So we get the 1, 1, 1, 1, 0, 0, 0, 0.
Sorry, I was looking at my notes there.
And that gets us our mask.
So that 240 is the whole half nibble there.
We drop down.
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.
And that's what's actually in the offset value for a real TCP packet.
So we use that 240 to get the mask.
And then once we actually look in that field using that mask,
we realize that there's an 80 in there.
So an 80 is made up of 64 plus 16.
Great.
Got that.
But we still need to bitshift 2 to the right.
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.
And so if we look, and that's exactly what we just did.
We just rolled those 1s two places to the right.
It's that simple.
Now, if you find yourself rolling off, there's a whole other problem that begins there, right?
But that's unlikely to happen in these much more simple binary math situations.
That's it.
So now we've got 20 as the result of this filter.
Wow.
So let's go back to our original, extremely intimidating, complicated filter.
And the point of that filter was to view only IPv4 HTTP packets that contain a payload.
And that's a tough one, right?
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.
Well, that doesn't satisfy the other part.
It needs to contain a payload, right?
Plus anything could be on port 80.
It doesn't have to be HTTP. It just probably is.
Okay, so if we look at this again, think back to, you know, last time you did math, order of operations.
We've got a color code here.
So what we actually did was we looked for a TCP port 80 and we need the IPv4 total length, which we got.
That was 60.
The TCP header length, we got that.
That was 20.
Those are in the first parentheses.
We have to break that down.
And then whatever that resulting value is, which is, of course, 40,
we need to subtract the TCP data offset from that.
That gets us down to 20.
It does not equal zero.
I would generally agree that 20 does not equal zero.
That brings our filter all the way down to TCP port 80 and true.
So true is just a more of a Boolean kind of keyword type here, right?
So it's not an actual TCP dump keyword that you can use.
We're using it to display that TCP dump is looking at every packet.
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.
False, don't show it to me, right?
Fantastic.
All right.
So success.
So at the very top, again, you can see that I'm using TCP dump.
And just go back to one of our first slides.
I use XNR, dash R is to read a PCAP.
So I'm reading HTTP.PCAP, which is one I pulled from a public traffic repository.
There's a lot of those out there.
I highly recommend using them as a playground to test these.
And it did the filter we've been looking at on the cross, and we've got something.
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.
That's definitely an HTTP payload.
And so we're successful.
Let's see.
Do we have any questions for our speaker?
We got... it looks like we're actually missing a slide here.
Let me just give you a couple of resources here real quick.
So tcpdump.org is actually a fantastic resource.
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.
It's not necessarily always the case.
tcpdump101.com, it will help you build filters like this with a GUI.
Save yourself some time, help to play around with it, figure it out.
The man pages for tcpdump and PCAP-filter, fantastic.
The long filter we looked at today came from the tcpdump man pages.
There's even an explanation at the bottom, right?
One of the best man pages I've seen out there.
If you're familiar with the awesome projects, awesome-pcap-tools,
take a look at that page.
I'm not just pushing it out there because I'm one of the maintainers of it.
It's actually a great list.
Take a look and please help, you know, if you have any tools that we're missing on there.
If you felt intimidated by any of this and you're, you know,
what the hell is he talking about, IV4, TCP, SYN, Synax?
You need to brush up on your networking.
Take a look at Professor Messer on YouTube.
It's a fantastic network plus video series.
You don't have to take the CERT if you don't care.
But just the content in the series is worth your time.
I think it's only like eight hours long.
It's free training, right?
That's right. It's free training. Absolutely.
And final few pieces, some tips and tricks.
A lot of people prefer Wireshark for their own reasons.
It is possible to use SSH to pipe a TCP dump session back to your local host and have it display in Wireshark.
Just Google that.
There's a long SSH command that you can do it with.
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.
ever since they did this update.
You're not going to want to be there at 2 a.m. because it happens at 4 a.m.
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.
If you get disconnected, even if it's backgrounded, that's still going to kill the TCP dump.
You can use a command called disown to separate the command from you and then disconnect.
It'll keep running in the background.
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.
That's well over time here.
Certainly appreciate everyone sticking around.
If you have any questions, feel free to grab me.
My Twitter handle is at404Scribbles.
If you have any questions, any ideas or anything that you think I missed,
certainly feel free to reach out.
I'd love to chat and share ideas.
Thank you.