All About Tcpdump

How to capture the right packets and not crash Wireshark

Hello frens,

Last time, we discussed capturing packets with tcpdump, and as promised, we have a dedicated stack for it because the documentation for it is kinda shit.

So why are we learning this? Consider the following scenario:

You’re a cyber boi for a large organization (or a medium organization, or a small organization, or any size organization that isn’t one device) and you think there might be an infection on a box.

You want to analyze the outbound network traffic. So what do you do?

You SSH to the firewall and you do a packet capture with tcpdump.

Let’s say this is a 10.0.0.0/24 network with 200 subnets going through this firewall. How many potential IPs is that?

Quick review - with a 24 bit subnet mask, this means we’re only considering the last octet (which is standard), the first available address is the network address and the last available address is the broadcast address. So 10.0.0.0 is the network address, 10.0.0.255 is the broadcast address, and everything else in the middle is a viable address. And of course one of those needs to be the gateway, but that’s still a usable IP, and while it is standard practice to make the gateway be the first available address in the block (10.0.0.1) it doesn’t have to be. You’ll occasionally run into network where this is not the case, so if you’re statically configuring IPs, make sure to VERIFY WHAT THE GATEWAY ADDRESS IS.

Anyway, so 2^8=256, minus the 2 IPs for network and broadcast, and we’re left with 254 possible IPs in the block.

So in this example with a firewall that routing 200 subnsets, 254*200=50,800 possible IPs of traffic you could be capturing. For reference, the packet capture I did of ONE MACHINE logging into a web server was this big:

1/5 of a MB. For a 30 second capture. And there wasn’t a lot of traffic to log into that web server. Just going to google or CNN will blow your shit up with all of the IPs, ads, and content information going to that page.

Meaning if we did a 30 second capture for 50,800 IPs, our file would 10GB OF DATA.

Here’s the thing, wireshark is cool, but to run, it has to throw ALL OF THAT PCAP DATA into RAM to process it. Anything over 1GB will take forever and likely crash the program.

The solution? Use SMALLER PCAPS.

BUT HOW???

By only capturing the data that we WANT.

Introducing the beauty of tcpdump - filters.

Filters allow us to only capture packets that match the right criteria so we’re ignoring most of the traffic we don’t care about and capturing all of the packets we want.

But there’s another feature and use case for tcpdump. Say you want to just get a little taste of the info. Not the whole thing. Not aggregated streams or data analytics, just a taste. What could you do?

Let’s look at what happens when we run the program with no additional arguments other than the interface:

We get an output, but it doesn’t tell us a lot. Essentailly just the IPs and ports, and a little bit of protocol information.

We can use the following switch -vv for very verbose and it tells us EVERYTHING.

This will give you every piece of information available to you in wireshark, but in the terminal output (without the data analytics). Of course, this would be impossible to decipher if there was too much data, which is why we will apply filters to only capture the right packets.

Consider the following output:

By adding the words “ip host 192.168.0.43” (my kali box’s local IP) we’re capturing only the traffic from my box. This is the switch you use when you want to capture packets from just one IP bidirectionally (where the IP is the source or destination). This is what you’ll use 99% of the time in your career because it’s good enough. If you wanted to write this to a file, you would just add “-w thenameofthefile.pcap” to the end of your statement like so:

And notice how I left the -vv switch in there but it is also writing to the file. Tcpdump ignores the -vv switch in this case because it’s not printing anything to the terminal, so it’s not going to hurt anything, but it’s not necessary either.

But say we want to capture packets with more than one IP? We have two options:

First, we could use the ip src and ip dst filters. Say we know the infected machine and the C2 (command and control) server IPs. We can then use the following filters like so “ip src <ip> and ip dst <ip>”

And notice here, we added a third filter: “and tcp port 80”. This now tells us to only capture traffic from the source IP AND the destination IP AND only on port 80. In most instances, it won’t be necessary to be this granular.

Finally, say you wanted to capture a bidirectional pacp, where you’re gathering all the data two and from the c2 and your infected box regardless of who’s sending and who’s receiving. As you may have guessed, instead of ip scr and ip dst, you just use ip host for both arguments like so:

And that’s it! Short and sweet but full of value. I’ve had to reinvent this wheel 100 times in my career trying to rediscover these filters and now you won’t have to.

Your homework for this week is to read the man page of tcpdump. To do so, type the following command:

man tcpdump

Then try capturing packets and reading the -vv output in the terminal. Then do a packet capture to bowtiedcyber.xyz with a clear text password and analyze it in wireshark. This should give you plenty of hands on for the next week.

Next up we’ve got a few gaps to fill with Linux, then a touch on parsing HTML (particularly forms) and then we dive into how to install and configure Suricata. This is gonna be a big one, so buckle up!

Special shoutout to our FIRST HOODIE to get a job. In just 8 weeks. This is absolute insanity