Tcpdump - Basics 3

Now we're gonna talk about data representation in tcpdump. So, so far we've actually haven't really seen too much interesting things. We just have a one line per pcap file by default where we have the source IP address, the port, the destination IP address, the port, etc. So how can we get actual content? That is, how can we get the payload of each packet? Well, there's a few different ways to display them, and you can represent them in hexadecimal or you can represent them in ASCII with tcpdump. First, let's— there's usually— so first off, you will have multiple lines of output per packet once you do this, so you'll have to use a— probably have to use a pager to parse through it. So let's begin by starting off with a small, a small snap length so you can begin to look at it, and then we'll work our way up. So I'm gonna run this, gonna send some data out, and then I'm going to listen on this interface and print 5— oops— print 5 packets. Okay, and now we're gonna add the -a option, and to print the ASCII, you can make it, you can add it to here, or you can do it by itself, whichever, doesn't matter. TCPdump will still parse it properly. And we're gonna print, I don't know, let's print 40 bytes of each packet. Actually, no, let's do 60. Aha! Now you can see that each packet takes multiple lines, and where the next one begins is just look for the timestamp. That's where the next one begins. Timestamp. And the packets that we're currently reading now aren't really useful. You can see that it's not human-readable. Bunch of stuff in here that isn't too helpful. However, what if we put a filter for something common like port 80? Let's see what we have here. Oh, nothing too interesting. Let's try DNS. Nope, nothing too, too interesting there either in this particular pcap file. We're actually truncating it, that's probably why. So let's actually get— remove that and do this again. Oh, actually, let's just have a better filter. Let's do OR 80. Aha! Now we're seeing juicy stuff. We got a script in here. Okay, so let's take it— let's just scroll up to a different pcap file, or I'm sorry, I'm sorry, a different packet from this list. We can have this machine, 199.93.58.125, is sending data. This is the server and it's sending data back to the client, and I know that because in TCP The destination port will be set to the server if you're making a request, and the server will take that and use the ephemeral port that that computer generated to actually send the reply. So here we have the ASCII data, and it's actually some code. So there's— this person is browsing code, or he's actually potentially getting attacked by some script. But, um, here it is. You can see it in its full ASCII glory. Right there. And let's just scroll up to another pcap file— I'm sorry, to another packet. Keep seeing pcap file. And you can see there's more code, and this is all JavaScript, it looks like. And there's further code as we keep scrolling up. Awesome. So now we actually saw how to use the ASCII portion. Let's see if we can— if there's any— anything else that's interesting in here. Oops, don't need that. Aha, now we have from this packet, again from the server to the client, that is the web browser. We have some stuff that's returned. It looks like— that looks to be formatting information, so CSS, I believe that is. Or ActionScript. It's looking at the Microsoft stuff right here, and then some data that we cannot read. Okay, but that gets the point across on how to take a look at this stuff. Let me do another one that makes— might hopefully make it easier. Um, uh, sorry, another process going that was generating those packets for us. And let's just open up, uh, tcpdump dump on eth0, and we're gonna do the same thing, -a for ASCII, and then we're gonna do port 80, and I'm gonna run it in the background here. Actually, no, I'm gonna write it to a file, test, or no, let's do, uh, jon.pcap, and I'm gonna run it in the background, and then I'm gonna use wget to go to my website because it's all in ASCII, should be easy to read. Okay, now let's bring up our pcap file, bring it to the foreground using job control in the shell. Quit. Copied or captured 36 packets. Those were the ones that were actually processed. I hit Ctrl+C and one was missed because of the timing I hit Ctrl+C. One had to be processed but was not able to make it past the filter. Then we're gonna read in this jon.pcap file. It actually appeared when I captured it. I really didn't need the 'a' because I wasn't actually looking at it, but I went ahead in there and put it there without paying attention. So let's now read it in and pipe it to less. Aha! So now if we're using a pager like less, we can go up and down through it with our keys on our keyboard. You can use the up arrows or you can use the J, K, L, H keys. So Let's find a packet. And here's the one we're looking at right now, or the one I want to look at. So this is actually my machine right here. And again, like I said, the destination port will be the web servers, uh, will be the, uh, the destination port will be the protocol, or sorry, the port for the service that we're using. And I use wget by default, did not specify an extra port, so it's gonna be 80, which is the default port for HTTP. Or the standard port for HTTP. And this is my web server that it's going to whenever it resolved. So next, we can see that in the actual data that my machine sent, it sent an HTTP request using the GET method. It asks for the home page, and it— by default, the web server serves up the, the slash. Which is to say the root of the directory. I guess all web servers probably do that. Then the protocol version of HTTP, and we're using 1.1. And then some information. You can see that my client, my wget, actually set some fields. So this is the header information that it was sending. It says the user agent is wget. So I actually told the web server in the request, hey, I'm wget, I'm running on a Linux-GNU system, I'm using the host of jonschipp.com, that's what we typed in, etc. And then finally the server says, oh, Jon Schipp, great, um, I got your message. Now I'm going to send from port 80 the response to your local machine on port 38390, and the content of that message is HTTP/200 OK. There's a status code that says we're good, I'm gonna send you some data now. And the data that he sent, or the server sent, personifying a little too much there, is Apache. It's running Apache web service, what it has in the server field in the header, and a bunch of other information that may be useful to you. But then there's the actual content of the website, so all the information about me that I wrote up. So, and it's returned. So this is the HTML. So then what then happens, my browser takes this HTML and renders it. It just, it just reads it and puts it, makes it, and makes the output so that it can actually display it usefully in the browser. So that's pretty much it. Next up, we're gonna talk about hexadecimal representation. Okay, so now we're gonna do the same thing except we're gonna print in hexadecimal. So we still have that Jon.pcap file. We're going to change the 'a' to an 'x', and then we're still going to pipe it to less because there's going to be a lot of data here. And you can see now we have it in hex, and it's not that— it's not really easy to read at all. You can't really do it unless you understand it. Some stuff is parsed out for you, like here in the case of the HTTP GET request. TCPdump was nice enough to print that out at the top to make you aware of what was contained in this packet, and the same for the response here. Other than that, it's typically not a number system that we can understand and read quickly. So what we can do though is we can use it in conjunction with ASCII, and that is— well, I should say, before we do this, let's go back to this. One benefit of the hexadecimal form is it's easy to search. So if you know a particular pattern, pattern, if you're looking for a sample and you know the hex values, and as quickly— it can search this quickly for it using the slash. So if you're searching for 4500, you can see each packet has that in common. And this actually is 2 bytes that are— that actually say the version information for the IP header. So the 4 is actually version 4, and the 5 is actually another number that represents the number of 32-bit words inside each packet, and it's in space, or yes, double word. So 4 times 5 is 20, so these are all 20-byte IP headers. This stuff will— you'll learn as you go, and I'll touch on more in the future. But this is a few quick things. And if you're looking for signatures like for the GET request, match GET, And what is, um, so let's just figure out what GET is in hex. So let's get out of this, let's go echo GET and send it to hexdump and -C, oops, uppercase C, and we can see it's 474554. And this one after is the newline I press, so it made that newline when I press Enter, or it's actually, yeah, it adds it by default. Um, so Course, if you don't want the newline, you can just do -n, and then now you don't have it. And now I can just go ahead and copy this, but I want it all together, so 4554. I'll copy that. And now let's go to our tcpdump again and let's search for this. Oh, that's right, it's not gonna work because the way this is done. Yeah, so there it is right there because it's in blocks, 2-byte blocks. But you can see if once I formatted it correctly, that is to show it again to match 4745 right next to each other and then a space and then 54. And that's what we have right there, 4745 and a space, then 54. That'll match all those GET requests in here. And really there is only one. So, all right, there you go. And now let's finalize this with adding ASCII data and hexadecimal data in one. And we're gonna use the -X option for this. And looking in here, we can actually see that the hex values are on the left-hand side and the ASCII values are on the right-hand side. So let's go ahead and search for, search for the hex value again. Whoops, don't wanna do that. Doesn't remember it. What was it? 4745. 4, 5, 4, 7. I don't remember actually. Let's just screw it. Well, boom, boom, boom, 4, 7. Well, that should have matched, I would have thought. So 4, 7, 4, 7, 4, 5. There it is. I must have typed something wrong. 4, 5 and then 5, 4. Yeah, so there it is. You can see per each byte over here, the corresponding one is set up over here. So 47 is G, 45 is E, 54 is T, 20 is a, is typically a space, nothing there, et cetera, and then HTTP, and it goes all the way down and matches up byte by byte across these. Across these packets. This is how I typically view things. I like to have both right there, so I usually use the -X option when looking at packet data like this.