 Just a couple of minutes earlier, just to get some of the administrative out of the way. First of all, this session is usefully labeled no IP, which is some kind of shorthand for stuff with sniffing, logging, and intrusion detection, useful and fun things you can do without an IP address. I'm not here to advocate the doing away with the IP protocol. I'm just here to talk about how you can live without an IP address on one or more of your security systems. Following this presentation in this exact same room will be Hurevan Tsir, with his presentation on lids, the Linux intrusion detection system. I think is that right? And, huh? I'll move it down. I'm too loud. Oh, muffled. My speech is slurred and I haven't even heard of my drinker. Is that better? Is that less muffly? Okay. And after that, at the 1300 hour, one o'clock p.m., Thomas Rood is not going to be presenting. Instead, we will have T-Dragon, who will be speaking about making non-portable systems portable. So, any systems portable if you've got the physical strength, I guess. Okay, and what else? Oh, this year's conference is being recorded on video and audio CD rounds. The recordings may be purchased or the recording set as desk located in the Parthenon foyer. Thank you, Defcon. Yeah. Alright. And, oh, and what else? I got some stuff I'm supposed to give away. And I think I'll start off with a trivia question and that is, at what layer of the OSI 7-layer model do IP addresses reside? Core softwares, yeah. Layer 3, that is correct. We have a winner. It wasn't in the phone with the question, but I don't give a rip. Okay. You have your choice. You can have a glamorous and useful Spark IPX, or you can have a complex Mongo switch. I don't know what speed it is, but it does appear to be Ethernet. Damn, I want an ArcNet. You can embalm over ArcNet. It's been done. I'll tell you what, you come here and grab a piece of gear and as long as it doesn't affect the audio presentation, I'll be cool with it. Biggest laptop. You'd probably be happier than IPX. Okay. For the second line, let's see. I'll do another giveaway and then if people stick around at the end, I'll do another giveaway. There's an incentive to not bail on me. The second trivia question is oh shoot, you have to know stuff to ask questions. I know what, those of you who might have been here at Hack a Juppie last night, what is the number of the requests for comments dealing with the TCP protocol? Someone way in the back there with the beard. Yes, yourself. I'm looking for a large positive integer. Let's see. You and the other shirt. No, you. Thank you. The man knows his RFCs or at least he knows his drinking games. His punishment is a Spark Station 10. It appears to have a processor. Congratulations, sir. It'll take two, you know. You can get them on eBay for 300 bucks. Okay. Oh yeah, I'm supposed to give a speech. Okay, so stuff receiving, logging and intrusion detection. Stuff you can do with our IP address. The program today is as follows. I'm going to introduce why you would want to do this. I'm going to talk about how to do it. I'm going to talk about network architectures in which it might be useful to run one or more systems without IP addresses. I'm going to talk about some specific configuration tips mainly focusing on stealth logging because to be perfectly honest it's trivially easy to set up a stealth sniffer. There's one command, exactly. But stealth logging, centralized logging is a little bit trickier and so that's where a lot of the examples will come from. And in fact, as I'll mention, a lot of network applications can use IP free interfaces. TCP dump, snark, pretty much anything that looks at packets below layer three. Excuse me. And then I don't really know why I made six and seven separate points. Oh I know. Point six is where I ask for people to share their own stealth war stories and to ask questions. And part seven is where I shut up all together and leave. There's not a slide for that last one though. Interaction, who am I coming from? I wrote this slide not so much because I'm an eomaniac, which isn't to say that I'm not I guess, but rather to give a little bit of context for why I'm here and why I'm standing on the stage instead of sitting in there. And basically I'm a security consultant like many of us. My day job is mainly with firewalls and with secure network infrastructure design. And the long insure of it is lately what I've mostly been doing is working in the financial sectors and keeping the bad guys out of bank accounts. What I also do on the side quite a bit, and it's kind of ludicrous to say on the side since it takes about as much time, is writing. Anybody here who read Linux Journal? And you still came. Wow, that's so cool. I write the security column for Linux Journal. It's called the Paranoid Penguin. And if you read that column, you know that my whole thing as a writer isn't really so much that I'm an expert do as I say, but more along the lines of at least that's how I think of it is, hey, I got this working in my basement. You probably can too. So that's very much the spirit of this talk. I'm going to warn you and feel free to leave if this really disgusts and disappoints you. But the stuff that I'm about to talk about isn't the result of decades of experience running systems with IP addresses as much as it is about me messing around in the basement and figuring out some kind of groovy stuff that you might find groovy and useful too. So that's the disclaimer and that's my excuse for anything that I say that is some combination of lame, stupid, or inaccurate. So, okay. And what else? Oh, and the other point that I wanted to make about myself is that I'm into digital defense. I was really delighted that that was the track this talk got put into because that's what my work is all about. I think that it's a lot of fun defending systems and it's really challenging and interesting. And you get to use most of the same skills that you would use if you were of a more evil bent. Myself, I really suck at evil, so that hasn't been too much of an option. Please don't use what I'm about to tell you for evil. Thank you. If you do, don't mention my name. Thank you. Okay. So, why on earth would you want to run a system without an IP address? Well, in the particular cases of intrusion detection system probes, which is to say a box running something like Snort to do network intrusion detection, or in the case of a centralized log host where you want your web servers and your FTP servers to send its logs to. Since they are on the network, they are obviously subject to the same sorts of vulnerabilities as any other system on that network. So this is kind of a paradox. You've got systems on the network that are trying to protect that network, but they're vulnerable to exactly the same stuff as everything else on that network. Okay. It's particularly important, obviously, with such systems that they not be rooted and remain available and that the data stored on them is trustworthy. Okay. The first thing anybody with a root kit does after they root a system, if they know anything, is commence to erasing and altering logs. Okay. The clear thing about a stealth logger is it has no IP address, and so it's very difficult, if not impossible in practical terms, to attack remotely. I mean, I guess if you rooted a box on the same network and laid some layer 2 voodoo on it, you could DOS it or something, but I don't think it'd be practical to get too much further than that. If you've got your logger just sitting on a wire and listening to packets that go through, those packets you can be reasonably sure haven't been messed with, because logging typically uses UDP. That goes by pretty quickly. It's not really feasible to hijack a log session. Now you can construct false packets and put those on the wire. So you're still vulnerable to that sort of log data tampering, right? But, you know, that's one risk with the others that you're going to kind of lump into the back of your mind and say, eh, hope that doesn't happen. So that's the value of a stealth log system. In the case of an IDS probe, same thing. You don't want it to get attacked. You don't want it to be compromised. You want to be able to trust the things that it tells you. Okay. How do you do that? How do you protect those boxes? The answer obviously is by not using an IP address. In that way you have eliminated or at least heavily mitigated entire classes of attack vectors, IP based attack vectors, right? And that of course is the main vector that you're trying to protect the other systems against. Okay. Any questions so far? Not that any of this is terribly deep, but okay, cool. So, what do you do? In a nutshell, you configure the backs that's going to receive stuff. You're in order to install an Ethernet interface in it. Maybe it's an additional interface. I'll talk about uses of multiple interfaces. You bring it up. If you're going to be doing your stealth with stuff on a switched environment, it may be necessarily desirable to hang a little hub off one of those ports and then connect it to the hub. If you're really paranoid, you can use a sniffing cable. That's a one way cable. It's received only. That makes it physically impossible for your system to transmit packets. Okay. This is cool both for purposes of stealthfulness. It won't respond, for example, to port scans that way. It wouldn't anyhow if it didn't have an IP address, but layer two type of scans that won't respond to our broadcast, that sort of thing. And the other value of the sniffing cable is that if somebody were to do something weird to this machine somehow, they wouldn't be able to do weirdness out through that interface, at least. Okay. Another thing you might need to do on systems that send to a stealth logger is map a bogus static R-pantry to the bogus IP address that you have everyone send their log data to. I'll talk about that in graded up for a minute. And that's pretty much it. And if you really understand that stuff, that might be all you need to know and you can go. But I've got pictures, so stick on for the pictures. Here's picture number one. Let's talk about architectures, architectural considerations for using a stealth sniffer. Probing the DMZ. This is, of course, where you've got the crown jewels. A DMZ network, if you're cool, is where you isolate all of your publicly accessible systems from your internal network. And I could talk on and on about network architectures, because like I said, that's my day job. But if you're unfamiliar with it, in a DMZ network, what you typically do is you break off a dedicated interface on your firewall and that is what you will connect to your DMZ network to. What this allows you to do is it allows you to define different rules on the firewall for this stuff than you would on the inside. In other words, it lets you treat traffic best in for and originating from, and that's really the important one, that network from your internal host. The beauty of that, of course, is that should one of these boxes in the DMZ get rooted, say somebody exploits a vulnerability on your Apache web server. Okay, they've rooted that box. Well now they still have to hack their way through your firewall to get at anything on the inside. And the chances are, if you've done this right, you will be allowing practically nothing originating from the DMZ to enter in the internal network. So anyhow, that's the obvious place to put an IDS probe or a packet logger or whatever. Now in this diagram, I show only one interface on the stealth probe and the assumption is that you would administer this from the console or you could put another interface in the box one with an IP address and connect that to a dedicated admin LAN. I know people who do this and they'll have a separate physical media network devices separate IP space that they use for administering the boxes that are connected to other networks. The machines on that network don't do any routing. They're specifically configured not to forward packets but they'll allow the administrators to secure shell into that box or whatever and see what's going on on the non-IP interface. Is that clear so far by the way? I kind of threw a lot of architecture stuff at you in just a couple minutes. Okay, here's another architecture. Same thing but including a probe on the internet. Take that a step further and you can have probes everywhere. Now you notice that at this point, you're running into kind of a scalability issue. You've got probes all over the place. This is not something you can really get around in a large environment, right? You need different logical and physical subnets of any different IDS probes. And incidentally I should mention that if you've got a switched environment one of the challenges is that if you have low end switches you can't really do sniffing across switch ports very easily. There may be a means of tricking it into broadcasting but that probably isn't even desirable from a performance standpoint. If you have a high end switch however, it may have a near report and actually this is something to consider when you're designing lands that you intend to hang IDS probes. There are a couple of considerations with a near report. A near report is a port that you tell the switch to send all traffic to. Normally a switch is selective. It only sends packets to the hosts to which those packets are addressed. I'm like a hub that just broadcasts everything. With a near port you're saying, okay, for just this one port I have to send everything in there. There are a couple of problems with this. The first is that the whole purpose of a near port is for land diagnostics. And so you as a security admin may potentially be competing with your network colleagues for use of that port. I actually work with one client who has that situation and it works okay. But once in a while the IDS probes are going to have to be unplugged so that they can plug in a sniffer and figure out why their mobile network doesn't work or whatever. Not something that's instrumentable but something to consider. The other problem with near reports is that the very types of switches that are likely to have a near port are also likely to have an ungodly huge back plane. And even if that near port is a gigabit ethernet port, if you've got a 9 gigabit back plane you're obviously not going to see quite everything. Now if anybody has had experience of the contrary or knows a ways around this, by all means speak up but the guys that I've talked to that focus solely on IDS agree that yeah, I mean you do wind up missing some stuff that way. Okay now if you're like me and you've got a little spaghetti network of your own at home with not too horribly many boxing it is possible to have a box with three interfaces. One for the DMZ, one for the internal network, and one for the outside world. And there's a couple of different the obvious benefit to this architecture is you only need one computer to dedicate to this purpose. Now if it's actually going to be doing network based IDS on two different networks that's going to have to be better than a P180 let's say right? But on the other hand if you've got a relatively low impact site you don't necessarily need a two gigahertz monster in there either. This is however kind of dangerous because what are you doing here? What's the difference between your stealth probe and your firewall at this point? Physically very little, logically a lot of course. I mean in this architecture you don't have an IP address on the DMZ. You don't have an IP address on the outside and you may or may not have one on the inside. It's certainly justifiable depending on your stomach for risk to say well I'm going to IP the internal interface so that I can administer this box because if anyone gets so far as they're able to attack that interface they're already inside. It's game over. So you may or may not consider this really dangerous. The other reason of course it's dangerous is because it's connected to all three networks. If this box gets owned and reconfigured with IPs then they've got carte blanche access. But again if they own this box you're in deep trouble anyhow so that may or may not be a showstopper for you. Obviously however this doesn't scale you would never ever do this in anything but a relatively small network or a set of networks. Okay so those are some architecture considerations. They apply equally to IDS environments and to packet logging and centralized logging things as well. Although in the case of centralized logging you're not going to be receiving logs from the internet probably you're probably just going to be receiving them from the DMZ and on the inside and on the inside you may decide that it is likely to do the stealth thing at all for logging. Okay so you've got a box and it's going to be a stealth box. You install your network interface card. You fire up Linux or whatever and the kernel recognizes the card. What do you need to do now to configure it? Well if it's a Unix box and the interface comes up as ETH1 you just derive config ETH1 up. Any questions? That's literally all there is to it. Now if you rely heavily on things like in the case of SUSE YAST and YAST2 or in the case of Red Hat Net Config life can get a little bit weird and you may wind up having to go in and hack your auto config scripts to I had to do this with my SUSE box. I had to put some information in RC.config so they would help with the fact that there was this additional physical interface but not actually assign the darn thing an IP address. But at the low level you know as far as the kernel itself is concerned this is all that's required to activate the interface. Just bring it up. At that point your user space applications will be able to access that device by name by you know DEV ETH1. Okay Let us depart for a second from the Unix operating system and talk about building a stealth cable. Not a whole lot to this. This particular stealth cable design doesn't work for switches. It only works for hubs. But it's cool because we notice that you got some loop back going on. What happens here is the green of course is received. When packets come in they come down the cable just as they would normally. They also get looped back to the transmit wires to the transmit terminations. That gives you a link light on your hub. It's a bogus link light. The hub thinks that you're sending traffic every time you receive traffic but you're not. You're just bouncing everything you receive back out to the hub. You might think that that would cause some sort of endless loop but it doesn't. I use these at home. If you build one yourself, I highly, highly recommend that you use solid core cable. It's a lot easier to cram two solid pieces of wire together and squeeze them like with a wrench a whole bunch of times and cram them into an RJ45 connector than it is stranded cable. Stranded cable of course basically turns to mush. So you push and it just goes pfft. I've tried doing it both ways and I got nowhere with stranded cable. Maybe it was just the type of male connector that I was trying to use. The other thing is, and I should have mentioned this a lot earlier, the resolution on these projectors is kind of crummy. Don't be alarmed by the fact that this is blurry. The slides on your CD-ROM are perfectly legible and so if you want to refer to this diagram, check it out on the CD-ROM. What's the problem with using this with a switch? It doesn't work. I'm... Right, right. The problem is that there's no way for a switch to receive a MAC address. A switch won't give you the time of day unless it recognizes a MAC address at your port. I'm sorry, I was a smart ass. Won't help again. Again, I promise. I don't think it would. I don't think it would. I guess it depends. I mean, switches tend to vary somewhat between manufacturer and how they handle me reports, I would guess. It ain't like I have one, so I don't know. Huh? Hasn't so far on my hubs on a switch, I don't know. That's quite possible. I'm sorry, I should be repeating questions. The gentleman asked whether this would cause massive collisions on a switch and I think that very likely is why it would not work. Now, I shouldn't stress, however, that the method of using no IP on a switch can work in a specific case of stealth logging and I'll talk about how using bogus R-pentries. That works just fine across a switch. It's just for sniffing proper where you want to see everything on the wire that you pretty much have to be on a hub port and a switch port, unless it's a rear port. Any other questions about receiving only cable? Yes. Oh, okay. The gentleman suggested that to get rid of the collision all you have to do is set the port to full duplex. Of course. You know, you've got access to super league hardware that you can manage. I don't. The switch does what it does. A managed switch, on a managed 10-100 switch, you would be able to set it to full duplex and the collision problem would be solved. Maybe you could make this work. I didn't have the time or the inclination to figure out how to build a receiving only cable for a switch. That certainly sounds like it could work. Okay. Oh, and incidentally, I got to give full credit. I didn't think of this myself. This is not original. I took this from the Snart FAQ and converted it to the beautiful graphic before you. It was originally ASCII art, so I did do something. Yes. Oh, right, right. Your ARP table on this switch would get really screwed up by the loopback. That's absolutely right. It would fill up. Then you would revert to port to a hub behavior and you'd be home free. At which point you'd get like 2 megabits throughput. Okay. Let's shift the discussion now to a somewhat narrow focus in that of stealth logging. The reason I'm not going to talk about stealth IDS explicitly or stealth packet logging any further is because it's easy. There's nothing to do at this point after you've brought up the interface, it optionally used a super paranoid receive only cable, but there's nothing else to do other than to do a Snart-I ETH1 maybe specify config file whatever. It'll work just fine at that point. TCP dump, same thing. Specify the interface and it'll just work. We've got a little bit more work to do however if we're going to do stealth logging. Now, if you're doing IDS you can just configure Snart the way you normally would configure etsysnartsnart.com with the rules or pointers to the files that contain your rules and so forth and that's no different whether the interface in question has an IP address or not. That in itself is actually kind of cool, isn't it? But doesn't involve extra work. But for stealth logging you're going to need a special rule. Now the stuff, oh man, that's totally illegible. What a total drag. Oh and you know what? This is not on the slides on your CD-ROM. I apologize. At the time that I was frantically trying to get these slides ready which was like three weeks ago I was also finishing a book, Building Secure Servers with Linux, O'Reilly and Associates October 2002. I'll try not to plug it. So I didn't really have my act fully together so I apologize for that. But if you go, and this URL is at the end of the presentation too, and it's also apologetically inserted on the dummy slides on your CD-ROM. If you go to defconx.yormonkeys.org you will find this slide in all its glory and in full resolution. But anyhow what it says is okay, any net is considered the external net, in other words look at everything in the same with the same weight basically. We want to look at packet contents. We've got a config dump underscore payload. But we want to see ASCII. There's really no reason to have the hex num. And now let me back up a second. What are we doing here? What we're going to do is we're going to configure a stealth logger. It's got an interface without an IP address and what we want to do is listen on that interface for syslog in GPAC it's sent to UDP port 514. Is anybody here completely unfamiliar with the concept of remote logging? Don't be shy. Okay, just in case anyone is both ignorant and shy I'll explain it. In remote logging you, ignorant is cool, you can fix that. With remote logging what you do is instead of in addition to configuring syslog in G or whatever you use on your unit system to log to a file you also say send some or log packets to this host. And by convention this happens on UDP 514. So you have some central logger with an IP address usually listening on UDP port 514. And the packet format's really simple. It's just IP header, UDP header such as it is, and let's see sending host's name as the sending host specifies it you can lie that can be fun. Priority level and facility. Priority level of course is the severity of the message. Facility is the type of log message. Which is sort of arbitrary, it's user definable. I mean there are standard categories like mail and kernel and so forth but it's perfectly possible to configure your logger to send mail messages to the current facility. But anyhow, how is it going with this? Oh yeah, so that normally happens on UDP 514. What we're going to do here is configure a stealth logger to sniff packets that it sees, optionally address to a specific bogus stealth logger IP address, sniff those packets, strip away the IP header info, and just save the payload of the log packet. So we're going to tell it dump the packet payload, that's the part we're interested in, don't bother with the hex, just give me ASCII and you know I've got a default log directory with Snout LogsGo, that actually won't be used in this case except as if I were to not use a fully qualified path name it'll stick that in front. Pre-processor frag too, we want it to rebuild fragments. Fragged log packets would probably not be as useful to us as complete log packets, right? And then here's the meat of the config file, there's a line that says log UDP source, in this case 192.168.123.0-24, in other words the class C address, that 123 on any source port, source ports are arbitrary, right, more or less, match packets that are addressed to 192.168.123.111 Is there a host that actually has that IP address? No, emphatically not. The whole point of this exercise, the only reason that you could write this rule to say any as the destination, right? But what I like to do, what I like to do is pick some IP address at random that none of the hosts on this segment are actually using and send packets there, in the sadistic hope that an attacker will try to identify and attack that system. But it doesn't exist. So it involves a little bit of extra work with configuration, and my log is I'm going to have to put a bogus R-pentry in for that IP address. But anyhow, that's what this rule says, is look for packets. To me, I like the idea of specifying the destination on my log rule for sniffing packets. And then in parentheses at the end, then it says log to my file. And my, you know, my log file, that's just the name of the file that I want to stick these packets in. Now at this point, we're telling Snort to log the whole packet. We kind of have to. There isn't an easy way that I know of to get Snort to only log the packet Wow, is that ever disturbing? I guess I'm glad I skipped breakfast. Okay. I'm going to hope that that wasn't some sort of statement. Oh, the dude scored 75 points in the scavenger hunt that way. Yeah, yeah, yeah. If anybody feels really traumatized and having some obsolete junk would help. I can help. I can offer some junk therapy a little later on here. Thank the vendors who contributed to use this joint, not me. Okay. Where was I? Oh, yeah. So we've got to add this log rule. Obviously on a stealth log system, we don't want to actually be looking for intrusion detection. I mean, I guess maybe you do. I guess you could have it do both, but that would make for a more complicated example, so it doesn't show that here. Okay. Now the way that you would fire up Snort to act that way looks a lot like the way that you would fire up to do IDS. You specify a configuration file and you tell it to run in Damon mode. Obviously in this case it's our truncated little teeny snort.conf file that just has the one rule saying look for log packets. We also use the dash I flag to specify an interface. Actually you probably want to anytime you fire up Snort, but for sure you need to hear. You need to tell it, listen on that stealth interface what has no IP. Okay. Now are you following me so far? We've just configured our central log server to sniff its log packets off the wire, right? Now we're going to do on each host that actually sends log data. What we're going to do are two things. First we're going to configure our logger on that system, our log facility to send to the bogus IP address so that it puts the packets out on the wire. Now if you use a bogus IP that's local to the LAN, you are going to need in addition to the appropriate configuration stuff in syslog.conf or in syslog-ng.conf, you're also going to need that static ARP entry. If you skip that part, if you don't have a static ARP entry saying, hey the MAC address of this bogus IP is this bogus MAC address. In this case E-I-E-I-O. Because I have little kids and that was on my mind at the time. And if you're doing this across the switch, you could in fact make that the real MAC address of your log server so that the packets actually get to the stealth logger. Obviously you are now making the system known to the switch, right? But the system isn't actually configured with that bogus IP address. So it would be possible for people if they want to to deliver packets to that host, but that host will drop them because it doesn't have an IP address. Okay. Except of course for log packets. Was that confusing? Was that clear? Ask two yes or no questions and then figure out which the answer applies to. Good, Nick. Was that, should I explain that further? No? Okay. Okay. So the static ARP entry. Okay. Once we've done that, well when I talk briefly about what I added to syslog.conf, that's really easy. I'm telling you in this example, what I've got is start at star, semicolon mail dot nun, semicolon news dot nun. I'm looking at the second liner. What this is going to match is all packets, all log messages except those that involve mail and those that involve news. Because typically you've got a dedicated log file for those. And unless this is an SMTP gateway or a new server, you probably don't care about seeing the log packets from a security standpoint so much. Well, you actually probably do. For whatever reason I've configured this to not send those to the log server. And what it's going to do is instead of logging to a file like the first line, I'm going to send to an IP address. So I use an app sign and then the IP address or host name of my center log server. Now remember that dot 111 is a bogus IP address. But what this is going to cause my logging host, my web server or whatever, is to construct these packets addressed to this bogus IP and slap them out on the wire. Okay, syslog ng looks more complicated. I guess it sort of is. But if you use syslog ng, which I highly recommend, it's much more powerful. So we need to define a destination. We've got a destination named d underscore log host. And that's a destination that uses UDP. We give the bogus IP. We give the port. We can use any port we want by the way. We don't have to use 514 for this. As long as you're sniffing for packets using the port that you set here on your sending machines, it can be anything you want. I used 514 out of mental laziness. So we've got a destination for filter. We want all packets that have got severity of info or higher. So that's what that filter says. And then we've got a login word that says syslog, anything that matches a filter called filter, and send packets that match to the destination d underscore log host. Okay, any questions on configuring your logger to send to the bogus IP address? Yes? How do you, the question is, how do you prevent poisoning? I don't know. How do you? I hope it doesn't matter. Yeah, I don't hope it doesn't matter. Our poisoning really is only going to pertain to switches. I guess what you could do is, I mean if you knew that if you as an attacker knew that the syslog had set up a stealth logger and that the box that you just rooted is sending its logs to a bogus IP, I guess you could mess with that R-pantry for some reason. And I mean that's not really our poisoning, that's just our futzen, but you know, I mean at that point I'm not too sure how much worse that is going to make your life and it already will be at that point. I mean, which is to say, obviously if somebody roots a box that is doing remote logging from that point forward the logs aren't trustworthy whether they're being logged locally or being transmitted. The whole point of this size is that the logs sent up to the point where the attack succeeded will be on the central log server in a place that they can't easily be erased or tampered with, okay? So our poisoning, yeah I don't know how you'd prevent it in this case. Yes. Ooh. Higher end switches can lock a port to a specific MAC address. Again, I have no experience with higher end switches. I use cheap Aussie crap. Can you tell that I've got issues with that? Got a little bit of resentment there. Okay, so we've set up a receiver, you know, we've set up our stealth log point, we've set up our senders and now packets start going over the wire. What do they look like? They look really blurry. Here we've got a standard snort outputted packet on top. We've got your IP header and timestamp and then the data payload. Now this isn't too bad. I mean you can quite possibly live with this as your syslog file format and make sense out of these and just kind of mentally ignore the first three lines. And the first three lines you might say to, I mean you might think well that's really important to log the IP header, right? So you know the packet really came from the host that it said it came from. But see the thing is to a point you sort of trust, you know until they've been rooted you trust the host sending the packet to not use a bogus name in the data payload versus whatever would reverse resolve from the IP address and the IP header. So in my opinion in practical terms there's really very little of value in that IP header. Okay, so what I like to do is I like to pipe these packets as they're logged using I'll tell that off through ARC and strip away everything up to the first left angle bracket which as it happens in syslog packets so far as I've seen them so far doesn't show up until you hit the, what is that number we're referring to, I guess message, excuse me? Process ID. Thank you, process ID. That's going to be the first left angle bracket that block encounters as it parses this packet and then I have it take everything after including that left angle bracket to that string of equal plus, equal plus, equal plus that Snort uses as a delimiter between packets. So that way you wind up with is the same thing but missing the first two lines. You get slightly more compact logs that way. So let's look at this as another slide incidentally that is not in on the CD-ROM but is on my website, the defconnx.ylamonkeys.org site. Oh, that's right because I did this one like yesterday. It will be there like within 48 to 10, 24 hours. So. Okay, so that's it. I mean that's really all there is to it. At that point now your self logger will be sniffing the wire for log packets, stripping away, optionally stripping away the IP header info and saving the data in a big file. You can run multiple instances of Snort if you want so that you can write those to different files. There's all kinds of different ways that you can fit this to your own needs. At this point I'd like to open the floor to questions, comments, observations. Better rip. Yeah, the gentleman observed that it would be really simple to write a program that would flood your network with bogus log packets and what fill up the server that way. Absolutely that's true whether you've got a self logger or a regular centralized logger. That's a problem that's inherent to remote logging. So you're right, that's a problem. I'm sorry. Yeah, this gentleman pointed out that if you use a non-standard port number then that's a little bit less obvious. I mean if you're filtering on port, I don't know, 999 then people can send, packets sent to some other port will be dropped by Snort. They won't be logged. You can certainly use TCP based log packages, yes. And that's the cool thing about SysLogNG. SysLogNG can let you define a destination that uses TCP rather than UEP. Again you can use any port you want and you get increased reliability. You also get increased process overhead but that's, you know, if it's a dedicated logger that probably is not a problem. So yes, excellent observation. I should have mentioned that myself earlier. Excuse me, can you filter and specify certain logic log packets coming from certain IP addresses? Yeah, definitely. That's an excellent idea. You could use IP tables or for that matter IP chains running locally on the stealth logger to filter out any packets not originating from your actual DMZ servers that are sending the logs. Yeah, now if one of those gets owned it can be used to do the flood, but if it doesn't it can't. Yes? Yeah, I do too. I mean, this is not a technique that will prevent any type of attack. Right? Except, specifically, IP based attacks on the stealth server itself. That is to say IP attacks that are meant to actually compromise the box, gain access to it. You are not going to prevent other types of weirdness happening on the wire. You're just going to improve your odds of logging that activity or detecting it with an IDS probe. This is really a last line of defense kind of technique, as remote logging and IDS are anyhow. Yes? Oh, yeah. How do you protect your logs from IP based attacks by stealth logging? That's how. By not using an IP address. It was a lame attempt at a joke, sorry about that. Other questions? Yes? Could you use the same machine both as a stealth logger and as an IDS probe? Absolutely yes. That wouldn't scale for solid grapes. You wouldn't want to do that on a really large 100 base T network with a bunch of really busy servers. You wouldn't want to do it on a gigahertz ethernet switch with a mirror port or gigabit, excuse me. But something like Mix Home Network? Yeah, that would work. There might be certain advantages to separating the functionality, but I guess I kind of doubt it. The reason my whole mindset is that you dedicate a host to being your stealth logger is because I've got really old, slow hardware at home that I use for this kind of thing. Here's the guy with the high end switches. Yeah, what do you want? Yeah, you could do that. That's a really good suggestion. Rather than if you didn't want to use a bogus IP address in a way that I described, could you map your static ARP entry to FF, FF, FF, FF, FF. Yes, you definitely could. And at that point, your log packets would be broadcast even on a switch. All I see, oh, that's so cool. I'm really glad I came today. You win some hardware, sir, because I think I get the impression that you don't have enough really old hardware. What is this? This one has got 20 ports. It's got serial ports. You can put T1s to the sucker. I'm going to give you the really cool one. It's got gazillions of ether ports. Oh my god. And at no extra charge, you get this ethernet module too. Gee, I hope I didn't break it. It won't be replacing my 3660 anytime soon. But it could be a backup to it, couldn't it? I shuddered to think that airport security would think of that thing. It's got these fingerprints on it. Are they my fingerprints? You don't know. They could just be gummy bear fingerprints, couldn't they? Okay, anything else? I guess I'm supposed to shut up soon. Yeah? I'd like to thank you for not using Microsoft Powerpoint. It is my pleasure to not use Microsoft Powerpoint. But then I'd have to pay for Microsoft Powerpoint, wouldn't I? I mean, have we not established that I'm a total scrounge? No, we're a virtue there, I'm afraid. Yes? Oh, of course. The schedule changes are as follows. Next as scheduled will be and if I mispronounce it, I really apologize, who will be presenting on lids which is really cool. So I highly recommend you stick around for that. If you're interested in kernel level IP protection or actually system protection, because we'd be under snow looking. And then after that, rather than Thomas Wood doing next generation data forensics, we will instead have T-Dragon who will speak about making non-portable systems portable. And oh, and also I've skipped this one before. Fuzzy or is it fuzzy? Will not be speaking on shell card. Instead, the ever popular speaker, I think I met this guy once, TBA will be presenting. So, greets to TBA if he's here. In the third room. That one, an incidentally that the one that fuzzy was scheduled for was for one o'clock. In the third room will be as scheduled, Nate Wiltschaffer doing a thing on biometrics. It's secret. It's undisclosed, yeah. Anyone need like directions to the airport, current time something related to my talk? Afterwards oh, thanks a lot. Thanks a lot for coming. Thanks for getting up. Enjoy the rest of your stay. I will be