Jun 01 19:04:55 	Bascially, I'll talk for a minute, hand it over to Kevin..  and he'll get it underway.
Jun 01 19:05:26 	I just wanted to say thanks for coming, we really appreciate the support we've received from the community.
Jun 01 19:05:55 	Our project was met with a bit of resistance at first, I think because people were set in their ways...
Jun 01 19:06:20 	... but now that we have a good project with signifcant development taking place, I'm glad to see that people are embracing the project..
Jun 01 19:06:48 	I know it's not a huge number..
Jun 01 19:07:05 	but we'll break the 17,000 download mark tonight...
Jun 01 19:07:15 	So, thanks, again...
Jun 01 19:07:25 	Kevin... you are the man..
Jun 01 19:07:29 	ok...
Jun 01 19:07:37 	and the crowd roars
Jun 01 19:07:39 	First I would like to also thank everyone for coming....
Jun 01 19:07:51 	and ask you to forgive my horrible spelling....
Jun 01 19:08:32 	This project has grown quite a bit in the time we have been here, much faster then I ever thought possible.
Jun 01 19:08:56 	I also believe that it has quite a ways to go to become the real "security engine" I believe it can be.
Jun 01 19:09:31 	1.1.3 is about to be released
Jun 01 19:09:38 	and 2.x is still being designed.
Jun 01 19:10:09 	so we felt that this was the perfect time, to ensure that our ideas for the new version meets with our abilities and our users needs
Jun 01 19:10:13 	hence this meeting.
Jun 01 19:10:16 	...
Jun 01 19:10:33 	1.x is based, as everyone knows on the original ACID source code.
Jun 01 19:10:46 	and while that code works and meets our needs at this point.
Jun 01 19:10:59 	most of the features that are being requested and bugs that need to be fixed
Jun 01 19:11:09 	are harder or impossible to do with this codebase.
Jun 01 19:11:32 	because of this, we are hoping to create a modular system with 2.x
Jun 01 19:11:51 	while not losing the simplicity of install and simple power that is the main reason people use BASE.
Jun 01 19:12:03 	....
Jun 01 19:12:14 	So, unless something comes up that changes this,
Jun 01 19:12:34 	2.x will be the main focus of development from the release of 1.1.3
Jun 01 19:12:51 	now, we will be fixing bugs that can be and even implementing simple RFE's to 1.x
Jun 01 19:13:06 	but if we are going to be successful with the next version, we must focus on it
Jun 01 19:13:13 	if only because our resources are limited.
Jun 01 19:13:24 	(we are all volunteers!)
Jun 01 19:13:34 	...
Jun 01 19:13:48 	2.x will be a system that breaks apart the GUI and the logic.
Jun 01 19:14:03 	the intertwining of those two pieces has caused most of the headaches in 1.x
Jun 01 19:14:36 	The logic system will run on the web server as a series of PHP scripts.
Jun 01 19:15:00 	these scripts will accept requests and send back streams of data.
Jun 01 19:15:15 	The GUI will then be able to determine the best way to display these streams.
Jun 01 19:15:38 	The primary interface will be a web client that will work similar to 1.x
Jun 01 19:16:38 	the web client will then just POST to the web logic system to get responses.
Jun 01 19:16:57 	We will then be able to support various front ends.
Jun 01 19:17:15 	Thick clients, Dashboard type widgets, and other applications.
Jun 01 19:18:02 	this will enable other applications to use the logic system of BASE to retrieve data.
Jun 01 19:18:27 	Right now other apps, such as OSSIM, have to package BASE as a part of their system and work around the tie-ins.
Jun 01 19:18:33 	....
Jun 01 19:18:56 	We will also be able to create various visibility systems using this.
Jun 01 19:19:36 	By this I mean, when we authenticate a user, the GUI will be able to determine what they see, instead of the logic being mixed in there...
Jun 01 19:20:07 	It will also let us take advantage of the power of the various systems we build on.
Jun 01 19:20:21 	....
Jun 01 19:20:38 	Another major feature will be the improved reporting system.
Jun 01 19:21:10 	We would like the system to generate reports that can be used for everything from day-to-day information, to management level "pretty graphs"
Jun 01 19:21:38 	....
Jun 01 19:22:08 	We will also be building what I believe Joel is calling an "Incident Response Workflow"
Jun 01 19:22:22 	:D
Jun 01 19:22:40 	This will allow people to respond to alerts and work amongst many handlers within the BASE system
Jun 01 19:23:36 	We have had many people ask for this type of feature and within the 1.x code train, it doesn't seem feasible.
Jun 01 19:24:41 	We are hoping that this basic idea babble will be grown through what users need and what people are willing to code.
Jun 01 19:24:42 	....
Jun 01 19:24:52 	Which brings us to the what I think we need....
Jun 01 19:25:14 	First, we need to figure out a system to better test releases.
Jun 01 19:25:35 	Chrisitan has done a great job testing what ever we throw at him, but he is only one guy.
Jun 01 19:25:49 	and I am the first to admit, I commit code that needs to be backed out!
Jun 01 19:26:10 	I would also like to grow the development team, with people who really want to code.
Jun 01 19:26:29 	We also need to create better documentation.
Jun 01 19:26:52 	The install guides by Patrick Harper and others are great.
Jun 01 19:27:13 	But if we are going to build a workflow system, we will need to create in-system help....
Jun 01 19:27:45 	Kevin, I actually had a good friend of mine, and known snort contributor to the community, volunteer to help us out in the documentation arena today.  I'll be adding him to the team soon...
Jun 01 19:28:00 	And of course, I want to figure out how we can work closer with snort to ensure that as releases are coming out, we are ready for them...
Jun 01 19:28:15 	So far, I believe that has been hampered by me not upgrading
Jun 01 19:28:28 	.....
Jun 01 19:29:04 	Well I have babbled for almost half an hour so I would like to open it up to questions.... First, Joel have you gotten any that we can start with?
Jun 01 19:29:22 	hhoffman posed a good question..
Jun 01 19:29:40 	I can repose (i already have another though) :-)
Jun 01 19:29:44 	
Jun 01 19:29:46 	Is base going to turn into a SIM?
Jun 01 19:29:58 	Security Information Manager.
Jun 01 19:30:11 	I cant answer that...
Jun 01 19:30:14 	basically because
Jun 01 19:30:22 	I believe that SIM is a marketing term
Jun 01 19:30:39 	We are going to become a system to handle alerts.
Jun 01 19:30:44 	well, what I'm curious about the the features normally associated with a SIM
Jun 01 19:30:49 	I believe that in order for an analyst to get the most out of a tool, and to keep the analyst from working with 5 different tools to get his information, he should only have to look at one piece.
Jun 01 19:30:56 	snmp traps, syslog, flow data, etc.
Jun 01 19:30:56 	I agree..
Jun 01 19:31:12 	Right now, we are looking at reporting the data out of BASE.
Jun 01 19:31:25 	That is one of the reasons we are splitting the logic and the UI.
Jun 01 19:31:35 	that leads to my other question...
Jun 01 19:31:41 	but I am not sure the right place for alerting is within BASE when Snort does it well...
Jun 01 19:31:53 	are there any plans to work with the snort team to modify the db schema at all?
Jun 01 19:32:11 	There have been a number of ideas around the snort db and the BASE db...
Jun 01 19:32:26 	not sure if we are able to change the db......
Jun 01 19:32:38 	problem is, if we work with Sourcefire to change the db, it would break countless other tools.
Jun 01 19:32:50 	hmm, good point
Jun 01 19:33:25 	we'd like to build more tables inside the db
Jun 01 19:33:42 	or a seperate "along side" db in order to perform the queries.
Jun 01 19:33:47 	And we will be creating a Barnyard plugin for any changes we make to our tables....
Jun 01 19:34:07 	yeah, that's what I'm currently resorting to with our homebrew reporting system
Jun 01 19:34:17 	oh! that's good to know
Jun 01 19:35:27 	We had a question about our statement: "the statement "when we authenticate a user, the GUI will be able to determine what they see" [/do?].  This implies you can bypass authentication by bypassing the GUI, and going straight to web requests.  Or does it?
Jun 01 19:35:34 	(Question was from cisc0man)
Jun 01 19:35:44 	The short answer is no.
Jun 01 19:35:46 	no it doesn't... 
Jun 01 19:35:53 	You will not be able to bypass user authentication.
Jun 01 19:36:00 	We are going to be building an authentication system that will be pluggable...
Jun 01 19:36:02 	Think PAM
Jun 01 19:36:04 	(unless you completely shut it off)
Jun 01 19:36:36 	it will happen at the logic portion but the GUI portion will also tie into it...
Jun 01 19:36:50 	where display of menus and such are there....
Jun 01 19:37:18 	OK, that sounds better :-)  Thanks.
Jun 01 19:37:26 	;>
Jun 01 19:37:29 	Another question: have you guys thought about using the horde framework at all?
Jun 01 19:37:40 	I have never really looked at the Horde framework..
Jun 01 19:37:44 	(Question was from hhoffman)
Jun 01 19:38:14 	I have heard good things about it though... so we probably should at least look into it...
Jun 01 19:38:22 	it's certainly something we can look into.
Jun 01 19:38:23 	it's quite nice... the framework is there for many things and then ppl write modules to interact with it
Jun 01 19:39:04 	cool.
Jun 01 19:39:19 	kevin, can we talk about a couple ideas, and see what people think about them?
Jun 01 19:39:29 	sure...
Jun 01 19:39:50 	Talk about our Incident Grouping Workflow.
Jun 01 19:39:54 	for a sec...
Jun 01 19:40:14 	What we want is the ability to be able to assign events to an "Incident Number"
Jun 01 19:40:24 	now, you guys are thinking "Alert Groups"
Jun 01 19:40:27 	
Jun 01 19:40:32 	which is something we already have, and no one uses.
Jun 01 19:40:42 	But we want to take it a step further.
Jun 01 19:41:08 	We want to be able to assign certain events/priorities/sensors to a person
Jun 01 19:41:17 	and have them work it from "cradle to grave"
Jun 01 19:41:53 	This will help a lot in the large systems or edu's where various groups are responsible for sections of the network or applications
Jun 01 19:41:55 	one of the present limitations with this is, that when an event is deleted or Archived, it's not in the Incident (or alert group) anymore.
Jun 01 19:42:04 	we're going to have to move these to a seperate table.
Jun 01 19:42:13 	any thoughts about allowing hooks into comerical tools like Remedy or Service Center?
Jun 01 19:42:30 	yes....
Jun 01 19:42:51 	It would just be another front end interface.
Jun 01 19:43:05 	under an incident group..
Jun 01 19:43:23 	and reconstruct data..
Jun 01 19:43:40 	attach various word documents or excel spreadsheets to the Incident Group..
Jun 01 19:43:47 	and have them flow..
Jun 01 19:44:30 	what else would you guys like to see as part of that?
Jun 01 19:44:34 	I'm most interested in separating "new, virgin" alerts from those that have been [deleted]/archived/alert-grouped/workflowed.  
Jun 01 19:44:46 	that would be key in making it work
Jun 01 19:45:05 	what about a real-time alert console?
Jun 01 19:45:18 	as opposed to an auto-refresh method..
Jun 01 19:45:38 	I think on front ends that can handle it, definitely.
Jun 01 19:45:43 	The alert group incidents still appear in the pool of current alerts, would like them to "go away" from most recent, today, etc.
Jun 01 19:45:46 	are you also thinking about escalation management? (ie -> analyst hasn't done anything escalate to manager)
Jun 01 19:45:57 	But still be available for "any sig, src or dst" for example.
Jun 01 19:46:06 	hhoffman, I consider that workflow.... but yes
Jun 01 19:46:32 	ciscoman, that would depend on the settings of the person,
Jun 01 19:46:34 	gotcha
Jun 01 19:46:59 	for example, if you were on a "new" screen, they would only be on the un-flowed alerts
Jun 01 19:47:13 	but if you were in a historical type mode, they would all appear...I think
Jun 01 19:47:39 	that will be something that will take extensive testing with the community to make sure it's what they want.
Jun 01 19:48:15 	That's the idea.  Now you have to delete/archive to get them out of current, but for long-term things it's nice to search for anything you have available.
Jun 01 19:48:50 	so you're talking about crossing databases for historical data?  Am I reading that right?
Jun 01 19:49:05 	(just trying to clarify)
Jun 01 19:49:35 	I think we should move away from the archive and current db and more toward tables within the same db
Jun 01 19:49:47 	i agree...
Jun 01 19:49:54 	simplifiy reporting...
Jun 01 19:50:10 	but it will require that we work toward using the power of each DB system to its fullest.
Jun 01 19:51:20 	okay..
Jun 01 19:51:38 	Another idea we had was the "session" playback theory.
Jun 01 19:51:54 	a few people have asked for it.
Jun 01 19:52:00 	As I am sure you are familiar, in the Snort rule options..  there is "tag"
Jun 01 19:52:14 	which will record further sessions as it relates to an alert.
Jun 01 19:52:30 	What we want to do is to be able to "aggregate" (is that the right word) this data
Jun 01 19:52:40 	so with one click, we can reconstruct a "session"
Jun 01 19:52:54 	thoughts?
Jun 01 19:53:01 	this would depend on whether some tie in is logged to the DB by snort
Jun 01 19:53:08 	I dont know if it is...
Jun 01 19:53:22 	Providing "real-time" view or better some reaction would be great. But it isn't something a web interface can do. We might want to write a wrapper which gets the alerts from Snort, acts on them if required (sends an email/snmp trap) and stores them in the DB.
Jun 01 19:53:25 	i am pretty sure it is..
Jun 01 19:54:02 	Maybe someone can square me away, because I can't remember off the top of my head (too many other thoughts..)
Jun 01 19:54:07 	I am not sure the std snort DB schema has a column for it, but tagged alerts contain ref info.
Jun 01 19:54:17 	I think the sid's for the tag and the sid for the rule that caused the tag are the same.
Jun 01 19:54:31 	Although they appear to be somewhat b0rked from my experience. (FYI)
Jun 01 19:54:35 	can't be sids...
Jun 01 19:54:36 	sorry, got distracted.  I was hoping not to have to pull from multiple DBs, just what was in current alert DB.  Perhaps a "Seen" flag.  Now I'll hush.
Jun 01 19:54:52 	dont hush...
Jun 01 19:54:57 	It should all be in one DB...
Jun 01 19:55:07 	are there any plans to tie in MAC->IP matching for local systems... this helps us with historical data in networks where we have short dhcp leases
Jun 01 19:55:20 	hadn't thought about it...
Jun 01 19:55:30 	but worth looking into I believe...
Jun 01 19:55:37 	there is something that is cross-correlated between the signatures and the "tag"'s..  but I can't remember what field there is...  Perhaps Matt scan clairfy on that one..
Jun 01 19:55:56 	hhoffman, are you dhcp host names the same?
Jun 01 19:56:12 	what if we built an option to be able to sort by host names?
Jun 01 19:56:56 	*on that note..  I don't think Snort logs layer 2 data to db..someone correct me if I am wrong..*
Jun 01 19:57:08 	eslerj: the host names stay the same
Jun 01 19:57:33 	but we would need to capture the host name at time of the alert.
Jun 01 19:57:41 	right.
Jun 01 19:57:42 	right... but in our case we have a pcap app running that logs arp traffic into the db from starting/ending/last seen time
Jun 01 19:57:52 	hhoffman, you're talking about something like arpwatch?
Jun 01 19:58:03 	that can then be correlated to the time of the alert for that ip
Jun 01 19:58:20 	zroone: yep, similiar to that but ours logs directly to the db
Jun 01 19:58:28 	this would probably call for one of the stand alone scripts to read your db and coorrelate
Jun 01 19:58:28 	what if we could make BASE read arpwatch logs?
Jun 01 19:58:53 	or dhcpd?
Jun 01 19:59:02 	that would be nice. but, arpwatch can't log to db?
Jun 01 19:59:03 *	eslerj nods
Jun 01 19:59:25 	arpwatch can't AFAIK
Jun 01 19:59:45 	but we can create programs, if they dont exist, to read the logs and write to the DB...
Jun 01 19:59:56 	yep
Jun 01 19:59:56 *	eslerj says, "By the way... We just acheived a download milestone.. 17,006"
Jun 01 19:59:59 	found it in google: http://www.thtech.net/article/12
Jun 01 20:00:18 	admit it Joel, you are d'ling copy after copy
Jun 01 20:00:30 	they've caught onto me.
Jun 01 20:00:31 	yep, we used that as our base and then modified it
Jun 01 20:01:31 	One point I forgot to make is that because of the expanse of features we want to implement and the limit on volunteers, we need to create everything in a modular fashion so that people dont have to wait 7 years for 2.0
Jun 01 20:02:01 	eslerj: if you email me i'll write something up for how tag logs stuff.
Jun 01 20:02:10 	yeah, that's a really good idea.
Jun 01 20:02:11 	thanks
Jun 01 20:02:18 	thanks matt..
Jun 01 20:02:31 	I know I know.. i just can't remember..
Jun 01 20:02:38 	Idea #3...
Jun 01 20:03:02 	BASE's ability to read other IDS's.
Jun 01 20:03:23 	how about nessus results?
Jun 01 20:03:25 	or perhaps translate other IDS db schemas to a common schema.
Jun 01 20:03:41 	hhoffman, hey.. this isn't site protector.. ;)
Jun 01 20:03:44 	I would want to do the second... translation is easier....
Jun 01 20:03:52 	what about IDMEF? how many IDSs implement this?
Jun 01 20:03:53 	and can be done with stand alone modules in perl.
Jun 01 20:04:27 	it would help in evnironments where we run different types of IDS;s to ensure depth
Jun 01 20:04:51 	if your dealing with anything other than prelude or snort, IDMEF isn't well supported.
Jun 01 20:05:21 	cisco, has good support for SDEE. when it works.
Jun 01 20:05:22 	hhoffman, the funny thing is that the original secureideas project was to handle VM using nessus results tied into various system fingerprinting tools.
Jun 01 20:05:35 	like p0f?
Jun 01 20:05:35 	At our office, we've figured out a common db schema for RealSecure and Snort, so maybe we can work that the same way..
Jun 01 20:05:58 	(we've integrated p0f into our common schema as well)
Jun 01 20:05:59 	it changed
Jun 01 20:06:03 	nice!
Jun 01 20:06:30 	@ our office, we've translated RealSecure, Snort, p0f, and Syslogged Router log messages into a common schema.
Jun 01 20:06:31 	I still have some of the code floating on one of these machines
Jun 01 20:06:54 	But we can pretend to be something the other IDSes know - have some kind of "input" modules.
Jun 01 20:07:15 	if people have the knowledge to write those modules it would be great...
Jun 01 20:07:16 	starting to sound like...  Arcsight.
Jun 01 20:07:36 	"Joel, the fount of product names!"
Jun 01 20:07:49 	or Cyberwolf...  *pukes*
Jun 01 20:08:24 	k...  idea #4...
Jun 01 20:09:02 	i was going to bring up alert color coding, but we have that working in cvs... and what we don't have hopefully zroone can get squared away.
Jun 01 20:09:25 	good work Alejandro...
Jun 01 20:09:41 	hey
Jun 01 20:10:40 	It's just my job. :-)
Jun 01 20:10:41 	k
Jun 01 20:10:46 	:)
Jun 01 20:11:08 	What would /you/ the customer.. (we're customer centric here at BASE)
Jun 01 20:11:11 	like to see..
Jun 01 20:11:13 	I have p0f
Jun 01 20:11:15 	arpwatch
Jun 01 20:11:19 	alert escalation
Jun 01 20:11:24 	nessus integration
Jun 01 20:11:27 	host name sorting
Jun 01 20:11:31 	horde integration.
Jun 01 20:11:43 	what else would you like to see from a tool?
Jun 01 20:12:46 	syslog/snmpd integration
Jun 01 20:13:05 	do you mean, make BASE able to listen on port 514/161...
Jun 01 20:13:10 	etc..
Jun 01 20:13:16 	snort performance monitor
Jun 01 20:13:19 	hhoffman, what would you like to see different then the snort built in output modules?
Jun 01 20:13:40 	eslerj: yeah
Jun 01 20:14:06 	Alejandro, I agree completely and have been whiteboarding some ideas for that...
Jun 01 20:14:16 	secureideas: sorry, I don't follow.
Jun 01 20:14:21 	What if you could configure your Snort IDS's from the console?  HOME_NET... EXTERNAL_NETs...
Jun 01 20:14:24 	rulesets..
Jun 01 20:14:28 	ow!
Jun 01 20:14:33 	distributed rulsets
Jun 01 20:14:42 	Similar alert suppression/easy grouping. When there's an attack a change in the network lots of "uniteresting" alerts slow down the DB.
Jun 01 20:14:43 	or distributable I suppose
Jun 01 20:14:43 	hhoffman, i know, that's a headache.
Jun 01 20:15:27 	zroone, do you mean something along the lines of pmgraph?
Jun 01 20:15:32 	.. _or_ a change ..
Jun 01 20:16:11 	how about the ability to query an argus server?
Jun 01 20:16:25 	Sorry, but I don't know about pmgraph. 
Jun 01 20:16:54 	pmgraph is a small perl prog that will read Snort's outputted stats and make graphs of it..
Jun 01 20:16:59 	mimecz, are you asking for us to set thresholds and control the sensors?  or drop from the DB if selected by criteria?
Jun 01 20:17:02 	hmmm, perfmon-graph?
Jun 01 20:17:11 	yeah
Jun 01 20:17:17 	pmgraph.pl is the command line..
Jun 01 20:17:19 	my bad.
Jun 01 20:17:31 	sorry, sure I know it. :)
Jun 01 20:18:03 	Well, I believe we can show the user better data than perfmon graph.
Jun 01 20:18:35 	would we have to build something to input Snort stats into the db, or could we get with Sourcefire and see if we could do that..
Jun 01 20:18:40 	BTW, I would like to, before we lose people, congratulate Thom on his newest addition to the family!  She is beautiful!
Jun 01 20:19:08 	Thom == driven1
Jun 01 20:19:11 	congrats Thom and family
Jun 01 20:19:23 	Better to monitor incoming events and store them 'inteligently'. Maybe to have a table of possibly uninteresting events and store the new 'similar' ones there.
Jun 01 20:19:25 	congrats Thom.  One for One trade this week I guess.
Jun 01 20:19:46 	Michelle's G-mother passed away this morning (michelle = my wife)
Jun 01 20:19:47 	Thanks.... this one makes seven :O
Jun 01 20:19:58 	seven kids?
Jun 01 20:20:02 	yup
Jun 01 20:20:04 	wow
Jun 01 20:20:07 	wow!
Jun 01 20:20:15 	mimecz, that makes sense.
Jun 01 20:20:21 	after 3 its a blur
Jun 01 20:20:29 	mimecz, would you want to automatically move them there? or manually?
Jun 01 20:20:45 	Joel, sorry....
Jun 01 20:20:57 	thanks.
Jun 01 20:20:59 	no p.
Jun 01 20:21:04 	your family is in our prayers.
Jun 01 20:21:24 	thanks.  she went peacefully, so all is well (IMO)
Jun 01 20:22:57 	Probably automatically. But it's a difficult job. We can rather easily (if we were incercepting incoming events) move it but I'd like to see them on specific queries. I can't really see how to code it.
Jun 01 20:23:22 	isn't there a tool that will assign a percentage to events? as they come in?
Jun 01 20:23:33 	and the more there are, the higher the percentage or something like tthat?
Jun 01 20:23:35 	mimecz, that makes sense, we will need to talk it out...
Jun 01 20:24:52 	what if we could make a module to be  able to auto-nmap or manually nmap a box upon a user click.
Jun 01 20:25:15 	eslerj, that is part of the code I mentioned floating around here....
Jun 01 20:25:27 	you're the man then.
Jun 01 20:25:32 	it would be part of a VM system to determine the priority of the events
Jun 01 20:25:57 	and would log the status of individual sigs
Jun 01 20:26:05 	as part fo the workflow....
Jun 01 20:27:46 	I wonder if it would be possible to coordinate with Sourcefire in order to be able to log Snort performance stats to a seperate table in the DB.
Jun 01 20:28:10 	it will be nice!
Jun 01 20:28:55 	perhaps matt or jennifer can point us to the right person..  (probably jhewlett)
Jun 01 20:29:14 	i can set you up to talk to some of our snort developers about it
Jun 01 20:29:38 	sfirejennifer, if you could, that'd be great.
Jun 01 20:30:18 	right on.
Jun 01 20:30:21 	It would be nice to compare when your snort is doing bad with number of alerts incoming for example.
Jun 01 20:30:34 	;)
Jun 01 20:30:34 	would be nice.
Jun 01 20:30:37 	I do it manually now.
Jun 01 20:30:53 	using perfmon-graph and correlating with time, but it would be nice to build it into once interface.
Jun 01 20:31:01 	wb sfirejennifer 
Jun 01 20:31:07 	thanks
Jun 01 20:31:21 	It would be nice if you can receive an e-mail when your snort is doing bad.
Jun 01 20:31:41 	a snort administration system..?
Jun 01 20:32:37 	Hmmm... ACID, then BASE, now Inert GAS (GUI Administrator of Snort) :-)
Jun 01 20:32:45 	not at all, but it's good to know when your sensor is doing bad.
Jun 01 20:33:01 	
Jun 01 20:33:09 	snort perfmon give it to you.
Jun 01 20:33:11 	nagios?
Jun 01 20:33:23 	or do you mean snort itself (i.e. packet loss)?
Jun 01 20:34:18 	yes I'm talking about packet loss
Jun 01 20:34:36 	hmm, that would be nice
Jun 01 20:34:51 	it becomes a tab of the system....
Jun 01 20:35:02 	perfmon also gives you the uses of CPU and memory.
Jun 01 20:35:07 	new alerts | reporting | system perf
Jun 01 20:35:28 	i would love to be able to enter a Snort rule into the interface, and the interface gives you some feedback on how to make the rule faster.
Jun 01 20:35:42 	ambitious....
Jun 01 20:35:43 	
Jun 01 20:35:46 	:)
Jun 01 20:36:01 	shoot for the moon.
Jun 01 20:36:07 	Any ideas for better integrating portscan into the picture?  would need some sourcefire collaboration
Jun 01 20:36:27 	whats your thoughts cisc0man ?
Jun 01 20:37:07 	how about integrating firewall log parsers?
Jun 01 20:37:15 	Oh I dunno, it should send a 240-volt charge down their Cat-5, for example.  Seriously, not sure, other than what we have now is pretty lacking.
Jun 01 20:37:19 	(one sec, I need more coffee)
Jun 01 20:37:51 	the portscan stuff broke when I put in a patch for the new type of alert...
Jun 01 20:38:08 	we would need to re-evaluate it... I think they need to work in 2.x
Jun 01 20:38:09 	cisc0man, I think we can work that.
Jun 01 20:38:13 	;)
Jun 01 20:38:30 	alot of people like the spp_portscan2 as opposed to the new sf_portscan.
Jun 01 20:38:35 	
Jun 01 20:39:10 	This would be a testing issue though.....we need to build test cases to ensure things stay working...
Jun 01 20:39:31 	which brings me to my next point.
Jun 01 20:39:41 	We still use spp_portscan. sf_portscan has some cool features though. Like "Open port" alerts.
Jun 01 20:39:47 	we need more developers.
Jun 01 20:39:53 	anyone interested?
Jun 01 20:39:59 	I am...
Jun 01 20:40:02 	
Jun 01 20:40:11 	or some how get me more time...
Jun 01 20:40:22 	:)
Jun 01 20:40:34 	kevin, lets see how we feel bout this...
Jun 01 20:40:45 	I think it's really badly placed. Why does it have it's own "progress meter"? It should be intergrated along other events.
Jun 01 20:40:53 	what about hiring (or contributing money for) developers?
Jun 01 20:40:56 	qru - secureideas, what if we worked on making our two tools work together?
Jun 01 20:40:59 	Sure.  cat base-developer >> my-projects
Jun 01 20:41:07 	Ooops, filesystem full, no more inodes
Jun 01 20:41:25 	Geek *points at cisc0man*
Jun 01 20:41:41 	how could a '>>' eat an inode? :-)
Jun 01 20:41:56 	hhoffman, we currently only have volunteers... and no money to pay for people
Jun 01 20:41:58 	eslerj: I am open to that. It'd be worthwhile to have you guys support our schema IMHO. But we really an't go back to the old snortdb.
Jun 01 20:41:59 	bigger geek *points at mimecz*
Jun 01 20:42:13 	with hot sauce from the bit bucket
Jun 01 20:42:30 	kevin, what do you think?
Jun 01 20:42:43 	about which...the hot sauce?
Jun 01 20:42:50 	secureideas: my last job we used a OSS piece of software and hired a developer to contribute the changes we wanted back to the cvs repo... changes accepted we pulled cvs everyone was happy
Jun 01 20:43:02 	yes, I think we should work together.
Jun 01 20:43:16 	obviously the developer worked tightly with the project leads
Jun 01 20:43:20 	yep
Jun 01 20:43:51 	hhoffman, we had a company donate three developers....but we received no code.
Jun 01 20:44:07 	We've got some pretty big changes to how the db is populated and what it looks like though. So I am not sure what your take would be.
Jun 01 20:44:08 	you could do a bounties system... match developers with people willing to pay
Jun 01 20:44:38 	For example: our event and associated tables look like this now:
Jun 01 20:44:39 	| event_gateway_20050304   |
Jun 01 20:44:40 	| event_gateway_20050305   |
Jun 01 20:44:40 	| event_gateway_20050306   |
Jun 01 20:44:40 	| event_gateway_20050307   |
Jun 01 20:44:48 	that would work if people werre willing to pay...
Jun 01 20:44:54 	Each sensor has it's own table for it's own day in the DB.
Jun 01 20:45:21 	I don't want to seem like I'm plugging the horde project too much but check out: http://www.horde.org/bounties/
Jun 01 20:45:26 	qru, perhaps we can have a member of our team work with your team, and we can develop a common schema/interface/backend.. something.
Jun 01 20:45:27 	Then we use mysql's (ISAM) MERGE type to merge them.
Jun 01 20:45:43 	hhoffman, I have seen bounties work....
Jun 01 20:45:56 	eslerj: Sounds like a plan.
Jun 01 20:45:58 	yeah, that's how we got into it
Jun 01 20:46:10 	but I think that until we have full time leads it would be a nightmare..
Jun 01 20:46:23 	hmm, yeah
Jun 01 20:47:02 	eslerj: I haven't used ACID in a very long time (meaning I've never used BASE). But I can remember having serious sacalability problems.
Jun 01 20:47:11 	The time factor was a major reason Joel became a project lead.....and the fact that he is great at it!
Jun 01 20:47:24 	ACID does have scalabiltiy issues as does BASE currently
Jun 01 20:47:33 	but we have improved GREATLY
Jun 01 20:47:45 	thanks for that vote of confidence..  I was worried about that first part of the sentance ;)
Jun 01 20:48:36 	Joel, please, as if you didn't know how much I appreciate your help!
Jun 01 20:48:44 	;)
Jun 01 20:50:22 	Hey Joel, you don't miss a second! There's an RFE on my mailbox about perfmon!
Jun 01 20:50:23 	qru, what I'll do is start working with you guys (or point the right people from our project over there, and see if we can't start working on that...
Jun 01 20:51:02 	zroone.. *points to Kevin's comment about "he is great at it"...* ;) j/k
Jun 01 20:51:12 	lol
Jun 01 20:52:18 	qru, i definately agree there are advantages to both tools, and maybe we can start, perhaps, working towards a common solution.. (sounds like a press release)
Jun 01 20:52:29 	wow marketspeak in IRC!!!!
Jun 01 20:52:33 	eslerj: Let me know when you guys have time. I can give you a 'tour' of the interface if you haven't mess with it, then we can go over how things work ;)
Jun 01 20:52:41 	perfect...
Jun 01 20:52:43 	heh
Jun 01 20:52:57 	Okay, I'll get with you guys probably next week.  I gotta funeral this weekend ish..
Jun 01 20:53:11 	I was just talking today about having the need to do RT event analysis (like w/sguil) and also batch analysis (like with BASE).
Jun 01 20:53:20 	eslerj: :(
Jun 01 20:53:51 	I would also like to build some canned reports to have out of the box
Jun 01 20:53:54 	qru, i think it would be great, espeically if we could read the dump porition of the db.
Jun 01 20:53:59 	and a report builder component....
Jun 01 20:54:03 	secureideas, yup.
Jun 01 20:54:16 	I'm looking forward to see the record of this conversation. I've got to go now.
Jun 01 20:54:18 	secureideas, I think I assigned that to Alejandro and Christian today.
Jun 01 20:54:26 	mimecz, have a good one, thanks for stopping by
Jun 01 20:54:28 	Sleep well...
Jun 01 20:54:30 	eslerj: If you mean for the 'transcripts' we do, that data isn't in the DB.
Jun 01 20:54:39 	?
Jun 01 20:54:52 	i think i am confused i guess.
Jun 01 20:55:00 	eslerj: Or I am :)
Jun 01 20:55:14 	if we could read the dump porition of the db. <=== what did you mean by that?
Jun 01 20:55:19 	doesn't sguil have the ability to read-playback sessions?
Jun 01 20:55:25 	eslerj: Yes.
Jun 01 20:55:29 	k.
Jun 01 20:55:33 	But we don't pull the data from the DB.
Jun 01 20:55:37 	ah.
Jun 01 20:55:44 	We collect pcap on the sensor.
Jun 01 20:56:17 	And we have an agent on the sensor. So when you request that playback, the request for pcap is passed down to the agent and then the pcap is copied back up stream.
Jun 01 20:56:29 	ah
Jun 01 20:57:01 	okay, i was confused.
Jun 01 20:57:11 	At that point we either run it thru tcpflow (for a transcript) or send the pcap to the requesting client (for ethereal).
Jun 01 20:57:28 	IMHO, the DB is a very bad place to store that kind of data.
Jun 01 20:57:47 	yes it is...
Jun 01 20:57:50 	You also have to remember that the pcap is saved independant of snort alerts. We aren't using tagged packets.
Jun 01 20:57:58 	right.
Jun 01 20:58:09 	but you modify source code to do that right?
Jun 01 20:58:19 	So, unless you build a filter, you a really doing a tcpdump -i fxp0 -w /path/log.pcap.
Jun 01 20:58:36 	Which is why I recommend big HDs for your sensors ;)
Jun 01 20:58:59 	We have users with terabyte storage arrays dedicated to sensors.
Jun 01 20:59:20 	Just don't pcap the fiber channel to your SAN (circular capture, anyone?)
Jun 01 20:59:27 	heh
Jun 01 20:59:38 	okay.
Jun 01 20:59:43 	Yeah, don't that, or do it "out of band".
Jun 01 20:59:45 	well, that's something we'll have to look into.
Jun 01 21:00:22 	Do you key it on timestamp or do you really enumerate a sequence number for each packet?
Jun 01 21:00:45 	cisc0man: src/dst ips/ports and timestamp.
Jun 01 21:00:55 	So, no, it's not perfect.
Jun 01 21:01:03 	close enough for govt work
Jun 01 21:01:09 	hey.
Jun 01 21:01:10 	'xactly.
Jun 01 21:01:13 	Joel resembles that remark!
Jun 01 21:01:17 	lol
Jun 01 21:01:20 	damn it!
Jun 01 21:01:24 	heh
Jun 01 21:01:27 	okay.
Jun 01 21:01:31 	Other thoughts?
Jun 01 21:01:33 	we're a state univ, I can't talk :-) much :-)
Jun 01 21:01:43 	what do people think about output systems...
Jun 01 21:01:50 	such as export to excel and pdf...
Jun 01 21:02:01 	we already do cvs, right?
Jun 01 21:02:05 	yeah.
Jun 01 21:02:05 	yes.
Jun 01 21:02:07 	We need PDF like a fish needs a bicycle
Jun 01 21:02:11 	heh
Jun 01 21:02:18 	rofl
Jun 01 21:02:19 	management likes PDF though
Jun 01 21:02:21 	that was good.
Jun 01 21:02:24 	Mgtment want's docs....
Jun 01 21:02:30 	yeah
Jun 01 21:02:32 	and management does read airplane magazines.
Jun 01 21:02:38 	html, rtf, and pdf.
Jun 01 21:02:46 	flash...
Jun 01 21:03:03 	flash  = bad.
Jun 01 21:03:06 	excel might be useful, or even CSV (problems with payload tho)
Jun 01 21:03:11 	Personally, I think you can do single html docs for mgmnt. 
Jun 01 21:03:18 	At least it appeases my PHB.
Jun 01 21:03:21 	I mocked up something to report to a flash system to load as a dashboard widget type thing
Jun 01 21:03:38 	evening all
Jun 01 21:03:44 	welcome marty.
Jun 01 21:03:46 	Welcome Marty....
Jun 01 21:03:54 	nice.
Jun 01 21:04:07 	how's things going here?
Jun 01 21:04:24 	I think well...
Jun 01 21:04:25 	we decided to rewrite snort
Jun 01 21:04:29 	
Jun 01 21:04:30 	In tcl.
Jun 01 21:04:32 	going good, we're just discussing some reporting modules we're thinking about building...
Jun 01 21:04:32 	lol
Jun 01 21:04:33 	lol
Jun 01 21:04:36 	heh
Jun 01 21:04:42 	I thought is was VB.net
Jun 01 21:04:43 	and we're going to discuss some problems.
Jun 01 21:04:44 	qru: heretic!
Jun 01 21:04:51 	no bot building, Joel
Jun 01 21:05:02 	roesch: Gonna use threads too. So we'll be snort++
Jun 01 21:05:19 *	eslerj says, "you're all geeks.."
Jun 01 21:05:26 	yup and proud of it...
Jun 01 21:05:27 	send me a note when you get the performance numbers back... :)
Jun 01 21:05:35 	heh
Jun 01 21:06:00 	marty, maybe you can chime in on this.
Jun 01 21:06:06 	ok...
Jun 01 21:06:09 	the biggest complaint we have
Jun 01 21:06:30 	is the barnyard/sid-msg.map/snort/base mapping.
Jun 01 21:07:21 	I remember a conversation that you and I had through email one time
Jun 01 21:07:33 	about having the sid-msg.map generate upon Snort startup.
Jun 01 21:07:41 	did you ever get a chance to look into that?
Jun 01 21:07:47 	oh yeah, never got around to looking at that
Jun 01 21:08:02 	k
Jun 01 21:08:03 	Tht's a really good idea.
Jun 01 21:08:15 	it would auto-fix all those ties..
Jun 01 21:08:24 	problem is, (correct me if I am wrong someone)
Jun 01 21:08:36 	problem is, the preproc's don't register their GID:SID pairs anywhere central
Jun 01 21:09:01 	roesch: That sounds like piss poor design.
Jun 01 21:09:04 *	qru runs away
Jun 01 21:09:06 	you'd have to sleep barnyard until after Snort starts all the way up.
Jun 01 21:09:20 	thanks, I do what I can (dick!)
Jun 01 21:09:26 	qru smokes crack.
Jun 01 21:09:29 *	eslerj nods
Jun 01 21:09:43 	No, but i am king of piss poor design :)
Jun 01 21:10:16 	eslerj: Yeah, I could see that being a problem.
Jun 01 21:10:36 	barnyard would balk if you tried to start it without an sid-msg.map
Jun 01 21:10:43 	Right now you have to kill BY, restart snort, then start BY again.
Jun 01 21:10:51 	how about just a perl script that can gen the sid-msg.map file from the rules directory?
Jun 01 21:11:03 	oinkmaster
Jun 01 21:11:04 	Maybe have snort write a dummy "flag" alert to tell barnyard to re-read the map file
Jun 01 21:11:14 	do you want the gid-msg.map too?
Jun 01 21:11:16 	after it rebuilt the map file
Jun 01 21:11:26 	does anyone use the gid?
Jun 01 21:11:39 	gid-msg.map doesn't have such a problem since it doesn't change much.
Jun 01 21:11:44 	yeah, we use it extensively
Jun 01 21:12:06 	then it would be beneficial.
Jun 01 21:12:10 	hm
Jun 01 21:12:22 	I think I like the idea of a stand alone script..
Jun 01 21:12:33 	unified2 is needed, then we could send messages to BY from snort (among other things)
Jun 01 21:12:37 	that way everyone could use it with out massive changes
Jun 01 21:12:49 	yeah
Jun 01 21:12:56 	and I like scripting
Jun 01 21:12:56 	problem with that is..
Jun 01 21:13:03 	we update the rulesets.
Jun 01 21:13:12 	what if two sid's are the same?
Jun 01 21:13:13 	I could also do the same thing I did for snort with the new runtime command interface where I make a unix domain socket that you can connect to and issue commands to the running process
Jun 01 21:13:13 	uh oh.
Jun 01 21:13:32 	What we need is for everyone to convert to BY, do some real testing, and thus help stimilate BY and unified development.
Jun 01 21:13:33 	roesch, that sounds like a direction....
Jun 01 21:13:49 	if two SID are the same, someone needs to be hit with a mallet
Jun 01 21:13:55 	it happens.
Jun 01 21:13:56 	ha!
Jun 01 21:14:00 	you know it does.
Jun 01 21:14:06 	:)
Jun 01 21:14:28 	I got with Jeff Dell and had him build in a dumass feature for IDSPM that checked for dups.
Jun 01 21:14:34 	are any of you using oinkmaster to merge rules, comment out specific rules, etc?
Jun 01 21:14:41 	nope.
Jun 01 21:14:43 	hhoffman: Sure.
Jun 01 21:14:45 	lol
Jun 01 21:14:47 	Yes, pretty extensively
Jun 01 21:14:51 	ah, ok
Jun 01 21:14:51 	I use IDSPM.
Jun 01 21:14:54 	lots of people use oinkmaster
Jun 01 21:14:57 	don't know that one
Jun 01 21:15:06 	IDS Policy manager.
Jun 01 21:15:11 	www.activeworx.org
Jun 01 21:15:19 	for you windows types.
Jun 01 21:15:27 	ah, not here ;-)
Jun 01 21:15:33 	windows = evil.
Jun 01 21:15:34 	not here either
Jun 01 21:15:36 	oink oink.  Even got oinkgui running 
Jun 01 21:15:41 *	cisc0man ducks for cover
Jun 01 21:15:47 	although we do run windows sensors and they work pretty well
Jun 01 21:15:54 	VERSION X-Chat Aqua 0.14.0 (xchat 2.4.3) Darwin 7.9.0 [Power Macintosh/900.00MHz]
Jun 01 21:16:03 	eslerj, show off....
Jun 01 21:16:15 	900 is not showing off.
Jun 01 21:16:22 	Matt and marty are probably on macs too.
Jun 01 21:16:32 	unified2 would be nice to have, but basically we need to come up with a set of serialization/deserialization routines
Jun 01 21:16:33 	sourcefire is heavy into macs.
Jun 01 21:16:45 	[Ignignokt ~]$ uname -a
Jun 01 21:16:46 	Darwin Ignignokt.local 8.1.0 Darwin Kernel Version 8.1.0: Tue May 10 18:16:08 PDT 2005; root:xnu-792.1.5.obj~4/RELEASE_PPC Power Macintosh powerpc
Jun 01 21:17:14 *	eslerj says, "Sourcefire runs DHCP"..
Jun 01 21:17:21 	what noone running CherryOS? ;-P
Jun 01 21:17:48 	certain people at sourcefire (superior people with straighter teeth and brighter smiles) are heavy into mac's, most of engineering is on linux, sales is on win32
Jun 01 21:17:57 	fedora here
Jun 01 21:18:11 	lol
Jun 01 21:18:12 	fedora here too
Jun 01 21:18:14 	here too
Jun 01 21:18:16 	fedora here three
Jun 01 21:18:19 	four
Jun 01 21:18:25 	Staighter teeth and brighter smiles.
Jun 01 21:18:26 	lol
Jun 01 21:18:29 	damn.
Jun 01 21:18:34 	(TM)
Jun 01 21:18:49 	okay, so we have that idea plugged into marty's brain.
Jun 01 21:18:55 	figured sales would be on blackberries
Jun 01 21:18:55 	what was the other one...
Jun 01 21:18:57 	oh..
Jun 01 21:19:00 	where's that mallet when you need one?
Jun 01 21:19:08 	I tried to maintain purity of essence within the company but it turned out that the linux people were just as parochial about their platform as the windows people
Jun 01 21:19:18 	damn skippy!
Jun 01 21:19:26 	Marty..  anyway we can get the snort.stats plugged into the DB somewheres?
Jun 01 21:19:41 	and mac people are even more anal.
Jun 01 21:19:46 	sales would like to be on blackberry but I refuse to allow an exchange server to be deployed in my company
Jun 01 21:19:51 	yes you are Joel....
Jun 01 21:20:16 	snort.stats?
Jun 01 21:20:21 	perfmon
Jun 01 21:20:22 	three cheers for roesch!
Jun 01 21:20:25 	the performance monitor.
Jun 01 21:20:28 	oh
Jun 01 21:20:29 	while marty's here, any ideas on [xxx]_portscan interfacing better with [database/unified/etc] alerts?
Jun 01 21:21:06 *	qru guesses Marty's answer is fsck portscan alerts.
Jun 01 21:21:15 	well, we don't maintain the db schema, that was under Roman/Jed's purview while they were working on ACID and is now your thing
Jun 01 21:21:42 	well in that case we would like to re-evaluate the schema
Jun 01 21:22:11 	you should build your own schema, the ACID schema was basically a science experiment....
Jun 01 21:22:21 	we are working on it for 2.x
Jun 01 21:22:29 	Snort is more interested in working with a unifed output, and the db schema is left up to.. whomeever.
Jun 01 21:22:43 	as long as we code a barnyard output, people would be happy.
Jun 01 21:22:56 	I have the barnyard stuff working.... our output that is...
Jun 01 21:22:59 	eslerj: Yep, just submit a op_base to Andrew and be mucho happy.
Jun 01 21:23:05 	as for portscan alerts, there needs to be an alert type for compound events
Jun 01 21:23:10 	damn I have way to much stuff in dir on my machine
Jun 01 21:23:31 	eslerj: yes
Jun 01 21:24:04 	roesch: I think there is still some problems with ref_time in tagged and sfportscan events.
Jun 01 21:24:09 	unified 2 was supposed to be a TLD data format, so in theory we could pump pretty much any data into it
Jun 01 21:24:25 	qru: that whole subsystem needs to be revamped
Jun 01 21:24:51 	when unified2 will be released? :)
Jun 01 21:24:57 	output/tagging/response needs to be put into a common unified API
Jun 01 21:25:11 	zroone: as soon as someone writes it
Jun 01 21:26:13 	then barnyard needs an input plugin that can read it
Jun 01 21:27:46 	serialization is a PITA
Jun 01 21:28:08 	I think event_ref is fine, but you need the time to correlate IIRC>
Jun 01 21:28:30 	Marty, is unified2 already designed/projected? you just need someone to code?
Jun 01 21:28:31 	yep.
Jun 01 21:28:32 	hey all.
Jun 01 21:28:42 	mind if I interrupt for a second.
Jun 01 21:29:00 	I've gotta go.
Jun 01 21:29:08 	Gotta pack, flying to NJ tomorrow.
Jun 01 21:29:21 	But using incremented numbers for serialization comes back and bites you :(
Jun 01 21:29:21 	I wanna thank everyone for the dicussion.
Jun 01 21:29:26 	zroone: we have something similar at sourcefire that we use for event comms between our stuff but it's never been moved into snort
Jun 01 21:29:43 	and it looks like we have alot of good areas to work on.
Jun 01 21:29:47 	ok
Jun 01 21:29:47 	qru: we need unique event ID's
Jun 01 21:29:49 	thanks Joel for organizing this.
Jun 01 21:29:59 	Kevin, if you can stick around, please log and post the chat on the web-page.
Jun 01 21:30:05 	I will...
Jun 01 21:30:07 	secureideas, no problem.
Jun 01 21:30:12 	something like a UUID or that packet serial number structure I was recommending a few months back
Jun 01 21:30:15 	Marty, matt, Jennifer, thanks for stopping by
Jun 01 21:30:27 	qru, we'll get with you soon...
Jun 01 21:30:36 	essler: Have a good trip.  My sympathies to you and your wife on your loss
Jun 01 21:30:39 	roesch: Yeah, I tried pushing microseconds for sguil. Got met with much resistance.
Jun 01 21:30:46 	eslerj: Cool.
Jun 01 21:30:49 	And tks.
Jun 01 21:31:09 	roesch: And it really needs to be done at the snort level.
Jun 01 21:31:09 	and the rest of the BASE developers, keep up the good work, keep trudging forward, I'd like to get all the open bugs knocked out before we do a release.
Jun 01 21:31:32 	if anyone is interesting in helping us code/joining the code team, please contact either kevin or myself.
Jun 01 21:31:32 	have a nice trip joel.
Jun 01 21:31:38 	at base@secureideas.net
Jun 01 21:31:49 	and we'll be sure and get you guys in the team.
Jun 01 21:31:55 	Thanks everyone for your kind comments.
Jun 01 21:32:19 	roesch: I think it was Brian who may have been talking about "UID"s.
Jun 01 21:32:39 	night everyone!
Jun 01 21:32:42 	night
Jun 01 21:32:50 	night
Jun 01 21:32:52 	laters
Jun 01 21:32:57 	I was recommending something like:
Jun 01 21:32:57 	struct packet_serial
Jun 01 21:32:57 	{
Jun 01 21:32:57 	    u_int32_t intf;
Jun 01 21:32:57 	    u_int32_t start_time;
Jun 01 21:33:00 	    u_int32_t packet_time;
Jun 01 21:33:02 	};  
Jun 01 21:33:28 	something like that
Jun 01 21:34:00 	Steve always puts a boot in me using time. Throws things like daylight savings at me.
Jun 01 21:34:08 	(that's why I run GMT, duh)
Jun 01 21:34:18 	you can only do it with GMT....
Jun 01 21:34:32 	unless the system translates....
Jun 01 21:34:45 	ah
Jun 01 21:34:48 	found it
Jun 01 21:34:56 	this is what I was recommending back in December
Jun 01 21:34:57 	typedef struct _PktSerial
Jun 01 21:34:57 	{
Jun 01 21:34:57 	        u_int8_t  if_mac[6];
Jun 01 21:34:57 	        time_t start_time;
Jun 01 21:35:00 	          u_int32_t pkt_id;
Jun 01 21:35:02 	} PktSerial;
Jun 01 21:35:17 	pkt_id a pkt_id++ thing?
Jun 01 21:35:21 	yep
Jun 01 21:35:29 	but you've got a unique instance ID
Jun 01 21:36:23 	Unless you cron to restart snort every hour.
Jun 01 21:36:27 	sensor if_mac is a neat idea
Jun 01 21:36:37 	you could also put things like an event_ref as well
Jun 01 21:37:17 	cisc0man: it identifies the instance of the engine basically, but I might need to do something a little fancier
Jun 01 21:37:24 	especially for things like bonded interfaces
Jun 01 21:37:29 	What about using some type of uniquie ID lib instead of pkt_id++  ?
Jun 01 21:37:42 	like a UUID?
Jun 01 21:37:57 	Yeah, or so called GUID (global unique IDs).
Jun 01 21:38:17 -->	fuzzyping (~jasondixo@69-174-136-18.frdrmd.adelphia.net) has joined #secureideas
Jun 01 21:38:21 ---	fuzzyping is now known as dixongroup
Jun 01 21:38:26 	hi folks
Jun 01 21:38:30 	yeah, we could do that
Jun 01 21:38:33 	hi dixongroup 
Jun 01 21:39:05 	GUID + time should be about as unique as you can get.
Jun 01 21:39:27 	Throw in interface stuff for giggles.
Jun 01 21:40:05 	interface + time gives you an instance ID
Jun 01 21:40:31 	which is unique
Jun 01 21:40:38 	at least until time_t wraps :)
Jun 01 21:41:05 	time_t isn't savings time aware?
Jun 01 21:41:14 	ah, ya got 33 years, almost
Jun 01 21:42:12 	I think we should do the daylight savings in what ever reporting system.
Jun 01 21:42:30 	let the program us a standard time...
Jun 01 21:42:30 	qru: your sensors should all be on GMT
Jun 01 21:42:37 	roesch: Mine are.
Jun 01 21:42:52 	But mine seem to be the minority.
Jun 01 21:43:24 	We pretty much beat you over the head with GMT in sguil, but people still try to avoid it.
Jun 01 21:44:00 	So once a year, you'd risk some idiot^H^H^H^H^Huser having a non-unique id with interface+time_t.
Jun 01 21:44:02 	why, do they enjoy dealing with timezones and daylight savings?
Jun 01 21:44:10 	roesch: I guess :/
Jun 01 21:44:15 	uhhh, you mean alerts are logged with localtime, not time_t? 
Jun 01 21:44:39 	alerts are using timeval (which comes out of pcap)
Jun 01 21:44:57 	roesch: Is that forced GMT by pcap then?
Jun 01 21:45:54 	no
Jun 01 21:45:55 	well, if some bozo sets their hardware clock to localtime, they asked for trouble.  it should always be GMT.
Jun 01 21:46:14 	Ohhh... ouch... nasty...
Jun 01 21:46:15 	roesch: So it's time_t based on when pcap reads the packet from the interface?
Jun 01 21:46:44 	qru: based on the system clock
Jun 01 21:46:56 	libpcap calls gettimeofday() when it grabs a packet
Jun 01 21:47:19 	So if you ntpd and you have timezone correct, you should be logging correct GMT?
Jun 01 21:47:31 	Which uses local TZ, right?
Jun 01 21:47:34 	cisc0man: yes
Jun 01 21:47:50 	qru: pcap uses whatever the system clock is using
Jun 01 21:48:02 	Ack, ntp adds another layer of problems.
Jun 01 21:48:06 	OK, so only bozos with TZ=GMT0 and hardware clock set to localtime have trouble.  whew...
Jun 01 21:48:15 	No, ntp solves numerous problems
Jun 01 21:48:18 	Your clock is 4 minutes fast, reset.
Jun 01 21:49:10 	If you are ntp synced and you drift 4 minutes, you've got worse problems :-)
Jun 01 21:49:15 	heh
Jun 01 21:49:54 	No, the problems come from those of us who run ntpdate by hand occasionally....
Jun 01 21:50:00 *	qru whistles innocently.
Jun 01 21:50:02 	Unless you've jumped into hyperspace, or engaged the improbability drive.  Did the Vogons give you a permit for that?
Jun 01 21:50:16 	ok, I've got about 15 minutes then I have to run
Jun 01 21:50:19 	at least cron it qru
Jun 01 21:50:21 	BTW, I am just throwing out possible problems that have already been chucked at my head.
Jun 01 21:50:21 	anyone got anything I can answer?
Jun 01 21:50:40 	I think we are wrapping up quickly...
Jun 01 21:50:44 	cisc0man: too much work.....
Jun 01 21:50:49 	Thanks for joining us....
Jun 01 21:51:03 	qru, wouldn't cron save work?
Jun 01 21:51:11 	heh
Jun 01 21:51:11 	No questions offhand, but thanks for a good sans webcast couple weeks ago Marty
Jun 01 21:52:11 	Let me thank everyone for joining us.
Jun 01 21:52:15 	cisc0man: my pleasure (as well as my marketing people's...) :)
Jun 01 21:52:22 	:)
Jun 01 21:52:24 	nice to meet you guys
Jun 01 21:53:00 	And remember if you have questions or want to sign up, base@secureideas.net
Jun 01 21:53:00 	Nice talking to you all. HAGO.
Jun 01 21:53:17 	Wonderful talking to everyone. Good night..
Jun 01 21:53:33 	thx secureideas
Jun 01 21:53:49 	Cheers for Kevin!!!
Jun 01 21:54:01 	Thanks...
Jun 01 21:54:37 	shutdown -h now
Jun 01 21:54:49 	ops, wrong place. :)
Jun 01 21:54:52 	
Jun 01 21:55:06 	see you
Jun 01 21:55:10 	bye
Jun 01 21:57:11 	And 1.1.3 should be out around the 15th.
Jun 01 21:57:32 	cool
Jun 01 21:57:35 	nice talking to everyone
Jun 01 21:57:43 	ditto
Jun 01 21:57:48 	same here....
Jun 01 21:58:17 	night all, great talk!
Jun 01 21:58:43 	we should have a discussion once a month
Jun 01 21:58:46 	or something.
Jun 01 21:59:08 	yes
Jun 01 21:59:22 	yeah, I'd try to show up
Jun 01 22:00:05 	at least a little bit before every release if not....
Jun 01 22:01:17 	good call.
Jun 01 22:01:24 	marty, feel free to idle here ;)
Jun 01 22:01:31 	I shall
Jun 01 22:02:12 	ok, ttyl
Jun 01 22:02:17 	later marty.