 Hi. Good afternoon. It's noon, right? No, afternoon. My name is Mick Bauer, and before anybody asks, I am not on my way to a Scottish funeral. Thank you. I'm here to talk about self-abuse for smarter log monitoring. And it's a really, a fairly simple technique, but I thought it would be a fun context in which to talk about log monitoring and to talk about self-scanning. And about self-abuse, if you want, later on. The talk that I'm about to give is reasonably well structured, and I just wanted to show you that I am working off of an outline, despite what might appear later on, because I do want to keep things fairly loose. I want you guys to have as much impact on the flow of this as you want to have. So comments, questions, observations are welcome at all times. Later on, I'm even going to open up the floor for people to beat up on my victim system here, and I'll give the IP address of that when the time comes, although some of you may have made deduce it way before then. And whoever causes interesting log messages to share up there will get a price. Okay, so let's just dive into it here. What is the point of scanning yourself, you might ask? Well, security people like me tell you monitor your logs when you harden your web server and you configure everything into a production state and it's working. You should not abandon it, right? You shouldn't just leave it chugging off in the corner. Among other things, you should be monitoring its logs regularly. Maybe you even want an IDS system running on it, a host-based IDS system. Maybe you want a simple log watcher like Swatch or Log Watcher or Log Digest. But in all of these cases, you as a sysadmin need to know something about what constitutes evil activity. Would you know an attack-induced log message if you saw one? Maybe you would, maybe you wouldn't. This technique can help. So, if I'm talking about running, let's say, Nessus or Nikto against a system and you're going to be logged onto that system and tailing the logs, there's a couple of assumptions at play here that I wanted to spell out. The first is that one of these scanners, the scanner that you're using, whether it's Nikto, whether it's Nessus or whether it's just Telnet, you know, Telnet 80, etc. The assumption is that that's going to look in the logs pretty much the same as live sploits that kitties in the field would be running on you. I think this is a fairly reasonable assumption. What a security scanner like Nessus does is it actually does the early stages of actual exploits. That is to say, it does the sort of very targeted reconnaissance and initiates the types of packet sequences that a full-blown actually trying to root your box attack would do. But that may or may not be a leap for you. When in doubt, there's no substitute for running actual exploit code against yourself if you want ultra-realism in this. In my opinion, you know, using a generalized scanner like Nessus or Nikto is perfectly okay. And then, so there's value in that in seeing what kitty behavior looks like. Another thing that's probably equally maybe even more important is, what if you run your all-the-stops pulled Nessus scan against your host and it logs like nothing? That's telling you something really important, isn't it? It's telling you, okay, time to go in and fine-tune sysloggy, time to go in and maybe tweak the logging settings on Apache or whatever so that I'm seeing the information that I expect or want to be seeing when the bad guys come knocking. And then finally, it's just good clean fun to scan yourself. Okay, now there are a few limitations, not only with, you know, this little technique but also with log monitoring in general and even I would extend that to IDS. And that is, I'm not proposing that if only you stay logged in long enough and frequently enough and watch the logs obsessively, you're going to catch bad guys in the act and lock them out of your systems. I mean, that's obviously not realistic. I think that it's not realistic a lot of the time with IDS as well. Logs are first and foremost a forensics tool. They let you know what happened. By definition, nothing is logged until after it occurs, right? So if you really want, if you're really worried about proactive security, the plain old unglamorous techniques of staying patched, disabling and uninstalling unnecessary stuff, being aware of current trends in infosec, you know, what is the latest worm making the rounds and that sort of thing. And finally, knowing and understanding the security features in your software and in your operating system, these are the ways that you keep attackers out. This is log monitoring, IDS, the rest of it. These are tools for knowing how good of a job you're doing with that other stuff, in my opinion. Now there are things that you can do. Snort, for example, has got an add-on called hogwash that can be used to dynamically reconfigure your firewall rules. Now it says right in the Snort FAQ, and I agree wholeheartedly with it, that this is a beautiful opportunity for denial of service attacks. If you know that somebody is using something like this, if you send a bunch of spoofed packets from victim A that look like an attack, in other words, spoof an attack from victim A against a hogwash or otherwise dynamic firewall modified type host over here, you can effectively prevent this host from receiving legitimate traffic from the victim host. This is really the fly in the so-called intrusion prevention ointment. And there's various ways around that, and I'm really not prepared to get in big debate about it or anything, but other than tools like hogwash, IDSs are mostly for forensics, I think. Okay, does anyone want to pick that particular religious fight with me now, or should I move on? I don't think it's really that controversial anymore. Okay, well then let's dive right into a demonstration. I'm going to run a Nikto scan against this box, which is running Apache, and give me a second here while I turn on a log tail. Okay, what I'm going to do on my main laptop over here, I've got a Nikto scan all fired up and ready to go, and Nikto, if you're unfamiliar with it, is the successor to Whisker. Rainforest Puppy stopped active development on Whisker. He's still maintaining LibWisker, and if you're interested in what Whisker used to do, you're redirected to, not redirected, but encouraged to go to cert.net and get your hands on Nikto, which in fact uses LibWisker. It is a web server scanner, and what it does, among other things, is it checks for known bad CGI scripts, known bad sample scripts of various kinds, and a whole lot more, and if you're interested in command line flags, I'm starting it with a general scan, that's what the dash G is for. Dash N means no DNS resolution, and then dash H tells it the target host to scan. So, I fire that up, and at this point, I can skip to my victim, and let me see if I can't expand that a little bit. Okay, and ta-da, that's what log output looks like on a machine that's being Nikto scanned. Fascinating, isn't it? I could watch this for hours. Actually, well, that isn't the point. Notice, though, what I'm seeing is a lot of repetitions of really similar messages. If I'm setting up something like Swatch, if I'm setting up something like log digest, I'm going to make sure that the string file does not exist, is one of the things that I'm checking for, right? If I'm concerned about being Nikto scanned, if I'm concerned about people probing this web server for stuff. Now, if I'm only interested in a specific type of scan, I can say, you know, grep for more than file does not exist, but you get the idea. Any questions? I know that's really deep and all. Okay. Wait, oops. Okay, there we go. Now, as you can see, this is back to, oh, nuts, look over here. Oh, I wonder if the problem is the switch. Well, oh, yeah, it must be the switch. Okay. So, as we can see, Nikto is finding some things wrong, and one of the things that it has found is that there is the Apache manual installed on here, which is default for SUSE Linux. When you install Apache on SUSE Linux, it very conveniently gives you the Apache manual. It's probably harmless. I mean, it's just a manual, right? But it has a little search engine in there. And the fact is that as a matter of practice, you don't want anything unnecessary installed on a production web server, right? So even something as innocuous as the Apache manual being there is still a significant finding. And this, of course, is the other benefit of this technique, is when you scan yourself, you will find out if there's more hardening that you still got to do on the hosting question. So I would like, if I could, to insert another demo here that I hadn't really included on the slides. But before I do that, are there any questions up to this point? Any at all? Okay. What I'm going to do is I'm going to pull up that manual. Bear with me. And what do we got here? Ah, yep, sure enough. Nikto was not delusional. The Apache manual is running on this host. Now, there is a thing called Peros. The loft has an equivalent of this, a commercial product. I think it's called, or excuse me, at-stake, my bad, the at-stake web security proxy. And what a web security proxy is for is for testing various types of web vulnerabilities at the, pretty much at the application layer. And in other words, I can trap requests from my, outbound requests from my attacking machine, monkey with them, and then send them back on their way towards the victim machine. So let's say I click trap request on here. And incidentally, Peros is available. Oh, brother, I forgot to include a URL on this. If you do a Google search for Peros web proxy, you'll find it really easily. Oh, wait, I know what I can do. Proofsecure.com, that's where you get Peros. Or Paros, if you're European. Proofsecure.com. Okay, I have told Peros to trap the next request that passes through it. Oh, and incidentally, behind the scenes in my hotel room, I set up my web browser so that it's using localhost colon 8080 as its web proxy. And that's what Peros is listening on. I go back to my webpage here. I type in some kind of, wait, let's do something that I'll see. I type in a search string, click the button. Now, the Netscape icon, oh, I'm pointing at my screen. That does you no good at all. In the upper right-hand corner, the Netscape icon is spinning and spinning. That's because that's because Peros has grabbed that outbound HTTP request so that I can monkey with it. And we see down here in the bottom, in the body, I mean, here's my search string. Now, this is sort of a lame example, but what I could do here is type perhaps a much, much longer string than the webpage itself will let me type in in that field. So I lay in a whole bunch of Fs. And then I hit continue. Now, if I flip back to my web server, okay, I got an error message. That's good. That little search engine apparently has some kind of error handling. But if it didn't, if the web server froze up or something, that would tell me something about the security involved in that little search thing. So anyhow, that's Peros. If you're interested in web security and if you're running a web server, you really ought to be. I highly recommend this tool for testing web forms and web applications, anything that could be vulnerable to fuzzing, which is what we just did, by the way, fuzzing, cross-scripting type of tax, you name it. Okay, back to the regularly scheduled program. Okay. So we saw Nikto versus Apache. Let's dive right into a third demonstration. Can you believe it? So many demonstrations in such a short period of time. Oh no, why is this still logging? Oh, is Nikto still running? Must be. Oh yeah, it is. Okay, I'm going to kill Nikto. And the site for Nikto, by the way, it's in the slides in your program, but it's cert.net. That's C-I-R-T.net. You know, www.cert.net. Okay, good. Now... Okay. Now Nessus. Now Nessus, available at www.nessus.org, Outstanding General Network Security Scanner from Ray Naud de Rison. He gave a presentation at, I think, Black Hat a couple years ago. Heck of a guy. And Nessus is, if you are a security auditor, or well anybody, it is just the coolest thing because it does what commercial, expensive commercial security scanners do, but for free and 100% user customizable. So in other words, you know of or have written some zero-day exploit, right? You're not beholden to some vendor to provide you with a plug-in script. You can write your own if you need or want to. It's got a super easy-to-use language for that, its own scripting language. Now, before I started this presentation, I logged in and everything, and I'm not, this is not going to be a tutorial on using Nessus. I've written articles about it. Actually, my book, I haven't plugged my book yet. Many of you are probably disappointed because I've not yet plugged the book. Building Secure Servers with Linux. You've got Chapter 10 from this book on your CD, which might have been really dumb of me because maybe you feel no need to buy it. Now that you've got Juicy Chapter 10, there's much more. Anyhow, in Chapter 3, I think I talk about using Nessus as a sanity check after you harden a system. So you want to detail the information on Nessus by the book, flipped to Chapter 3. Okay. So what have I got here? I set up a scan that's pretty selective. I disabled a bunch of the plug-ins that I know are completely irrelevant to this system, strictly for the sake of expediency here. Another thing that's cool about Nessus is step one in the Nessus scan is a big old Harry port scan. Usually, I mean, by default, it uses NMAP. But that's really pretty time-consuming. And there's nothing to stop you from running your own NMAP scan, saving the output to a file, and then telling Nessus, hey, I've already got scan output, use that. And what else have I got here? Okay, target selection. My target host is 10.25.25.2. Oh. In the interest of full disclosure, you know what? I misinterpreted that error message I got from my web server before. According to my log dump, the reason I got an empty page was because I've got a broken manual installed here. File does not exist. I can't serve the hd.cgi local guestbook.cgi. That's pretty cool. If there are any invulnerabilities in that guestbook, they don't apply. It's not there. I'm sorry. That just kind of caught my eye there. Oh, good, the screen came back up. Nessus is really good about tracking sessions. So if you've already scanned a host and you had clicked save this session, then later on you can click on that session. You know, it's got a date and a timestamp and an IP address and WAML. It will pick up where that scan left off if you interrupted it or rerun it, whatever you want to do. I'm putting it in manually because I want to pretend that I haven't already scanned this box sideways. And... Oh, wait, let me show you the knowledge-based page, too. That's actually pretty cool. Nessus can keep track of everything that it scans in a database. It's called the knowledge-base. So when you do subsequent tests, say you've got this web server farm and you're going to scan it periodically to make sure that as you add web applications, as you add software, as you apply system patches or what have you, that you're still not exposing yourself to anything obvious, you can maintain a knowledge-base on that host so that basically what you do is a full scan and then incremental scans. That saves you the time and tedium of running the same scripts over and over and getting the same results over and over. Okay. I'm just going to fire up the scan here now, though. And now at this point, I'll flip back to our little web server. And... since where I'm now doing a general scan, I'm going to tail virolog messages. And if you see some really wacky animation, it's because I've got a bad, bad checkpoint driver on this system. Hold on a sec. Okay. And now we start to see some nasty grams. Oh, and some of them are even coming for me. Better still. Oh, it looks like it's doing a port scan. Well, I'll be darned. Well, isn't that annoying? Well, that's going to take all day. Nessus is not without its quirks. Well, that's funny. I said, do not execute scanners that have been executed. What the heck? Oh, well. Maybe it'll go real fast. Hmm. Now, it's worth mentioning that on my victim host here, these messages that you're seeing, the drop by default, that's not stock SUSE 8.1 behavior. I'm running a custom IP table script on here. And at the bottom of the script, I've got default drop rules and each default drop rule, for each of the three chains, input, forward, and output, I've got a log rule that says log everything that's made it this far and then drop it. So you're not going to see these messages, the packet level, dropped by default messages unless you have done the same on your system. A note about IP tables. Most of the major distros now have their own scripts and firewall rules. I've really got a love-hate relationship with those. Sometimes they can be helpful if your needs match those that the distro developer had in mind. I tend to do pretty zany stuff with my machines and so that's seldom the case. I tend to prefer to roll my own. Chapter 10 of my book, which, again, is on your DEF CON CD-ROM, so that statement is not in itself a pitch, has... Oh, wait a minute. No, it doesn't. Okay, I am pitching my book. Chapter 2 of my book describes how to write IP table scripts for the specific purpose of protecting a bastion host. I think that running firewall rules on a non-firewall machine is a really groovy thing to do. I mean, why not? Maybe you, as a web administrator, are more clue-ful than your local firewall admins. I've seen it happen. It's not quite as common as the reverse, but hey, the point is that any system that is internet accessible should have some ability to defend itself, regardless of what the firewall that it's on the inside of does or does not do for it. So I've got some really simple rules that I'll inbound HTTP, inbound secure shell, inbound SMTP, just so that people would see something if they scanned it, and nothing else. Another thing that's worth noting is naturally I have set my default IP tables policies on input, forward, and output right? So I don't really need my drop rules at the bottom, but they're there anyhow so that I can have the logging. Because your default your default policy that you assign to an IP tables chain doesn't log. Go figure. Okay. So my nest is, okay, it's beginning actual attacks. I did wind up with a much, much shorter port scan. So the knowledge base did kick in there. Okay, cool. It's beginning to question my grip on reality. I never do that. All right. And now at this point, at this point, the web log starts to get interesting, and we start to see nest-specific Apache errors. We're seeing a lot of the same stuff that we saw from Nikto, aren't we? We're seeing file does not exist, but then we're also seeing some, somewhat more exotic stuff, attempt to invoke directory something it zipped by a little too fast. But there you have it. Nest of scan, tailed logs. I now have some idea of what script kitty behavior should look like. And it's been on my terms, on my own spare time, at my own pace, instead of when the fur is flying. A lot harder to get up to speed on this stuff when the fur is flying. Any questions up to this point? Comments, jokes, coughs? No one's even coughing. They're out. Oh god, they're alive. Good. Thank you. Oh, and by the way, can everyone hear okay? Dumb question. Never mind. Okay, I killed the scan because I'm sure that you get the idea. Oh, I guess here. In case you've never seen nest-less output before, here's some nest-less output for us. Now I didn't even finish the scan, but I already found some stuff. What did it find? Oh, this is entertaining. I've seen this one before. Oh, sorry, sorry. Thank you. And to think I doubted that you guys were awake. Okay, remote OS guess. This is a Panasonic IP technology broadband networking gateway. I had no idea. When I bought this thing, I thought I was getting a plain ordinary think pad. Actual volums, though. It did correctly identify an HTTP problem and that is that it supports the trace method. Now, if I go back here and I'm not going to do it right now, but if I go back in the logs, the log message is the correspond to that attack, I will see that this is in fact sort of a false positive, but there it is. Something that's worth pointing out is that if I let the nest-less scan go to its logical conclusion, I will see some different stuff than I saw in the Nikto scan. So, while it might be tempting to assume that there is a really well-known finite list of attacks that people think are noteworthy against Apache, there are in fact differences of opinion between the guys who do Nikto and the guys who do Nessus. It truly is worthwhile doing more than one type of scan against a production host. If you're serious about checking your hardening work, knowing what types of attacks to look for, and that sort of thing. So, I found that interesting that I got different results each way. Okay, I'm going to close the report. Oops. That can't solve. Don't need to save that. Back to the slides. Now, I've got screenshots in the slideshow on your CD-ROM. Now, it would be a lot more fun for you to reproduce these on your own, but if you're not inclined to, I've got I show Nessus in action and I show the log output. So, now let's talk about loggers. I've done these scans. I've gotten a feel for what scan activity looks like for some pretty granular, some pretty deep security probing, you know, way beyond just simple port scanning, actually. And suppose that I have not seen as much as I expected or wanted to see. What do I do about that? Well, on most systems, you edit etsycislog.com on most UNIX systems. What I've got here are the relevant lines. I've stripped away most of the commentary from a Red Hat 7.3cislog.com file. And as with Nessus, I'm not going to deliver a dissertation on configuring syslog. It's all in the syslog.com command page. But just at a high level, what you've got on the left-hand side of the screen are log-facility and log-severity pairs. So you've got facility.severity, right? And you can use the star wildcard. That tells syslog.d in any given case what sort of message is to look for. And then on the right-hand side, it tells syslog.d what to do with them. I can write them to a file. So with our log messages, I'm going to write a lot of stuff, too. If I put a star on the right-hand side, I keep pointing to the screen. You can't see this. Oh, use the mouse. Good idea. If I put a star over here, that says, write the log message to all consoles. Now, that's only useful, of course, if some sysadmin... some sysadministrative type person is actually logged on. So that's one that you generally don't want to do. That's not the only destination that you want to use for any given class of log messages. You want to make sure that that entry is redundant with other entries that write to files. And indeed, by default, the redhead73syslog.com file is. You can also send messages to a remote host, and the way that you do that is by doing atSign and then hostNamerIP. And that'll send it to UDP514 on your central log server. My talk at Defconn last year was about setting up a centralized stealth logger and using it in just that fashion. It's real important that you have good logs and you have logs that you can trust. Which is to say, if you get owned, you want to make sure that later on when you go to analyze the logs from that, that you don't have to worry about them having been altered. Well, the local logs on the machine, you have to assume that they've been tampered with. Your best hope at log integrity is having a copy of those log messages having been sent to some centralized logger so that you can use those for the serious forensic analysis later on. Here's a bonus. This is a chart that was not included in my book. My editor felt that it was kind of confusing. But the thing is it won't be confusing to you because I'll explain it right here in real time. This is actually like three or four charts glommed into one. The double lines separate the different parts. But I've got a list of the facilities that Syslog uses with their corresponding numeric equivalents. I've got a list of priorities, log levels, and their corresponding numeric values. If you've ever tried to dig up this information in other places, it can be a little tricky. I don't think that the numeric codes are in the man page, at least on Linux. And then I've got a synopsis of the different actions that you can use. And the usage of different operators like bang and equal sign. So I encourage you if you've got Syslog Damons to configure to print this out and tack it up on your cube, it'll save you a bunch of man page and info page lookups. At least that's what I hope. But I won't read every line on it to you right now if that's okay. Okay, now for you to see what happens out there. Here's the SyslogNG configuration. If you run Debian, I believe SyslogNG is the default logger, isn't it? Or is it optional? Oh, it is optional. Oh, my mistake. But it's there. I recommend that you use it because it's a lot more powerful than regular old Syslog. SyslogNG is also available on SUSE Linux as an optional package, probably on other Linux distros too by now. You can run on anything. You can get the source code from, let's see, www.balabit b-a-l-a-b-i-t dot h-u and the home page is in Hungarian but there's a little button that says English. You probably want to click that and then follow the links to SyslogNG. SyslogNG is covered in depth in the sample chapter from my book that's on your CD-ROM. Can you let that do the talking about SyslogNG? Pardon the jet plane. Oh, yeah. I just said that in a really Minnesotan way, didn't I? Yeah, sure. You can gaze upon that a little longer if you like. Yes. Well, does a killed facilitate self-abuse? I'm not going to answer that question directly, but what I will say is that the sporton, which is the pouch in front, is the most practical accessory because it not only gets all of your important stuff right there in front of you, but if you need to scratch, no one's the wiser. I believe Jethro Tull may have said happiness is a warm sporton. If he didn't, he should have. Yeah, I wanted to get the furry one but that would be just too distracting. Okay. Are we done transcribing my SyslogNG chart? I'm glad you like it. I worked so hard on that and then they didn't include it in the book. I was miffed. I'm still bitter. Okay. So, SyslogNG, what I will say about SyslogNG about how it works is you may look at this and say, God, that's a lot more confusing than syslog.com and it is more verbiage. But it's highly module. You've got your option statements. They're global options for the daemon's behavior. You've got source statements that tell SyslogNG where to get its log information from. This one on my site is actually kind of oh, fancy because I'm piping off a PROC K message. What I'm doing is I'm doing an end run around K log D which you really don't have to do. I mean, SyslogNG and K log D work just fine together. But if you want to kill K log D because it's an extra process and it offends you, you can do so with a statement just like that. You set up your sources. You set up filters and that's where you specify your log facility and severity pairs and attach arbitrary text labels to them. F underscore weirdness. F underscore messages, whatever. Destinations. Places to write the logs. Terminal consoles. Files. Programs. I really should have put a UDP statement in there because you set up a remote host as a log destination. And then the payoff. The log statements. That's where you combine the other elements and so you can reference sources that you set up above. Filters that you set up above and destinations in whatever combinations trip your trigger. So that's SyslogNG. Flexible. Marvelous. Another cool thing about SyslogNG by the way, SyslogNG supports logging over TCP 514. By default Syslog, plain old BSD Syslog only uses UDP 514. That means that it's not as reliable and it means that it's not so easy to tunnel. So that's a feature worth mentioning. What's the other thing I was going to say about it? Oh, I believe there's also a... Nicholas, what was that thing you were telling me before? Your mind was telling me about some kind of throttling. Is there some kind of throttling in SyslogNG now? I was too lazy to write this down. So... You can have target every X minutes to tell you how many packets it lost and to affirm to you that it's still alive. Thanks a lot. Okay, not actually throttling but you can have it tell you statistics about how many packets it drops if in fact it does wind up having to drop packets. That's something that Syslog won't do. If Syslog drops packets, remote log packets, you never even know about it. Okay. I could go on and on about SyslogNG. It's really groovy and Bashe is such a sweet guy. But I'm going to go on and talk about automated log watchers. The payoff as aware of the technique. Once you've figured out what to look for, you can configure some other application to look for it for you. The one that I cover in the log chapter in my book is SWatch or Swatch, the simple watcher. I don't know if I like Swatch as much as I used to. For one thing it hasn't been updated since like 2000. For another, being a Perl script it's got a certain amount of overhead associated with it. Thank you. And I was running it on this machine this morning. This thing is I think a M266. I was really shocked by the CPU hit that I took from running Swatch. I'm not trying to dissuade anyone from examining Swatch because it's one of a fairly small number of tools that will watch a log file in real time. That will basically tail a log file and watch it for specific strings. What I do want you to know is that your mileage may vary. Don't throw Swatch on a production system. Configure it and leave it running overnight in hope for the best. Bench test it first and make sure that it doesn't have any deleterious effects on your system. You want to do that anyhow because it's got a really fussy configuration syntax. If you just type some stuff and fire it up it may or may not work the way you intend it to. The good news is that the Linux distros each come with their own log watchers of various types. Red Hat now has got one called Log Watch. I'm told that there's a different tool by the same name that's older. That one I don't know. I have some familiarity with Red Hat's Log Watch. Log Watch is cool because unlike Swatch it has its own brains. It has its own rules that constitute Log Weirdness. And it's customizable of course as well. Log Digest is Suze's equivalent of that and it does not tail an active log file. It runs as a cron job. In other words it's a script that you run once in a while to parse your logs and report on any weirdness that it finds. It's not very well documented but it's a really easy script to reverse engineer even if you don't know it's not in Perl. Never mind. It's easy to reverse engineer. All of the configuration information is kept in Etsy Log Digest. The interesting files there are Ignore which is where you can specify strings that it should ignore if it sees. And then the other one is oh let's see I'm spacing out what it's called. Oh wait I wrote it down. And I misplaced the notepad. Alarming. Alarming. That's the name of the file. That's where you look for stuff that is alarming. So if I cat that file Shoot. Bear with me here. Okay. This is where you can specify strings that you want Log Digest to look for. This way. Okay. Now it's time to open the floor to beating up on this box. I've got oh wow there's some strange stuff in my log right now. Holy cow. That's the most juicy invalid method request I've ever ever seen. Can you see that on the bottom? Did anybody here perpetrate that? Because if they did that's worth a prize. Beg your pardon. I'm not entirely parsing you. Something about the second layer. Are you getting me? Are you doing it? I will flood you with misconfigure with my formed layer 2 frames. In this case using Fata Jack, Air Jack. So I wonder if that can produce anything and I also wonder if I can sneak under the login in your case. So I don't know maybe it's just noise. Maybe it's a red noise which does it. Yes. Yes. Layer 2 attacks. Well, the gentleman said that what he's doing and so he's wondering if it's maybe maybe if it caused that message, maybe if it's sneaking under my radar. And the answer to that is malformed packets and layer 2 attacks constitute denial of service and I'm not going to give any prizes for that. Well, okay, consolation prize. Fine. The consolation prize is an SBUS scuzzy interface with a black and, oh no, GX frame buffer. Hot damn. There. Are you happy now? Are you happy kids? That's the only DOS attempt that I'm going to give prizes for though. I've got my morals. Sure. What else we got here? I've got some undersized frames received. I think that was the same thing. 192.168. 77.4. Oh, that's a broadcast. Okay, never mind that. And in case you missed it, my victim host is located at 10.25.25.2 with a class C subnet mask and an ESSID of Wazala WUZZALA. Oh, I see. You're right, my terminal got corrupted somehow. Oh, okay, there we go. Thank you. That hasn't happened to me like in three years. I totally missed that. Okay. Ooh, thank you. Okay, who said that? Who's 25.69? Someone gets a prize for complimenting the kill. All right. Oh, yes. I know him. A prize over there. Raise your hand again, please, so the goon can spot you. Right over here. Yeah. Yeah. How could you tell? How could you tell if it were broken? I'm not even sure what that is. Is that a repeater of some kind? Hmm? Ooh, cool. Prizes, by the way, were donated by Uncle Ira from Miko. So, buy stuff from Uncle Ira. Very cool guy. Okay, so what else here? These are all from 25.69. Is that all you, Tony? Oh, wait, there was something fairly involved. Man, you were really going to town, man. Did you root me? I've only got two minutes. You've got two minutes left to gain a prize. Come on, have added. I got junk to give away here. Okay. Be that way. So then, maybe I'll ask a trivia question. Okay. What is the list price of my book? No, that's lame. Never mind. I retract it. Oh, wait. Yes, sir. $44.95. Yes, JBL gets a prize for answering the lamest trivia question at DEF CON ever. J, it does whatever you're elite enough to figure out it does. That's what it does. Ooh, okay. Okay, who's got 25.79? Who's 25.79? Yes, we've got a lucky winner. All right. And I'm quite delighted to end my talk on that note. Thank you very much.