From pepperjack at autoshun.org Mon Jun 1 08:07:37 2009 From: pepperjack at autoshun.org (Jack Pepper) Date: Mon, 01 Jun 2009 07:07:37 -0500 Subject: [Discussion] The approach to detect proxybots In-Reply-To: <4A20C1EC.9040709@stud.ntnu.no> References: <4A20C1EC.9040709@stud.ntnu.no> Message-ID: <20090601070737.3r5kvzxhhc4w0s0w@mail.afferentsecurity.com> You might consider also posting this on the spamassassin mailing list (mailto:users at spamassassin.apache.org) . Lots of email managers and anti spam gurus over there. jp Quoting Gurvinder Singh : > Hi, > > First of all thanks to matt for introducing me to the open information > security foundation. I was in touch with matt and he suggested me to put > the concept in discussion list to get feedback on it from team. If > possible we can implement this concept to a preprocessor of the new > engine (read message from matt below). > > The approach is based on Interarrival Packet Time (IPT). The IPT is the > difference between current packet arrival time and the last packet > arrival time from the sender under current session. The IPT is recorded > from incoming packets at the receiving end. Consider the following scenario > (200ms) (50ms) > Spammer ------------> Proxybot -------------> Mail > server > > The spammer starts a session by sending a command to a bot. The bot > initiates a connection with the mail server and establishes a > connection. The mail server responds with greeting message and the bot > relays this message to the spammer. After receiving the greeting > message, the spammer sends HELO message to the bot and bot will relay > message to the server. The server will receive message after delay of > 250ms or higher which is the total delay on connection between mail > server and spammer. If the bot system is the real originator of message > request, then the HELO message will be received in 50ms by mail server. > This delay is seen on each command (MAIL FROM, RCPT TO and DATA etc.) > received from bot at server end. > > There is a probability that the delay can be due to congestion on the > network. But in above case server will receive an ACK message from bot > system after 50ms which signifies the lack of congestion on the network. > > I tested the approach for different protocols and find it working on > FTP, HTTP GET request (Tor), Telnet and simple data transfer using TCP. > I will be happy to answer any question regarding above approach and > looking forward to hear from you about feedback on the concept. The > above concept is result of my master thesis work. If possible, I would > like to join the team. > > P.S. The code can be released under GPL. > > Thanks for your time. > > Best Regards, > Gurvinder Singh > >> >> Matt Jonkman wrote: >>> Forgot to mention that this code will all be GPL. :) >>> >>> matt >>> >>> Matt Jonkman wrote: >>> >>>> Hello Gurvinder! Your timing couldn't be better. >>>> >>>> I'm fascinated by the concept, that would help in a lot of things we >>>> are >>>> currently challenged in with IDS. >>>> >>>> The timing is perfect because we've received US Dept of homeland >>>> security funding to build a new next generation IDS. We're about to get >>>> the bulk of our funding and begin development work. >>>> >>>> I'd like to talk to you about applying this concept to a >>>> preprocessor of >>>> the new engine. If you're interested I'd like to introduce you to the >>>> rest of the team. We're having our final planning and hiring meeting >>>> late next week. So this couldn't be more perfect. >>>> >>>> More information about us at http://www.openinfosecfoundation.org >>>> >>>> If you hop on the discussion mailing list we could bring the idea up >>>> and >>>> see what the community thinks about it as well. >>>> >>>> Thanks for contacting me! >>>> >>>> Matt >>>> >>>> Gurvinder Singh wrote: >>>> >>>>> Dear Matt Jonkmans, >>>>> >>>>> I am Gurvinder Singh, master student at Department of Telematics, >>>>> NTNU, >>>>> Trondheim, Norway. Currently i am working on my master thesis on topic >>>>> tittled "Detection of Intermediary Hosts through TCP latency >>>>> propagation". I performed experiments for different protocols and >>>>> find a >>>>> method to detect the intermediary hosts. After reading your article i >>>>> realize that my approach can be used to detect the spam coming from a >>>>> proxy system which is actually sent by some other system behind it. In >>>>> the scenario like this >>>>> >>>>> Spammer ----> ProxyBot ------> Mail Server or Relay >>>>> >>>>> at Mail server or relay we can detect the message is relayed via proxy >>>>> bot and thus server can drop the message and if the behavior is >>>>> persistent the IP address of Proxybot can be added to blacklists. I >>>>> was >>>>> wondering if you have some live traces of communication during arrival >>>>> of spam messages at mail server from proxybot, then i can have real >>>>> world data not just data from my lab. If yes, can it be possible to >>>>> share with me? I would appreciate any comment from you in this regard. >>>>> >>>>> Thanks for your valuable time. >>>>> >>>>> Best Regards, >>>>> Gurvinder Singh >>>>> >>> >>> >> >> > > > _______________________________________________ > Discussion mailing list > Discussion at openinfosecfoundation.org > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion > -- Simple compliance is a hacker's best friend ---------------------------------------------------------------- @fferent Security Labs: Isolate/Insulate/Innovate http://www.afferentsecurity.com From jonkman at jonkmans.com Mon Jun 1 11:23:31 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Mon, 01 Jun 2009 11:23:31 -0400 Subject: [Discussion] The approach to detect proxybots In-Reply-To: <4A217AF0.3070204@stud.ntnu.no> References: <4a21709d.0504c00a.3bcc.ffff860d@mx.google.com> <4A2171BA.5050105@secnap.net> <4A217AF0.3070204@stud.ntnu.no> Message-ID: <4A23F273.8060404@jonkmans.com> This is a spectacular idea I think. Definitely something we could use in a rule for a number of protocols. FTP, telnet, maybe even HTTP (although proxying in http isn't an indication of being evil). Imagine our existing spambot rules being able to also check if the connection is proxied. That puts us near 100% confidence in most cases. Matt Gurvinder Singh wrote: > Michael Scheidell wrote: >> >> Nick Rogness wrote: >>> This is an intersting approach. I don't know how probablistic the delays will be however. Most isp's will deliberately slow mail connects in the network to act as a sort of tarpit for spam farming. I know we do at least and have talked with others about it as well. This may be in transit or at the actual mail server. >>> >>> Additionally, with spammers, they are clever little SOBs. Once you have this detection working, they will change the botnet code to react differently to avoid detection. >>> >>> Nonetheless, one could increase the probability of detection with a significantly higher sampling...whether using information from other sensors in one network or from other sensors in other networks. A network of OISF sensors independently distributed across the internet would be useful for these types of detections and other like it via some sort of feedback system. >>> >>> I still think it would be worth investigating as one of many ways to detect these botnets. If you have some code to test I'll put it on our ISP network to see how well it works. >>> >>> >>> >> we run a managed anti-spam service, as well as sell appliances, and, >> yes, we do funky things with delays in between helo and data session. > There is a possibility to detect use of proxybots based on the inter > arrival packet time of data packets. This will add up to have small > false negative rate :) >> I would not count on any 'accident' but RFC compliant behavior. >> >> p0f is still a good source of passive os detection, and from the smtp >> side, why do I want windows 95 machines running smtp servers :-)? >> you might want to get with Lawrence Baldwin (mynetwatchman) he has >> some interesting data on DNS lookup timing and zombies. >> > will it be possible for me to get access of data from proxybots. ? It > would be great for me, as i am planning to write a paper and it will > help me to provide proof from real world data not just from lab :P >> in fact, he might be a good one to get involved in this project >> >> >> -- >> Michael Scheidell, CTO >> Phone: 561-999-5000, x 1259 >>> *| *SECNAP Network Security Corporation >> * Certified SNORT Integrator >> * 2008-9 Hot Company Award Winner, World Executive Alliance >> * Five-Star Partner Program 2009, VARBusiness >> * Best Anti-Spam Product 2008, Network Products Guide >> * King of Spam Filters, SC Magazine 2008 >> >> >> ------------------------------------------------------------------------ >> >> This email has been scanned and certified safe by SpammerTrap?. >> For Information please see www.secnap.com/products/spammertrap/ >> >> >> ------------------------------------------------------------------------ >> > > _______________________________________________ > Discussion mailing list > Discussion at openinfosecfoundation.org > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From gurvinde at stud.ntnu.no Tue Jun 2 11:15:28 2009 From: gurvinde at stud.ntnu.no (Gurvinder Singh) Date: Tue, 02 Jun 2009 17:15:28 +0200 Subject: [Discussion] The approach to detect proxybots In-Reply-To: <4A23F273.8060404@jonkmans.com> References: <4a21709d.0504c00a.3bcc.ffff860d@mx.google.com> <4A2171BA.5050105@secnap.net> <4A217AF0.3070204@stud.ntnu.no> <4A23F273.8060404@jonkmans.com> Message-ID: <4A254210.9000804@stud.ntnu.no> Matt Jonkman wrote: > This is a spectacular idea I think. Definitely something we could use in > a rule for a number of protocols. FTP, telnet, maybe even HTTP (although > proxying in http isn't an indication of being evil). > The motivation for the HTTP protocol is to detect the use of Tor protocol. As Tor is currently mis-used for the copyright infringement, web page defacement etc. The most of the method are based on including a code in their web page and executing it on client system to check out about the use of Tor. But the method in the given approach monitors the incoming request at the web server and decide the usage of tor in the incoming request based on the inter-arrival packet time :-) -Gurvinder > Imagine our existing spambot rules being able to also check if the > connection is proxied. That puts us near 100% confidence in most cases. > > Matt > > > Gurvinder Singh wrote: > >> Michael Scheidell wrote: >> >>> Nick Rogness wrote: >>> >>>> This is an intersting approach. I don't know how probablistic the delays will be however. Most isp's will deliberately slow mail connects in the network to act as a sort of tarpit for spam farming. I know we do at least and have talked with others about it as well. This may be in transit or at the actual mail server. >>>> >>>> Additionally, with spammers, they are clever little SOBs. Once you have this detection working, they will change the botnet code to react differently to avoid detection. >>>> >>>> Nonetheless, one could increase the probability of detection with a significantly higher sampling...whether using information from other sensors in one network or from other sensors in other networks. A network of OISF sensors independently distributed across the internet would be useful for these types of detections and other like it via some sort of feedback system. >>>> >>>> I still think it would be worth investigating as one of many ways to detect these botnets. If you have some code to test I'll put it on our ISP network to see how well it works. >>>> >>>> >>>> >>>> >>> we run a managed anti-spam service, as well as sell appliances, and, >>> yes, we do funky things with delays in between helo and data session. >>> >> There is a possibility to detect use of proxybots based on the inter >> arrival packet time of data packets. This will add up to have small >> false negative rate :) >> >>> I would not count on any 'accident' but RFC compliant behavior. >>> >>> p0f is still a good source of passive os detection, and from the smtp >>> side, why do I want windows 95 machines running smtp servers :-)? >>> you might want to get with Lawrence Baldwin (mynetwatchman) he has >>> some interesting data on DNS lookup timing and zombies. >>> >>> >> will it be possible for me to get access of data from proxybots. ? It >> would be great for me, as i am planning to write a paper and it will >> help me to provide proof from real world data not just from lab :P >> >>> in fact, he might be a good one to get involved in this project >>> >>> >>> -- >>> Michael Scheidell, CTO >>> Phone: 561-999-5000, x 1259 >>> >>>> *| *SECNAP Network Security Corporation >>>> >>> * Certified SNORT Integrator >>> * 2008-9 Hot Company Award Winner, World Executive Alliance >>> * Five-Star Partner Program 2009, VARBusiness >>> * Best Anti-Spam Product 2008, Network Products Guide >>> * King of Spam Filters, SC Magazine 2008 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> This email has been scanned and certified safe by SpammerTrap?. >>> For Information please see www.secnap.com/products/spammertrap/ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >> _______________________________________________ >> Discussion mailing list >> Discussion at openinfosecfoundation.org >> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion >> > > From jonkman at jonkmans.com Thu Jun 11 10:40:31 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Thu, 11 Jun 2009 10:40:31 -0400 Subject: [Discussion] Bylaws Draft 2 Available! Message-ID: <4A31175F.6090607@jonkmans.com> Thanks to everyone who commented on the existing Bylaws draft. We've made some changes to suit the comments and concerns. The major change being that contributors to the project retain their copyright of code or ideas. This was discussed on the lists and makes a lot of sense, and we hope will satisfy both our individual contributors as well as the organizations that intend to contribute. The latest (and lets hope final!) draft is available here: http://www.openinfosecfoundation.org/bylaws_draft_v0.2.txt We welcome further comment good or bad! The Open Information Security Foundation -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From tomb at byrneit.net Thu Jun 11 18:43:07 2009 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 11 Jun 2009 15:43:07 -0700 Subject: [Discussion] Bylaws Draft 2 Available! In-Reply-To: <4A31175F.6090607@jonkmans.com> References: <4A31175F.6090607@jonkmans.com> Message-ID: <70D072392E56884193E3D2DE09C097A91F40B0@pascal.zaphodb.org> I think we need more clarity as to what the position on patents will be, given that you are planning on GPLv3. Section 11 of the GPLv3 only requires licensing the patent in connection with the contributed Copyright, but given that you are assigning Copyright, you need to be clear how you handle any Patents practiced in the Copyrighted code. Clearly, the simplest case is the typical one envisioned in the GPLv3: A contributor contributes Copyright, and as part of that, grants a patent license under Section 11, para 3, of the GPLv3 "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version." Requiring assignment of patents is likely to be problematic, but there may be cases where contributors would like to do so, in which case there needs to be a way to address how a contributor is reverse licensed for their contributed patent. There also should be some discussion of the status of the contributed patent, as patents that are still under review may encumber OISF with additional costs if contributed, or create liability if the contributor grants a license to or assigns a Patent, some of whose claims, which claims are practiced in the code, turn out to be part of a prior, valid, patent (and thus the code infringes the IP of a non-contributor). This latter piece is a common problem with even GPLv2, an example being the MS FAT32 patent, which all GPL code that can read and write FAT infringes. We may also be severely limiting the reach of the project by using GPLv3, which is not exactly popular. Personally, I'm more comfortable with GPLv2. If it's good enough for Linux..... There should be some language about how a license is chosen, and process for appeal. Also, there needs to be definition of a quorum for all votes. The rest of it looks fine. YMMV, IMNSHO, etc etc (think Maurice in "Madagascar" as he introduces King Julian). -- Tomas L. Byrnes ByrneIT Phone (it will find me): 760.444.4727 Text Message: 7604023999 at messaging.sprintpcs.com e-mail: tomb at byrneit.net IM: MSN Messenger tomb at byrneit.net ????? Skype: zwithapggb >-----Original Message----- >From: discussion-bounces at openinfosecfoundation.org [mailto:discussion- >bounces at openinfosecfoundation.org] On Behalf Of Matt Jonkman >Sent: Thursday, June 11, 2009 7:41 AM >To: oisf-announce at openinfosecfoundation.org; >discussion at openinfosecfoundation.org >Subject: [Discussion] Bylaws Draft 2 Available! > >Thanks to everyone who commented on the existing Bylaws draft. We've >made some changes to suit the comments and concerns. The major change >being that contributors to the project retain their copyright of code or >ideas. This was discussed on the lists and makes a lot of sense, and we >hope will satisfy both our individual contributors as well as the >organizations that intend to contribute. > > >The latest (and lets hope final!) draft is available here: >http://www.openinfosecfoundation.org/bylaws_draft_v0.2.txt > > >We welcome further comment good or bad! > > >The Open Information Security Foundation > > > >-- >-------------------------------------------- >Matthew Jonkman >Emerging Threats >Phone 765-429-0398 >Fax 312-264-0205 >http://www.emergingthreats.net >-------------------------------------------- > >PGP: http://www.jonkmans.com/mattjonkman.asc > > >_______________________________________________ >Discussion mailing list >Discussion at openinfosecfoundation.org >http://lists.openinfosecfoundation.org/mailman/listinfo/discussion From jonkman at jonkmans.com Mon Jun 15 10:20:52 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Mon, 15 Jun 2009 10:20:52 -0400 Subject: [Discussion] Board Meeting Notes Message-ID: <4A3658C4.4030009@jonkmans.com> The Open Information Security Foundation held it's first Board Meeting and Planning Session. The meeting was incredibly productive, and we were able to secure the support of a number of new organizations and vendors. We're very excited about the future, and we've a lot of news to share. Most of the news and decisions that have been made we'll release in individual statements in order to avoid information overload. But overall let me summarize what the Foundation is doing and where we all stand: We have received allocation of the second phase funding, and we're part of the OSSI HOST program (http://www.oss-institute.org). This allows us to begin immediately our coding efforts. We have finalized hiring of about ten contractors for everything from coding and research to quality assurance and sysadmin work. These individuals will be introduced to the community soon, but you know most of them already. I'm VERY excited about the team that's coming together. That said we have room for more. Primarily we need more programmers, but we are also in search of an exceptional individual to become our documentation project lead. If you are interested please email jonkman at emergingthreats.net. We are in the process of building out our infrastructure. Code repository, QA lab and hardware, and public facing hosting and the like. We are in need of all sorts of assistance, the less we spend on hardware and infrastructure the more goes into coding efforts of course. If you or your organization is interested in becoming a member of the Foundation Consortium (which grants the ability to use an alternative more permissive license) please contact us now. We have quite a few needs that will save the foundation's resources for more directly beneficial effort. We'll be announcing a number of other things shortly, including a new draft of our bylaws, new mailing lists, and a list of the features we're going to build into our first release. Please stay tuned. While we're getting to coding later than we had hoped last year, rest assured we are still committed to a production release of the engine by the end of 2009! We will make this goal and we have the resources and brain trust to make it happen!! Thanks to all for your support to date. This is truly a community driven and supported project, and we look forward to cementing the relationships with both the community and the organizations that will be our constituency over time. -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From jonkman at jonkmans.com Mon Jun 22 15:41:05 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Mon, 22 Jun 2009 15:41:05 -0400 Subject: [Discussion] OISF Meeting Announcement! Message-ID: <4A3FDE51.2010206@jonkmans.com> We'll be having a public forum and brainstorming session in Washington DC on July 16th, 2009! This session will be a mix of technical and political issues. We encourage our current and potential consortium members, potential users and resellers, as well as future end users to attend. We very much want to hear from all in a discussion format what is most important to you, and what you need to have in the next iteration of IDS. The discussion on the lists has been great, but most often even better things come to life when a lot of smart folks are in the same room at the same time, as we've seen at our prior brainstorming sessions. We'll be getting quite technical, but we'll also answer any and every question about the politics, goals, and funding sources of the foundation. We know this is a very strange situation we have, being funded by DHS to create open source security software. So please plan to attend, July 16th in Washington DC, at the SRI Building in Rosslyn: http://www.sri.com/contact/wdc.html If you plan to or are rather sure you'll be there please drop an email to jonkman at emergingthreats.net, we need an approximate headcount for the catering, provided courtesy of SRI. If you can't make this one don't worry, we are planning similar meetings through the development cycle on the west coast and in Europe. We want to hear every idea we can get! Matt -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From jonkman at jonkmans.com Thu Jun 25 13:44:48 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Thu, 25 Jun 2009 13:44:48 -0400 Subject: [Discussion] Bylaws Draft 2 Available! In-Reply-To: <70D072392E56884193E3D2DE09C097A91F40B0@pascal.zaphodb.org> References: <4A31175F.6090607@jonkmans.com> <70D072392E56884193E3D2DE09C097A91F40B0@pascal.zaphodb.org> Message-ID: <4A43B790.9030806@jonkmans.com> Sorry for the delay in answering Tom, but you make good points. We've been talking to our counsel and think we have things ironed out. We are being VERY careful to have a solid legal framework to stand on that will allow the foundation to fulfill it's goals of building a great piece of software, making it open source and easy to use without license conflicts, and protecting the foundation and project from litigation down the road. So version 0.2 of the bylaws are available. The only changes are: 1. We are going with GPLv2 to avoid the patent complications. Those are surmountable, but the possible negative image some folks still have of gplv3 are something we don't want to have to overcome. 2 will work. 2. A quorum will be defined as a majority for voting purposes. (this isn't spelled out in the summary of the bylaws here. These are just working material, once we're set these will be drafted into full legalese and made available for review) So please all take a look and let us know if there are any other issues we should consider before the full bylaws are drawn up. http://www.openinfosecfoundation.org/bylaws_draft_v0.3.txt Thanks Tom and everyone for the frank and constructive conversation. It'll pay off for us all with a solid and reliable framework to get things done! Matt Tomas L. Byrnes wrote: > I think we need more clarity as to what the position on patents will be, given that you are planning on GPLv3. Section 11 of the GPLv3 only requires licensing the patent in connection with the contributed Copyright, but given that you are assigning Copyright, you need to be clear how you handle any Patents practiced in the Copyrighted code. > > Clearly, the simplest case is the typical one envisioned in the GPLv3: A contributor contributes Copyright, and as part of that, grants a patent license under Section 11, para 3, of the GPLv3 "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version." > > Requiring assignment of patents is likely to be problematic, but there may be cases where contributors would like to do so, in which case there needs to be a way to address how a contributor is reverse licensed for their contributed patent. There also should be some discussion of the status of the contributed patent, as patents that are still under review may encumber OISF with additional costs if contributed, or create liability if the contributor grants a license to or assigns a Patent, some of whose claims, which claims are practiced in the code, turn out to be part of a prior, valid, patent (and thus the code infringes the IP of a non-contributor). This latter piece is a common problem with even GPLv2, an example being the MS FAT32 patent, which all GPL code that can read and write FAT infringes. > > We may also be severely limiting the reach of the project by using GPLv3, which is not exactly popular. > > Personally, I'm more comfortable with GPLv2. If it's good enough for Linux..... > > There should be some language about how a license is chosen, and process for appeal. > > Also, there needs to be definition of a quorum for all votes. > > The rest of it looks fine. > > YMMV, IMNSHO, etc etc (think Maurice in "Madagascar" as he introduces King Julian). > > > -- > Tomas L. Byrnes > ByrneIT > Phone (it will find me): 760.444.4727 > > Text Message: 7604023999 at messaging.sprintpcs.com > e-mail: tomb at byrneit.net > IM: MSN Messenger tomb at byrneit.net > Skype: zwithapggb > > >> -----Original Message----- >> From: discussion-bounces at openinfosecfoundation.org [mailto:discussion- >> bounces at openinfosecfoundation.org] On Behalf Of Matt Jonkman >> Sent: Thursday, June 11, 2009 7:41 AM >> To: oisf-announce at openinfosecfoundation.org; >> discussion at openinfosecfoundation.org >> Subject: [Discussion] Bylaws Draft 2 Available! >> >> Thanks to everyone who commented on the existing Bylaws draft. We've >> made some changes to suit the comments and concerns. The major change >> being that contributors to the project retain their copyright of code or >> ideas. This was discussed on the lists and makes a lot of sense, and we >> hope will satisfy both our individual contributors as well as the >> organizations that intend to contribute. >> >> >> The latest (and lets hope final!) draft is available here: >> http://www.openinfosecfoundation.org/bylaws_draft_v0.2.txt >> >> >> We welcome further comment good or bad! >> >> >> The Open Information Security Foundation >> >> >> >> -- >> -------------------------------------------- >> Matthew Jonkman >> Emerging Threats >> Phone 765-429-0398 >> Fax 312-264-0205 >> http://www.emergingthreats.net >> -------------------------------------------- >> >> PGP: http://www.jonkmans.com/mattjonkman.asc >> >> >> _______________________________________________ >> Discussion mailing list >> Discussion at openinfosecfoundation.org >> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From jonkman at jonkmans.com Tue Jun 30 13:30:04 2009 From: jonkman at jonkmans.com (Matt Jonkman) Date: Tue, 30 Jun 2009 13:30:04 -0400 Subject: [Discussion] OISF DC Meeting Agenda Message-ID: <4A4A4B9C.1040305@jonkmans.com> We have a draft Agenda available for the July 16th OISF meeting in Washington DC. This is subject to some change, and the meeting will be relatively informal to allow any other topics to be discussed. We still have room for a more attendees, so please consider attending. RSVP to jonkman at emergingthreats.net so we can have adequate catering available. Agenda: Opening 10am ET Team Introduction Project Summary Status of Funding Unveiling of Foundation Logo Consortium Membership Benefits License and Legal Status Open Positions and Skill sets Status of Development Technical Discussion To include but not limited to: Multi Threading Hardware Acceleration Support IPv6 Support IP Reputation Global Variables Protocol Detection Web-based Configuration Multi-Packet Matching Rules Language and Support HTTP Module Engine Library-ization Protocol Normalization Open Discussion of Additional Requirements -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: oisf dc 2009 meeting agenda.pdf Type: application/pdf Size: 77844 bytes Desc: not available Url : http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20090630/e65e3647/oisfdc2009meetingagenda-0001.pdf