 Hey folks, there we go, cool. We'll give people a little bit of time to connect and then we'll get ready to rock and roll. Can everyone hear me? Good. Thank you. How's assignment four gone with previous classes? How about this? I'll tell you about it after the assignment's done. I don't want to give anything away. Do you get extra credit for not signing adversarial keys? No, that's part of the assignment. You 10 points of your assignment are for not signing adversarial keys. Yeah, the point was to do it quickly so that everyone could get people's signatures. Because if you give people a lot of time, they wait till the end anyway, so it really doesn't make sense. Yeah, you'll be able to see how many keys you signed when you submit and then I'll let you know exactly how many adversarial and real keys you signed. All right, well I think we got people in, so let's get started. For assignment four, you can submit more than once as many times as you want up until the deadline. Correct, so if you accidentally sign a key but you don't send it back to them, they don't get it so they can't submit it. So that would not count. If you just sign it and you never send it back, then it doesn't count as a signature. Cool, well I'm glad that's going well. Got one more day on it. I'm sure the piazza is going to be kind of crazy. If you look up in the chat, somebody has posted a link to a class discord that apparently people are currently using, yeah, going to be because you haven't seen anything yet really. It gets even crazier, yeah. So it's going to be fun, cool. Okay, then let's get started. So we've been talking about networking, so specifically we've been looking at how network routing works on the internet right now. And so we've looked so far at specifically just looking at, okay, so we've been specifically looking at how packets move, we've been looking at how packets move on the local network, right? We know that when we want to talk to an IP address on our local network, we look at the net mask and we're able to determine if that IP address is in our local network or external network. And if it's in our local network, we can then send the packet out on the local network on the link interface. And we know we can use the address resolution protocol to translate the IP address we want to talk to to the MAC address. And so now we're going to look at what happens with the indirectly, oh, I'm not sharing my screen. That's the problem. Loles. Okay. Share screen. I knew something was different. There we go. How about now? Better? Cool. Okay. Well, I didn't actually do anything yet, so that's good. But, okay, so now we have the, so now we're going to look at indirect delivery or basically what happens when we want to send a packet to somebody who's not on our internal network, right? So if we kind of go back to the example we've been using, we have systems A, let's say systems B connected to a switch, we'll add another system. We'll just call it G for now that are all connected here. And they're all connected to the same switch. They're on the same network. And so now we have the case. So we know the current process and we can walk through it, right? So host A has its IP address. It needs to know, it can check with its net mask if this IP address that it wants to talk to is in its local network or not. And the question is, what happens if it's not? So essentially every host, so we talked about, so what are the pieces of information that we talked about that every host on a network needs to have? Mac address? Yeah. So like a Mac address of A, an IP address, and what else? Mask. Yeah, the net mask. So IP address of A is, let's say, 10.0.0.2, the net mask, we're going to be 255.255.255.0. So we can think of this as a slash 24 network. So we have the IP address, the net mask, A will also have some Mac address that we won't care about necessarily for now, we'll just call it the Mac address of A. And so A has all this information, but now and this, all this information allows A to be able to tell using the net mask, is this a local IP or not? If it is like, for instance, to send an packet to be who's at, let's say 10.0.0.1, or sorry, dot, let's go with dot three, we know how to do that and how that protocol works. But what if A wants to send a packet to, let's say, eight dot eight, dot eight, dot eight, right? So what procedure does a go with? Well, first it needs a look, is this IP address in my local network? So what would a conclude in that case? Yeah, no, right? Because we can see by the net mask, the first 24 bits are not the same. Okay, then it's now it needs to know, okay, but where does this packet go? And so the piece of information that we're missing from the network is we need to know what's an IP address on my local network that I can send packets to that it knows how to get outside of the network. And so this is what's known as the gateway. So we need another piece of the puzzle, which is the gateway. So in this case, we'll call it 10.0.0.1, which will be this machine G. So G will be our gateway. And what this tells the, what this tells the A is that, hey, if you want to send an IP of packet to somebody who's not on your local network, then send it to the gateway. And so how does it do that? Well, it, it does exactly the same process. So it has the gateways IP address. So now in order to send the packet from A to G, what does A have to know about G the MAC address? Yeah. So it needs to know G's MAC address. So A needs to do an ARP request asking, Hey, who has the MAC address 10.0.0.1? G will respond, I have the MAC address 10.0.0.1 at MAC address of G. And now A can send the packet to G on a first hop that then will continue on. So let's actually look at what that packet is going to be like. Um, so, so if we look at that packet, so source IP, so what's the source IP here? A, so 10.0.0.2. And what's the destination IP? It's not G because we're not sending it directly to G, right? The packet we wanted to send was we want to actually send a packet to 8.8.8.8. Right. So we want to send a packet there. It's going to happen to go to G on the first hop. But our destination IP address is we want it to go to 8.8.8.8. And then what is then the MAC header look like? So what is then the Ethernet header look like? So what's the source MAC MAC address of A and the destination MAC? Yeah, MAC address of G, right? Because we're sending it on the local network. So the packet we want to go to 8, we know we can't get it directly there. So we know we have to send it to G first. So this will go out on the local network, it'll go from A to G. G will get it. And then the really interesting thing, and this is why this process actually becomes pretty straightforward, is that from A to G, G then does the exact same procedure. So G will then take it, look at it, check if it's on a local network that it can deliver it. If not, G has its own gateway where the next hop is. And that's how packets hop from host to host to host until finally it gets on the local network of 8.8.8.8, where it's finally delivered and then that person can respond. So let's, yeah, so we can walk through a little example real quick here. So here, and this is the, yeah, you're seeing presenter view me too. I know there's always a button, but there's, there we go. Cool. Okay, so we have two machines here. We have 11.10.20.121 and 128.11.41.10. These are on different networks. And so the idea is, and the important things to remember to keep in mind is that IP addresses always stay the same, the source and destination IP from hop to hop. We talked about the TTL is the time to live field. So this gets decremented on every hop so that packets don't bounce around forever in the network. And the other thing to remember is that the link layer gets destroyed and recreated on every hop. And so that we can see that here, and this is kind of the interesting thing. What happens is the destination 128.11.41.10 never sees the source MAC address. Yes, the link layer is the yellow packets and the red is the IP packets. So the yellow layer gets destroyed and recreated at every step. So on the initial, um, when the packets going out here, the link layer is from A, B, C, D, E, F to A0, B0, C0, D0, E0, F0. And that happens as it's going on a new pack link layers created. And then finally, what it gets to it, to the destination IP is a completely different link layer packet. Yeah. So we'll talk about where it needs to go in just a second. So it's kind of a visual representation of kind of these hops that it's, uh, that's going on. And so the question is then how does that packet route? How does, and this was the question of how does, uh, this packet route and happen to go from one to the other to the next to the next and all the way finally to the destination, right? So we know where to send our packet. A knows where to send its packet because it has a gateway that it says, okay, this is where I send all my packets to, uh, that I don't know that are on my local network. Um, and, um, the other things that are important is, um, hop by hop routing. So, um, the idea is every gateway and every hop along the way decides where the packets go. This is the standard way that routing occurs, uh, on the internet right now. Um, it used to be, there used to be a way, uh, called source routing. So if we go back, this means that the source who's sending the packets would be able to determine what route it takes on the network. Um, so why is that a, either a good or a bad idea? Why should this, uh, why should the person sending the packet be able to determine the route that it takes? Yeah. So maybe a good ideas in there, maybe you can determine security in the sense that maybe, um, one way to think about that is maybe you decide the route that it's going to take is going to be all within your own country. So, uh, rather than if routing happens, maybe the packet leaves the country and comes back, uh, maybe you can, you can decide on places that you trust that you want to route through the hops. Um, right. So there's good reasons. What about bad reasons? Or maybe take the shortest route. Maybe you want it to be super efficient to get from you to there. So what would be a downside of that? Yeah. So you could try to take the longest route. Um, it may not be very efficient. A hop could no longer be there. So think about how big the internet is. If you just think in terms of websites, there's a couple billion websites. So now your machine would have to know about all the routes and all the hops to every single IP address on the internet. Um, and or you could, yeah. So the other idea is everyone could decide to clog a specific route and overload, uh, an address. And then you have to deal with things changing. Uh, it causes a lot of problems. So they got rid of that. The other, um, really interesting thing is email addresses. If you've ever seen a really old, uh, email address, uh, food. Baz, um, email addresses used to have, uh, I think they used, um, exclamation point for this that you could, you would specify the route from your machine to their machine using, uh, exclamation points. So it would see that of how to actually route and get this mail to somebody else, it's kind of crazy. Um, so source routing isn't used very much anymore for all of the, the same reasons, uh, that we talked about. It has a lot of problems in terms of scalability and many other things. So it's basically not used very much. Um, so the question then becomes, how do we determine routing? So, uh, it can be, and the cool thing is it can be as simple as, uh, this example here where we have a local network and we say, if it's not in our local network, then give it to the gateway. It can be as complicated as this is a gateway. Maybe it has two different networks to go to, two different next hops. And so may, it may have a complicated routing algorithms that decide between them. Um, it all comes down to your routing table is where all this information is stored. Um, so let me see route dash N. Oh, it's, uh, this is on a Mac. So, uh, route and are, so this will show me the routing table on a Mac, uh, on Linux, you can do route dash N. Uh, you can run this on your local machine to see, uh, what it's basically saying, but essentially it's saying, okay, if, so default is your, um, base case, uh, here. So, Hey, if you don't know where to send it, send it in my case to one, nine, two, one, six, eight, zero. One on network interface, Ian five. And you'll see, I have the same route of Ian zero. Uh, so I believe if they're the same, it'll, it should do the first one. So this is my Ian five is my, uh, wired connection to my router. And Ian zero is going to be the wireless connection. Um, and then we can see different things like, okay. So this would be my local address, uh, one, nine, two, one, six, eight, zero. So this is a one, nine, two, one, six, eight, zero. So this is the slash 24, uh, send that out, uh, on the local network on link, I guess, number 10. I'm not really used to, uh, looking at the Mac this way. And then you can see the IPv6, um, you can see actually kind of a complex routing table, but we can go through something a little bit simpler here in this example. Um, so essentially this says, um, uh, one, nine, two, one, six, eight, one dot zero. So the mask is two, five, five, two, five, five, two, five, five. So this means the first 24 bits, if that's the same, then just send it out on ethernet, uh, interface zero. So ethernet zero. So this is what, uh, specifies that catch all routing table of if it's a local network, send it out. And, uh, you have the local network. So one, two, seven slash, what is that a slash eight, um, is the local network. So your local interface, um, is yourself. So one, it's mostly represented as one, two, seven, zero, zero, one, but, uh, actually there's a whole address range in there that all starts with one, two, seven. So that means send it back to you on the loop back interface, uh, which means it's not actually going to go out onto the network. And otherwise, if it doesn't match any of these, so zero, zero, zero, zero says, Hey, send it to the gateway, which is one, nine, two, one, six, eight, one dot one on each interface zero. And so this is what, um, uh, and so this is, uh, what's stored in the routing table. And this is how each of the machines decides where to send what packets to. So you can look at that and this can allow you to set up complicated things. If you're ever in a situation where, um, you know, you can actually set up your machine to act as a router and route packets back and forth. And so you can use these kind of techniques to actually do that and make that happen. Um, but it can be as simple as this or as complicated as, um, as it needs to be. Um, and so this is why, you know, we're hitting the high level overview of networking. So we're not going to get into exactly how all this stuff happens, but you know, when you take a networking course, you will get into these details. And so that's why our packet can go from A to G. And then G has some routing table that says, okay, a packet destined for 8.8.8.8 needs to go out on this interface. So it sends it to the next hop, the next hop, the next hop, and so on until it goes all the way there. Yeah. So the gateway in the switch can be physically separate. So that's most of the times when you think about home networks, we have a, um, we get a router, right, which has ports on it. And it acts as both the switch and the gateway. Yeah. So when the packet comes in, like, let's say G comes in, it says the destination IP address that knows it needs to to get this packet to 8.8.8.8.8, it looks up in its routing table, what interface do I send this packet on? So it would probably have a rule, hey, by default, if you don't know, so like think about your home router, right? So home router, your A, your switches G, you send a packet from you to your home router, the home router says, oh, and actually I guess the diagram is a little bit different, on a home router, you'll have maybe four ports for local, and then you'll have like what they call the WAN port or like a wide area network port or your, to your cable box or whatever. And so your router says, okay, 8.8.8.8.8, let me look it up in my routing table. Oh, it's not in here, the default is to send this packet out the WAN, and so it gets sent out on this to that next packet. And then it's your ISPs responsibility to then get that packet, that next switch or that next router uses its routing table to figure out where that packet goes and it keeps going on from there. So the question about Wi-Fi extenders or mesh networks operate more on either the link layer or lower on the physical layer. So to be perfectly honest, I don't know exactly how they work, but you can think of they work underneath this level. Cool. And so the cool thing is for all, so all you really need to know is understand exactly how packet, packet movement works at the local network level and then extend that concept up with routing. And now you have packets that can traverse from your machine to another machine completely on the other end of the network. So let's do, I mentioned a Wireshark last week. So I did install it. Yeah, routers pass, except all packets, pass them along just like the post office, exactly. And the interesting thing is where this gets into kind of interesting things and why it's not good to let the source define the routes. So here you can have three different ISPs like I don't know, level three, Sentry Link, somebody else. They all have connections with each other. And for like business reasons, let's say L3 will say actually it's a, I'll say Verizon. I don't know if they're actually one maybe. So L3 would say actually it's the shortest path for this packet to get to Sentry Link, but it's cheaper for me to send the packet to Verizon. So that's actually why it will go to Verizon. And as we'll see, kind of the nice thing is there's no guarantee about what path packets take forward and backwards. So the host in Sentry Link may say, oh, it's actually better for me to go to level three. So there's all this complex kind of business level decisions that happen to decide where packets go kind of in the middle core of the network. But it really does all, is based off of these protocols and these ideas. So let's do two things. Let's open up a terminal. I am gonna start a TCP dump, interface five, and I want ARP or ICMP. Oh, and I want to write that out to a file, write temp test.pcap. So I'm gonna capture all ARP traffic and all ICMP traffic and I can't do that, I need to redo sudo. So I can do that and listening. And now I will ping 8.8.8.8.8. And so we'll see some packets go back and forth and I believe there's a way to payload. Okay, that's fine. So let's cancel that and hopefully we'll be able to see. So now I'm gonna open Wireshark and let me open up that file, testpcap. There we go. Okay, so we didn't get all of the ARP requests. Ah, this is fine. Okay, no, we didn't get the initial ARP traffic here. So this is Wireshark, this is the tool I was telling you about that you can use to graphically look at packets. So you can see kind of on the left here, it's showing me the requests and responses. It's parsed this packet out and it's shown me the source IP, the destination IP, the protocol that it's using, the length and it's parsed it out to say, look, this is an echo request packet. So it's a ping request packet with this ID and this time to live of 24. And on this frame, you can actually look and see the frame level. So this is all the ethernet level packets. Sorry, this is the frame level. Then you can see the ethernet level. So you can see the source ethernet and the destination ethernet. So this is the, sorry, the MAC address is what we've been talking about. So this is the destination MAC and the source MAC. And this is from my machine to, this should be my router. So this ASIS-TEX-C. Then we can see IPv4. We can see all the different headers in here and the really cool thing is, so on the bottom here is this is the raw packet itself. And as we highlight and click on different aspects of this packet, it shows you where those bytes are in the actual packet itself. So we can see that this specific byte being one tells you that it's an ICMP packet. And we can see the, oh yeah, this is interesting. So you can see the IP addresses. So this is the source IP 1921680.27 And kind of interesting since this is 8.8.8.8.8. And that's a valid, we can actually see those eights here because this is still the same hexadecimal number. So we can actually see that in there. And furthermore, we can look at this ICMP packet to see what type of packet this is. So we can see there's check sums in here, which we talked about are like hashes, but not as good, timestamps and the actual data that gets sent back and forth. And we can see that it sends this kind of pattern of, you can see 08090A, O-B-C-D-E-F, one, two, three, all the way up to three, seven. So just kind of a bunch of bytes. And then the goal is to see that back from the other side. So the other side responds back with an ICMP reply with the same data that we sent. So yeah, you can see the command in the terminal is right here. I'll keep that up. Sure, I can copy and paste that in there. It won't work exactly for you because you'll need to change the interface. So for me, the interface that I'm using is EN5. For you, it will be different depending on your machine. So yeah, this is, and we can see kind of looking then at a ARP packet. I'll go back to Wireshark to kind of show some of the features as we go along, cause it has really cool stuff to do, especially as we get into TCP. We can even see it here for this ARP packet. So we can see that this is an ARP request saying, hey, who has 192.168.0.131, which is not me. It's another machine on my network. So I'm showing you, I guess, random IPs on my network. I don't know who has that. Whoever has that tell 192.168.0.1, which is our gateway or our router as well. So it's like the router has a packet for this machine that needs to know where to send it. Will Wireshark be used for a future assignment? Perhaps, we'll see. Okay, how are we doing on time? Oh, plenty of time. Cool. So 8.8.8.8 is a target IP address. So it's some IP address. We know it because it's Google's DNS server. You can also do something. Oh, maybe this would be, we'll do that and we'll do ping. So I can ping google.com. We'll see, I'll get a different IP address. And so my machine has my gateway. Oh, I don't need Google's gateway and that's the beauty of it. I only need to know about the next hop. So I only need to know, oh yeah, this is, I shouldn't have done UDP. This is all of the video that we've been sending. But I can filter this a bit. No ARP traffic. Okay. So, nice. Okay. And what about DNS? This is interesting. Okay, so the beauty of it is I never need to know Google's gateway. So all I know is my own gateway. And then my gateway knows how to get packets in the next hop and the next hop and they just luckily get closer and closer to Google. And at that point, then Google gets that packet. Yeah, you can ask the, once the piazza dies down, that's definitely a good idea. Let's see. Okay, let's get out of this. Let's continue on. Cool. Okay, so yeah, so then the, great, okay, cool. So that's kind of how routing works. So you can set up those routes statically. They can be done in more complicated manners. We're not going to get into that. So now that we, how can we know if a router is doing something similar to, well, I don't know what that is to what traffic going through. I don't quite know what that question's asking. So feel free to rephrase it or edit that to happy to answer. Cool. So now we've looked at, and we have an understanding of how data works and how packets go from the link layer. So at the hardware interface from one package to the other, how IP traffic and how traffic gets from one machine to the other on the internet. Oh, we don't know. So yeah, this is the, so any route and any hop that the machines take on the internet, any machine could be listening and sniffing to our packets. So we really have no way of knowing if you or your ISP is, if somebody's sniffing on your packets. And that's why cryptography is so important and why things like SSL, TLS, HTPS are so important because any machine on that path from you to Google could see exactly what we were doing and what we sent. So now what we're gonna do is we're gonna go up to the transport layer and start seeing how data actually gets from one machine to the other. We're gonna first look at between TCP and UDP. We're gonna look at UDP, which is kind of nice. So UDP, and this is very ironic and funny that we're talking about this so I'll literally, you saw UDP packets flying back and forth on my machine. And so the idea is UDP basically is a very thin layer on top of IP. So no, UDP stands for the user datagram protocol. So UDP provides a connectionless, unreliable best effort datagram. So when we say datagram, we just kind of mean a packet or one piece of information. So the whole point is just to get some, you can think of it like an envelope or whatever or actually an envelope is not a good metaphor, maybe like a postcard. So we're trying to send some piece of information just like we've been trying to use TCP, sorry, ICMP4 with Pings. And we get, we don't, and UDP the important thing is doesn't offer any guarantees on top of IP. And we know one of the really interesting things about IP is it doesn't provide anything, right? So this means that it's connectionless, means that I haven't established a connection with the other side. I'm just gonna send a packet and hope that it gets there. It's unreliable, meaning I have no idea if this packet will ever make it or not. It's best effort. So people will try to deliver the packet, but it could just get dropped for whatever reason. Datagram, again, one piece of data. And it doesn't, so delivery, integrity, non-duplication ordering and bandwidth is not guaranteed. So all of these things, nothing is actually guaranteed in here. But it does offer one really important thing on top of IP. So when we talked about IP, all we really get is the ability to, let's say, so when I say ping a specific machine, 8.8.8.8, when I say ping a specific machine, here 8.8.8.8.8, it's replying to me. But as we saw, we actually want to be able to run different services on this IP address, right? We want to be able to run things like HTTP, SMTP, DNS. So actually that is 8.8.8.8 is the DNS server of, is the Google's DNS server. And so maybe I want to get those packets. NFS, the network file system. So how do I, and the way I think of it and the way that will help you is you can think of an IP address like an address, right? We talked about addresses in the physical world. We have an address we can send out of there. But if you're in a large, let's say like apartment complex where you have a lot of people living there, that building itself has an IP address, just like a, sorry, has an address, just like a machine has an IP address. But how do I then get that envelope to a specific person inside that house or that apartment complex? Yeah, so apartment number, right? So I need to know the exact apartment number within that building. So the very similar analogy works here where we're gonna introduce the idea of a port. So there'll be zero, basically 65,000 ports on a machine so we can talk to different applications that are listening on different ports. And as we'll see, we'll have to define standards to know which ports are what things are on. But this is the big thing that UDP adds on top of IP. So it introduces this notion of a port so that you can send different messages for different destinations for the same IP address. And that machine will know exactly what destination you're talking about and we'll be able to give the packet to the right application. And so UDP, kind of interesting, right? It's like, why would you wanna use something that doesn't offer you any of these great features? And one of the key things is multimedia. So exactly why essentially Zoom, what we're using now we saw is using TCP because we don't care if you, let's say, one packet of my voice gets dropped you don't wanna wait for it before getting all the rest. You wanna display those right away. Same with video calls and also for services that are based on this very simple request reply schema. And so you need things like DNS, NFS, remote procedure calls, use UDP. Oh, did I meant to say TCP? Yeah, sorry, I meant UDP. I'm fairly certain. Like we saw, well, we can look at it really quickly, right? We can look at, right? These are all the UDP packets that are happening on my card right now. And I'm the only one with video, nobody else has video. So I wonder if you can see it. Does it pause when I stop talking? That'd be kind of weird. But yeah, you can see versus let's say TCP. Like there's some TCP action going on and it's probably a lot of stuff operating the background, Dropbox, pinging its backend servers, all kinds of stuff. But we can see that there's a lot more UDP traffic going on and it's happening. You can see these are timestamps. So there's a lot of packets happening very, very quickly. Cool. Okay, so then let's look at the, yeah, the reason why UDP is preferred for VPNs. It's probably a design decision as we'll see. So it'll make more sense when we look at TCP because TCP gives you a lot of important things, but that comes as a cost. So for instance, even games, let's talk about games for a second, right? Games, you know, if you're playing like an online game where there's a server component, right? You want like everyone needs to get updates and everyone needs to get maybe some kind of updates in a specific order. Like you need to know that your health goes down or something like that. So you may want, and you may want non-duplication. So anyways, we'll see, you can add these to your UDP without getting all the features of TCP. So that's probably why VPNs typically do this is they have a mechanism to retransmit and they have features of TCP without requiring all of the overhead. Oh, how about now? How about now? Okay, sorry about that. Okay, so now here we can look at the packet of a UDP message. So, and we can look at the headers that are here just like we looked at everything else before. And we can see very interesting, UDP adds very little on top of IP. So all that really adds here is source port, destination port, and these are, and message length and a checksum. That's it. So that's everything that's here. And so we can see that source port and destination port are, so this is 32 bits. So it's 16 bits. So then how many ports do we have? Yes, six, five, five, three, six. Yeah, two to the 16th. So this is how many ports we have for each IP address. Cool, so let's see then how this is actually used. And so just like before, right? The data gets kind of a encapsulated and we're building up this kind of like onion of layers. So in the core right now, we have our UDP data that we wanna send. We have that UDP header that specifies the source port, destination port. That is put inside of the IP data where the IP header adds the source IP, the destination IP and some other features. And then that all is put inside a link layer of the data of the frame, along with frame headers of source MAC and destination MAC. And so that's how kind of it's stacked inside of this packet. And then, okay, so let's look at a packet real quick. So, okay, so now I'm gonna do dig. So we'll do, we'll do something we know, ASU.edu. So dig is a command to do a DNS lookup. And normally we'll use your DNS server, but you can use the at sign to use a different server. So this is saying, what's the IP address of ASU.edu? Ask 8.8.8.8. So I do that, and oh, there we go. Okay, yeah, I was wondering why it took so long. Okay, so it's telling me, okay, ASU.edu is at the 104, 16, 50, 14. So then let's look at what that protocol look like in Wireshark. I guess I should stop quitting this and just... There we go. Okay, cool. So now we can see here. So this is a, if we kind of expand this packet out, there we go. So we have the Ethernet layer. We have the IP layer, right? So again, this is my source 192.168.0.27, destination 8.8.8.8. Could I rephrase ask 8.8.8? What's the, yeah, it's tricky. It's the DNS protocol. So we can't, and we're not gonna go into the details, but yeah, basically we can ask 8.8.8. It says, I don't know, and it asks somebody else and it keeps going from there, but from our perspective, we're just asking, hey, 8.8.8.8, what's the IP address of ASU.edu? And it's specifically using the DNS protocol. So if we look then now at the, so this was the port and all of the information at the UDP level. So we can see the source port is something 55567. So this is what my machine decided that source port was. Then its destination port was 53. So this is important. Okay. I gotta remember where that is, but okay. I'll find it in a second, but anyways, so this is how when I ran dig, right? Dig needs to know, okay, so I'm talking to 8.8.8.8. But how do I know, how does dig know to use port 53 in order to make a DNS request? So the way to think of it is technically, and what this means is that there's some application running on 8.8.8.8, which is speaks the DNS protocol and is listening on a port for DNS requests in order to send DNS replies back. So it's just a standard that port 53 is the DNS port. So there are a number of ports that are defined by the standard. And so I'm trying to remember, if anybody remembers what that file is, I can open the file here. Let me see. ETC, is it services? There we go. Okay, cool. So we're not gonna get into the specifics of how DNS works. You can go look that up. But yes, there's basically DNS is insane. Let's just say very complicated. But yeah, so here we have this, yeah, ETC services, that's what it is. So this has, so if we look up DNS, hopefully, where's 53? Oh, domain, okay, they call it domain instead of DNS. But here we can see all the different ports. So these are a bunch of different ports that are essentially allocated as part of a standardization process of what ports are on what services. So for instance, SSH is TCP over port 20. FTP is TCP over port 21. Let's see, what are some other UDP ones that are actually interesting? So yeah, DNS was the one we were looking at. The domain service can be over TCP or UDP. It's typically over UDP. So anyways, these are all just defined here. So things like HTTP is over port 80, also called dub, dub, dub. And ports, let's say 443, 443 is HTTPS. And so basically there's just these standards of what all these ports are. And so we can then look at the DNS query just to dig in a little bit about how this works. But this is basically, I'm querying and saying who has ASU.edu. And the then response can say, so this is then the response. And so we can go back through the headers. We can see that this is a response from 8.8.8.8 to 192.168.0.27. And what does, so let's think about the dig program that was running. How does that know that a UDP packet came back as a response to its query? Yeah, remember these are the only two packets that get sent. And so the only thing that, basically the only thing it has to do is it created this source port 55567. And so it knows it got a response not, so from specifically the IP address that it was meaning to. So from 8.8.8.8 and specifically two port 55567. So this is how it kind of knows that it's getting that response back. Now there's also a, we can see the DNS has this transaction ID. So it probably also looks that the ID is the same. But at the UDP level, what it has is this destination port. So this is how it knows this reply is back for it. And then we can, you can dig through this query here. So we can see ASU.edu is at address 1041650.14. So the interesting thing to think about is this DNS protocol, these UDP packets get sent every single time you type any IP address into your browser or unless it's been cached locally, like stored to be reused. So every time you go to a site before it can even get there it needs to translate domain name to IP address. And then once it does that, then it can do whatever it needs to do. So this is just kind of a brief example of how actually, why don't we, you wanna look at some zoom packets? One, two, three. Yeah, so we just got 478 packets. Let's open this. No, we won't hack zoom. We're just looking, trying to look at what's going on. So this is, maybe this is a zoom central server. We can look at one of these packets. We can see that it's sending a bunch of bytes. So this is in the length of the packet. You can see the ASCII values here. So if ASCII, I wonder, I would bet it's kind of encrypted. Okay, how about this? Why don't we do this together? Okay, I'm gonna hit enter. And then, yeah, somebody type something that's random, small, but unique into the chat. Now, can't you do random? Okay, thanks. Okay, so out of 15,000 packets, this is actually an interesting way we can see if it's using encryption. And of course, maybe it's, maybe the chat is not happening over UDP. That's an option. Let's see. Find packet, string. Yeah, it does make sense to use TCP for a chat. So let's capture everything. Okay, somebody send another chat message. Okay, oh no, too much, too much. Let's see, interesting. Okay, a lot of SSL stuff. So it's probably unlikely that we'll actually get that. I think there's somebody in here, Popeyes let's go with. No, no Popeyes. Oh, oh, let's get rid of this filter. Get rid of that, find anything no Popeyes. Yeah, so at least that's, so that's good. This means that at least we think that it's probably doing encryption of our traffic. So that's good. Yeah, and we can actually see here kinda interesting. The IP addresses are the same, right? So all the UDP packets are coming from this 52, 25, 157, 135. And the packets that I'm seeing here over TCP are happening over, what port is this? 443, yeah, so it's SSL, but to the same connection. So it's highly likely that they're using SSL, but I would guess probably TCP for chat. Cool, well that was fun. Okay, and so because at this same level, so because UDP doesn't offer any additional guarantees over IP, essentially all of the same attacks against IP work for UDP. So the same types of things we talked about of IP spoofing, IP hijacking, also happen at the UDP level. So we can, for instance, if we wanna take this scenario, as an attacker, if there's a trusted server and a client. So for instance, maybe it's this server is a network file system, so an NFS server that is, so maybe it's an NFS server, a network file server, and maybe the client can access either files without logging in or anything. And so we can, if we pretend to be this trusted client, we can maybe get the server to remove files or do whatever we want. And so we can essentially use the exact same ideas of IP spoofing and send a spoofed UDP request to the server. So specifically then to get this spoofed UDP request to get the server to realize it, how does that packet have to look? So I'll do trusted server and I'm the attacker, right? So what does my packet have to be if I want to impersonate T? What packet do I have to send out? So let's think through it, we'll do it at the levels we're used to. So what's the destination IP gonna be? We'll just use the names right now or IPS. And then what's my source IP, IPT, for now we'll ignore the link layer because we're not quite sure how that data's gonna get there. But now at the UDP layer, so what's the destination port I want? Yeah, well I need to figure that out, right? It depends on what service I want to, right? So if this is NFS, yeah, so let's say here, 2049. I don't know if this is exactly right, but we'll go with that. So I need to know what port that service is thinking about, yes, and somebody's right. So I will swap these because this goes kind of better like this, right? And then the source port. What would the source port be? Yeah, essentially we can make this up, right? We can put 55667, that's like what my machine have. We can do 6972, it really doesn't matter. Anything, essentially from zero to 65536. So we can do that and we can send this packet. Oops, it's ugly, right? So going with our version of layers here. And now we send this packet out, A sends this packet, this packet goes out, it goes to S, and then S is gonna get this, and it's gonna reply, and where's that reply going to go? Yeah, to T, right? And what does that reply look like? So then let's write up the reply here. So what's for the reply, what's the destination IP address gonna be? IPT and the source, source IP, IPS, and the destination port 5572, source port 2049, great. And so this packet then gets sent from S to T, right? So just like IP spoofing, the, and the interesting thing here is the response, we may or may not get this response, right? We may get this response if we're, let's say, on the route or on the local network between TRS. So this is kind of what we talked about and why we talked about being able to do ARP spoofing and ARP sniffing at the local address in between TRS, right? So we can actually get that packet if we're on local networks and we do some kind of ARP poisoning or if we're on a router or an ISP that are in between them, we'll also get those packets. So that's kind of something to think about the reply. But we can do this and we can do this incredibly easily like this UDP spoofing is very easy to do. And now though, so now what about the other way? So the other way we thought about this is in the form of hijacking, right? So we have our trusted client, have a server, an attacker. So in hijacking, right, the difference here is T is going to send a UDP request. And what's that UDP packet gonna look like? So T sending a packet to S, destination IP, IPS, source IP, IPT and destination port we'll keep it the same as the other example, 557, so 2049 and source port is and source port is, now we'll do a different one, 5290. Okay, so just like let's say now, so we looked at DNS, right? Let's say this is a DNS request. T is asking S, hey, what's the IP address of, and in that case, let's change this to 53 just to be a little bit more correct, 53 DNS, right? That's what we saw DNS as. So T is asking S, hey, what's the IP address of, let's say ASU.edu, right? And so this packet gets sent from T to S. Now we wanna essentially pretend to be S and hijack this communication. So we want to spoof a reply from S to T. So we wanna send out our own packet and what's that packet gonna look like? So what kind of packet do we need to come up with? So we need a destination IP. So what's that packet gonna look like? IPT, source IP, IPS, destination port, 5290 and source port, 53, perfect, great. So now if I, so if as soon as T sends its reply, if A is able to send this packet out, it goes to T. Now, T gets this packet, what can it know about this packet? So again, what we talked about, what does T trust about this packet? What does it know that has to be correct? Yeah, destination IP. This is the only thing that it can trust. It doesn't know that A forged this packet, right? So it can, so it essentially has to take it on faith and in this way, A can hijack this communication and be able to trick T into thinking that ASU.edu or whatever domain name is what A says that it is. So we may need to worry, of course, S, like is mentioned, S is gonna send its own reply. So it depends on the protocol, especially with UDP. Oftentimes all we need to do is be first. So we just, if we get there first, T will ignore the second reply. We're gonna ignore NAT and all that stuff for right now. We can go over it later at some point, but for this, it doesn't matter. But okay, so A had to know, obviously, the destination IP address, the source IP address, because these are the people that it targets. It knows, let's say it's DNS, so it automatically knows the source port. But how did it know the destination port? How can A know this destination port? Yeah, it needs this somehow, right? So this is kind of interesting, right? It has to somehow know that destination port. So it can either try, so one option would be brute force them all, just send out 65,000 packets. Or it can sniff this original packet if it's on the path or it's on either the local networks, then it can sniff this packet and send the proper reply. But there is some measure, the measure here is in getting this destination port, because if it's not correct, then T will just drop it because it says it's not part of this reply. So this will come up over and over again. It's an important concept to think about. But yeah, we basically have now this notion of a UDP hijacking where the client sends a request and maybe hopefully the attacker gets a copy of it somehow. And we reply with our spoofed UDP reply before the server is able to do that. Ooh, this will be a fun one. Okay, cool. Let me check if I have something. Cool, so these are two different attacks we looked at that allow us to be able to spoof UDP or spoof UDP or hijack UDP connections. Yes, I currently use iterm2. I was using Alacrity, which is pretty good, but I don't know, it broke in my new system. And okay, so now though, so okay. So now if we think back to what we talked about as part of what we wanna do as an attacker is think like attackers and think like how to break into things. So we have some remote system, some remote server on the internet, right? And just like if you remember, we brought up this idea of bank heist movies, right? So what happens in a bank heist movie? You first need to, the very first step is essentially recon, right? You need to understand exactly what's going on on this system in order to break in. So when we're talking about a remote server, one of the really important things is what, yeah, okay, zero is get a crew together, that's good. But the next step is recon, right? You need to be able to perform reconnaissance on the system. So what we wanna know specifically with remote system is is it running a DNS server? Is it running FTP? Right? And so the idea is we need a technique in order to, and this is called the port scanning. So we wanna be able to scan all of the ports of S to understand what services are running on those ports. Because if we know that there's a DNS server, one thing we can do to go to step two is we try to identify what application, what is the DNS server application that's running? What version is it running? And then does that version have a known vulnerability that you can use? So basically, and the way we do that, there's many different techniques, we're gonna go over the basics here, is you send a zero length UDP packet to every single port on the system. And if you get back a message that says an ICMP message, which is at the IP level that says the port's unreachable, then you assume the service is unavailable. The problem here is many TCP IP stacks implement in limit on the message error rate. And so it can be kind of slow. So why don't we, now, oh, brulink nmap. Don't know why you don't just do that. Oh, fun, okay, bup, bup, bup, bup, bup, bup. There we go, okay, user local opt nmap. That's not what I wanted. Then, okay, there we go, cool. So one of the things I can do so nmap is kind of a, the way I like to think of it is it's a network Swiss army knife tool. So it has tons, so many features. It's kind of crazy to keep them all up. It can do things like scan ping scan. So scan host in your local network to see if they're up by pinging them. So for instance, let's see, one thing I can do right now, I just want to do a ping scan. Let's see scan sn sn 192.168.0.0 slash 24. And I think, yeah, okay, cool. So this just sent pings, 255 pings. So it scanned this whole slash 24 of my local networks. These are all machines on my local network. And then it's telling me that 192.168.0.1 is up.27, which is this machine, and then a bunch of other machines on my local network. So you can, so now that we have that, we can let's say, which one's Fang? Yeah. So we can do nmap you and I need to run it as root. So now, oh, let's do that while also capturing. Okay. So things are happening. It's listening. It's port scanning. And as we saw, UDP scanning is a little bit slow. I think there should be at least one service on here. So essentially what my machine is doing is sending out zero length packets to 192.168.0.134 to each of the different ports to try to see which ports are open. So we can see here's an example of something that actually happened, a UDP scan on this machine. And so by default, it actually will not do all 65,000 ports. It will only do the most common 1,445 for time. There's a different option to set up to scan all of the port ranges. And so you do that and it will tell you the state of all the ports on that machine. So hopefully while that's going, we will cancel that. We'll see that sent out a bunch of packets and let's open recent, test pcap, good. Yeah, so here we can see all of the packets that are getting sent. So this is a, yeah, you can see the destination port keeps changing, right? So this is all of the different ports that it's testing. I guess it's testing all of them to see if they're open. So it's randomly searching through this range and you can see it's sending out these ports really quickly. Oh, see, and then here's it's getting destination unreachable. So this is the destination unreachable packets that it's getting back from that other machine that's saying, hey, this, I couldn't get to this port. There is no port on here. So, okay, good. So this is a good stopping point right now, but before, I would be remiss if I mentioned to be careful about running this. So the way to kind of think about this is you're, so it's not illegal to port scan a machine because you're trying to determine what ports are open, but it's not friendly, let's say. So yeah, don't do it to random people's machines if you don't have permission. It's very much not a nice thing to do. And yes, as you can see from all of this traffic, it is insanely easy to detect, right? I just sent out thousands and thousands of packets in eight seconds, right? This is like a bunch of packets all around the same time. And so yeah, just, you know, don't do stupid stuff. It's not illegal, like I said, but it's not nice. So, you know, if you wanna play with stuff, do it on your own machines, like spin up a machine with a DNS server and, you know, sniff your own packets. So that's definitely what, but you know, it could be like here's some fun targets to do. Yeah, people can easily detect that you're doing this. It's very clear. And so some nice things to do, scan like your iPhone or maybe a printer on your network. That could be very fun. It's always interesting to look at what services are running. So yeah, cool. So we learned about UDP packets and on Thursday we'll get into TCP and we'll talk about assignment four stuff. So keep signing those keys. See you everyone.