 Survive the two minutes I guess. Also as a courtesy to everyone in here please turn off your cell phone and paging devices. I hate it when those things ring. They're distracting. So please just if you can be courteous just turn them off. Thank you. Otherwise I'll have to get a cell phone jammer next year and I don't want to have to do that. Air Ideas. I have looked at no less than well let's look. There's network flight recorder. There's real secure. There's those horrible NT based ones from Raptor. I mean Raptor. Sorry. Accident technologies. They don't call them that for nothing. And they basically all have a problem. None of them are integrated. They yell at you and they scream and they don't do anything. And more often than that they, I regard an Ideas largely as a DOS against the operator. It's what you call a human denial of service. When you have a human being can only take in so much finite information. Well in Ideas I had the misfortune of looking at real secure and it has some nice features if you want to snoop people's IRC traffic. But the problem with it is it's noisy. In one day I got, just with a default set, I got 300 email messages. Do you know what I did? I created a filter that automatically sends them to the trash because I don't really care about all these things that aren't really happening or they're happening wrong or they're just dumb. It's like basically Ideas technology is like a virus scanner, but it only scans. It doesn't clean. It doesn't quarantine and it doesn't do anything. Who cares if you have a virus if you can't clean it? So anyways, this is why I, and a guy named Chris Cooth, a really, really, really sharp Canadian fellow who isn't here, he's the open BSD portion of this. I use open BSD. I am not a God in it so please forgive me if I might spell it wrong occasionally or you know I'm not a BSD God so please forgive me for that. Anyways, I'm going to begin now. A note of caution. Automated response systems can cause more problems than they solve. These things that I am presenting you are nothing more than guidelines. Denial of servicing yourself is very easy. Enemies more clever than yourself can make life most miserable. Nothing replaces vigilance, defense in depth, keeping the server's patch and being sneaky. Again, the reason I put this note of caution is because what I'm suggesting, I thought of it just today, was basically I'm giving the equivalent of SAMs. We now have radar, which is Ideas, but now you have SAMs which you can launch against incoming aircraft. But if suddenly your SAM thinks that your air traffic controller is a target, things are going to get in trouble. So this is just a note of caution that what I'm describing and the flexible response systems, which I will be describing in here, can cause more problems than they cure. So with that said, I'm going to continue. Don't say I didn't warn you. Deficiencies of typical Ideases. They do not adapt and consider multiple factors. They only respond with things like resets or blocks. They don't do anything. They just scream. And they do not automatically stop an intruder. One of the largest things I've heard here is automated attack. Well, why not automated defense? Or even better, automated defense. And if necessary, I don't advocate the use of offensive force, but flexible response I do advocate. And instead of just dropping a packet, what if suddenly I start logging, let the intruder think they've got in and reroute them dynamically to a honey pod. As they're attacking my IAS server. That's one kind of a dynamic response that you can do. Instead of just, oh, I'm reset packet. I mean, that just seems lame to me. I mean, with the AI technology that we have, with all the clever and really cool hacks I'm seeing, why can't we have clever responses? They're also expensive. An average IDS sensor will run you between $5,000 to $15,000 per sensor. Now, I don't mind making people like NFR rich. I don't have any problem against it. They have a reasonable project. At least it's not based on NT. But when I see that it's that much, and I say I want a place, I work in a trading environment, and we have, I think at last count, at least 14 different networks and on, like, 15 different vendors. And that's a lot of places where I'm going to place sensors. At $15,000 a sensor, we'll just use it. That's a lot of money. Now, people who are traders hate to spend money. They love spending it if there's equities and risk. You know, give me my money. But ask them to spend $10,000 on a firewall product, and they, well, what's my ROI? And then you say, well, what makes you feel safe? And then they laugh at you. So, this is kind of, basically for the cost of a sensor, $400 with a cellarine, cellarine processor with a, if you want to really be fancy by yourself a $500 Intel Ether Express Pro with a four ports, so you can monitor up to four ports per sensor now. If you don't have enough CPU, well, that's a different question. But it's definitely an option. The signatures, which are the heart of all the IDSes today, with exception of anomaly-based, are not updated fast enough. I think I may be wrong in this, but as I, from a year ago when I was dealing with ISS, they updated quarterly, maybe, maybe more than that now, but it was, it was roughly quarterly. NFRs, I think, were a little better monthly. And I can't, I don't really know how real secure does it. I haven't actually looked at theirs. But even if it's a month, it's too long. All of a sudden, all these clever people here come out with, say, 17 variants on a new exploit for God forbid, IIS. And, you know, Unicode or, you know, some kind of a thing, because Microsoft, when they patch things, they just patch the one thing, oh, it's a 256-byte off, but not a 257-byte offset. Because, you know, I mean, they don't patch very well. So, basically, because of the fact, and this is another limitation, is signature-based IDSes do not detect things that they don't have signatures for. So it's very nice to be able to have other people all over the net who are relatively intelligent writing signatures. You're also locked into a closed and expensive solution. If I, I mean, some of them do have languages, but like for instance, the NFR, the key exchange is absolutely a nightmare. They use 56-bit DES, and the keys never change ever. It's a shared secret between the client and the server. And it's not even public key. It's not even like 128 bit, because, well, we couldn't figure out how to get the license export or whatever. And I don't like that. I don't like being boxed in. I like having flexibility. I like being able to be sneaky. And a lot of times, it's very difficult to be sneaky with a lot of these commercial vendors. Now, they do have their place. I very much feel that if you're in a Fortune 500 or trading firm or financial firm like I am, you probably need both simply because the people upstairs really like to spend money in some senses, which is counteractive to what I said. But you have your one $15,000 sensor and your 30 Snort sensors. And so they kind of think that, oh, you're guarding the gates with a wheel and really when Snort's doing the work in the background. Not that they know that, of course. It's also harder to be clever and integrate data across multiple sources. All of the IDSs have woeful user interfaces. One of the gentlemen yesterday was talking about horrible user interfaces. Well, IDSs have everybody beat. I've never seen any of them with decent user interfaces, especially the alert screens. There's too many of them too quickly for a human to absorb. I mean, I can read like Moby Dick in a day. And I don't like to see 7,000 alerts paging by me at, you know, 2,400 bot even. It's too fast. So anyway, here's my philosophy for our IDS. Basically, an intrusion detection system should be able to intelligently respond to data from a variety of sources, hosts, networks, multiple points of view. In other words, for instance, from the point of view outside the firewall, point of view on the DMZ on the firewall, point of view on my people going out to the firewall. Because for those of you that NAT, you know that telling what traffic is coming out as it's knatted behind a firewall makes finding out who's really downloading all those Napster files very difficult. Also, there's hosts. Basically, the hosts are really important because network traffic by itself doesn't allow you to correlate. Whereas with host stuff, I'm talking things like you have an NT host running Tripwire with a syslog monitor with auditing, reporting to backlog or there's 101 of those things for NT. And this is the sneaky part and I don't really mentioned here. You actually construct because you have an IDS, you send the port 540 to nowhere. But of course, you reconstruct it on the IDS because you're listening to UDP port 540 bound for a non-existent IP address for any of you that want to be sneaky with syslog. So the attacker comes in, ha, ha, ha, he's stupid. He doesn't have any syslog server, but yes, he does. You just don't know he does. Anyways, routing and switching gear. Anyways, those are just some of the sources. Sources can even be, you know, I mean, you know, router switches, firewalls, I mean, and all kinds of other data sources. I'm trying to be all inclusive. Am I speaking loud enough? How is this? Okay, I'll speak loudly from now on. Continued on the philosophy. Air IDS should never denial of service and its own network. Denial of servicing is a very bad thing, especially when you're doing it to yourself. And IDS should be mostly open components. I said that because I don't really know what license I'm wanting to go with. GPL is really nice and then there's open BSD and there's all these silly licenses and I don't really know which one. But I want to be mostly open because that way people can work on it and realize that they're not going to make me rich. I mean, that's not the object of this project. The object of this project is to provide a community-based IDS that doesn't suck. I mean, that's basically what this whole... So anyways, that is the project goal. You can tweak it because it's open source. You've got the source code. You've got the license. And documentation is another thing. I'm going to make sure that the documentation is damn good because I hate it when you download these things and it says compile it this way and you do and it doesn't work. I mean, that is frustrating. If you write documents, write them correctly or don't write them and let them figure it out for themselves so they're not fooled into thinking that your documentation actually works. You can use it in ways the original authors never imagined. There are things that you can do with Snort and Pearl and PHP and SSH and all these open things and you can combine them in a system that is far greater than the original intent of any of their authors. I mean, using SSH to write dynamic firewall rules is not something I've heard of. I've heard of it being done on the host, but not being done from a central command processor, which I'll get into. And finally, it's cheap. I mean, not cheap in terms of labor, but even with these commercial IDSs, you're going to spend months tuning your network. I don't care what anybody says. You're going to have to know what your traffic is. You're going to sit down there with ethereal and TCP dump and you're going to have to look at your networks or you're going to have a useless IDS because you have to tune it. And everyone talks about that, but no one really stresses. Tuning will take you a quarter. I mean, if you're on a relatively large network monitoring anywhere from three to six network points, you're talking a lot of time. I did a complete network evaluation of just six network segments. It took me a month because you're going through raw packet data. You're looking at stuff. You're having to talk to programmers. Why are you using port 56789 through 60,000 for your application? I mean, and you have to, oh, well, I also use 12345 and 678910. I mean, there's these human factors that you have to throw into the mix. You just can't go to the protocol analyzer and say, we use all these ports and not know who they are and be able to intelligently look at what they are. So I do want to really, really, really stress the human factors involved in this system are probably the most important. Technologically, it's kind of a neat idea, but the human factors are the singularly most important because, like I said, if you've got developers working on programs and you don't know what they do and it's like, oh, my God, why are they opening 50,000 connections per second? Well, we're getting quotes from AT. I mean, there's those kinds of things that you have to know about your network. So anyways, I'm going to continue. And IDS should not annoy. When I get an alert from my IDS at 3 in the morning, it had better well be an alert. I don't want to get woken up at 3 in the morning to know that some idiot's trying to run the newest IIS exploit on me. I patched it, have a nice day. And IDS should be completely out of band so it is undetectable. Now, I will admit I have not researched into the implications of using a bridging sensor. I'm sure that they're detectable. I'm not saying they're not. But to your average attacker on the outside, the only way I know of, and please correct me, the only way I know of to detect a bridging sensor would be latency. Because it's just sending them along. I mean, because it's a layer two device. It's open BSD. So as far as I know, I actually did some measurements. And the only way I could tell by looking at the packet was that there was a tenth of a millisecond delay between the time that it got between the two interfaces. So it's kind of hard to detect. The management portion of it, I like to have out of band because a lot of times there are flaws. No matter what you do, you probably will make a mistake. So if the IDS's management console and all of the components are located on a completely out of band network, there is no way that anyone, or it's very difficult, for anyone to get in and hack your IDS and look at all the beautiful signatures. It's less convenient for the admins, but so what? They get off their butts and they walk to the server room or you patch it into your cubicle and do it that way. At least it's somewhat more secure. When they cut across? Well, that's the advantage of using bridging, because there's no IP. I mean, yes, there's certainly, there certainly are things they can do to make your active response act against you. That kind of attack is quite possible, but the sensor itself doesn't have an IP on either side. I mean, there are certainly certain kinds, you could probably try to denial of service it and whatnot, but there are other preventative measures that we can take to minimize and limit that. IDS should have at most one or two decision-making points. Now you do start running into a problem with this in terms of performance, if you're monitoring large amounts of networks using, essentially I'm advocating the use of a centralized SQL database on one computer with probably four or five processors on a really big network, simply because it's less places for things to go wrong. It's less places for attack. If you keep some of the componentry down, it's simplicity, so you want to keep it as simple as possible and yet at the same time maintain the flexible response. So it's a very important to have one or two decision-making points. And IDS should work in conjunction with other protection systems. Firewalls, the host themselves, and routers. They should be able to dynamically talk to these components and, if necessary, take action based on the input of multiple sources. And again, I'm trying to advocate as a union of all these technologies that everyone says, like one people say network-based, one people say host-based, I say both in conjunction because neither of them by themselves is sufficient. And IDS's evidence should be admissible in court. There are a lot of really neat technologies like worm drives and those, if you've ever had the cool those HP jukeboxes with the flip disks, and those are worms. They're on alterable media. Those packets have been written and logged to those things. And all the raw packets should be available. The problem with basically any of the sensors is you don't have the raw data. So somebody who is in court can say, well, your tool sucks. So you can say, okay, here's the raw data. And, you know, here's what the conclusions we can do and you can actually look at the raw data. So having a packet vault is a very important thing. And IDS should be OS agnostic. That means it doesn't matter what OS. It has to work on all of them. I mean, not necessarily the sensors or not necessarily the actual hardware that runs it because I just can't really advocate running most of these things on Windows. It's just too scary. I mean, it's, I just, I can't. I mean, I'm just, I was, I was trying to secure it. This is a brief aside. I was trying to secure an IIS server. I was reading, the stupid thing runs as a local system. There is nothing I can do. It runs as a local system. So if there's any new problems, it's got root. So just put a reverse proxy in front of it and be done with it. I mean, that's really the only way I know how to secure IIS. It's just put a squid proxy in front of it and just filter out Unicode and get rid of all those IIS things and just send it. And of course you get rid of no ops too that way. Well, you don't have a choice when you have a CIO and silly developers who, it's a reality of working in business is that I hate IIS and I managed to stop exchange. I'm quite proud. But I could not stop IIS because a lot of the kids coming out of college today dare I say use Microsoft Foundation classes and Visual Basic for their programming and lots of these people will be hired because A, they're cheap and B, the only thing they know is Microsoft. And so weaning those people from the the that process is kind of hard. So you'll, for any of you who doubt what I'm saying, unfortunately Microsoft is a necessary evil and it does keep us employed. Just think of it that way. Microsoft is so insecure that we will always have a job. Anyways. And yes, I know I just, I'm not being OS agnostic. Oh well. The IDS is, yes. And IDS should allow the analysis and analyst the flexibility of looking at past data. This is the snort portion of it. I haven't really talked, I'm not really going to get into the specifics of using snort and acid and all these other things. But those are some of the, all this is at this point, the only thing that's real is the flexible, is the ability to have a command processor respond to input from a snort sensor. And the concept of a bridging sensor. Most people just have sensors. This is why I have a sensor when you have bridging code. So not only is my sensor a sensor, it's a firewall. So I happen to be running checkpoint and there's the new horrible RDP attack. My sensor basically, I can put the firewall rule block all RDP from the outside. My checkpoint never sees it and I don't have to worry about patching and causing my network to crash. Because I'm sure you've all had upgrade fun anyway. Components of RDS. This is actually, can someone tell me in an hour, because I'm just going to kind of take a five minute break for everybody, because a lot of times you go on with these two hour presentations and you know you get kind of bored. So I'm going to take a five minute break after the hour mark, and then I will begin immediately after the five minute break though. So if you're thinking of leaving or whatever, you'll need to be back here then. Anyways, so the components of RDS. These stealth sensors, they are bridging firewalls with open BSD and to be correct, we use the, it's PF rather than the other one because of that licensing thing. I still haven't figured that out, but anyways, the centralized data gatherer, the sensors and host report to this. Typically this is going to be an industry standard database, whether it be my SQL or Postgres. Problem with my SQL is if you have a lot of data coming in, it doesn't do transaction queuing. And so you're just going to be in trouble, because my SQL will just choke. Because it does blocking IO when you start getting multiple data sources. So you've got 17 snort sensors reporting to one database, and all of a sudden, my SQL just can't handle it. So at this point, it's just a database, I'm not going to say which, but a database which can handle transaction queuing and can do threads, because you're going to have to do threads in order to keep up with the speed of the network. And I'm not even talking about gigabit. I mean, anyways, a historical comparison module. This is what I regarded as an anti-annoyance feature. If you have a site saying, well, let's not say China, because everybody said China today. Let's say Russia. You have all these annoying Russians that are probing your network and trying to hack you and get their elite ware sites up. Well, I see this and I say, you know, there's about five or six IPs and I verify them, because you really don't want to react based on historical stuff, because machines do exactly what you tell them, and if they see a particular host six times denial of service, well, we all know what spoofing is, don't we? Anyways, so the historical comparison module is more for a human to look at. Say, are these hosts repetitive offenders? Are they doing port scans? Are they doing what I consider to be hostile traffic? I'm very much an advocate of what I call geographic profiling. If a particular geography is causing you problems and you have no business have to be receiving web traffic. For instance, I work in a Chicago-based trading firm. There's no way that anyone from China should be looking at my website. I'm sorry. We were proprietary markets. There's no business reason for me to be even accepting any traffic, except maybe email, and even that questionable from these hostile sites. I recently saw a lot of the these HTTP scans from the from the Beijing and other areas, and I just got tired of it, so I just said 209.star.star.star. Block! And all my ports can't stop, so anyways. Yes, I know it's racial, but sorry. Anyways. The command rules processor for active filtering. This is probably the most complex part of the whole thing. It's a separate module which would have to use an expert-based system to make intelligent decisions. You just can't have something if I regular expression this signature do that. You can do that, but you're going to have some very dangerous rules if you do. So what I'm proposing, I don't have yet. I've got a couple people hopefully in the audience who are really good at expert system stuff. I need a database and what we can call a response library. We have not only a database of hostile actions, but a response library that can talk to the other modules so that it reacts intelligently to threats, intelligently and automatically. And with all the processor power that we have these days, why not have a really big expert system? I mean you, with a gigahertz panium costing less than $500, there's no excuse not to. So anyways, this command rules processor, what it does fundamentally is it takes the input, consults with the expert system, and decides what it should do. For instance, I am running a trading firm. I start seeing HTTP scans and hostile IS activity from site X. I'm running Tripwire at the same time. I guess we'll run it hourly because we can't run it too much because I'm just one binary because otherwise you run out of processors on poor little NT boxes. And basically all of a sudden, so I see this traffic and then on the host, the trading application binary is suddenly modified. Now this is probably a bad thing. It means that my trades are no longer trustworthy. So that warrants an immediate response. So it consults with it and it says, oh, this host, that problem, shut the connection. It doesn't matter where it's from. The reason why is because it is such a catastrophic condition, it is better to stop the trading than it is to go on trading with unknown data. And again, it depends on the site policy. This is where the human factors come in. You have to know what an unacceptable condition is and oh, be sure to translate that to your manager. Say, if this happens, we will lose connectivity. Or if this happens, this will happen. You have to be very clear in the policies and written procedures that you have in your organization. Again, if you're just doing it for yourself, don't worry. But if you're in a Fortune 100 or banking or clearing corporations like I've been in, if you suddenly stop service and you're clearing a billion dollars a day, you don't have a job very long. So you do have to bear these things in mind. The command processor essentially uses SSH to talk to the sensor on an out-of-band network. Now you say, why do you bother? Well, we all know about the problems with SSH. I mean, it's certainly better than Telnet. But even with version two, there are problems. If it's out of band, well, first of all, I've got an encrypted transmission, which is good. But now it's an out-of-band encrypted transmission. So then an attacker through the internet, I will say that, through the internet or an outside or even inside without physical access to my out-of-band network, cannot subvert the system. Now it is relying on physical security of the boxes. Obviously, you don't want to leave it out in your kiosk area. But anyways, what it does is it sends an SSH command, you know, pf, block in, source my web server, if it sees that event, and then send out a page. That is one example of a kind of response that the command processor could do. Another kind of response that you could do would be, say, I see, I just see suspicious web traffic, you know, like, why are they doing 100 million dollar trades when all we do are, you know, like, four lots and eight lots, you know, of trades. So basically it can look for, you know, you can actually have like a little processor. And then what you do is you start recording those packets to your worm drive or something there. And in case there's fraud, and we have SEC unfortunately, we're trading, so we have to worry about that, we can admit that, and if necessary, convict this person based on the packet vault. So you can do more intelligent, and you want the raw packet data again because it's the raw most form of the data. It's not been distilled, it's not been altered, and in a court of law, as far as I can understand, it's the raw data that's probably more important, although the distilled data is very important, but the raw data is a vital aspect of this. The anti-shoot ourselves in the foot module contains hosts not to block. For instance, it would contain our infrastructure servers, never block my DNS, never don't do dumb things like block my partners. If I start seeing hostile traffic from a partner, scream, but don't block them, and notify the partner, maybe send a message to the sysadmin at the remote site saying, by the way, it looks like I'm receiving port scans from your IP, can you check to make sure you haven't been hacked? And I wouldn't have to do anything, the whole system would do it for me, and that's what I'm talking about with flexible and intelligent response. It doesn't denial of service my partners, or my web server can talk to my DNS server, oh my god, port scan from DNS, block, end of game. I mean, you don't do DNS anymore, and anyways. Finally, the last one's kind of a pipe dream, I just threw this in, that did a heuristic or learning mode to make configuration easier. It'd be kind of nice if you could just have like you'd fill out these little questionnaires about your network, and it could come up with a fairly basic set of rules that would actually be applied, because most people are not going to have the expertise to go with TCP dump on their networks and do things. So kind of like those silly wizards you see that ask you things, and to kind of to some degree have a very limited response system. Like what is your web server, what is your DNS server, who are your partners, and if I see an attack from one of these, what do you want me to do? That kind of a heuristic, it's not really heuristic, but the learning mode I was thinking of, if every review is mason, it dynamically watches the traffic and then just automatically generates rules based on that. It's very dangerous, but very convenient. So it's just kind of it's just kind of a thought. I don't really know what to do with it, but anyways. This DELS sensor, it's a transparent, bridging approached, is used. This allows for undetectable monitoring. Well, relatively undetectable. I'll say that because I'm not an expert on bridging transparent firewalls, but it should be relatively undetectable. Traffic flows can be stopped because it's also a firewall redirected or even reflected back in an attacker. I don't know, I kind of like the new the new, this is a Linux plug. I kind of like the, we reflect attack, the mirror target on the new IP tables is kind of cool, but anyways. Finally, it makes it difficult to attack the IDS itself. It's bridging. I would love to see some attacks on bridging IDS's that would be very interesting paper. I haven't seen any to date. I've seen nothing that really, that talks about it other than denial of servicing them. Finally, it doesn't prevent fooling the filtering module into doing something bad or stupid. Again, if the rules are improperly made, an attacker can send packets at you knowing that you have the system in place and really make life miserable. The sensors have three interfaces. One for management and two for bridging. Ether Express and Nix. I've heard a lot of banter about which one's the best. I personally use three comms, but I have noticed high CPU utilization. You probably, the Ether Express, Chris basically recommended them. My friend who's a Cisco person said he saw like five times the throughput on the new ones. You don't go with the old ones, but the new ones. So anyways, and as you know, CPU utilization and bust mastering and all these other things are quite important on an IDS. Sensors should be based on a reliable and secure operating system. OpenBSD, as far as I know, is one of the more secure operating systems on the planet. I will preface that. Mainframes are more secure, but anyways, they are. It takes 30 minutes to enter a user. Anyways, 26 transaction codes before you can even log in. OpenBSD is relatively easy to set up due to its minimalist philosophy and secure design. For me to go through the package selection on Susie or any of the Linuxes, it takes the better part of an hour and a half to two hours because there's 4,000 packages in Susie alone. And I think in the New Mandrake there's like 3,500. And so, and the default package selections are stupid. So you have to go through every package and so anyways, BSD is just install it default, turn off the, you know, they for some reason they leave RPC open is turn off the RPC and it's pretty much done. OpenBSD, Snort, Acid and the database work. The rest is going to be a project. Anyways, let's continue. The, anyways, let me continue. For those of you that who are here, this is a theoretical talk. I do have some practical application, but unfortunately, I'm not a programmer. I'm okay at network stuff but I'm not an expert. And so what I'm trying to do is I'm trying to get together, like I said, a community-based project where we can get all these different people with different expertises for a non-profit because if it's a profit, it's just everyone becomes selfish and then suddenly it just doesn't work. So this is kind of an allotruistic vision of having a community-based intrusion detection system that kicks everybody else's ass. I mean that, that is really what the vision of this project is. And so at the end, there's all kinds of resources and I will continue with that. Yes. You, you, you redirect, you can rewrite packets though. You can rewrite the packets in transit between bridge one to bridge two. Anything you want. That's the whole point. Use dev random, I don't know. Oh, sorry. The question was is if you don't have a IP address, how do you rewrite packets? Headers. And I basically said, well, you rewrite the source address and destination address any way you want because it's PF. You know, it's, it's a low level. You've got raw sockets. That's the whole advantage of the OS. You write any source or whatever. I mean, write in Muser's own source address if you want to be nasty. Anyways, sensors, sensor descriptions. Sensors communicate relevant traffic via out of band network to reporting module. Sensors can receive commands via SSH version two. Version one is hopelessly flawed. I don't recommend using it unless you have no choice. It's better than Talnet but avoid one if you can. If you do use it, turn on compression. At least it makes finding the passwords a little harder. Sensors can dynamically block, allow, ignore, reflect, or redirect or log traffic. I didn't put that in there. Sensors can also send out syslog, basically the covert channel thing I talked about where you, you just have all your hosts on the DMZ basically sending to a mythical syslog server but you're actually recording the syslog traffic as it, as it comes in and reconstructing it based on that. It's, it's for the event logging in for some of the host based stuff that you need. Sensors will send data to an industry standard SQL server. And one thing I should put in there, sensors will send data in a standardized format. Or at least there'll be some kind of a, because it, I, originally was just going to use snort but then I thought well why don't we use all these other ideas as too? And so just basically somehow parse their alerts into a one to one equivalence so that you get some kind of a standardized database among all the different date of all the different vendors. I, obviously this is a huge task but it's a nice idea. Data will be encrypted. I know it's an out of band channel but a lot of people, well our band networks are paying in the ass. So, let us use Zebedee. It's a very nice blowfish encryption. It works on windows. It works on Unix. It stands for Z, Zlib compression blowfish encryption. And it's really fast and it's much faster than SSH. It supports keys between servers and so basically you send your database connection through an encrypted Zebedee tunnel to the sensor. So, you don't have to but for the truly paranoid it's there. Centralized information repository description. The host is hardened. Basically, you know, you've done the sensible things taking out unnecessary services, no compilers, etc. Runs a journaling file system. The nice thing about journaling file systems is if you turn off the power, you don't lose your database. Well, guess what we have? We have a very large database and they don't take kindly to power outages and to be honest, I really, the XT2 kind of scares me with databases because it's fast but it's just kind of squirrely at times. So, I personally use a Susie with Ryzer. Some people say it's unreliable. I've been running it for a year and a half now and haven't lost a single file on 100 gigabyte file system. So, it's pretty reasonable. It's on a UPS and obviously has the UPS connector connected to it. So, if you lose power, it shuts itself down gracefully. Now, this means that if you have a server, you make sure that you buy yourself a little 400, you know, APC 400 and it runs your server for two minutes. That's silly. Buy yourself a big APC and then your database can take as long as an hour to shut down if it's Oracle, God forbid. And so, you need to make sure that when you get a UPS, you get one that's big enough for the wattage. Look at the wattage or the ratings and do a test. You know, before you have all your important data on it, to unplug it and see how long it lasts under load. I mean, I know what the manufacturer's saying, Voltaurs say, but batteries go bad. You know, there's all kinds of all these other factors in them. It's regularly backed up. When I say it, the only thing I really refer to is the database. If you're using my SQL, it's really easy, shut down the database and tar up the directory. With other types of databases, it's a little more complicated. And to be honest, I'm not really a database guru, so I don't know. Figure it out. It's on an out of band network again. It doesn't have to be, but I recommend that it is just because of the fact that it's such vital information. And from a privacy standpoint, when you're talking about deploying a system like an IDS, especially in universities, or you're recording all the traffic. And not only that, but you have a permanent record of all the traffic. The privacy concerns of protecting that kind of information are huge. I mean, even if it's the company's data, the politics and the levels of problems that occur with this kind of information are huge. I've seen people fired. I've actually had to have people fired as a result of sensor traffic. I mean, and it's a really hard thing to do. I mean, someone you like and all of a sudden, you know, they're doing kidney porn and it's against the policy and have a nice day. You know, go feed your children. I mean, you know, it's pretty unpleasant. I mean, it's just, it's just unpleasant. And I just, like I said, so it has to be, I think, just because of the fact that it's repositorying all the information, it has to be on an out-of-band network. It doesn't have to be, but again, because of the ethical concerns in the kinds of data that we're collecting, I think it's in your best interest to do that. Currently, the only OS that does most of this out of the box is Susie Linux. Mandrake will do it. I don't know if there is a journaling file system for BSD out of the box. If there is, great. Slackware? Okay. Well, thank you. I haven't used Slackware since 92, so please excuse me. Yeah, and Dead Rat, I just, it's better in the 7.1, but it unfortunately, I just don't like the way they do things. It's, they don't use any kind of standards as they use that stupid check config thing to turn things on and off and just all their RCs are in the wrong places and I don't like figuring that out. So that's just me. Now you were saying, you're worried about a journaling file system, but you're recommending RAID 0. Well, that's why we have backups. RAID 0, I'm sure you're all Uber hackers, but just in case there aren't any, RAID 0 means you stripe the disk across two, so you have basically twice the speed, but half the reliability. Because if either of the disks go bad, you lose everything. But you have a really fast disk. For less than $400, I can have a 160 gigabyte disk, which will do 50 megs a second on an IDE channel. Mind you, that's IDE. That's not SCSI. We're not talking Ultra-166 or Sun hardware or 64-bit PCI. I mean, 50 megs a second. That's a lot of bandwidth. You're almost saturating the bus at that point. Basically, the central, as a host-based firewall, in the case of Linux, you would be using, I would recommend IP chains until IP table stabilizes, but IP tables is really nice because you could do MAC address checking. You do MAC address checking. You can do all kinds of flexible response. And basically, what it says is, even though you're an autoband network, only these hosts can connect to me. So even if they get physical access or tap into the line because you're not using fiber, because most of us can't afford the fiber cards to our desktop. Anyways, so basically a host-based firewall, it doesn't change. It's just, these things can connect to me on these ports and whatever. Sensors and syslog reconstruction occurs on this host. Basically, the syslog input is fed directly to this host and in parallel to the system, I just like to do a tail on the text file for any immediate responses that need, you know, right now, this is just one event that doesn't need to be correlated, that's catastrophic or needs to be responded to. It just gives you a really nice way to write a quick and dirty proscript to send an emergency rule out to a sensor firewall if you need to. Again, basically a talk to the central command processor stores all the data, syslog, IDS data, host alerts, and TCP dumps of all, I would say not all data, but all relevant data. Obviously, if you're not doing certain kinds of things, you don't need to monitor everything, but figure out what you need in your policy and dump that to raw packets. The historical comparison module, it talks to the centralized information repository, checks to make sure that all the data coming forward, it looks for repeat offenders, and it checks for port scan repetitions from hosts. It's largely from nuisance users or hosts. It can also be used to detect stealth port scans. Again, imagine a database that you never erase. I mean, suddenly you have every person who's ever scanned you since like last year. I mean, that's, that's very powerful, especially if you start getting the data mining. The command rules processor. Again, this is the heart of the IDS. It dynamically adjusts the rules based on attacks in real time. It doesn't do dumb things because of the anti-shoot ourselves in the foot module. It sends rule changes via an encrypted channel to the sensor. It constantly communicates with the centralized information repository, and it can interact with firewalls. This last part is, is if a lot of the commercial firewalls checkpoint, sunscreen, ANS interlock, if anyone has used that firewall. It's like we in the past anyways. Basically have scripts that you can dynamically add rules. So you can actually, on your main firewall, do things. And again, it's just thrown in as kind of a, it's, it's an integration feature that you can actually do with your firewall. Of course, it requires command line facilities on the firewall to work. Command rule processor continued. It is able to react to network event and host events. Compares and correlates the results from multiple sensors to see if sophisticated attack is taking place, and it contains a flexible response. In other words, if certain conditions are critical, cut off all access, if only non-critical, perhaps, page or log all of the suspicious packets from the hosts. How am I doing for time? Okay. Thank you. The, again, the command rule processor, it can block problematic hosts via historical module. Basically, these are ones that are not in the anti-shoot ourselves in the foot module. So I will not be blocking my DNS server. Can actually tell what is happening on the host itself. I like Tripwire because combined with a lot of other techniques, it can, it can tell you if a file is changed. Now the problem with Tripwire is if an attacker gets in and modifies or gets rid of the Tripwire process, obviously you're out of luck. But a lot of times if you're sneaky and rename the Tripwire executable write.exe, I mean, a lot of people probably are not going to figure out that you have Tripwire. I mean, and you can actually move things to non-default locations. Now, granted it's security through obscurity, but everything that you can do to slow down your attacker gives you more time to defend. And that's what they'll game is, is basically is to increase the amount of expense, time and effort to get into your systems. The, can actually, and again, Unix Syslog, I kind of like Syslog. A lot of people say it's bad. It's so universal. And as long as you do it out of band, people aren't going to denial of service you. It's harder anyway. I mean, they can't like spoof a host and then go in now with the thing that I described, someone could conceivably send out bogus UDP streams from a host. You can use things like Syslog next generation, but I find that it's kind of buggy and like it has memory leaks and it's gotten better. You know, the cryptographic check sums are very helpful, but again, if they've compromised your host, they probably have access to your keys anyway. So why worry? Custom alerts. Again, there's different kinds of ways to be alerted. There's like Snort has the SMB server message box for your Windows users. There's pagers. There's, you know, there's all kinds of different ways. This is kind of an interesting thing. I just thought of it's kind of a random thought, but instead of representing a host as something impersonal, like I have a picture of something like a person and say that someone denial of service is your web server. All of a sudden, like a bullet hole appears in the head. I mean, it would be, it would be kind of a very graphical way to show a manager what's going on because managers don't understand this. They don't. So anyways, it's the use of a, of a custom alert system such as that. The command rules processor can take corrective action based upon a host as well as network inputs. On the open source network components that I'm using today, Snort, SSH, Zebedee, Pearl, or whatever scripting language of your choice, for those who have other ones. Did you want to take a break now or do you want to keep going? Okay, we'll break for five minutes then. It's already posted. It's already posted. Are you going to get it? Yeah, at the end. Yes. Yeah. Basically, the next module is the anti-shoot ourselves in the foot module. Contains lists of hosts that should never be blocked. Contains trust relationships. I don't like trust relationships, but they're a fact of life, unfortunately. So if we have trusted partners, we at least don't denial of service them or block them. Contains knowledge about our network, what services should