 Okay, I'll start now then. I'm Ian Peters, I'm going to be talking about Vubicon, an extensible IDF. First about a bit about me, and a look at what we're going to be doing. I until very recently was studying in London at Imperial College, now graduated. And this project was my final year degree project. It sort of started with Thomas Munn's presentation in Defcon 9, in which he mentioned the idea of Active IDS. Basically an IDS which can route an integration of a firewall and an IDS. Now some of the problems I came across were, well, academia. They don't seem to like products. They like algorithms, that's cool, but actually trying to even let them do this was a bit of an ask. Then about seven hours before I was due to present it, I had a head crash. All my backups were screwed, so that was a bit of an issue. Tested backups, if there's one thing you're going to learn today. So I rewrote it, and this presentation is primarily on version 2.0, as it were. First, a very bit, a little bit of background. Most of you can probably sleep through this bit. Firewalls, well we all know what it does. Simple example, allow stuff house and replies, but stop the hackers coming in. Stateless and stateful, you all know this. A couple of shortcomings though. You can't understand upper level traffic data, things like HTTP. You can't filter on that most of the time. And similarly, you have issues with encrypted or tunnel traffic. Some of that I'm trying to address. Bit of anproxies, that's Firewalls which can handle it. They do a lot of them just via madden middle type effort. Now there's no such thing as 100% secure network, so we want to know when there's problems, what's going in. And I like people say lots of the hackers are on the inside. I guess you guys don't know that. So you want to know about what's going on. So use an intrusion detection which gives you the information, which allows a human to look into it, respond, whatever. Host based running on the server, network based looking at network traffic. This is primarily a network based solution that I'm dealing with. A couple of patterns, a couple of different types and techniques mentioned in the previous, so I'll miss that. Two things which we've got to remember, false positives and false negatives. They do happen and there's nothing we can do with it. RDS is currently can't stop and attack. That's a big problem with it. We'll be talking about it six hours later, but by then your web service down, half your systems have been routed, so on and so forth. A lot of the traditional signature based stuff can't detect a whole new attack. Now if you're looking for a buffer overflow, somebody changes the shell code or the specific bit of the signature, you're screwed. And as mentioned, you can't have no false positives and negatives. So, one of the solutions, integrate a firewall and an IDS to our firewall, start filtering off IDS results. Packet comes in, you run your signature analysis and says, oh, buffer overflow, so drop it or reuse it or whatever. By doing this, it means humans aren't involved, so it can happen straight away. And additionally, you can have some quite funky functionality. Hopefully, I'll cover that in a minute. Now ways you can integrate, 14 control packets, like TCP resets. Now Snor do that but does that, quite a few IDSs are doing that. You can do that based on the log outputs of the IDS, using Swatch, Syslog, whatever. You can wrap firewall outputs around IDS code. For example, Hogwash with Snor basically does that. You can insert IDS facilities into a firewall. For example, Netfilter, you can take packets off into user space, do your IDS stuff there, return it back up to Netfilter ID tables, and it can then deal with the dropping forwarding. Or, and this is what I did, fully integrate a bespoke solution. Cynnydd stryd diolch, well, as I said, academia don't seem to be interested in products, especially not in the UK. That's a real shortfall in that part, I think. Hogwash already mentioned, a few others. Recently, Git's functionality has been added by several vendors. I started this project about October last year. A lot has changed since then, and that's one of the things I've really learned. IDS is a fast-moving area. Now anyway, originally it was all firewalls. Problems with integration, false positives. You don't want to go dropping everything from your upstream user. That would be a bad thing. Don't know how to serve the same sort of thing, or just hitting it with so much traffic, because don't forget, IDS stuff takes a lot of processing power. And finally, processing power and bandwidth. So, what am I going to do? What have I done? The design was very modular, or supposed to be, because the idea was things change. We get new protocols all the time. We need to be able to change that, modify quickly. How hard is it to add IPX support to snort? I've looked at it, and it looks quite hard. I don't know snort that well on the inside. I'm sure some of you will correct me on that. I always start with an example of where this would be useful, and that helps me design it. Basic firewall-type functionality. But how about instead of blocking, just blocking, straight away based on, say, source IP address, or port, or whatever, how about we run the IDS on the input? Say it contains a buffer overflow, which we know from one of the different analyses, which you could do, for example, the pattern matching, but you could easily do statistical, you could do protocol anomaly, so on and so forth. If there's a buffer overflow, we reroute it transparently to a honey net. Rubycon can map bridging, so the only thing which changes is delay time or something. The hacker could then use your box to attack someone else, which you might get sued for. How about we add the SD outbound as well? If it contains an attack, which we recognise, how about we then modify the packet to kill that attack? For example, stand buffer overflow, your payload is shellcoded and that. How about just changing the payload just to nulls? It means that the attacker just thinks, oh, crap, it didn't work, unless they're trying to hack their own box to test whether you've got Rubycon in place. There's nothing I can do about that. But they might just think, oh, it didn't work. Next, meanwhile, you're getting information on who they're attacking and what they're attacking with, and similarly coming back. So from that, a few requirements. It must itself be secure. You don't want your box, your Rubycon box, getting hacked, and then everything falls apart at that point. It must be stable, otherwise it will fail safe, but if you're on a really high bandwidth, important network, you don't want it to fail and block everything. Well, you don't want it to fail, full stop. And it must be able to handle the load. So a quick high level design, basically on the left here, you've got all the different types of plug-in currently supported. Now, these are all connected via the central loop process, and on the right is the policy subsystem. That's actually run as a separate thread for reasons I'll go into in a bit. Each of the dark, black lines can be thought of as an interface between each part. Interfaces need APIs or similar to be designed. So the core loops contains a packet structure which just wraps the packet and all the other data that's attached to it. One of those is a link list of protocols. A protocol is basically the decoded protocol header or whatever with a name. For example, Ethernet. I will point to the start of the Ethernet header, the length of the Ethernet header and so on, and the payload. Normally that's just a pointer into the actual packet itself. I'll advise you copy and stuff, which is a bad thing. However, you might want to do RDS on decrypted SSL traffic. Now, just a quick digression here about SSL, I didn't know about this, maybe that's just me, but SSL works, you know, client server, exchange a key, mess around with it a bit, and then use that from now on. A couple of different methods for that, RSA, where the client encrypts the session key with the service public, sends it off to the server, server decrypts, and then that sort of, or Diffie Helman, which uses combining logs. I won't go into that. Now, if RSA is used, which you can normally set up, and the RDS has a copy of the service public private key pair, and what you can do is use, on your RDS, you can use a combination of a hacked up version of SSL done, an open SSL, to actually decrypt the traffic as it's going through, not performing the man in middle, anything like that. So that means that, say for example, one thing which has been done a lot at the moment is hiding web attacks using SSL. Well, this would totally circumvent that. A quick look at the plug-ins. Everything has the plug-in interface, basically registration, initialisation, and cleaning up at the end of the day. Full types of plug-in, input, fully interface input, outputs, obvious, analysis, and protocol. Rubicon, by default, does not have any support for any group of protocols. Instead, everything, Ethernet, IP, ATM, IPX, Serenet, whatever, has a protocol plug-in. Well, a few different things. Decode, basically, is the one which produces the protocol link list. Test is used for special tests, for example, to check whether checksums are valid. Print, for printing out, obviously, and make tests, whatever. Policy interface. On the internal, you've got a mutex share pointer for the threads, because compiling the policy from an intermediate language to the level representation is potentially processor intensive, and you don't want that to affect your system, so hence a separate thread. On the external side, well, I haven't really written much that way, so I can't be arsed. High-level policy hasn't been implemented. I'm not interested in doing it. If anybody does, get in touch. Intermediate-level is XML, but it's used basically to get around, well, some of the problems which occur with lower-level, you know, binary-type things. And the low-level is what's actually on the box, which I'll get into now. Intermediate, byte-ordering, et cetera, you don't have to worry about. It's human-readable and writable, which is good, because I haven't written a high-level policy, so I need to write the intermediate level by hand. I certainly don't want to be writing the link list by hand. And we want fast translation, so there's a one-to-one mapping, realistically, between the XML structure and the low-level structure. An example, XML. The low-level is a link list, which I'm going to show you in a minute. Basically, a very large tree, which you process, descends down and potentially back it up, loads of tests, leaves of the outputs or whatever. For example, that's the generic link list, so you'll start at the policy head, go down to the first relevant protocol that you've decoded, and say, well, say, Ethernet or whatever, go along the matches, looking for the match on source address, that sort of thing. And if a match is made, then it descends down the output chain, so test results are on and so forth. A more accurate example, following Mr Wong, you go down, you hit Ethernet, so your source address is that one. Then you won't go down that drop. EOF is basically, well, it's end of processing, so it should be EOP. Then you go back up down into IP and through. Quick look at the plugins which have sort of been written, because it's version two, they haven't totally been written. I've just been moving house, so that wiped out my internet connection for two weeks. It's so hard to live without the internet these days. LibPcap, standard, everyone knows that. LibIPQ, that's for user space handling of packets from Netfilter, IP tables. So say you want to just phase your product in on a live network, but you could just have the odd packet, or the odd set of rules, sending it into Rubicon from your Netfilter, so your network wouldn't really be affected if Rubicon screws up. One thing to notice is about LibIPQ is it exports both the input and output plug-in interfaces, input to get the packet, output to tell LibIPQ or Netfilter what to do with it. Protocol, I've mentioned. Analysis, basically I pulled out the snort's matching. It was an old version of snort. I think they've updated it recently. Basically that gets initialised. In the XML policy you can actually include snort rules. So that gives some cross-platform compatibility I was looking for. It gets initialised with a load of rules and names. So for example you could use IIS and all the rules that you want to do IIS, and then any traffic sent to your web server. I'm not a Microsoft fan by the way. I'm just using Windows for the hell of it. You could just run the IIS rules against the packet rather than having to run everything. Another nice one, personally I think, counter. So you can increment, decrement, set whatever values for as many user defined variables as you want. And then you can test them or test them. So say for example you only want so many FTP connections per hour. I'm planning to modify counter so that you can do stuff on time as well. So reset every hour. Defrag, well what can be said is defragmentation. Output, you've got the network output, same as any firewall, and you've got your log output, same as any IDS. The network, all provided by libnet, it doesn't do masquerading yet but you can do drop except reject. Netmandering is the term I use for the modification of packets in rhyme. You can modify any packet you want and any header or payload is specifiable. You can't resize though. This isn't strictly true. You can't resize on anything which uses sequence numbering. If it's not using sequence numbering then you've got nothing to worry about and you can resize your packet. But currently it just doesn't allow you to resize or it allows you to do is just replace. Logging, well all the standard stuff. I have a quick look at IDXP which is an ID having F. They're cross-platform ideas for common logging formats or whatever. It doesn't really work yet. That's not my fault, that's theirs. Conclusions, God, I'm racing through this. We'll always be on time. Because of the code review there aren't any benchmarks available yet but the old version of code basically I only had a crap network at home so I just banged away with a full every single snort rule I could find and it didn't drop anything at 8 megabits and that was logging to file. Just to make sure that everything was working correctly I used both Rubicon and Snort with identical rules to pass the Sands 2000 log. Rubicon a bit slower but the output was identical so I'm not having screwed up too much there. Problems and limitations, well because of the way I've written it access internal traffic is a real issue. Trying to say when you're referring to IP IP source address, which IP source address? The one at the bottom or the one being tunneled? A bug's obviously need loads of work. The big thing and this is one of the reasons I'm here is there needs to be uptake. You need people testing any product. Every year at DEFCON products are talked about some of them are quite good, some of them less so. I'll leave you to decide which this is. The fact of the matter is if no one uses it then good or bad it'll just fall flat on its face. There have been some successes. It is very modular. It took me about two hours to write the TCP plug-in. Most of that is copy and pasting for printing it and that sort of thing. It's very fast and very easy. It does do everything I was wanting to. At the time it was unique functionality, the mangling. I believe hogwash. I don't know if anybody can agree or disagree. Hogwash apparently can do this. Can you mangle packets now? I think that was a yes. So it wasn't that unique but still. In theory using automaking LibTool on that it's relatively cross-platform although I haven't tested it that much. As I said it is very easy to develop for. Further work, as you can see, loads of different possibilities. This doesn't have to just be a security tool. This is primarily for non-production use or maybe it will scale up. Say for example you want to add quality of service to your network or load balancing. But because of the whole modular design then you can do that as well. Few conclusions on intrusion detection systems that I've come across or made in my time. That we have to reduce false positives. We have to come up with new ways to do that. Now academia is working on it. We are coming up with algorithms. I'm not that impressed most of the time but I don't work that close in the area. We also need to pick up new attacks. Now false positives picking up new attacks. They're working against each other here. We're starting to distribute analysis in that. I think three commons produce mix with firewall capabilities. Apparently they can do IDS stuff in as well. I hope today that that's quite crap though. That's a correlation of the previous presentation actually covered that. Standardisation. How are we supposed to communicate between different intrusion sections, firewall, etc. If there's no standardisation. There's so many vendors in the area now and each of them seem to want to follow a Microsoft route of let's follow the RFC but change it. So we need to sort that out and we're going to have to have more host space due to encryption. I can handle SSL maybe sometimes. Finally, I'm not sure that's snort but I know certain of the IDSs out there have themselves got security flaws and exploited them off and just because you've not got a portal open doesn't mean you can't be broken into. That's basically it. It was a very quick run-through. Hopefully there'll be questions otherwise you've got enough time to get a drink. Yes. Sorry I couldn't quite catch that. Do you want to run here and grab the mic from it? Sorry am I hearing shot after a flight yesterday? Any plans to move it over to packet filter or IPF on FreeBSD and OpenBSD? Not especially. Most of the effort and plans at the moment are basically on just expanding what's here. Partly because I haven't got that much BSD experience I'm primarily a sort of learned person. However, if anyone's interested then I would definitely be interested in doing that. Anyone else? Louise. The question was, or comment, basically to do with defragmentation. What do we defragment? If we defrag everything then we're going to have problems with latency. If we don't then by the time we see stuff it's already gone through. The answer is, that was the question pretty much here, the answer is it's a configuration issue surely. You defrag stuff which you don't think is an issue and you are frags through otherwise. This is, ordinarily I'd say defrag everything. This isn't set for production sort of quality code. So the latency introduced shouldn't be too much of an issue although that's a potential denial of service problem. But that's the same with anything. There's realistically nothing you can do to get around that. One thing that just occurred to me a while back you could do protocol and packet shaping as it comes through. For example, fragments, common way to get around intrusion section systems, overlapping fragments. What we could do is remove that overlap because overlapping fragments, it's breaking the RFCs anyway. So by removing that overlap and resizing one or the other and that again is a configuration issue then you can get rid of that particular problem. That's it. Right, again that's currently although I'm thinking about involving some sort of stop list. Sorry, the question was how does Rubicon handle like spoof attacks and things like that. Again, it's a configuration issue. I'm continuing looking into stop lists so do not ever drop these IP addresses. However, if you think about it that you can involve that in your rules. So that's more of a configuration issue than anything. Okay, thank you for listening and go and get a drink.