 So my name is Matt and my handle is spelled S-Y-K-E and I'm a member of New Hack City which is a hacker collective in San Francisco and J-Roo which is right here, he's also going to attempt to speak hopefully with a video projector in place of some kind. What else can I say? So I worked for two years for a commercial vendor of security software. It doesn't really matter which one and I prefer not to say because I hate to think that people think their products are better because of my knowledge anyway. We have t-shirts for sale out there and I'm going to be giving out t-shirts. New Hack has already sold out before anyone even knew who they really were. Before we just jump the gun, I think the inspiration was AdStake selling out so fast, or Roth selling out to AdStake so fast. So here's the basic deal is that there's four major areas I'm going to cover and I posted an outline to, Jeff posted my outline to the DefCon web page and I've changed it a little bit since then because I thought it would be a little bit more interesting to look at things a bit from a bit more holistic perspective. So I'm going to cover four areas and those four areas are what user expectations of IDS's and firewalls are. Like why do people buy these things in the first place? And then the second thing is how to test for those expectations to make sure that people are getting what they want hypothetically. And then the third section is common coding problems that sort of come up, that sort of bubble to the surface when you actually start doing this kind of testing, testing. And then the fourth thing is what designers and people who are writing these things like right now, like from scratch, can do to avoid a lot of the mistakes that I have seen in the last couple years, code-wise and design-wise. So the first thing is users. Why do people buy IDS's and firewalls? And like why is it such a popular market right now? Or like the last year, it's up to a couple billion dollars or something? It's like crazy that people are actually paying money for this stuff. Well, I think the main reason is people basically don't care. Users really don't care if a proxy firewall or a packet filtering-based firewall or a hybrid firewall is going to make them more safe. Or if a network-based IDS or host-based IDS is going to make them more safe. All they care about is they have a topology and an infrastructure. They don't want to change, and they will put in whatever is going to fit in what they have right now. Whatever is the easiest thing to implement is what they're going to end up implementing. And that's basically what it comes down to. So this talk has nothing to do with arguing over which is better or any of this complete nonsense. So because you have to make both because people want both or need both or have been convinced that they want or need both kinds in either the firewall or the IDS space. So yeah, people just want to deploy and not have to deal with anything. I think most people actually are aware that IDSes don't make you safe. I'm pretty confident of this. I know a lot of people think a lot of, I don't know, hacksawers and security consultants over, think that like general, I don't know if you call them consumers or not, think that IDS is making you more safe somehow. IDSes just give you time to react, and that's all that they do. And I think that most people are aware of this. I think that most people don't think that IDSes are going to magically stop you from being attacked. So I don't think that there's a misperception there. Firewalls, this is kind of weird because real purists will say, you know, firewalls and IDSes are fluff and crap, and they just need to fix the real problems and like make the code in the OSes better and in the FTP dams and whatever. That's not really practical. So from a certain standpoint, firewalls do help you reduce and manage risk. If the firewalls are implemented properly in both code and topology, if the coding is solid, like they've done everything properly, and you've deployed it properly in your infrastructure, and you've configured it properly and everything, hypothetically speaking, it will reduce the ways people can get in, hypothetically. Although we've all seen like the hacking exposings that Ernst and Young and those guys did were like they don't need, all they need is port 80, and then they bounce in and do a port 139 redirect and using netcat and like all kinds of crazy shit. But hypothetically, from a certain perspective, it does reduce risk, and so vendors have convinced people, of course, that since some bullshit percent number, let's say 80% of all intrusions come internally, and your firewalls are going to protect you from those, you need to have an IDS anyway. So you need to have your IDS to protect you from the outside problems, and you need an IDS to protect you from the problems that the firewall can't block or use, can't deal with it or whatever. OK. So people expect firewalls to keep packets out, and people expect IDSes to tell them when they're being attacked with whatever signatures. Oh my god, is that a video projector? Be still in my heart. So this is what people are expecting. So section two, how do you test for these expectations? I have three favorite tools, basically. They are Nmap, Whisker, and ISIC. And ISIC is a suite of utilities. And I think Mike Franson, who ISIC is here, he's right there. This guy is the bomb shit right here. This guy's tools have helped me find so many bugs. We released a new hack, released a NetBSD advisory two months ago or something. Yes, you do get a t-shirt. Promise. Here's a t-shirt. Oh, by the way, here's what they look like. ASCII art. Let me see if I can look at the bottom. Let me see if I can throw it that far, eh? Oh, pretty close. There you go. Yeah, so Nmap, Whisker, and ISIC. Basically, here's the deal. You can't just download these tools and start using them and think you're going to find shit. Please understand what these tools are doing. Even if you can't read code, read the docs and figure it out. Like, I don't think I'm that smart. And yet, I can sort of know how this stuff works. And if you actually read the docs and understand how works, you'll understand that when you're using ISIC or ISIC that you should disconnect yourself from public networks so that you don't like DOS every box on the subnet plus, which people still do. Yes? ISIC, oh, I'm sorry. It's IP Stack Integrity Checker. And it's actually a suite of utilities. And I'm going to go through each of them individually and how they should be used. And I'll say to URLs at the end, it's really pathetic I have all these URLs memorized. So, I understand the tools. OK, what the fuck is that? That's odd. OK, what do the tools do? I'm glad you asked. I think everyone knows what NMAP is. I think it's pretty ridiculous how popular NMAP is and how much everyone uses it for everything. How every time you go on an ISC channel, someone says, you're running NETBSD. And it's like, well, that's great. Thanks for telling me something I didn't know. So NMAP is really good, not as a port scan or anything like that. NMAP is really cool for testing a couple of things in firewalls and IDSes. In state-based packet filtering firewalls and NAT implementations, and even IP sect tunnel implementations, NMAP is really, it's so simple. It's really elegant. Just like doing a port scan through a trusted tunnel, like a thing scan or something, and then watch the IP-seq implementation of them and take a shit. All these tools, by the way, the focus is firewalls and IDSes, but testing IP-seq tunnels, like if you go to your VPN bake-offs in your area or whatever, take these tools with you. Whisker, not so much, but Icic especially, holy shit. Icic found so many things, so many bugs and IP-seq implementations. It's not even funny. So anyway, NMAP. So just doing a simple port scan with NMAP will usually suffice. So because I don't have my slides and my pretty pictures, I'm going to use my hands. So I have an untrusted network, the Big Bet internet over here. I have my firewall IDS, whatever the fuck. And then I have my trusted machines that are protected by the firewall and whatever else. So the interesting thing to do is to run an NMAP scan through all 65,535 ports. Just to really give the state table, shall I explain this? So in an IDS, when you make a connection, when you send a SAM like, there's a state table structure. Generally, I don't know if everyone's implemented this the same way, but I don't know how else you do it. There's a state table structure. Then it adds your source and the destination like this. Yes? Whoa! Oh my goodness. All right. Where is that at? Right here? Awesome. Oh. What? Do you actually expect me to use Star Office? Whatever. In an introduction, run-down user expectations testing for most users are aware, most have both anyway in NMAP and in NMAP Whisker. Oh, I'm sorry. So I'll start here. So here's a so in NMAP Whisker ICIC, IPC intern checker. Don't just use these tools blindly. Understand how the fuck they work. Otherwise, your testing means dick and you post a security focus like an idiot. I post a bug check like an idiot. I ran NMAP a thousand times and then when I came back in the morning, the box crashed. That doesn't help anybody. It really doesn't. The vendor's like, well, where's your configuration? It's like, I wiped the box already. Like, you really aren't helping anybody trying to solve the problem that you've found. Configuration can make a difference, especially on fireballs. Like, let's say that you do an NMAP test or you run TCP sick, route it through the firewall, and you have one deny rule. I've seen situations where you add an allow rule or you add an absorb rule or whatever or you add two deny rules or something and then the machine will crash or then it will leak packets or what have you. So if you're really interested in finding problems and stuff, just be really diligent if you have the time and the resources and whatever. Oh yeah, so here's the network idea. Untrusted, you have your target machine, which is your firewall, and then you have your trusted network. And so usually in my examples I say go from untrusted to trusted, because that's what usually what people do when they're doing penetration testing. But if you're looking for crashes or packet leakage or whatever, you can find it the other way as well. And people usually miss this from a couple of bugs in the software I was testing by just going the other way around, especially with NAT. If you have a NAT at firewall or IP masqueraded or whatever links people call it, and you send like from trusted to untrusted or the other way around, that gives the code that maintains the state tables for NAT a really good workout. Give an example of a bug that I found that worked like that. When you sent thin packets through NAT from trusted to untrusted, the firewall made an entry in the state table for that thin and then never removed it ever. So if you did a fin scan or flooded it with fins or what have you with like from random source addresses, basically you're testing to see if there's any unchecked mallets. And if there's an unchecked mallet and these other stuff is in ring zero, you've got a blue screen or an oops or whatever links cause it or a kernel panic or what have you. Put your firewall down. Huh? Put your firewall down. Put your firewall as well. Put your firewall down. It doesn't matter if it's been fixed. Next, right. OK, so end map. Yeah, state table code and packet filter and NAT implementations from untrusted, from an untrusted machine, net map, end map, thin scan, ports one through 65, 535. A really cool thing to do by the way that end map will let you do is send stuff from port zero through a firewall. That gets interesting results sometimes. Same way with an IPsec tunnel, et cetera, et cetera. And so what you can see when you do this, if you know how to look, by the way, if anyone knows how to see non-paged kernel memory usage in Linux, could you please tell me programmatically or otherwise because I couldn't find any information on the net at all on how to do it. But if you were able to do that, like you are on NT in about one second, what you'd see is that when you do that, you see non-paged kernel memory increase because what's happening is the state table is growing because you're doing a lot of connections. And so like I said, what this test for is one unchecked malloc. Like most operating systems impose a hard limit on non-paged kernel memory, like 16 meg or 20 meg or however much it is. It depends on how much physical RAM you have. And for you non-OS architecture people, a non-paged kernel memory is memory only accessible to the kernel that never gets paged out, ever. Because for whatever reason, the data structure that's holding it couldn't handle a virtual memory fault or a page fault of any kind. And state tables happen to fall into this sort of category. And so if you make the state table grow large enough, eventually it's going to hit that hard limit of non-paged kernel memory. The OS is going to say sorry. And I've seen it time and time and time again where I don't know why, but people don't check the return values of sys calls, not just malloc, although malloc is like the most common, all the other malloc calls as well. There's been a couple vulnerabilities now like people weren't checking their return of set GID. Like if that failed and like defaulted to zero or something, I think it was a weird or something, it's the echo pic show. So that's basically what you're testing. And if you're looking for stuff like that, like you're looking for DOSes where they run out of memory and then they fuck up because they didn't check in malloc somewhere, both in Linux and in NT and probably VSD as well, you can limit the amount of physical memory the OS will use. That will help you greatly in finding these bugs faster. Because if you do this 128 meg machine, you really have to beat the living fuck out of it in order to get it to crash or do whatever you're trying to get it to do. And so if you just kind of lower it just a little bit, you'll hit these conditions a lot easier. Wait, I don't want to go to the whisker. That's a five. Go back to me. There we go. Different scan types, like I said, fin packet and a certain implementation of a Safefield packet filter firewall didn't remove fins. If you just sent a fin, it was really odd. I don't know how the thing ever worked. It probably didn't ever work for it. Acts, gants, et cetera, et cetera. So tiny IP frags. This used to be an interesting way to leak packets through firewalls and to make firewalls crash. Because for a Safefield packet filter based firewall, god damn it, it's hot. Wow. For a Safefield packet filter to do its job properly, if I've blocked port 80, I'm assuming I'm going to assume some knowledge of TCP-IP here. If I block port 80 and the TCP header is split up across multiple IP packets. So when I get my first IP packet on the firewall and I'm analyzing it and I'm looking at it, and I'll say, OK, is this allowed on the ports that I'm allowing to pass through me? Well, I can't see the port because the port information in the TCP header is in the next IP fragment. You can do one of two things if you're an implementer. You can either reassemble it to get the full TCP header, in which case you're opening yourself to DOS with memory usage, with people sending a whole lot of frags, and you're holding them, waiting for the next fragment to come so you can get the full header. Or you can just drop them. I'd recommend dropping them because the likelihood that an MTU is that small that a TCP header would be split across IP packets is very, very, very, very, very unlikely. In fact, if anyone can tell me a configuration in which that would really happen, I'd really like to hear it. So if you're an implementer, drop tiny IP frags. Don't even fuck with them. It's not even worth any trouble because it doesn't happen in real life. If someone sends you tiny IP frags, they're fucking with you, period. So the neat thing tiny IP frags does now is that state-based IDS is the key track of connections and whatever else. If your IDS is like a logic tree like, they're not just doing the flat sort of packet gripping, and they actually check to see that, OK, there's a SIN, all right. There's an ACK, OK. And then I look for my GetPHF, all right. Stuff like, excuse me, IDS is they do stuff like that. You can actually, this sort of stuff kind of works. Because for IDS is that don't do IP fragmentation reassembly. Like it says the same problem that the state-based packet filtering firewalls do in that they can't get the full state with the first packet, so it's like, what do I do? I can't do reassembly either, so I guess I'm not going to pay attention to this stream unless it matches like my packet gripping. And because you're fragmenting that small anyway, it doesn't really matter. And you can do tiny IP frags with another tool that I almost mentioned called FragRouter. And FragRouter is a fine tool. I think it's written by Doug Song. Maybe he's here. And that can send tiny IP frags with just regular traffic. It's sound, it works just like it sounds. It's a router that fragments packets to whatever interesting configuration you want. So, since scan Portland, like all the ports, basically doing a third port sweep, like, expanding in tracks, state tables if they're implemented properly. So this is pretty evil because this next example here, Nmap, send scan, all the ports, decoy scan. I love decoy scan. Let me tell you why I love decoy scan. And with decoy scan, you can fill up state tables faster than anything. And I really like using really fucked up addresses for the decoy scan, which if you're one or two hops away you could probably get away with. But it might not be practical. So, F3, can I go back now? So see here, this network here is 192.168.2. And the one I'm sending from is 10.0.0. Can you go back again? Oh, thanks. Does it work? This thing here? Yeah. So I'm using the loopback address of the destination network, the broadcast address of the destination network. And then the loopback and the broadcast of my network. And then just crazy shit like 255.255.255.255.255 and 0.0.0.0. I've found interesting packet leakage problems doing stuff like this. Whether or not these packs can be routed through the actual internet is a whole another question. But if someone owns your ISP and they're one hop away, it's a completely feasible scenario. Yeah. So decoy scans are actually pretty neat. And actually, I don't think that they're really useful for reading IES detection at all, because that's what the original purpose was. Was that you do so many parallel scans that the IES logs flood, and they can't tell what's going on, because they see so many source addresses for the voice canceling. They can't tell which one's the real one. And so Nmap can be gotten from http.com. Insecure.org, slash Nmap, I-N-S-E-C-U-R-E.org, slash Nmap. I think everyone knows that. Whoever doesn't know that shouldn't be here. Next. Please. Next please. Thank you. Whisker. Whisker is really cool. It's written in Perl, so you can just run it on Win32 or Linux or BSD or whatever the fuck runs Perl. Probably your Palm pilot can run a Whisker if it runs Perl. Yes, sir? I'm sorry. All right. That would be nice. Do what? Turn up the volume? Like this? All right. So I think everyone knows that Whisker is basically made to... It's an HCP scanner, but Rainforest Puppy blesses heart at a whole bunch of IDS evasion functionality, which is really cool. If you see him, give him a big hug and a smooch because he really deserves it. Because this gets passed. These things, I think... I have not seen an IDS that one of those evasion techniques does not get passed. If you can show me one, I'll blow you or something. So Whisker basically... What? Oh, thank you. Let me take it real quick. So Whisker works like this. You have Perl installed. Oh, you have Perl installed. I'm sorry. You have Perl installed just Whisker, dash H, your target host, and then dash I goes through all of the various IDS evasion techniques. Dash I1 is URL encoding, which is a very popular one to do, which lets us face Robert Kramp from Network Eyes Blasted, Network Associates' Cybercop Monitor for not doing when it really does. So I think everyone knows Whisker is good for doing this stuff, but here's an interesting point that I don't think you need to use what I thought it is. HTTP proxy is a block-by-url. Like, they block anything where fuck is in the URL or something. How much do you want to bet that they're all susceptible to URL encoding? I bet you that they all are. So a lot of people think proxies are just deployed so that users on the inside can browse through this proxy. Actually, sometimes it works the other way. They have a proxy so that people coming in from the outside like are limited access to certain URLs unless they belong to a certain IP range or something like that, or they authenticate first. And this gets passed that. Something else to test for in HTTP proxies. I'm not going to talk too much about this because Whisker has great docs. Everyone knows what the hell it is and knows what it is and knows what its capabilities are. So the URL is http://www.yotrip.net-rfp. You can go in there and choose your theme and then find the Whisker docs. That's www.w-i-r-e-t-r-i-p.net-r-f-p for Rainforest Puppy. Next. Isic. Okay. I'm sorry. I can't get over it. These are my favorite tools ever for testing this kind of stuff. It's not necessarily a new idea. It's just something that finally did it. Isic is a suite of utilities. There's Isic, which is IP stack integrity checker. TCP is stack integrity checker. UDP is UDP and ICP is ICP. And Isic is Ethernet, which is actually really cool. We found some interesting problems with that that we'll probably release sometime in the next millennia, hopefully. Great for testing protocol implementations on all of these, all of these. So we found the NetBSD bug, the remote crash, with an IC&P packet using... I'm sorry, it was an IC&P packet. It was unaligned IP options across an unaligned memory access using... Ah, it stopped working. There it goes. Using IC&P-SIC and the steps which were reproduced from the advisory. ICP... Or, I'm sorry, Isic. All the utilities are used libnet by route, which is also a great library. Beautiful code to read if you're into that kind of thing. State-based IDS is a packet filter. Wow. Basically, what these... I'm sorry, what these tools do is they send sort of controlled random packets. It's kind of interesting. So basically, you seed it with a random seed. Remembering all your basic stuff, you use RAN and you have to seed it with like 32K to negative 32K. Works kind of like that. And so basically, if you enter the same random seed, you'll get the same random results. And it, you know, does IP options. It changes all the IP options. It changes the length. It changes the header length. Lies about the header length. All kinds of crazy shit. Basically, it throws a lot. It just pukes all over the protocol stack and sees that the protocol stack can take it. Because state-based IDS is a packet filter, or sort of kind of implementations of TCP-IP to an extent. God, it's hot. Our implementation of TCP-IP to an extent, this sort of vomiting works as well. And it's just like in-map with the state-based IDS, where from a certain IP I go a state-based IDS. I go SIN and wait a minute. I don't get an act. I get a fin immediately. You know, God, I'm screwed in an IQ. Same way with state-based firewalls, small IP packets, not necessarily tiny IP effects, certain fragment offsets. That's what else this is good at finding. Some things are sensitive to just certain fragment offsets. And if you run these tools for long enough, eventually you'll hit all of them. So, IP sect tunnels, same thing. In fact, I would, if someone would take these, Hugh Daniel and I talked about this a couple months ago. I don't know if he's done it yet. But he used to take HPING, some utility called HPING, to loopy and bake-offs and try and get other people's IP sect implementations to crash at the bake-offs. And I pointed out an ISIC, and I don't know if he's actually used it yet. I really hope he does, because I'm sure that it'll just make a whole lot of people's IP sect implementations just puke. And NAT as well. NAT once again. Testing from both, routing from both the trusted network to untrusted and untrusted to trusted and everything in between. Also firing directly at the untrusted interface of the firewall and at the trusted interface of the firewall as well can yield some different results. And also before, like I said, try all kinds of different configurations, one with the denial, one with an allow, two to allow, two allows and absorb, whatever. So here's the example. TCP SIC-S, which is the, specifies the source IP, RAND. If you specify RAND, it will pick a random IP for every single packet it sends out. It's pretty cool. Sometimes though, you don't want to do that because the firewall will just drop things that, like if you're testing from the trusted network to an untrusted network, for instance. I'll do questions at the end. If you're testing from the trusted network to an untrusted network and you aren't sending from the subnet of the untrusted network, the firewall will be smart enough to just drop your packet and you won't go all the way through the code pass that you need to to test them properly. So Dash-S RAND is a good way to do things. When you use Dash-S RAND unplug yourself from the public internet. All right? When you send, it's at a host. It's going to reply back to the source address, right? And if you hit some dot nil by accident or something and people come knocking on your door, that's why. Especially when you're using ESIC, because ESIC by default sends to the broadcast Ethernet address. It kills networks, okay? If you can hide a laptop store in an ESIC that's broadcasting, that's sending like Ethernet frames to the broadcast address, you will kill a network. That's not a legitimate testing though. It's just on the side. So, and then Dash-D is the destination. Trusted. So if we're going from untrusted. And set, be sure to set your random seed. If you don't set it, it uses the process ID of what it's running as right now. And so when you don't use Dash-R, like your PID is incremental or random and open BSD or whatever, you won't get consistent results. And I've seen this mistake happen with people who didn't understand the tool basically. They just, you know, they did Dash-S RAND, Dash-D trusted, and then they just went to town. And then like, they got something to crash and then they could never get to crash again and they were like, what was your random seed? I don't know. Well. Oh, well. So I usually use 3-3-3-7 or 6-6-6. Something's really dumb and easy to remember. If you can't get like anything to happen in like the first 5 million packets or so, try changing the random seed to something else. Dash-M 700 limits, it's like the maximum, maximum not a package. You can pump out on the network kilobytes per second-wise. Now, like the next point says, Linux sends packets fucking fast. Like, 4 meg per second, really fast. But as we mentioned in our NetBSD advisory, Linux mangles packets and doesn't tell you. And so when we were doing some last-minute like tests to make sure this was completely reproducible, like we were releasing the budget, we couldn't reproduce it on Linux and we were like, what the fuck is going on? And so we tested it from BSD, it worked. Problem with BSD is that because for whatever architectural reason, it's not slower at sending packets. It has these things called NMB clusters that fill up very fast for whatever reason. So you can't send them as fast. If you send them as fast, it will drop packets. So instead of sending mangled packets, you still send the packets at all. And this can be a problem. So Dash-M 700, when we were sending from some ARM32 boxes, running NetBSD and also from OpenBSD and like some Pentium 2s or something, that seemed to be about right. And I don't think it has anything to do with how fast the machine is. I think it has to do with the drivers and how they're written. And if you run into that, if your machine's slower than ever, you can increase NMB clusters. Don't ask me how. I don't know anything about Unix. So the URL for ISIC, the suite of utilities, is htgbcon slash hash expert.cc.purdue.edu slash tilde f-r-a-n-t-z-e-n, that man's last name right there. So ex-p-r-t.cc.p-r-d-u-e.edu slash tilde fancy. And so that's slide eight. Next please. I was going to have a code example, by the way, but it got lost in the ether. So I can't do it. Define the, okay. So this is only loosely related, but as far as the kind of, the point of this is this kind of testing brings about certain problems, certain problems with memory allocation, not checking syscalls, not checking the return values of syscalls, various other problems. So just some suggestions for dev managers, for whatever else. For the love of Christ, don't just start coding if you're going to do something serious. All right, if you're going to write like a 200 line program, fine. Like get stoned, drunk, and like code until your fingers bleed. But if you're going to do something serious, define your interfaces first, plan first, try and maintain consistency in the interfaces. God, it drives me crazy. I really, really hate code that's just a total rat's nest. There's no consistency at all. So this is always a good idea, and if you're in a professional environment, modeling tools like UML, what else are in UML? National Rose, whatever, can maybe help you with that kind of thing. Writing well, writing clean, a well-documented code, I mean, like well-formatted, like you can read it, good comments, stuff like that. We'll save you time and anus later. A lot of people think it's a waste of time. A lot of managers think, no, we don't have time to clean it up, whatever. It will always bite you in the ass every single time. When you think the code is going to be used for three months, you're going to rewrite it. It's going to last three years every single time. Have never seen it not happen. All right, this is a real pet peeve. All right, anybody tried to compile in-map like 2.08, or in-map anything pre-2.5? And there's a zillion warnings complaining about all kinds of crazy shit and all that, most of it ended up being bugs. Linux, GNU, not so much BSD, like GNU programs just all the time, or like the compiler gives you warnings for a reason, okay? It's not telling you just to fill up your screen with crap. Please fix warnings if you see them. It's like the most simple thing that's overlooked every single time. Everything is source and runtime analysis tools. If you have loads and loads of cash to spend on Purify, but in SharePlus Plus and FlexAlent and stuff like that. If anyone wants to talk to me further about this stuff, I can talk about it at great length, but it's nothing to do with it. Who is supposed to be here? No, go back. I'll embellish and I'll name this for a minute. I was supposed to be here and I was going to ask the crowd for like, to tell me what was wrong with it. And so I'll put it up on the NuHack page or off my page off of NuHack and along with these slides and hopefully recording the talk and you all can send me mail saying what you see and be like, where's Maldo? Of land coding. So what I was going to do was for every guest that got right of what was wrong I was going to hand out a shirt. So I'm going to hand out shirts doing a Q&A instead for people who have really good questions. For designers designers and coders if you're implementing on NT and you're interested in application level stuff use TDI transport something interface I can remember it as transport data transport driver interface, thank you. You can stuff pre-IP assembly so you don't have to duplicate work of the IP stack and further slow your IDS down. However, comma this only works on host-based IDSs which could be argued here IDSs doesn't really work. On and it works on Windows 95 98 whatever NT and Win 2K so if you write code it's going to be portable for the most part. The other thing you can use I didn't mention here on the slide is IP helper functionality is kind of interesting instead of like seeing maintaining your own state table. Excuse me. Just use the OSes in Windows 98 and NT starting the service pack for NT 4.0 starting the service pack for which is IP helper functions where you can actually get the connection table. You can see who's connected and not have to deal with maintaining your own state and duplicating your work. And if you do this you're just going to be faster and you're just not duplicating work so because you're not duplicating code you're not going to like implement mistakes all over again et cetera, et cetera. In Linux 2.4 you can use net filter interfaces like the Linux crew actually has proper interfaces for something if you can find them such a thing. You can use the net filter interfaces to read yourself at whatever point in the stack you want to get data much like TDI slash and this on Windows. And this is what I highly recommend. I wouldn't bother re-implementing IP5 re-assembly, TCP3 re-assembly. It's just dumb, okay? Seriously. Seriously, okay? Because when you re-implement things there's those other things. Don't re-implement things, okay? Don't rewrite the libc calls. It's stupid. When you write code you're going to make mistakes. When you rewrite code that's existed for 10 to 15 plus years it's been around for that long. People have probably found a lot of the bugs. People aren't going to find the bugs that are in your shitty code. Don't rewrite libc calls. If someone can argue with me later and prove me wrong on this great. I'd really like to be proven wrong. Right now it just annoys the shit out of me that things take three times as long just because someone has to rewrite SN printf. Oh, and also when you're doing NAT and IP stack stuff use the free stuff. There's no reason not to. Try and find someone else who has a NAT implementation like Cisco. Like everyone in the world used Cisco's first reference implementation of IP stack. And it's a camp. And that's why they're all vulnerable to UDP garbage appendage bugs. But if it's a mature code and you're reusing it that's a good thing. You aren't wasting time. It's a really good thing. I can't stress this enough. If you have to argue with your manager about it tell him send me mail. I'll gladly argue. This is something I love arguing about. So there's a New Hexity webpage www.newhexity.net. There is not a whole heck of a lot there right now. I'm sure there will be in the future. We'll be able to buy various memorabilia and that's my email address. S-Y-K-E at newhexity.net N-E-W-H-A-C-K-E C-Y-T C-I-T-Y.net And that's it. So Q&A. If you're running Isaac and it sends like five million packets at your IDS and one of them crashes it how do you narrow down which one did it? Excellent question. Excellent question. It was something I overlooked and I forgot to add in. Isaac has two options. Dash P which says send this many packets and dash K which says skip this many packets. Mike should really be doing the talk on Isaac at this time. And so what you do is if you don't let it run overnight like try and pay attention like look every 500,000 packets or something and see if it crashes. J-R-U actually wrote a patch that pinged after every so many packets and I think maybe it was Mike told me someone like wrote a shell script or something that would send X number packets ping the host and like sort of incrementally go. Okay. He says there's one included in the tar ball. So if you get the if you go to the webpage export.cc.purdue.edu slash tilde F-R-A-N-T-Z-E-N it's in the tar ball. But to answer your question so you understand what's going on so what you do is like you know it crashed sometime between packets 2.5 million and 3 million sake of argument. So what you do is you do Isaac dash S whatever dash D whatever dash R whatever and then you do dash P for sending and you say skip the first 2.5 million when it skips packets it takes a really long time because it has to go through with the random things so you get the same results if you use the same random seed and then from there you do binary search it crashes again you say otherwise you know you expand your search a bit and so once you have the range you know the range you just start doing the binary search and you say okay it's between 2.5 million and 3 million right it doesn't do it that you know it's the other half and you just like you know I don't have to two hours to do that with a net BST exploit except I was lucky there where it didn't happen at 3 million packets it happened at like 30,000 something so that's how you do that that's an excellent question you get a T-shirt anybody else Mr. Balkan would you like to come up and how many intrusion detection did you test? how many he said how many intrusion detection systems do you test with whisker? with all these tools we're testing five five professionally or in my spare time huh huh together seven huh I really don't want to I would rather not advocate anything I don't work for vendor by the way as I'm sure you will all find out you're burnt out on this crap after a while and you just don't deal with it anymore you should that's why I'm doing this so people can test the stuff themselves so admins can go a vendor says it detects everything under the planet you know and then you can just you can test for yourself and if you really feel like it you can post a bug track and get you 255 T-shirts of fame huh so that's probably the reason for this talk I want to do this so people to enable people to do this themselves