secureideas-base-devel Mailing List for BASE (Page 76)
Brought to you by:
secureideas,
sinukas
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(23) |
Oct
(41) |
Nov
(234) |
Dec
(45) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(93) |
Feb
(181) |
Mar
(70) |
Apr
(89) |
May
(77) |
Jun
(46) |
Jul
(32) |
Aug
(31) |
Sep
(12) |
Oct
(21) |
Nov
(10) |
Dec
(2) |
2006 |
Jan
(54) |
Feb
(34) |
Mar
(41) |
Apr
(33) |
May
(36) |
Jun
(30) |
Jul
(70) |
Aug
(36) |
Sep
(9) |
Oct
(7) |
Nov
(19) |
Dec
(26) |
2007 |
Jan
(29) |
Feb
(8) |
Mar
(13) |
Apr
(3) |
May
(7) |
Jun
(11) |
Jul
(1) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
(5) |
Dec
(23) |
2008 |
Jan
(34) |
Feb
(3) |
Mar
(5) |
Apr
(25) |
May
(8) |
Jun
(69) |
Jul
(67) |
Aug
(30) |
Sep
(16) |
Oct
(29) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(9) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
(14) |
2010 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris S. <ch...@co...> - 2004-09-12 02:21:05
|
I slightly modified the capability registry include file (base_capabilities.php) so that after the class definition it is instanced as $CAPAREG. This is because we will want the object instanced any time we include it. You can see some example usage on line 119 (AddValidAction function) in base_state_query.inc.php: function AddValidAction($action) { global $CAPAREG; if (! $CAPAREG->hasCapa(CAPA_MAIL) && (strstr($action, "email") || strstr($action, "csv"))) { // Do nothing } else { $this->valid_action_list[ count($this->valid_action_list) ] = $action; } } -- Chris Shepherd Wise man say, chemist who falls into acid, absorbed in his work. |
From: Kevin J. <kjo...@se...> - 2004-09-12 02:13:16
|
I have just commited all the files with the new header format... This should be the last time for a while that we will need to update all files at once..<grin> Kevin |
From: Chris S. <ch...@co...> - 2004-09-11 17:44:22
|
Kevin Johnson wrote: > Okay... It would be easier to maintain one version.... I will try to > test it out tonight on my php4 system... I will also be installing a > php5 system so that I can get started testing that. > > Since I wrote the first patches, I'll handle all cross-version compatibility co-ordination, so if any of the devs find problems under PHP4 due to PHP5-patching, I'll work on working around them. > Personally I like the quick look I took.... Are we going to need a > check for PHP5? I really need to look at 5 before I continue to ask > dumb question<grin> > > There's a good guide to the differences between PHP4/5 at: http://www.sitepoint.com/article/coming-soon-webserver-near/5 Basically if we avoid public/private use, the new constructor/destructor methods, abstract classes, interfaces, exceptions, etc.. We should be by and large fine if we write for PHP4, although the OOP model of PHP5 is very enticing as in, it is an actual OOP model, instead of an objective-C style approach. I think we may want to look down the road and set a project date to start working on writing solely for PHP5, when it will be very popular due to its OO capabilities. We need not worry about it now, it will be quite a while before that is the case, and MOST of PHP4 functionality is backwards compatible. > The only other thing that I forgot last night was that for compatibility > reasons I would like to leave the database tables the way they are. So > if we can add tables but I would rather wait a while before we modify > the existing tables. We will then have a couple of scripts for the > databases... one that has every table and thing needed and one that is > an upgrade script for ACID users which will only have the additional > things.... > > Good idea. It will simplify everything. I noticed when I was going through that all the SQL table names are still prefixed with acid_, and I assumed that was for seamless upgrade purposes. I think we should make a target of 1.0 to convert all the table names. Hopefully by that release there will be a lot of changes, and it will make BASE a separate product from ACID. -- Chris Shepherd Wise man say, chemist who falls into acid, absorbed in his work. |
From: Kevin J. <kjo...@se...> - 2004-09-11 14:25:30
|
On Sat, 2004-09-11 at 01:15, Chris Shepherd wrote: > I am actually running PHP5, so I think we should be good to go in terms=20 > of testing. We should commit to regularly testing the patches backwards.=20 > As long as the patches for PHP5 compatibility don't break BASE on PHP4,=20 > I see no reason to keep a separate directory. PHP CAN be written so as=20 > not to cause problems between the two, the changes aren't all that drasti= c. >=20 Okay... It would be easier to maintain one version.... I will try to test it out tonight on my php4 system... I will also be installing a php5 system so that I can get started testing that. > As for the Registry, it is committed at the moment as=20 > base_capabilities.php in the includes/ directory. Right now it checks=20 > for four things: mail(), PEAR::Mail, PEAR::DB, PEAR::Image_Graph.=20 > Example use: > $reg =3D new CapaRegistry(); > $reg->hasCapa(CAPA_MAIL); // Detects mail() >=20 > The capabilites are defined as: CAPA_MAIL, CAPA_PMAIL, CAPA_PEARDB,=20 > CAPA_PGRAPH (pretty obvious at this stage). I'll work on implementing=20 > this usage for whether to display mail links and such provided you're=20 > okay with the way the class is setup Kevin. Personally I like the quick look I took.... Are we going to need a check for PHP5? I really need to look at 5 before I continue to ask dumb question<grin> The only other thing that I forgot last night was that for compatibility reasons I would like to leave the database tables the way they are. So if we can add tables but I would rather wait a while before we modify the existing tables. We will then have a couple of scripts for the databases... one that has every table and thing needed and one that is an upgrade script for ACID users which will only have the additional things.... Kevin |
From: Chris S. <ch...@co...> - 2004-09-11 05:13:18
|
Since Kevin lead the way with the introduction, I figure I should follow suit. I'm a long-time developer/sysadmin, and have been doing a lot of work with web projects in the last five or six years. The languages I've primarily worked with are: ASP(VBS/JS), Java, Visual Basic, C, PHP, Perl, HTML/DHTML, XML, and a fair bit of work with SQL. I've also done a load of systems admin work on various OSes (Windows 9x/NT/2K, Linux, Solaris, BSD, etc). My primary interest lies in security, on both the development side, and on the systems admin side of things. I'm 23 and currently in college, and have had four years of in the field experience doing a mix of Windows/Linux/Unix admin and Windows/Linux development prior to enrolling this year. >I think it is obvious what each of the directories holds.<grin> I am >thinking that until Chris finishes the capability repository, which I >will let him explain :) , we should add a php5 directory and put the two >patched files there with instructions on where they should go... > > I am actually running PHP5, so I think we should be good to go in terms of testing. We should commit to regularly testing the patches backwards. As long as the patches for PHP5 compatibility don't break BASE on PHP4, I see no reason to keep a separate directory. PHP CAN be written so as not to cause problems between the two, the changes aren't all that drastic. As for the Registry, it is committed at the moment as base_capabilities.php in the includes/ directory. Right now it checks for four things: mail(), PEAR::Mail, PEAR::DB, PEAR::Image_Graph. Example use: $reg = new CapaRegistry(); $reg->hasCapa(CAPA_MAIL); // Detects mail() The capabilites are defined as: CAPA_MAIL, CAPA_PMAIL, CAPA_PEARDB, CAPA_PGRAPH (pretty obvious at this stage). I'll work on implementing this usage for whether to display mail links and such provided you're okay with the way the class is setup Kevin. >I also think we should look at changing the graphing library away from >jpgraph since they have a commercial license. I am not sure, but I >think it would cause people who want to use BASE in a business, most >people, to have to pay for a license if they followed the license >correctly.( I need to research this one a bit) > > Indeed. I would favour using PEAR classes whenever possible, given their close ties to PHP in terms of compatibility. >I would also like to change the header of the files to the below >format.... >[...] > > Looks good to me. When I committed the capabilities registry (base_capabilities.php) I used this header. -- Chris Shepherd Wise man say, chemist who falls into acid, absorbed in his work. |
From: Kevin J. <kjo...@se...> - 2004-09-11 04:23:19
|
Hi all and welcome to the first post of the BASE-developer list! Since we are just getting started I thought that I could use this message to try and set some standards for the work we are doing and hopefully get some feedback all of you as to the best way of doing this.... so this message will probably end up longer then most that I would send. First I guess I should introduce myself. I am Kevin Johnson and I am 31 years old. I have been everything from a developer to a sysop to a network administrator. I run mostly Linux at my house but have VMWare where I test on various other platforms. My preferred distro is Fedora. I write in PHP, C, C++ Perl, VB(I know) and Assembly. I am pretty heavy into security and security testing and have been for a few years. I also currently live in Jacksonville Florida. Now onto the important stuff..... The current release of base is 0.9.7.1 (Francis) [yes after the hurricane] The directory structure is as follows... root/ docs/ images/ includes/ sql/ styles/ I think it is obvious what each of the directories holds.<grin> I am thinking that until Chris finishes the capability repository, which I will let him explain :) , we should add a php5 directory and put the two patched files there with instructions on where they should go...=20 I also think we should look at changing the graphing library away from jpgraph since they have a commercial license. I am not sure, but I think it would cause people who want to use BASE in a business, most people, to have to pay for a license if they followed the license correctly.( I need to research this one a bit) I would also like to change the header of the files to the below format.... /**************************************************************************= ****************************************** ** Basic Analysis and Security Engine (BASE) ** Copyright (C) 2004 BASE Project Team ** Copyright (C) 2000 Carnegie Mellon University ** ** (see the file 'base_main.php' for license details) ** ** Project Lead: Kevin Johnson <kjo...@se...> ** Built upon work by Roman Danyliw <rd...@ce...>, <ro...@da...> ** ** Purpose: Type the purpose of this file here ***************************************************************************= ****************************************** ** Authors: ***************************************************************************= ****************************************** ** Put each person who changes stuff here in the Name <email> format ** ***************************************************************************= ****************************************** */ This way we have a standard header and we can keep track of who has worked on stuff... =20 I would like to also use the odd even version number scheme. 0.9.7.x is a development release 0.9.8.x will be the stable release. I expect that 0.9.7.2 will include the PEAR::DB switch and the start of the capability system. I will also try and update all of the headers this weekend. I also see the following things as TODO items... please add, comment and pick from it... - Short Term (all started to some degree) - Modify the UI for a more professional and easier to use interface - documentation - full input validation - Switch tables to divs and really use the css - PEAR::DB support - Optimize the SQL statements in the application. There are many places wh= ere I think this could be done, first of which is in applying=20 functions (archive, delete, etc) to alerts. - Optimize the SQL statements in the application. There are many places wh= ere I think this could be done, first of which is in applying=20 functions (archive, delete, etc) to alerts. - Modify certain SQL statements to use transaction processing. = =20 - Long Term - User Authentication - Security System - Create a capability registry that would list what the install was capabl= e of, and modify functionality as such. For example, if the mail()=20 function is nonexistent it shouldn't give users the option to email stuff,= which will only lead to errors. This would apply to graphing as=20 well, and any other forward going yet optional pieces. - Add regular expression filtering of alerts. - Add internationalization support (timezone support and multi language su= pport) - Add event suppression with the ability to limit it to specific offenders= . This is handy for when a snort rule hits on a box you KNOW=20 will generate certain types of traffic, and don't need an alert in that on= e instance, but do need the alert for other hosts. - Add attacker tracking. I see this operating in such a way that an admin = could flag a specific host as an offender, which would then be=20 viewable on its own separate list. - Correlation Engine - Other sources of alert data Now I know that this is all pretty ambitious but I really see a need for it= . Again thanks to everyone for joining up and I hope that we can continue to = work well together. Kevin By the way, all of my emails will be PGP signed |