 So, we want to be able to detect when someone's trying to intrude into our computer system, into our network, for example. So when someone's trying to attack us and log in remotely or do something malicious. We talked about the types of intruders and the general concepts of intrusion detection, but we'll come back to that with some examples today. And really, we'll classify into three types of intrusion detection. Host-based, think of there's some software that runs on a host on a computer and monitors what happens on that computer. And from that monitoring, it tries to determine is there an intruder or not. So a host-based on a computer. Distributed host-based extends that, so say in SIT, we have some software on each of the computers, on each of the hosts, and they collect information and send it back to some central server to help trying to determine if there's an intruder. So distributed host-based collect information not just from one computer, but from multiple computers in the network to see if there's an intruder A into a computer and B into the network. So both of them are looking at what the activities on the computers. And network-based intrusion detection we'll get to is looking at the activities on the network. What packets are being sent between computers into the network and out of the network? So monitoring the packets, the communications, as opposed to monitoring what's happening on the computer, like the file reads, the programs that are executed. So let's go through them. So host-based intrusion detection system, some software that you install on your computer that tries to detect if there's an intruder and log events that may be suspicious so that we can study it later. If you can detect an intruder early, you may be able to stop further intrusion, stop a malicious attack. So if you can detect someone logging in that should not be, then you may be able to automatically log them out so that they cannot do anything else that's malicious. The idea is to look at what the normal users do. So the normal users of the computer system and understand their behavior and then under the assumption that an intruder will do something different and therefore use that information to try and detect, okay, based on the behavior, based on what's happening, is this an intruder doing it or a normal user? Early detection is to look at strange things, look for anomalies. So if we know the behavior of the normal user, let's say that we study the behavior of the normal user over a period of one month and we can understand what they normally do, what files they access, what programs they execute, when do they execute them, when do they log in, how often do they log in per day, per week, for how long are they logged in? So if we can understand the characteristics of the normal behavior, then what we do, given that information, is that when something's happening we compare it to that normal behavior and see if it's outside the normal behavior, that is, it's an anomaly. Two approaches have some thresholds and, for example, we say that based on our study of the normal behavior we expect that no user accesses or starts this program more than five times per day, or no user accesses this file or tries to read this file more than once per week, or no user logs in for more than one hour at a time, or less than two minutes at a time. So based upon some known behavior, set some thresholds, so set some values based on the known behavior, and then when something happens, some events happen that exceed those thresholds, that's a trigger, this may be some strange event, this may be an intruder. It doesn't guarantee that it's intruder, but the idea is that if we, if multiple thresholds are crossed, then that's an indication that this is likely to be an intruder. This is independent of the user, so the thresholds think are for the entire system for any user. So think of the ICT server, there are many users, many students can log in and staff can log in and do things on the server. So what we'd need to do is set to observe some profile of a normal user, students and staff, and then set some thresholds about the activities that may be undertaken, and then monitor if those activities exceed the threshold, then that's a trigger that this may be an intruder. Profile based is a bit more complex in that we look at individual users, normal users, and create profiles of what they do. And again, when for example someone's logged in as that user, compare the activities of that user against their profile. If it doesn't match the profile, that's an indication that it's an intruder. Let's have a look at an example for this concept of a profile. Before we go to the example, let's look at audit records or logs. So where do we get information about what's happening? What do we monitor? Well, computer systems, the applications running, the operating system always or can maintain some log of the events that take place. So say we have a log of who logs in, when, for how long, what files they read and try to write to, what programs they execute, what those programs try to do. So if we could log all the activities of what's happening on the computer, then we use that to observe the behavior. So these are generally called audit records, so some record of what's happening. So most operating systems have logs of what the software and the user does. So native audit records is using those logs of the operating system or the software, the applications. So you run a web server on your operating system, it produces a log normally. So read that log to observe what's happening. So most operating systems and applications have their own logs. So one approach is that the intrusion detection system uses those logs, it reads those data logs and makes some observations based upon that, use the existing ones. The other approach is that the intrusion detection software itself maintains its own logs, it creates its own separate logs. So think again, an intrusion detection system is just a piece of software running on your computer, the host based. So it could generate its own records of what's happening. So when you install the intrusion detection software on your computer, some privileged process, it hooks into the operating system and creates a log of everything that happens on the computer, its own log. So different approaches use the existing logs which the normal applications already create or the intrusion detection system itself creates its own logs or own records. What's the difference? Well, in the first case, we don't need any special software to create the logs, the logs already exist, are there anyway, so it makes sense to reuse them. But as we'll see in an example, the logs produced by different software, by different applications may be in many different formats, maybe text, maybe some binary file, maybe in a database, so we need to handle all those different formats and we need to process it. Because if the intrusion detection system does its own log keeping, then it's independent of the software and it's independent of the operating system, however, it requires some extra processing and record taking. So either way, we need to have some log of what's happening. We need to know what's happening on the system. Does Windows have any log of what's happening? Anyone seen a log? I haven't used Windows for a while, but what's the name of the software or the feature in Windows that shows a log of what's happening? Anyone know? I'm sure you can find in the control panel or somewhere that there's an event, I think it was called a Windows event viewer. You can see many events that happen with respect to the operating system. You can try and find that. It shows at different levels of detail the events, the things that are happening on the system, especially errors and warnings. But you could configure it to log normal things, things that are not errors and warnings and therefore keep a record of everything that's happening. The programs which are started, the users which log in, the files which are read, written to, deleted. Let's look at an example. We'll come back to Moodle log in a moment. Let's look on the ICT server as an example. I'm logged in to the ICT server. Most Linux computers keep very basic logs of some things that happen. For example, the people that log in, the ICT server, many students have accounts that they can log in, so there's a record of who logs in. Let's have a quick look just to see some of the information we can see. In Unix systems, they usually store logs, I'll show you again. In the directories, slash bar, slash log, that's where most applications and the operating system stores their logs, and the logs are usually just text files, just one line for every event that happens. There are many different types of logs. We're not going to look at many, we'll just look at one example. There are logs about what happens when the computer boots. The operating system kernel about the email, because this is also an email server, so when someone sends and receives an email on this server, there's a log of what happens. The system so includes applications, there's logs there, and MySQL, when the database server starts and does things, there's a log of what happens. So up the top, many of them are not relevant. Apache, the web server, so there's a web server running here in that directory. There are many more logs of whenever anyone accesses the website, there's a log of a summary of what happened there. There are many logs, usually just kept in files and you see that they rotate over time, so as the log gets to some size, copy it to a new file and start writing in a new file. But that's not the point here. There's this authentication log, which is a log of essentially the log-ins by people to the server. The details of the log, it's very hard to see, and we'll look at some a little bit closer, but every line it prints, the date, the time, and some message about what happened. Now these, though, are not so important, we'll filter out. There are thousands of logs over the last few days. Let's just go straight to some of them. For example, when I logged in, let's try and see the logs. There are many different logs, so I need to search through them. I think the message is this, we'll try and then explain, no it's not. One word. So this just searches through all this log file, looking for this string, accepted public key for S Gordon. I know that because that's the message that's printed whenever I log in. I don't log in with a password, I use a public and private key to log in. So the software, when I log in, prints a message saying that the system has accepted the key that I've provided, allowing me to log in. In fact, there are many log files. I'll zoom out a bit, and it just lists all of those log-in attempts, or successful log-ins by me. Looking at a little bit closer, just looking at one of them, for example, it shows us the date, the time of the log-in, and when we log in, we use the secure shell to log into the secure shell server, or demon, and it says, accept a public key for this user, so my username, from this address, so this is the IP address that I logged in from, and the port number that I used. So a very simple log, but from this, the server knows when each user logs in, and you can do more analysis to see when they log out as well. So from that, the duration they're logged in for, so for each day, how often they log in, for how long they log in, and at what times do they log in? So let's say we do analysis of all this data from the normal user, and we come up with some profile with respect to the log-ins. And to keep it simple, let's say we analyze and we look at all the times when I log in over the last month, and use that as my profile. So from that log, of course, we wouldn't do it manually. The intrusion detection system should do it for us. You should monitor this to develop a profile. And we come up with some profile, and I'll try and draw a profile that, and you'll see it makes, it compares to one of our earlier slides, a rough plot of the log-ins, or an example of log-ins over time. Let's say we looked at over the past month when I logged in, what times during the day. So from our zero up to 24. And we count how often I log in, say between 11 and 12, or here, 11 and 12. And between 4 p.m. and 5 p.m. And we count them over some period of time to develop a profile of that user's normal behavior. So we'd get a really a histogram of the log-ins. So I'll just make up some data. Let's say I log in these times the most frequent. That is, we record how many occurrences I've logged in at particular times. Whereas this is the frequency, okay? So I'll log in most times around 12 o'clock, sometimes in the afternoon, sometimes at 8 p.m. Okay? So we develop a profile of the user. We can think of that as some distribution. So we could fit a curve to that, it's something like that, okay? So this is the profile of the user. So we've given that, now when the system is running, when someone logs in as S Gordon, the intrusion detection system compares. Okay, someone's logged in. If they've logged in at 1 p.m. as S Gordon, so at this time. And this intrusion detection system compares that to the profile and sees, okay, that matches the profile quite well. Because there's a high probability that the normal user logs in at 1 p.m. But if there's someone logs in as S Gordon at 1 a.m. Okay, at this time. Then again, the intrusion detection system compares, okay? S Gordon logged in at 1 a.m. But given the profile, it's very unlikely that the normal user logs in at 1 a.m. It's possible, but very unlikely. So that's an initial trigger that this is possibly an intrusion. Now, this is quite simple, just considering the login times may not be enough. But then if we add further information, not just the times, but then even the days, days of the week. So you may have different profiles based upon the day of the week as when you log in, sad days and Sundays may be different from Mondays through to Friday. In fact, on Monday when I'm teaching a lab, it will be different from Tuesday when I'm in the office. So the profile will be more detailed than just this. And again, the system compares the current activity to the profile. So with more information about the profile, you can get a more accurate guess or accurate estimate if this is an intruder or not. And this diagram is, if we go back a few slides, is the concept here. So we said this was the profile of the normal user, some parameter that we can measure, some behavior, login times, files accessed. So some profile of the normal user. And we work under the assumption that the intruder would have a different profile. And therefore, we monitor what happens, compare it to the user's profile. If they match, then we assume it's not an intruder. If they don't match, then we assume it's an intruder. And of course, the problems arise with intrusion detection systems in that, okay, sometimes the behavior of the intruder matches that of the normal user. There's an overlap here. So, someone logs in, go back to our case. Someone logs in as S Gordon at, what's, say at 6 a.m. Our profile says that that's unlikely. Okay, it's very unlikely, it's possible. Now, what's the decision, intruder or not? Well, if we make the decision that it's not an intruder, because there is a chance that I logged in at 6 a.m. If we make the decision, or if the intrusion detection system makes the decision, it's not an intruder, but it is, then that's a failure of the detection system. Or the other way, if it assumes it is an intruder, because it was logged in at 6 a.m., which was very unlikely, but if it wasn't an intruder, if it was actually me, I just woke up early, then again, that's a failure of the intrusion detection system. False positives and false negatives. So, a real intrusion detection system doesn't just use one parameter, it uses a combination of many parameters, not just logins, but then also the activities. When I log in, what commands do I execute? What files do I access? The more information, the more accurate it can be. Just coming back to our, well, with that example, our log, so that was a log of my logins. I just searched through for everything that had accepted public key for S Gordon. When you try to log into the server and you have the wrong password, it prints a message, failed password. So, let's search for all the lines that contain failed password. Of course, hard to see how many over the last few days, 2100 failed password attempts. I think the logs are over the last, I don't know, week or so. So, in the last week, there are about 300 attempts per day of someone trying to log into the ICT server and they don't have the correct password. Now, this is just a basic feature of the operating system and the server, but it's a basic intrusion detection system because we can see, if we look at some details, we can see some of the details, okay, failed password for root. So, someone tried to log into the server as the root user from this IP address and at 9.30 a.m., 12 seconds, and then three seconds later tried to log in from the same IP address as root user, and then three seconds later again, okay, then at this time, same IP address trying to log in. What's happening? What's happening there? One computer with IP address 124219196.188 is trying to log in to the ICT server, username root, supply a password, and the password is wrong. So, someone's trying to guess the password for the root user in this case. So, this is an attack on the password of the root user. So, essentially the start of a brute force attack or an attack on password guessing. It may not be brute force, it may be trying some expected passwords. This system is set up such that after several attempts of this, I think five or six, so six attempts, it starts to block that IP address. So, this is the case of one of those ways to stop password guessing. If someone tries to guess the password and they get it wrong six times in some period of time, then don't let them try again. And that's what's happened here that they've tried over a period of just 10 seconds or 15 seconds, six attempts at the root user password. After that, the system blocks that IP address. So, a way to stop password guessing. And then you see some others. Not just for the root user, here's failed password for invalid user. Someone has again tried to log in. All Linux systems have a root user. But in this case, someone's tried to log in as some other user. In this case, it's an invalid user. There's no such user with this name on the ICT server. Again, what they're trying to do is try and log in with common user names. They're passing the user names and then also with those user names trying to guess passwords. So, one thing that may be happening is that they just choose some random or some common user name. And maybe they try the password or one, two, three, four, five. That is, they try common passwords. And then they try a different user with that same common password. And there's not many others shown here. But if we look through later, you'll see some many different attempts at different users. So, that's an attack on the passwords of trying to use common passwords for many different users. We can see that, I think, again for the non-root users. So, here someone has tried many different almost random passwords. Random user names. And they've tried some passwords for them. So, an obvious feature of an intrusion detection system is to monitor the login logs. To see who's trying to log in and to block those that should not be. I think we skipped over this slide. Requirements of any intrusion detection system. Okay, let's go through them quickly. They should run automatically. So, you install the intrusion detection system on your computer. And once it's set up, it just runs and it runs forever. That's the idea. That you don't have to intervene to operate it. Your computer crashes for some reason. Then, of course, the intrusion detection system should automatically start and recover. If someone tries to attack the intrusion detection system itself, it should try to have strong ways to defend against such attacks. Because if someone can attack the intrusion detection system and turn it off, then they can try and log in and, of course, they will not be detected. Or do other things. Of course, when the intrusion detection system is running, it's monitoring logs. It's monitoring events that are happening on the computer. That takes some processing and some discrete time. So it needs to create minimal overhead so that it doesn't disrupt the normal user. It should be configurable. That is, sometimes we have different requirements of what we want the intrusion detection system to do. Maybe we want to focus on monitoring these set of files, which are the files for our accounts, our financial accounts for our organization. So they are the most important things. So configure it to monitor those only or to give high priority to those. So be able to configure it. If we develop a profile of a user and then use that fixed profile, well, unfortunately over time the profile of users changes. So if you develop a profile of S Gordon, of the logins, of the files he accesses and so on, over time his normal activities may mean that that profile changes. So the system should be able to adapt to such changes. On a single host that should work, but in a network where it's more useful, when we have many computers that should be able to adapt, especially distributed host-based intrusion detection and network-based, it needs to be able to work when there are thousands of computers in the network. Maybe the intrusion detection system has components on different computers. We'll see in the last two distributed and network-based, there are many different components. So if some of them fail, for whatever reason, the rest still should keep working. That's the last requirement. So the last two are really about distributed host-based and network-based intrusion detection, not so relevant for host-based. So we said one way is to develop a profile of the user and compare the activities against that profile. If it's inside the profile, okay. If it's outside the profile, let's assume it's an intruder. Looking for anomalies in the behavior. Another approach is signature detection. Define the behavior as a set of rules. So try and write some rules that define what a user normally does, rule-based anomaly detection, or what an attack normally does, penetration identification. So if we can write some rules that the attacks that we know of are trying to penetrate into our network to intrude, if we can define a set of rules as to what that normally involves, then when something happens and matches those rules, then we identify that as an intrusion, a penetration. Whereas rule-based anomaly detection is having rules based on what the normal user does. And again, if something happens that matches those rules, then that's okay. But if something happens that doesn't match those rules, then that's a likely intrusion. But this relies on having some rules, so some statements or some conditions. If this happens and this happens and this happens, then that's normal behavior. And in terms of penetration identification, it relies on knowing about the attacks. An anomaly detection is understanding what the normal user does. Anything that's not normal is an attack. Whereas penetration identification is knowing about what the attack does, and that's the way to identify the attack. A simple example may be, okay, we know there's some attack software that tries to automatically log in to SSH servers, like ICT. And the way that they attack is they first try and find the port number that the secure shell server is using. So they scan through the ports and then they try and submit passwords of these types to try and log in. So we may know what the attack normally does, define some rules to capture that attack, and then when we monitor what happens, if what happens matches those rules, we assume it's an intrusion or an attack. So on Tuesday we mentioned these just to gain, so there are many different measures for what's normal behavior and what's not. So log in activities, activities on files, activities on using programs, using applications. So that was about host-based intrusion detection. So running on an individual computer, some software to detect intrusions. Distributed host-based, we have a network inside SIT. What we do is that we run host-based intrusion detection software on multiple computers on hosts throughout the network. And so we run some special intrusion detection software on each computer inside SIT, the office computers, the servers, for example. They collect information. So we have some agent that collects the information, the records, the logs on the individual computer and eventually send that back to some central manager that will incorporate all of that data, not just from one computer but for all the computers to make decisions of intrusion or not. Of course, the more data you have, potentially the better you can detect intrusions. This also mentions, okay, we may also monitor the traffic on the LAN. So this is leading to network-based intrusion detection. Monitor the packets as well. And the host agents and the LAN monitor send alerts. So when something happens locally, they send some notification to some central manager and that central manager component combines all that data to detect intrusion or not. And the picture, I think, captures that. So a simple network. We have on hosts, we have some, let's think of this, some intrusion detection software. It's called an agent module, but you install some software on each host as part of the intrusion detection system. That monitors what happens on that host, looks at the logs and the events. And that's done on multiple hosts. We may also have some device that monitors the packets going through the network. We'll see the details of that in the next part, but the packets sent from the router to the host, it can monitor them as well. So they all collect information and then they send either all of that information or usually just a condensed form of that information. So they do some processing and send to some central manager who then makes the decision intrusion or not. And the idea is that with the more information, the better you will be at making that detection of an intruder. Because an intruder may, the packets that they send through the network may give an indication if they're an intruder. The hosts that they access, if they access particular hosts, particular computers, if they access someone's laptop or someone's desktop computer, may be different than if they access the database for the finance department. So the computers that they access may be an indicator of what the behavior is. So by collecting all the information we can improve the chance of successful detection. Let's say we have SIT, we have many different computers. We want to run such a system so that all computers, we install some intrusion detection software, this agent module on each computer. So there's one that runs under Windows, there's one that runs under the servers in Linux, and there's some that run in the Mac OS in the labs. They're all running on the individual hosts, and they all report back to a central manager. Some of the issues with that, each of those computers have different formats of their logs. So the intrusion detection system has to deal with all those different formats. So a Linux computer keeps a different log than a Windows computer. So how do we combine that information? The information that comes from those agent modules must be sent back to the central manager, but that needs to be secured. So these agents look at the logs, look at the events that are happening locally, possibly do some processing of that and send back some information, some summary information to the central manager. This information should be secured in the transmission so that no one can intercept it in the network. If we have just one central manager and that fails, then effectively our whole intrusion detection system fails. So this single point of failure is a problem here. If we have multiple managers, so to avoid that problem we duplicate the manager across five or ten different computers, have a distributed system, it should be better, but it's more complex. They must coordinate and make sure that they have up-to-date information. So as with any centralized system, there's a single point of failure. That's a problem. Distributed systems don't have that, but they are more complex to have all those different managers keep up-to-date. So just some of the issues with distributed host-based intrusion detection. And the last approach, network-based intrusion detection. So I think with host-based, we're monitoring what happens on computers. Logins, session activities, file access, program access. Network-based intrusion detection, we monitor the packets through the network. What's being sent and received? Monitor the traffic. So at different points across the network, we monitor what's coming in and out with respect to packets. And we do that using some sensors, some device that will basically keep track of the packets coming in and out. We call them sensors. And then some analysis of that traffic has taken place to do, again, to work out intruder or not. So look at the patterns of behavior based upon the traffic to see if there's an intruder or not. Now the analysis may be done at the sensors, or that they may send information back to some management server that does the analysis for all of them. This is a typo here. Examine packets at close to real-time, not example, examine PLE. That means for this to work efficiently, as packets are being sent through the network, these sensors are capturing the packets. You know how to capture packets. It's the same concept of TCP dump. You capture packets and then do some analysis. So look at the contents of those packets, who's sending them, who they're sending to, what protocol, what's the contents, and try and make a decision. Are these packets an indicator of an intruder or not? And that needs to be done quickly. So examine the packets very quickly at close to real-time. Because if you examine a packet and then slow down the packets to examine them, then that slows down the delivery in the network. This is an example, a simple example where we have an internal network, the outside internet. We have some switches and some, okay, here are some internal servers. So here are some PCs, some of the workstations here, but say that the user's computers, some internal servers, some external servers. So these are the servers that the public access, web server, mail server, whereas these internal ones may be just for the internal use only, like database servers for finance, for registration, and different internal uses. So just an example of a network structure connected via some switches. The next topic is about firewalls, but firewalls are really there to control what packets can come in to the network and what can go out in some cases. So we'll look at them in detail next. These magnifying glasses are indicating that these are where we have some sensors. Somehow we need to monitor the packets at these points in this example. So we have some sensors that record the packets coming in and out and then do some analysis of those packets to help determine if there's an intrusion. They could do the analysis themselves, or maybe the sensors could all send some data to some other server that does the analysis, some management server, which is not shown in this example. Normally the analysis of packets can take place at devices which normally have packets passed through them. Switches, routers, and firewalls. So switch, packets come in and it sends packets out. So what does a switch packets come in and come out? Then you can add some software to that switch such that it, as the packets come in, that's intrusion detection software monitors and keeps a record of the packets for analysis. So it's logical in most cases to put the sensors on devices which are already existing in the network for packet delivery. Switches and routers and firewalls even. That is inline sensors. So they insert it into the network and as packets pass through those sensors, they record a copy or do the analysis. Usually runs as software on existing switches, routers and firewalls. So the switches in our lab, in those cabinets, we could set them up that we have some extra software on those switches. Now I'm not sure if they support them but I'm sure we could buy one that does that extra software captures all the packets going through the switch, essentially runs TCP dump, capturing all the packets and also doing analysis of those packets looking at who sent them, who they sent to, what protocol, ICMP packets, HTTP packets and the profile of those packets. Like how many are coming in per second? How many ICMP ping packets are coming in to the switch or the firewall? And the intrusion detection software does some analysis to detect is this an intrusion or not? Are these secure shell requests to log in packets? And then analyze that based on the expected behavior. So an inline sensor is something that usually runs on an existing network device. You don't need extra hardware. Passive sensors usually require some extra device that takes a copy of the traffic and does analysis. And monitors a copy of the traffic. Here is that, let's say this switch here. An inline sensor would be some intrusion detection software running on that switch as packets come in. It analyzes those real packets and then they send out. Passive detection or a passive sensor, there'll be another computer say here and this switch is configured that everything that comes in, let's send a copy to the destination but also send a copy to this extra device. Then that extra device does the analysis. So it's just a difference is do we do the analysis on the switch? Or if so, we need a switch that supports that intrusion detection software. Or quite simply, we use our switch to make a copy of every packet that comes through it. Send it to some special computer that then does the analysis. In that case, we need that extra special computer but it reduces the load on the switch. It just sends a copy. It's very easy to do that with switches. So there's some differences there. Into where do you put your sensors? Inline sensors don't require extra hardware because it's happening as those packets are going in then it can detect quite quickly but it requires a lot of performance of the switch. Packet comes in, analyzed, send it out. When you've got thousands, hundreds of thousands of packets per second coming in you need a high-capability switch in terms of hardware to do that. Whereas a passive sensor, the switch just copies everything and sends it to another computer. That requires another computer but has little impact on the performance. The switch doesn't slow down. And that's the three types of... general types of intrusion detection. So host-based and network-based. Network, look at the packets through the network. It's not looking at what happens on the computer so it's not looking at which files were accessed. What's the CPU utilization? It's just looking at packets. And again, looking at the expected profile. What packets do we expect to be sent through the network? And when there's something that's unexpected, that's an indicator of an intrusion. And that's... We're not going to go through any more detailed examples. There is different software that you can buy or you can get that performs intrusion detection. So an example of a host-based intrusion detection software I think, and I've never used it, is called Tripwire. It's a common one that you install on your computers and it records things like disk activity, file access, and the operating system activity and tries to detect intruders. And then there's software that you can install on network devices to do network-based intrusion detection. And a common one, or popular one, it's called Snort, S-N-O-R-T, that you install on devices, you set it up, and it tries to detect intruders. They're not easy to set up, because we need to get some profile of what we expect. So they're hard to configure and to get right in terms of reducing the false positives and false negatives. It's complex. The last thing in this topic, sort of related, honeypots. What's a honeypot? It catches bees, doesn't it? Something to attract people to some location and keep them there and not let them go to do malicious things elsewhere. That's the idea. The honeypot, the bees go to the honeypot and therefore they don't come to you and sting you. They all hang around the honeypot. And with computer systems, a honeypot is something that the malicious users go to so that they don't go to your real services and attack your real network. So let's just briefly mention the honeypots but one or two slides, I think. So decoys, they are. They're designed to attract some malicious user, some potential attacker away from your real important systems. So you have some important servers, web servers, database servers, but you set up this honeypot server and make it such that when a malicious user tries to break into your network, it's highly likely that they'll go to the honeypot server because they think that's your important server and so therefore they don't go to your real important servers. Well, how can that help? Well, if they go to that honeypot server and maybe they think they've accessed important information but they really haven't, then maybe they stop attacking from now on and you can learn about the attacker's activity. So if they access this honeypot server, what do they do on it? What commands do they run? What files do they access once they're on this honeypot server and that helps you build up your profile of what an intruder does. And of course if you can encourage the attacker to be logged into that honeypot server for as long as possible, then maybe someone can respond. Again, make it easier to track that intruder. So a honeypot system may be filled with fake information. So normal users don't access it. So imagine SIT has a, we have a web server, an email server, a database server for finance and a database server for registration. They're our real servers. Then we set up a honeypot server that we put on some information that looks like it's information about registration information but it's fake information for fake students, fake grades and so on. And the idea is that when someone tries to intrude into SIT's network and access the grading information for students, they go to this fake honeypot server. They think they've got information so they go away but they haven't obtained anything confidential. So it has no value for the organization, the honeypot. And again, what are we saying here? Okay, so for this honeypot server, if there's packets going to this honeypot server, that is highly likely it's coming from an intruder because this honeypot server is set up that the normal users don't know about it and can't access it. So we have this special honeypot server for SIT. No one else in SIT uses it. There's no need to, they don't even know about it. Therefore, if someone accesses it, someone sends packets into the honeypot server, that's an indicator of an intruder because who else would be sending packets to this server that has no value? So incoming communications is most likely an indicator of someone scanning what's on your network as the prelude to an attack. So again, it's a trigger of a potential intruder. If this honeypot server starts sending packets out, that is packets have come in and then some reason they start sending out, then that means it's being compromised because it should not send out. It should be set up that this server doesn't send out, only if someone accesses it. And the only reason for someone to access it is if they're an intruder because normal users don't access it. So again, if we monitor the honeypot server, if we see packets coming into it, that's a trigger, someone's likely doing an attack on SIT. If we see packets going out of it, that's a trigger, someone's probably done an attack, they've compromised that honeypot server and again, that triggers, we've got an intruder. And if an intruder's within the network and on that honeypot server, then the people running the network can observe what they do to work out what are the flaws in our system. So let's say we run a honeypot server, so there's a set of servers here, there's a web server, DNS server, mail server and a honeypot server that looks like a server for registration, but it's not, it's a fake server. If packets get to this fake server and packets start going out, that suggests that it's been compromised and intruder has got in. And that tells us maybe there's a problem with our firewall because our firewall should have blocked that. So this is an indicator, well, we need to improve our firewall so that we block that. So maybe it indicates a flaw in the setup or the software on the firewall. So honeypots are used to keep people away from the real services and to learn about what intruders do. Oh, this is a better picture. Okay, our real servers, our internal network, several honeypots. One which is outside the firewall so that it's easy to access. So if someone accesses this one and then so they can compromise this, that suggests that for example the access control and the software on this server has flaws that someone can access unauthorized. But if someone can access this honeypot then it suggests there's a problem on this one and there's a problem with our firewall. Because the firewall, and again we haven't covered it yet, but a firewall should be set up to limit who can send packets into the network. They should only be able to send to the correct destinations. So if someone can access Honeypot 2, that's an indicator we've got a problem with our firewall here. Even worse if they access Honeypot 3, again a problem with a firewall because they can not only access publicly available computers, but internal computers as well. So it tells us about how good our network security is if someone accesses a honeypot. But that's all we want to say because I think you may hear about the terminology that's just a brief introduction. Intruders may be insiders or outsiders. It's harder to deal with insiders in many cases. But the intrusion detection systems can in some cases. The aim is to gain access to a computer system. Get access when you're not allowed access or to increase your privileges. That is to be able to do things that you're not authorized to do. How do you do that? Exploit flaws in software and flaws in people's behaviour. So some social engineering to get protected information. So we need intrusion detection. Some way to detect an intruder so that we can respond. And the concept is we need to be able to distinguish normal behaviour from the behaviour of an intruder and using profiles of the patterns and then look for something that's strange in what's happening, anomalies. We can do it on an individual host. So collect data on one host or even better, collect from multiple hosts. And we can collect data from network devices, packets going in. So intrusion detection software can in fact combine all of that. That is not just host-based or network-based, but a combination. Collect packets and collect activity on hosts. What are some issues? It's hard to achieve this trade-off of we want to make sure that we want a low number of false positives and low number of false negatives. So if there is a high false positive we effectively have a denial of service. If there's high false negatives that is if there's many intrusions that we don't detect then again our system is compromised. So dealing with that trade-off is difficult. And attackers once they know of how you're detecting them can change their behaviour to avoid that detection. We've talked about intrusion detection systems but how do we prevent intruders? So there's intrusion prevention systems which we're not covered. There's whole industries or companies that test networks. So penetration of networks. So people have a business of we will test the security of your network. We'll try and penetrate your network to see how good it is. Penetration testers. And if you do that without someone's permission it's usually illegal. Similar honeypots. The legality of honeypots is an issue. And of course in terms of algorithms how do you define normal and abnormal behaviour is an area to explore. But that's something for you to look at it if you're interested. Questions? To finish this topic. Any questions on intrusion detection? The concepts. Everything okay? You know how to detect intruders? No. But be aware of the different types. Those three different types. Be aware of what do we mean by anomaly and signatures and the way that we use profiles to detect. Another main concept here.