 Okay, so going forward, I will, later tonight, assign you a homework assignment. This will be, I think, easier, deliberately easier than the other ones, so there won't be as much work involved, but there also will be less time, so that way. Basically, I want to touch on the networking stuff, so I'm going to have you do a cool networking project, learning about how to play with packets and do that kind of stuff. And then, I'm also going to set you up because I want the next assignment is going to be related to application security, so we're going to talk about how to try to actually exploit applications. So the second part of the assignment will actually get you just familiar with playing around with the Linux environment and trying to find flags and this kind of stuff. I've done this in my 545 class, so it's really helpful to get students up to speed for what they need for the next assignment, and that should be pretty cool. All right, so back to networking. So we talked about denial of service attacks on Tuesday, and we've been talking about the fact that if an adversary can ever cause another system to consume or resources, either in terms of memory, bandwidth, CPU, storage, whatever, if I can trigger that functionality, then if I can send one byte and make you store a make-up byte, that's a nice letter that I can use to send a thousand bytes and make you store whatever that conversion is because I can't do that in my head a lot. So since learning attacks are a very common type of denial of service attack, which the idea as we talked about is the attacker sends a SIN packet, the victim then replies with what? SIN act, replies with a SIN act packet, and then the attacker does nothing, so stays completely silent, right, or sends another SIN packet. And if we as an attacker don't care about getting the reply back, what does that mean we can do with this SIN packet? The SIN packet, we have to send it to the searcher. So as the attacker you don't care about the response, do you need to drop it? Was that a question you were asking? Kind of, yes, so as the, so we don't care about the response, so we don't care about the SIN act coming back to us, right, we're just going to send a SIN packet. Just keep sending them SIN. So we can keep sending them with no limit except for the heart bandwidth going out, what else? We can analyze their sequence numbers, we'll try it. We just want to take them down, we actually don't care about that at all. We can change the source, but they don't send them back to us. We can actually change spoof the source IP so that they look like they're coming from all over the world, and actually they wouldn't know that they're necessarily coming from one host, right, because we don't care about getting that packet back, we can spoof the source address. And so, A, this helps us not DOS ourselves, because if we're sending out a bunch of SIN packets and then we've got a bunch of SIN X, that can be a problem. But we can actually spoof the source IP because we deliberately do not care about completing the SIN-SINAC-AC cycle, right? All we're trying to do is get the server to store data because we send a SIN packet. And so, the idea is because of this, the operating system will limit the number of what they call half-open connections. So half-open connection is you send a SIN, the server sends out the SINAC, and it's waiting for that final AC. So there's a fixed number, which means that the server will drop any other SIN packets and not process them. Therefore, nobody else can actually connect to the server. So how do we fix this, or can it be fixed? Is it a fundamental limitation of TCP? I mean, the collection just started dropping out. The older ones, I mean, I guess it's still, it doesn't really solve anything. But it could fill up your queue, right? It could fill up your queue. Your server is still being denied, but at least, like, it's your implementation. You understand why it didn't. OK, that would be my first guess. All right. Instead of focusing on actually fixing the problem from a security perspective, it's going to be the first guess. Yeah? So time limit, or if you don't get an acknowledgment back on your SINAC, it will automatically drop. So you wouldn't be, hopefully, you wouldn't fill up your entire queue of SINAC. Which actually maybe is a similar idea. Maybe you could dynamically adjust, based on how many open, half-open ports you have, adjust down your timeout into where you're going to drop those, right? The problem is, can the attackers send enough packets to continually fill that, no matter how low you turn it? Or can the attacker get you to turn that so low that nobody can ever respond back to your SINAC with a valid act, because your threshold is longer than the time it takes for a packet to travel from them to the server? So is it interesting? Of course, you would have to know that those are the things you're actually doing in your system to try to prevent those kinds of attacks. Correct. Or if the defense doesn't work, if it, well. Yeah, I mean, yeah, they would have to know. And you could have kind of assumed that they know. Yeah? Depending upon the system and the application nature, you could let the passports feature and maintain a dictionary of posts that have used your system recently. And so if out of the flu, you start getting a billion requests all over the planet that are not people that have used your system before, you can de-prioritize those connections. Interesting. So we could essentially try to learn the behavior of our application and then more or less whitelist, in some sense, those hosts that we've talked to before. And so if they want to make a same connection to us, that would maybe go in a different queue than another one of hosts that we don't know. What's the fundamental, can we actually solve the fundamental problem? What is the fundamental problem? So we know how to solve it. What's the problem that we have to store all the memory and everything that's incoming? So one idea is, couldn't we just send like another packet back directly who says to just try again later? Right. Restore the information. Yeah, so going back, so the core problem is exactly that. But we said that one single packet causes us to store data but doesn't cause any data to have to be stored on the client. Right? And so kind of going off of that idea is basically, well what if we don't store that data? What if we essentially try to put it into our sequence number that we sent back? So that we actually don't have to store any data and if we see an act packet back with an acknowledgement number, we can verify that it's actually correct. So we can filter, we can try to increase the length, reduce timeouts. These are all actually things that we're doing. Drop it for a limit and use SIN cookies. So SIN cookies are a super interesting thing. The idea is, essentially the idea is what from a service perspective, the reason why it's storing data is so that when it gets an act packet back, it can verify that yes, this packet is in response to an already established TCP connection. So the idea is, hey, let's use an algorithm to try to inject that data into our sequence number that we sent. And that way, when they send us an act back, we can actually check that it's a valid sequence number. So it's a very cool process. It uses hashes based on the source, destination, IP address, and pair. So it essentially, you can think of starts the, starts the initial sequence number of our connection based on the tuple, right? The four tuple of source IP, destination IP, source port, destination port, plus a counter that's changing. And then when we get back and act, we'll see this number plus one. So we can actually redo this calculation, right? We can check, we know the source and destination IPs. We know the destination source ports. So we can check, basically, I think the idea is you essentially brute force here and check, wow, this is weird, okay. Too many wires. So anyways, the key idea here, that I think the details here aren't exactly important. You can dive into this if you want to. But the idea is, this actually is a setting you can enable in Linux to enable SIN cookies. So that way, your server never stores any data in response to a SIN packet. It sends back a SIN act and then waits for an act and then it can verify that that act was in response to a SIN act that it just sent after a certain time. There are also different types of these things. So the idea is, if the server allocates memory, so this was specific in response to a SIN, but maybe we can do a SIN SIN act and maybe then the server will store memory that we don't have to store. So that could be another happening of attack. How do web servers handle massive amounts of requests? And concurrent requests? Since it's a message queue. They can do that, but how, well, I guess I'll go more specific, how, what are the ways that Apache deals with that? The Apache itself can't spin up a new instance of itself. So in normal programming, how do you handle concurrent requests? Spin up another thread or another process, right? You either have to spin up another thread or another process, right? You have to use multi, either multi-threaded or multi-process approach, right? So those each have pros or cons and web servers and most client-based servers work the same way because when a connection comes in, if you block and can't accept any more connections until that request is processed, you're a terrible web server, right? You need to be able to handle hundreds of, even thousands of requests per second to hundreds of thousands of requests per second and you're fundamentally not gonna get there unless you do that. Or unless you take a completely different approach and just have a load balancer with tons of back-end servers that you can just spin up more of, but that load balancer itself has to do this anyways, right? So there's still this processing in here. And so how many threads can we, all right, how many processes, processes I have set up? Can you have a Linux server? Is it infinite? I actually don't know, so cool. Look that up, I'm very fine. Two to 16, I think that's right. It's like 65,000 or something. Is that two to 16? 65,000, 35,000, 36. I should have just gone with it, that was much cooler, right? So if every time I make a request to your web server, it forks, creates a new process, all I need to make is 65,000 requests and keep them open and now literally nobody can make any more requests to your web server because Apache can't fork and the whole thing's gonna fail. Or with threads, there are limits to the number of threads you can have and so some of our things occur here. So, and it really does depend on the server application. Here you're moving less up from, previously we were thinking about attacking maybe the operating system's TCP IP implementation, now we're moving up to attacking the application itself that's living there. So there's all kinds of fun attacks that you can play with here. Questions on this? This is kind of a generalized approach and idea of how to tackle and identify the denial of service vulnerabilities in networks and other types of, the idea is applied anyway. All right, so what is the, well, I'm trying to think what we're trying to say. So you, so what are some mechanisms that we can do, we can use to protect our networks? Because we've seen that there's a lot of games that you can play, a lot of bad stuff that can happen. So what do we do, we're just not safe, we just have to live with this fact. Worried about plugging a computer, branding a computer in on their home network and used to apply. So yeah, so okay, so the, there used to be, I don't know if this is true anymore, and I don't actually know if this was true in the past, but it used to be said that if you took a unpatched Windows XP machine and plugged it directly to the internet where it had a publicly routable IP address, in 10 minutes that machine would be infected with malware because there are worms running that are constantly scanning the IP address space and looking for vulnerable instances and automatically take them over and infect them. But why doesn't that happen anymore? Is it because now we're using Windows 10 and everything's awesome? Yeah, so, I mean we've done this before, but can somebody run ifconfig or, I think that works well on that, on Linux and Windows. What's your IP address on the network here? 10.summon? Yeah. 10.zero.zero.whatever. So, I think we talked about it briefly, but the 10 network space is a private network space, right? So why can you access the internet? How can Google talk to you? Is your network gateway? So is the router access your network gateway and what way? So what does that mean? It has a public IP address, which it then uses, what is it? Address, A, T, N address, translation, something or other, to translate your private address into its public address and then it sends traffic up to the internet with its public address and then when stuff comes back to it, it forwards it to you. Cool. So the two things just separate there. So yeah, so we had this idea of a router, like a gateway or like a router, right? So the important thing to remember is your router does act as a gateway router. It forwards packets where they need to go. But that's not all that it did. That's all that it did. You would just be on their network, right? So NAT, basically, I think it's, was it network? I don't know, network address or translation? Yeah. So we're gonna, yeah, let's try this one, right? All right, so we have our switch here. We have you with the dot-top here connected to the switch. The switch is connected to the world. So you have a, you have a 10.0.0.2 address. So your router is 10.0.0.1. And your public IP, anybody, can somebody go to itchickin.com or whatsmyip.com and tell me what your IP is that you're using? 4-7-0-1-4-4-dot-7. Okay. This is different. So that's somehow our external address. This is different than mine. Interesting. That's because ASU's network is great in a good way. So Google is here, they have their own server that's gonna handle your requests. A lot of people are lights. And then they have some IP address. Well, whatever, it doesn't matter, we'll call it G. So our machine wants to send a packet to Google. They're gonna make a DNS request to figure out what's google.com's IP address. It's gonna come back as the IP. And then your computer's gonna make a packet. What kind of a packet if it wants to talk to the web server on HTTP port 80? An IP packet with a source of what? 10.0.0.2 and the destination of Google. And what will be inside that IP packet? Yeah, TCP packet, right? Then we know this will be a SIN packet because I'm trying to initiate a connection. What's the destination port for 80 and somebody gave me a number for source port. Something that's not crazy. 2222, there you go. It needs to be high-ish, but not, thanks for that. You guys are bad, right? I don't know if we're generating it, by the way. All right, so we send this packet out to the router. Now, if, like we talked about with indirect routing, the router then just takes this and says, great, okay, this is going to Google, I know how to send that out, it goes here, it gets to Google and Google replies back with it, right? It's going to try to reply to some private IP address range which Google itself may be using, right? The whole point of private IP addresses is they're not publicly routable, but you actually probably could send this packet out on the network and I don't know what would happen, but it would be interesting. So, the router says, hey, I know my internal network is a private IP address range and I need to talk to the outside world and the outside world knows me at this IP address. So, your router is actually going to change this packet around and so it's going to put IP source, it's going to change the IP source to this 209, and the destination, is it going to change the destination? Nope, they're going to Google. What about the TZP layer? Does it keep the TZP layer the same? So, let's take it one by one. Would it change the destination port? No, because then you're talking to something different. So, what about the source port? Right, so let's think about it in two different ways. So, like, two, two, two, two, so let's say it keeps it the same, right? So, this packet goes out, Google replies back with a SIN act with the destination IP 209, 147, 111, or whatever this is. I should just call it A for ASU. The packet comes back, it has a source port of 80 and a destination port of 2222, then the router gets that and what does the router then do with that response? The packet need to go back to us to 1002, right? How does the router know how to put that, how to change that header to send the packet back to 1002? Yes, so this is so it can keep a mapping and say, hey, I just sent a SIN packet to, actually you could probably do more complicated and use the IP address, but I think it just uses the source port because there's enough. It says, hey, I just sent a packet out from 2222. If I get the response back, I'm gonna forward that to 1002 and not 1003 or any of the other machines on our network, right? But of course, what if there's 20 machines back here, they're all using their own source ports and they all send out packets from port 2222, right? Then the router will get confused and not know what to do, so what it does is it will actually not, usually not use the source port here, create its own random source port, let's say 4444, and then the router will store in its NAT table, hey, 4444 maps to 1002. And then when another packet wants to get sent out, then it just creates a new one as you enter into the table. So this is how it's translating and basically, pretending for the world to be 1002, sorry, pretending the world to be ASU 209147144.7, but it's translating all the packets you're sending and all the replies, so everything's great. What if you want to run your own web server behind this router? So what's the difference here? IP address, can the outside world use 1002? No. No, so they have to use the public IP address. So it'd be trying to contact the router, the router doesn't know what to do. Exactly, it'd be trying to contact a web server on the router, hopefully it would reject that and not display its admin page, although I thought it would be bad. And the whole problem is there is no mapping in this table that maps and says, where should I give this traffic to, right? Because you think, okay, it's easy when you're making a connection outgoing because you expect a response back and I can tell what that response is. But if somebody's making a connection, how do I know it goes to 1002 and not 1004, or 5, 6, or any of these other machines? So this is where if you've run and messed with, running, trying to run a SSH server or a web server from your home IP, you have to set up in your router and specifically add a rule that says, hey, actually anything on port 80 is redirected to 10.002. And that's what that rule does, basically says, hey, forward all traffic to port 80 directly to 10.002. And then people can contact you when everything works, unless your IP, unless you're... Many of you have cease and desist letter from Cox or something. Depends on what server you're running, so we won't address that. But part of this is your IP address really doesn't remain constant. It can be a dynamic IP that's changing, so that might also be a pain. But anyways, so this actually, so it seems like this is just kind of like a standard network thing that we all take for granted and don't really think about. Why does this actually offer security benefits here? Until the router's set up to direct to you, it wouldn't know to direct to you, right? Nobody can contact you, right? So even if you're running on your system an insanely vulnerable Windows XP machine, at least we know that other malware, viruses, worms, whatever, they can't send any sim packets and initiate any connections to your computer. Now, as you're browsing around on the web, you are bringing content in, so it's likely that at some point, malicious JavaScript will find its way on there and exploit something and flash it on your computer. But until that happens, nobody can connect to you, so it actually is a nice safeguard. It's important to understand how this works for understanding, so actually, that is a decent kind of like first layer. Okay, I'd say it's a product, it's a decent, it's a consumer or client level network defense mechanism. Because you're basically saying, hey, out of my home, I don't want people to contact me, I'll only contact other places. This causes problems if anybody's ever tried to, usually like Xboxes or video game systems, sometimes if you don't connect to a central server to do online gaming and one of the players hosts a game, you have to have people connect to you. Or if, I think, you have to get torn up, right? You're having people connect to you or Skype, part of the whole point of Skype is you use other people's bandwidths, you connect to them. So there's, super cool, I think it's, if you wanna look at this, Stun is a really interesting protocol. The idea is, if I'm a program here and I'm running on port 80 and I want you to be able to talk to me on port 80, I can basically send out a packet, a fake SIN packet that actually opens up that redirection backwards from the server. So anyways, there's like a whole head loop. So I think there's two different protocols. One is like a series of tricks and techniques to trick the NAT to opening up ports that went forward so that people can connect to you. There's also, I believe, protocols that an application can actually talk directly to the router and say, hey, I really want this port forwarded to me because I need people to contact me. But now it's put on our shoes, not in the us in our homes, but in the Google scenario, right? So with Google, NAT doesn't really make sense here. Because this machine needs to be accessible from an IP address, right? There has to be a way to talk to the web service. So let's say like a router within NAT. So what are their options? Let's think about this. What are their options? What can they do? I mean, one of the options is they can use basically a router and set it up like we talked about before different traffic. What else can they do? Easy one is nothing, right? They do nothing. They just put computer, public IP address, that's fine. What's the downside there? We'll think about it this way. So we're Google. We have our server on an IP address. This IP address secret, I don't know this IP address I want to talk to us. If they can't talk to us, we don't make money. Everyone knows this IP address. So let's take a web server. So we know what's running on it for sure. A web server, it's not a sure question. A web server, we know there's something running on port 80. What else might be running on, reasonably be running on this server? SSH. SSH, port point two, right? Why would you think that it'd be reasonable for SSH to be running on that server? People don't want to physically go to the machine every time they need to change something. Yeah, but Google has literally thousands upon thousands of these servers. They do not want to have to go into it and type in things. We have to remotely administer these tools and SSH is an excellent tool for that, right? So you clearly want an SSH port, an SSH service open. What else? The mail service as well. Sure, yeah, yeah, SMTP. HTTPS. Maybe they have Port Worth of .5, HTTPS, Port Fort Three, there we go, thank you. Maybe LDAP, which is like a directory service, which I have no idea what port this is. I don't remember. Somebody look through that for me now. Right, they have all these services. So, now it comes down to a... 3D9. What was that? 3D9. 3D9, I will not remember that. Cool, so all these ports, all these services running, but do we think about it in terms of authorization? Who should be allowed to, is EPCHO, should everyone be allowed to access all these services? Which ones? No. Probably not SSH. Probably not SSH, why? Because you don't want people even attempting to log in if they happen to guess or group force the passports. So who would you want to be able to access Port Point Two? Google employees. Or maybe somebody else, because we got to think. So this is the public internet, and then this is somehow Google's network, right? So we want Port Point Two only on the internal network. What about Port 80, can we restrict that? Probably not, we shouldn't, right? Because we want people to access Port 80. What about 4.43? Yeah, the same thing, we want people access that. What about the LDAP server, which has our corporate directory and all the people who work in our company? Probably not as well, that should probably also be internal network. What about SMTP? I think the answer is it depends on what this is for in the company. If this is like the Gmail SMTP server, then clearly it needs to be world accessible. If not, it wouldn't make sense. So I think about it in terms of going back to talking about the attack surface, right? So to think about every single port we have accessible to the world means that anybody in the world can make a request to that port. So if somebody finds a vulnerability in one of the services that is listening on that port, that means they can get into our servers and propagate it from there. So we want to restrict the attack surface and only allow what things we actually want people to access. So how do we actually do that? Like what mechanisms do we have to be able to do that? Yeah, so let's add basically a little box here. So we can put something there that acts as our network enforcement mechanism. That we can make rules that say to whatever, server G only allow traffic to port 80 and 443. That's it, nothing else. Don't allow access to, I mean, block all the other ports. So the way to think about it, and the way I think about it is that essentially isn't to enforce some network security policy. So this is why we spent so much time beginning the class talking about mechanisms and policies because this is what everything is. So then the policy becomes, what do we actually want to block? Are there blanket statements of what we want to block in every server? So maybe the answer is that maybe it depends. So we may want to, if our firewall is smart enough and we can say, hey, don't except drop any SIN act packets that you didn't see an initial SIN for or something like that. You could try to restrict the traffic so it's only good traffic. But so it really comes down to, so firewalls come down to how do you specify the policy? And really how expressive is that policy? Can you express, so think about this, how would you implement this or what would you look for in the firewall? If you said so, if we think about the Google server, the Google server should be able to accept incoming connections to the web. To what? Should that Google server ever make outgoing connections? Yes, why? When? So it depends, it depends on what you're doing. Maybe you're fetching Twitter data or Twitter API for something. Well, let's say that's handled on some other backend server that's not this server. This server just serves up web content. In that case, we wouldn't want to allow, we would want to restrict that server so it can't make any outgoing connections because that's not what it's job is, right? That's not how it should function. So if there's any packets going out, that could be an attacker on our system initiating some request to try to leak some data back. But the question is then, so we're not gonna get into all different types. You can look this up with various types of firewalls, stay where firewalls, not stay where firewalls. But some of them can't express this notion, right? Which as we know goes back to SYN packets. So it means that the firewall itself should not send any outgoing SYN packets, right? So we should see, we should drop any packet that has a source IP of the server and has a SYN flag set. That would stop all outgoing packets, but not every firewall can do that. Some of them maybe only can target IPs and ports. And so some other limitations of a firewall are one of the main ones is that we don't. So we have our nice internal network here which has server, can you guys see that? Okay, okay. Has server A, server B, server C. So can this firewall control the communication between A, B, and C? It only sees the outgoing traffic. So this is actually one of the major flaws of kind of the current thinking about firewalls is it's very remote-based thinking of like, oh, we have our internal network. And so we just need a firewall to protect us from all the garbage on the outside. When that ignores all of the internal attacks that can happen. So if any of these internal machines ever gets compromised, it's very easy to, there's no protection there, yeah. Is there any benefit to having the firewall running on a separate physical machine as opposed to an abstraction layer or a big configuration file in the web server or around itself? Right, so good question. What does the class think? Senator Rier, what do you mean? So, can I explain that to the defense? It just depends on what you would, what you need your firewall to do. Like, if you wanted to set it up on its own server, you're gonna, its own separate unit, like, you're gonna be able to do more with it. And as opposed to if you have just a firewall on your personal computer, like, parts of your, except your personal computer isn't dedicated solely to the firewall property. So, in your name. Right, so it comes back to what we talked about what's your threat model, right? What are the threats you're worried about, right? If, so let's say I put the firewall essentially on this web server and somebody compromises the web server through some Apache exploit and then through that they're able to use a local root exploit to get root on my system, now what can they do to my firewall? Just say, well, completely get rid of it, right? Because it's on the same system, right? However, if my firewall is a separate box that literally just only essentially looks at packets and either drops them or allows them to go through, there's very few ways. The attack service there is significantly reduced in the fact that it would be hard to compromise, let's say, an inline firewall like this. However, there definitely, it depends on, as I think we've talked about with the switches and hubs, it depends on the failure mode of this firewall. So they're having attacks against firewalls that they cause the firewall to crash. And so when the firewall crashes, rather than stopping all traffic, it does what we call fail open, where it just fails and all packets go through so your firewall is completely disabled and useless. So they all have frozen cons and it depends on these boxes. I mean, to get a separate box, it's expensive, right? And the firewall included in Linux, this comes with the server. So you have to consider those types of things in there. Probably the best way to think about it would be a combination of both, where you're looking at not only, you should, each server itself should be restricted to only do what it needs to do on its own and then also have other mechanisms of restricting those as well, kind of a defensive depth strategy. Great. So, you're an organization, are you under attack? Yes, the answer is yes, you're always under attack, but it doesn't matter how big of an organization you are. I guess if you literally just bought a brand new computer and put it in your garage to do a startup, you're probably not yet under attack. As soon as you connect to the internet, you're pretty much under attack. Are you, have you been compromised? I had some microchip from type one. Ah, I see, so not in that scenario. Go back to a general, you're in some organization that's not the tiny startup that you've created with the fresh computers. You're in some organization, are you compromised? You don't know, do you want to know? Yeah, you definitely want to know, so how do you know? Higher forensics consultants are very good after the fact. So, a forensics consultant can go in, check all your logs, assuming you actually have the correct logs and have a logging infrastructure set up and they can figure out what happened. So, they may not be able to tell you that you're actually currently infected at all events. They have different focus. But, we know that you want to know if you were under attack, right? I mean, that's kind of step one. And so, that's the other major kind of network security defense, so maybe two big things you'll hear about a lot, firewalls, which we just talked about, and intrusion detection systems. The idea here is basically, this is a mechanism that acts similarly in some sense to the firewall, where it's monitoring all the traffic, but instead of dropping traffic that doesn't match a certain policy, it's going to try to determine, is either this machine or is another machine compromised? And that would be really the goal, because you want to see, it's an intrusion, right? You want to see, is my system compromised? Is there somebody inside my network? Question is, how do you do this? You're building one. He said, ask who is building one. How do you do it? What are traffic and do what? Well, you have to operate on, predefined roles that are. How do you come up with those rules? It's all nice to write them. It's all nice to write them? How do they write? Based on your policy, your policy would determine, your policy would determine network traffic that you need to be malicious, and you'll search for that, and hopefully be constantly vigilant on new trends in updating your new rules to reflect and in search for those. Yeah, there it is. Just that, like if you work at the NSA, and you have this system behind your firewall, what a reason, like every 10 minutes, it's sending a signal to a computer in the Ukraine, you might want to look into that, and see what's going on. Well, why would that, how would you know that that's a, maybe a batch sign, or some kind of thing you want to look at? Generally, again, it depends on the organization application, but you have some scope of services that you're providing, like going back to the white list, and there's posts that you would talk to on a regular basis, and you might be able to see a deviation or an outlier from the pattern. Man, maybe this connection is a little bit weird. Right, so there's two main classes of intrusion detection systems. One is basically signature-based, where you try to come up with rules that define when you're being, when an attack or a compromise or an exploit took place, and then you just look for those, that traffic in the network. That clearly has problems because you can easily, an attacker you have to assume the adversary knows these things, and so are these, is it possible for an adversary to still get what they want while like launch an exploit of your service, launch a whatever remote code execution attack, while still invading your rules. So it becomes this kind of interesting cat and mouse game. The other approach is what we just talked about, of anomaly detection. Basically, you somehow, all kinds of ways, statistically model the network, the traffic that happens, and you look for outliers. So what does a bank use, both? Yeah, so I think about it like this, like this is, you know, it's, anomaly detection can be good, but at the same time, it's not the end-all, be-all. So if you think about a bank, like a security guard, visible security guard inside of a bank was just using anomaly detection, right? So if you walked in with a gun and a mask, right, they would alert, call the police, and you'd get arrested, right? Because that's not normal, that's not what normally happens. But what if you start going to the bank wearing like a beanie, right? So you go in and the guard learns, I got paintings, paintings are cool. And then the next day, you come in with like a ski mask, because it's like super cold out, right? Like aloe beanies are really close to a ski mask, if that makes sense, right? And so the guard learns, ah, ski masks are definitely okay. And then maybe you come in with like a toy BB gun at some point, you know? It's like a BB gun, everything else is super normal, just your kind of BB gun, and they're like, that's weird, but, you know, but it's still close to everything else I've seen, because everything else looks good. And so they learn BB guns are okay, so you keep pushing that, eventually you could just walk in with your ski mask and your BB gun, your real gun, and then they just say, oh, great, I've seen a person wearing a ski mask before and I've seen a person carrying them before, so this is clearly normal traffic, right? So this is kind of the key problem with anomaly detection systems, is they can be adjusted adversarily over time to think that not normal traffic is actually normal, right? Whereas the flip side, these signature detections, you basically define known bad input, so you know if you ever see these, it's bad, right? So an adversary can't change that, but the adversary can change what they're doing to evade your signatures. So this kind of gets into like the policy of what to detect, like how do we detect things? Anybody look at the default, like snort rules? So snort, S-N-O-R-T is an intrusion detection system. It's open source, you can actually download it with the code, you can run it on your own computer. The default rule set sucks a lot. They have all these different categories that have like ridiculous false positives, so you can run this on your system, it will just alert, alert, alert, alert, alert, and all of them will be false positives that weren't actual alerts. And so the downside of an intrusion detection system is basically it just tells you that you're compromised, so some things we talked about, we need to actually have confidence that our intrusion detection system is going to tell us when it's compromised, and so an attacker can't exploit the IDS itself, but we actually, it's kind of a counterintuitive thing, it's like, why would I buy, why would I spend $10,000 to buy something that tells me that I've been compromised? It's like a security guard with like a whistle. It just like blows the whistle. It was a great cool, we're seeing a robber in progress. Awesome, it's better than not knowing you've been robbed, right? But what you'd want is maybe a prevention system that actually acts like a firewall in the sense that it's in line and can drop offending packets. This has all of the downsides of an IDS of false positives, but now you're gonna drop actual real traffic, which could cost you business and money. This is actually something that somebody wants to, I don't remember all the details, it's probably still true, so I think I mentioned this before. ASU definitely has a, I would say like an intrusion prevention system or some kind of firewall system that looks into packets to see what's going on because I've definitely, I've hit it two ways. One was doing a web security assignment on my own server and not being able to send cross-site scripting payloads because they're just getting dropped somewhere. So I switched to HTTPS and everything works because it's all encrypted so I can't see the packets. The other thing was we were looking at web vulnerability scanners and these tools sending HTTP header called like x-scan-width and then the name, like the name of the tool. And so what we found out by playing with it is if we scanned out like another website from inside ASU, those requests would never get there because ASU would drop, it should say ASU, the firewall would drop all those packets. So then we were like, huh, I wonder how smart that thing is, right? Like where does it actually look? And it doesn't look for any HTTP header, it actually just looks for the words x-scan-width, whatever the standard's name was, anywhere in the header. And one of the header fields is to refer where you came from. So if I send you a link that, if I send you a link to something and the page that you're on includes this keyword, when you click that link you actually can't visit that link, like that next request gets dropped. I actually couldn't turn it into something super interesting but it was a weird instance of like these intrusion prevention systems. They're not full proof in both ways. They may miss stuff and they may accidentally block other stuff. That sounds sufficient to me because it was looking for a keyword in a single packet and let's assume that the dictionary of its bad keywords was rather large. Would that increase the latency astronomically that it was analyzing? No. Or are you tearing rants, hacking your packets, looking for these bad things? Like that one was just from the header, right? It's in the HTTP header so it doesn't look in the body of the message. So that's less of the packets but it definitely, yeah, there are performance impacts but there's also really cool ways to get around that. So there's some approaches I've seen where they use GPUs to do this kind of intrusion detection. They can do it crazy fast in parallel so it's almost no noticeable delay, all kinds of cool stuff. And four, so an IPS must be in line, right? For it to drop something needs to be in line whereas the intrusion detection system, if it gets a copy of every packet that gets sent, most switches have like a tap device or have a way to set up a certain port to either mirror another port or your certain ports, then you can actually see all the traffic there. So usually you get a copy. But yeah, and we saw you could play all these kinds of games with packets, right? We can actually, we don't have to send the whole payload in one TCP packet, right? We can actually send it byte by byte, one byte at a time. So then you have to think, well, is this IPS or IPS going to actually, when it gets a packet, is it gonna keep track of the whole stream that I've been sending or is it going to either accept it or block it at that point? And most of them make the decision right then. Or you can play crazy IP fragmentation games that we talked about and break your packet up into different IP fragments which some of these things can't actually correctly assemble. And so you can do super cool stuff like that. Okay, so these are really the kind of current generation of these tools. And so going forward, so network security research, the ideas are we want, they're actually a lot of different ways here. So there's a, I mean, my lab is doing research into software-defined networking, which is essentially, as maybe, I'm gonna talk about this, it's maybe set up and configured a, like router or switch before, like a decently sized one. How did you do it? You go into a stupid web interface and you have to change and set up. And if you set up any VLANs, we console them, basically set up each individual interface and then set up routing tables, connected that to a wireless access controller and then to an access point. That's a huge pain, right? Yeah, it takes hours. And when you wanna go change something, you have to dig up the credentials to get to that switch, say actually we wanna change it like this. So the idea behind software-defined networking to say let's make the switches dumb. Super dumb switches that actually don't know what to do. And when they get a packet in, they'll actually ask a centralized component called the controller, hey, what do I do with this packet? And then the controller will install rules on each of the switches to tell it how to forward those packets. So then you can think, rather than your network infrastructure and your network configuration to be distributed inside all of these different switches, you actually remove all that out into a central location that has a view of your entire network and can make intelligent decisions about where to route and where traffic should go. So you can do super cool things and they've actually built it in a similar style where you can build apps on top of that controller. So you can add a load balancing app that would actually add a network level to load balancing. So super cool stuff there. Other areas of research, there's IPv6 which we didn't even talk about or we briefly, briefly mentioned that vastly increases the IP address space. There's IPsec which actually tries to build in. We've said some of the key problems at the IP level is that the source IP and the destination IP are completely spoofed. The packet's not protected at all. Anybody can see anything that's inside that packet. And so IPsec has different ways of doing this and of building really cool security around there. So there's, yeah, network security research, there's a ton of areas here. How to build better intruded detection systems and intruded prevention systems. Everything we talked about, the current state is basically that everything sucks but it's getting better. And so research is trying to push that forward to make things better. So, all right, cool. We are right on time.