[00:00.630 --> 00:03.200]  Please enjoy taking a bite out of logs with Sagan.
[00:03.820 --> 00:06.200]  I present to you Da Beave Champ Clark III.
[00:10.270 --> 00:10.910]  Thank you.
[00:11.510 --> 00:12.190]  All right.
[00:12.630 --> 00:13.450]  Let's do this.
[00:13.610 --> 00:16.250]  I got to work some time in here from Steve.
[00:16.390 --> 00:17.830]  So my name is Champ Clark.
[00:17.950 --> 00:19.130]  I do a little project.
[00:19.250 --> 00:19.870]  It's called Sagan.
[00:20.390 --> 00:22.710]  And so Sagan basically is a log analysis engine.
[00:22.830 --> 00:28.690]  And if you're interested in it, these are the websites you can go to down at the bottom there in the yellow to get more information about them.
[00:28.690 --> 00:35.230]  The top one is the main site where the source code and things like rule sets and stuff like that can be found.
[00:36.230 --> 00:41.030]  So one thing I do want to mention before I get started, I'm one of the founding members of these guys.
[00:41.610 --> 00:45.130]  And downstairs this year we have a GSM network set up.
[00:45.230 --> 00:48.150]  And actually that's largely due to Jay Falcon's effort.
[00:48.290 --> 00:52.850]  So basically it's a GSM network that you can use and make calls through your cell phone.
[00:52.870 --> 00:56.090]  You just need a cool Telephreak sim like that.
[00:56.210 --> 00:57.450]  And you can find those guys downstairs.
[00:58.410 --> 01:00.330]  Jay Falcon's done a really cool job with that.
[01:01.290 --> 01:05.410]  Oh, and yes, and pay phones are set up and whatnot in the Telephreak area.
[01:05.690 --> 01:07.030]  So just briefly, who am I?
[01:07.030 --> 01:08.230]  I'm a security researcher.
[01:08.230 --> 01:10.310]  I work for Quadrant Information Security.
[01:10.630 --> 01:13.370]  I did a couple of books a while back, mostly on Asterisk.
[01:14.010 --> 01:19.450]  I've done a lot of, most of the time whenever I speak at events, it's usually on voice over IP and things of that nature.
[01:20.010 --> 01:23.010]  And I'm freaking, but this year I'm kind of changing it up a little bit.
[01:23.010 --> 01:24.810]  As I said, the founder of Telephreak.
[01:24.970 --> 01:28.590]  I'm also, I also run this program called the OpenVMS Death Row Cluster.
[01:28.770 --> 01:39.850]  It allows people to connect to it and play with the OpenVMS operating system, which is a older operating system that not as many organizations use nowadays.
[01:40.250 --> 01:42.310]  Everybody's kind of moved over to UNIX based.
[01:43.210 --> 01:46.990]  And it was used for Defcon CTF prequals this year and all kinds of stuff.
[01:46.990 --> 01:50.690]  And I'm kind of into defensive computing whenever I say that.
[01:50.850 --> 01:55.890]  What I'm talking about is writing software that helps you detect attacks happening in a network.
[01:56.790 --> 01:58.170]  So just to get to it here.
[01:58.790 --> 01:59.810]  So what is Sagan?
[01:59.950 --> 02:01.450]  Sagan is an open source project.
[02:01.590 --> 02:02.290]  It's multi-threaded.
[02:02.410 --> 02:08.310]  It runs on a UNIX type of environment, be it Linux, OpenBSD, whatnot.
[02:08.410 --> 02:10.530]  We don't currently support Windows.
[02:10.790 --> 02:13.230]  We don't use Windows in our environments.
[02:13.230 --> 02:17.490]  So there's no plans on porting it over, but it should be fully possible.
[02:17.830 --> 02:19.970]  And open source GPL version 2.
[02:21.150 --> 02:24.710]  And it's a multi-threaded engine to analyze logs.
[02:24.870 --> 02:44.190]  And we do multi-threaded to keep it so that whenever it has to do things like write to a database or anything like that, Sagan, the primary engine, can monitor logs as thousands of logs are coming in and then turn around and be able to insert into a database or whatnot without having to interrupt the process of analyzing those logs.
[02:44.830 --> 02:47.310]  And there's other systems out there.
[02:47.410 --> 02:49.610]  There's other software that do very similar things.
[02:49.670 --> 02:52.130]  But we kind of do it with a little bit of a twist.
[02:52.670 --> 02:56.590]  What we're trying to do is write the best log analysis engine that we can come up with.
[02:56.790 --> 03:00.230]  So we're trying not to reinvent the wheel.
[03:00.230 --> 03:03.890]  And as I said, we want it to be the best log analysis engine that we can do.
[03:04.050 --> 03:12.290]  And the way that we try to prevent reinventing the wheel is we leverage a lot of stuff that's already been done in Sourcefire Snort.
[03:12.610 --> 03:19.050]  Now, Sagan, other than the things that I'll go into, we don't share source code with Snort.
[03:19.250 --> 03:21.230]  And how many people are familiar with Snort?
[03:21.950 --> 03:23.670]  Yeah, I kind of figured that would be the case.
[03:25.590 --> 03:32.750]  So it's for the people who aren't familiar with it, Snort is a packet analysis engine.
[03:32.930 --> 03:35.210]  Basically, it's an IDS engine, intrusion detection.
[03:35.430 --> 03:36.870]  And so it has rules.
[03:36.870 --> 03:41.510]  And if rules get triggered in the network, it can fire it off alert and whatnot.
[03:41.670 --> 03:42.910]  And it uses pre-processors.
[03:43.090 --> 03:52.190]  So Sagan takes some of the ideas from Snort and does some very similar things idea-wise.
[03:52.190 --> 03:52.930]  Excuse me.
[03:53.550 --> 03:54.990]  But they're not the same code base.
[03:55.090 --> 03:57.750]  They're not anything related other than a few little things.
[03:58.790 --> 04:03.710]  So one of the reasons that we use the same structure is that we can log to a SQL database.
[04:03.830 --> 04:06.010]  Same SQL databases that Snort uses.
[04:06.310 --> 04:07.750]  But I'll get to that a little bit later.
[04:07.950 --> 04:13.070]  We can write to unify to output, which is good for things like queuing.
[04:13.170 --> 04:16.210]  And if you're a Snort guy, these terms all make kind of complete sense to you.
[04:16.350 --> 04:21.170]  And another thing, too, is we build our rule sets for our log analysis engine very similar to Snort.
[04:21.170 --> 04:26.370]  And then that way we can utilize tools out there for rule management.
[04:26.670 --> 04:38.190]  Basically, my point is we're trying to do things in a way so that we can concentrate on writing a good log analysis engine and not worry about where the data goes or how to manage rules with it.
[04:38.290 --> 04:40.970]  So we're going to use a lot of the same technology.
[04:41.050 --> 04:43.790]  And we do this primarily for correlation.
[04:43.790 --> 04:48.810]  So as I said, so Sagan can write to the same database as a Snort engine.
[04:48.930 --> 04:53.910]  Where your IDS data goes to, your intrusion detection data, Sagan can write to that same type of database.
[04:54.210 --> 05:04.270]  And that makes it kind of interesting because then if you have reports or anything that you run, you'll have not only your packet level information, but you'll have your log information in there as well.
[05:04.270 --> 05:05.810]  And then we can cross-reference stuff.
[05:05.910 --> 05:10.050]  We can show me just the types of logs that look like attacks.
[05:10.150 --> 05:13.050]  Or show me just the packets that look like just kind of attacks.
[05:13.150 --> 05:15.470]  Or show me them together and get some kind of correlation.
[05:15.850 --> 05:28.130]  And we cross-reference stuff like through log normalization, but we cross-reference things like the source IP address, the destination IP address, the protocol being used, things of that nature, or even by the classification.
[05:28.130 --> 05:38.930]  So, for instance, if Snort classifies a packet as an attempted user and we have a log that can be generated, we'll also classify it as an attempted user.
[05:40.050 --> 05:44.130]  So basically, the idea behind it is you have all these logs.
[05:44.390 --> 05:46.770]  Sagan works best in a centralized log environment.
[05:46.770 --> 05:55.490]  So if you think about all your network gear and all your machines and whatnot, they're sending it all to a centralized point where all the logs are aggregated.
[05:55.550 --> 05:57.550]  And that can be for archiving or whatnot.
[05:57.550 --> 06:06.210]  And what we use to collect those logs can be syslog ng, rsyslog, and basically feed Sagan the logs that are coming in.
[06:07.070 --> 06:09.030]  Sagan can also do this kind of nifty thing.
[06:09.170 --> 06:13.650]  So let's say you already have in your environment a centralized logging setup.
[06:14.050 --> 06:24.610]  Well, Sagan can go in kind of a sniffer mode and basically sniff the wire, like if you set up a span port, and sniff the wire and pull the logs off the wire as they're going to your centralized backend.
[06:24.610 --> 06:30.630]  And the reason that's kind of interesting is because people might buy a arc site or something that's very, very expensive.
[06:30.890 --> 06:34.530]  And redesigning the entire network isn't something that they want to do.
[06:34.530 --> 06:38.690]  So what this allows you to do is sniff the logs and not change anything in the network.
[06:38.870 --> 06:40.250]  So that's kind of one nifty feature.
[06:42.690 --> 06:49.250]  And so we can do correlation between the log stuff and the IDS stuff across several points.
[06:49.410 --> 06:51.790]  Obviously, timestamps being one of them.
[06:52.030 --> 06:56.170]  Of course, I'm sure everybody runs something like, you know, network time protocol, NTP.
[06:57.150 --> 06:59.190]  You can do, as I said, by source and destination.
[06:59.350 --> 07:00.270]  You can also do by protocol.
[07:00.430 --> 07:02.290]  I'm going to get into this pretty quickly.
[07:02.290 --> 07:07.030]  Sometimes the port, the target port, the source port, and the classifications.
[07:08.410 --> 07:13.370]  So how are these events actually normalized or, excuse me, correlated?
[07:13.610 --> 07:15.570]  And that's actually through log normalization.
[07:15.790 --> 07:20.150]  And we use several different techniques to extract useful information out of logs.
[07:20.150 --> 07:28.850]  Because typically in syslog, and I'm talking about traditional syslog, like how it works, the source and destination in syslog are a lot of times kind of useless.
[07:30.010 --> 07:31.870]  Not all the time, but in a lot of cases.
[07:32.290 --> 07:37.990]  So if we take, like, our fake company here, they have a centralized logging environment.
[07:37.990 --> 07:49.710]  And all the logs in the company, all their Windows servers or routers, everything is going to 10.10.0.5 and the target IP address, that's who the attacker is attacking.
[07:49.710 --> 07:55.790]  It's 10.10.0.10 and the attacker's real IP address is 192.168.1.50.
[07:57.070 --> 08:00.410]  And so what becomes the syslog source and destination?
[08:00.990 --> 08:08.930]  Well in a regular syslog message, it's going to be the source is the machine that generated the log event, 10.10.0.5, and I know this is kind of confusing.
[08:09.670 --> 08:14.710]  And the destination will be to the centralized logging server, 10.10.0.10.
[08:14.710 --> 08:20.150]  Well, that's very interesting, but it doesn't tell you where the attacker's IP address.
[08:20.410 --> 08:22.690]  And basically, I consider that kind of lame.
[08:23.710 --> 08:29.050]  So all is lost, though, because there's information that's actually inside the message that's kind of crucial.
[08:29.210 --> 08:31.450]  And that's where the log normalization comes in.
[08:31.790 --> 08:38.030]  So if we look, let's say, just for instance, this is our attack message, this is what we'll call it.
[08:38.030 --> 08:38.470]  Okay?
[08:38.730 --> 08:43.210]  There's lots of good information in here, probably most of you can probably figure out which information that is.
[08:43.410 --> 08:48.610]  Now, the traditional syslog source and destination are fairly much useless.
[08:48.750 --> 08:56.330]  But as we can see in here, we have some of the data that shows us that 192.168.1.50 is attacking this machine.
[08:56.670 --> 09:01.670]  And Sagan knows how to extract this information and basically use it in such a way that it's actually usable.
[09:01.670 --> 09:10.870]  So whenever you want to go through and find events in your database, you'll find the real source of the attack, not just the syslog source.
[09:11.070 --> 09:16.110]  And it can extract out a lot of useful information of just basically this slide.
[09:16.770 --> 09:20.610]  For instance, we already know we record timestamps, so we already know we have a correlation point right there.
[09:21.410 --> 09:23.230]  It knows that this attack is TCP.
[09:23.790 --> 09:28.450]  It also knows that the port is likely port 22 because that's what OpenSSH uses.
[09:28.930 --> 09:38.690]  The source port is 6500, invalid login, the B, the true source of the attack, 192.168.1.50, destination.
[09:39.330 --> 09:40.990]  And then we attempt to do the classifications.
[09:41.550 --> 09:46.850]  So, but really you might ask, well, how do you know that, you know, just from that little bit of information?
[09:47.250 --> 09:53.590]  Well, as I said, we'll notice in our syslog message right here, the program that actually is generating the event is SSHD.
[09:53.590 --> 09:55.970]  Again, we know it's a TCP protocol.
[09:56.230 --> 10:02.390]  It's typically port 22 that would be being, quote, attacked in this case.
[10:03.890 --> 10:06.350]  And the rule set actually defines that.
[10:06.450 --> 10:07.490]  It will be port 22.
[10:07.710 --> 10:12.310]  So, if you actually run SSH on port 2222, you can just change the rule set.
[10:13.270 --> 10:17.410]  And the rest of this stuff we can pull out, as I said, like the source.
[10:17.410 --> 10:20.550]  The source actually becomes the destination, which is kind of strange, but...
[10:20.550 --> 10:28.470]  And then we store all this information into our snort database, the same place that we're storing our IDS events.
[10:30.250 --> 10:32.250]  And why would we want to do that?
[10:32.370 --> 10:36.350]  Well, for one thing, keep in mind, I'm talking about not reinventing the wheel.
[10:36.530 --> 10:46.950]  So we can take advantage of, for instance, consoles that are already used in the IDS and IPS world for snort, be it's proprietary consoles or open source consoles.
[10:47.070 --> 10:52.930]  So basically, if the console works with snort and it writes to a snort database, Sagan can utilize that.
[10:53.010 --> 10:54.450]  You don't have to do any retooling.
[10:55.470 --> 11:00.330]  So just like, for instance, this is a buddy of mine, Dustin Webber's project.
[11:00.510 --> 11:06.690]  It's called Snorby, which is a great front end for looking at IDS events.
[11:06.750 --> 11:08.350]  And in my personal opinion, it's probably one of the best.
[11:09.370 --> 11:18.830]  So if we look in here, it looks like right off the bat that this information is just all your, if you're familiar with Snorby, that this information is just IDS related.
[11:19.130 --> 11:22.970]  But you'll notice in the green, actually the green stuff is actually log base events.
[11:23.170 --> 11:26.590]  And then all the other stuff, all the other colors are basically your IDS events.
[11:26.750 --> 11:30.850]  So we can take advantage of, we don't have to worry about now writing consoles for this.
[11:31.050 --> 11:37.570]  And then you can break it down, like even with Snorby, make more sense out of the data about what the threat priorities were, or whatnot.
[11:38.030 --> 11:43.050]  Or even break it down to what kind of signatures were being triggered.
[11:43.310 --> 11:46.630]  Like for instance, a lot of these are actually Sagan signatures.
[11:46.870 --> 11:53.570]  So you're taking this data and you're putting them into the same place so that you can correlate them, look at them different, different ways.
[11:55.070 --> 12:01.630]  And from the, the standpoint, like in this particular slide, we're actually looking at log data.
[12:01.930 --> 12:07.770]  To a person who's familiar with Snort or Snorby or whatnot, at first glance, you would say this looks like IDS data.
[12:08.030 --> 12:12.470]  But this is actually both, but this is, in this particular case, I'm only looking at log data.
[12:12.730 --> 12:13.510]  It's not IPS.
[12:13.870 --> 12:15.350]  And that's kind of the, the point.
[12:17.510 --> 12:30.910]  So basically what happens is Sagan, whenever it sees an event, he creates a pseudo packet and inserts it into the database, the Snort database, because remember Snort and IDS, stuff like that, work at a packet level, what we're dealing with a log level.
[12:31.070 --> 12:36.750]  So we actually do some trickery to create a packet that goes into the database.
[12:37.150 --> 12:42.650]  And you'll notice in the payload area is actually the log message that tripped the event.
[12:42.650 --> 12:48.790]  And then we also add in our source address, our destination, timestamps already a given, and classification.
[12:49.390 --> 12:55.150]  And obviously we're fudging some of this stuff because we're dealing with a log event and not a network event.
[12:55.150 --> 12:59.510]  So we don't have, for instance, you know, time to live in this type of packet.
[12:59.610 --> 13:01.310]  So obviously we set some of that stuff to zero.
[13:03.170 --> 13:06.090]  And you know, so, and it doesn't really matter.
[13:06.270 --> 13:11.190]  So for instance, if you wanted to use a squeal, you could do the same thing.
[13:11.190 --> 13:17.830]  So basically my point is all your stuff goes into one place and that you can, you can correlate it and use it.
[13:17.990 --> 13:21.890]  And from our standpoint, the security console doesn't matter to us.
[13:22.030 --> 13:27.330]  So again, we can always concentrate just on being a better log analysis engine.
[13:27.870 --> 13:29.530]  And again, we don't worry about it.
[13:29.590 --> 13:31.330]  For instance, this is an older project.
[13:31.570 --> 13:34.910]  Probably some of you, if you're familiar with Snort, might remember Base.
[13:35.370 --> 13:37.070]  So Base is one of those out there.
[13:37.190 --> 13:37.930]  It's by Kevin Johnson.
[13:37.930 --> 13:41.310]  It's no longer really maintained anymore, but people still use it a lot.
[13:42.370 --> 13:47.250]  And what we have is, this is actually a wireless IDS system that I was using, but it's still, again, syslog data.
[13:47.450 --> 13:54.470]  My point is, whenever you look at this, it's not, it's not, the log data gets treated kind of like IDS data.
[13:54.550 --> 13:56.330]  It gets just inserted into the database.
[13:56.650 --> 14:01.450]  Again, here is our payload, our quote payload, which is actually the log event that triggered the event.
[14:01.570 --> 14:03.790]  Or you have things like Prelude.
[14:03.790 --> 14:07.830]  Maybe Prelude's more your speed, which does some really nice grouping and things of that nature.
[14:09.090 --> 14:15.090]  And again, once again, you know, the payload becomes the, is the log message that generated the event.
[14:15.270 --> 14:20.270]  So what we're trying to do here is it doesn't matter which console that you want to use.
[14:20.450 --> 14:22.570]  You just pick your favorite one and move on.
[14:22.570 --> 14:33.470]  Even if it's, even if it's a proprietary console, it's something that you wrote in house only for you to use to query your IDS backend and generate pretty reports so the managers can use it.
[14:33.590 --> 14:34.210]  It doesn't matter.
[14:34.330 --> 14:43.170]  You can use that exact same software to generate now reports that go off log data to generate pretty pictures so you can hand them to a manager and he's really happy about it.
[14:46.510 --> 14:53.650]  So, the other thing that we do, we also keep our rule sets very, very similar to how Snort does it.
[14:53.810 --> 14:55.270]  We use a very similar structure.
[14:55.450 --> 14:59.230]  And the reason that we do that is, again, the management of the rules.
[14:59.550 --> 15:13.150]  For Snort people, you might remember there's programs like Pulled Pork and Oink Master, we're downloading your rules every night and disabling certain rule sets and doing all this, you know, kind of cool stuff to customize the rules for your environment.
[15:13.370 --> 15:14.350]  You don't have to retool.
[15:14.590 --> 15:17.830]  You use the exact same software to manage the Sagan rules.
[15:18.030 --> 15:20.130]  Again, trying not to reinvent too much of the wheel.
[15:22.670 --> 15:31.330]  So if we look at something like this, our pseudo attack, we'll write a really basic rule for it.
[15:31.630 --> 15:37.830]  Now, actually, I was showing a friend of mine this talk and he got really confused because he looked at this particular...
[15:37.830 --> 15:38.430]  This is a rule.
[15:38.570 --> 15:39.490]  This is a Sagan rule.
[15:39.490 --> 15:41.710]  And he looked at this and thought it was a Snort rule.
[15:41.950 --> 15:49.490]  Yep, that's actually the idea, is that they should look very similar, but it was confusing as hell to him because he didn't realize we were talking about logs.
[15:49.790 --> 15:55.030]  So this is like about the most basic you can get with a Sagan rule.
[15:56.750 --> 15:58.710]  One thing that I'd like to point out.
[15:59.130 --> 16:11.750]  So in the Snort world, the very top part, at the packet level, you're telling Snort when, I want to watch for TCP traffic going to port 22 in my home net.
[16:12.050 --> 16:13.830]  Obviously, we're dealing with logs.
[16:14.030 --> 16:15.070]  So this is a little bit different.
[16:15.350 --> 16:29.310]  What we're saying is when this part of the rule gets triggered in Sagan, we are telling Sagan that this is considered a log message that was generated by a program that is TCP protocol.
[16:29.310 --> 16:33.950]  And the port is usually port 22, which is obviously you can change.
[16:34.190 --> 16:37.810]  But the idea is that you're kind of telling Sagan.
[16:37.890 --> 16:39.490]  So you actually kind of flip around.
[16:39.710 --> 16:41.590]  And this actually confuses the hell out of people.
[16:41.650 --> 16:44.990]  So if you have questions about it later, maybe ask me on the side.
[16:45.390 --> 16:48.170]  But we kind of flip around the meaning of how this works.
[16:49.710 --> 16:55.330]  So yeah, so it's basically Sagan knows that it's port 22 from looking at this.
[16:56.330 --> 17:00.770]  So if we look, our first part is the messages of the human readable format.
[17:00.910 --> 17:04.830]  This is the alert that pops up that might get emailed to you or put into a database.
[17:05.030 --> 17:12.270]  This is the part that, you know, tells the end operator or whatnot, looking at a console, that this was an invalid user attempt.
[17:14.770 --> 17:16.950]  Then the next part is actually what we're looking for.
[17:16.950 --> 17:20.090]  We're looking for the term invalid user.
[17:20.250 --> 17:20.670]  Pretty simple.
[17:21.050 --> 17:22.990]  Basically, just as a simple string match.
[17:23.350 --> 17:28.550]  We can use PCRE or excuse me, regular expressions, which I'll get into a little bit later.
[17:28.970 --> 17:34.850]  But a little bit extra overhead whenever you're using regular expressions like PCRE kind of libraries.
[17:35.150 --> 17:41.570]  And we're trying to make this really fast because we in some cases where we use it, we're dealing with 10 to 15,000 log lines a second.
[17:41.810 --> 17:45.230]  And we don't have, you know, we got to make it very efficient is my entire point.
[17:45.950 --> 17:48.870]  And then this is the program that actually generated the message.
[17:48.930 --> 17:54.310]  Remember earlier, so we know we're only going to search through logs that are generated by the program SSHD.
[17:54.630 --> 18:00.290]  In some cases, you might only want to search certain types of logs for certain types of events.
[18:00.290 --> 18:09.590]  So it's that it takes more CPU time to sit around and analyze every log for some type of event if and for stuff that you're not interested in.
[18:09.710 --> 18:15.670]  So you can actually break it down and tell it, I only want to search for this type of program generating this type of event.
[18:16.690 --> 18:17.550]  And it'll sift through.
[18:17.590 --> 18:20.070]  It also makes it a little bit more efficient if you can break it down that way.
[18:20.230 --> 18:25.190]  And then we can give it a priority level, which is priority number one, the highest level priority.
[18:26.170 --> 18:29.150]  And then we have a unique signature ID.
[18:29.670 --> 18:35.750]  All Sagan rules start at 5 million to keep away from snort rules and stuff like that.
[18:35.830 --> 18:36.990]  So we start at 5 million.
[18:37.510 --> 18:40.610]  Snort rules, of course, you know, started real low.
[18:40.810 --> 18:43.410]  I think emerging threat rules start at like 2 million.
[18:43.750 --> 18:45.610]  So our rule sets start at 5 million.
[18:45.690 --> 18:47.570]  So you can keep kind of still everything kind of separated.
[18:47.890 --> 18:50.250]  And then obviously, you have a rule revision.
[18:50.250 --> 18:53.330]  So every time you make a modification, you increment your revision.
[18:53.330 --> 19:02.590]  So not only does the back-end database and everything know that the rule revision has changed and that maybe, you know, I need to look at things differently, you can keep track of what the hell is going on.
[19:02.950 --> 19:06.570]  So for a basic rule for what we just did, that's pretty much it.
[19:07.490 --> 19:12.870]  But in reality, life is more complicated than that.
[19:13.330 --> 19:17.670]  And obviously, with port 22, you see things like brute force attacks and stuff like that.
[19:17.670 --> 19:25.930]  So what we're going to do, just briefly, is kind of get this, just throw in a few extra directives into the rule.
[19:26.170 --> 19:28.490]  So remember, we have the content user.
[19:28.770 --> 19:30.150]  You'll notice the no case now.
[19:30.390 --> 19:34.710]  Basically, if I'm searching for content, it's going to be search for case insensitive.
[19:34.990 --> 19:39.690]  We changed our priority, we've removed, and we've made now a classification type.
[19:39.690 --> 19:52.950]  So remember, as I said, Snort might, if it has a kind of a similar kind of IDS signature, and we can kind of match it up with a log signature, it might classify it as an attempted user.
[19:53.070 --> 19:54.210]  We attempt to do the same thing.
[19:54.370 --> 19:59.290]  An attempted user happens to adopt the priority of that particular classification.
[20:01.010 --> 20:06.170]  And as I said, we can do regular expressions, and those are great.
[20:06.910 --> 20:10.850]  But a lot of times, it makes things, your rules look really, really ugly.
[20:11.190 --> 20:18.050]  And so what you can do is mix and match your content and PCRE kind of stuff, your regular expressions.
[20:18.830 --> 20:24.070]  Sometimes you need to have regular expressions, because it's just easier to get the rule to do what you want it to.
[20:24.270 --> 20:29.350]  So our thing is, like, use content when you can, use regular expressions whenever you have to.
[20:30.030 --> 20:40.050]  As I said, and that's for more of a speed factor, because whenever you get into dealing with thousands of thousands of log lines, you want to make your system as fast or as efficient as possible.
[20:40.630 --> 20:45.510]  So just always throwing regular expressions at the problem isn't always the best thing.
[20:46.310 --> 20:53.170]  But what I'm going to do here, just to keep things kind of simple, is we'll just use the Perl compatible regular expressions.
[20:53.310 --> 20:54.630]  That's what the PCRE stands for.
[20:54.770 --> 20:59.810]  And we'll just look for invalid user or illegal user, just to keep it kind of simple.
[20:59.810 --> 21:05.690]  Now, as I said, this is a kind of a thing that we also share with Snort.
[21:05.770 --> 21:08.130]  People brute force SSH all the frickin' time.
[21:08.390 --> 21:20.450]  So, in previous rules, if you had put that in an environment, and let's say you had a pen-tester come by or an external facing piece of hardware, you're going to get SSH attempts all the time.
[21:20.590 --> 21:26.130]  And then you'll go into your console and you'll have 20,000 events of somebody trying to SSH in.
[21:26.130 --> 21:34.750]  Well, the problem with that is that now you have these 20,000 events and you're having to sift through those to find the two that you actually care about.
[21:34.990 --> 21:37.230]  So, what we can do is things like thresholding.
[21:37.310 --> 21:44.770]  So, we can actually say if you see this event and it happens more than five times within a five minute period, threshold it.
[21:45.210 --> 21:49.970]  You tell me five times, that's probably about the max I need to know that something's going on and probably react to it.
[21:50.110 --> 21:54.530]  So, there's no reason for me to fill up my console with lots of data.
[21:55.630 --> 21:58.270]  And then after five minutes, that thing gets cleared out.
[21:58.450 --> 22:01.910]  And then, you know, for instance, like you say, they stop attacking you, then you come back.
[22:02.290 --> 22:05.310]  They come back a little bit later the next day, then it'll start back up again.
[22:05.530 --> 22:06.370]  And that's pretty good.
[22:06.470 --> 22:07.650]  That helps limit some things.
[22:07.830 --> 22:15.810]  But then we also added in, this is one thing that, for instance, Snort doesn't have, is a after directive, which basically says, after you've actually might have it.
[22:15.990 --> 22:20.370]  But anyways, after you've had this event happen so many times, so then send off an alert.
[22:20.610 --> 22:31.050]  So, for instance, if I, with the previous example, it's still going to capture every, every time somebody logs in five times, it's going to generate those five events.
[22:31.190 --> 22:33.170]  But the fact is, I mistyped passwords.
[22:33.330 --> 22:34.770]  I'm sure everybody does at some point.
[22:35.030 --> 22:40.490]  So, what you want to say here is basically, don't tell me until it's happened three times.
[22:40.650 --> 22:43.550]  And then after that, threshold it once you get past a five point.
[22:43.730 --> 22:49.870]  So, if Bob, the developer, tries to log into a machine and he fat fingers his password, then you don't get alerted.
[22:49.970 --> 22:53.130]  But if Bob does it three times, there might be something else going on.
[22:53.230 --> 22:56.570]  If Bob does it a thousand times, well, shit, there's obviously something going on.
[22:57.990 --> 23:04.690]  But as you might notice in all this, there's a lot of detection talk, but there's not really any log normalization.
[23:04.970 --> 23:08.670]  So far, we've only talked about how to detect some of these type of events.
[23:09.450 --> 23:13.730]  And basically, what we use is the normalized directive.
[23:14.430 --> 23:22.710]  So, basically, whenever you add this to a rule, you create a... into your rules file, you create another file.
[23:22.790 --> 23:23.710]  It's called a rule-based file.
[23:23.870 --> 23:35.770]  And basically, it says the type of event that I'm going to attempt to normalize, I'm going to attempt to extract useful information out of, the log message with, is going to be SSH, open SSH.
[23:36.730 --> 23:42.210]  And then, so that way, instead of having to go through its entire rule base saying, well, is this a Cisco log?
[23:42.330 --> 23:43.250]  Is this a blah, blah, blah log?
[23:43.290 --> 23:45.770]  You can actually say, no, this is going to be freaking SSH.
[23:45.970 --> 23:46.610]  Just look for that.
[23:46.910 --> 23:51.690]  So, and there's other ways that we can do normalization, but this is probably like one of the better ones.
[23:51.770 --> 24:02.530]  We have some directives where you could do dynamically fine IPs in a particular log, but those have a lot more overhead than using this, liblog norm.
[24:03.030 --> 24:05.470]  And liblog norm was started by a guy named Rainer.
[24:05.630 --> 24:07.390]  He's he's the author of rsyslog.
[24:07.870 --> 24:16.150]  And, which is great because I was looking at writing a very similar utility, and I was thinking this is going to suck, and he already started on it.
[24:16.230 --> 24:16.830]  So that was great.
[24:17.390 --> 24:19.630]  And it kind of works off of a masking system.
[24:20.230 --> 24:27.730]  So if you, if you look at it, you take an event like this, so you know where the information is.
[24:27.830 --> 24:31.030]  And as I said, these are, these are really good for a very dynamic type of log event.
[24:31.230 --> 24:35.490]  You know, like visually, you can look at it and get a good idea of where the events are.
[24:35.690 --> 24:41.590]  But the way that the liblog norm rule base loads it, that's a part of Sagan, it'll look more like this.
[24:41.770 --> 24:49.550]  So what it's basically saying is the invalid user, and then you'll notice the percent sign user colon word percent sign.
[24:49.730 --> 24:55.950]  And basically the user name is the variable, and then I'm telling liblog norm it's going to be a word.
[24:56.150 --> 24:58.510]  And then the same thing with the source IP.
[24:58.510 --> 25:04.770]  So it's saying, I'm storing it into a variable called source IP, and it's going to be IPv4.
[25:04.910 --> 25:06.610]  So look for something IPv4.
[25:06.750 --> 25:09.610]  And then the number, and they have several different types of variables.
[25:09.710 --> 25:17.970]  And what we try to do, anybody who's really kind of into logging, we try to keep up with the common event expressions, the CEE.
[25:18.290 --> 25:22.250]  We kind of try to use the same thing so that later on, hopefully we don't have to change a bunch of crap.
[25:23.690 --> 25:27.870]  And right now we have a pretty good amount of rule sets.
[25:28.110 --> 25:39.850]  And that's actually where people who are interested in log analysis that are coming from syslog or event logs that are being sent from their Windows server to their centralized backend can help us.
[25:40.070 --> 25:47.710]  Every time that we have a new rule set, for instance, I had somebody donate some HP pro curve rules, we can add that to our arsenal.
[25:47.950 --> 25:54.930]  And then we put it in and then maybe you have that similar piece of equipment so you gain from his experience of writing the rule sets.
[25:55.070 --> 25:56.690]  And we add in stuff as we go along.
[25:56.810 --> 25:58.430]  And we have thousands of rule sets out there.
[25:59.250 --> 26:05.130]  If you'll notice, we have even things like bash, which is the command shell, bash shell.
[26:05.370 --> 26:16.930]  You can do something really cool with bash in that you can tell it, instead of storing your history file where all your commands that you've been typed, instead of storing it to a file, send all that information over to a syslog server.
[26:17.130 --> 26:22.070]  And what's interesting about that, then if somebody goes in and says, well, I'll just wipe out my history, well, it's too late.
[26:22.150 --> 26:22.990]  It's already being sent.
[26:23.170 --> 26:35.870]  And so from our standpoint, if we have, for instance, a a production environment, we can say, if you ever see somebody running in map in our production environment, maybe tell me about that.
[26:35.970 --> 26:38.910]  Because nobody's supposed to be doing that in this production environment.
[26:39.090 --> 26:46.370]  Or running an a out file out of the temp directory, you know, that could maybe be a little bit strange.
[26:46.510 --> 26:47.550]  These are strange characteristics.
[26:47.750 --> 26:51.210]  So we can kind of keep an eye on using things like bash events.
[26:51.310 --> 27:04.310]  But as you can see, we have everything from firewall events, Windows rule sets, switches, routers, some fun stuff like Web Labyrinth, all kinds of stuff.
[27:04.490 --> 27:14.830]  So if you do decide that you want to get into log analysis and stuff like that, and you want to use Sagan, we would really like you to donate any kind of rules that you come up with.
[27:15.010 --> 27:19.850]  Because it turns around and helps build our rule set and the community can use it and whatnot.
[27:20.910 --> 27:23.930]  And then one thing that I'm going to go over real quick is output plugins.
[27:24.150 --> 27:33.670]  So whenever I say output plugins, I said Sagan can write to a database or it could send you an email or it could do all sorts of things.
[27:34.130 --> 27:38.030]  And we have a few of these output plugins that people like to use.
[27:38.550 --> 27:43.750]  Probably one of the ones that you always get asked for is, can you get it to email me when something bad happens?
[27:43.950 --> 27:44.790]  Which is okay.
[27:45.950 --> 27:52.810]  So you can use in the, just like it's very, it's again very similar to how Snort lays out its configuration file.
[27:52.890 --> 27:54.470]  And this is in the Sagan configuration file.
[27:54.630 --> 28:01.370]  You can actually tell it, when you see an event and it's a this priority of above, email it to the administrators.
[28:01.650 --> 28:12.190]  Or you can say, if you have a Windows event and it goes wrong or something happens and we detect something, send that Windows event to the Windows administrators, but not the UNIX administrators.
[28:12.390 --> 28:14.350]  And you can actually base that off of the rule.
[28:14.470 --> 28:23.030]  So it's basically a, a simple SMTP plugin that you can kind of tweak to get, to make sure like Windows guys get their stuff, Linux guys get their stuff and whatnot.
[28:24.750 --> 28:28.810]  We also can do where you can call your own program.
[28:28.970 --> 28:38.790]  So basically when an event happens, and since Sagan's multi-threaded, what, what it can do is hand that data over to your software.
[28:38.970 --> 28:41.750]  You could write that in Perl or Python or whatever that you want.
[28:42.090 --> 28:50.470]  And the reason that I bring it up, since it's multi-threaded, if your program takes two or three seconds to actually do execution, from our standpoint, we're still running.
[28:50.810 --> 28:52.810]  We're still collecting logs, still working.
[28:53.170 --> 28:56.550]  We've just handed that, that threaded process over to your program.
[28:56.710 --> 29:09.430]  Then you could turn around and you might be able to do something like, you know, paste the IP address on a webpage, or I was going to say like add a rule to my firewall to block this type of event.
[29:09.570 --> 29:12.030]  But actually I have a better way of doing that.
[29:12.170 --> 29:20.510]  So basically you can write your own customized software and it can be in C or any language that you want, as long as it'll take input from standard in, then, then you're pretty much set.
[29:22.470 --> 29:29.110]  Then obviously we can write directly, I wanted to bring this up, we can write directly to your SNORT database.
[29:29.350 --> 29:34.830]  That is, like Sagan itself will actually spawn off a thread and go right to the database.
[29:35.130 --> 29:41.490]  The reason I bring that up is if you look in the SNORT world, the SNORT IDS world, it's not really multi-threaded.
[29:41.610 --> 29:56.730]  So what it, if it has to go out and do an insert, and see how packets that are coming in, it has to actually stop what it's doing, go over, do an insert into the database, then come back and do, start watching for information, you know, packets that are coming that might be bad.
[29:56.950 --> 29:59.590]  You're losing possible events at that standpoint.
[29:59.990 --> 30:03.190]  They got around it with kind of a cool way.
[30:03.390 --> 30:06.650]  Well, my point is we don't have that problem with Sagan because we actually have it multi-thread.
[30:06.770 --> 30:10.610]  So it'll actually go out and insert these events for you and then keep them kind of separated.
[30:10.650 --> 30:12.490]  So your main engine's doing the log analysis.
[30:12.730 --> 30:15.350]  The other one is doing the SQL inserts.
[30:15.550 --> 30:19.750]  The way they get around it is they use a unified two output format in SNORT.
[30:19.970 --> 30:35.050]  So basically what it does is in the SNORT world, it writes out to a file, the event happens, it writes it to a file and then you have another program like Barnyard or something like that, that reads that file as it's being written to and then turns around and inserts it into the database.
[30:35.630 --> 30:37.170]  We can actually do the same thing.
[30:37.370 --> 30:43.230]  We, there's another advantage to using things like Unify2 and that you get queuing.
[30:43.470 --> 30:55.050]  So for instance, you bring your database down for maintenance, the events still get written to the file and then whenever your database comes back up, they get read back in and then they can insert into the basic database.
[30:55.370 --> 30:58.410]  So it's kind of, you get a kind of a queuing mechanism out of it.
[30:58.690 --> 31:00.910]  So, so we kind of support the same thing.
[31:01.030 --> 31:05.710]  As I said, we're trying to do a lot of this very similar things as, as a SNORT does.
[31:07.730 --> 31:18.290]  So, as I said earlier, we have the external output format and I said you could write your own rule set that, or excuse me, external program that would go through and add a firewall rule set.
[31:18.290 --> 31:23.470]  Well, the reason I was saying that that's fine and all, but there's actually a project already out there.
[31:23.590 --> 31:24.390]  It's called SNORT SAM.
[31:25.050 --> 31:27.270]  And I don't, has anybody ever gotten a chance to play with that?
[31:27.710 --> 31:30.230]  It's always amazing to me that nobody uses this more.
[31:30.350 --> 31:35.370]  It basically takes the, the idea was to take the SNORT engine and it turns it into an IPS.
[31:35.790 --> 31:39.790]  But with SNORT SAM, what's interesting about it, it'll go and communicate with your perimeter gear.
[31:40.050 --> 31:59.350]  So if you, if you have an event happen, SNORT SAM will actually communicate to your Cisco and then drop it in ACL or go to your, you know, your ASA, well, your ASA and drop it in ACL or your Linux boxes, if you use Linux box for, so it can go out to your perimeter and block those.
[31:59.530 --> 32:01.610]  Well, in Sagan, we actually use the exact same thing.
[32:01.650 --> 32:06.290]  So if a log message comes in and you deem it that, holy crap, this is so bad.
[32:06.830 --> 32:10.190]  If this gets triggered this rule set, I have to have this stop.
[32:10.310 --> 32:11.390]  It needs to be proactive.
[32:11.790 --> 32:21.190]  What you can do is you can use this to tell Sagan to go out to your perimeter gear, your Cisco ASAs or whatever, your juniper boxes or whatever, and set up a firewall.
[32:21.370 --> 32:23.650]  And the way that you do that, again, we go back to our rules.
[32:23.830 --> 32:27.990]  We simply add in the SNORT SAM directed there.
[32:28.210 --> 32:31.770]  We tell it firewall it by the source, IP address, not the destination.
[32:32.050 --> 32:35.310]  And then you give it the time that you want it to be firewalled for.
[32:36.570 --> 32:38.590]  And it'll automatically go out and do this for you.
[32:38.710 --> 32:39.870]  And the same thing with SNORT.
[32:40.050 --> 32:45.530]  But, so rather than using the external plug-in to write your own, I just think this is a better way to do it.
[32:45.590 --> 32:46.270]  It's already been tested.
[32:46.410 --> 32:47.750]  People actually already use it.
[32:49.570 --> 32:51.610]  I'm going to go through pre-processes.
[32:51.710 --> 32:52.890]  This is kind of a fairly new thing.
[32:53.010 --> 32:56.770]  So everything that I've talked about so far is based off of rule sets.
[32:57.050 --> 32:58.250]  And rule sets are fine.
[32:59.310 --> 33:04.090]  You need to invest a lot of time in research in the type of hardware or whatnot that you want to write rules for.
[33:04.890 --> 33:08.270]  Pre-processes are allowed us to do interesting things that aren't rule set-based.
[33:10.290 --> 33:18.390]  For instance, probably one of the most simple pre-processes that we can do is to track the systems that are reporting to us.
[33:18.610 --> 33:30.470]  If I have an environment and I have 50 servers and they're all logging information over to me, and then one of them goes away, so now I only have 49, I need some sort of mechanism to tell me, hey, somebody just isn't logging.
[33:30.710 --> 33:34.730]  So the most simple one is the Sagan Track Client.
[33:34.810 --> 33:41.450]  So basically what it does is it says, if you don't hear from a particular machine in 360 minutes, give me an alert.
[33:41.630 --> 33:42.550]  And it's not based off rules.
[33:42.630 --> 33:44.950]  And that's just a really kind of a simple example.
[33:45.090 --> 33:50.850]  But then you'll get a rule on one of those consoles, like Snorby or whatever, and it'll say, hey, I haven't heard from this guy in a while.
[33:50.930 --> 33:53.170]  Then whenever you go over there and you say, oh, shit, somebody turned it off.
[33:53.430 --> 33:58.510]  Then you turn it back on, right whenever he sees the log information, he says, hey, by the way, I'm starting to see him again.
[33:59.490 --> 34:00.030]  Everybody's good.
[34:00.430 --> 34:07.910]  But what you can do with that is then you can start doing anomaly detection and things of that nature and statistical stuff.
[34:08.070 --> 34:14.750]  So for instance, maybe it's an event that is coming in 10,000 times a second.
[34:15.190 --> 34:18.050]  It's not tripping off any rules, but that's kind of an anomaly.
[34:18.150 --> 34:20.270]  I might want to know about that.
[34:20.410 --> 34:24.530]  So what it can do is actually say, well, I'm getting this event a whole crap ton.
[34:24.790 --> 34:31.390]  So maybe I'll go ahead and generate an event saying, hey, I'm not sure if this is important to you, but this particular message keeps coming up.
[34:31.450 --> 34:32.650]  So you can do things like that.
[34:34.010 --> 34:35.830]  We also did a project.
[34:35.990 --> 34:38.510]  We were doing some work with WebSense.
[34:38.690 --> 34:41.810]  WebSense has a thing called the Threat Seeker Network.
[34:42.010 --> 34:50.710]  And basically what it is, you can query their network and find out reputation based stuff, like reputation based by IP or whatnot.
[34:51.070 --> 34:55.810]  And what we can do with Sagan is basically connect to that Threat Seeker Network.
[34:56.090 --> 35:08.450]  And even before it's gotten to a part where it might trigger a rule, we're already looking at the information like IP addresses, what type of information is coming from the log message by itself to figure out maybe it's something bad.
[35:08.670 --> 35:15.270]  So for instance, one of the demonstrations that I gave was to go to a command line and type in and ping and then I'd ping a known botnet.
[35:15.530 --> 35:28.450]  And then the bash rule would trigger... well, not bash rule, but since the bash logs are being sent to a centralized server, it would automatically say he's ping... it would pick out that IP address and tell, you know, set up an alarm that basically says somebody's,
[35:28.450 --> 35:34.090]  you know, trying to communicate with a known botnet network or an IP address that is a known botnet network.
[35:34.270 --> 35:39.950]  But unfortunately with the Threat Seeker stuff, it's... that is a closed source plugin for Sagan.
[35:40.490 --> 35:41.970]  And... but that's not really that big of a deal.
[35:42.090 --> 35:44.630]  I mean, really, how much WebSense crap do you have at home?
[35:45.010 --> 35:45.890]  I mean, probably none.
[35:46.550 --> 35:54.810]  So people, you know, who want to use the WebSense stuff typically have already a lot invested in it.
[35:55.450 --> 35:56.530]  And then there's other stuff too.
[35:56.610 --> 36:01.370]  We can take a lot of this type of pre-processors and turn around and use it in other places.
[36:01.530 --> 36:16.810]  For instance, like taking DShield information and utilizing that or there's tons of places you can get attack data from across the Internet and pull it into Sagan so that we're seeing that all in real time, be it rule-based or not rule-based and stuff like that.
[36:18.730 --> 36:24.650]  And that was pretty much... I was kind of trying to get through it because I didn't know with the... oh, well, that works out pretty good.
[36:26.650 --> 36:30.490]  With the last speaker, he's kind of cut in, which is fine.
[36:31.350 --> 36:33.910]  I was going to kind of blaze through this here real quick.
[36:34.370 --> 36:39.590]  But... so what I'd like to do now is just a real quick Q&A, any kind of questions or anything like that.
[36:42.710 --> 36:44.210]  I couldn't have explained it that well.
[36:45.250 --> 36:46.130]  There's no way.
[36:46.530 --> 36:48.030]  I hardly understood anything.
[36:51.610 --> 36:53.710]  No, we're not currently taking NetFlow data.
[36:53.970 --> 36:54.150]  No.
[36:54.630 --> 37:00.810]  We're basically taking... it's either syslog, event log or... yeah, events from Windows system.
[37:01.110 --> 37:04.170]  You can do SNMP... or excuse me, SNMP trap.
[37:04.570 --> 37:09.490]  Because basically, with SNMP trap, it just records into a syslog message and we can... we can do stuff like that.
[37:09.630 --> 37:11.130]  We're not currently doing anything with NetFlow.
[37:11.390 --> 37:15.410]  Okay, so I have a central syslog server with 90 days worth of stuff.
[37:16.290 --> 37:19.350]  What do I need to, um, you know, put a week's worth in here?
[37:19.550 --> 37:20.550]  What do I need to spend up?
[37:21.010 --> 37:22.010]  You need to spend on it?
[37:22.150 --> 37:23.110]  No, what do I need to spend up?
[37:23.170 --> 37:25.070]  What do I need to set up to... Oh, okay, okay.
[37:25.290 --> 37:30.250]  Um, well, basically, if you're going to be using, uh, the IDS backend and whatnot... Sure.
[37:30.470 --> 37:30.990]  I already got that.
[37:31.130 --> 37:31.630]  I already got that.
[37:31.670 --> 37:31.910]  Oh, okay.
[37:31.990 --> 37:32.190]  Perfect.
[37:32.310 --> 37:32.450]  Perfect.
[37:32.870 --> 37:34.810]  Then, um, no, it doesn't take hardly any time at all.
[37:34.890 --> 37:38.290]  Of course, there's a little bit of a learning tour, um, about how to install Sagan.
[37:38.550 --> 37:40.710]  It's very much like the configure make, make install.
[37:40.970 --> 37:43.270]  Uh, then you got to tweak a configuration file.
[37:43.630 --> 37:46.490]  Uh, then you have to figure out how you're going to place it into your network.
[37:46.710 --> 37:53.710]  That is, is your centralized environment might be set up in such a way that there's no compromise for changing that environment.
[37:53.950 --> 38:05.630]  So what you might be able to do is like, if it's going to like an arc site or something, some sort of centralized system is send from that centralized system back over to the Sagan box, or you might have Sagan sniff the wire and pull the logs off by himself.
[38:05.830 --> 38:14.690]  We try to make it so that if you already have like a Splunk or something already in there that you don't necessarily have to rip it out and reinvest or redo all your network.
[38:14.870 --> 38:17.070]  We try to make it so it's fairly friendly with that.
[38:17.190 --> 38:20.990]  So that would be the other step is figuring out how to implement it into your network.
[38:21.210 --> 38:22.510]  I hope that, I hope that helps.
[38:23.830 --> 38:24.270]  Jude?
[38:39.240 --> 38:45.040]  Um, so, so you have, uh, the question was, you have our syslog and it's going up two hops.
[38:45.280 --> 38:50.220]  So I'm assuming you have our syslog sending to another hard syslog, which sends it, sends it out.
[38:50.260 --> 38:52.880]  Yeah, I was in secondary data center and then...
[38:52.880 --> 38:56.680]  Well, I mean, actually, I, I've not really run into that, uh, type of problem.
[38:56.880 --> 39:05.880]  But, um, what I would probably say, as long as you're, um, the information, I'm assuming, like, is this standard UDP 514 kind of stuff?
[39:06.200 --> 39:08.360]  Are you spoofing the addresses as they go through?
[39:09.100 --> 39:12.500]  Like, so the device that reports to it is, is all the data in check?
[39:12.660 --> 39:13.980]  Then I would say at the very end.
[39:14.180 --> 39:14.780]  Yeah, basically,
[39:18.090 --> 39:23.210]  which is comp, and comp is central.
[39:23.650 --> 39:24.890]  Right, to your centralized server.
[39:25.190 --> 39:31.950]  I, I would say at where, probably, as long as your data is intact, probably where the centralized server is is probably your best bet.
[39:32.170 --> 39:34.250]  Because everything's kind of already getting over there anyways.
[39:34.510 --> 39:40.630]  And if you start putting it out at the different areas, and you have multiple Sagans, you have multiple sensors, and that's what I would think.
[39:40.730 --> 39:41.790]  But we could talk about that more.
[39:43.550 --> 39:44.150]  Yeah, no problem.
[39:44.330 --> 39:44.970]  I hope that helps.
[39:48.410 --> 39:48.730]  Cool.
[39:48.730 --> 39:49.510]  Any more questions?
[39:51.270 --> 39:53.310]  Man, I felt like I was blazing through that crap.
[39:54.570 --> 39:55.770]  Oh, shoot, very back over there.
[40:01.160 --> 40:03.300]  What kind of CPU, yeah, you might need to use the mic.
[40:03.440 --> 40:05.980]  I think you said what kind of CPU load does he use?
[40:06.260 --> 40:14.200]  So, like Snort, whenever you put it into an environment, with IDS, you typically want to turn on just the rule sets for what you want.
[40:14.320 --> 40:24.540]  So, for instance, if you don't have any MS SQL databases in your network, you turn off the MS SQL rules, and your Oracle rules, which maybe you use, you leave those on.
[40:24.620 --> 40:25.620]  You do the same thing with Sagan.
[40:25.620 --> 40:31.500]  You actually say, these are the type of systems that I know that are in my network, so I'm only going to turn on the different types of rule sets.
[40:31.720 --> 40:37.180]  My point of that is because I get people who just load up all the rule sets, you know, and they're, it's just ridiculous.
[40:37.420 --> 40:42.280]  And then, it has to take, it has to do the extra work to go through to figure out if these events are happening.
[40:42.460 --> 40:44.420]  So, what you want to do is customize it to your environment.
[40:44.540 --> 40:46.400]  You can tune it down fairly well.
[40:46.580 --> 40:50.800]  And I said, I mean, on some environments, we're getting 10 to 15,000 log lines a second.
[40:50.980 --> 40:52.180]  And this is on moderate hardware.
[40:52.260 --> 40:55.140]  This isn't like, like super badass machines.
[40:55.360 --> 40:56.580]  It's like decent machines.
[40:56.820 --> 41:04.580]  But, so it, it largely depends how many log lines you're getting, how, what kind of CPU time or that you have, how many rule sets are you enabling?
[41:04.680 --> 41:05.540]  Are you enabling them all?
[41:05.720 --> 41:06.380]  Are you enabling just a few?
[41:06.380 --> 41:08.320]  So, it's, it's, it's largely tunable.
[41:08.560 --> 41:10.360]  I mean, that's basically it.
[41:12.420 --> 41:13.220]  Any other ones?
[41:15.980 --> 41:17.240]  Well, I have five more minutes.
[41:17.860 --> 41:21.580]  But, well, uh, okay.
[41:22.920 --> 41:23.760]  Sorry, is this on?
[41:23.980 --> 41:24.120]  I guess.
[41:24.320 --> 41:24.340]  Yeah.
[41:24.540 --> 41:28.260]  You mentioned Rayner's live, uh, liblog norm.
[41:28.320 --> 41:29.040]  Liblog norm.
[41:29.220 --> 41:29.340]  Right.
[41:29.740 --> 41:33.200]  Um, was that part of his log analysis?
[41:34.020 --> 41:38.820]  Well, actually, um, no, he, uh, uh, it's not really for log analysis.
[41:39.040 --> 41:43.320]  It was more to just extract data out of logs to make it useful.
[41:43.540 --> 41:48.560]  So, he started also writing, uh, like a web frontend for our syslog that lets you search through logs.
[41:48.740 --> 41:55.000]  Well, he's actually, he's actually had a web frontend that lets you go through everything, you know, go through all your logs and search.
[41:55.700 --> 42:02.620]  Um, his, he wanted to use that to extract certain types of information, but he's not using it kind of like in the same way that Sagan is.
[42:02.640 --> 42:04.800]  We're doing everything all in real time as it happens.
[42:05.180 --> 42:05.340]  Yeah.
[42:05.460 --> 42:14.040]  And he wants to be able to, like, eventually take it and extract that so that you can go to his web interface and go, show me the users who logged in three months ago or show me these type of events.
[42:14.340 --> 42:22.200]  Sagan really concentrates on security related events that are happening in logs in real time and get them into the database so you can react better or whatnot.
[42:22.320 --> 42:22.540]  Okay.
[42:22.680 --> 42:28.240]  So, my real question was, is there any integration or overlap between Sagan and...
[42:28.240 --> 42:32.920]  No, actually, and you can ask Raina this, he actually started the liblog norm.
[42:33.120 --> 42:36.460]  I would say that Sagan uses it more than our syslog does.
[42:36.720 --> 42:36.720]  Nice.
[42:37.000 --> 42:37.120]  Okay.
[42:37.520 --> 42:43.020]  Uh, we, I mean, it was something that we just kind of jumped on right whenever he, uh, uh, made it.
[42:43.260 --> 42:49.620]  So, uh, I mean, and he's even told me, he's like, yeah, you, you, we try to use it, but good God, you guys use the hell out of it.
[42:49.840 --> 42:51.680]  So, and I'm glad that we can help.
[42:51.920 --> 42:52.060]  Yeah.
[42:52.540 --> 42:53.040]  He's a cool guy.
[42:53.320 --> 42:53.620]  Thank you.
[42:54.000 --> 42:54.260]  Thank you.
[42:55.040 --> 42:55.400]  Yes.
[42:55.400 --> 42:59.360]  Do you foresee any licensing charges or rules in the future?
[42:59.700 --> 43:00.700]  Uh, I do not.
[43:01.240 --> 43:06.600]  Um, but you know, I mean, well, I didn't see that in the future for Snort either.
[43:06.720 --> 43:07.300]  Yeah, same here.
[43:07.480 --> 43:07.900]  Right, right.
[43:07.980 --> 43:08.920]  Then the VRT rule sets.
[43:09.080 --> 43:15.640]  As I can see it right now, I mean, no, no, I don't, I don't see any, but I, you know, I can't never say never.
[43:16.180 --> 43:17.720]  Uh, but I don't, I don't see that happening.
[43:18.060 --> 43:18.120]  No.
[43:19.160 --> 43:20.960]  Especially with the current rule sets now, we can't.
[43:21.080 --> 43:22.380]  I mean, they're GPL version two.
[43:22.780 --> 43:33.960]  I mean, we can't now put the GD back in, you know, so those rules are there, but I, and I don't see there being any, any, any type of commercialization of the rules.
[43:34.120 --> 43:37.880]  It's, you know, there's this, that's easy information to get and write your own.
[43:37.980 --> 43:40.160]  It's not really worth it in my opinion, but.
[43:42.660 --> 43:43.260]  Any more?
[43:44.700 --> 43:45.340]  Well, cool.
[43:45.560 --> 43:47.220]  Well, hey, I really appreciate it, guys.
[43:47.420 --> 43:48.100]  Thanks for coming out.
[43:48.500 --> 43:49.200]  I can't blame you for it.
[43:49.360 --> 43:49.780]  Thank you.