 All right, good afternoon, almost good night, everyone. Slight housekeeping, your first homework assignment will be released on Monday, so we'll start off. Yay, it's going to be awesome. Programming homework assignment, you can write code and fun code, security code. If you don't like coding, you can probably wrap this class, or you'll find out that sooner or not. Cool, any questions before we get started? Don't ask me what the assignment's going to be, sorry, I'll hand that off to you. Anything else? Yeah, do we say it post again? On Monday, we'll talk about it in class, we'll be ready for your class. What if computers are bad? What if what? What if she's got a bad book? Ask someone to borrow our starter, yes? Two textbooks from the Force, can you comment on the material and the context we should be looking at? Yes, so on the textbook, let's see, I'll bring it up there. So we left off on Monday on art spoofing, so we saw how a host C, this is where we left off, right? Yes, okay, we did this. Yes, so we saw that an attacker that's on the local network, right, an attacker that is on the same switch or local area network as two hosts can trick each host and change their, basically their art table entries to say, if you want to talk from host A to host B, talk to essentially host C's MAC address. And if host B wants to talk to host A, then they should talk to host C's MAC address. So all communication will first go through host C on the local area network, and neither host will actually know that this is happening. So there's some problems though when you do this, right? Because the cache, the arc cache should be invalidated. Somebody may ask who, you know, you may have an arc request, and so it could be the case that host B tells host A it's real address, it's real MAC address, and then all of a sudden you've lost this connection. So you're the bad guy, what do you do? Or bad person, doesn't have to be, you know, get the software on the other system. What was that? You can get software on the other system. Ooh, you're getting software on the other system, so take over the other things. It's not really, you just need to monitor when the arc table goes. Ah, okay, okay, so try to figure out when the arc table's going to switch over or invalidate and then send your, let's move for why, nice. What else? Just periodically send replies to each host. Yeah, so this is kind of when you're doing programming interviews for companies, right? This is tangent, that's related. They tell you, you know, I should do the stupidest, easiest thing that works first, right? That should be your first answer. So that's a lot of times what I agree with when I think about these things. Yeah, just brute force it, like just keep sending these arc spoof packets. If you send them every 10 seconds, the amount of traffic you'll miss will only be 10 seconds, right? That's definitely something that'll work, but you're making a little bit more noise in the network. Maybe you're more detected, so maybe then you can move on more sophisticated methods of trying to figure out when that cache is going to be validated. Cool, yeah, so most arc spoofing tools do this. And those repeatedly send these spoof replies in order to keep that arc cache where they want it to be, right? So this is the way they continually manage the middle of that traffic. And there are tools that do this. So you can write these tools yourself. You can also use off the shelf tools when you are learning through your own education or performing a sanctioned penetration testing. So DSNIF is a collection of tools. There's all kinds of cool stuff. So these tools will look at network traces and try to pick out passwords in the network traffic. So they are looking for certain protocols and patterns in order to submit either like SMTP messages, files that are getting sent, URLs that are getting sent. And this allows you to passively monitor. And they have other tools to arc spoof and DNS spoof to actually perform these attacks, essentially automatically, so in a tool. So they also include tools to perform these man in the middle attacks. So once you, by using these arc techniques to route all traffic from one host to the other, you can then use these tools to force the traffic to go through you and to actually see all the communication that's happening. Entertap is also another tool for performing these man in the middle attacks. You do arc spoofing. You can intercept SSH. You can collect passwords. It's a really cool, fun one to play with. I have not really a go at this. You set up which groups you want to be poisoned to which other groups. You then on your system, so that your system needs to do packet forwarding. So when you get a request from host A to host B, you need to forward that request on. And so you need to set up in your, because by default, most systems don't do this, don't act as routers. So on Linux, you have to enable IP forwarding inside the setting. So this is how you do that there. Then you start the poisoning with the Entertap tool. And then you actually collect all the traffic so you can use arc anything to be TZD up that we talked about on Monday. And you get to dump all the traffic that's getting sent in between those two hosts. So this kind of shows how easy this is to perform. So you just learned about the attack, should you? How do you defend against this? You are protecting that work. What do you do to defend against this? Static arc tables. Static arc tables, that's a good one. Yeah, you can statically program the arc tables on each of the machines. Anybody program like static IP and static routes before? Yeah, is that a pain to do in a large network? Would it then, then now if you had to not only do static IP and static routes, but all of these MAC addresses for all of the physical machines on your local area network, you'd have to put on each machine. That's kind of rough. And what happens if we get a new nick? Right, now you have to update everyone else's arc table entry that you've statically programmed so that they can actually talk to your new machine. What else? You said it's like an IBS or an IBS that you can rule this name. I see a bunch of arc replies in a certified line. Yeah, so you can look for replies that have the wrong response, right? That can be a way to look for it. So try to detect it in the traffic, what else? If I come up with a mechanism such that any user can talk only if they have a white certificate. Or like, so if I pass the IP of MAC through encrypted one so that they can only decrypt only using their key, or like RSA. So how do you transmit those keys? So if I'm going to enable the system on my IP, on my network, I would basically keep them clean so that they can, and some left off steps so that they can actually encrypt their key which can only be decrypted by some other person because they're in the public key. So if I have that scenario, person see, I mean the hacker will never have any key so he will never be able to map the forwarding. So it won't make any sense for him to like to be able to forward the packet. I agree that it kind of has the same drawback though, the static art tables, right? Because you have to do a lot of manual configuration on each machine to make sure the keys are all distributed properly and all those kind of issues. But yeah, if you could do that, yeah, it would definitely be another layer. So we can, like you said, we can use static art of entries, it could be difficult to manage in a large installation. One idea that can be nice to think about, it's not always a good idea to throw away an entire defense just because there are some bypasses or because it's difficult. There's some user experience or maybe setup problems. If it does offer a lot of really good security for critical servers, maybe that makes sense to do. So like a DNS server you don't want, you wouldn't want so maybe you could do that or maybe you can hard code gateways, probably another thing. You can also, I think we mentioned this on Monday, so you can have the operating systems being more unsolicited in art replies. So the kernel now would have to keep track of what replies have I sent and what have I got responses for. If I get a response for something I've never sent, then throw it away. Unfortunately, we also talk about this is still vulnerable, right? Because you just have to wait and you wait until that person sends an art request that says, hey, who's at this, where's this IP at what MAC address? And all you have to do is beep the other ones reply and now your reply is legitimate and the other one's not legitimate, it'll be a problem. So you have to reply on a specific period of time like for 10 minutes one hour in a day or in a week. You mean like control the cache, like how long they're valid for? Yes. I'm sure you can, I'm sure in Linux you can. I mean, you might have to read by your kernel or something. I mean, for not every time they are listening to and only for specific time they are listening and updating their connection. Yes, the problem is if you have sale entries, that means if machines move to different network cards or something like that, right? Now you can't talk to that machine until you try to refresh, right? So, but yeah, you could, it's adding more difficulty to the attack but it doesn't really fundamentally solve kind of the attack, right? Because I can just, I don't care if I have to wait a day, if I can do it once, then now I've got intercepted all of your traffic. Yeah. Like a timing in what sense? So. You send the object in what's held and then there's this activity of the attack behind it's supposed to come back. And it could be something like that. So. Did you do it? But if it's in that range, right? Because the, so the ART request is a broadcast, right? So if everyone gets that request, so you can't hide any information or requests because the attacker also gets that request. So yeah, you need some kind of secret sharing, essentially, between the two machines beforehand before you did this, so that you could say like, I'm really the same person. Let's feel probably, we need to sort of pull, right? This is probably difficult to implement like static, sort of, to be a difference. Yes, yes, exactly. And then it could cause, right? And that's probably the problem, right? If you have some kind of defense, if it causes a network, operators, any kind of headache, they like throw it out. Why would they use that, right? It makes their more job more difficult. For the abstract, you know, thing, they've never seen this, don't know how easy it is, it's just kind of an abstract concept in their heads. And then they realize, wait, I have to do all this extra work in defending this thing or whatever. Nobody's gonna, no, not actually, exactly. But then they get hit and then they get trouble, right, yes. So classic security aspect. So we can update on the timeout. We can monitor changes. So this would be a little more active approach, like you said, with the IDS, IDS, we can listen for our package so we can have a sniffer in our network listening for our packets, keeping track of internet IP pairs and trying to see when they're swapping. What would be the downside of this? Yeah, so you can get alert blindness or alert fatigue, right? Like maybe it's actually supposed to be doing this or something, or maybe, you know, those corner cases where you actually not appear attacked, the false positives, those can completely ruin people's trust in this and then they'll just kill it. Also, think about large networks, right? If you have a very large subnet, even just monitoring all that traffic is not straightforward. It can actually be very expensive to monitor. Could you have to monitor all traffic that's going across your network? So it could be difficult to perform that sense. Okay, so kind of going more broadly, so we talked about defenses against R. Now if you think more broadly, how can we detect sniffers on your network? So somebody's saying, why is this a hard problem? Yeah, they're passively listening, right? That's like, I don't know. Trying to detect somebody who's just like, has their ear to your door, right? And it's trying to listen in on your conversation. It's very difficult. They're not actually making any noise. They're not saying anything out loud, so I'm going to detect them. So, ideas? If you look for increases in packet delay since it goes through them and then it goes back to the switch and then to the... So I guess there's a couple things, right? Passive or active sniffers, right? So an active sniffer where we've done an art poisoning attack and now we're just listening to the network flow. Yeah, if you can look at maybe the TTL value will be different, right? Because the packets from one host to the other, the TTL should be one or decreased by one. Here it was decreased by two because it's going through your system. Maybe that would tell them. Of course then the attacker should have changed their operating system to not decrease the TTL value and then now that's not very good. But maybe there's delays. There's extra delays because they're going through another system. Or some others. Louder. Monitor the routes. Monitor the routes. Yes, you could monitor all of the routes. So when we talk about routing, it kind of brings up IP hops, right? And here we're just talking about one hop networks, essentially, like local networks. So yeah, monitoring the routing in there, that could definitely lead to the second simmer. What about a completely passive simmer? Let's say you're on a hub. Don't use a hub. Don't use a hub. Yes, but what if you're using a switch and they've, I don't know, they've done some art poisoning to make it seem like all of your MAC addresses are on their point too, so they get your traffic too. It's a really difficult problem, right? Don't be surprised you haven't solved it in like two seconds, so that's like... Press any of some kind of dummy packet and then maybe track the packet to have, you know, detect the simmer. So see if they respond to it or something, maybe? Or... Yeah, maybe like just cast the simmer right in there. How do you catch somebody listening? I'm trying to think of a scenario like, when you see somebody that you don't quite know they're made, so you go like, I don't know, and see if they turn around. LAUGHTER It's really their opportunity to respond when they need it. Yeah. If you know a number of activizers in our network, then from the address, we can figure out the passivism because there will be one after the address or which will be the passivism. Ooh, okay, so, but what if they're... What if they are a legitimate system? They're just now in from, like an attacker's taken over a system. So somebody didn't come in and plug into the device, right? So that would be one thing. You should know about how many things are plugged into your switches, although, when you think about a building like ASU, right, where any of you can take your laptop and plug it into the wall and get internet access, that doesn't really make sense, right? But yeah, even if you take over one of the machines now, this is a legitimate machine, but now we want to detect a bit sniffing when before it wasn't sniffing, yeah? If you have a configuration management tool set up, you can see if the person's permissible or not. Yeah, so maybe you could, if you have, this is again assuming that you have access to the system, right, and so if you have access to the system and you can do some monitoring to see, hey, this NIC card turned into permissuous mode, that's back, somebody's sniffing our network. So then what about the case on the ASU network when anyone can plug into the network? How do you detect if they're sniffing? So, let's look at some things. So, they're typically passive, right? This is what makes it so difficult to detect. And, okay, so yes, we talked about if we can run code on your machine, yes, we can see if you're sniffing or not. We can use IF config on a Linux machine to see the configuration and we can see that one of the interfaces has been put in permissuous mode. And you can see that here in this example. But, if you have somebody executing the kernel, right, you can control the operating system. You can have the operating system lie and say that it's not in permissuous mode when you run IF config, but it actually is in permissuous mode and it's listening. We can look for suspicious ART activities, this is what we talked about, right? So, you can look at the traffic that's being sent, if there's any suspicious ART thing. If you're doing ART catch poisoning attacks, these are noisy and are sending lots of ART packets. There are tools to detect that, so not even just using general IDS tools, there are specific tools to look for these. You can look for who is a good one. So, if they're using a sniffer that is looking, so as we talked about, TCP dump can be used in the mode that automatically looks up ID addresses to try to reverse resolve DNS names. So, you can send out packets with weird ID addresses or weird domain names to see who queries that and nobody should do it, so if one person does it, maybe you found it out that way. Yeah, so, you would basically try to fake an IP packet from a host that's not on your network and see who tries to resolve that domain name, right? That's up. So, this is kind of the, try to get them to do something, like throw something at them and see if they respond, right, in a way that they shouldn't. The really interesting technique is latency, right? So, you think about what their machine is doing, it's listening to every packet that's coming in and doing some processing on it, maybe logging in or whatever, but fundamentally it's doing more work than other machines. So, you could maybe detect it by kind of every packet when we process, so you can ping the time of post A and you can see that the response time is higher than other similar machines and maybe you can detect it that way. Or you can generate a huge amount of traffic to other machines, right? So, instead, generate a lot of traffic from U and A and then ping B, post B to see if his response time changes based on the traffic you send in A, right? It shouldn't, but if it does, maybe that means that's a signal that they're sniffing your network. So, other types of weird behavior, right? So, you can try to use weirdness when it's in promiscuous mode. So, some kernels accept a packet that has the wrong Ethernet address with the right destination IP, so you could try sending them an IP packet just to them, but with the wrong destination MAC address and see if they respond to you, that means they're in promiscuous mode. So, you can use kind of, so the idea is the IP, the TCP IP hold networking stack, right? Changes subtly its behavior if it's in promiscuous mode or not. And so, from the outside, if you know those changes, you can make these kind of detections from the outside. So, yeah, so the idea was send an ICMP, a ping request to them with the wrong Ethernet address but the correct IP address, and if you get a response back, that means that they're sniffing. There's a tool that covers some of these that you can look at that's pretty old. So, fundamentally, it's difficult, right? It's actually a very hard problem, but it's actually, it's interesting to think about how to detect something that's just listening, and doesn't ever say anything. Another way is you can just completely control the network access, right? So, another way would be don't allow any random person to just plug in to your switch, right? As we said, that can mitigate some attacks, right? This can mitigate attacks where a random people, attackers come in and plug in. It doesn't mitigate attacks when a person's machine gets compromised who's actually plugged in to our switch. So, these attacks require physical access, so hey, stop that, right? So, it seems kind of silly because how do you stop people from plugging things into switches, right? It's just a switch in the wall. And so, there's a protocol 802.1x that does port-based access control. So, basically, your laptop connects to a switch and does authentication between your computer and the switch to say, no, this is who I am, I'm supposed to be on this network, and only if you pass the authentication check will it allow you to access the network. I would say, I don't know if that's true. It sounds similar to high level to basically a security user on an ASU network, right? You have to give your ASU username and password in order to access the wireless. So, it'd be a similar type of thing, but with wired access. And so, this is a nice way to actually force this security to have it be that you cannot plug in if you don't have a username and password. Okay, so we talked about ARP spoofing. Now, we wanna see how can we fake IP packets. So, what does spoofing mean on a high level? We talked about ARP spoofing a little bit. What does spoofing mean? It tends to be something you're not. Yeah, it tends to be something you're not. I could be spoofing being a professor right now. What? Yeah, none of you looked at my credentials ever. You don't know, I could not even be active if there's been a website with some guy's name, and now I'm just gonna have to teach classes. Basically, the entire movie would catch me if you can. I had a different kind of movie. So, the idea is we wanna send a packet as if with the source IP of somebody else. So, we wanna make it seem like a packet came from somebody else. So, we're on a subnet of 11, 10, 20. We have our next network. We have 11, 10, 24, and we have a, this looks like an old school PDA, but whatever, we'll call it a mobile phone. Okay, 11, 10, 20, 76, and we're at 11, 10, 20, 121. So, the idea is we wanna send a packet as if it was coming from 111, 10, sorry, 111, 10, 20, 76, to 111, 10, 20, 14, right? So, we wanna do this, what happens? What's the first thing that happens when we wanna send out this packet? What do we need to know? MAC address, we need to know the MAC address of 111 to the destination, 111, 10, 20, 14. And so, this will actually work even if we put a different from MAC address. It actually doesn't do any checking there. So, we do an argument quest. We say, who has this IP address? We catch that, and then we can just create a packet to 111, 10, 20, 76, from 111, 10, 20, 14. And so, when this machine gets it, it looks at what IP address sent this packet. Who's the guy I think it came from? Yeah, the mobile phone, right? So, we just like this packet went to the mobile phone. Now, what happens when now this computer wants to respond to that packet? What are they gonna do? They're gonna respond to the packet, so they take the, in this case, the source and destination message. The source IP, there we go. It's gonna take the source IP 111, 10, 20, 76. If it doesn't happen in its arbitrage, it's gonna make an ART request. It's gonna get a reply. And so, where will the return packet go? To the mobile phone. So, this is a key part. So, when we look at the IP packet, the IP headers, there's nothing in there that says I'm actually at this IP address or I have this IP address. The same thing with the lower level of the link layer. There's nothing that says I have this MAC address or I'm at this MAC address. Nobody's actually doing that checking. So, the important thing here is I send a packet. I can spoof, can I spoof the to address? What's the point of that? Exactly, what's the point? It doesn't make any sense. It's a nonsensical question, right? Whatever you put it back to address, that's the address it's going to go to, right? So, yes, I agree, it's testing. Doesn't make sense to spoof the to address, why? Because a packet that you send will always go to that IP address if it can, right? You can't try to, yeah, I guess you could, you could, okay, you could put a different, let's see, if you put a different to address with a, and force it to have the same MAC address, the packet will go to this computer, but it won't be processed. The kernel will just drop it because it'll check and see, oh, this is for somebody else, it's not for my IP address, right? So, yeah, fundamentally, wherever you put in that to address, that's where your packet's going, right? So you can't spoof a to address, it doesn't make sense. You can spoof a from address, but what don't you get? The reply, you do not get the reply. And this is a key concept to grasp, and this is why we study the core networking protocols. So we can understand when we look at higher level layers, when we talk about TCP spoofing, like Ketamine used, or UDP spoofing, right? We can see that from these fundamental characteristics at the IP layer that causes different behaviors at the top layer. But we can do this. Nothing in the network stops us from creating this packet, right? The switch just looks at the from and to MAC addresses and puts it out on the report, sends it to that machine. This machine looks at it, there's nothing in it that says, hey, this is actually from 1011, 1020, 76. So it just sees this packet and it responds. Cool. So, IP spoofing is critical because it forms the basis of other attacks. And we'll definitely look at those. So you can spoof DNS requests or NFS requests. Sometimes people use, specifically, we use the IP address to do authentication. So as we saw, if there's a trust relationship between that phone and that computer, if I can spoof that packet and make it think like it's coming from the phone, then that would be trusted communication. Lots of tools available to do this to play with IP spoofing. And there's generic tools and protocol specific tools and we'll kind of get into those protocol specific tools. But that's kind of where we'll leave IP spoofing for now because we haven't talked about what to use it for, right? But the key concepts there are critical. So now I'm gonna talk about different. So what we look at so far is tools. So kind of my high level philosophy. I want to teach you guys the skills to create the tools. I don't want you to be a person who relies on tools, right? I think that's important to carry especially in security. Like yes, if you're doing a professional gig or whatever, you need, use every tool that you have available, right? You need to have the level of knowledge where you could build one of these tools because they're not magic. They just do all the techniques that we talked about. And so by being able to really understand things at that level, you should be able to code these things. So now I'm gonna talk about some libraries that you can use to code network sniffers and do all kinds of cool packet manipulation things. So LibNet is a platform independent library that allows you to build, create, inject arbitrary packets so you can completely control MAC addresses, IP addresses, everything in TCP header. You can completely control everything in there. You can write Ethernet spoofed frames and spoofed frames from other people. You can do custom art attacks by hand. You, it's a C library I guess I should have led off with. And it has, I'll be optimistic and say maybe the situation has changed. Now they used to have some of the worst documentation of any project that I've ever seen. But it actually worked, which was super cool. And a lot of these tools drill on top of these libraries when they build sniffers. So why do you want to use C for something like injecting packets or doing network manipulation? It's close to the kernel, it's low level. It's low level, what does that get you? Speed, speed. Speed, yes. You get a lot of packets, right? And so the kernel, if you don't have fun in time sometimes drop packets, right? And so now you want to be as fast as possible while processing packets, exactly. So that's why a lot of these networking tools are written in C. So you have to initialize the memory, you have to initialize the network, you have to construct the packet that you want to make. You need to calculate the packet checksum so they're appropriate for the values that you have. And then you actually inject the packet onto the wire. So it's really cool, you literally control everything about the packet. If you want to experiment and figure out what do different routers or switches do when I change the terms, not the terms of service, the service flags and IP headers, what happens, these are the kind of tools you use to do that. Okay, the other tool that is really cool is Scapi. Scapi, I don't know how to pronounce it. It is a Python based library, it is awesome. You can, very quickly, it has a really cool interactive prompt mode where you can kind of craft packets and look at things interactively like I Python, if you're familiar with that. You can also write whole scripts that run and use this. It has libraries and support for both sniffing and spoofing, so you can read in packets, arbitrarily change packets. This is one of the coolest things, I got to doing a project in LiveNet and then doing one in Scapi, it's like night and day. It's really cool. It's slower than using LivePcap and LiveNet, but it's a lot easier to use. So for example, to send like a spoofed ICMP packet, this is all you need to do, you send an IP packet with a source of this, a destination of this, and you wrap that in an ICMP message and you're done. And it does everything, it sends it out. It's very cool. So sniffing and spoofing, right? So if we pretend to be from someone else and we can sniff, we can actually try to hijack connections, right? And we've kind of alluded to this a little while, and so now we're gonna actually look at how you perform hijacking attacks. So that idea is you sniff the network waiting for some kind of request depending on what you're trying to hijack, and then you race the host to send a legitimate reply. So for instance, like you had the ART hijacking, right? You can sniff well. If you can just poison them, it's really easy. You just poison them. If you can't, you would sniff the network, wait for ART requests, and quickly send a reply back before the other machine had a chance to respond. So there's ART style, which I just described. There's UDP style and TCP style variations of this attack. So we'll see these later, but I just wanted to define what hijacking, when I say hijacking, you're trying to hijack a connection for hijacker requests, this is what we're talking about. So now we get into routing. So we've only looked at, even though we've looked at IP for a long time, and it's actually kind of really interesting, right? Even just focusing on such a small layer, like the link layer, right? We already found vulnerabilities, and were able to attack the network layer, just looking at the link layer, like ARB traffic, right? And then looking out one level up, and saying, okay, now what if we include IP, but restrict everybody to be on the same network, right? We saw that there's still attacks that you can do, and sniffing that you can do, and ARB poisoning, and hijacking that you can do there, right? So now we say, okay, what happens if we go up one more? So we know that the goal of IP is to get a packet from one IP address to another when they can be in different networks, right? And what we looked at so far is just what happens if they're in the same network. So now we're gonna look at how does we call, so the opposite of like direct delivery when you're on the same physical local area network, when they have to go to opposite networks, or not opposite, there's no such thing as opposite network. When they have to go to somebody else's network, how do those routing steps actually occur? So we're gonna look at how that happens, and then look at what attacks this enables, and this gets us to like, very cool stuff. So, how does the host know if it's trying to send a packet to something that, and it needs to use indirect routing? I love the address, I'll have to check the subnet. Yes, it checks the IP address it's trying to talk to, and it looks at a local subnet, and says, is this in my local subnet? If it is not, where does it go? Yeah, so it needs another piece of information, so this isn't something we didn't really touch on it, so when you set up the networking, you need to know your IP address, you need to know what subnetwork you're on, and you need to know who's my gateway, who do I talk to if I don't need a net packet to this network, right? And there's, you can actually set up all kinds of complicated routing, but in general, that's just kind of the way we'll think about it, so there's, and this is where routers come in now. So, a switch doesn't do anything, right? Only lets machines talk to each other on their local network, right, in their subnet. When you have a router, that's now when, if the machine's not on your local subnet, you can give the packet to the router, and the router will try to get it to where it's trying to go. So, if we can't get the packet from, if it's not on our local network, we know we have to use indirect delivery. So, the gate, so the idea is, the host only needs to know the next hop, one hop, right? So, if you have a packet, it's not on the local network, send it to the gateway. So, the gateway has its own routing table that says, hey, if it's going to these type of address, put it here, if it's going to these other type of address, put it here. So, it has another hop, and then finally, and that hop will tell where to go, and then finally, it'll keep going until either the TTL is decreased to zero, in which case the packet's dropped, where it finally gets to a destination, and the destination machine receives it. So, yeah, so it keeps going until finally, somebody's on the same local network as that target machine that you're trying to send it to, and they get the packet. And then we use direct delivery. So, this is the critical thing, right? So, we talked about, this is why we focused on direct delivery first, because every hop is using direct delivery, right? So, when I want to send a packet to my gateway, the destination IP address will be the machine I'm trying to talk to, but the destination MAC address will be the gateway's MAC address, because I need to send this packet to the gateway. And the gateway will see that, and then figure out where it goes next, and it will create its own ethernet or link layer frame to pass the packet on, and so on until it finally gets to its destination. So, we have two machines, completely different networks. So, we have 111, 1020, 121, and 128, 111, 411, 10. So, a key thing is the IP, most of the IP headers stay the same forever we hop. Right, what changes? The TTL, yeah, the main one that changes, and the checks that will change to update that, right? So, with the source and destination IP remain the same at every step along the way, that's an important thing to remember. The TTL field is decreased, and the link layer adjusts actually change at every step. So, the source, at the first hop from here to this gateway, right? The source MAC address will be this MAC address, the destination MAC address will be the gateway's MAC address. And then from there, the source MAC address will be the next hops. The source MAC address will be the gateway's MAC address, the destination MAC address will be the next hops, and so on and so forth, right? So, you can see that the, you think about the layers of a packet, kind of like, if you've ever done this to somebody, like wrapped up present multiple times, so they open up one layer and there's another layer below. Right, so you think about a packet that's kind of like a package that every time one layer's being taken off, and then the next hop rearranges a new layer, puts it on, they take off one layer, rearrange it, and keep pushing it up. And so, and the other core idea here is that, well, the process where we're trying to go to is based on the destination IP address. So, each node only needs to know how to get traffic, either to its local addresses or to somebody else to pass it along. How does the destination router know which local machine it can actually access? Ah, perfect, okay. So, when the packet gets here, right, in this local router, or this local gateway, it gets it, it looks at the IP address, and then what does it look at? A subnet, because it has a configuration that says this is your subnet, and it will say, oh, this is for a machine on my local subnet, I need to do direct delivery. So then, if it doesn't know that person's MAC address, it does an ARC query to say who has this IP address, gets a reply with the MAC address, and then packages that packet in the MAC address and sends it off forward. So, it's exactly the reverse. But public IP for one opening is constant for the whole subnet. That's a different issue. We'll talk, I think we'll talk about madding at some point, but, we can assume that these are both public IPs. We're trying to get this from us to Google and we're both on public IP addresses. Okay, so we can see, not that we already kind of did it, but yeah, so we can see, we talked about it, so this packet goes across, and at each step, the yellow layer is being destroyed and recreated, depending on the link layer for the walls. Yes? So, I'm going to start with you, so this is like my computer, this is like a friend's computer, and like, if you're both on the public internet, let's say you both have publicly accessible IP addresses. And so, it's going to connect to like ISP and it's going to go through a bunch of servers, and how is it going to, how do those servers know to get to the destination address? I don't want to, I'm not going to go. Yes, so that's this big, I should replace this with just like a big, like cloud, like amorphous block. The basic idea is, at a high level, they've all decided where to route traffic, and each ISP, so each ISPs have agreements with other ISPs, how they need to route traffic and how much they want to charge. So, some routing decisions are based on cost, right? If I see you have a packet for Netflix, and I have agreements with two different providers, they both can get to Netflix, but one is cheaper for me, I'm going to send it that way, even if I know it's going to be slower for you, because what do you care? You're still going to get your video. So, that's part of it. The other aspect is there's a protocol called BGP, that each autonomous network is running so that they can announce to each other what IP addresses belong to them. So, that allows them to say, hey, I'm in charge of this IP address break, and that can be changed, and yeah, it's actually the source, there's been a lot of denial of service attacks from allegedly incorrect BGP routes. So, for instance, can't remember which country it is, which is a good question, it was a guess, maybe a guess, but they want to take off Twitter, they want to censor Twitter from their network. So, instead of basically sink hauling and capturing, and saying like, oh, if you want to go to Twitter, you go to this non-existent page, what they did was they advertised the BGP route that says, hey, we're the authority network for Twitter's IP address, and that meant everybody in the world, whenever they want to talk Twitter, and all ISPs would send their traffic to that one person, and which was not Twitter. And so, essentially, they hijacked their IP address that way, because yeah, that's the problem, is each network needs to know where to pass their traffic to. So, those are actually fairly rare, which is surprising, and a person in my, when I was doing my PhD at Santa Barbara, I tried to do a study to look at, can you get yourself into the BGP network, and try to inject fake routes? Turns out, because there's actually not a ton of BGP peers, they're all admins who kind of know who's who, they were pretty secure and couldn't get it, and it's good things, so. And they see what, and I know why we don't, I go to my IP address packet. No, yes, so if you receive a packet, you have no idea how it got there. How do you reply? I view the source IP address. Yeah, you use the source IP address, and you just send that packet back, hope that it goes the right way and gets to that person. Right, so that's you, so that was part of those IP options, we looked at, there were debugging options that each hop would put a stamp so you could see what route it traveled to the network, but they stopped. I don't think you can do that anymore. Do you have more questions? Does the source machine know how many steps the packet is going to take? Beforehand, well, no, and kind of yes. Can't look at that counter. Yeah, but look at it, if you could know the source if this was like you somehow, right? You can send the packet and see what the TTL at the end, and then you can know about how many hops it went through. That was my next question, if the source machine does not know how many hops the packet's going to take, how does it reach that the TTL is going to be? Ah, how many bits was the TTL value? Eight, eight, how many, what's the max value you put in there? 255, so that's what people do. Essentially, it means you're not, you're more or less not more than 255 hops from whoever sent it. And of course, no. When you get it to netting, things change, and a lot of weirdness happens in the networks, you gotta think, some of the big back bone things, they can take your packet and wrap it in another protocol and then send it along their own proprietary protocol in their networks, and then when it gets to the end and some of the others, they pop it out and pop it out of the packet for you, so you would never know maybe it went through five other non-EHOPs. Yeah, it's terrifying that it all works. This is one of the things, the more I've learned about computers and especially security, the more shocked I am that everything still works. Think about how much money is pumping through the system and it's just all, this is how it all works, it's not magic, it's just packets going through and it's best effort. Is there any organization that sort of monitors what's happening in the net, looks for inefficient routing or efficient routing? I don't know, that's a good question. Anybody a networking person who knows that? Any networking PhD students? That I don't know. I'm sure, no, the short answer is I don't know. I mean some of the things that they're trying to do to relieve congestion, right, because there's so much, if you look at the data that's being pushed through the internet with the rise of streaming video, it just has really increased. So basically the way they get around that is Netflix goes and says, hey, you wanna reduce the load you're paying in your network? Great, let us put a box in your ISP and we'll cash popular movies and serve them from our box. So it's great for your customers because they get videos quicker and it's better for you because that traffic doesn't have to go all the way to Netflix's servers crossing multiple ISPs who all pay for that traffic to go back. So that's kind of, downside of that is the big play, you have to pay a lot of money to play those kind of games. So yeah, you know, we're, yes, yeah, I don't know of any organization that does that, that would be interesting. Okay, yeah, so the key in this diagram basically is the from and to MAC addresses change, right, at every single hop. So this brings up things like if you ever hear somebody saying, oh, you know, authentication is easy or whatever, you just check the MAC address of whoever sent you the packet. Right, you can know that they don't actually understand how networking works because when you receive a packet, what MAC address do you see as the source? The gateway, the previous hop, exactly. You don't see, you never see the other machines MAC address unless they tell you explicitly in some other protocol. So, yeah, so there used to be multiple types of routing. I kind of alluded to this a little bit. The primary method now is hop-by-hop routing where you just say, hey, go here, and you know, I want to talk to the list node on the network as IP address and then your packet will hop through the network. It used to be that you could actually do source routing so you could tell the network exactly how you want your packet routed. Like we talked about that has problems with security. You could maybe overload certain nodes on the network and really the ISP can care less what you think your package should be routed as. They're gonna do what's best for them and their customers. Another interesting fact that I like about source routing is that you know how emails, what email addresses used to look like. So the host name of an email address. So you have the username, act, and a host name. But your host name would be host one, exclamation point, host two, exclamation point, host three, exclamation point, host four. And that would actually specify how to get your email from your machine to their machine. So you would have to specify in the email address all the, in this case it would be IP hops, but I believe it's SMTP hops that it would need to go to correctly get to their system. They got rid of that pretty quick, well I don't know how quickly, but yes, thankfully that's gone now. We don't have to think about that. I like the parallel there between source routing and email essentially source routing. Yeah. In the previous slide you mentioned the, they won't know about the source packages. Yes. Then how do you trace somebody? How do you trace somebody? Yeah, if they, you're not recording, I don't know. So, how do you trace somebody? So who knows? So let's think about, in this case, the host on the left. Who knows their MAC address? So in the case of when you plug your machine directly into the public network, who's your gateway? Yes, your ISP, right, is your gateway. And so they see you doing anything, and they also are the ones that give you an IP address. Right, so they know your IP address, they know your MAC address. They also know what port you're connected on. I mean they know physically where you are. They know your billing information, all your customer information. So that's why when they detect, if they see this IP address causing trouble or doing something illegal, they can know who it is. Now, they can know, but this is a good foreshadowing. So if we look here, if 128-1-1-4-1-10 gets, let's say, an attack traffic from 11-10-21-21, does that mean that host sent it? Why not, it might be spooned, right? We saw that nobody's checking the IP address, right? They just look and see, oh, this is trying to go to somewhere. Nobody's checking who it's coming from, right? So just because you receive, now it's the important thing for them, just because you receive an IP packet from a source machine doesn't necessarily mean that that person sent it. So that's an important thing to think about. Yes. Is there a reason like your ISP doesn't do this checking of, because they could do it on the gateways, is it just too expensive or? Ah, it's too slow. Yeah, they tragedy the commons thing, unfortunately. So from my understanding, some ISPs do this, so it's called egress filtering, where you filter out the traffic that's going out, maybe some of the IP addresses that are coming from inside your network, right? So one thing is it depends on how big your subnet is. If you have a large subnet, you could just pretend to be somebody else's IP address on the subnet. If you move somebody from a completely different network, then it's on the gateway or the ISP to filter that traffic out. And some networks do, and unfortunately, enough other networks don't, that it's still a problem on the internet today. If you run a TCP dump at the destination, then how much information you can extract from there, like from where, what was the force or the last of you? So yeah, you'll know, you get this packet right here. So you know, from at the link layer, you'll know who sent you the packet, right? On your local network. You'll know that it was addressed to you. You'll know that the packet, the IP address was directed to you, right? So the two addresses correct. But everything else in that packet could have been changed and altered by an attacker, right? So you can't, you don't actually know that that other IP address sent you a packet, right? You know you've got a packet and the packet says that it's from that person. And so we'll look at other ways that protocols deal with this issue. But fundamentally, you know very little. You know that you've got some information. And this is what makes denial of service attacks so difficult to prevent. Because you're just getting a bunch of packets and they're probably not even from who they say they're from. And it's overloading your network, right? You're doing so much, you're getting overloaded, so. Cool, okay. We'll talk about the types of routing, hop, source. So it used to be, we talked about this, so using source routing, you could maybe force people, you could maybe force sniffing through there. So yeah, so one thing, right? If I can specify how to reply to me, right? Like, oh, what do you want to talk back to me? Talk through these hosts, right? And then I can maybe spoof other IP addresses because you'll reply directly to me, right? So this is other reasons about why this is completely gone already. It's not, apparently, not used by any routers, although that would be interesting to investigate which ones do use that and why. That would be pretty cool. So each hop in the network is maintaining this table. So in, well, I think in new versions of the Linux kernel the route command is, I think, maybe still works, but it's, some soon, but I think it is. You can look at, just Google how to look at routes on your operating system. It'll show you, it's routing tables, so it'll say the destination of the gateway is some masked drives and one interface. So in the simplified model we looked at, right? You just had one interface and you had one gateway, right? But you may actually have multiple interfaces. You may be connected to multiple different subnets. You may have different gateways that you want traffic to go out of. And so this allows you complete flexibility in how you control your networking environment. So for instance, this is specifying, so the, this is specifying 192.168.1.24. So this gen mask defines the gateway. So it's a bitwise hand. So you look at two by five, all two by fives is one. So you mean that's what you use as the gateway. So here this is a gate, or sorry, not a gateway, a subnet. So you're defining this as one host. So you're saying if you want to talk to this host, they're on ethernet interface zero. So they're on your local network, talk about that. So you can specify exactly, so you can make all kind of complicated routes. Like if you want to talk to this host, use this interface. If you want to talk to this other host, even though they couldn't be on the same network, use this other interface. Then you can say if you want to talk to anybody in the 192.168.1.0, so here the subnet would be the gen mask bitwise and with the destination ID here. So this is a subnet of 192.168.1. If you want to talk to anybody there, they're on interface zero. So this is a local network. If you want to talk to 127.0.0 with a subnet mask of two by five, so anything below 1.2.7, talk to the local interface. So what is this? Local host, the loopback interface. So this is actually something that a lot of people don't realize is you think of it as 127001 is like the standard HELL network, but actually anything that's in the subnet of 127 is also local host. It's actually some ways you can get around filters that filter out local host, like things that will make URL requests to and deny local host or 127.0.0.1. Is it 011? 0101, right? Yeah. You can get around that by using different values for those and it will still go to the local interface. And if you look at the spec for what local host is, it specifies exactly this. So this is by the RFC spec. Then finally, if it doesn't match any of these things, right? All zeros, zero gen mask, then this means that our default gateway send it to 192.168.1.1 on interface zero. So the flags mean that it's up. It's a good route. G means that it's a gateway. H is a host. So this is how to talk to the specific host. And then there's other messages in here. So it's always interesting, especially if you start playing with virtual machines, when you start installing virtual machines, which create virtual interfaces, your routing table gets a little wonky and weird. And you can look at it to kind of see how packets are actually moving through your network. And so the way this routing works is it goes from most specific to least specific. All right, so what's the most specific thing I have on this table? The first one, the host, right? If you're trying to talk to, that is the most specific. If you're trying to talk to a specific host, use this rule, right? That less than that is if you're trying to talk to a host on this network. And then if you're trying to talk to anybody who's not 127.001, then talk to 192.168.1.1, use this rule. So that's how the rules are processed and that's how you should think about that if you look at these tables. So yeah, you see, do any hosts match? Do any network addresses match? Then you search for a default entry and you do it just as we talked about. If you can't, if there's no route, has anybody ever seen this? If you're trying to access the internet and you're trying to run a ping and you get a host unreachable or a network unreachable, this would be either two things. A, either your kernel has no route to the host. Maybe you have your DACP hasn't, you don't even have an IP address that has no way to talk to the host or maybe your gateway. So if you try to, if you do this at home, you can run ping, like pinggoogle.com, see that it's hanging correctly and then on your router, unplug the WAN port or just unplug your cable box, your cable motor and you'll see that you'll start getting ICMP messages back that says, I think it's host unreachable which would be from your gateway machine saying, sorry, I can't talk to anybody. I can't get this packet anywhere. Which is nice that you actually get a reply rather than just not knowing and hanging from. So you can do routing tables, you can set routes statically if you need to configure stuff, especially or use routing protocols like DHCP which allows the gateway to dynamically tell you how to issue routes and what your route should be, what your gateway should be. Okay, so the attack we wanna look at now is taking our IP spoofing attack and doing it on the network. So we want to spoof an IP packet from a machine that is not our own and send it to a destination machine. We just kinda talk about this at a high level and my animations are a little weird, sorry about that. Happens sometimes, there's a lot of things that click on them. So, why is this called blind? What do you think once you send our packet? Right, when we send our packet out, we spoof it from somebody else. When that machine gets the packet and they reply, what happens? It goes to that other machine. Yeah, it goes to that other machine, right? We never see the reply to our packet and fundamentally we can't. And this is another important concept and that's why I've been carving on it again because this forms the basis of security of TCP handshakes, as we'll see. So, we wanna send an IP diagram with another host and the idea is it's really easy. We just change the source IP address to be from that target IP address and we send out the packet. But the important thing to remember is that we do not get the reply. We will never see that reply. So, there's a trust relationship here between 135 and .10, right? So, there's a trust relationship here and we wanna spoof essentially a packet from 128.111.41.135. So, we send that out, it gets here and now the important thing is, so now the packet gets there, right? Everything goes fine but then when it replies, we never see the reply. How to check the source address or just check the destination? Just the destination, a lot of times. It would be, let's see, maybe you could test this but you'd have to spoof an IP address that you control. You don't wanna spoof somebody else's IP address. That would be interesting to study and actually I talked with some other professors about because this is a problem, right? We can fix a lot of IP spoofing attacks if we stopped, if every network would not allow traffic outgoing that was not from its IP range. And one of the ideas was name them and shame them. So, measure them and make a list so that people can see which ISPs were the worst about not doing this. And the reverse, which ones are good about doing this. So yeah, it would be an interesting research project to do to try to understand and measure this. So, blind IP spoofing, look at other kinds of spoofing. One thing that we need to think about, right, is on this path, every hop in this network, this packet is essentially sent as is. So I won't say it in the clear or not, but it is sent as is, right? So this yellow packet that we sent originally in the network, every gateway and router along the way sees that packet, right? So this way, it's very similar to a postcard, right? A mailman can read your postcard just like every router along here can read your packet. This is why we need, and we add encryption on top of all these layers. But fundamentally, at the IP layer, there's no security in here for any of these things. So any node can read your packets, which then allows us to think what happens if we take over one of these routers. Pretty cool, right? So this is kind of what forms the basis that we think about as a man-in-the-middle attack. So the idea is post-A and B are trying to talk, but actually all their packets are flowing through speed. And they could be doing that because like we saw in a local network, we've done ARP poisoning and we convinced all the packets to go through us. And so if we can control a gateway, we can sniff all the traffic, right? As we saw, which is awesome. We can intercept or block traffic that we don't like if we're an authoritarian country that we want to enforce our policies. We can look at all the traffic coming in and out of our country and block those that we do not like hypothetically. We can modify traffic, right? So we can change the contents of packets as they're going across. We can perform a full man-in-the-middle attack, which is that we basically completely, we just impersonate the other hosts, right? So we could not even send any traffic to that other host and just pretend to me, let's say Google.com or your name. So this is fundamental to the architecture of the internet. So if you think about why we have such bad security problems, why we have to have E2DPS, why we have to have all these other protocols, it's because fundamentally at the network later, we can't insure anything. Man-in-the-middle attacks. Now we're gonna look at some really cool, we're gonna circle back to a problem that we looked at. So anyone wanna remember what's the maximum size of an IP packet that we have sent? Roughly. Like 65,000 bytes rounded to the nearest power two, right? So, back to the 65,000 bytes, what was the max limit on an Ethernet frame? 1500, right? Is there anything about, anything that we talked about in this routing diagram that says that Ethernet has to be used at every one of these link layers? No, right? Think of using something else that's smaller than Ethernet, right? Or maybe we're on a network that allows larger than Ethernet frames. So what happens if we try to send a packet of size 65,000? What would suck if it just dropped, right? That would suck because IP says we should be able to send packets of size 65,000. Now you're telling me it depends on the network or what if I send a packet of size 15,000 here and somebody else along the way just dropped it because they only support 900 bytes of the link layer frame. That would suck. So this is where we looked at very briefly these mechanisms and items in the header of IP packets for fragmentation. So the idea is IP actually has a way to if the packet can't be sent because of a link layer, a message goes back and it tries to get our, no, does it go back? I'll think about that in a second. Essentially what it'll do it will fragment and break up that packet into sizes that can fit across that network. But now you need to know what do you do when you receive all these little fragments of packets? You have to reassemble them back into the original 65,000 bytes. And so this is where fragmentation comes in. It's important to study because it's one of those things that your packets don't, oh that's true or not. Fairly certain your packets don't get fragmented anymore. They've done a lot of network studies to look at the network and the operating systems have kind of put very solid IP frames in there for sizes. So your packets very rarely now get fragmented. But important thing that happens is this is where security vulnerabilities lie. So in complicated, rarely used corners cases of specs this is where security vulnerabilities occur. This happens again and again. So IP fragmentation is a prime candidate and has caused several high profile security vulnerabilities. So we will look at this on Monday looks like.